Миссия не выполнима

Есть такой тип программерских команд, я называю их «миссия не выполнима». Что это такое? Начинается все как обычно. Набирается команда для разработки нового проекта. Здесь ключевое слово – «нового». Как обычно в таких случаях, при подборе команды, говорят всякие красивые слова про передовые технологии, невероятную крутость будущего продукта и т.д.и т.п. Хотя это может не иметь ни какого отношения к действительности, не важно. Разработчики, обычно подбираются с уровнем выше среднего, это второй ключевой момент. Есть еще третий ключевой момент, но о нем я скажу несколько позже.

И тут начинается. Парни действительно верят, что они собрались здесь для того, чтобы совершить как минимум третью (пятую, восьмую) программную революцию. Энтузиазм бьет ключом, и работа кипит. Используются только новые и самые навороченные технологии, в бета или альфа версиях. Пышным цветом расцветает перфекционизм - все должно быть совершенным, архитектура, стиль кодирования, модульные тесты… Еще бы, ведь цель – создать совершенный, невиданный продукт. Если вдруг обнаруживается, что проблему можно решить другим более красивым способом, или обнаружен новый более продвинутый фрэймворк, никто не остановится пред тем, чтобы все переделать заново, не считаясь с затратами. Однако здесь важен один момент, должен быть дядя с тугим кошельком, способный в течении длительного времени кормить и поддерживать этот «dream team». И это третий ключевой момент, без которого все заканчивается довольно быстро.

Попасть в такую команду очень сложно. «Мы лучшие и нам нужны только лучшие». Новичкам обычно довольно сложно по началу. Когда то мне самому довелось поработать в такой команде, - «Группа разработки ядра» (ядра чего – не скажу :), это было необычайно круто. Я был просто счастлив, что попал туда. Я работал как вол. Потом, спустя время, я был счастлив, что ушел оттуда, это было потом.

К сожалению, все те силы, которые питают «dream team» невероятной энергией, в большинстве случаев приводят ее к гибели. Использование необкатанных сырых технологий вызывает большой энтузиазм у разработчиков но, одновременно, несет в себе массу архитектурных и технических рисков. Стремление реализовать уникальные фичи часто ведет к небрежению основным функционалом в ущерб его надежности. Пренебрежение сроками, синдром второй версии, все это типично для таких команд. По большому счету все это происходит из-за недостаточной управляемости. Однако управлять такой командой не легче, чем болидом NASCAR на полной скорости. Одно неверное движение руля и уже обломки летят по всей трассе. В зарегламентированной, управляемой команде нет того выброса ментальной энергии, который есть в «dream team», а в «dream team» нет возможностей управления, которые не погасили бы пыл разработчиков.

Стиль управления, предлагаемый методикой экстремального программирования (XP) больше всего подходит в этом случае. Однако XP, согласитесь, требует высочайшей дисциплины в исполнении своих практик. Многие считают, что это не так, и поэтому, в конце концов, все идет кувырком.

Так и выходит, что миссия оказывается не выполнима. Говорят, иногда у них все получается. Говорят, кто-то видел такие команды в Mountain View или в Redmond или высоко в Гималаях. Наша «Группа разработки ядра» была расформирована после трех лет существования. C тех пор прошло три года. На созданном ядре разрабатывается продукт. Разрабатывается до сих пор.