Портал №1 по управлению цифровыми
и информационными технологиями

Есть ли польза от оценок трудозатрат разработчиков для самих разработчиков?

Мы знаем, что заказчикам и заинтересованным сторонам проекта нужны оценки по срокам реализации задач. На их основании они строят планы, расставляют приоритеты и планируют даты поставки разрабатываемых продуктов. А что для разработчиков? Для них отдача совсем не очевидна. Да и в целом может показаться, что и пользы-то никакой нет, ведь оценки используются зачастую “против” разработчиков, поскольку интерпретируются и воспринимаются стейкхолдерами именно как обещания.

Вполне естественно, что разработчикам без особого удовольствия дают оценки, ведь они могут повлечь неприятности. Однако, оценки могут принести однозначную пользу командам разработки – фактически, со временем они могут повысить статус команд разработки среди всех заинтересованных сторон и дать больше возможностей и веса на встречах и обсуждениях, считает Майк Кон (Mike Kohn), рассуждая на эту тему в своей заметке. Как же этого добиться?

Давайте взглянем на текущую практику. Что происходит, когда разработчик дал верную оценку и уложился с задачей в срок? Ему полагаются какие-либо бонусы, награды? Объявляется ли по этому случаю праздник? Может, пробки в потолок? Да нет же. Просто выполнил данное обещание. Никто и думать не думал придавать этому событию какое-то особое значение.

А вот если не уложился… Здесь-то и начинаются неприятности. Стейкхолдеры явно указывают на нарушение сроков, злятся, грозятся, кричат, требуют объяснений. Этот печальный опыт остался с Майком на всю жизнь.

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

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

Вполне ожидаемо, что это не сработало. Члены команды вскоре быстро поняли, что заниженные оценки приводят к негативным для них последствиям: им приходилось работать сверхурочно, “срезать” углы, чтобы уложиться в срок. И, чтобы избежать этого, они начали формировать оценки с запасом, чтобы темп работы был не таким напряжённым и изматывающим. В свою очередь, такое поведение вызывало внутреннее напряжение и диссонанс, поскольку было нечестным по отношению к заказчикам. Нужен был другой подход.

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

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

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

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

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

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

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

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

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;