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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правило 2. Технический арго ничего не значит.

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

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

Правило 3. Разработчики всякий раз называют неуверенные сроки.

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

Правило 4. Разработчику характерен врожденный оптимизм.

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

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

Правило 5. Программист проверяет страсть к обобщению.

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

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

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

Баланс меж обобщением и текущими требованиями рынка достигается экспериментом и соображениями бизнеса. Программистам полагаться здесь безусловно бессмысленно, как зря обсуждать с пьяницей фамильный бюджет.

Правило 6. невозможно делать "по-хорошему".

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

Верный признак работы в манере "по-хорошему" - упорная работа с "ядром", задержки с реализацией конкретной запланированной функциональности и срыв сроков выхода продукта.

Правило 7. Приминание травы может отобрать любое численность времени.

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

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

Правило 8. Разработчик не интересуется бизнесом, он - обычный автор.

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

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

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

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

Схемы мотивации еще должны принимать во внимание авторские мотивы и врожденный оптимистичность разработчика (например, из этого общего принципа просто выводится недопустимость штрафов за срыв сроков).

Этот маленький словарик - приложение к моей статье "Правила Ашманова" (см. выше). Там я произношу об особенностях управления программистами, а тут собрал "практический материал" - высказывания, коие менеджер не обязан понимать буквально.

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