Сколько раз вы оценивали проекты или задачи и не попадали в оценки? Наверное много. За 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 (запас). Про него ниже. Однако часто эта поправка - пальцем в воздух чтобы дать команде времени немного выдохнуть. Из-за отсутствия логики за сценой, во взгляде снаружи команда все равно не попадает в оценки.
И что делать?
Напрямую с исполнителем:
Даже как глупенький менеджер, я задаю инженерам вопрос Расскажи как понял задачу, что нужно получить в итоге? И слушаю насколько ответ похож на реальность. Если я в роли аналитика, я буду докапываться чтобы бедняга-программист понял все требования и с ними согласился. Или пойду доделывать требования.
Второй вопрос с подвохом: Расскажи как будешь делать задачу? Первые три шага. Я хочу понять насколько человек понимает как он будет решать проблему, мне примерно все равно что именно он говорит. Мне нужна уверенность в словах.
Договориться когда я (менеджер) приду за промежуточным результатом или статусом. Чтобы инженер знал что к четвергу мне нужно что-то будет сказать, так ему проще со мной работать и мне не нужно бегать с микроменеджментом каждый день.
С командой
Не планировать больше 80% доступного capacity на инженера и не больше 60% на лида. Потому что митинги и всякая незапланированная НЕХ точно сожрут кучу времени. Чем больше у человека коммуникаций, тем больше для него НЕХ. Если планировать 100%, вы не успеете никогда unless инженеры всегда добавляют запас к своим оценкам.
Planning pocker. Это правда работает! Но работает только для равнозаменяемых членов команды. То есть если у вас один дизайнер, один тестировщик, один FE и один BE, то вам не поможет. Смысл покера в том чтобы сравнить оценки на одну задачу и понять кто не понимает систему больше, а в конце договориться о процессе запиливания фичи.
Grooming meetings один раз на спринт, в середине. Если команда большая и качество требований низкое, тогда два раза в спринт. Не в начале потому что вы все забудете к следующему спринту. Не в конце потому что еще нужно же какое-то discovery сделать по мотивам встречи. Смысл грумминга - убедиться что все одинаково хорошо понимают что в задачах прописаны требования, их можно брать и пилить. И понятно как пилить, да. Не забудьте разбить фичу на понятные подзадачи размером не больше половины дня работы.
Тип задачи: spike. Это ограниченная во времени задача на исследование чего угодно. Заложили два-три дня, рассказали что нарыли и ура. Чтобы не тратить хз сколько времени и быть способным прогнозировать загрузку команды чуточку лучше. Хорошо работает если на грумминге понять что так просто слона не завалить, сделать спайк на два дня, а потом на планнинге или следующем грумминге разобрать что получилось.
В срезе проекта целиком
Contigency для целого проекта / фичи. Это может быть + 20 процентов или даже +50, в зависимости от степени неопределенности и рисков. Чем больше высоковероятных и высокоимпактных рисков определено, тем выше ваш запас. Для суровых fixed-price проектов на галерах contigency может быть и 100%, особенно если требования оставляют желать. Важно этот ваш запас коммуницировать как минимум в команду и в сторону account manager. Но еще важнее убедить команду что запас != подвинуть сроки.
Перед подписыванием в сроках кровью убедиться что собраны все оценки, со всех команд, учтено тестирование, 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.: Кажется у нас появляется подобие проектно-менеджерского коммьюнити. Пишите мне если есть желание иметь больше таких философских постов на около-менеджерскую тему и пишите сами. У меня есть ряд идей похожих постов, но я не уверена что формат / подача ок.
Интересно почитать в комментариях насколько ваша реальность отличается от моей.
Опишу свое отношение к эстимейтам с позиции инженера.
Cred: работал в восьми командах (не компаниях) с разными процессами над разными проектами.
Anti-cred: я не менеджер, не претендую на объективность. Просто хочется выразить свое мнение "по ту сторону клавиатуры".
На всякий случай: обращение на "ты" обезличенно, все описанное ниже мое мнение основанное на моем опыте.
Хорошо, а что нужно делать?
В общем, всем #NoEstimates.
UPD: ссылочки на почитать/посмотреть, кому интересно:
Оооо, какая тема! У меня два камаза кирпичей по ней. Разгружу полкамаза для начала.
Я из тех менеджеров, которые топят за #noestimates. Команда работает гораздо продуктивнее, веселее и качественнее, если нет давления эстимейтов.
Заказчика стараюсь образовывать и обрабатывать в таком ключе:
Всё! Я осмелюсь дать зуб без кариеса, что этого набора достаточно, чтобы организовать джаст-ин-тайм-деливери, при условии, что проектом будет заниматься "здоровая" (всмысле, которая не больна различными оргнедугами) сбалансированная (то есть в ней есть и джуны, и сениоры по своим направлениями) команда специалистов. Причём они не должны быть рок-звёздами-единорогами.
Сами же фичи поддаются оценке только по кажущейся сложности одна относительно другой, а более-менее реальную оценку может дать только конкретный специалист, когда посвятит фиче хотя бы 1 продуктивный рабочий день.
Самый кайф в том, когда без давления сроков разработчики предлагают 5 отличных способов сделать фичу — тогда начинается самое увлекательное обсуждение того, насколько детально фичу есть смысл прорабатывать, как именно её делать (говнокод на бойлерплейте или TDD парное программирование), есть ли смысл попилотировать на фиче новые компоненты, подходя, технологии и т.п., что делает нашу работу интересной и осмысленной.
Одна беда у меня с этим: к такому подходу можно прийти поработав с заказчиком где-то с годик, чтобы он проникся доверием к команде и смог "отпустить вожжи" и начать говорить с командой честно.
Тогда открываются феерический открытия: например, что киллер-фича нужна только в виде скриншота на проде, который поможет заказчику выиграть очередную интригу внутри организации, что сулит крутую должность и увеличение бюджета в его отдел. Потому фичу архиважно сделать суперкрасиво, но на беке будет дырка от бублика пока. И вообще сразу после демо фичу надо убрать за тоггл до лучших времен.
Таких историй у меня вагон. Цимес их — ни заказчику, ни команде не нужны эстимейты. Команде нужна спокойная интересная работа, а заказчику — достижение KPI.
Со своей колокольни: при выполнении EPC (Engineering, Procurement, Construction) контрактов оценку длительности работ делать приходится как минимум дважды. Первый раз - это про деньги, потому еще до заключения контракта мы должны заявить свою цену - или в технико-экономическом обосновании, или в тендерной заявке, или на переговорах. Чаще всего тут посчитать помогает экселевский шаблон Cost Time Resourse (CTR) документа. Опытный менеджер, склонный к умеренному пессимизму, да в знакомой теме вряд ли тут ошибётся больше чем на 20 процентов. Помочь с оценкой могут: фактические табеля подобных уже выполненных проектов, мнение коллег-менеджеров и сенсеев-инженеров. Наибольшие риски - это неучтенные внешние факторы вроде особо свирепых требований по технике безопасности на сайтах, сокращающие фактическое эффективное рабочее время чуть ли не вдвое, или необходимость дополнительной экспертизы проектной документации во внешней организации до старта работ. До перехода на CTR, как ни странно, не самым плохим способом показал себя кондовый «стоимость работ как процент от стоимости оборудования и материалов». В проекте средней сложности - это 15-20 процентов.
Второй момент - график выполнения работ, подписывается и выдаётся клиенту или вместе с контрактом, или сразу после подписания контракта. Тут уже только про сроки. Клиента интересуют фазы контракта и ограничивающие фазы контрольные точки - гейты. Скорее всего, гейтами будет окончание проектирования, закуп и поставка оборудования, проведение factory acceptance test, монтаж и пуско-наладка на сайте, проведение site acceptance test и сдача в эксплуатацию. У каждого гейта есть вход - скорее всего, результат предыдущей фазы и выход, оформленный в виде какого-то документа -реестра проведённый через документ-контрол DCC документации, накладной на поставку оборудования, протокола тестирования системы и пр. Собственно, оценка продолжительности тут идёт уже в формулировке «сколько необходимо нам потратить ресурсов на этой фазе, чтобы попасть в гейт». Даже если этих ресурсов потребуется больше, чем было предусмотрено при предконтрактной оценке - надо делать работу, разбираться уже после. Справедливости ради, попадались клиенты, которые ради сохранения экосистемы своих подрядчиков давали делать «работу над ошибками» и выслушивали потом обоснования на повышение стоимости контракта, был шанс получить дополнительное финансирование, если удавалось доказать, что в объеме работ произошли объективные изменения, которые мы не могли учесть при подаче предложения.
В небольших проектах график и отчёт выполнения может делаться в виде эксель таблиц. В средних или больших- MS Project/Oracle Primavera отчетов, которые в исходных форматах файлов плановым отделом клиента вместе с отчетами других подрядчиков сливается потом в один гигантский файл с зависимостями и критическими путями. И упаси господи, если на критическом пути станет наш график и именно он будет тянуть общий график «вправо», на опоздания.
Спасибо - полезная статья, закину коллегам-проджектам идею про PERT.
С продуктовой колокольни добавлю про T-shirt sizing: мы используем этот подход для оценки как effort, так и impact. На выходе получается матрица приоритизации, которая служит хорошей стартовой точкой для разговора "а что нам взять в ближайшую итерацию - Штуку А или Штуку Б?"
Effort:
Impact:
Таблички не мои, их автор (если правильно помню) - VP Product из Elsevier.
Очень и очень хочется больше подобных постов!
В частности интересует оценка совсем новых задач, которые команда еще не решала.
Я работаю с разными аналитическими проектами в сферическом вакууме (доставка – ноутбук с кодом) или с интеграциями (от middleware до оболочки алгоритмов в виде сайта или апки).
Раз в неделю примерно поступают задачи, которые мы с командой не решали никогда. Иногда не решали даже отдаленно похожих. Соответственно, надо как-то понять, сколько времени и денег решение таких задачек будет стоить, сможем ли мы вложиться в ограничения и так далее.
Сейчас мы запускаем для таких задач отдельное дискавери, где разбираем по косточкам все, что касается задачи и областей вокруг неё. Это приводит нас к ряду документов, которые описывают различные требования и особенности задачи.
Постепенно складываются разные форматы документов, которые помогают потом задачу оценить. Интуитивно это все работает, но может, есть какие-то форматы и методологии для оценки новых задач, которые вы пробовали и можете сказать, что они помогают лучше.
Буду оочень рада, если пост о чем-то таком появится :)
У нас в компании раньше оценки с потолка давались почти без подготовки, но требований к высокой точности и не было. Были авралы раз в полгода зато. Потом появились требования к относительной точности сроков и желание авралов избежать. В рамках своей группы мы начали строить скрам. Скоро уже год будет, как мы работаем в рамках этого фреймворка, что очень недолго на самом деле. Но результаты уже есть.
Конечно, нельзя просто взять и сказать "А теперь мы скрам". Это ничего не поменяет. Пришлось бороться с концептуальными проблемами, которые приводили к неудачной оценке задач.
Текущая концепция у нас вырабатывалась долго и мучительно, и у нее все еще есть недостатки, но крупных авралов у нас больше не бывает и оценки мы даем в среднем корректные.
Спринты у нас двухнедельные и фокус фактор мы считаем на 8/10 дней спринта. Два оставшихся дня мы считаем выпадающими и потраченными на всякие собрания и другие полезные вещи. В эти же два дня группа должна подготовиться к будущему спринту (что на самом деле мало кто делает, но в какой-то мере это работает). Если все очень хорошо, то можно заниматься любыми задачами из техдолга по своему желанию.
Оценка задач дается коллективно на планировании, но никакого скрам покера у нас нет. Мы считаем, что к непонятным задачам должны быть готовы минимум два человека из группы, иначе оценка может получиться не слишком адекватной. Непонятные задачи - это такие, оценка которых не очевидна сразу, т.е. не типовая. Если задачу за два дня оценить не удается (какой-то сложный клиентский дамп с утечкой памяти), она оценивается в 3SP. В среднем все непонятные задачи у нас делаются за такой срок.
Сейчас мы набираем задач на фокус-фактор 25-30% (это с учетом восьми дней на спринт). Полностью закрытые спринты все еще очень редки (где-то каждый пятый). Конечно, мы продолжаем ошибаться в оценках, но теперь ошибаемся в обе стороны и погрешность компенсируется.
Вот еще полезная ссылочка по теме:
https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning-fallacy
У нас OKR на уровне организаций и департаментов и Scrum с футболками/стори поинтами в командах (в тех что я знаю) но в целом есть релизы в проектах и некоторые активити с жесткими дедлайнами а так в основном метрики и Objectives (я в феврале на конфе рассказывал как оно работает в деталях)
Спасибо за пост!
Каждый раз, когда начинается давление эстимэйтами, я начинаю объяснять про когнитивный баг людей - ошибка планирования. Сами люди склонны переоценивать свои способности и легкость задачи.
Особо отбитые манагеры не спрашивают, а спускают сроки, думая, что они все знают и могут сами все рассчитывать (типичное "гладко было на бумаге, да забыли про авраги").
В целом после этих лекций можно делить людей на неадекватов, от которых лучше сваливать, и на тех, кто способен осознать.
А так уже все верно сказали:
Вообще, важно дать понять, что никто не будет к назначенным срокам рвать жопу бесконечно долго. Даже если человек в целом лоялен и готов напрячься ради "светлого будущего", то он выгорит от переработок за несколько дней и станет овощем. Руководителю нужно понимать, что есть некий ограниченный ресурс и это даже не 8 часов рабочего времени - на деле средний человек без пачки порошков будет способен прямо работать и концентрировать внимание на чем-то сложном порой менее 4 часов. Даже если он будет овертаймить, то из себя он не выдавит пользы сильно больше
😱 Комментарий удален его автором...