Всегда горят сроки: что мешает работать по плану

Ни один IT-проект не обходится без увеличения сроков и бюджета, если в него добавляются все новые и новые функции. Придерживаться плана выходит далеко не всегда, и это не обязательно плохо. Рассказываем, что помогает нам в InfoShell не терять голову на проектах и держать их в рамках.

Мастера продакт-менеджмента вряд ли прочтут что-то новое, а вот новичкам будет полезно узнать довольно очевидные, но все-таки необходимые вещи.

Помимо очевидного разговора о функционале и миссии проекта это принесет ощутимую пользу в предотвращении конфликтов. В общении с заказчиком есть 2 крайности:

ПЕРВАЯ
Заказчик не вовлечен в разработку.
Она уже идет полным ходом, все фичи согласованы, прототипы заходят «на ура», и мы уже готовы встречать довольного клиента, как вдруг выясняется, что это все не то. Нужно все переделать, все заново обговорить, имелось в виду совсем не то, что получилось. Занавес.
Помимо переработок, раздутого бюджета и конфликтов, мы получаем демотивированных сотрудников, с которыми нам предстоит переделывать проект.

ВТОРАЯ
Заказчик контролирует каждый шаг команды.
В этом случае все члены команды вместо работы над продуктом усиленно работают над отчетностью, уделяют рабочие часы созвонам. Чаще всего это проблема не налаженной коммуникации. Заказчик сомневается в вашей профессиональной компетентности? Сомневается в том, что вы правильно его поняли? Предупреждайте такие мнения ДО начала проекта. Позднее, поверьте, не получится.

Итак, до начала разработки обязательно:

а) обговариваем видение проекта;
б) предлагаем свои варианты решения;
в) детально(насколько это возможно) обговариваем функционал;
г) обговариваем сроки и возможные риски;
д) рассказываем, как лучше всего строить коммуникацию и отчетность. И корректируем по усмотрению заказчика.

Фундамент заложен, но расслабляться нельзя – ещё больше возможностей провалить сроки ждет нас во время проекта. Если команда работает по Scrum, она может менять функционал продукта прямо по ходу разработки, если продукт от этого изменения станет лучше или этого требует заказчик. Это здорово, но влечет за собой ряд неприятностей. Например, трудно контролировать расширение объема задач. Поэтому каждый спринт мы перераспределяем задачи и корректируем процесс. Но это не работает, если мы не можем оценить загруженность и эффективность каждого члена команды.

В команде должен быть показатель продвижения проектного процесса, который исчерпывающе отвечал бы на 4 вопроса:

а) какие задачи предстоит выполнить?
б) на каком этапе разработки находится конкретная задача?
в) кто занимается выполнением этой задачи?
г) сколько времени потрачено на выполнение задачи?

Нам с этим помогает доска спринта.

Доска — основной показатель продвижения проектного процесса и прекрасно работает, когда нужно отследить:

a) личную эффективность разработчика/менеджера/тестировщика;
б) загруженность члена команды, чтобы при необходимости перестроить процесс.

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

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

Сотрудники обсуждают X и считают, что обо всем договорились (нет) => X пускается в работу => X наполовину готов => закрадывается подозрение, что что-то пошло не так => сотрудник тратит ещё некоторое время на то, чтобы убедиться, что что-то пошло не так => обращается к сотруднику из начала цепочки => сотрудники обсуждают X и считают, что обо всем договорились. Хорошо, если на этом этапе X наконец пойдет в разработку. Плохо, если цепочка станет циклом. Такие ситуации не происходят часто, но единичные случаи сильно бьют по разработке и их достаточно.

Поэтому нетрудно вывести общие правила для всех, кто разрабатывает IT-продукт:

а) будьте ответственны за то, что вы делаете. Осмысляйте свою работу.
б) понимайте, почему эта фича важна в проекте. Как можно её улучшить? В чем она плоха?
в) если что-то в проекте непонятно, вызывает вопросы, требует улучшения — это должно быть озвучено.
г) если вам есть, что предложить — делайте это. Не думайте, что проактивность в разработке тормозит проект. Что его тормозит наверняка, так это незаинтересованная команда.

Кто-то ушел в отпуск, работа backend тормозит работу разработчиков, идет борьба со сторонними сервисами. Не планируйте жизнь в вакууме, посмотрите на проект сверху и задайтесь вопросом: «Где могут возникнуть проблемы?». Уделите больше внимания тем частям проекта, в которых все зависит не только от вашей команды.

Например:

Burn up chart – диаграмма, которая наглядно показывает, сколько осталось сделать до конца спринта. И если изменяем скоуп задач, конец проекта на графике сдвигается. С помощью burn up мы прогнозируем, ставим гипотезы, выбираем лучший путь.

Но так как burn up ориентирован на среднюю производительность команды, он не всегда показывает правду. Количество выполненных задач на этапах разработки разнится. Поэтому существует инструмент, который помогает отслеживать текущую эффективность.

Velocity – показывает, как быстро мы «съедаем» объем задач и какой объем работ осталось выполнить. Вычисляется как КПД. Нужно выбрать метрику трудозатрат (рабочие часы на проекте/задачи и т.д.) и разделить количество эффективных часов на проекте на количество рабочих часов. Подробный пример разобран в статье «Налаживаем процессы в продуктовой команде». Наглядность происходящего делает его регулируемым. Мы не ориентируемся на среднюю прогнозируемую эффективность, а регулируем эффективность относительно проекта.

В конце проекта проведите встречу, чтобы обсудить не конечный продукт, а работу команды над продуктом. Суть в том, чтобы подтолкнуть всех членов команды (в том числе и себя самого) к анализу собственной работы, на который у нас никогда не хватает времени. Пусть каждый из членов команды ответит на 4 вопроса:

1) Как я участвовал в проекте? Не какие были у меня обязанности, а что я сделал по факту.
2) Какие у меня возникали проблемы?
3) С чем у меня были трудности? Удалось с ними справиться или нет?
4) Что бы я улучшил в своей работе?

Рефлексия в первую очередь должна проводиться для каждого участника команды, а не для техлида или менеджера. На ней не должно быть никакого осуждения и привычного «разбора полетов». Не пренебрегайте рефлексией.
Итак, краткое summary о том, как держать проект в рамках:

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

Мы разрешаем отодвинуть сроки:

а) когда это происходит из-за требований заказчика по расширению функционала;
б) когда это сделает проект лучше;

Если ни одна из вышеприведенных мер не решает ваших проблем (убедитесь наверняка), тогда…

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

Не нужно бояться факта изменения проекта. Не бейтесь головой о стену из-за того, что что-то идет не по плану. Тратьте время на прогнозирование и поиск лучшего подхода. Опережайте проблемы, предлагайте пути развития проекта, а не ждите, пока проект сам сообщит вам, что нужно что-то менять. Воспринимайте изменения в плане как возможность, а сдвиг дедлайна — как необходимую меру. Удачи в работе!