Книга: Как пасти котов. Наставление для программистов, руководящих другими программистами

Когда проект разрастается

Когда проект разрастается

Я имею в виду классическое понятие разрастания проекта. Если аналитик бизнес-требований утверждает, что занимается уточнением рамок, знайте: он их раздвигает. Не важно, как этот процесс называть. Факт тот, что специфицировать и сконструировать программу, избежав разрастания требований, не удавалось еще никому. Объясняется это натурой человека – невозможно с первой попытки сформулировать все функции, которые предполагаемой программе предстоит выполнять.

Рассмотрим типичный процесс производства программного продукта. Вне зависимости от того, что вы предпочитаете – стремительный напор или постепенные итерации, – процесс этот всегда состоит из нескольких фиксированных этапов.

1. Замысел. У кого-то появляется блестящая идея.

2. Специфицирование. Куча людей пытаются описать эту идею.

3. Проектирование. Высокоинтеллектуальные товарищи решают, как сконструировать предполагаемый программный продукт.

4. Конструирование. Бессонными ночами и нескончаемыми днями программисты программируют.

5. Тестирование. Обнаруживается, что конечная реализация блестящей идеи не так хороша, как хотелось бы, или, еще хуже, что идея-то отнюдь не блестящая.

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

А теперь подумайте: таким ли уж неожиданным станет разрастание рамок в контексте отраженного в этом списке реального сценария? Мне так не кажется, и вам тоже не должно так казаться. И тем не менее, если речь об этом зайдет, воя и зубовного скрежета программистов не избежать. Как заставить их поверить, что вы во всеоружии и ваша позиция правильна? Лучше всего поставить их перед фактом, что разрастание неизбежно, и научить их справляться с этой проблемой. Вы руководитель, и это – ваша обязанность. Не поддавайтесь соблазну разнести «крайних» в других отделах – этим вы не приблизите завершение работы и не исправите ситуацию.

В своей немного устаревшей, но, тем не менее, сохраняющей значимость книге под названием «Managing the Software Process» Уотс Хэмфри (Watts Humphrey) сформулировал принцип, актуальный по сей день:

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

• любой процесс продлится дольше, чем вы надеетесь;

• всегда появляется что-то, о чем вы не подумали.

Вооружившись этими аксиомами и введенным Хэмфри понятием «состояния проекта», старайтесь контролировать разрастание и обязательно убедите ваших подчиненных в том, что вы человек проницательный, поскольку предсказывали такую возможность и учли ее в процессе тщательного планирования. «Тщательное планирование»! Звучит замечательно, но что же это означает в контексте выпаса котов? А вот что. Вернитесь к главам 1 и 2, еще раз пробегитесь по изложенным в них принципам и попытайтесь сделать их неотъемлемыми элементами своего характера. Помните, что лидерство происходит от сердца, а не от ума[36].

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

Оглавление книги