Comments 36
В оценке трудозатрат есть одна м-а-аленькая проблемка. Они становятся понятны только после выполнения задачи. Всё остальное - гадательное с разной степенью достоверности. Но раз вы просите, ваши сотрудники же не дураки. Они сначала закладывают х3-x10 а потом тянут до последнего, потому что неверная оценка создает проблемы. А, ну скорее всего у вас есть один-два "дурачка" которые оценивают супер-оптимистично а потом не вылезают с работы до ночи и пролюбливают сроки. Такие везде есть. В результате все счастливы. Люблю хэппи энды.
Да, конечно, оценка трудозатрат - материя сложная. Особенно, если с ней не работать.
Кейс, когда разработчики перезакладываются, это показатель недоверия между руководителем и специалистами и боязнь наказания.
Мое понимание оценки времени, которое я транслирую команде:
Мы не делаем культ из оценок, но стремимся к реалистичному значению. Как в случае математического предела переменная неограниченно приближается к какому-то постоянному значению
Оценка не пересматривается только при неизменности вводных данных, на основании которых она была сделана.
Оценка КРИТИЧЕСКИ нужна для планирования и для работы с бизнесом.
Вы - правы: мои сотрудники - не дураки. Но мы экспериментировали с форматами встреч для оценок и этот вариант им зашел.
Жила-была компания Motorola, еще в стародавние времена когда она была американской. И работали в ней люди, которые очень любили оценивать трудозатраты. Год из году они работали над тем чтобы оценивать точно, но постоянно они промахивались. Но люди были упорные, проводили ретро, создавали списки причин которые могут повлиять на неточность оценок. Движ был нешуточный. А время шло.
Короче, через четыре года они на это плюнули. Но вы конечно можете повторить.
Пример с Motorola, это вывод на основе ограниченных данных. Что вы хотите этим сказать? Не нужно заниматься оценкой сроков вообще или вы за другой подход в этом?
Меня беспокоит в индустрии тотальное игнорирование мотивации разрабочика. Общий подход который я наблюдаю практически всюду - "Наградой за хорошо сделанную работу, является больше работы. Наказанием за плохо выполненную работу, является меньше работы."
Я понимаю ценность оценки сроков для РП. Но примеры из жизни показывают что проекты можно выполнять в три раза быстрее без потери качества по сравнению с медианным что сейчас есть в индустрии. Просто это никому не надо.
Я понимаю ваше беспокойство. Примеры, о которых вы рассказываете, к сожалению, имеют место в жизни.
И хорошо, что тем не менее вы разделяете: перегибы и ценность практики. Потому что любую самую лучшую практику/принцип/институт в абсолюте можно довести до маразма.
Согласитесь, бывают несчастные браки, но из этого не следует, что ВСЕ люди несчастны в браке.
Ценность Planning Poker - во всестороннем обсуждении задач перед оценкой. Поэтому странно звучит аргумент "Отвлечь ценных специалистов от работы". Это и есть их работа. В ходе которой в том числе растёт и их ценность.
imho статья в очередной раз демонстрирует столкновение культур - традиционной корпоративной (иерархия, планы со сроками, "учёт трудозатрат" и "утилизация ресурсов", вот это вот всё) и Agile (команда разработки все решения принимает сама, и менеджер ей не нужен).
груминг и покер планирование это 2 разных процесса
Расскажу про текущую ситуацию у меня. На груминг привлечены только высокоуровневые спецы которые имеют отношение к фичам, обсуждается планы и декомпозиция. На оценке все специалисты подразделения и там уже каждый рассказывает о назначенных ему задачах, что позволяет держать в курсе всего проекта всю команду и уменьшить количество дейликов для обсуждения проблем, так как если возникают вопросы то в основном на оценке. На мой взгляд так намного лучше чем заниматься оценкой не зная контекста или привлекать лишних людей на груминг который намного дольше оценки
Ценность Planning Poker - во всестороннем обсуждении задач перед оценкой. Поэтому странно звучит аргумент "Отвлечь ценных специалистов от работы".
Не все встречи одинаково полезны.
Как я подчеркивал в своей статье, каждая задача требует своего инструмента. Данный инструмент эффективен в решении задач, где предыдущие этапы выполнены специалистами качественно, и имеются четкие артефакты.
imho статья в очередной раз демонстрирует столкновение культур - традиционной корпоративной (иерархия, планы со сроками, "учёт трудозатрат" и "утилизация ресурсов", вот это вот всё) и Agile (команда разработки все решения принимает сама, и менеджер ей не нужен).
Я работал как в традиционной корпоративной среде, так и в творческой, современной Agile-компании. Крупные проекты - большие заказы от бизнеса, и для успешной работы необходимо умение оперировать в их системе координат
Чем большим количеством инструментов и подходов вы владеете, тем шире поле задач, которые можно решить. Полностью отрицать корпоративные методы, так же недальновидно, как отказываться от Agile. Все зависит от решаемой задачи.
Учитывается ли как-то тот факт, кто будет делать задачу? Сеньор сделает задачу быстрее, чем джун. Соответственно, его оценка будет ниже, а фактическое время зависит от того, кто будет исполнителем.
Да, безусловно влияет. И вот, что я делаю в этом случае: https://habr.com/ru/articles/789414/
Кажется лёгкой цифра "фактическое время". А насколько она точна? Как выцепить время потраченное именно на реализацию данной фичи на фоне параллельно реализуемых задач? Например, реализация фичи по (консолидированной) оценке должна была занять 40 часов. А сделали её через месяц. Сколько времени из этого месяца занимались именно данной фичей, чтобы можно было понять, попали в оценку или нет?
Очень хорошее замечание! Вы правы, люди всегда люди:
Люди могут иногда забывать отмечать свои действия.
Бывает, что они не всегда относятся к этому ответственно, заполняя некоторые данные точно, а другие оставляя на усмотрение памяти.
Не обойтись и без случаев, когда люди преукрашивают или преуменьшают свои достижения, чтобы создать определенное впечатление.
Фактическое время - не «священная корова». Я как руководитель могу повлиять на выстраивания необременительного процесса трекания времени. Необходимо находить баланс между требованиями к точности, которые могут оказывать давление на разработчиков, и приемлемыми отклонениями.
Мы не приветствуем переключения между задачами, потому что это драматически снижает эффективность. Но, к сожалению, и у нас такое бывает.
И как учитывать такой момент, что люди будут стараться попасть в установленный срок, даже неосознанно. Если заложили многовато то станут более тщательно тестировать, делать код "получше", если маловато - то торопиться, местами откровенно тяп-ляп. В результате получается подгонка решения под ответ - оценка сроков будет "точная", а качество продукта при этом очень сильно плавать. Тогда planning pocker нужно применять и далее - чтобы исполнители не знали, какой реально срок был назначен :).
Ваш пример про подгонку еще одно подтверждение «эффекта привязки» :)))
С моей точки зрения, важно донести до команды, что поиск новых ИТ-решений и дополнительные доработки для достижения целей проекта допустимы, однако, при этом недопустимо уходить в бесконечный цикл работ. То есть все дополнительные активности должны выполняться в рамках других отдельных задач. Подробнее тут: https://companies.rbc.ru/news/Q1vEYxbaGU/kak-ponyat-chem-zanyatyi-vashi-razrabotchiki-i-chto-proishodit-na-proekte/
А вы не пробовали взять да и отказаться от каких-либо оценок времени? Что толку гадать на кофейной гуще, если ошибка планирования есть и никуда не денется, так как эта ошибка свойственна любой человеческой особи? Особенно имеет место быть она в отношении оценок времени? Не лучше ли взять да и откалибровать сами работы на промежутки времени фиксированной величины? Например, 40, 60, 90, 120 мин? А сам объем работы сделать переменной величиной хоть в килограммах, хоть в функциональных точках, хоть в тех же сторипойнтах? ;) При условии, что работа выполняется 1 индивидуумом со 100%-й вовлеченностью ( нет параллельных работ )? :)
Можно просто разделить задачи на мгновены, лёгкие, средние, тяжёлые, адские. Каждой группе определить время. Мгновенные это очевидно разные правки конфигурации, исправление текста и прочее делаются условно за 0 минут и в планирование не учитываются вообще. Лёгкие это до 2ч, средние от 8 до 20ч, тяжёлые большее 40ч обязательно 8ч на исследование, адские время выполнения неизвестно.
Как можно видеть есть разрывы. Почему? Потому что в любой задаче могут быть подводные камни мы просто знаем что в среднем задача максимум займёт столько времени.
Я бы не стал применять величины размером более длительности 1 рабочего дня/смены. Во-первых, это прямой путь к незавершенке и последующим "перезапускам" (особенно после выходных, праздников) Во-вторых, это свидетельство недостаточной продуманности работы в деталях, т.е. плохого планирования и непонимания задачи. Что касается адских задач, как вы говорите, то у них тоже есть ограничение по времени выполнения. Например, срок завершения спринта или этапа проекта (или проекта в целом ). Или срок выхода работника за ворота (или на пенсию, или в последний путь), так? Вы ж не Саграда-Фамилья строите, верно? ;)
Не имеет срока означает что невозможно определить можно ли это вообще сделать и как это делать и вообще ничего непонятно или это лютый баг который не удаётся поймать и определить.
Как раз делать сроки строго в 1рд это обман. Ну не бывает так что все задачи уложаться в 1 день, часто такое начинает приводить к лишней декомпозиции где 1 логическая задача делится на несколько совершенно надумано.
Поправьте меня, если я не правильно вас понял.
Вы же сами предлагаете оценку времени. Т.е. ценность планирования вы все же признаете?
Планировать полезно. Но планирование деятельности не сводится к параметров, измеряемых временем. Планирование гораздо "ширее и глубжее". По большому счету сроки нужны прежде всего для того, чтобы синхронизировать работу составляющих производственной системы. И чтобы сихронизировать работу самой производственной системы с другими системами. Но не для того, чтобы заниматься гештальт-терапией, "мотивированием сотрудника" и прочих благоглупостей. Я всего лишь предложил откалибровать продолжительность работ под индивидуальные слоты времени исполнителей в их графиках рабочего времени :) И наполнять эти слоты большими, средними и малыми объемами с возможностью дробить работы опять же под фиксированные величины (или объединять более мелкие в крупные). И менять их порядок следования. Это называется выравниванием плана (чтобы потоки работ были равномерными). Улавливаете мысль, уважаемый коллега?
По большому счету сроки нужны прежде всего для того, чтобы синхронизировать работу составляющих производственной системы
Полностью согласен и рад, что здесь есть консенсус. При разработке зависимых микро-сервисов важно синхронно выкатывать функционал в прод. И, как вы правильно заметили, необходимо выравнивание загрузки.
Солидарен и с тем, что только время не должно быть единственным параметром при планировании.
чтобы заниматься гештальт-терапией, "мотивированием сотрудника" и прочих благоглупостей
Тоже согласен. Где-то здесь уже отвечал, что это плохой кейс, когда оценки времени становятся инструментом наказания.
Есть интересная книга "Чистый Agile". Рекомендую!
Качество оценки срока разработки для задачи, у среднестатистического разработчика, в среднестатистическом проекте, в среднестатистической компании, зависит от того, насколько хорошо было создано описание задачи, от полноты разъяснения всего что необходимо сделать и от понимания кода предметной области в коде проекта. В идеальных условиях эстимэйт точен, если менеджер лукавый и хочет заработать на разработчике лишний миллион - он сделает описание похуже, задачу даст разработчику который в этой части код видит впервые. В таком случае разработчик вероятнее всего ошибется в эстимэйте, а последствия зависят от корпоративной культуры...
Прокачать скил точного эстимэйт невозможно! Только точное, подробное описание задачи и знание кода даст возможность точного эстимэйта.
Подход оценки в абстрактных единицах сложности описанный в книге Чистый Агайл предполагает переход к планированию поставки фич проекта в прод спустя некоторое время необходимое для сбора статистики работы команды. Собрав статистику сколько стори поинтов команда делает за спринт, можно планировать достаточно точно, сколько команда сделает за месяц или квартал. И что стоит отметить, планирование в этом случае будет честным, без нагрева и без срыва сроков.
Каждый сам выбирает что лучше использовать...
Что касается использования гугл докс: намного проще для разработчиков запилить на условном PHP, веб страницу для индивидуальной оценки задач и формирование сводной таблицы за 2 дня и не париться с гугл доком.
По-моему, у вас самый обычный planning poker, просто вы поставили перегородочки между разработчиками, чтобы они не видели, какую карточку выбрал сосед. Главная ценность planning poker не в том, чтобы сиюминутно на выходе получить гладкие цифры, а в том, чтобы понять, какие есть точки роста у членов команды, чтобы в дальнейшем (да-да, не прямо сейчас) работать над подъемом уровня разработчиков.
«Однако в этот раз он не обладал всей информацией, в частности не знал, что для реализации новой фичи необходимы...» — это вообще сторукое лицо-рука, коммуникации в команде не выстроены совершенно, тут к planning poker’у еще рано переходить.
Коммуникация в команде — первична (и я не имею ввиду психологический климат в коллективе и прочий фэн-шуй, а самый натуралистичный риск спуска бюджета проекта в унитаз), красивый отчёт с циферками — глубоко вторичен.
По-моему, у вас самый обычный planning poker, просто вы поставили перегородочки между разработчиками, чтобы они не видели, какую карточку выбрал сосед.
Совершенно верно. С помощью данного конкретного инструмента я решал утилитарную задачу. Подходит ли он для всех кейсов разработки и для всех команд? Нет
это вообще сторукое лицо-рука, коммуникации в команде не выстроены совершенно, тут к planning poker’у еще рано переходить.
Большинство проблем в мире случаются из-за неэффективной коммуникации. Это данность, с которой каждый из нас работает.
Любопытен ваш опыт, какие у вас критерии перехода к planning poker?
Покер планирования и оценка не в часах, а в абстрактных единицах сложности, например, попугаях, не кратных, например, по Фибоначчи, придуман потому, что новую задачу невозможно оценить в часах и даже в днях: она новая, её никто не делал раньше, статистики нет для оценки.
Когда люди собираются вместе и начинают гадать, насколько сложно сделать нечто новое, то появляется хоть какая-то оценка: это и есть ценность обсуждений (люди думают, разговаривают и начинают понимать, что нужно сделать и как)
Спасибо большое за важное уточнение! Действительно, лучше использовать относительные, а не абсолютные оценки в случае новых задах с высоким уровнем неопределенности.
Описанный мною способ решает проблему агрегации оценок времени без эффекта привязки для задач с "ясным" описанием:
Будем считать, что информация, описанная в постановке, достаточна для корректной оценки времени. Вопрос про полноту входных данных оставим за рамками данной статьи.
Для знакомых задач можно поднимать статистику времени по аналогам - и давать разработчикам минимум, максимум и среднюю на вход для оценки.
Фактическое время выполнения учитывается только для этого, если разработчики в штате на зарплате, а не на почасовой оплате и не должны заказчику отчитываться о трудозатратах.
У вас так?
Если у всех оценки совпали, то есть вероятность, что кто-то один (одна) проставила оценки за всех - или первой, а другие скопировали. Или собрались посовещаться за кулисами и отправили согласованную оценку. Вероятность совпадения ряда независимых оценок у трёх человек почти нулевая.
Интересно, конечно, ИИ подключать к определению аналогов для сбора статистики по аналогам для оценки сроков и трудозатрат, но о таком я ничего запоминающегося не читала уровня "сделали, работает")
Для типовых задач уже наработана статистика времени, например создание простой синхронный CRUD REST API, добавление дополнительных атрибутов в существующий метод и т.д. Также смотрим Lead time для похожих фичей, чтобы примерно понимать, через сколько времени после старта работы команды Delivery фича окажется на прод-окружении.
Но таких задач не много, поэтому для большинства задач мы все же проводим оценку без оглядки на исторические данные.
Кейс, когда разработчики копируют друг у друга оценки умышленно, - это кейс взаимоотношения внутри коллектива и принципов, которые вы транслируете команде. Как бы это ни звучало пафосно, мы за честность.
С ИИ не баловались для сбора статистики.
P.S. позвольте рекомендовать мою другую статью про планирование сроков https://habr.com/ru/articles/789414/
Спасибо за статью и интересный взгляд. Одна из целей - устранить эффект привязки? Если так - planning poker решает эту проблему, участники выкладывают карты рубашкой вверх и когда все карты выложены, можно их вскрыть.
Можно перемешать карты и попросить каждого из участников задать вопрос к оценке, которую они считают отклоняющееся от их собственной и обосновать вопрос, после того, как все желающие зададут вопросы, последуют ответ владельца карты.
Способ с таблицей похож на компромисс между запросом экспертного мнения и покера, он сокращает коммуникацию, делегируя принятие решения об оценке в большей степени менеджеру. В то время как более эффективна оценка, которую дал исполнитель и согласился с ней, поскольку сохраняется мотивация оправдать правильность оценки, против подтверждения навязанной. Мне кажется важно учесть, что можно оценить то и правильно в самом начале задачу, а потом тупо забить или полениться, вопрос мотивации не самый последний.
Спасибо вам большое за подробный и обстоятельный комментарий
В то время как более эффективна оценка, которую дал исполнитель и согласился с ней, поскольку сохраняется мотивация оправдать правильность оценки, против подтверждения навязанной
Вы подсветили важный аспект, что оценка времени являются на самом деле обещанием разработчика выполнить работу. Можно сказать другими слова: приложить все усилия и уделить 100% внимания на применение своих навыков для решения поставленной задачи за отведенный срок.
И, естественно, обещание, которое получено добровольно, намного ценнее для выстраивание доверия внутри команды, чем навязанное сверху. Об этом я писал в этой статье: https://companies.rbc.ru/news/gJvDSCK7EE/kak-prohodit-etap-turbulentnosti-pri-postroenii-komandyi/
Как оценить задачи без Planning Poker и лишних слов