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

В Fixed Price проектах команда должна понимать всю сложность проекта и очень осторожно действовать с требованиями, оптимизациями, предложениями и замечаниями заказчика.

Тут меня могут спросить: “А как же Agile?! Мы же все такие гибкие и ориентированные на изменения под требования заказчика!” Всё так и есть. Здесь Fixed Price проекты не выделяются. Я успешно делал Fixed Price проекты по Scrum (и это было весело). Но надо учитывать, что высший приоритет заказчика – это бюджет. Любые предложения что-то добавить ведут к необходимости что-то выкинуть. Это можно сделать и реально делается, но надо быть осторожным.

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

Причём, заказчик в Fixed Price проектах абсолютно осознанно сам за объёмом работы не следит. Он ведь специально заплатил вам больше денег, чтобы вы это делали за него. И в контракте его очень точно прописано, что нужно сделать и за сколько. Так что любые улучшения, которые вы предложите и на которые он согласится, будут за ваш счёт.

Жёсткое отслеживание объёма работы в случае Fixed Price проектов – это не агрессия и жажда денег, это проявление профессионализма и уважения к заказчику.

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

– Так, первый пункт “Экран ввода данных”, у Дмитрия общая оценка получилась 200 часов. Посмотрите ваши оценки, у вас такие же часы получились по подзадачам?

– Нет, у меня больше на создание БД. 32 часа вместо 24. Мне кажется мы там провозимся, – озвучивал я свои отличия.

– Отлично, ставлю 32 на создание БД, – Владимир не спорил.

– А у меня ещё там есть подзадачка обновление юнит-тестов на 6 часов. Но её Дима, наверное, по другим раскидал, – заметил другой разработчик, Алексей.

– Хорошо, добавляю задачку на юнит-тесты на 6 часов, – Владимир обновлял оценку, пока говорил ответ. – Всё по этой задаче? Следующая: “Отчёт по премиям”.

– У меня там на дизайн формы в два раза больше времени…

– А у меня ещё на экспорт и отправку почты маленькие задачи.

– Добавлено, – оценка росла как на дрожжах. – Двигаемся дальше.

Так мы очень быстро проходили по всем пунктам, выбирая максимальные оценки и добавляя максимальное число задач. Я не выдержал:

– Владимир, а почему ты выбираешь максимальные оценки и, не разбираясь, добавляешь задачи в список? Как-то бездумно получается.

– Константин, мой опыт показывает, что если кто-то видит какую-то проблему, то он прав, эта проблема обязательно возникнет и мы потратим на неё время. – Владимир шёл по задачам, округляя все числа в большую сторону. – А это мне ещё все говорят, что я слишком оптимистичен.

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

Сложность.В официальном “The Scrum Guide” Scrum определяется как нечто, что “легко понять”, но “трудно овладеть”. То есть если у вас Scrum не заработал, то это нормально. Scrum указывает некоторое направление, но совсем мало помогает в достижении ваших целей. Это не инструмент в обычном понимании.