Правила Ашманова

Игорь Ашманов

Данный свод высказываний предназначен для руководителей, которым волей судеб пришлось заниматься новым для себя делом - управлять тем или иным "программистским" проектом (созданием информационной системы предприятия, разработкой сайта, и т. п.).

Опытному человеку сказанное ниже может показаться набором простых и давно известных истин. Я и не собираюсь претендовать на авторство всех приведенных ниже правил.

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

Много раз видели мы срыв сроков, провал проектов. Видели бизнесменов, с готовностью вкладывавших деньги в новую технологию, поражающую воображение - без понимания рынка, бизнес-планов и даже примерных результатов и сроков работ. Я и сам совершал множество подобных ошибок за 15 лет работы в индустрии производства программного обеспечения.

Вот эти простейшие вещи и собраны здесь в виде свода правил.Вот самое первое из них:

Первое правило Ашманова. Не бывает технических проблем. Бываюттолько человеческие, то есть организационные.

Я не даю здесь технических советов относительно управления проектами, правил планирования и документирования, процедур тестирования и выпуска. Обо всем этом написаны горы специальной литературы, в том числе классическая книга Фредерика Брукса "Мифический человеко-месяц".

Однако должностные инструкции и правильные процедуры - далеко не всё. При запуске проекта руководитель в первую очередь вступает в человеческие отношения с коллегами, исполнителями, подчиненными. Эти отношения сложны, непривычны и часто могут просто поставить в тупик, если не знать всего нескольких простых правил.

Об управлении программистами

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

Управление программистами - не магия. Управлять программным проектом может даже гуманитарий. Но для этого обязательно нужно вообще уметь управлять людьми и проектами. Как и в любой отрасли, менеджеру достаточно знать некоторые особенности технологического процесса и не поддаваться "мифам индустрии". Всё остальное зависит от обычного умения менеджера наладить работу.

Мифы. Управление программистами имеет особенности, осложненные мифами и иллюзиями вокруг программирования. Эти мифы охотно поддерживаются разработчиками и продавцами компьютерных услуг. Основной причиной мифов является противоречие между очевидной интеллектуальностью и сложностью работы с одной стороны, и совершенно обычными свойствами персонала и проектов - с другой стороны. Независимость от мифов приходит с опытом и знанием.

Распространенные мифы о разработке программного обеспечения

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

Поэтому разговоры об уникальности разработчиков ПО, специфике управления программистским проектом, особых путях бизнеса - всегда очень подозрительны.

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

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

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

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

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

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