Джозеф Фокс - Программное обеспечение и его разработка

Вторым необходимым качеством руководителя является внимательность к деталям. Большинство хороших руководителей разработок программного обеспечения тратят очень много времени на изучение мельчайших подробностей работ. И не напрасно.

Третьим желательным качеством руководителя программным проектом является способность к руководству вообще.

Затем следует учитывать знание области, в которой будет проходить работа. Затем опыт. Приходилось ли ему ранее участвовать в какой-нибудь столь же крупной разработке? Не забывайте о «принципе Питера». Многие люди, бывшие способными заместителями, никогда не могут стать хорошими руководителями! Разработка программ объемом в миллион строк намного более чем в 10 раз сложнее разработки в сто тысяч строк.

Какие качества нежелательны?

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

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

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

1. Трудно сказать, насколько велика данная работа.

2. Вы не можете сказать, какова будет (или даже была) производительность труда ваших людей.

3. Вы не можете указать процент выполненной работы.

4. Трудно сказать, в каком направлении идет работа!

5. Трудно сказать, насколько быстро вы движетесь!

6. Трудно сказать, насколько далеко вы продвинулись! Найдется ли человек, который захочет взять на себя руководство работой при таком спектре нерешенных проблем?

1. Эйфория.

2. Разочарование.

3. Поиск виновных.

4. Наказание невиновных.

5. Награждение непричастных к делу.

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

Сказано точно. Изучение новых разработок показывает, что первый руководитель и второй, пришедший ему на смену, обычно кончают одинаково — их снимают. Только после одного или двух «кровопусканий» главное руководство может занять реалистические позиции. Почему люди вообще хотят стать руководителями больших разработок программного обеспечения? Потому что это наиболее быстрый способ продвижения по служебной лестнице, «путь наверх» — если, конечно, вы сможете удержаться.

Вы будете прекрасно вознаграждены, если преуспеете.

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

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

Почему же это должно быть очевидно? Это не так очевидно, как можно было бы подумать! В 1961 г. комитет, созданный по предписанию президента Джона Ф. Кеннеди для расследования причин воздушной катастрофы над Нью-Йорком, вынес рекомендации по автоматизации управления авиалиниями. Комитет настоял на том, чтобы Федеральное авиационное агентство (FAA) для всех новых систем покупало только «отработанные» вычислительные машины. Это ограничение было наложено потому, что в конце 1950-х г. FAA стала вкладывать деньги в разработку вычислительных машин — и деньги стали уходить в эту область, а не на разработку собственно систем управления авиалиниями.

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

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

Небольшая консультационная компания потеряла 300 000 долларов — доход за несколько лет — при попытке закончить работы по контракту, в которых использовалась машина фирмы IBM «Series 1». Аппаратура была великолепной; а системное и инструментальное программное обеспечение было отработано не до конца. Каждый раз оказывалось, что люди натыкались на какую-нибудь неисследованную проблему. Программное обеспечение было новым! По этой причине фирма IBM не давала по нему никаких гарантий. И контракт был передан IBM.

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

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