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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как объединить усилия тех, кто гуляет сам по себе

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

• недостаточное функциональное разделение при создании объектов и стыковке логических уровней;

• непродуманные интерфейсы объектов;

• чрезмерная взаимозависимость объектов;

• пристрастие к усложнению внутреннего устройства объектов.

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

В отличие от плодов творчества, которое бесценно, практичный и удобный в сопровождении код можно не только оценить, но и продать.

Опасность!

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

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

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