Мы знаем, что заказчикам и заинтересованным сторонам проекта нужны оценки по срокам реализации задач. На их основании они строят планы, расставляют приоритеты и планируют даты поставки разрабатываемых продуктов. А что для разработчиков? Для них отдача совсем не очевидна. Да и в целом может показаться, что и пользы-то никакой нет, ведь оценки используются зачастую “против” разработчиков, поскольку интерпретируются и воспринимаются стейкхолдерами именно как обещания.
Вполне естественно, что разработчикам без особого удовольствия дают оценки, ведь они могут повлечь неприятности. Однако, оценки могут принести однозначную пользу командам разработки – фактически, со временем они могут повысить статус команд разработки среди всех заинтересованных сторон и дать больше возможностей и веса на встречах и обсуждениях, считает Майк Кон (Mike Kohn), рассуждая на эту тему в своей заметке. Как же этого добиться?
Давайте взглянем на текущую практику. Что происходит, когда разработчик дал верную оценку и уложился с задачей в срок? Ему полагаются какие-либо бонусы, награды? Объявляется ли по этому случаю праздник? Может, пробки в потолок? Да нет же. Просто выполнил данное обещание. Никто и думать не думал придавать этому событию какое-то особое значение.
А вот если не уложился… Здесь-то и начинаются неприятности. Стейкхолдеры явно указывают на нарушение сроков, злятся, грозятся, кричат, требуют объяснений. Этот печальный опыт остался с Майком на всю жизнь.
Перейдя через какое-то время на менеджерскую позицию, Майк осознал, что привлекать членов команды разработки к ответственности за неверные оценки – не лучший выход. Более того – такой подход не работает.
Разработчики в его команде, как и сам Майк когда-то, были хроническими оптимистами и были склонны недооценивать время, необходимое для завершения задач. При этом Майк считал, что даже если команда при таких сверхоптимистичных оценках не уложится в срок, то всё равно будет близка к нему. И проекты будут выполнены в целом быстрее, чем закладывалось заказчиками, и они будут довольны.
Вполне ожидаемо, что это не сработало. Члены команды вскоре быстро поняли, что заниженные оценки приводят к негативным для них последствиям: им приходилось работать сверхурочно, “срезать” углы, чтобы уложиться в срок. И, чтобы избежать этого, они начали формировать оценки с запасом, чтобы темп работы был не таким напряжённым и изматывающим. В свою очередь, такое поведение вызывало внутреннее напряжение и диссонанс, поскольку было нечестным по отношению к заказчикам. Нужен был другой подход.
Нужно было добиться такого состояния и условий, считал Майк, что побудили бы команду разработчиков охотнее делать оценки, а не отмахиваться от них, как от назойливых и неприятных вещей. К тому времени Майк управлял уже несколькими командами. И он заметил разницу в восприятии команд заказчиками. Команды, которые давали более точные оценки в отношении задач проектов, имели и хорошие отношения со стейкхолдерами. Например, к таким командам разработки прислушивались, когда они заявляли, что уложиться в обозначенные сроки по задаче невозможно.
Представим себе две разные команды разработки. Пусть первая команда внутренне противится оценкам и, в целом, делает их неважно. У неё отсутствует история по оценкам, у неё плохая репутация среди стейкхолдеров из-за расхождений в оценках и фактических сроках. Поступает новая задача, руководитель обрисовывает в общих чертах набор функций и спрашивает команду, сколько времени займет разработка, намекая, что на самом деле всё нужно сделать за шесть месяцев.
Команда оценивает объём работы и приходит к выводу, что она займёт больше шести месяцев, что им нужно больше ресурсов, больше времени, или они могут уложиться за шесть месяцев с меньшей функциональностью. Но реализовать все требования за такой срок просто невозможно.
Какова вероятная реакция руководителя в подобной ситуации? Скорее всего он авторитарно решит сделать всё и за полгода, поскольку команда не обладает весом, чтобы к ней прислушивались, когда её члены говорят, что уложиться в такой срок невозможно. В этом случае руководитель будет склонен рассматривать сопротивление команды как нечто, что необходимо преодолеть, а не как мнение, подкреплённое фактами, т.е. историей успешных оценок команды.
Теперь рассмотрим подобную же ситуацию с другой командой. Да, она не идеальна с точки зрения даваемых оценок. Например, в одном из прошлых проектов разработчики оценили задачу со сроком сдачи в апреле или мае, а закончили незадолго до конца мая. По другому проекту оценили срок реализации в три месяца и выполнили точно в срок, но пришлось отложить в бэклог пару небольших фич по продукту.
Вторая команда тоже оценивает объём работы и приходит к такому же выводу, как и первая – за полгода всё реализовать не получится. По оценкам разработчиков им потребуется от восьми до девяти месяцев.
Как поступит руководитель в этом случае? Станет ли он “давить” на команду и заставлять уложиться в полгода? Нет. В прошлом эта команда предоставляла реалистичные оценки, поэтому руководитель внимательно прислушивается к тому, что разработчики говорят, что это невозможно. Как равные партнеры в решении общей проблемы, они начнут обсуждать, что делать, учитывая, что желаемый срок окончания разработки невозможен. Возможно, в команду можно добавить больше людей. Или добавить целую вторую команду. Может быть, одно или два требования сильно влияют на график релиза и смещение реализации всей функциональности с опозданием на месяц – не проблема, если при этом основная часть важных функций будут представлены вовремя.
Таким образом, систематическое предоставление командой более-менее точных оценок приводит к возникновению взаимоотношений между руководителем и командой разработки “на равных”, основанных на доверии и взаимном уважении. Конечно, отношения такого рода не выстраиваются за один присест, но можно гарантировать, что они точно не будут выстроены, если команда не будет постоянно практиковаться в повышении точности своих оценок.