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

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

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

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

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

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

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

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

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

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

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

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

Например, вы руководите проектом на 12 месяцев с довольно большой командой в 30 человек. И вы решили сделать промежуточный релиз, который будет содержать основную функциональность в приличном качестве. Заказчик готов посадить своих специалистов на проверку системы. Вы получите дополнительное тестирование, а заказчик сможет провалидировать свои требования. Если окажется, что ему нужна немного не такая система, как ему казалось, то ещё будет время что-то исправить.

Предположим, вы оценили этот релиз и получилось, что он будет готов через 6 месяцев. Так вот тут очень важно запланировать дату этого релиза на неделю (а может и на две) дальше. Этот буфер заказчику не будет стоить ничего, потому что на объём работ он не влияет. Но вам и команде будет гораздо проще жить.

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

Другой вид бесплатных буферов – это когда вы подстраховываетесь от действий других. По вашему плану нужно, чтобы требования были готовы 10 июня? Сообщите заказчику, что вы ждёте требования 1 июня. Тогда у вас хотя бы будет шанс не понести потери, когда вы получите требования плохого качества или с задержкой.

Или вам нужно интегрироваться с ещё не разработанным сервисом, который будет готов в декабре. Сообщите заказчику, что вам нужна документация по API хотя бы в ноябре. Явно она уже должна быть готова. Если вы не получите документацию в ноябре, то самой системы в декабре вы точно не получите. Ну и, конечно, даже если заказчик очень уверен, что это API будет готово 1го декабря, то никак нельзя ставить задачи, зависимые от него на 2е декабря. Обязательно нужен  такой же “бесплатный” буфер в плане, который подстрахует вас от неудачи другой команды.

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

Если вы видите, что не можете добавить запас по времени в ваш план, то это повод записать в свой реестр новый риск. Это показатель хрупкости плана. Скорее всего, у вас проблемы и надо начинать их решать уже сейчас.