Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [85]
Конечно, бывают моменты, когда расширение команды ускоряет прогресс, но середина работы над проектом к их числу не относится. Понятно, что многое изменилось с тех пор, как Брукс опубликовал «Мифический человеко-месяц», но эта концепция в значительной степени осталась верной.
На рисунке показано то, что я наблюдал лично. Я составил формулу[10] для расчета. Она не слишком научна, но, если спросить разработчиков о том, близка ли такая зависимость к истине, думается, они с ней согласятся.
Результаты снижаются, когда число разработчиков увеличивается до 10. Это подчеркивает необходимость сохранения небольших команд, а также объясняет, почему нельзя добавить людей в существующую команду и ожидать большего результата. Если увеличить число разработчиков с 10 до 20, то вы более чем вдвое снизите производительность и получите замедление работы, а не ускорение. А если команда разрастается примерно до 25 человек, то результат становится отрицательным. Я не знаю точно, чем объяснить этот эффект, но мой опыт говорит, что результат именно такой.
Понятно, если вас расстраивает то, что нет возможности привлечь больше работников к устранению проблемы. На бюджет тоже нужно смотреть с позиции руководителя, и он не резиновый. Но в краткосрочной перспективе не выливайте свое раздражение на команду. Это только деморализует уже и без того измотанных людей. Это все равно что злиться на гравитацию. Если ваш парашют не раскрылся, вы можете проклинать гравитацию сколько угодно, но это не поможет.
Однако в более отдаленной перспективе хорошие лидеры могут более эффективно «разделять и побеждать». Разделение проблемной области, кода и работников на более мелкие блоки позволяет создать резерв и добавить больше сотрудников. Вспомните процесс клеточного деления, описанный в главе 8. Не забывайте, что подобные реорганизации требуют времени. Рассчитывайте на то, что увеличение численности разработчиков и бюджета приведет к ускорению прогресса не ранее чем через полгода.
Недавно у меня был разговор с руководителем, рассматривавшим проект, для выполнения которого требовалось три года. Это был важный проект, и руководитель очень сожалел, что они не могли «бросить $100 млн на решение проблемы» и справиться с ней за год – лидеры разработчиков заявили, что прямо сейчас они не в состоянии ускорить проект даже с большим бюджетом. Затем руководитель сказал: «Держу пари, если предложить [название крупной консалтинговой фирмы] $100 млн, они сделают это». Я ответил: «Конечно, их торговый представитель скажет, что они сделают это, когда увидит $100 млн, но им тоже не удастся одолеть задачу». Вот почему крупные консалтинговые проекты никогда не укладываются в сроки и бюджет. Примечательно, что руководитель не стал спорить со мной, надо думать потому, что его опыт подтверждал мое мнение. Иногда принятие трудных решений требует времени. Но я все же предложил этому руководителю обсудить с техническими лидерами, что они могут предпринять сегодня и в ближайшие месяцы для увеличения бюджета через полгода и завершения проекта за полтора года вместо трех лет. Это разумный вопрос, и эффективный технический лидер должен знать, как ответить на него.
Даже в нынешней аджайл-среде работа по-прежнему делится между командами. Чтобы ускорить работу, менеджерам нужно либо добавлять персонал в команду (а это ведет к проблемам, описанным Бруксом), либо перераспределять работу так, чтобы команды могли выполнять ее параллельно. В любом случае это влечет за собой огромный перерасход ресурсов сначала на поиск сбалансированного распределения работы, а потом на встраивание ее частей в кодовую базу. Это классическое «замедление ради ускорения». И наконец, нужно укомплектовать команду и добиться продуктивности. Как бы то ни было, лучше всего просто позволить команде продолжить работу в краткосрочной перспективе, а в это время подумать над реорганизацией структуры команд, которая обеспечит ускорение. Существуют естественные точки остановки, где очень удобно провести переоценку и перераспределение задач (я показывал в главе 8, как клеточное деление позволяет с течением времени разделять и выращивать команды), но это надо делать не в разгар работы над проектом, особенно если намечается отставание от графика.
Ловушки методологии аджайл
Все это хорошо, но методология аджайл не панацея от всех проблем, как ее иногда описывают неофиты. Как и любая система организации, аджайл-подход имеет свои плюсы и минусы. В недавнем разговоре с генеральным директором публичной компании я спросил, как продвигается их аджайл-трансформация, и он ответил: «Сборище лентяев рассказывает нам, как вести бизнес, – и ничего не меняется!» Я чуть не упал со стула. Где же методология аджайл дала сбой?
