Жёсткое отслеживание объёма работы в случае Fixed Price проектов – это не агрессия и жажда денег, это проявление профессионализма и уважения к заказчику.
История про объединение оценок
Однажды я работал под руководством очень хорошего менеджера, Владимира. И он применял удивительный и эффективный метод оценивания. Когда были готовы требования, он с помощью архитектора выделял высокоуровневые задачи и рассылал команде. Каждый из нас должен был декомпозировать задачи на более мелкие и оценить в часах каждую из мелких задач. Мы, не совещаясь друг с другом, делали эту работу, а потом отсылали ему. А потом Владимир организовывал созвон, где показывая на экране все оценки, собирал общую. Как основу он брал оценку архитектора, Дмитрия, и потом опрашивал всех.
– Так, первый пункт “Экран ввода данных”, у Дмитрия общая оценка получилась 200 часов. Посмотрите ваши оценки, у вас такие же часы получились по подзадачам?
– Нет, у меня больше на создание БД. 32 часа вместо 24. Мне кажется мы там провозимся, – озвучивал я свои отличия.
– Отлично, ставлю 32 на создание БД, – Владимир не спорил.
– А у меня ещё там есть подзадачка обновление юнит-тестов на 6 часов. Но её Дима, наверное, по другим раскидал, – заметил другой разработчик, Алексей.
– Хорошо, добавляю задачку на юнит-тесты на 6 часов, – Владимир обновлял оценку, пока говорил ответ. – Всё по этой задаче? Следующая: “Отчёт по премиям”.
– У меня там на дизайн формы в два раза больше времени…
– А у меня ещё на экспорт и отправку почты маленькие задачи.
– Добавлено, – оценка росла как на дрожжах. – Двигаемся дальше.
Так мы очень быстро проходили по всем пунктам, выбирая максимальные оценки и добавляя максимальное число задач. Я не выдержал:
– Владимир, а почему ты выбираешь максимальные оценки и, не разбираясь, добавляешь задачи в список? Как-то бездумно получается.
– Константин, мой опыт показывает, что если кто-то видит какую-то проблему, то он прав, эта проблема обязательно возникнет и мы потратим на неё время. – Владимир шёл по задачам, округляя все числа в большую сторону. – А это мне ещё все говорят, что я слишком оптимистичен.
Почему Scrum не решает менеджерских задач
Сразу скажу, что я очень уважаю Scrum как философию. Scrum привнёс очень много в индустрию разработки ПО. Достаточно вспомнить хотя бы скрам-митинги, которые сейчас используются повсеместно. И в продуктовой разработке, на которую Scrum ориентирован в первую очередь, результаты его применения очень хороши. Но проблема в том, что Scrum часто позиционируют как средство управления проектами, которым он совсем не является. Да и вообще, как средство управления Scrum вообще рассматривать не стоит. Давайте посмотрим, почему.
Сложность. В официальном “The Scrum Guide” Scrum определяется как нечто, что “легко понять”, но “трудно овладеть”. То есть если у вас Scrum не заработал, то это нормально. Scrum указывает некоторое направление, но совсем мало помогает в достижении ваших целей. Это не инструмент в обычном понимании.
Оценка и планирование. Что хочет знать заказчик, который приходит с некоторым проектом? Ему интересно знать, сколько будет стоить реализация его проекта, и когда будет результат. Какие ответы даёт на это скрам? Никаких. Это гениально, на самом деле, но ответа скрам не даёт. Сейчас даже про story point никаких упоминаний нет.
А как планировать какие-то даты? Если, например, нужно будет код интегрировать с куском, разрабатываемым другой командой, то на какую дату можно ставить эту интеграцию? Неизвестно.
Даже традиционные статистические методы предсказания конца проекта, которые неплохо работают в традиционных проектах (например, статистика багов), очень плохо работают в Скраме, так как он не даёт никаких ограничений на элементы баклога.
От руководителя проектов больше всего требуют конкретные сроки и прогнозы по их выполнению. Скрам тут не помощник.
Командообразование. Может быть, скрам как-то помогает сколотить команду в единое целое? Отнюдь. По скраму команда является самоорганизующейся (self-organizing), а скрам-мастер может только заниматься коучингом (coaching). А коучинг, между прочим, является сложнейшей менеджерской техникой, когда менеджер, абсолютно не высказывает своего мнения и помогает человеку прийти к решению самому. Как овладеть скрам-мастеру такой техникой? Ответа нет. Что делать, если в команде конфликты, если часть команды ведёт себя контрпродуктивно, если разные члены команды действуют неслаженно? Ответа нет.
Даже самые простые вопросы координации скрам не освещает. Например, у вас есть разработчики, тест-дизайнеры, автоматизаторы и ручные тестировщики. Как они должны работать, чтобы никто не простаивал, а спринт выдавал качественный результат? В начале спринта у тестировщиков нет тест-плана, а в конце спринта у тест-дизайнеров нет работы. Скраму это безразлично.
Управление большими командами скрам тоже не поддерживает, указывая, что команды больше 9 членов “нуждаются в слишком большом объёме координации”. А ведь размер команды как раз является одним из показателей мастерства менеджера. Скрам это не покрывает.
People management. Очевидно, скрам игнорирует более сложные вопросы стратегического управления людьми, как, например, мотивацию, профессиональный рост, повышение самооценки, обучение.
Риски и кризисное управление. Скрам заявляет, что следование ему позволяет контролировать риски, но никаких средств по управлению рисками не предоставляет. Предполагается, что максимум, что может пойти не так – это придётся “откатить” работу одного спринта. На практике, конечно, это совсем не так. Повсеместно встречаются проекты, в которых много одинаково критичных кусков, без каждого из которых система не нужна. Успех любого количества спринтов может быть легко перечёркнут одной проблемой, вылезшей в самом конце проекта.
И, конечно, скрам никак не помогает в ситуации, когда проект заходит в тупик по какой-то причине.
Список ограничений можно продолжать долго. Проще сказать, что скрам не закрывает ни одной функции менеджера. Значит ли это, что менеджеры должны его игнорировать? Ни в коем случае! Я считаю, что сейчас каждый работающий в сфере разработки ПО должен хорошо представлять, что такое скрам и уметь работать с ним. Но относиться к скраму нужно не как к инструменту менеджмента, а как к набору идей, которые расширяют сознание и вырабатывают полезное отношение ко всему процессу разработки.
