Темная сторона стори поинтов

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

Мои друзья все как один сказали, что да, оценивают задачи – кто в стори поинтах, используя последовательность Фибоначчи, кто в часах, а кто в размерах футболок (S, M, L, XL). Но то, что они делают с этими оценками потом, меня удивило.

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

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

– Не совсем.

Если награждать программистов на поинты, они будут пусть даже бессознательно завышать оценку задач и выбирать задачи из соображений максимальные поинты за минимальное время. Более того, сам ПМ будет думать о поинтах вместо того, чтобы приносить пользу компании и клиентам. Желание заработать поинты приводит к тому, что команда выпускает фичу за фичей и не позволяет себе остановиться, сделать step back и задуматься, то ли они вообще делает и в чем цель.

Скептики возразят – решать, что делает команда и зачем, и расставлять приоритеты – это работа ПМа (а в особо тяжких случаях - CEO). Программисты должны внедрять то, что решит ПМ максимально быстро и без ошибок. Этому помогают поинты.

Так работают очень многие команды, но это ineffective (объясню акцент на этом слове чуть позже). Во-первых, команда на то и команда, чтобы искать решение вместе. А во-вторых, успешный ПМ – это не тот, кто генерирует гениальные идеи в вакууме и подгоняет программистов их воплощать. Толковый ПМ знает, что чем больше каждый человек вовлечен в процесс тем лучше результат. Поэтому, он четко коммуницирует команде проблемы клиентов и цели компании, держит на них фокус, как можно больше вовлекает всех в процесс поиска классных решений, помогает воплотить их в жизнь и раскрыть потенциал всей команды.

Если диалог в команде построен вокруг того, как решить проблему клиента максимально быстро и выгодно для компании – каждый программист, дизайнер и аналитик начинает об этом думать, используя свой профессиональный бекграунд и уникальный опыт. У всех возникают идеи, как этого достичь, в результате обсуждений генерируются еще лучшие идеи, люди чувствуют себя более мотивированными и команда выпускает правильные фичи быстрее.

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

Как и обещала, возвращаюсь к слову ineffective, которое употребила выше.

Попробую перевести эти термины на русский. Be efficient (эффективный, оптимальный) означает сделать что-то в минимальное время с минимальными затратами, а be effective (результативный) – это достичь желаемого результата. Например, efficient – это сделать так, чтобы один рабочий за 1 час крутил как можно больше гаек. А effective – это решить задачу, скажем, получить готовый агрегат не важно каким способом.

Так вот, сюрприз, на дворе 21 век! Мы больше не работаем на конвейере и не крутим гайки. Нам не надо быть efficient и оптимизировать количество однотипных операций. Мы решаем сложные интеллектуальные задачи, которые никто до нас не решал. Результат нашей работы – это не количество нарезанных болтов или написанных строчек кода, а то, как это решение влияет на пользовательский опыт и на бизнес. Достигли мы результата или нет, были мы effective или нет.

Поэтому, лучше считать, не сколько поинтов стоила фича, а сколько платящих клиентов она нам принесла.

Ну почему же? Оценивайте, пожалуйста, если это помогает планировать спринты и распределять задачи между программистами. Главное, не забывать – растет то, что меряешь. И если цель работы компании – это платящие клиенты, то успех надо оценивать именно ими, а не поинтами, количеством выпущенных фич или строчек кода.

На любую активность тратится время и силы. В сутках всего 24 часа, продуктивных из них часа 3-4 не больше. Поэтому лучше тратить это время на то, что действительно полезно для компании. Команда и ПМ либо считают поинты и отчитываются по ним высшему начальству, либо ищут, как привести больше клиентов и принести им пользу.

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

Чтобы оценить задачу, надо ее детально проговорить. Чтобы проговорить все задачи на спринт для команды в 10 человек, надо несколько часов. При этом, в обсуждении каждой задачи участвуют не все присутствующие, остальные – сидят и зевают. Время уходит впустую, в детали все равно не углубиться, оценки получаются далеки от реальности.

Еще в Nautal мы прошли через общий планнинг со скрам покером и поняли, что для нас этот подход не работает. В итоге пришли к небольшим груммингам или ворк-сессиям, в которых участвуют только те программисты, кто будет непосредственно разрабатывать фичу + ПМ + иногда tech lead. Подробно обсуждали задачу, прорабатывали сложные места и оценивали. После этого задача шла на доработку мелких деталей и приоритезировалась.

У нас нет отточенной годами четкой системы оценивания. Делали по-всякому. В последнее время стали снова оценивать в днях из расчета 1 день = 5 часов. Особо мелкие задачки или баги могут быть оценены в 1/2 дня или даже 1/5 дня.

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

Цель оценивания – прикинуть загрузку программистов и решить, входит задача в спринт или нет. Если видим, что времени на задачу надо много, а бизнес-выхлоп от нее по сравнению с другими инициативами незначительный, то отменяем ее или откладываем.

После планнинга эти оценки никуда не идут, скорость не меряем, за поинтами не гоняемся. Фокусируемся на квартальных OKR-ах и стратегических целях.

А вы оцениваете задачи? И что делаете с оценкой? Расскажите в комментариях.