Сделано

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

Палочка-выручалочка и методология

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

Однако моя цель в этой главе, да и в книге, не в том, чтобы сравнивать различные методологии. Напротив, я считаю, что нужно овладеть концепциями, на которые они все опираются, чтобы преуспеть с любой из них. Методологию всегда следует адаптировать и корректировать под спецификации каждой команды и проекта, а это возможно, только когда ваши знания намного глубже поверхностных. Итак, если вы прислушаетесь к основным идеям этой главы и книги, вероятность вашей эффективности возрастет, независимо от того, какой методологией вы пользуетесь. Я объясню аспекты некоторых методов, однако если вам нужен подробный анализ, его придется поискать в других источниках[20]. Хотя методы разработки программного продукта важны, это не палочка-выручалочка. Худшее, что можно сделать, – слепо соблюдать правила, которые явно не работают, просто потому, что они указаны в какой-нибудь известной книге или рекомендуются авторитетным экспертом. Зачастую зацикленность на процессе – тревожный признак: она может свидетельствовать о попытке менеджера уклониться от трудностей и ответственности или погрузиться в бюрократические процедуры, которые заменяют настоящие лидерские действия. Более того, одержимость методологией иногда указывает на слабые стороны организации. Как Том ДеМарко пишет в книге «Человеческий фактор»[21]:

Одержимость методологией – еще один пример иллюзии высоких технологий. Люди убеждены, что самое главное – технология. ‹…› Но какими бы ни были технологические преимущества, они возможны лишь за счет значительных жертв со стороны команды.

Сосредоточившись на методе и процедуре, вместо того чтобы выстраивать процедуры в помощь людям, МП приступают к планированию, ограничивая вклад отдельных сотрудников. Они акцентируют внимание на правилах и их соблюдении, вместо того чтобы учить сотрудников думать, адаптировать, совершенствовать эти правила. Так что любую методологию следует использовать крайне осторожно: нельзя навязывать ее команде[22]. Напротив, методология должна поддерживать, стимулировать команду, помогать ей достичь результата (в главе 10 вы найдете советы на эту тему).

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

Как выглядят графики

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

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

Согласно правилу третей, один день вы должны уделить написанию кода, один день – планированию и один день – тестированию и исправлению ошибок (рис. 2.1). Что может быть проще! Это удобный способ проверить существующий график или составить новый с нуля. Если общее количество времени не делится на три части, должны быть очевидные причины, почему проект требует неравномерного распределения усилий. Дисбаланс в правиле третей (например, тестированию уделяется на 20 % больше времени, чем внедрению) допустим, если он не случаен.

Рис. 2.1. Примитивное правило третей в графике проекта

Возьмем, к примеру, гипотетический проект разработки. Если вам дали шесть недель на запуск, то первое, что нужно сделать, – разделить это время примерно на три части и рассчитать, когда работа будет выполнена. Если для ее качественного выполнения времени не хватает, в ваш проект закралась серьезная ошибка. Либо график следует изменить, либо сократить объем работы (или же снизить планку качества). Если урезать время тестирования, то велика вероятность, что время, отложенное на программирование, вы потратите впустую или же такой код будет сложно сопровождать. Правило третей полезно, так как исключает перетягивание каната, свойственное проектам. Чтобы добавить новые функции, нужен не только программист: неизбежны затраты на проектирование и тестирование, которые кому-то придется взять на себя. Обычно проект отстает от графика из-за скрытых или проигнорированных затрат.

Рассмотрим самый простой пример: нет никакого проекта. Вся работа выполняется фрагментарно: поступает запрос или задача, ее оценивают относительно других задач и ставят на ближайшее «окно» графика. Разработчики сайтов и программисты работают именно так. Они редко вкладываются в масштабные задачи. Подобным командам рекомендуются Agile-методы (скоро мы их обсудим) как самая гармоничная система организации работы, потому что они акцентируют внимание на гибкости, простоте и готовности к изменениям. Если вы трудитесь над несколькими небольшими задачами (не проектами) одновременно, вы можете отталкиваться от примеров проектов, которые я привожу в этой книге.

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

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

20

Подробное сравнение традиционных методов разработки программного продукта и agile-метода можно найти здесь: Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner (Addison-Wesley, 2003).

21

ДеМарко Т., Листер Т. Человеческий фактор. Успешные проекты и команды. СПб.: Символ-Плюс, 2011.

22

Подробнее о том, как осмыслить изменения в процессе разработки софтверного продукта и управлять ими, см. Watts S. Humphrey Managing the Software Process (Addison-Wesley Professional, 1989).