Константин Борисов - Как хорошему разработчику не стать плохим менеджером

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

В моей практике был забавный случай, когда я пришёл на новый проект, где вроде бы были проблемы с оценками, и поэтому случился кризис. Когда я стал разбираться, то выяснилось, что изначальные оценки были сильно уменьшены, так как заказчику они показались большими. И параллельно объём требований увеличился в десять (!) раз. После такого адекватность самих изначальных оценок можно было и не проверять. Там могли бы быть случайные числа, на “успех” проекта это не повлияло бы.

В общем, все эти, показавшиеся мне очевидными, рассуждения об оценках я убрал. Но, возможно, я был неправ. Если вам не хватает информации об оценивании задач и проектов, напишите мне, пожалуйста, о том, что именно вам хотелось бы знать: borisovke@gmail.com.

Но один момент в оценивании необходимо упомянуть, так как я часто вижу, что его игнорируют и попадают в беду. Важно понимать, что оценка – это субъективная величина. Про это легко забыть, когда смотришь на результат оценки в долларах. Кажется, что если проект оценён в $1’000’000, то это объективно. Ведь величина бюджета – это объективная величина! Как будто у нас есть некий мешок работы и мы его взвесили. Всё точно!

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

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

Совсем нет. Например, если вы спросите оценщика, на какую команду он рассчитывал оценку, то он скажет либо конкретные фамилии, либо уровень. Разумно в оценку сразу закладывать определённую структуру команды: один тимлид, три senior-разработчика, 5 middle-разработчиков. Но нужно понимать, что здесь тоже заложена субъективность.

Даже одинаковые по структуре команды могут сильно отличаться по производительности, просто за счёт того, что отдельные люди не могут сработаться. А отдельные могут так сработаться, что пожениться и сбежать из компании в отпуск на Багамы.Опытный менеджер может это выровнять, а может и не выровнять. Я уж не говорю о том, что вместо планируемых middle-разработчиков обязательно в команду вкинут junior-ов. Реальный бюджет при этом изменится и не в меньшую сторону.

Но, предположим, команду вы получили ту, какую планировали и какую указали в оценке. Теперь-то оценка стала объективной? Ничуть. Сам менеджер является также критичным условием валидности оценки.

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

Поэтому, кстати, я очень против распространённой практики, когда оценивает проект один менеджер и оценщик (часто более опытные), а на выполнение проект попадает к совсем другому менеджеру и лиду.

Чтобы не было мучительно больно, я призываю помнить, что оценка – это не просто некая сумма денег, а это фактически некий мини-план проекта, выполненный конкретными людьми для конкретных условий.

Оценка проекта важна на этапе определения бюджета, но для контроля выполнения проекта и менеджеры, и заказчик используют плановые даты, milestones. Основная дата, дата окончания проекта, жёстко закреплена и для контроля не подходит, так как в конце проекта уже ничего изменить нельзя. А вот многочисленные промежуточные даты используются для отслеживания прогресса, координации разных команд, демонстрации системы и уточнения требований, а также многих других полезных вещей. И тут есть возможность (и необходимость) заложить буферы, которые я называю бесплатными.