Боль PM или почему важно оценивать задачи

Процесс разработки — не всегда простое и предсказуемое дело. Часто мы прорабатываем все негативные сценарии развития и делаем оценку и анализ рисков по всем фронтам, рисуем диаграммы Ганта, планируем, выполняем другие шаманские ритуалы и приносим жертвы Богам разработки, чтобы получить заветный срок окончания и обзавестись запасами подушек безопасности.

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

Во главе команды разработки, как правило, стоят «они». «Они» — это PM. Те участники команды, которые постоянно пристают к разработчикам со своими языческими ритуалами: дейлики, контроль потраченного времени, остаток часов по задачам, прогресс спринта. Поэтому каждый разработчик сталкивался с неприятным моментом, когда к нему приходят «они» и спрашивают: «Ну что там? Когда будет готово?».

В ходе таких вопросов разработчики закатывают глаза для считывания информации с затылочной части, а попутно у них в голове возникает вопрос: «Опять?! Зачем им это нужно?». Так вот, если с этим разобраться и давать сходу ровно то, что требуется, процесс общего дела оптимизируется. Поэтому мы решили поделиться мнением нашего Lead PM, Светы Шишковой, об оценке задач и ограничению по треку времени.

Зачем?! Зачем PM задает один и тот же вопрос? Здесь есть несколько важных фактов:

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

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

• Выстраивание приоритетов при планировании следующего этапа работ. В этом случае важны оценки каждой задачи, потому что от них может зависеть последовательность работ. Как правило, PM может выстроить последовательность по методике «ценность vs сложность». Например, можно провести мозговые штурмы с заказчиком и командой, и оценить задачи по двум критериям: ценность для бизнеса и сложность выполнения. Обычно оценивают по трехбалльной шкале: высокая, средняя, низкая. После таких ритуалов удобно выстраивать приоритеты: сначала делаются очень ценные и очень быстрые, потом очень ценные и средне-быстрые и так далее. Малоценные и очень сложные задачи формируют вечный бэклог, откуда выбираются очень долго. Ну прям очень долго. Или никогда.

• Оценка проекта на стадии пресейла. Обычно с этим к PM пристают продажники,  ну, а те, в свою очередь, уже идут приставать к команде. На данном этапе оценка требуется примерная, так как редко есть какие-то четко сформулированные требования и никто на этом этапе не знает, что точно нужно сделать. После, на основании этих оценок, принимается решение, какие задачи оставить/убрать, какие отложить, как поделить работы на этапы, а самое главное — известен примерный бюджет и срок проекта. Плюсом идёт планирование работ (время, ресурсы, участники команды), построение диаграмм Ганта и прочая подобная деятельность.

Ну вроде зачем это «им», мы разобрали. А нужно ли это самим разработчикам? Представь себе, что твой менеджер ушел в отпуск. И, возможно, навсегда. И вот ты сидишь, спокойно работаешь, никто не спрашивает «Ну что там?», и ты даже скучать немного начинаешь, и так проходит день, два, неделю. Никто оценок не требует, жизнь удалась. Нужно ли в такой ситуации давать оценки самому себе?

Можно привести несколько аргументов «за»:

• Декомпозиция и оценка — воздух и вода разработчика. Человеческий мозг — штука затратная, и думать человек не любит — это сложно и больно. Поэтому естественное стремление — думать как можно меньше. А как это сделать? Для этого на помощь приходит декомпозиция и грамотная формулировка задач. Если составить план выполнения задачи, то можно считать, что декомпозиция успешно выполнена на 50%. Остается грамотно пункты плана озаглавить и оставить пометки для выполнения, чтобы не забыть, что ты там себе в прошлом на листочке накарябал. Если избегать таких действий, то может произойти следующее: задача сама по себе похожа на сложную (вроде изъян), а никто не позаботился о ее декомпозиции и грамотном описании, то обычно, в процессе разработки, меняется план выполнения задачи и меняются наши представления о ней. Из-за неопределенности она превращается в страшную кракозябру и делать ее никак не хочется. И даже смотреть на нее тоже. И вообще хочется куда-нибудь подальше убрать и больше никогда о ней не вспоминать. Через несколько таких подходов к работе в голову стучится эффект самозванца. Поэтому, декомпозиция и оценка = избежание головных болей и вздыхающего (нередко матерящегося), прикладывающего к своему лбу ладонь, PM’a.

• Контроль себя. Для выполнения задач лучше составлять план на день. Если это не делает для тебя PM (а, да, мы же его в отпуск отправили), то лучше это сделать самому. Ну для себя же, родимого. Если заметил, что вываливаешься из плана, и все идет по одному месту — это повод прекратить исполнение и сесть подумать. Таким образом ты сможешь себя контролировать, соответствует ли твое ожидание (оценка) реальности (попаданию в оценки) или реальность другая, и первоначальный план не подходит. Итог: оценка помогает анализировать работу и принимать решения, если в процессе что-то пошло не так.

• Непредсказуемость и потерянность в процессе. Если оценок нет — нет понимания о сложности задачи и нет возможности грамотно планировать свою работу. Без оценок единственное, на что мы можем ответить — в каком порядке будем делать задачи (и то это обычно через эники-беники и тыканье пальцем в монитор с закрытыми глазами). Непонятно, когда можно расслабиться, а когда, наоборот, следует сжать булочки. Из-за это возникает стресс, выгорание. А оно тебе надо?

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

Если задача новая и ты ранее её никогда не «щупал» (за телеса), бесполезно угадывать, сколько времени займет задача. Можно долго «тыкать пальцами в небо» и проводить другие ритуалы, чтобы явилась реальная оценка задачи — не получится достоверно её выявить, пока задача не будет сделана. Звучит как парадокс, но доля правды в этом есть.

Фух, добрались до важного! Оценка — это не попытка угадать, сколько займет задача. Оценка — это договоренность между заказчиком и исполнителем о рамках и  способе выполнения задачи.

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

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

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

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

Эти правила позволяют избежать перевес часов разработки за оценку задачи, без ведома PM’а. Тем самым, при подготовке отчетности и при сведении часов не будет каких-то неожиданных сюрпризов, разъяренного PM’а и хлопающего глазами разработчика.

Вообще PM не такой фееричный персонаж, который от нечего делать пристает ко всем с непонятными телодвижениями, вопросами и оценками. Очень надеюсь, что после прочтения стало чуть понятнее, зачем он это делает. Если есть понимание зоны ответственности и роли каждого человека в команде — наступает идиллия, любовь, dream team, и солнце за окном начинает светить. И радуга еще сразу появляется. Поэтому, когда любой участник команды поймет, что его оценки влияют на ВСЁ, что может быть связано с проектом, то наступит счастье для всех: планирование и процесс выполнения итераций будет приносить только удовольствие, PM будет признаваться вам в любви и осыпать комплиментами (по поводу того, какие у вас красивые и прямые руки), а заказчик платить миллионы за вашу работу.