Абсолютно каждый CEO любой IT компании хочет, чтобы разработка ПО проходила быстрее. Время – это наиболее дорогой и ценный ресурс. Вы не можете тратить его на доработку, рефакторинг, митинги и т.д. Правда ведь?

У большинства компаний есть три составляющих жизненного цикла: активный рост, замедление, смерть. Хорошая скорость разработки необходима для выживания. Представьте, у вас действительно хорошая концепция, подтвержденная в множестве различных ситуаций большим количеством людей. Вы знаете, наверняка, (это достаточно редкий случай на практике, но давайте только представим, хорошо?) что этот продукт станет очень популярным. Все, что вам нужно, это его закончить.

У вас есть команда с десятками талантливых и опытных разработчиков, вы мучаетесь и выпускаете что-то через два года. Команда истощена. Продукт соответствует примерно 10% первоначальной концепции. Есть огромный потенциал, но 10% недостаточно для запуска. Вы мучаетесь еще несколько месяцев, продажи ниже среднего, отсутствие денег, и как итог, конец компании.

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

Скорость с разных сторон.

Большинство людей воспринимают понятие скорости как отдельный объект, но это не так. Существует два противоположных понятия скорости: Краткосрочная скорость и Долгосрочная скорость. Хорошим примером здесь будет спринт и марафон. В разработке ПО, как и в беге, у вас не может быть и того, и другого.  Давайте рассмотрим абстрактную единицу, к примеру пункт. Работать в полную силу в режиме Спринта вы будете выполнять 100 пунктов в месяц. Вот мой первый аргумент:

• Вы не сможете применять метод Спринта на долгосрочные проекты разработки.
• Может быть вы и сможете выполнить 300-600 пунктов за 3-6 месяцев, но очень маловероятно, что вы сможете работать с такой скоростью в течение года.

В какой-то момент большинство разработчиков достигнет точки кипения и производительность значительно упадёт.

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

Как создавать ПО быстрее в течение долгого промежутка времени? Это вопрос на миллион. Вероятнее всего, ответ на этот вопрос уникален для каждой компании, но все-таки возможно построить обоснованную общую модель, которая может быть полезной.

Спринт, Марафон и… Интервалы!

На первый взгляд существует только три варианта.

Вариант 1. Экстремальный Спринт

Вы можете работать на полную мощность, 12-14 часов в день, заливая все это энергетиками, кофеином, сахаром и Бог знает, чем еще. Вы можете работать всю ночь, спать по несколько часов и тратить минимум времени на питание, гигиену, спорт и т.д. Я дам вам месяц. Может быть три, если вы в отличной форме. Хорошо, что все знают, что данный режим настолько плох. Перегорание неизбежно.

Примечание.
Я знаю человека, который работал в таком режиме целый год! Он выучил много нового и значительно прокачал свои скилы, но у всего есть последствия. Вероятнее всего, его проблемы со здоровьем, в настоящий момент, обусловлены именно этим режимом. Разве это хорошая идея, обменять здоровье на опыт? Я так не думаю.

Вариант 2. Умеренный спринт

Вы можете работать по 8-10 часов в день, выжимая все, что можно из этого времени. Никаких бессмысленных бесед, спортивной активности на работе, веселья и т.д. Некоторые компании не делают ничего, чтобы сделать работу интересной, увлекающей. Проекты всегда запаздывают и все находятся под огромным давлением. К сожалению, данный режим может длиться годами. Люди привыкают к этому и не замечают насколько они несчастны. Они компенсируют это дома с семьей или увлечениями. Основная опасность заключается в том, что спустя несколько месяцев продуктивность падает и никто этого не замечает.

Вариант 3. Марафон

Этот режим выглядит наиболее оптимальным. Вы работаете максимально эффективно 6-8 часов, но при этом оставляете немного времени на отдых и упражнения. Вы не торопитесь и обдумываете проблему некоторое время. Никакой спешки в том, чтобы выпустить все ПРЯМО СЕЙЧАС! Звучит отлично. Как бы то ни было, большинство менеджеров не особо удовлетворены таким режимом. Они хотят выполнять все быстрее. Я считаю, что в чистом виде режим Марафона встречается достаточно редко. В большинстве компаний менеджеры стараются максимально ускорить процесс работы и делают это максимально глупым способом, используя овертаймы, продвижение задач и мотивацию типа «мы герои, мы все сможем».  

Может показаться, что это все возможные варианты. Но я думаю, что есть еще один. Если честно, я никогда не слышал о нем.

Вариант 4. Интервалы

Я не говорю сейчас про итеративную разработку. По факту итеративную разработку можно отнести к Умеренному Спринту или режиму Марафона. Интервальная разработка заключается в смешении режимов.  Короткий период времени вы можете работать в режиме Спринта, потом переключиться на Марафон. По моему мнению, хорошим расписанием может быть следующий вариант:

1 месяц – Высокоскоростной Спринт
3 месяца - Марафон
1 месяц - Высокоскоростной Спринт

Давайте я объясню, что я подразумеваю под высокоскоростным режимом. В этом режиме команда (или целая компания) бросает все второстепенные задачи: все митинги про будущие перспективы, обучающие мероприятия, HR мероприятия и т.д. Команда делает акцент на достижении результата: пишет код, тестит, занимается документацией и т.д.

Высокоскоростной режим заканчивается неделей отдыха. Эта неделя посвящается рефакторингу, обсуждениям и мыслям про будущие перспективы.

Преимущество очевидно – средняя скорость будет выше в режиме Марафона. Высокоскоростной режим с режимом Марафона после проходит максимально спокойно и без стресса. Более того, это может выступать в роли мотивации, в момент, когда команда, подсучив рукава, выполняет задачи и выпускает продукт быстро. Полное удовлетворение наступает, когда вы, наконец, выпускаете какой-то продукт. Это достижение, событие. Это наркотик, в каком-то смысле. Может быть именно поэтому люди могут работать в экстраскоростном режиме некоторое время.

No Comments