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

Таблица 3.4. Реалистичный план проекта

Задача……Время выполнения (произвольные интервалы)

Анализ требований……А

Обсуждение результатов анализа с сотрудниками отдела……В

Создание проектного решения……С

Макетирование проектного решения……D

Оценка макетов……Е

Пересмотр проектного решения……F

Реализация высокоуровневых объектов проектного решения……G

Тестирование высокоуровневой интеграции……Н

Оценка системы на предмет соответствия требованиям……I

Создание компонентов системы……J

Интеграция и тестирование компонентов……К

Повторная оценка системы на предмет соответствия требованиям……L

Тестирование комплектной системы……М

Исправление неисправностей системы в преддверии альфа-тестирования……N

Начало альфа-тестирования……О

Исправление ошибок, выявленных на этапе альфа-тестирования……Р

Начало бета-тестирования……Q

Разработка стратегии развертывания……R

Исправление ошибок, выявленных на этапе бета-тестирования……S

Тестирование стратегии развертывания……Т

Тестирование конечного продукта……U

Развертывание программного обеспечения……V

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

По большей части, разрастание рамок проекта происходит по причине недоработок специалистов, отвечающих за планирование.

Каков механизм совершенствования навыков временной оценки? Он очень прост – поначалу вам предстоит неоднократно нарушать утвержденные графики сдачи проектов, но, в конце концов, вы научитесь им соответствовать. Практика эта довольно нервозная и даже угрожающая вашему карьерному росту. Возможно, это не лучший способ самосовершенствования, но что можно утверждать со всей определенностью, так это то, что в области управления проектом опыт играет огромную роль. А чтобы ускорить обучение, почитывайте анекдоты, относящиеся к руководству проектами. В своей леденящей душу коллекции очерков о неудавшихся программных проектах Роберт Гласе (Robert Glass) составил список наиболее распространенных «программных катастроф», который я привожу в порядке снижения значимости[37].

1. Неадекватное специфицирование задач проекта (51 %).

2. Неудовлетворительные планирование и оценка (48 %).

3. Применение новой для данной компании технологии (45 %).

4. Негодная/отсутствующая методология руководства проектом (42 %).

5. Нехватка ведущих специалистов группы (42 %).

6. Срыв договоренностей производителями аппаратного/программного обеспечения (42 %).

Процентные показатели, приведенные для каждой из вышеупомянутых причин несостоятельности, выведены Глассом в ходе специального исследования с целью выявить основную причину выхода процесса разработки программных продуктов из-под контроля. Я очень рекомендую ознакомиться с этой и другими подобными работами[38]. В результате вы поднимете процесс обучения на более осмысленный уровень, получите определенное представление о реалистичном планировании проекта, овладеете методикой контроля над разрастанием рамок проекта.

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