В ванной капает кран. Кап-кап, выносит мозг. Сколько времени тебе потребуется, чтобы его починить? «Часик», прикинул ты? «А почему столько?» — спросит тебя владелец бизнеса (жена). Все, тупик, тебе ответить нечего. Хоть раньше ты и чинил краны, но ты только что дал необдуманную, исключительно интуитивную оценку, и теперь вынужден нести за нее ответственность.

© 2009 orkomedix | http://www.flickr.com/photos/orkomedix/4197641094/

«Как это так я дал необдуманную оценку? А сколько времени, по-твоему, нужно чинить кран?»

Прислушайся к своим мыслям, у тебя в голове сейчас запустился алгоритм: ты представил себе смеситель, инструменты лежат рядом, взять отвертку, открутить ручку, отложить, зажать кран в гаечный ключ, крутануть, ой бл#, забыл воду перекрыть — и так далее. Выпиши последовательность своих воображаемых действий на бумагу — и ты получишь план. Прокрутив в голове весь процесс несколько раз, ты увидишь, сколько времени занимает каждый шаг этого плана¹.

Программный продукт рассчитывается точно также: нужно вспомнить, сколько времени раньше занимали максимально похожие действия.

Большой проект делят на минимально возможные части и оценивают отдельно каждую из них. Чем мельче рассматриваемая задача, тем точнее будет общая оценка. Проще говоря, программист точно знает, сколько времени занимает написать код «прочитать значение из файла» («открутить ручку крана»), но никак не может аргументированно оценить «личный кабинет на сайте» («починить смеситель»).

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

По каждой задаче нужно выписать две оценки: оптимистическую и пессимистическую. Обычно ручку крана можно снять за полминуты, но если там застрял винт, то на это может уйти минут пять-десять.

Затем оценки суммируются, к ним добавляется 30% на приятные неожиданности², и ты получаешь сроки разработки «от» и «до».

По разнице между ними можно проверить качество планирования:

• Если разница двухкратная — оценка слишком точная. Это знак опасности: либо проект маленький и понятный, либо эта оценка делалась поверхностно;
• Если пессимистическая оценка в шесть раз больше оптимистической — оценивались слишком общие задачи или же у программиста нет конкретно вот этого опыта;
• Очень хорошо, когда оценки отличаются в три-четыре раза.

Важно!

Сроки реализации конкретных задач называет только исполнитель. Именно ему писать этот код и, следовательно, только он может знать, сколько у него с его знаниями и опытом уйдет на это времени.

Тут менеджеру очень важно осознать ключевой момент: полученные оценки — это не приглашение к торгам. Эти оценки не подлежат обсуждению: глупо убеждать программиста, что он такой-то код напишет быстрее чем он сам думает. Еще хуже — таки убедить его.

Оценка сроков в каком-то смысле похожа на медицину: решения хоть и обоснованы, но неподконтрольны, и в реальности все может получится иначе. Это невозможно предусмотреть или избежать. Подавляющее большинство всех софтверных проектов в мире выходят за пределы установленных сроков и бюджета. Не нравится? Вон из театра!

«Программисты называют сроки, которые могут отличаться в три раза и я еще и не имею права им что-то сказать? Да вы там что, с ума посходили?! Так бизнес не делается.»

Нормальная реакция менеджера, впервые сталкивающегося с реальным софтверным производством. И его можно понять! Крайне тяжело нести ответственность за календарный план, в котором ключевой процесс может длиться месяц, а может пять, может стоить сто рублей, а может пятьсот и никто не знает точнее.

Типичный способ, как эту проблему пытается решить неопытный менеджер: он заставляет людей назвать нужные ему сроки. Ну или просто ставит коллектив перед фактом, если он полный идиот. Это дает менеджеру немедленное ощущение успеха и уверенности в себе: он молодец, он составил план! Но объективная реальность существует вне зависимости от его фантазий: код все равно будет писаться так, как обычно пишется код, и этот замечательный план сорвется на первой же контрольной точке.

Следовательно, такой подход — неизбежный и запланированный провал.

© 2010 Josh Shefman | http://www.flickr.com/photos/departingyyz/5816678307/

Если чуть подумать, то окажется, что существует масса бизнесов, где ситуация аналогична. Научные исследования или медицинские процессы точно также не прогнозируются по срокам; торговля на фондовых рынках точно также не прогнозируется по доходности; производственный процесс в театре точно также зависит от настроения участников и так далее.

Понимаешь? Проблема размытых сроков не уникальна для софтверной индустрии. Более того, бизнес уже научился с этим работать!

1. Ключевое решение, как и все гениальное, очень простое: в бизнес-план сроки записываются с большим запасом. Нормально, например, удвоить пессимистическую оценку и рассчитывать уже на нее. Хорошо, если код сдается раньше, чем записано в бизнес-плане, но тоже неплохо, если сдается всего лишь «вовремя».
2. Не страшно, если софт задержится. Страшно, если ты об этом узнаешь днем накануне и у твоего бизнеса не останется времени подготовиться к задержке. Контролируй выполнение проекта и регулярно двигай план в соответствии с текущей ситуацией.
3. Софт обычно можно начинать использовать еще до окончания официального срока его разработки. Например, если разработка предположительно займет 300 часов, то скорее всего, «личный кабинет» появится через 40 часов, «начисление платежей» еще через 20 часов, и т.д. Свои люди уже смогут частично пользоваться продуктом, а для многих начинающих бизнесов этого достаточно.

Да, все настолько просто.

«Зажрались! Я на них поору и урежу премии — быстренько все напишут мне за два дня».

Программирование — это искусство, процесс сугубо творческий. Творчество же возможно только тогда, когда в душе покой, когда вокруг мир и комфорт. Творчество слабо контролируется разумом, поэтому если менеджер создает стресс вместо покоя, то программист просто не сможет работать. Он не сможет сконцентрироваться на задаче, уйти в себя, хорошо обдумать код и что-либо создать. Все, к чему стремится человек в таких условиях — поскорее избавиться от источника стресса. Таким образом, запугивая творческий коллектив, менеджер гарантированно задерживает сдачу продукта.

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

Сколько ни ори на жука-шелкопряда — он не даст больше паутины. А вот если его хорошо кормить…

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

© 2007 Rahul Nair | http://www.flickr.com/photos/rnair/1352595043/

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

Но пока так; нравится тебе это или нет, но результат зависит от настроения программиста.

Вопросы? Комментарии? Прошу в блог или почтой.