HowTo: Оцениваем проекты эффективно
 Публичный пост
1 июня 2020     3396   

Сколько раз вы оценивали проекты или задачи и не попадали в оценки? Наверное много. За 9 лет управления проектами мне встретилось настолько мало инженеров, менеджеров и команд, чьи оценки бы совпадали с реальностью хотя бы в половине случаев, что хоть пост пиши.

Давайте разбираться почему так происходит и что делать. Пост не только про оценки, он про жизнь и боль. Осторожно, многабукаф.

UPD:

Disclamer: этот пост для случаев, когда оценки все же нужны. В комментариях развилась шикарная дискуссия про no-estimates и приоритеты, и все правда. Однако в этом тексте давайте считать что приоритеты уже понятны и оценки в каком-то виде нужны.

Disclamer 2: оценка в виде S/M/L или "до апреля успеем", а так же "от 2 до 6 недель", это тоже оценки и они нужны в определенных случаях.

Disclamer 3: процесс оценки и все это ваше планирование точно занимают время. А еще уходит время на уточнение и постановку приоритетов. Об этом мы тоже немного поговорим, но приоритеты и их необходимость - out of scope этого поста.

The why

Здесь должна быть картинка для привлечения внимания, но ее не будет.

В масштабе фич

Во-первых, человек - существо в целом оптимистичное и настроенное на результат. Вот пришел менеджер к условному Васе-разработчику и просит оценить задачу. Вася хочет быстро разделаться с задачей и пойти чаи / в теннис гонять. Или хочет показать какой он быстрый. Или надеется что он достаточно умный чтобы ррраз и запилить фичу. Или правда думает что "да там делов-то". И не раковыривая задачу на составляющие, говорит сакральное "два дня". Если наш Вася не зануда, он не станет вникать в детали оценки пока не начнет собственно пилить. Даже на грумминге инженеры не всегда включают мозги чтобы правда понять а что делать-то надо. Более senior инженер скорее скажет что ему надо подумать и покумекать с коллегами, да вернется с оценкой позже. Но мы-то знаем что инженер обычно оценивает только свой кусок работы, а Definition Of Done для фичи это куча всего сверху.

Все, пути назад нет, два дня значит два дня и снова надо рвать пятую точку. А еще Вася может забояться поменять оценку чтобы не выглядеть глупеньким.

В масштабе команды

Часто при оценке задачи мы не видим всего масштаба трагедии. Еще раз, инженеры склоняются к оценке только своего куска работ. И под работами я понимаю поковырять систему, подумать и написать код. Может быть покрыть его unit-тестами и пофиксить что там принесет code-review. А функциональное тестирование, UAT, релиз, багофикс и прочие уточнения часто остаются за кадром. Я молчу про зависимости на другие команды, про них и тимлиды не всегда вспоминают.

Наконец, система оценок одного человека часто не равна системе координат в команде или голове менеджера. Если не прояснить на берегу, то условные "два дня" для разработчика выглядят как "найду два дня с перерывами на другие задачи и чай может быть на следующей неделе", а для менеджера оно звучит как "через два дня фича будет в проде". Да, местами все настолько плохо.

В масштабе управления менеджерами

Менеджер редко честно знает сколько займет конкретная фича, он опирается на команду. А ему вон Вася сказал что угадает эту ноту за два дня, забыв про все остальные звенья цепочки. Наш менеджер может быть даже сходит к тестировщикам за оценкой. Иногда он достаточно опытен чтобы накинуть некий % запаса сверху чтобы не обосраться перед заказчиком. В некоторых случаях он даже способен сказать что фича / проект будет готов тогда-то, но есть риски А, Б и Ц, что означает возможные задержки. Но это скорее исключения, к сожалению.

Представьте что вы - заказчик. Или программный менеджер, которому нужно знать только когда будет готова функциональность. Тут у нас новая проблема: scrum-master или проектный менеджер редко понимает фичу достаточно хорошо чтобы учесть все шаги за пределами собственно разработки. А еще он почти наверняка боится сказать нет Его Величеству заказчику. И включает такой же оптимизм, как и условный Вася четыре параграфа назад. "Ну мы же успееем..."

В итоге заказчик давит, менеджер обещает что все скоро будет в лучшем виде, команда оптимистична чтобы заделиверить, в оценки никто не попал и мы снова в жопе.

На выходе имеем

Менеджер прибегает 100500 раз с вопросами "ну когда будет готово" -> инженер нервничает и начинает тихо ненавидеть менеджера.

Менеджер видит что наш условный Вася не попадает в оценки или не успевает в им же поставленные сроки -> Менеджер больше не доверяет Васе, а это может иметь последствия для карьеры последнего. Если непопадание случилось в противоположную сторону и команде/Васе пол спринта нечего делать, это тоже проблема.

Команда не может заделиверить вовремя примерно ничего -> недовольный заказчик, демотивированная команда, люди валят.

Менеджер добавляет к оценкам команды пресловутое Пи-пополам или какая там у него поправка на ветер для этой команды. Правильное слово для этой техники - contigency (запас). Про него ниже. Однако часто эта поправка - пальцем в воздух чтобы дать команде времени немного выдохнуть. Из-за отсутствия логики за сценой, во взгляде снаружи команда все равно не попадает в оценки.

И что делать?

Напрямую с исполнителем:

  1. Даже как глупенький менеджер, я задаю инженерам вопрос Расскажи как понял задачу, что нужно получить в итоге? И слушаю насколько ответ похож на реальность. Если я в роли аналитика, я буду докапываться чтобы бедняга-программист понял все требования и с ними согласился. Или пойду доделывать требования.

  2. Второй вопрос с подвохом: Расскажи как будешь делать задачу? Первые три шага. Я хочу понять насколько человек понимает как он будет решать проблему, мне примерно все равно что именно он говорит. Мне нужна уверенность в словах.

  3. Договориться когда я (менеджер) приду за промежуточным результатом или статусом. Чтобы инженер знал что к четвергу мне нужно что-то будет сказать, так ему проще со мной работать и мне не нужно бегать с микроменеджментом каждый день.

С командой

  1. Не планировать больше 80% доступного capacity на инженера и не больше 60% на лида. Потому что митинги и всякая незапланированная НЕХ точно сожрут кучу времени. Чем больше у человека коммуникаций, тем больше для него НЕХ. Если планировать 100%, вы не успеете никогда unless инженеры всегда добавляют запас к своим оценкам.

  2. Planning pocker. Это правда работает! Но работает только для равнозаменяемых членов команды. То есть если у вас один дизайнер, один тестировщик, один FE и один BE, то вам не поможет. Смысл покера в том чтобы сравнить оценки на одну задачу и понять кто не понимает систему больше, а в конце договориться о процессе запиливания фичи.

  3. Grooming meetings один раз на спринт, в середине. Если команда большая и качество требований низкое, тогда два раза в спринт. Не в начале потому что вы все забудете к следующему спринту. Не в конце потому что еще нужно же какое-то discovery сделать по мотивам встречи. Смысл грумминга - убедиться что все одинаково хорошо понимают что в задачах прописаны требования, их можно брать и пилить. И понятно как пилить, да. Не забудьте разбить фичу на понятные подзадачи размером не больше половины дня работы.

  4. Тип задачи: spike. Это ограниченная во времени задача на исследование чего угодно. Заложили два-три дня, рассказали что нарыли и ура. Чтобы не тратить хз сколько времени и быть способным прогнозировать загрузку команды чуточку лучше. Хорошо работает если на грумминге понять что так просто слона не завалить, сделать спайк на два дня, а потом на планнинге или следующем грумминге разобрать что получилось.

В срезе проекта целиком

  1. Contigency для целого проекта / фичи. Это может быть + 20 процентов или даже +50, в зависимости от степени неопределенности и рисков. Чем больше высоковероятных и высокоимпактных рисков определено, тем выше ваш запас. Для суровых fixed-price проектов на галерах contigency может быть и 100%, особенно если требования оставляют желать. Важно этот ваш запас коммуницировать как минимум в команду и в сторону account manager. Но еще важнее убедить команду что запас != подвинуть сроки.

  2. Перед подписыванием в сроках кровью убедиться что собраны все оценки, со всех команд, учтено тестирование, UAT, интеграция, live tests если есть, документация, зависимости на сторонние системы. И коммуницировать например как "Разработка и тестирование займут два месяца при условии что assumption 1, assumption 2. В худшем случае будет не два месяца, а 4 потому что. Интеграцию и релизы в оценки не включили, нужно немного больше времени."

То есть описываем что именно вкладывается в оценку, а что нет. И проговариваем что может повлиять на оценку. Не забываем рассказать о предположениях по пути.

В идеале конечно на каждый проект у вас есть WBS (work breakdown structure), critical path и вот вся эта ПМская теория на практике. Но так бывает не везде.

Не только про оценки

Кроме собственно оценок и промахивания в них, у менеджера или тимлида много времени уходит чтобы убедить человека / команду вообще делать задачу. Если разобраться в причинах оттормаживания, станет проще деливерить фичи быстрее, а микроклимат в коллективе станет чуточку менее токсичным.

Человек может вас динамить с задачей потому что:
а) Не знает систему достаточно хорошо. Убедитесь что человек понимает в каких частях системы нужны изменения, что нужно затронуть и как протестировать.
б) Не понимает задачу в полном объеме. Простой вопрос "Понял? - да/нет" не работает, нужно разбирать подробнее. Иначе вы получите результат ну совсем не в том виде что надо. В идеале стоит проговорить с исполнителем в какой форме вы ждете outcomes. Особенно актуально для не-разработки.
в) Не хочет делать вашу задачу или не видит в ней смысла. Я столько раз видела как одну мелкую фигню не делают месяцами, что уже даже не больно. Если вы менеджер, продавайте команде задачу! Аргумент что так сказал заказчик работает в основном на галерах и то не долго.
г) Не может. Нет времени. Убедитесь что нагрузка работяги соответствует норме. Ему может быть даже в кайф фигачить с утра и до забора, но выгорание никто не отменял. А еще есть такая штука как приоритеты. Если кроме вас у него очередь из страждущих, нужно бороться с очередью, а не больно тыкать вилкой.
д) Не умеет. Не все и не всегда готовы открыто сказать что они не знают как выполнить задачу. Проверяйте что исполнитель достаточно опытен для отдельно выбранной задачи.

Техника оценок

Не человекочасами едиными! Проблема с человеко-попугаями в том, что люди почти всегда в момент оценки считают чистое, а не календарное время. Перекуры, согласования и прочее проходят как бы мимо и это стоит учитывать. Однако с высоты оценки целого проекта, такая методика понятна примерно всем. С другой стороны, это самая неточная техника оценки.

Story point. Еще одна святая корова в мире разработки и проектного менеджмента. Самое сложное - понять и принять что story point не имеет никакого отношения ко времени. Это сложность задачи в сравнении с другими задачами. И его нельзя определить в нулевом спринте. Возьмите за образец одну простую законченнную задачу и приложите к ней оцениваемые. А все остальные объяснения я оставлю не к ночи помянутым Agile-коучам. Оценка будет более точной, но проблема возникает когда нужно объяснить оценку заказчику или сравнить/просуммировать оценки нескольких команд. А оценить проект для галеры чтобы прописать в контракт, это уже за гранью простого и сложного unless вы прописываете эти самые сторипоинты.

T-shirt sizes Отличный способ оценить быстро. Или оценить в неопытной команде. Просто примеряем S-M-L-XL и все. Кстати, хорошо работает как помощь в первичной приоритезации внутри роадмапа. Проблемы начинаются когда нужно относительно точно напихить задачи в спринт. Придется считать поизводительность (velocity) в тех же единицах, а это очень не точно.

PERT Пожалуй самый хороший способ оценки, когда нужно попасть как можно точнее. Можно немного упростить и остановиться на Оптимистично+Реалистично+Пессимистично и так пойти к заказчику. В идеале же посчитать (O + 4Р + П)/6. Или можно усложнить, добавив standart deviation (П-О)/6. Минус: оба варианта требуют некоторого скилла у всех участников событий.

UPD: куда-то я потеряла оценки в ranges, они же самые удобные! Можно оценить, что задача займет от 1 до 3х недель, даже без углубления в Оптимистично-пессимистично-реалистично, хотя с некоторой стороны это одно и то же.

Confidence per date или насколько мы уверены к определенной дате - мой самый любимый способ для борьбы с исторически недовольными заказчиками. Команда оценивает любым удобным способом, а затем мы начинаем разговор "будет ли готово на проде к 1 мартября? - 60% что да, а про 20 мартября мы уверены на 98%." Важно опросить всю команду и принести заказчику где-то две даты, не все 10. Важно! Этот способ оценки перекрывает весь индивидуальный оптимизм, как менеджерский, так и отдельного Васи. Только вам придется ближе к датам проверять и уточнять оценки, а еще точно нужно держать заказчика в курсе событий чаще обычного. Иначе он будет нервным из-за неопределенности.

DoD & DoR

В некоторых командах Definition Of Ready / Done для девелоперов и тестировщиков отличаются, в некоторых это только одно Готово на выходе из команды. Как ни внедряй, смысл упражнения в определении:

  • Что такое готово быть принятым в разработку / тестирование?
  • Что такое готово с точки зрения разработки / тестирования / заказчика?

DoD & DoR лечат бесконечные возвраты задач на предыдущие шаги вашей пищевой цепочки. И снимают недовольство тестировщиков разработкой, а разработчиков - аналитиками или дизайнерами. Но более важно что когда вы одинаково понимаете как должен выглядеть выхлоп в глазах заказчика, он будет более доволен вашими результатами. Управление ожиданиями никто не отменял.

Оба два не постоянны! Они меняются с развитием команды и должны пересматриваться хотя бы раз в полгода. Ну и с заказчиком договоритесь что такое Готово, иначе смысла почти нет.

Зачем это все?

Получился весьма водянистый пост, увы. Я хотела написать только про техники оценок, но тут Остапа понесло. Потому что нельзя просто взять и оценить проект, тут думать надо.

P.S.: Кажется у нас появляется подобие проектно-менеджерского коммьюнити. Пишите мне если есть желание иметь больше таких философских постов на около-менеджерскую тему и пишите сами. У меня есть ряд идей похожих постов, но я не уверена что формат / подача ок.

Интересно почитать в комментариях насколько ваша реальность отличается от моей.

Связанные посты
36 комментариев 👇
Egor Biriukov, Engware Softineer 1 июня 2020

Опишу свое отношение к эстимейтам с позиции инженера.

Cred: работал в восьми командах (не компаниях) с разными процессами над разными проектами.
Anti-cred: я не менеджер, не претендую на объективность. Просто хочется выразить свое мнение "по ту сторону клавиатуры".

На всякий случай: обращение на "ты" обезличенно, все описанное ниже мое мнение основанное на моем опыте.

  1. Эстимейтить хоть сколько сложные задачи в сложных системах невозможно с приемлимой точностью. Если тебе кажется, что возможно, на мой взгляд, ты ошибаешься либо в оценке сложности задачи, либо в эстимейте. Как CAP-теорема, только про менеджмент.
  2. Эстимейты это easy, а не simple и даже right. "Просто" сказать "10 SP/две недели/L", сложно понять почему 10 SP, что на эти две недели влияет, какие факторы делают M -> L, как из 10 SP сделать 1 SP * 10. Я видел много первого, не видел ни разу второго. Возможно, где-то умеют второе.
  3. Процесс эстимейта ВНЕЗАПНО отнимает время: грумминг, планнинг, покер-планнинг, ретро -- все это время, когда никто не работает, целая команда сидит и оценивает задачи. Это звучит очевидно, но это мало кто на самом деле понимает: пока мы говорим, станки простаивают, а могли бы работать. Если посчитать затраты времени на эстимейтинг, получится, что это немалый процент времени команды, которое можно было бы потратить на непосредственно разработку и шипнуть продукт быстрее.
  4. Чем точнее эстимейт, тем с бОльшей вероятностью это цифра в воздух. Эстимейты футболками работают неплохо, эстимейты часами не работают вообще (см. пункт 1).
  5. Самое важное: когда твой менеджер спрашивает тебя об эстимейтах, попытайся понять, зачем ему это знание? Допустим, есть задача, по твоим оценкам реализация займет месяц. Постарайся узнать, что будет, если задача будет сделана через два? А через три? Если нет никакой разницы -- эстимейт не нужен. Если разница есть, значит эстимейт, вполне возможно, поставили до тебя и вопрос "сколько это займет?" на самом деле попытка тебя под этот "внешний" эстимейт подвести. Важно: если ты не знаешь, сколько займет задача, твоя обязанность, как инженера, сказать "не знаю", а не выдумывать большие цифры.
  6. Попытайся понять, что вы эстимейтите: скорость команды для анализа эффективности или подписываете контракт с клиентом. Первое достаточно безобидно (но, на мой взгляд, управление ограничением (по Голдратту) это работа менеджера, а не тебя, и происходить это должно без твоего участия). Второе, на мой взгляд, причина многих проблем с техдолгом/паникой/недовольствие и должно решаться другими способами.
  7. Есть задачи, эстимейтить которые просто и точно: добавить страницу на основе существующей, написать документацию, сделать маленькую, хорошо декомпозированную задачу без unknown unknowns. На мой взгляд, если эстимейтить просто, значит эстимейтить не нужно, быстрее сесть и сделать.

Хорошо, а что нужно делать?

  1. Оценивать не время, а сложность. Еще раз: не время (нет, SP это неявное время), а сложность. Максимально абстрактно.
  2. Декомпозировать задачи, сложность для которых зашкаливает и не пускать их в работу.
  3. Анализировать сложность: почему каждая задача в подсистеме X оценивается как "очень сложно"? Что мы можем с этим сделать, давайте посмотрим на техдолг?
  4. Следить за WIP стэком на команду/разработчика, учитывая сложность задач. См. теорию ограничений: https://www.leanproduction.com/theory-of-constraints.html
  5. Работать, а не эстимейтить.

В общем, всем #NoEstimates.

UPD: ссылочки на почитать/посмотреть, кому интересно:

  1. http://kyleprifogle.com/dear-startup/
  2. https://weekly-geekly.github.io/articles/459312/index.html

Спасибо за картину с другой стороны клавиатуры! Вы в целом говорите ровно то же что и в тексте. Особенно относительно SP и митингов.

Я не соглашусь про no-estimate, но я менеджер, у меня свои заморочки.

  Развернуть 1 комментарий

@Covectb_cobaka, что мне, как разработчику, говорить менеджеру, когда я не знаю, сколько займет задача кроме как "не знаю"? Но знаю , что в ней куча unknown unknowns пресловутых?

  Развернуть 1 комментарий

@dkol, что нужно больше времени на дискавери. Например, чтобы менеджер вернулся через три дня. И отметить что задача выглядит как M-size, например, но это не точно. Спросить когда нужна оценка и почему тогда. Спросить насколько подробная нужна оценка - часто M-size / один спринт достаточно чтобы менеджер убежал. Попросить с кем-то сконтачить если нужно, или пнуть аналитика. Менеджер почти наверняка любит помогать упрощать жизнь. Помогло?

  Развернуть 1 комментарий

@Covectb_cobaka, да, спасибо!

  Развернуть 1 комментарий

@dkol, есть даже тип задачи - spike, где результатом (артефактом) должен быть break-down другой задачи и попытка ее естимейта.

  Развернуть 1 комментарий

@hackman, не знал, спасибо. только я искренне не понимаю, как все эти эстимейты и спайки приносят деньги бизнесу, по виду это наоборот, отвлекает от решения самих задач?

  Развернуть 1 комментарий

@dkol, в самом деле, тот же скрам добавляет довольно большой оверхед на работу: по моим наблюдениям, в лучшем случае, порядка 20-30% времени уходит на митинги, груминг, планирование, ревью, демо, ретро. Да еще и программистов постоянно выдирают из потока: добавляем оверхед на переключение контекста.

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

  Развернуть 1 комментарий

@Covectb_cobaka, "что нужно больше времени на дискавери". – Я конечно с технической стороны смотрю на жизнь и преверженец #no-esimates, но я прекрасно понимаю, что всем хочется составлять роадмап, подсчитать бюджет etc... Проблема в том, что "делать дискавери" может занять добрую треть времени, если задача не совсем прикладная и очевидная. А если эстимировать всё подряд и планировать, можно убить кучу времени на планирование, эстимейты и общение с командой. Поэтому, наверное и вправду лучше эстимировать сложность в поинтах, а не сроки.

  Развернуть 1 комментарий

@dkol, со спайком вы будете меньше времени пилить задачу или быстрее откажетесь от самой идеи этой задачи.

  Развернуть 1 комментарий

@hackman, Подпишусь под каждым словом!

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N, чтобы здесь не болело, для этого нужно сначала выяснить когда нужна оценка и насколько подробно. Иногда стоит ставить отдельную задачу на дискавери, например если у вас проект месяцев так на 9.

Поинты прикольны в масштабе команды, но не всегда работают в контексте крупных программ.

  Развернуть 1 комментарий

@Covectb_cobaka, Да, я это понимаю. Поэтому стараюсь сторониться от продуктов, где больше ~30 разработчиков и чёткое планирование с детальными роадмапами. Это хоть и предсказуемо и позволяет управлять процессом, но куча времени тратится на планинг покеры, скрам ритуалы, спайки, ретроспективы и иногда срезаются углы слишком сильно.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N,

но куча времени тратится на планинг покеры, скрам ритуалы, спайки, ретроспективы и иногда срезаются углы слишком сильно.

Печальная правда жизни :)

Иногда это можно полечить "микросервисным подходом" к разработке: команды меньше и, соответственно, их горизонты планирования яснее.

Но это, конечно, не для всех проектов подходит.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N, мне внезапно стало интересно как на это влияет размер команды.
То есть как бы реально кто-то делает там "планинг покер" или стендап на 30+ человек?
В моей вселенной более 10-12 человек - неуправляемая орава. :)

  Развернуть 1 комментарий

@dj_kill, Количество человек влияет на культуру компании и прцоессы. Когда в компании много команд –заводятся общие порядки и процессы. Т.е в компании, где 150-200 человек, даже внутри комнды уже совсем другая атмосфера, чем когда над проектом работают, скажем 4 команды и всего мксимум 50 человек в компании и средне управляемый хаос.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N, Количество человек очень опосредованно влияет на порядки и процессы.
Ну и команда в 50 человек просто не может существовать.
То есть как бы более 10-15 человек в прямом управлении не работает.
То есть команда в 50 человек - это 5 разных команд внутри которых задачи пилятся независимо и между ними обмен только по in/out

Но я бы посмотрел на людей где одна команда в 50 человек что-то пилит. Это должно быть забавно. :)

  Развернуть 1 комментарий

@dj_kill, Ну я и не говорил, что в одной команде 50 человек. Я больше про то, что все друг друга хорошо знают и решают вопросы между собой напрямую. И есть видимость того, кто что делает и у тебя полное понимание что вообще происходит и процессы более легковесны и просты.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N, Чем больше людей, тем больше коммуникаций. У меня как-то была команда из 35 человек со стендапами по часу. Первое что я пушила сделать, это распилить команду на части. Жить всем стало легче, но появились новые проблемы. Например, что лидов нужно было сильно тренировать чтобы они смогли в коммуникацию с другими командами. Но это другая история.

  Развернуть 1 комментарий

@gwgjga6dQ4Wnve1N, 35 человек решающие вопросы друг с другом напрямую и полное понимание что они делают у одного лида?
Элон Маск, перелогинься. :)

  Развернуть 1 комментарий

@dj_kill, Дело не в лидах или в ком-то ещё, я ничего про лидов не говорил. Когда я могу посмотреть что делают сейчас другие по комитам или в джире и с кем я могу пересечься и куда все движется – это очень помогает. И когда я могу обратитсья к кому угодно минуя лидов или кого-то ещё напрямую и спросить что мне нужно, с кем-то скооперирвоатсья над чем-то – это очень помогает. Когда нет практики, что каждый изолирован от других людей и от других команд и рабтает только в изолированой кодовой базе.

  Развернуть 1 комментарий
Захар Кириллов, Амбассадор ЕРАМ в Клубе 1 июня 2020

Оооо, какая тема! У меня два камаза кирпичей по ней. Разгружу полкамаза для начала.

Я из тех менеджеров, которые топят за #noestimates. Команда работает гораздо продуктивнее, веселее и качественнее, если нет давления эстимейтов.

Заказчика стараюсь образовывать и обрабатывать в таком ключе:

  • выдай-ка нам очередность выкатывания фич, сиречь — расставь приоритеты;
  • если какие-то фичи привязаны к календарю — расскажи о них суперподробно (что именно и почему, а что будет если дата настанет, а фичи нет на проде? кто определил эту дату и почему именно её?)
  • для каждой фичи напиши самый главный приёмочный критерий, который кровь из носу должен быть (им может быть некий happy path) на момент готовности;
  • для крупных фич (epic / capability) — снабди нас граничными условиями, техническими ограничениями, полиси, нормативами, нефункциональными требованиями, которые должны быть выполненыны, чтобы никто не обосрался и не получил по башке.

Всё! Я осмелюсь дать зуб без кариеса, что этого набора достаточно, чтобы организовать джаст-ин-тайм-деливери, при условии, что проектом будет заниматься "здоровая" (всмысле, которая не больна различными оргнедугами) сбалансированная (то есть в ней есть и джуны, и сениоры по своим направлениями) команда специалистов. Причём они не должны быть рок-звёздами-единорогами.

Сами же фичи поддаются оценке только по кажущейся сложности одна относительно другой, а более-менее реальную оценку может дать только конкретный специалист, когда посвятит фиче хотя бы 1 продуктивный рабочий день.

Самый кайф в том, когда без давления сроков разработчики предлагают 5 отличных способов сделать фичу — тогда начинается самое увлекательное обсуждение того, насколько детально фичу есть смысл прорабатывать, как именно её делать (говнокод на бойлерплейте или TDD парное программирование), есть ли смысл попилотировать на фиче новые компоненты, подходя, технологии и т.п., что делает нашу работу интересной и осмысленной.

Одна беда у меня с этим: к такому подходу можно прийти поработав с заказчиком где-то с годик, чтобы он проникся доверием к команде и смог "отпустить вожжи" и начать говорить с командой честно.

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

Таких историй у меня вагон. Цимес их — ни заказчику, ни команде не нужны эстимейты. Команде нужна спокойная интересная работа, а заказчику — достижение KPI.

Красиво рассказываете! Уточнения по прриоритетам и откуда растут даты это важно, без вопросов. С некоторыми фичами получается no-estimates, но не в каждой среде это возможно. Потому что mindset двигается не за один день. А если у вас программа из 6 продуктов с минимум пятью проектами на продукт, то тут без оценок сложно. ну, хотя бы без примерных. Однако круто что где-то возможно иначе.

  Развернуть 1 комментарий

@Covectb_cobaka, а вот это интересно как раз — как программе из 30+ проектов и 6 продуктов помогают все эти эстимейты, сделанные по разным методикам разными людьми?

Мой опыт в больших программах был несколько однобок, потому что там драйвером был дедлайн вступления в силу закона MIFID-2, так что всем 20+ проектам (уж не знаю сколько было продуктов) приходилось планировать от конечной даты и впихивать невпихуемое в этот таймлайн.

Так вот, там тоже пытались что-то проэстимейтить, но чем выше по иерархии передаются эстмейты, тем больше они обрастают contigency, оверхедом и прочим обвесом. Более того, менеджеры верхнего уровня вообще мало заинтересованы во вникании в эстимейты.

Если на низах эстимейтят в условных попугаях, то к верхнему уровню попугаи превращаются в лучшем случае в кварталы-полугодия. В нашем случае были "триместры" и все эстимейты от девелоперов пройдя скрам-мастера, продукт-овнера и програм-менеджера в конечном итоге на самом верхнем уровне, после устаканивания зависимостей попадали в 3 ведра: "весной", "летом" и "осенью". После чего менеджеры спускали решение вниз командам: "фичу Х нужно зарелизить осенью". "Ну осенью так осенью" — отвечали разработчики в марте и шли пилить свои 13 сторипоинтов.

  Развернуть 1 комментарий

@zahhar, в предложенной вами структуре я где-то недалеко от "верхушки". Да, все так, но!

Начинается проблема яйца и курицы, а именно понять когда заказчику надо и постараться впихнуть туда или услышать когда хотят и договориться когда можем после некоторого discovery, но не вдаваясь в подробности.

В моем мире проблема "летом" и тд лечится через верхнеуровневое планирование с горизонтом больше чем (хотя бы) один квартал. Если бизнес понимает что и когда нужно + почему оно нужно именно летом / в Q3 / H2/ сентябре, то зная это заранее, команды могут начать ленивое discovery хоть бы и за полгода. Тогда становится понятен размер в тех же футболках. Чуть ближе к датам появляется техническое решение и более подробная оценка. В таком случае цвет попугаев оценок внутри команд уже не волнует, наружу требуется только дата / разброс дат / уверенность в дату. Ну или в месяц. Чем ближе к датам и глубже в код, тем более точной становится оцунка.

Я не прошу оценивать все проекты на полгода вперед в человеко-часах или любых других попугаях, кроме понимания насколько страшна задача. Часто оно происходит волнами: мы четко знаем все сабтаски и нюансы на месяц или фазу / гейт вперед, знаем фичи на квартал и понимаем направление на полгода вперед.

Если оценка, даже high level, не вписывается в хотелки заказчика, начинаем торги: двигаем что-то другое, сокращаем scope, делаем фазы, ну и тд.

Так что с какой-то стороны это жизнь без оценок. Потому что олдскульный waterfall с подробной оценкой проекта на два года с внесением в контракт это прошлый век и не работает даже на галерах.

Наверное мне стоило написать в начале поста что здесь я пишу в основном про боль работы с командой в разрезе деливери небольшого increment. Потому что когда доходит до оценки куска в месяц-два, после всех раундов discovery и выяснения требований в течение предыдущих трех месяцев, команды часто не могут оценить по-человечески. В итоге в перспективе программы эти относительно небольшие куски начинают не спеша съезжать почти всегда, unless добавлять поправки на ветер больше чем ожидается.

Anyway, спасибо за ваши подробные комментарии. Это ровно то обсуждение, которого хочется когда приходят в голову идеи таких постов. Очень интересно а как оно в голове у других.

  Развернуть 1 комментарий
Galina Ryzhenko, Head of Product 2 июня 2020

Спасибо - полезная статья, закину коллегам-проджектам идею про PERT.

С продуктовой колокольни добавлю про T-shirt sizing: мы используем этот подход для оценки как effort, так и impact. На выходе получается матрица приоритизации, которая служит хорошей стартовой точкой для разговора "а что нам взять в ближайшую итерацию - Штуку А или Штуку Б?"

Effort:

Impact:

Таблички не мои, их автор (если правильно помню) - VP Product из Elsevier.

  Развернуть 1 комментарий

Спасибо! Это достаточно стандартная практика для продуктовых чуваков. В этом месте оценки команды на high level очень помогают в приоритезации. Было бы круто почитать текст про боли с оценками со стороны продактов ;)

  Развернуть 1 комментарий
Nika Tamaio Flores, Head of Consulting 3 июня 2020

Очень и очень хочется больше подобных постов!

В частности интересует оценка совсем новых задач, которые команда еще не решала.
Я работаю с разными аналитическими проектами в сферическом вакууме (доставка – ноутбук с кодом) или с интеграциями (от middleware до оболочки алгоритмов в виде сайта или апки).
Раз в неделю примерно поступают задачи, которые мы с командой не решали никогда. Иногда не решали даже отдаленно похожих. Соответственно, надо как-то понять, сколько времени и денег решение таких задачек будет стоить, сможем ли мы вложиться в ограничения и так далее.

Сейчас мы запускаем для таких задач отдельное дискавери, где разбираем по косточкам все, что касается задачи и областей вокруг неё. Это приводит нас к ряду документов, которые описывают различные требования и особенности задачи.
Постепенно складываются разные форматы документов, которые помогают потом задачу оценить. Интуитивно это все работает, но может, есть какие-то форматы и методологии для оценки новых задач, которые вы пробовали и можете сказать, что они помогают лучше.
Буду оочень рада, если пост о чем-то таком появится :)

  Развернуть 1 комментарий
Anna, Программист 3 июня 2020

У нас в компании раньше оценки с потолка давались почти без подготовки, но требований к высокой точности и не было. Были авралы раз в полгода зато. Потом появились требования к относительной точности сроков и желание авралов избежать. В рамках своей группы мы начали строить скрам. Скоро уже год будет, как мы работаем в рамках этого фреймворка, что очень недолго на самом деле. Но результаты уже есть.

Конечно, нельзя просто взять и сказать "А теперь мы скрам". Это ничего не поменяет. Пришлось бороться с концептуальными проблемами, которые приводили к неудачной оценке задач.

Текущая концепция у нас вырабатывалась долго и мучительно, и у нее все еще есть недостатки, но крупных авралов у нас больше не бывает и оценки мы даем в среднем корректные.

Спринты у нас двухнедельные и фокус фактор мы считаем на 8/10 дней спринта. Два оставшихся дня мы считаем выпадающими и потраченными на всякие собрания и другие полезные вещи. В эти же два дня группа должна подготовиться к будущему спринту (что на самом деле мало кто делает, но в какой-то мере это работает). Если все очень хорошо, то можно заниматься любыми задачами из техдолга по своему желанию.

Оценка задач дается коллективно на планировании, но никакого скрам покера у нас нет. Мы считаем, что к непонятным задачам должны быть готовы минимум два человека из группы, иначе оценка может получиться не слишком адекватной. Непонятные задачи - это такие, оценка которых не очевидна сразу, т.е. не типовая. Если задачу за два дня оценить не удается (какой-то сложный клиентский дамп с утечкой памяти), она оценивается в 3SP. В среднем все непонятные задачи у нас делаются за такой срок.

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

Вот еще полезная ссылочка по теме:
https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning-fallacy

  Развернуть 1 комментарий
Andrey Kucherov, Руковожу проектным офисом 1 июня 2020

Со своей колокольни: при выполнении EPC (Engineering, Procurement, Construction) контрактов оценку длительности работ делать приходится как минимум дважды. Первый раз - это про деньги, потому еще до заключения контракта мы должны заявить свою цену - или в технико-экономическом обосновании, или в тендерной заявке, или на переговорах. Чаще всего тут посчитать помогает экселевский шаблон Cost Time Resourse (CTR) документа. Опытный менеджер, склонный к умеренному пессимизму, да в знакомой теме вряд ли тут ошибётся больше чем на 20 процентов. Помочь с оценкой могут: фактические табеля подобных уже выполненных проектов, мнение коллег-менеджеров и сенсеев-инженеров. Наибольшие риски - это неучтенные внешние факторы вроде особо свирепых требований по технике безопасности на сайтах, сокращающие фактическое эффективное рабочее время чуть ли не вдвое, или необходимость дополнительной экспертизы проектной документации во внешней организации до старта работ. До перехода на CTR, как ни странно, не самым плохим способом показал себя кондовый «стоимость работ как процент от стоимости оборудования и материалов». В проекте средней сложности - это 15-20 процентов.
Второй момент - график выполнения работ, подписывается и выдаётся клиенту или вместе с контрактом, или сразу после подписания контракта. Тут уже только про сроки. Клиента интересуют фазы контракта и ограничивающие фазы контрольные точки - гейты. Скорее всего, гейтами будет окончание проектирования, закуп и поставка оборудования, проведение factory acceptance test, монтаж и пуско-наладка на сайте, проведение site acceptance test и сдача в эксплуатацию. У каждого гейта есть вход - скорее всего, результат предыдущей фазы и выход, оформленный в виде какого-то документа -реестра проведённый через документ-контрол DCC документации, накладной на поставку оборудования, протокола тестирования системы и пр. Собственно, оценка продолжительности тут идёт уже в формулировке «сколько необходимо нам потратить ресурсов на этой фазе, чтобы попасть в гейт». Даже если этих ресурсов потребуется больше, чем было предусмотрено при предконтрактной оценке - надо делать работу, разбираться уже после. Справедливости ради, попадались клиенты, которые ради сохранения экосистемы своих подрядчиков давали делать «работу над ошибками» и выслушивали потом обоснования на повышение стоимости контракта, был шанс получить дополнительное финансирование, если удавалось доказать, что в объеме работ произошли объективные изменения, которые мы не могли учесть при подаче предложения.

В небольших проектах график и отчёт выполнения может делаться в виде эксель таблиц. В средних или больших- MS Project/Oracle Primavera отчетов, которые в исходных форматах файлов плановым отделом клиента вместе с отчетами других подрядчиков сливается потом в один гигантский файл с зависимостями и критическими путями. И упаси господи, если на критическом пути станет наш график и именно он будет тянуть общий график «вправо», на опоздания.

  Развернуть 1 комментарий

Спасибо! То что ты пишешь очень хорошо ложится на процесс деливери на галерах, почти один к одному.

  Развернуть 1 комментарий

Касательно Contigency для целого проекта / фичи. Это может быть + 20 процентов или даже +50, в зависимости от степени неопределенности и рисков.: Здесь вот лежит гайд по расчету коэффициентов коррекции на Optimism Bias, пробовал с ними тоже играться. На development максимально можно выйта на +200 процентов по затратам и +54 по срокам.

  Развернуть 1 комментарий
Alexander Babenko, Либертарианец, блогер, архитектор ПО 5 июня 2020

Каждый раз, когда начинается давление эстимэйтами, я начинаю объяснять про когнитивный баг людей - ошибка планирования. Сами люди склонны переоценивать свои способности и легкость задачи.

Особо отбитые манагеры не спрашивают, а спускают сроки, думая, что они все знают и могут сами все рассчитывать (типичное "гладко было на бумаге, да забыли про авраги").

В целом после этих лекций можно делить людей на неадекватов, от которых лучше сваливать, и на тех, кто способен осознать.

А так уже все верно сказали:

  • приоретизация
  • конкретизация требований (что из тасков действительно нужно срочно)
  • декомпозиция

Вообще, важно дать понять, что никто не будет к назначенным срокам рвать жопу бесконечно долго. Даже если человек в целом лоялен и готов напрячься ради "светлого будущего", то он выгорит от переработок за несколько дней и станет овощем. Руководителю нужно понимать, что есть некий ограниченный ресурс и это даже не 8 часов рабочего времени - на деле средний человек без пачки порошков будет способен прямо работать и концентрировать внимание на чем-то сложном порой менее 4 часов. Даже если он будет овертаймить, то из себя он не выдавит пользы сильно больше

  Развернуть 1 комментарий

Дописала в начале поста что описываю ситуацию, когда оценка все же нужна. А отбитые манагеры с дедлайнами сверху вниз это фу, да.

  Развернуть 1 комментарий
Roman Kononov, Site Lead/ Engineering Leader 3 июня 2020

У нас OKR на уровне организаций и департаментов и Scrum с футболками/стори поинтами в командах (в тех что я знаю) но в целом есть релизы в проектах и некоторые активити с жесткими дедлайнами а так в основном метрики и Objectives (я в феврале на конфе рассказывал как оно работает в деталях)

  Развернуть 1 комментарий
Dmitriy Rozhkov, Engneering Manager 3 июня 2020

Спасибо за пост!

  Развернуть 1 комментарий
Maksim Brigadirenko, разработка неповоротливой бизнес системы 9 июня 2020

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб