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

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

Поделиться:
Кирилл Каплин
CEO
Время чтения статьи: ~ 3 минуты
30.09.2022
Процесс разработки — не всегда простое и предсказуемое дело. Часто мы прорабатываем все негативные сценарии развития и делаем оценку и анализ рисков по всем фронтам, рисуем диаграммы Ганта, планируем, выполняем другие шаманские ритуалы и приносим жертвы Богам разработки, чтобы получить заветный срок окончания и обзавестись запасами подушек безопасности.
Но не всегда это идет по запланированному сценарию: человеческий фактор внутри команды сыграл свою злую шутку, настроение у заказчика поменялось и он решил изменить половину концепта проекта, да и вообще осень за окном наступила. Скоуп факторов такого рода в праве влиять на сроки и поставленные планы.

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

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

Как понять PM — прямая инструкция

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

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

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

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

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

Чем это поможет разработчику?

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

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

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

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

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

Цель оценки

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

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

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

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

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

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

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

Делаем выводы

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

Читайте также

Инструменты, примеры и преимущества применения мобильного маркетинга для привлечения новых клиентов
Мобильный маркетинг: как приложение поможет привлечь и удержать клиентов?
Читать
Тимур Кубинев
Digital-маркетолог
Тимур Кубинев Digital-маркетолог
Когда компания приходит к тому, что ей нужно мобильное приложение, выбор подрядчика становится отдельным испытанием. Делимся критериями выбора качественного исполнителя
Как выбрать студию для разработки мобильного приложения
Читать
Замрат Аджиев
Руководитель направления продаж
Замрат Аджиев Руководитель направления продаж
Наш опыт создания дизайн-системы на примере «Заступника». А еще о том, как дизайн-система упрощает работу не только дизайнерам, но и разработчикам, тестировщикам и аналитикам
Зачем мы разработали дизайн-систему?
Читать
Дмитрий Евдокимов
Lead UI/UX
Дмитрий Евдокимов Lead UI/UX