Лидер программного проекта

В.Н. Лукин,

к.ф.-м.н., доцент Московского авиационного института (Государственного технического университета), Россия

“Самое лучшее, что может сделать лидер большой группы – это позволить ее участникам обнаружить в себе величие и раскрыться в нём”.

Уоррен Беннис, Organizing Genius: The Secrets of Creative Collaboration. – Reading, M.A.: Addison-Wesley, 1997.

Проблемы разработки прикладных программ и систем занимают исследователей и прикладных программистов без малого 60 лет. Учитывая темпы развития науки и технологии в 20-м веке, это огромный срок. Были предложены и внедрены различные методологии создания программных систем, разработаны многочисленные инструментальные средства, призванные снизить трудоёмкость их производства и улучшить качество. Однако по-прежнему не удаётся найти кардинальное решение этой проблемы. Да и вряд ли удастся, если дело касается лишь технической стороны вопроса. Причина кроется не в том, чем разрабатывается система, а кем. Устойчивый, квалифицированный, работоспособный коллектив разработчиков (программистов) стоит гораздо больше, чем любая, самая модная методология и самое современное инструментальное средство. Роберт Гласс [1], ссылаясь на многочисленные источники, приводит высказывания специалистов в области разработки программного обеспечения, которые безоговорочно ставят на первое место по важности именно человеческий фактор. Так, Листер и Демарко утверждают, что «серьёзные проблемы в нашей работе имеют не столько технологическую, сколько социологическую природу». Дэвис сформулировал это так: «Люди – ключ к успеху». Интересен и такой вопрос: «Если бы Ваша жизнь зависела от конкретной программы, что бы Вы в первую очередь захотели о ней узнать?» Естественно, меня бы не слишком интересовало, с помощью каких технологий она была разработана, гораздо важнее – кто её написал, уровень его квалификации и добросовестности.

Так как в настоящее время программное обеспечение разрабатывается не одиночками, а коллективом (командой), за качество разработки отвечает его руководитель, роль которого исключительно высока. Здесь как нельзя лучше подходит старая мудрость: «Армия баранов, ведомая львом, победит армию львов, ведомую бараном». Рассмотрим проблемы руководства программным проектом, исходя из положения, что самый важный фактор разработки программного обеспечения – это не методы и средства, применяемые программистами, а сами программисты [1].

Руководитель проекта: кто он

Представим, что вы стали руководителем программного проекта. Момент вашего перехода из программистов – поворотная точка в судьбе: вам придётся узнать многое, о чём вы, возможно, смутно догадывались, но, скорее всего, не знали. Действительно, ещё вчера вы отвечали лично за себя, сегодня с вас спрашивают работу других людей, вчера вы придумывали убедительные объяснения, почему программа до сих пор не работает, а сегодня вам приходится выслушивать их от ваших программистов. Кроме того, у вас появляется множество других обязанностей: вы отвечаете не только за личный участок в проекте, но и за его состояние в целом, и за команду. Вам приходится решать задачи, казалось бы, не связанные напрямую с разработкой: подбор кадров и адаптация новых сотрудников, организация работы и разрешение конфликтов, то есть создание творческого климата, способствующего успешному завершению проекта и побуждающего работать дальше. Вы будете решать рутинные вопросы администрирования проекта и технического оснащения, следить за качеством продукта и отчетностью, но среди Ваших обязанностей не будет предмета Вашей гордости – умения быстро создавать эффективный программный код. Точнее, не это будет главным. При командной разработке программного обеспечения роль руководителя проекта становится ключевой для достижения успеха проекта в целом. К сожалению, в учебных курсах слишком мало внимания уделяется руководству разработкой, многие навыки зачастую получают на практике, так что приходится учиться в процессе. Учитывая, что каждый программист – потенциальный руководитель проекта, полезно рассмотреть некоторые стороны этой деятельности. По различным аспектам руководства существует неплохая литература, например, замечательная работа Рейнвотера [4], работы Гласса, Йордона, Демарко и Листера, упомянутые в библиографии.

Как становятся руководителем проекта? Самый, видимо, распространённый путь – выдвижение наиболее толкового, опытного программиста, разбирающегося не только в кодировании, но и в смежных областях: системном анализе, проектировании, знакомым с принятыми методологиями разработки. Реже, к сожалению, учитываются способности к взаимодействию с людьми, тем более, программистами: распространённая ошибка считать, что программист со своими общий язык найдёт. Иногда выдвигают на руководящую должность программиста, которого нужно удержать: не всегда есть возможность платить ему столько, сколько он стоит. Этот вариант, как справедливо пишет Ф.Брукс, приводит к замене хорошего программиста плохим руководителем. Далее, могут предложить руководство усердному работнику, который много лет добивался этого продвижения. Обычно это не лучший вариант: работник будет больше думать не о проекте, а своём месте в нём. Лучше, когда руководителем назначается признанный лидер команды. Наконец, руководителя проекта можно пригласить со стороны, но это, скорое всего, будет не новичок.

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