Product Developer

Промо в бигтехах Немного философский пост о том, как устроено повышение в корпорациях — от человека, который уже полгода работает «в шапочке» следующего грейда, но все еще не получил промо. И да, я понимаю, почему так, и сейчас буду вам объяснять, что это нормально. Попутно расскажу, почему успеха на текущем грейде недостаточно, чтобы получить промо, а матрица компетенций не всегда работает так, как задумана. ——— В корпорациях все знают: хочешь промо — заполняй матрицу компетенций следующего грейда. Почему так? Чтобы избежать или уменьшить влияние Принципа Питера — «В иерархической системе каждый индивидуум имеет тенденцию подниматься до уровня своей некомпетентности». Проще всего объяснить это как промо за успехи на текущем грейде. Типа, Вася самый лучший разработчик в команде. Тимлид уходит — ставим Васю тимлидом. Разберется. Или так: Вася — хороший мидл, но что-то заскучал. Повысим его до сеньора. Чтобы избежать принцип Питера, в бигтехах принято сначала успешно делать что-то на уровне следующего грейда, а потом уже получать за это промо. Побочные эффекты Проблема такого подхода в том, что у сотрудника появляется мотивация и склонность «натягивать» проявления компетенций. Помню, как пришел тимлидом в Авито, и старательно выискивал проявления TUL’a (руководителя юнита). Вот я цели на год составил — галочку поставил. Сейчас хихикаю, понимаю что это было как раз натягивание. При этом уверен, что заполняя матрицу на руководителя кластера, я точно так же склонен искать разовые проявления и переоценивать собственные навыки. Роль руководителя и почему объяснение может ранить Задача руководителя — объяснить, как матрицу для грейда Х трактуют те, кто проводит перформанс-ревью для этого грейда. И из-за того, что сотрудник склонен «натягивать», это объяснение от руководителя может считываться как обесценивание. «Да, цели на год есть, но они чисто операционные. А где твоя персональная техническая повестка? Куда ты ведёшь юнит с точки зрения техландшафта?» пу-пу-пу.. в матрице-то написано просто «составляет цели на год». А тут оказывается какая-то повестка требуется и техландшафт. И таких вещей много, а матрица достаточно компактная. Получается, нужно выпускать дополнительный «поясняющий» документ к матрице? Слишком сложно, да и читать его никто не будет, скорее всего. Потому что людям некогда читать инструкции. Им нужно чтобы инструмент был очевидным и самодокументируемым. А матрица не может быть такой, — в качестве сопровождения нужна сотня примеров проявлений разных сотрудников. Редкость проявлений на высоких грейдах От сеньоров требуются проекты на квартал или полгода. Понятно, что такие проекты появляются не часто. От менеджеров тоже требуют проявлений компетенций, которые могут быть достаточно редко нужны. Условно, средний тимлид М2 в Авито нанимает одного-двух инженеров в год. Таким образом, техлиду М1 скорее всего потребуется год, чтобы показать, что он умеет самостоятельно нанимать, и поставить галочку в матрице тимлидов. Средний TUL М4 нанимает тимлида раз в 2 года. Таким образом, тимлиду в шапочке aTUL нужно 2 года, чтобы закрыть компетенцию М4. Средний кластерлид М6 нанимает TUL’a раз в 3 года. .. Ну вы поняли. Чем выше грейд — тем больше долгоиграющих компетенций надо закрыть. А справедливо ли это? Выглядит как несправедливость: человек сидит «в шапочке» грейда Х+1, делает работу Х+1, но получает зарплату грейда Х. Но если это повышение нужно самому сотруднику — считаю, что это ок. А вот если это компания приходит к сотруднику и говорит «нам надо чтобы ты работал работу грейда Х+1» — справедливо сразу дать за это компенсацию. Проблема в том, что обычно процесс одинаковый для всех. Давайте обсудим в комментах. P.S. Не говорю, что это идеальная система и всем срочно надо так же делать в любом стартапе. Это способ обеспечить управляемость системы, как в посте про Performance Review. Добро пожаловать в мир корпоративных процессов и правил :)

Манипуляции: норма влияния или психологическое мошенничество? Disclaimer: пост — реклама бесплатного вебинара Soft Skills Lab. Ребят уважаю, тема откликается, сам пойду. Иногда после разговора ловишь себя на мысли: «согласился на лишнее — ещё и виноват». Определение с википедии:

Психологи́ческая манипуля́ция — тип социального воздействия (или социально-психологический феномен), представляющий собой деятельность с целью изменить восприятие (или поведение) других людей при помощи скрытой, обманной, насильственной тактики в интересах манипулятора, можно привести аналогию с понятием психологическое мошенничество.

Моё мнение: описание на википедии достаточно противное, а на самом деле ничего ужасного в манипуляциях нет. Манипуляция — это по сути своей влияние. Преднамеренное или нет, явное или скрытое — не так важно, и в слове «манипуляция» не зашито. Влияние — это ок, все мы друг на друга влияем. Это как эффект наблюдателя в физике: сам факт наблюдения за фотоном уже влияет на его состояние. Вопрос в границах: где заканчивается нейтральное или «win-win» влияние и начинается мошенничество, которое надо замечать и пресекать. Признаки «не той» манипуляции: ▫️ Апелляция к вине/стыду: «из-за тебя все пострадают» ▫️ Дефицит и FOMO: «последний шанс, решай сейчас» ▫️ Ложная альтернатива: «или так, или никак» ▫️ Обесценивание границ: «да это же мелочь» ▫️ Спекуляция лояльностью: «ты же командный игрок» 🗓 28 августа, 20:00 мск — открытое занятие «Защита от манипуляций» (Zoom, бесплатно) от Soft Skills Lab. За 1,5 часа разберём на кейсах: — На чём строится манипуляция и как вас втягивают в чужой сценарий — Почему одни приёмы на вас «заходят», а другие нет — Универсальный принцип защиты в любом контексте 👩‍🏫 Спикер — Нелли Григорьева, преподаёт переговоры в ВШЭ. Можно прийти со своими ситуациями — разберём в эфире. 👉 Запустите бота, чтобы получить ссылку на Zoom. Я пойду. Реклама. ИП Клименко А.А. ИНН 772077460576 erid: 2Vtzqx5PcHx

Исследование тимлидов Каждый год проходит большой опрос тимлидов от DevCrowd, и я вас призываю его пройти. Это некоммерческая история, мне не платили за этот пост, и да, опрос я прошел. Прохождение займёт у вас ~1-5 минут. В сентябре ребята подобьют результаты и выложат в виде красивой инфографики. А пока поделюсь интересностями прошлого года. В прошлом опросе приняло участие 659 человек, из которых: - 70.1% – тимлид - 21.4% – менеджер менеджеров - 8.5% – директор 📌 Топ-3 обязанности руководителей любого уровня: 1️⃣ Собеседования, 2️⃣ Развитие людей в команде 3️⃣ Оценка их перфоманса. 📌 Топ-3 навыка на прокачку: 1️⃣ Стратегическое видение, 2️⃣ Коммуникации, 3️⃣ Самоорганизация 📌 — Каждый четвертый тимлид столкнулся в прошедшем году с чрезмерным объемом работы. 📌 — При этом только 6.7% тимлидов активно собеседуются. Остальные не планировали менять работу в ближайший год 📌 — Большинство тимлидов тратит не более 30% рабочего времени на написание кода. 📌 — Медианная зарплата тимлида в 24 году — 400к рублей. Интересно будет посмотреть на результат 25 года. Подробнее, с инфографикой и цифрами — Ссылка на результаты 2024. ——— P.S. там есть вопрос про медиа, которые вы читаете. Ну вы знаете, что отметить 🙂 Пройти опрос

Как научиться не перебивать У меня есть проблема. Если у тебя её нет, — ты либо святой человек, либо врёшь (возможно сам себе). Я перебиваю людей. Не потому что вредный и злой редиска, а потому что «хочу как лучше». Чаще всего мне кажется: вот прямо сейчас если я не добавлю эту мысль, то без неё всё потеряется, мы будем обсуждать не то и встреча станет бессмысленна. Кому я вру. Я перебиваю не потому что «хочу как лучше», а потому что импульсивен, ставлю собственное мнение выше мнения других, и не умею вовремя остановиться. Когда-то услышал фразу «если тебя перебивают — значит, ты позволяешь это делать». С тех пор я не стеснялся перебивать и не считал это проблемой. Ну подумаешь, встрял в фразу — ничего страшного, мы же в диалоге. Тем более, человек сам позволил это. Потом начал замечать, что у людей от этого сбивается мысль, теряется мотивация продолжать и возникает ощущение, что их не слушают. И всё больше становится людей на мьюте, и всё сложнее становится вовлечь их в диалог. Короче, перебивание — это не сигнал вовлечённости. Это сигнал, что я не умею слушать. Надо с этим что-то делать. Вот три вещи, которые помогают (когда не забываю их применять). 1. Правило трёх секунд Самый простой и самый трудный совет. Прежде чем сказать что-то — пауза на 3 секунды. Да, я иногда прямо считаю про себя до трёх. Да, будет казаться, что это очень долго. Да, сначала это выглядит странно. Но обычно происходит такое: — Человек продолжает говорить. Значит, мысль не закончена. Хорошо, что ты не вклинился. — Ты даёшь себе время подумать, а не просто реагировать на последнюю фразу. Дискомфортная тишина — не враг. Это пространство, в котором люди думают. 2. Записывать, а не перебивать Почему я перебиваю чаще всего? Потому что боюсь забыть мысль. Она кажется важной, критически важной прямо сейчас. И я боюсь её потерять. Теперь у меня рядом блокнот (или приложение с заметками), и я просто пишу туда то, что хотел сказать. А когда человек договорит — выбираю: это всё ещё важно? если да — нужно ли это говорить прямо сейчас? Почти всегда оказывается, что половина моих мыслей уже озвучена другими, а другая половина уже не кажется такой важной через 5 минут. 80% «перебивок» просто растворяются. 3. Признать проблему вслух Я начал прямо говорить: «Если я вдруг перебью — скажи мне об этом. Я над этим работаю». Эта фраза меняет тон разговора. Во-первых, ты берешь на себя ответственность, а не сваливаешь на культуру / Zoom / задержки. Во-вторых, люди чувствуют, что ты хочешь слушать, а не доминировать. Итог Если тебе правда важно, что человек говорит — дай ему место. Если тебе важно, что ты скажешь — тем более стоит подождать. Тогда это услышат. P.S. До сих пор иногда перебиваю. Но теперь слышу это и учусь останавливаться. Иногда даже успеваю. Если есть ещё способы — напишите в комменты, поделитесь опытом. Upd Из комментариев: ...пункт 0: научиться хотеть слушать и услышать. Желание перебивать пропадает, когда ты приходишь не рассказать, а выслушать. Если менять свою позицию с «сейчас я всех научу» на позицию «я хочу услышать разные варианты и выбрать лучший», то дальше сильно легче становится не перебивать.

Авито и ВШЭ запускают магистратуру для продактов Когда я учился в Бауманке, традиционные программы давали скорее базу и тренировали навык быстро сориентироваться в куче материала, чтобы сдать сессию. Были крутые преподы, которые на собственном энтузиазме делали полезные и современные курсы. Это было супер ценно, но таких было буквально единицы. У сегодняшних студентов в этом плане есть из чего выбрать. Авито уже несколько лет сотрудничает с топовыми вузами страны. Уже есть программа по аналитике и Data Science в Физтехе, курс для инженеров в ИТМО. А теперь, — полноценная магистратура для продактов в НИУ ВШЭ, той самой Вышке! Чем это круто? 1. Курсы построены вокруг матрицы компетенций продакта в бигтехе. Внутри программы: аналитика, custdev, юнит-экономика, архитектура продукта, стратегия, ML — это значит, что знания можно применить сразу в реальной работе. 2. Программа создана совместно с действующими продактами, аналитиками, UX-исследователями и экспертами Авито. Никакой устаревшей информации. 3. Студенты могут попасть в Avito Product Bootcamp — 9 месяцев работы с реальными задачами, командой и зарплатой. Если бы такая магистратура существовала в моё время — возможно, моя карьера сложилась бы быстрее и проще 🙂 Авито финансирует 30 из 42 мест, так что шансы попасть весьма высокие. Документы можно подать до 8 августа.

Два подхода к обучению: Principles-first vs Application-first Disclaimer: этот пост — реклама библиотеки кейсов от Карьерного Цеха. В книге The Culture Map Эрин Мейер меня зацепило описание 2 подходов к обучению: 📌 Principles-first (от принципов к практике): Сначала глубоко разбираешься в теории, понимаешь фундаментальные принципы, и только после этого идёшь применять их на практике. Так обучают в традиционной российской школе и вузах: «Разберусь в сути, остальное приложится». Плюсы подхода: ➕ Позволяет глубоко понять и систематизировать знания. ➕ Даёт фундамент для самостоятельного принятия решений. Минусы: ➖ Может казаться слишком теоретическим и оторванным от реальной жизни. ➖ Не всегда понятно, как и где использовать теорию на практике. 📌 Application-first (от практики к принципам): Обучение сразу идёт через конкретные примеры и ситуации, на основе которых затем выводятся общие принципы. Так учатся маленькие дети: моя дочь изучает мир не через принципы, а через множество конкретных ситуаций. «Разберусь на примерах — а потом пойму почему». Этот подход хорошо работает и для взрослых и применяется в андрагогике. Наш мозг гораздо эффективнее запоминает то, что сразу можно применить. Application-first — это про насмотренность и наработку опыта через большое количество кейсов. Плюсы подхода: ➕ Прямая связь знаний с практикой, быстрый результат. ➕ Уверенность в решениях, т.к. ситуации уже встречались. Минусы: ➖ Меньше глубины, если не уделять внимание обобщению. ➖ Без должного анализа может превратиться в «делай по шаблону». Какой подход лучше? Они разные. Лучше работает комбинация: 1. Application-first для быстрого старта, насмотренности и уверенности. 2. Principles-first для систематизации знаний и осознанности решений. Ребята из Карьерного Цеха сделали полезный продукт, заточенный именно под прокачку насмотренности — большую библиотеку продуктовых кейсов и разборов от экспертов рынка. Внутри библиотеки: 🎥 Видеоразборы реальных продуктовых задач. 📌 Конкретные кейсы с подробными комментариями. 🎧 Удобный формат: можно смотреть видео, а можно слушать как подкаст по дороге на работу. Подойдёт, если вы: — Продакт, который хочет расширить набор рабочих решений. — Планируете стать продактом и хотите понять, что это за работа. — Хотите держать себя в тонусе и быть в курсе актуальных задач и решений на рынке. Цена для моих подписчиков: 7 дней доступа за 1₽, затем 1800₽ вместо 2000₽ в месяц по промокоду PRDEVELOPER 👉 Оформить подписку Реклама. ИП Федоров Е.П. ИНН 532008901966

Performance Review: the good, the bad, the ugly Я уже когда-то писал пост про перфревью. А потом еще один про калибровки. Тогда впервые проходил процесс, и казалось что цель — справедливость для всех и каждого. Сейчас заканчивается мой седьмой цикл перфревью. Первые два я прошел как тимлид. Тогда для меня главным было, чтобы все мои инженеры получили справедливые (по моему мнению, конечно же) оценки. Всё остальное было вторично. Следующие четыре — как руководитель юнита. У меня всё еще было некоторое понимание, какая оценка будет справедливой для работы некоторых инженеров. Но все ребята в юните уже в голову не помещались. Поэтому на первый план вышла работа с тимлидами и помощь им в проведении перформанс ревью. Сейчас первый цикл прохожу как руководитель кластера. Теперь понимаю, что справедливость у каждого тимлида своя и в финансовый отчет её не положишь. Пришло время переосмыслить, зачем оно вообще нужно. Помог подкаст Бреслав и Ложечкин, выпуск «Как устроен карьерный рост в Корпорациях» Вот к чему пришел. 1. Основная цель — управляемость компании как системы В Бауманке у нас был курс ТАУ — Теории Автоматического Управления. Управление – это такая организация технологического процесса, которая обеспечивает достижение поставленной цели. Применительно к компании: 1. Сотрудники или команды — элементы системы, объекты управления 2. У каждого элемента есть вход, куда подаются сигналы — цели / KPI 3. И выход, откуда берется результат работы Система преобразует сигнал с выхода «проделанная работа» и подаёт его на вход как сигнал «оценка перформанса». Сигнал «оценка перформанса» влияет на выполнение следующей «работы». Высокая оценка — сигнал развиваться дальше в том же направлении. Низкая — сигнал скорректировать курс. Эта обратная связь — то, что обеспечивает управляемость системы. Без нее система либо уйдет вразнос, либо затухнет. С ней — стремится к заданным параметрам. Что до справедливости.. Это вторичный продукт. Абсолютной справедливости не существует, потому что это она субъективна и у каждого своя. Звучит бездушно, но на больших числах по-другому не работает. Когда у тебя 1000+ сотрудников, ты физически не можешь с каждым поговорить. Тебе приходится управлять через абстракции и метрики, прятать живых людей за цифрами. 2. Защита от ошибок и выравнивание стандартов Если у вас классные люди и классный руководитель — можно жить и без ревью. Но если руководитель не очень, или у него депрессия, или личные проблемы — система поддерживает минимальный средний уровень и не дает упасть ниже. Ревью защищает компанию от ошибок менеджеров: — Не поднял зарплату сотруднику вовремя — Не дал обратную связь о работе из-за ежедневной суеты, или дал неправильную — Некорректно использует ресурсы компании. Например, дает сеньорам простые мидловские задачи Система заставляет руководителя регулярно думать об этих вещах, даже если ему не хочется или некогда. Правда, эта же система не дает и высоко подпрыгнуть от среднего уровня. Эта усредниловка — цена за стабильность. Перформанс ревью — это система-уравнитель. 3. Защита от инфляции грейдов и хаоса при ротациях У каждого тимлида своё понимание: кто такой джун, где заканчивается мидл, откуда начинается сеньор. Без выравнивания всё начинает плыть. Особенно когда люди переходят между командами. Если убрать перформанс ревью и калибровки — то будет очень обычная ситуация «что-то Вася загрустил, дадим ка ему повышение». Когда все знают, что промо — это не «руководитель захотел», а часть системы, у людей появляется ощущение прозрачности. Хотя это не всегда делает систему справедливой. Итог Можно не любить ревью. Я сам часто не люблю. Оно отнимает время, вызывает споры, и почти всегда есть кто-то недовольный. Но альтернатива — хаос, в котором компания обречена, потому что не может повернуть руль. Если ты сотрудник — не воспринимай оценку как вердикт. Это не суд, это сигнал. Если ты менеджер — старайся быть тем, кто переводит сигналы в человеческий язык.

Не все должны расти …пост вдохновлён книгой Radical Candor. Из каждого утюга вещают про успешный успех: телеграмм-каналы и подкасты про буст карьеры, 10-кратный рост и авторские курсы — сейчас основной поток контента. Ну правильно, а иначе зачем мы здесь все собрались? Не деградировать же, как в твиттере. Расти, конечно! Non progredi est regredi. Не будешь расти — уволят и обязательно умрешь от голода под мостом. (мой вольный перевод) Но сегодня хочу написать непопулярный пост, и пусть меня закидают помидорами. Знакомьтесь: сеньор Дима — 20 лет в профессии, последние 10 — в текущей компании — Не ведёт блог, не выступает на конференциях, не продаёт курсы — Просто работает работу. Стабильно и качественно. Не быстро и не медленно, средне. Но на него всегда можно положиться. — Никогда не ноет. Вокруг него не возникает конфликтов. — Не приходит с запросом х2 зп. Ему норм. — Работает не больше 8 часов. Иногда справляется с задачами за 4 часа и тогда может больше времени провести с семьей. Об этом все знают и всех всё устраивает. Дима — не топ-перформер и не Rock Star Назовём его Rock-Solid 🗿 Rock Star vs Rock-Solid Rock Star 🌟 — Хочет новых задач, технологий и челленджей — Готов работать много и напряжённо — Хочет быстрого карьерного роста — Получает от текущего места всё что может за 1-2-3 года и уходит искать новые вызовы Rock-Solid 🗿 — Глубоко знает свою работу и технологии — Стабильно выдаёт предсказуемый результат — Не гонится за хайпом и модой — Работает долго (5–10+ лет) Проблема в том, что компании часто не понимают ценности Rock-Solid сотрудников. Их начинают сравнивать с молодыми и амбициозными, забывая, что стабильность и надежность — это тоже огромная ценность. Многие даже осознанно «нанимают только звёзд», тем самым загоняя себя в ловушку. Когда в команде 8 человек, и 7 из них — Rock-star с запросом на постоянный рост — это беда. Через полгода половина разбежится. Потому что невозможно всем одновременно дать челленджевые задачи и карьерный рост. ——— ⚠️ Почему мы недооцениваем Rock-Solid? 1. Культ роста в IT. Все хотят нанимать только «амбициозных» и «с горящими глазами». 2. Недостаточная видимость. Rock Star — всегда на виду. Рефакторинг всего легаси, презентации новой архитектуры, внедрение новых технологий. Rock-Solid тихо чинит прод, фиксит баги, онбордит новичков. Его ценность становится очевидной только тогда, когда он уходит. 3. Неправильные метрики. Performance Review обычно поощряет тех, кто делает задачи выше своего грейда. А где метрика «стабильно держит критичный сервис уже 5 лет»? Где награда за то, что благодаря его экспертизе мы избежали 10 архитектурных ошибок? 4. Единственный карьерный трек: Junior -> Middle -> Senior -> Manager. А что если человек не хочет становиться менеджером? Что делать руководителю? Концепция из Radical Candor: ваша задача — не заставить всех расти вверх, а помочь каждому двигаться по его траектории. Для Rock-Solid: — Признавайте их ценность публично — Создавайте возможности для менторства и обучения других — Платите справедливо за экспертизу, а не только за «потенциал» — Давайте интересные задачи в рамках их зоны комфорта Для Rock Star: — Обеспечивайте челленджи и новые проекты — Готовьте к следующей роли — Будьте готовы к их уходу через 2-3 года Идеальный баланс: — 20–30% Rock Star — 70–80% Rock-Solid Да-да, большая часть команды должна состоять из стабильных экспертов! Это контринтуитивно для индустрии, помешанной на «hiring only A-players». Итог Не все должны расти вверх. Не всем нужен рост и челлендж. Не все хотят быть тимлидами. И это нормально. Более того — это необходимо для здоровой команды. Если вы — руководитель и у вас есть свой оплот стабильности — позаботьтесь о нём, пока он с вами. Не забывайте поднять зарплату. Поинтересуйтесь, всё ли его устраивает в работе и можете ли чем-то помочь. Потому что найти нового Rock-Solid гораздо сложнее, чем Rock Star. А если вы — Rock Solid, — скиньте своему менеджеру этот пост. И не стесняйтесь своего выбора. Наша индустрия держится на таких, как вы.

Гибкость vs прогнозируемость Всегда хочется одновременно: — Быстро реагировать на изменения. — Чётко планировать спринты и попадать в срок. Но это взаимоисключающие настройки: 1. Подкручиваешь гибкость — снижается прогнозируемость, больше шанс что у сырой задачи что-то вскроется в процессе и сроки поедут. 2. Тюнишь прогнозируемость — добавляешь пункты в Definition of Ready и начинаешь сопротивляться непроработанным задачам. Когда-то давно у моей команды был максимально гибкий процесс: продакт приносил задачки прямо на планирование и мы весь понедельник с ними разобирались. С одной стороны, супер-гибко: пришла идея — сразу пошла в работу. С другой — неэффективно и без гарантий сроков: целый день улетал на то, чтобы договориться о деталях, но чаще всего цель спринта не успевали и доделывали в следующем. Как итог — накапливался снежный ком «доделок с прошлого спринта». Минимальная глубина прогрумленности бэклога Если задачи проработаны заранее, — планирование становится простым и быстрым. Для этого верхушка бэклога должна быть проработана и готова к взятию в работу. Но встает вопрос: верхушка — это сколько? Мы экспериментировали с разными вариантами и пришли к оптимальному значению — 2 спринта. Почему именно 2? Так у команды появляется запасной план на случай, если продакт вдруг решит отложить какую-то задачу или попросит больше времени на дополнительное дискавери. Больше — есть шанс, что время на проработку будет потрачено впустую, а задачи никогда не пойдут в работу. Меньше — есть риск потратить весь день на планирование, если проработанные задачи попросят поставить на паузу. Как измеряем 2 спринта 1. Берём задачи, проработанные не позднее 90 дней назад. Если задача более старая — скорее всего, что-то уже поменялось и её надо заново прорабатывать. 2. Считаем медианное velocity команды за последние 3 месяца. 3. Делим сумму оценок готовых задач на медианное velocity. ——— В итоге, можно сказать что наш ползунок «гибкость <—> прогнозируемость» стоит где-то посередине. Что не идеально — в итоге гибкость ограничена по сути выбором из двух наборов задач. А прогнозируемость гарантируем в пределах двух спринтов. Но это не хорошо и не плохо — это наш выбор. А у вас как?