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

Докладчик: Максим Дорофеев, начал карьеру в 2002 году, как инженер по тестированию в компании DC BARS, специализирующейся на создании и сертификации бортового ПО гражданской авиации. Руководил проектами по созданию, поддержке и тестированию встраиваемого программного обеспечения. В июне 2009 года присоединился к команде Лаборатории Касперского для решения еще более сложных задач.

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC11.

Время проведения: 18:00 – 21:00
Место проведения: компания R-Style, ул. Пришвина, д.8, корп.2, 1-й этаж, ауд. 117. Схема проезда

Личное участие в семинаре бесплатное при условии предварительной регистрации.
Зарегистрироваться для участия

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

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

До встречи на семинаре!

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

Правило 1

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

Правило 2

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

Правило 3

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

Правило 4

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

Правило 5

Руководителями проектов могут быть порочные, презренные и совершенно неприятные люди. Бездушные, нерешительные копуши или болтуны – нет.

Правило 6

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

Правило 7

Одной из проблем нового руководителя проекта является то, что все ждут от него решения своих проблем. Старым руководителям проектов старшее руководство обычно говорило «решите ваши собственные проблемы, мы вас нанимали именно для этого».

Правило 8

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

Правило 9

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

Правило 10

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

Правило 11

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

Правило 12

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

Правило 13

Руководитель, который является своим собственным системным инженером и финансовым менеджером, является тем, кто вероятно пытается сделать самому себе открытую операцию на сердце.

Правило 14

Большинство руководителей преуспевают за счёт усилий и навыков своего персонала.

Инициация проекта

Правило 15

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

Коммуникации

Правило 16

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

Правило 17

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

Правило 18

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

Правило 19

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

Персонал

Правило 20

Вы не можете наблюдать за всем. То, за чем вы должны наблюдать обязательно – это персонал. Люди должны знать, что вы не потерпите плохой работы.

Правило 21

Существует достаточное количество людей, более заинтересованных в процессе работы, чем в её результатах, как часто считают старые менеджеры. Последним кажется, что новое поколение более заинтересовано в форме, чем в её содержании. Главный вопрос в том, правы ли эти старые менеджеры или они только стары? Учитывайте обе возможности.

Правило 22

Хорошие технические специалисты, инспекторы качества для получения хорошего продукта важнее всяких бумаг и отчётов.

Правило 23

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

Правило 24

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

Правило 25

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

Правило 26

Если кто-то не смотрит, не спрашивает, не анализирует, то попросите его уйти.

Правило 27

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

Правило 28

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

Правило 29

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

Правило 30

Некомпетентные специалисты обычно не любят демонстрировать свою работу.

Правило 31

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

Правило 32

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

Правило 33

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

Доклады и отчёты

Правило 34

В НАСА определён перечень стандартных докладов и тех должностных лиц, кто обычно ихрассматривает . Однажды настроенная, такая система будет бороться за то, чтобы продолжать существовать, так что вам остаётся максимально использовать её.

Правило 35

Количество докладов и отчётов увеличивается, но объём содержащихся в них знаний не остаётся тем же самым; поэтому все ваши диаграммы и презентации должны строиться с учётом этого. Это значит, что вы должны быть способны подготовить такой набор слайдов, который можно будет перетасовывать от одной презентации к другой.

Правило 36

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

Правило 37

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

Правило 38

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

Правило 39

Отчёты пишутся не для того, кто их составляет, а для того, кому они предназначены. Если тот, для кого отчет предназначен, не узнает из него ничего нового, то такой отчет неудачен.

Правило 40

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

Правило 41

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

Правило 42

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

Правило 43

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

Правило 44

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

Правило 45

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

Правило 46

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

Контракты и субподрядчики

Правило 47

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

Правило 48

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

Правило 49

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

Правило 50

Быть в дружеских отношениях с субподрядчиком прекрасно, но дружеские отношения с субподрядчиком – подвергают опасности вашу объективность.

Правило 51

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

Правило 52

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

Правило 53

Субподрядчики обычно хорошо относятся к заказчику, который уделяет внимание их работе, но плохо – к тем из заказчиков, которые пытаются непрерывно контролировать их деятельность. Основное правило здесь звучит так: клиент всегда прав, но затраты возрастут, если заказчик всегда будет настаивать на том, чтобы всё делалось в соответствии с его представлениями, вместо того, как это запланировал субподрядчик. Основное правило выглядит так: никогда не изменяйте планы субподрядчика, если только они не совсем плохи и не вызовут значительного роста расходов (лучшее – враг хорошего).

Правило 54

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

Инженеры и учёные

Правило 55

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

Правило 56

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

Правило 57

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

Правило 58

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

Правило 59

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

Аппаратное обеспечение

Правило 60

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

Правило 61

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

Компьютеры и программное обеспечение

Правило 62

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

Правило 63

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

Правило 64

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

Правило 65

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

Старшие менеджеры, руководители программ и те, кто над ними

Правило 66

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

Правило 67

Знайте своих руководителей – некоторые любят хорошую шутку, другие любят шутить только сами.

Правило 68

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

Правило 69

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

Правило 70

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

Правило 71

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

Планирование, бюджетирование и оценки

Правило 72

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

Правило 73

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

Правило 74

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

Правило 75

Старая НАСА покровительствовала лимитам на технологии и науку; следовательно, её не волновали отставания от графика или превышения бюджета. В новой НАСА все проекты имеют фиксированную цену; следовательно, запрос на перенос сроков становится смерти подобен.

Правило 76

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

Правило 77

Любая информация о проекте, кроме бюджета, до представления её президентом в конгресс, вероятно, не является секретной – так не делайте из неё секрета. Каждый сможет принять более правильное решение, если сможет видеть полную картину, поэтому не скрывайте ничего.

Правило 78

Программы НАСА выполняются за счёт бюджетных фондов – и не финансируются из других источников (то есть, никогда не требуйте от других программ или работ НАСА, чтобы они поделились с вами финансированием). Продайте что-либо из имеющегося у вас в пользу своей программы.

Правило 79

Следующий год – это всегда год с нормальным финансированием и графиком работ. Такой следующий год наступит на пятидесятом году вашей карьеры.

Заказчик

Правило 80

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

Инструкции НАСА по управлению

Правило 81

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

Принятие решений

Правило 82

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

Правило 83

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

Правило 84

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

Профессиональная этика и порядочность

Правило 85

Порядочность означает, что ваши подчинённые доверяют вам.

Правило 86

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

Управление проектом и рабочая группа

Правило 87

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

Правило 88

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

Правило 89

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

Правило 90

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

Правило 91

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

Переговоры и предотвращение неудач

Правило 92 В случае неудачи:

• Восстановите цепь событий и отразите в ней всё, что вам известно.
• Рассмотрите известные факты. Проверьте каждую гипотезу о них.
• Не надо выдавливать из фактов выводы в попытках восстановить сценарий.
• Не делайте заключений слишком быстро. Будьте уверены, что любые отклонения от нормального хода проекта объяснены.
• Помните, что любое неправильное объяснение – только пролог к следующей неудаче.
• Знайте, когда следует остановиться.

Правило 93

Думайте, что неудачи – это выученные на будущее уроки. Иногда правильно думать, что это только выученные уроки. Старайтесь повторять их во время работы.

Правило 94

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

Правило 95

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

Правило 96

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

Правило 97

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

Правило 98

Одним из достоинств НАСА в раннем периоде её существования был тот факт, что если некто что-то знал, то мы были абсолютно уверены, что он может быть неправ.

Правило 99

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

Правило 100

Никогда не оправдывайтесь; вместо этого представьте план действий, которые необходимо предпринять.

О документе

Документ подготовлен Джерри Мэддоном (Jerry Maddon), ассоциированным директором Директората полётов Годдартовского центра космических полётов NASA. Джерри собрал эти драгоценности мудрости за много лет из разнообразных источников. Они были отредактированы Родом Стюартом (Rod Steward) из Mobile Data Service из Хантсвилла в Алабаме (Huntsvill, Alabama),. 1 января 1995 года. Обновлено 9 июля 1996 года. Переработано и отформатировано Оливером Ф. Леманом (Oliver F. Lehmann, Ismaning, Germany). Контакт: Шерман Джоб (Sherman Jobe) Sherman.jobe@msfc.nasa.gov, (205)-544-3279.

Источники:

• Оригинальный английский текст (прим. редакции сайта Гильдии: ссылка, судя по всему, потеряла актуальность; английский текст можно посмотреть, например, в документе One Hundred Rules for NASA Project Managers)
• Русский перевод (PMProfy) (перевод: В. Куперштейн, редакция: В. Богданов)

1. Руководство приняло решение перейти с модели разработки “Водопад” на модель разработки “Экстремальный водопад”
2. Ваша компания начала нанимать консультантов, чтобы было кого во всем обвинять
3. Ваш сервер непрерывной интеграции “упал” с ошибкой “Все, б$%, я больше не могу!”
4. Вы написали на языке ruby свой собственный фреймворк, который использует конфигурационные файлы в формате XML
5. Старший член вашей команды считает Мартина Фаулера самонадеянным сопляком
6. Ваша системы контроля версий – это набор папок “revision 1″, ” revision 2″, : “revision 465″ и т. д. на сетевом диске
7. Контроль качества проекта состоит из ответов на вопросы типа “почему эта х%$#я не работает?!”.
8. Ваше ТЗ состоит из трех страниц, написанных за 2 часа перед обеденным перерывом.
9. Вы стали подыскивать новую работу, потому что не хотите поддерживать код, который сейчас пишете.
10. Ваш главный веб-разработчик уверен, что X в XHTML значит “eXtreme”

11. Первая фраза на любом совещании “Есть хорошие новости, есть плохие. С каких начнем?”
12. Ваше руководство приняло решение выстраивать процесс разработки по CMM-уровню 5 (”Optimizing”)
13. Прогресс вашего проекта теперь измеряется числом исправленных багов, а не числом реализованных фич.
14. Термин “Непрерывная интеграция” обозначает контроль того, что новые сотрудники прочитают Wiki-страницу проекта
15. Вы подружились с уборщицей
16. Ваш руководитель не знает, чем вы занимались вчера (и ему на самом деле не особо интересно, что именно вы будете делать завтра)
17. Every milestone ends in a dead sprint
18. У вашего лучшего разработчика из документов об образовании есть только справка о посещении двухмесячных курсов по подготовке системных администраторов в центре “Специалист” при МГТУ им. Н. Э. Баумана.
19. Вы незнакомы с сокращениями DRY, YAGNI, или KISS; но отлично понимаете, что значит WTF или FUBAR
20. Вашего руководителя можно заменить набором правил для автоматического перенаправления электронной почты

21. Ваш процесс разработки имеет сертификат ISO 9001/2000 (и всё)
22. Ваше руководство считает, что “Метрика” – это протеиновый напиток
23. В системе багтрекинга любой баг имеет приоритет “Critical”
24. :А любая новая фича – приоритет “Trivial”
25. Затраты на проект всегда магическим образом совпадают с бюджетом проекта
26. Разработчики используют слова “самодокументирующийся код”, когда объясняют, почему в их исходниках нет комментариев.
27. Вашим любимым шаблоном проектирования является “Обьект-Который-Делает-Все” (God Object)
28. Вы все еще верите, что компиляция – это одна из форм тестирования
29. Разработчики используют vi в качестве IDE
30. Ваш начальник тратит 7 часов в неделю на сбор сведений о ходе выполнения проекта

31. У вас нет личного компьютера на работе (при этом вы не занимаетесь парным программированием)
32. Негласное правило: не устраивать совещания до 10 утра (потому что мы все сегодня были здесь до 2 ночи)
33. Ваша команда считает, что Object-Relational-Mapping – это скоропроходящее увлечение
34. Вы планируете плавно перейти с VB6 на VB.NET
35. Ваш начальник считает, что MS Project является лучшим в мире средством для управления проектами
36. Ваша жена видит вас только через веб-камеру
37. В ваших юнит-тестах нет ассертов.
38. FrontPage является вашим любимым редактором веб-странц
39. Вы до хрипоты спорите о том, нужно ли ставить “{” на новой строке, а обсуждения насчет использования шаблонов проектирования типа MVC проходят быстро и спокойно.
40. Девиз вашей компании “Делай больше, напрягайся меньше”

41. Фраза “у меня все работает” слышна чаще, чем раз в день
42. Последней конференцией, на которой была ваша команды .NET разработчиков, была Apple WWDC 2000
43. Ваш начальник настаивает на том, чтобы вы составляли детальные отчеты о проделанной работе, но никогда не использует их для принятия решений.
44. Отладка идет на боевом сервере
45. Ваш начальник не знает, как проверять электронную почту
46. Your manager thinks being SOX compliant means not working on baseball nights (непереводимо!)
47. Для придания новых жизненных сил проекту, компания нанимает Владимира Жириновского, чтобы тот выступил с пламенной речью перед разработчиками.
48. Последняя книга по программированию, которую вы читали – “Библия Visual InterDev 6″
49. Общий бюджет вашего проекта перепутали с недельным счетом за кофе.
50. Ваш начальник проводит обеденный перерыв в своей машине (плачет)

51. Ведущий веб-разработчик заявляет, что Аякс – это такой чистящий крем
52. Ваш начальник выделил вам 2 дня на написание заявки на покупку видеокарты
53. Отдел продаж снизил оцениваемую сумму выручки, так как там верят, что вы можете работать быстрее.
54. В списке требований к проекту есть пункт “Быть первыми в выдаче гугла”
55. Каждый день вы работаете до полуночи, а начальство уходит в 16:30
56. Руководитель любит говорить “Чего разработчики возмущаются? У них же почасовая оплата”
57. Продавцы “Крошки-картошки”, работящие в ночную смену, начинают узнавать вас в лицо
58. Руководство не может понять, зачем кому-то нужен второй монитор
59. Разработчики используют систему контроля версий только как средство бэкапа исходников
60. Разработчики не занимаются тестированием. Вообще.

61. Разработчики отказываются использовать SVN, потому что считают, что мерджевание – это черная магия Вуду
62. Your white boards are mostly white (непереводимо!)
63. Клиент постоянно принимает график роста затрат за график роста прибыли
64. Кодовое имя проекта изменили на “Камикадзе”
65. С недавних пор вы испытываете чувство иррационального страха, если приходится отвечать “да” на вопрос “сделаешь?”
66. Your teammates don’t refactor, they refuctor (непереводимо!)
67. В качестве поощрения за переработки начальство заказало в офис новую кофе-машину
68. Бюджет вашего проекта в бухгалтерском балансе перешел в статью “Накладные расходы”
69. Вы тайно аутсорсите часть проекта, чтобы читать ЖЖ на работе
70. Еще не выпущена альфа-версия проекта, но уже создана комиссия по контролю за внесением изменений.

71. Вы подумываете о том, чтобы сломать себе пальцы, чтобы вас отправили на больничный.
72. “Дедлайн” был переименован в “майлстоун” (как и предыдущий “дедлайн”)
73. “Политика открытых дверей” у вашего менеджера проектов действует с 19:01 до 9:59
74. Начальство заявляет: “Да нафиг покупать, мы сами это напишем!”
75. По вечерам вы покупаете пиццу, шаурму и адреналин-раш в офис
76. Вашего начальника застукали во время спиритического сеанса (спрашивал советов по руководству)
77. Вы даете неправильные советы коллегам, чтобы лучше них выглядеть на отчетном совещании.
78. Code review начинается за неделю до выпуска продукта
79. Планы на тестирование определены как “Если будет время”
80. Клиент не хочет говорить о требованиях к проекту, не получив плана работ.
81. Начальство не видит юмора в комиксах про Дильберта

82. You start noticing your boss’s poker tells during planning poker (непереводимо!)
83. Вы начинаете задумываться о том, не является ли 12-ти часовая работа в Макдоналдсе более перспективной с точки зрения карьеры
84. Все проблемы с производительностью решаются покупкой более мощного железа
85. Проект решили выпускать в виде постоянной бета-версии
86. Эвакуатор увез вашу машину со стоянки перед офисом, потому что ее посчитали брошенной.
87. Во время совещаний, посвященных сбору требований, менеджер проекта водит карандашом по бумаге, рисуя сложные геометрические узоры
88. Вы занимаетесь парным программированием в одиночестве.
89. Ваш табель учёта рабочего времени напоминает лотерейный билет “Спортлото”
90. The web developer thinks being 508 means looking good in her Levi Red Tabs (непереводимо!)

91. Вы считаете, что пора лечиться от раздвоения личности, потому как вы являетесь одновременно Робин-гудом, Элвисом, and Эйнштейном
92. Роль профессионального консультанта выполняет подбрасываемая монетка
93. Вы отлично знаете, сколько должно быть ворнингов компилятора, чтобы возникла ошибка ‘Out of Memory’ в вашей IDE
94. В этом списке дважды упомянуто IDE, а вы не знаете, как это расшифровывается
95. Вы копипастили код с The Daily WTF
96. Неработающие юнит-тесты удаляются, потому что они, очевидно, устарели.
97. На конференции вы ездите только чтобы разжиться халявными футболками и поесть бесплатной еды.
98. В отделе QA вас прозвали “Мистер Переполнение Буфера”
99. Вы используете MOSS 2007
100. 90% времени у вас все готово на 90%
101. “А, да, совсем забыл Ммм.., эээ.. тебе тоже нужно будет прийти в воскресенье с утра. Спасибо.”

Источники:

• Оригинальный английский текст
• Русский перевод (RSDN), дополнительная правка – редакции сайта Гильдии
• Русский перевод названия статьи – с сайта seregaborzov.wordpress.com
• Русский перевод термина “Magic 8-ball” (”подбрасывание монетки”) – с сайта it4business.ru

Автор: Сергей Архипенков

Год публикации: 2004

Кто виноват в том, что, спустя 30 лет после объявления «кризиса программирования», компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» [1] пришла к следующим неутешительным выводам.

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

О чем и зачем

Почему эссе? Потому, что этот материал на достаточно частную тему – психологические аспекты управления программными проектами. Потому, что трактовка рассмотренных вопросов отражает субъективный опыт автора и не претендует на полноту.

Для чего написана эта статья? Для того чтобы обнародовать еще одну попытку ответить на традиционные для России вопросы: «кто виноват?» и «что делать?». Вдруг кто-нибудь еще не знает правильных ответов?

Кто виноват в том, что, спустя 30 лет после объявления «кризиса программирования», компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» пришла к следующим неутешительным выводам.

«Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения – на 122%»?

Что делать, для того, чтобы, все-таки, производить необходимые программные продукты с удовлетворительным качеством и в приемлемые сроки?

Начну сразу с ответов.

Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов – объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».

Что делать? Управлять людьми. Успех, а равно и провал, проектов по производству ПО на 100% лежит в области психологии.

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

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

Вспоминается книга по теории вероятностей, в которой было приведено около 200 различных определений понятия вероятности.

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

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

Цели могут быть любые: воспроизведение звука в динамике ПК, расчет траектории полета космического аппарата на Марс, печать годового балансового отчета и т.д. Важно то, что они должны быть определены. Это звучит банально, но сколько бы раз об этом не твердили ранее, по-прежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели.

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

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

Профессиональное программирование (синоним производство программ) – деятельность, направленная на получение доходов при помощи программирования.

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

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

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

Моцарт и Сальери

Гуру программирования Ф. Брукс в 1975 году писал [2]: «Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов». Некоторые психологи, которые работают с программистами, идут дальше и даже утверждают, что программирование – это высшая форма творчества [3].

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

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

Пример из личного опыта. Когда я работал в Центре управления полетами, нам для долгосрочных прогнозов траекторий КА потребовалась более точная модель вращения Земли. Некоторые думают, что Земля равномерно вращается вокруг неподвижной оси со скоростью 1 оборот за 24 часа. Однако, это не так. Земная ось под влиянием притяжения Солнца, Луны и планет совершает в пространстве прецессионное движение и нутационные колебания. В «Астрономическом ежегоднике РАН» регулярно публикуются многолетние данные натурных измерений вращения Земли. Там же публикуется алгоритм построения модели, экстраполирующей это движение. Модель представляет собой разложение угловой скорости по достаточно сложной системе функций. Разложение содержит около сотни членов. Коэффициенты этого разложения подобраны каким-нибудь методом наименьших квадратов по эмпирическим данным. Заявленная точность аппроксимации, если не изменяет память, составляет 10**-10. Там же приводятся результаты расчетов, сделанные по этой модели. С точки зрения программирования, эта задача, на первый взгляд, является тривиальной. Однако, этот случай запомнился мне по двум причинам.
Первая. При разработке этой программы я поставил абсолютный личный рекорд производительности: 2000 SLOC на С++ (отлаженных и оттестированных) за рабочий день (правда, рабочий день продолжался часов 14-16).
Вторая. Я навсегда утвердился в том, что даже простое кодирование готового алгоритма есть процесс творческий. И вот почему. Я собрал в кулак всю свою волю и сконцентрировал все свое внимание, поскольку помимо того, что мне требовалось запрограммировать достаточно сложную систему функций, необходимо было еще безошибочно ввести достаточно много констант, которые содержали по 12 десятичных разрядов (работали без сканеров, не было их тогда). На это у меня ушли первые 8 рабочих часов. Наконец, собрав программу целиком, я достаточно быстро выявил и устранил явные ошибки, которые являлись причиной того, что полученные результаты отличались от искомых в разы. И тут случилась катастрофа. Результаты расчета по моей программе стали почти правильными. Это «почти» заключалось в двух последних десятичных знаках, т.е. относительная ошибка расчета имела величину 10**-8, но абсолютная-то точность отличалась в 100 раз! Каждый программист знает, как сложно искать ошибку в почти правильной программе. Остальные часы я потратил на безуспешные попытки выявить источник ошибок, в основном вычитывая код и проверяя коэффициенты. Выручил меня более опытный коллега, с которым я поделился своими проблемами. Он обратил мое внимание на то, что разрядная сетка представления десятичного числа на компьютере конечна (как будто я сам об этом не знал), а члены разложения по абсолютному значению отличаются на сотни порядков (и это я знал), поэтому складывать их надо, начиная с самых маленьких (а вот это уже «опыт – сын ошибок трудных», которого мне не хватило). После внесения необходимых исправлений я, наконец-то, получил искомый результат. Спасибо Учителям…

Факт 1. Программирование было, есть и останется в обозримом будущем творческой деятельностью.

Творчество неразрывно связано с вдохновением, а это субстанция капризная и непредсказуемая (помните знаменитый сон Д. И. Менделеева, про Периодическую таблицу элементов его имени?). Знаю только, что без вдохновения в программировании не обойтись. И чем сложнее задача, тем труднее извлечь это вдохновение из подсознания. Иногда для этого требуются часы, а иногда недели.

Испытано многократно. Особенно запомнилось решение, которое пришло во сне (до этого сон Д.И. Менделеева мне представлялся историческим анекдотом). Для построения оптимальной орбитальной структуры навигационных спутников требовалось уметь определять на достаточно длительном промежутке времени статистические характеристики навигационного поля. В первом приближении задача сводилась к вычислению как функции времени площади земной поверхности, из которой одновременно можно наблюдать 4 спутника из группировки. Причем, наш заказчик устроил соревнование и поручил эту же задачу еще и коллегам из Брауншвейгского Технического университета. Очевидно, что сначала мы попытались пойти простейшим путем и решить задачу методом прямого перебора на компьютере, разбив поверхность Земли на географическую сетку. Более рациональные методы оптимизации не подошли, поскольку критерий, по которому проводилась оптимизация, представлял из себя довольно «рваную» функцию. Однако, быстро пришлось признать бесперспективность прямого перебора. Для решения этой задачи у нас был всего один Intel 486 и расчет значения критерия оптимальности на 1-ом узле сетки занимал 15 минут. Исходя из полученных оценок, пришлось сделать вывод, что мы ни только не получим решение к обещанному сроку, но и не дождемся его в течение года непрерывных расчетов. Требовалось повысить быстродействие алгоритма вычисления площади кратного покрытия зонами видимости навигационных КА, не менее чем в 100 раз. С этой задачей я промучился недели три, периодически, то отбрасывая ее (вытисняя в подсознание), то снова возвращаясь к ней. Решение пришло во сне. Причем в предыдущий вечер я этой задачей не занимался. Естественно я проснулся от неожиданности и часа 2 потратил на запись сна в виде математических формул. Придя на работу, я за пол дня запрограммировал и отладил изобретенный алгоритм. Всего 100-150 SLOC, не так уж много за три недели. Ну и еще, запомнилось чувство морального удовлетворения и гордости, которое я испытал, когда представлял заказчику полученные результаты. Первым о полученных результатах докладывал немецкий коллега. Они решали задачу прямым перебором, и он долго рассказывал о том, сколько им для этого потребовалось недель непрерывных расчетов и сколько процессоров Pentium они задействовали параллельно. Затем он представил полученный результат. Он отметил, что он не может дать объяснение, почему получилось именно такое орбитальное построение – так рассчитали компьютеры. Свое выступление я начал словами: «Мы получили очень похожий результат, только он на 15% лучше и я вам сейчас объясню, почему оптимальное орбитальное построение должно быть именно таким». Это был, безусловно, мой звездный час. В конце концов, мы с немецким коллегой объединили наши результаты и опубликовали их в совместном докладе на международной конференции по навигации.

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

Случай из жизни об эстетике настоящего мастерства. Еще не так давно в нашей удивительной стране не было возможности заработать своим умом. Я имею в виду законные способы. Поэтому в мои студенческие годы существенным подспорьем была летняя работа в строительных отрядах, которая позволяла за 2 месяца увеличить доходную часть годового семейного бюджета в несколько раз. Так вот, мой друг, почти двухметровый Геракл, мастер спорта по водному поло был профессиональным копателем ям и траншей. Он сознательно специализировался в этой области, поскольку рассматривал это как тренировку. Его работа была близка к идеалу, в ней не было ни одного лишнего движения. Местные крестьяне, возвращаясь после трудовой смены, любили присесть недалеко от места его работы, покурить и с восхищением понаблюдать за искусством ямокопания. Но думаю, что, вряд ли, они смогли бы оценить эстетику программного решения задачи расстановки восьми ферзей на шахматной доске.

Программирование это не наука. Наработки математиков в области логики, теории информации, численных методов, реляционной алгебры, теории графов и некоторых других дисциплинах на долю процента не покрывают сложность программистских задач. В программировании нет системы знаний о закономерностях создания программ. Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной. Хотя в программировании уже накоплен определенный опыт провалов, который может позволить искушенному программисту увидеть в архитектуре новой системы антипаттерны – источники серьезных будущих проблем. Но не более того. Существующее состояние Software Engineering напоминает мне большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых у меня никогда в будущем не будет. Завтра в моей новой системе будут другие вычислительные машины, технологии, языки программирования, инструменты и окружающее ПО, новые проблемы взаимодействия с которыми мне обязательно придется решать.

Факт 2. Программирование – не искусство и не наука – это ремесло. Сегодня мы так же далеки от индустриальной разработки программ, как и 50 лет назад.

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

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

Хотите, меряйте производительность в строках исходного кода, хотите – в функциональных точках.

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

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

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

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

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

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

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

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

Факт 4. В обозримом будущем большая часть проектов разработки ПО будет завершаться со срывами сроков и перерасходом бюджета, часть проектов не будет завершена вообще, и только приблизительно 20% проектов будут укладываться в первоначальный бюджет и сроки.

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

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

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

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

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

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

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

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

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

Образно можно сказать, что программист должен сочетать в себе легкость и полет таланта Моцарта с усидчивостью и скрупулезностью Сальери.

Описанные психологические особенности программистского творчества привели к тому, что наиболее успешными программистами становятся люди, которые обладают выраженным аутистическим складом мышления. Аутистическое мышление (от древнегр. autos — сам) — замкнуто-углубленный тип личности. Применительно к личности используется также термин «шизоид».

Факт 5. Аутист-шизоид – наиболее распространенный среди программистов тип личности.

Мы, программисты, все немного шизоиды.

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

По неофициальным данным, в компании «Майкрософт» число аутистов среди сотрудников составляет от 5 до 20%. Аутизм это не болезнь! Мы просто не такие как остальное большинство, которое не готово сутками проводить время за мониторами компьютеров и получать от этого удовольствие. И, пожалуйста, не надо нас лечить и переделывать! Это удача для человечества, что рождаются аутисты. Так, по результатам исследований процент гениев (то есть людей, способности которых существенно выше средних) среди людей с диагнозом “аутизм” достигает 20%. В то время как среди так называемых “нормальных” людей он не превышает 0,001%. Психологи считают аутистами таких известных исторических личностей, как Ньютон, Эйнштейн, Гегель, Фрейд, Юнг, Агата Кристи и даже любимый Пушкин.

Ну, как здесь удержаться еще от одной цитаты по поводу Моцарта и Сальери в одном лице: «Пушкин сам был Моцартом в искусстве, и он знал это; но во всем другом он был Сальери…» (М. О. Гершензона «Мудрость Пушкина», Москва, 1919 год). А аутизм тогда еще даже не придумали…

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

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

“Аутист видит в компьютере близкое существо, – считает Эми Клин, ассистент профессора Центра детского развития при Медицинской школе Йельского университета. – Компьютеры бескомпромиссны и негибки, а люди, с которыми нам приходится иметь дело, отличаются теми же качествами”. Аутизм ограничивает способность таких людей к общению, но вознаграждает их даром невероятной концентрации и творческой продуктивности [5].

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

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

Это следствие закона больших чисел. Главное, чтобы оценки элементарных работ были независимы между собой. Например, закон больших чисел не сработает, если все ваши оценки поражены оптимизмом.

В моей практике ошибка суммарной трудоемкости проекта составляет не более 30%. Производительность участников проекта также может отличаться в разы, но средняя производительность по всем участникам вещь достаточно стабильная и прогнозируемая. По моему опыту оптимальное с точки зрения макроуправления количество человек в группе разработчиков – 4-6. Если проект большой, то необходимо провести его архитектурную декомпозицию на минимально связанные подсистемы, разработку которых следует вести отдельными группами со своими руководителями и планами.

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

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

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

Факт 6. Цель управления программным проектом лежит в области психологии.

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

Факт 7. Средства управления программным проектом лежат в области психологии.

То, что важным фактором программистского проекта является психология, начали писать более 30 лет назад, книги Венберга [6] и Де Марко [7] ничуть не утратили своей актуальности и сегодня. Но понимание того, что психология является решающим фактором успеха или неуспеха проектов разработки ПО, пришло только в последние годы. Радикальным решением проблем кризиса программирования поочередно объявлялись поиск лучшего языка программирования (1960-е годы), технологии программирования (1970-е годы), инструментария программирования (1980-е годы), системы качества (1990-е). И только центральному и ключевому фактору – фигуре самого программиста – внимание почти не уделялось [8].

«Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте». Это вывод Алистэра Коуберна [9], который базируется на результатах анализа очень разных программных проектов, реализованных за последние 20 лет. Проекты отличались друг от друга по количеству программистов, по срокам выполнения, по применяемой технологии – от самой тяжелой (CMM 5-го уровня) до полного ее отсутствия. Коуберн не обнаружил статистически значимой корреляции успеха или неуспеха проекта ни с одной из перечисленных характеристик.

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

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

Управляем катастрофой

До сих пор мы только констатировали объективно существующие трудности и проблемы, которые связаны с разработкой программных проектов. Читатель давно уже в праве ожидать от нас ответа на вопрос «что делать?». Короткий ответ – управлять людьми, которые вовлечены в проект. И круг таких людей достаточно широк. Оставшаяся часть статьи будет посвящена управлению программными проектами, а если точнее, то работе менеджера проекта 14 по управлению людьми, как внутри проекта, так и вне него. Начнем по порядку.

Над входом в храм Аполлона в Дельфах написано «Познай себя». Начинайте проект с себя. Вы – менеджер проекта. Если это ваш первый проект, то поздравляю вас с приобщением к благородной профессии. «Управление благородно по своей сути. Менеджмент ничего не имеет общего с деятельностью бюрократа, сидящего наверху. Менеджер делает самую необходимую в компании работу. Благодаря нему становится возможным выполнение самых грандиозных проектов. Нет более почетной работы, чем та, которую делает настоящий менеджер» [10].

Но даже, если у вас сверхвысокий IQ , это не поможет вам в управлении людьми. Чтобы управлять людьми, нужны совсем другие качества. Менеджер должен обладать сверхвысоким EQ – коэффициентом эмоционального интеллекта (Emotional Intelligence). Вот три компонента эмоционального интеллекта:

1. Понять свои собственные чувства.
2. Научиться управлять ими.
3. Научиться распознавать эмоции других и управлять ими.

Загляните в себя, есть ли у вас необходимые качества. В силу аутистической природы программирования хороший программист, как правило, этими качествами не обладает. Из хороших программистов выходят, как правило, плохие менеджеры проектов. Аутисты предпочитают не общаться с другими людьми и не испытывать потребности в таком общении, они не интересуются другими людьми, стремятся быть в одиночестве. Недостаточный EQ и шизоидные наклонности могут привести к параноидальному стилю управления: чрезмерной бдительности, подозрительности, озабоченности скрытыми мотивами, повышенной тревожности [11]. Такие руководители считают подчиненных некомпетентными симулянтами, которые не любят свою работу и стремятся избежать ее, если у них есть такая возможность. Руководители подобного типа практикуют строгий контроль через активное личное наблюдение, формальные правила и ограничения. Ведут себя агрессивно, в особенности с теми подчиненными, которые высказывают свое мнение. «Кнут и пряник» для них единственные инструменты мотивации подчиненных.

Метод «Кнута и Пряника» – алгоритм, описанный в известной монографии Кнута и позднее модифицированный русским программистом Пряником. Программистский фольклор (И. Одинцов, «Профессиональное программирование. Системный подход», BHV, Санкт-Петербург, 2002)

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

В истории нашей удивительной страны был такой опыт – сталинские «шарашки».

Если у вас недостаточный EQ , не отчаивайтесь. В отличие от IQ , который формируется в ранней молодости и затем практически не меняется, EQ можно повышать на протяжении всей жизни.

Призыв 1. Повышайте свой эмоциональный интеллект, если вы хотите руководить успешными программными проектами.

Поймите свои собственные мотивы. Ответьте себе на вопрос, почему вы беретесь именно за этот проект. Если единственным ответом является: «Потому, что мне поручили», знайте, что катастрофа не за горами. Помните, что вам предстоит поставить на кон свою репутацию и вложить в проект душу. «Вполнакала проекты не делаются» – очень точная формулировка И. Ставинского [12]. Поэтому нужно четко понимать, в чем будет ваш выигрыш в случае успешного завершения проекта.

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

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

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

Призыв 3. Продавайте свой проект от начала до завершения работ.

Понимание этого правила пришло ко мне достаточно давно, но формулировку его я заимствовал у Тома Питерса [13].

Долгое время, работая в научном коллективе, я не мог понять, почему умным и талантливым ученым, раз за разом, урезают финансирование очень перспективных направлений, а другие деятели от науки получают ассигнования на все новые и новые «мыльные пузыри». Так продолжалось до тех пор, пока мне не попалась фраза, приписываемая великой Раневской: «Не важно, милочка, что Вы из себя представляете. Важно, что о Вас говорят». Эта истина все расставила по своим местам.

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

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

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

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

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

И если уж речь зашла о руководстве, то уместно привести здесь еще одно правило.

Призыв 4. Не позволяйте руководству принимать других решений в вашем проекте, кроме двух: остановить проект или сменить менеджера.

По всем остальным вопросам в проекте принимать решения должен менеджер, а руководство вправе лишь высказывать свои рекомендации. Если это не так, то вы идете к катастрофе. Джоель Спольски [14] так описывает последствия вмешательства руководства: «…Руководители разных уровней с удовольствием запускали руки в каждый стряпающийся пирог, раздавая указания направо и налево в стиле, который я стал называть порулил и убегай. «Порулил и убегай» потому, что начальники появлялись на горизонте вероломно, отдавали глупые распоряжения как именно все, черт побери, должно быть сделано, без какого-либо предварительного размышления, и покидали комнату, оставляя всех собирать осколки». Если вам не удалось оградить проект от подобных вмешательств, вам, скорее всего, придется собирать осколки до его завершения.

А теперь о самом главном в управлении программным проектом – управлении проектной командой. Управлять людьми – значит побуждать их к правильным действиям. А побуждать их можно, только управляя мотивами. Согласно теории мотивации для того, чтобы человек совершил какое либо действие он должен испытывать некую потребность и предполагать, что, выполнив это действие, он в той или иной степени эту потребность удовлетворит. Поэтому управление мотивами осуществляется, как правило, в двух направлениях: 1) формирование правильных потребностей; 2) формирование правильной оценки степени их удовлетворения.

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

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

Об этом же пишет Э. Йордан [15]: «Деньги, выгода, комфорт и тому подобное являются факторами «гигиены» – их отсутствие вызывает неудовлетворенность, однако они не могут заставить людей полюбить свою работу и дать им необходимые внутренние стимулы. Что действительно может дать такие стимулы, так это ощущение значительности достигнутых результатов, гордость за хорошо выполненную работу, более высокая ответственность, продвижение по службе и профессиональный рост – все то, что обогащает работу». Об этом же более 30-ти лет назад писал Вейнберг [6]: «Творчески работающему программисту присуща глубокая внутренняя мотивация». На мой взгляд, это еще одно следствие аутистической природы программирования.

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

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

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

Команда успешного проекта это команда победителей. Успешный проект должен сделать победителем всех его участников [16].

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

Управление командой начинается с ее формирования.

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

Вроде все просто, однако, это не так. Сможет это не только знает и умеет, но еще и захочет.

Я, например, не знаю, как мотивировать суперпрограммиста переписать библиотеку DLL с C++ на Java, если эта работа больше чем на 2-3 дня.

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

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

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

При отборе кандидатов только очное интервью «глаза в глаза» и личный опыт работы с людьми позволит вам создать эффективную программистскую команду. О практике проведения интервью могу рекомендовать работы [17, 18], в которых изложены подходы, во многом совпадающие с моим опытом.

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

Призыв 8. Не загружайте программистов несвойственной для них работой.

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

Теперь, когда цели определены, команда собрана, пора приступать непосредственно к созданию программной системы. Поскольку, разработка ПО, как мы отмечали выше, корпоративная игра, то первое, что мы должны сделать, это договориться о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды в проекте. Повторим вслед за автором [19]: «Каждому проекту своя технология». И чем больше и ответственней проект тем «тяжелей» должна быть технология. Технология может меняться вместе с развитием и ростом проекта, но на каждом этапе она должна быть определена и описана . Бессмысленно спрашивать с программиста ответа за то, что ему не поручено.

Существует удобная для руководства формула: «ты в ответе за все». Для того, чтобы избавиться от неугодного работника – удобно, но организовать эффективную работу невозможно.

Призыв 9. Договоритесь о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды.

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

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

1. Получает удовольствие от своей работы, гордится ее результатами и стремится, чтобы эти же чувства испытывали все коллеги.
2. Четко осознает свои личные и общие цели, понимает их взаимообусловленность, настойчиво стремится к их достижению.
3. Занимает активную позицию, стремится расширить свою ответственность и увеличить личный вклад в общее дело.
4. Постоянно приобретет новые профессиональные знания и опыт, выдвигает новые идеи, направленные на повышение эффективности достижения общих целей, добивается распространения своих знаний, опыта и идей среди коллег.
5. Уверен в себе и в своих коллегах, объективно оценивает их достижения и успехи, внимательно относится к их интересам и мнениям, активно ищет компромиссы при противоречиях.
6. Является оптимистом, при этом твердо знает, что окружающий мир несовершенен; воспринимает каждую новую проблему, как дополнительную возможность подтвердить собственный профессионализм в своих глазах и во мнении коллег.

Основные усилия по мотивации участников проектной команды я направляю на то чтобы стимулировать правильное поведение.

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

Очень важно, чтобы каждый член проектной команды знал, или хотя бы имел при желании возможность узнать о проекте не меньше, чем его менеджер. И не стоит ничего скрывать, ни проблем с заказчиком, ни разногласий с руководством. Трудно ожидать самостоятельные, нестандартные и эффективные решения от человека, у которого «шорами» ограничено видение проблемы.

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

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

Де Марко [7] по поводу одной из своих коллег говорил: «я слабо представляю, какой вклад она вносит в мой проект, но за 12 лет ее работы в компании все проекты, в которых она участвовала, заканчивались успехом». За ответом направляю к его книге.

Основным инструментом управления у менеджера является план работ. Как мы уже отмечали ранее, работа по проекту должна вестись итерационно, а каждая итерация должна наращивать функциональность, которая определена требованиями к системе. Наиболее приемлемое время итерации от 2 до 6 недель. Именно на этот срок должно осуществляться детальное планирование. Поскольку в реализацию попадают только хорошо проработанные системные требования, то можно добиться достаточно высокой точности плана. Трудоемкость элементарных работ детального плана должна составлять от 4 до 20 часов при расчете на среднего программиста. Каждая итерация должна заканчиваться коллективным анализом «Lessons Learned»: удалось ли достичь поставленных целей, какие проблемы пришлось решать, как реорганизовать технологические процессы для более эффективной работы, – и детальным планированием следующей итерации.

Макро-показателей, по которым менеджер должен осуществлять мониторинг проекта, не так уж и много:

• Процент реализованных функциональных требований от общего числа.
• Объем затраченных на разработку человеко-часов.
• Количество строк исходного кода.
• Количество ошибок выявленных и закрытых.

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

Программисты это, как правило, очень трудолюбивые люди (порой до фанатизма), с глубокой внутренней мотивацией к программистской работе. Как правило, я не вмешиваюсь в работу конкретного программиста, если срок выполнения поставленной задачи не превышен в 2-3 раза по сравнению с оценками в детальном плане. Так я определил для себя допуск на разброс траекторий на молекулярном уровне. Это оправдано, поскольку некоторые задачи решаются в разы быстрее, и на макро-уровне проект продвигается в соответствии с планом. Но если на микро- уровне возникают существенные отклонения от плана, это служит поводом для анализа причин неэффективной работы программиста.

Для эффективной работы программисту необходимо и достаточно выполнение четырех условий:

1. Понимание целей работы.
2. Желание ее сделать.
3. Умение ее делать.
4. Возможность ее сделать.

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

Мне лично не приходит в голову интересоваться тем, насколько элегантна и оптимальна схема моего телефона, пока он удовлетворяет моим требованиям.

Призыв 11. Нацеливайте программистов на правильное решение задачи максимально быстрым способом.

Опыт свидетельствует, что более чем в 90% случаев ее не придется переделывать. Если работа вашей подпрограммы занимает только 1% общего времени выполнения, то, затратив сколько угодно времени на оптимизацию ее алгоритма, вы не добьетесь улучшения системных характеристик более чем на 1%. Такой выигрыш вряд ли стоит того, чтобы тратить время на оптимизацию. Со всеми остальными программистским наворотами дело обычно обстоит так же.

О мотивации программистов я уже говорил, поэтому добавлю лишь одно правило.

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

Ключевое слово здесь «хочет», заметьте, не «может», а именно «хочет».

Из нашей истории. Рассказывают, что когда Александр I лично управлял сражением при Аустерлице в 1805 году, он послал одного из своих адъютантов на левый фланг сражения, чтобы быстро понять, что там происходит. Прошел не один час, пока адъютант вернулся с удалым блеском в глазах, весь перемазанный, в изодранном мундире и с саблей наголо (явно нашел, где ввязаться в стычку с неприятелем). Все окружающие втянули голову в плечи, ожидая «гром и молнии» от императора, но он только сказал: «Я и сам дурак, что тебя послал».

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

Еще раз напомню, что доминирующие потребности программистов находятся в верхней части пирамиды Маслоу, поэтому пинать и пугать их – занятие совершенно бесперспективное. Для начинающих программистов хорошим стимулом является само участие в успешном проекте (может быть в первом в их жизни), возможность учиться ремеслу у более опытных и искушенных коллег. Для опытных программистов хорошим стимулом может служить новизна и востребованность на рынке труда технологий, используемых в проекте (потребность безопасности). Для них также существенны сложность и самостоятельность (потребность самоуважения) в решении поставленных задач. Как правило, я стремлюсь ставить задачи примерно в 1,5 раза сложнее, чем те которые данный программист решал ранее. Для опытного программиста каждая новая задача должна предоставлять дополнительную возможность доказать свой профессионализм. Сложнее дело обстоит с суперпрограммистами. Их основным мотивом, как правило, служит самоактуализация, поэтому они стремятся решать задачи, которые до них еще никто не делал. Оптимальное их место в проекте – системная архитектура и реализация архитектурно значимых компонентов системы (скелета системы). При правильной мотивации оставшаяся часть их потребностей принадлежности и самоуважения реализуется через обучение коллег и передачу им своего опыта. На эту деятельность следует планировать до 50% времени суперпрограммиста. Суперпрограммист в проекте должен играть роль технического лидера, который ведет за собой остальных участников под лозунгом: «Делай как я!». Он всегда должен быть готов продемонстрировать, как можно решить любую задачу в проекте.

Третье условие эффективной работы программиста – умение делать порученную работу. Как правило, начинающие программисты мало что умеют. Их главный метод программирования – копирование чужих образцов (Copy/Paste). Это естественный путь обучения ремеслу. Вспомним художников, которые учатся, копируя полотна великих мастеров. Важно, чтобы образцы для подражания были достойными. Поэтому целесообразно поручать задачу паре программистов, в которой один из них выступает наставником, а другой подмастерьем, перенимающим опыт.

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

Дополнительно, парная ответственность за исходный код страхует ваш проект от негативных последствий неожиданного ухода одного из специалистов.

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

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

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

И о последнем условии эффективной работы – программисту должна быть предоставлена возможность сделать порученную работу. Здесь речь идет не о тривиальном наличии компьютера и инструментов разработки.

В общем-то, даже доступ программиста к компьютеру необязателен. Когда мое поколение начинало, мы писали свои программы на бланках и сдавали их операторам в вычислительный центр. Оттуда же, спустя сутки, получали листинг с результатами работы программы. «Семь раз отмерь, один раз запрограммируй», – было главным правилом нашей работы. Сегодня, неограниченный доступ к компьютеру приводит к тому, что начинающие программисты «думают руками»: бесконечно экспериментируют с исходным кодом, пока программа не заработает приблизительно правильно. Полученный таким образом код очень часто совершенно не читаем, не сопровождаем, а правильно работает только в том случае, для которого программист проводил отладку. Как-то мне пришлось с одним из моих менее опытных коллег разбираться в его программе, на которую у него ушло две недели, вместо 20 запланированных часов, а программа по-прежнему работала почти правильно. Кода было написано раза в три больше, чем это предполагалось. Поражало изобилие загадочных переменных flagN и немыслимое количество условных операторов типа “if (flag21==true)”. Работая за одним компьютером, мы сделали эту задачу за день. Запомнилось искреннее удивление моего коллеги: «А что, так можно?». – «Так нужно», – терпеливо отвечал я. Правда, это опять о необходимости обучения.

И не о наличие отдельного кабинета, о котором пишет Де Марко.

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

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

Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов свободы. Бессмысленно заставлять программистов работать больше, устраивать сверхурочные авралы и субботники. Работать больше, это совсем не значит – работать продуктивнее. Скорее наоборот. Излишнее давление и суета приводят к непродуманным решениям и многочисленным последующим переработкам. «Хорошо управляемое предприятие – это спокойное место. Зато «фабрика, отличающаяся “кипучей” деятельностью и “трудовым героизмом” работников, который бросается в глаза любому посетителю, является на самом деле плохо управляемой». Это не я сказал, это говорит управленец «в законе» [20].

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

Вспоминаются молодые годы, когда причины большинства ошибок, которые не удавалось локализовать в течение многочасовых ночных поисков, всплывали в голове, спустя некоторое время после того, как я, отчаявшись, наконец, бросал данную задачу. Обычно мне хватало времени только для того, чтобы дойти от места работы до проходной. Поэтому, если я замечаю систематические сверхурочные переработки кого-либо из сотрудников, то, как правило, обращаюсь к нему со следующими словами: «Уважаемый коллега, Вы не справляетесь с работой в рабочее время? Давно бы сказали мне, я бы нашел Вам задачу полегче». Сверхурочные работы не только не эффективны. Я уже давно принял истину: мы живем не для того, чтобы работать, а работаем для того, чтобы жить. Многое в жизни бывает только раз: молодость, первая любовь, маленькие дети. Пренебрежение к личной жизни приводит, как правило, к стрессам и неизбежным последующим проблемам в профессиональной сфере.

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

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

Призыв 14. Не мешайте программистам. Доверяйте им. Обеспечивайте им свободу творчества. Предоставляйте им право на ошибку. Не оказывайте на них давление.

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

Важнейшим неформальным макро-показателем состояния проекта являются коммуникации, их качество и количество. Если угодно, то по моей экспертной оценке коммуникации, включая наставничество и консультации, в успешном проекте занимают 30-50% рабочего времени. Только благодаря эффективным коммуникациям можно достигнуть синергетического эффекта, который отличает команду от просто группы. Мне неоднократно приходилось убеждаться, что освоение новой информационной технологии парой программистов, которые осуществляют интенсивный обмен знаниями, происходит минимум в 3 раза быстрее, чем в случае, когда ту же работу выполняет один программист. Недостаточное количество коммуникаций свидетельствует, как правило, об отсутствии команды, каждый углублен в свою задачу и не интересуется, что делают его коллеги. В результате будет сделано не то, что нужно, а то, что будет сделано, вряд ли удастся интегрировать в единую систему. Если через день после получения недельного задания у программиста не возникло уточняющих вопросов, жди беды. Скорее всего, он с головой ушел в «проектирование дома, забыв уточнить, для чего он предназначен» [18]. Учитывая шизоидную несклонность программистов к общению, менеджеру требуется прилагать значительные усилия для того, чтобы мотивировать необходимый уровень коммуникаций.

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

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

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

Призыв 15. Наблюдайте за коммуникациями в проекте.

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

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

Резюме. Растите профессионалов

Работа менеджера проекта подобна труду садовника.

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

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

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

«Что посеешь, то и пожнешь» – этот закон одинаково применим как к труду садовода, так и к труду менеджера проекта. Пренебрежительное отношение к людям породит лишь ответное пренебрежение. Вложите в людей часть своей души, и вам воздастся сторицей.

P.S.

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

Литература

1. Jim Johnson. «Chaos: The Dollar Drain of IT Project Failures. Application Development Trends», January 1995. Standish Group.
2. Брукс Фредерик, “Мифический человеко-месяц, или Как создаются программные комплексы”, Пер. с англ., СПб., Символ-Плюс, 1999.
3. Richie O’Bower, «Programming as the best creative specialty», 1997. (русский перевод Сергей Кашменский, 1999 года).
4. Журенков К. «Аутизм — болезнь ХХI века?»
5. Немира В. «Гении тоже страдают задержкой умственного развития», Utro.ru, № 162 (233), 2000
6. Gerald Weinberg, «Psychology of Computer Programming», Van Nostrand Reinhold, 1971
7. Tom DeMarco, «Timothy Lister, Peopleware : Productive Projects and Teams», Dorset House, 1987
8. Белая О. А. и др. «Психология программирования: человеко-машинный аспект информационных технологий», СПбГУ, 2004
9. Алистэр Коуберн, «Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения», Humans and Technology, Октябрь, 1999
10. Кэтлин Мелимука, «Разговор с Томом де Марко», Computerworld, #05/1996
11. М. Ка де Ври, «Мистика лидерства. Развитие эмоционального интеллекта», Альпина паблишер, Москва, 2003.
12. И. Ашманов, «Правила Ашманова», 2002
13. Tom Peters, «The Wow Project», Fast Company Magazine, Issue 24,May 1999
14. Joel Spolsky, «Command and Conquer and the Herd of Coconuts», March, 2000 (русский перевод)
15. E. Yourdon, «Death March», The Complete Software Developer’s Guide to Surviving “Mission Impossible” Projects, Prentice Hall, 1997
16. B. W. Boehm, «Theory-W Software Project Management: Principles and Examples», IEEE Transactions on Software Engineering, Vol. 15, No. 7, July 1989
17. Эд Салливан, «Время – деньги. Создание команды разработчиков программного обеспечения», Русская редакция, Москва, 2002.
18. Joel Spolsky, «The Guerrilla Guide to Interviewing», март 2000 (русский перевод) и октябрь 2006 года)
19. А. Коуберн, «Каждому проекту своя методология», Humans and Technology Technical Report, TR 99.04, Oct.1999 (русский перевод)
20. Питер Ф. Друкер, «Эффективный управляющий».

Оригинал статьи

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

Программа курса

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

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

Процессы

• Почему проваливается или испытывают серьезнейшие трудности большинство ИТ проектов? Скрытые причины провалов. Что и как можно выявить на ранней стадии, чтобы не допустить провала проекта.
• Как привести к успеху проект с нечеткими требованиями, рискованными технологиями и недостаточно компетентными программистами, другими «технарями» и менеджерами проектов?
• Формулировка целей и составление экономической модели проекта – фундамент успешности проекта
• Пять простых практических способов оценки технического задания
• Постановка проектных процессов. Главные риски программных проектов и способы противодействия им.
• Долгосрочное планирование – практические способы сформулировать стратегию развития проектов на 1-3 года. Обоснование работ и бюджета на будущие периоды.
• Использование стандартов, выбор и адаптация методологии на проект, а также как подружить методологию со стандартами.
• Выбор и контроль субподрядчиков – как не получить кота в мешке

Человеческий фактор

• Работа в матричной структуре, когда проект затрагивает интересы смежных подразделений.
• Человеческий фактор: как управлять неуправляемым
• Задачи бизнеса: как получить команду инженеров, которая думает о бизнесе. Семь признаков эффективной команды.
• Мотивация разработчиков: почему традиционные подходы работают так плохо? Что держит ИТ людей на работе и от чего у них зажигаются глаза. Бонусные системы, которые работают.
• Демотиваторы: десять реальных способов избавиться от лучших инженеров (при этом они уйдут внезапно, с максимальным вредом для проекта)
• Фильтр на вход и фильтр на выход: подбор правильных людей для работы в ИТ проекте. Работа с «незаменимыми» и «суперзвездами».
• Как найти эффективного менеджера ИТ проекта. Качества и компетенции, которыми должен обладать этот ключевой человек.

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

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

Авторы и ведущие

Курс проводят основатели Гильдии менеджеров программных проектов:

Сергей Архипенков – ведущий российский эксперт по управлению программными проектами (с более чем 30-летним опытом в ИТ, включая работу в Центре Управления Полетами, компаниях Luxoft, CBOSS, R-Style), автор множества известных книг и статей по управлению командами и проектами.

Алексей Баранцев – эксперт в области тестирования программного обеспечения, главный редактор портала www.software-testing.ru, руководитель отдела коммерческих разработок в Институте системного Программирования РАН.

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

Александр Орлов – эксперт в области мотивации ИТ инженеров. Основатель проекта «Клуб Успешных Менеджеров Программистов». Автор книги “Секреты управления программистами”. В прошлом – менеджер в компаниях Intel и Sun Microsystems, Inc.

Вячеслав Панкратов – эксперт в области управления проектами и тестирования ПО. Руководитель учебного центра Luxoft Украина. Главный редактор портала www.it4business.ru. В прошлом – директор киевского офиса компании Яндекс.

Денис Петелин – независимый эксперт и тренер по программной инженерии и управлению проектами. Свыше 3000 слушателей, в том числе из Intel, Microsoft, Yandex, Checkpoint, IBS, EPAM. Основатель и совладелец компании-разработчика и консалтинговой компании.

Сурен Самарчян – руководитель департамента управления проектами в компании Иннова Системс. Президент Гильдии менеджеров программных проектов. Эксперт в области гибких методологий разработки, таких как Lean и Kanban.

Асхат Уразбаев – ведущий российский эксперт в области гибких методологий разработки ПО. Основатель сообщества Agile Russia. Совладелец консалтинговой компании ScrumTrek.

Этот курс можно назвать уникальным в полном смысле этого слова:

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

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

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

Место проведения

Курс пройдет 27-28 марта 2010 в гостинице Мариотт Гранд Отель по адресу: г. Москва, ул. Тверская, 26 (схема проезда).

Как записаться на курс

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

Не пропустите ключевое событие марта 2010 – курс «Промышленная разработка и эксплуатация ПО: управление и контроль»!

Для участия в курсе заполните, пожалуйста, форму регистрации:

cforms contact form by delicious:days

Помимо основных разделов о Целях и Программе Гильдии, а также признанных экспертах, основавших Гильдию и руководящих ее деятельностью (информация, которая присутствовала и на “старом” сайте), сайт Гильдии теперь содержит новый раздел – Новости – содержащий анонсы мероприятий, которые Гильдия планирует провести в ближайшее время, а также архив новостей о мероприятиях, которые проведены под эгидой Гильдии в прошлом 2009 году. Отдельный интерес для сообщества представит еще один новый раздел – Библиотека – в котором будут накапливаться наиболее интересные и полезные материалы менеджерской направленности, причем как перепечатки уже известных статей, так и эксклюзивные материалы экспертов Гильдии и других признанных специалистов отрасли.

Вот как прокомментировал событие один из соучредителей Гильдии Дмитрий Башакин, который руководил проектом по запуску новой версии официального сайта организации:

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

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

Мы приглашаем всех, для кого тема управления программными проектами представляет профессиональный интерес, внести посильный вклад в развитие нашего сайта – комментариями к материалам, предложениями по форме, структуре и содержанию сайта, материалами для публикации (в том числе ссылками на профильные материалы, опубликованные на других ресурсах) – всем, что может способствовать решению главной цели, которую ставит перед собой команда проекта “Сайт Гильдии”: сделать так, чтобы наш сайт стал заметным ресурсом русскоязычной части Интернета по управлению проектами по разработке ПО.

Ждем Ваши предложения по адресу: Info.SPMGuild@gmail.com

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

Семинар провел Денис Петелин, признанный эксперт в IT-индустрии. Известный автор и ведущий курсов по программной инженерии и управлению проектами. Свыше 3000 слушателей, в том числе из Intel, Microsoft, Yandex, Checkpoint, IBS, EPAM. Основатель и совладелец компании-разработчика и консалтинговой компании.

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

Участники могут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC09.

Скачать презентацию

Предлагаем Вашему вниманию видеокаст выступления Дениса:

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

Приходите, будет интересно!

Подробнее о семинаре

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

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

Докладчик: Денис Петелин, признанный эксперт в IT-индустрии. Известный автор и ведущий курсов по программной инженерии и управлению проектами. Свыше 3000 слушателей, в том числе из Intel, Microsoft, Yandex, Checkpoint, IBS, EPAM. Основатель и совладелец компании-разработчика и консалтинговой компании.

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC09.

Время проведения: 18:00 – 21:00
Место проведения: компания R-Style, ул. Пришвина, д.8, корп.2, 1-й этаж, ауд. 117.
Схема проезда

Участие в семинаре бесплатное при условии предварительной регистрации.

Регистрация на семинар закрыта.