Гильдия менеджеров программных проектов » Карьера http://spmguild.org Сайт Гильдии менеджеров программных проектов Tue, 11 Oct 2011 11:34:24 +0000 ru hourly 1 http://wordpress.org/?v=3.2.1 Состоялся семинар / вебинар С.Калканова «Построение карьеры в области разработки ПО» http://spmguild.org/news/732/ http://spmguild.org/news/732/#comments Fri, 04 Feb 2011 21:55:45 +0000 admin http://spmguild.org/?p=732 01 февраля 2011 в рамках совместной инициативы Гильдии и Локальной группы по интересам «Управление проектами в ИТ и телекоммуникациях» московского отделения американского Института управления проектами (PMI) состоялся семинар Станислава Калканова «Построение карьеры в области разработки ПО«.

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

Семинар провел Станислав Калканов, директор Центра Качества компании Люксофт. Должностные обязанности: планирование, управление и выполнение работ по совершенствованию производственных процессов и обеспечению контроля качества процессов в соответствии с требованиями стандарта ISO 9001 и 5-ого уровня зрелости модели CMMI в ведущей Восточно-Европейской компании – разработчике заказного ПО (более 2 500 сотрудников).

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

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

Скачать видеокаст

]]> http://spmguild.org/news/732/feed/ 0 Анонсирован семинар / вебинар С.Калканова «Построение карьеры в области разработки ПО» http://spmguild.org/news/726/ http://spmguild.org/news/726/#comments Mon, 31 Jan 2011 21:28:39 +0000 admin http://spmguild.org/?p=726 01 февраля 2011 в рамках совместной инициативы Гильдии и Локальной группы по интересам «Управление проектами в ИТ и телекоммуникациях» московского отделения американского Института управления проектами (PMI) состоится семинар Станислава Калканова «Построение карьеры в области разработки ПО«.

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

Докладчик: Станислав Калканов, директор Центра Качества компании Люксофт. Должностные обязанности: планирование, управление и выполнение работ по совершенствованию производственных процессов и обеспечению контроля качества процессов в соответствии с требованиями стандарта ISO 9001 и 5-ого уровня зрелости модели CMMI в ведущей Восточно-Европейской компании – разработчике заказного ПО (более 2 500 сотрудников).

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

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

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

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

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

]]> http://spmguild.org/news/726/feed/ 0 С.Архипенков. Психология управления программными проектами http://spmguild.org/lib/533/ http://spmguild.org/lib/533/#comments Sun, 07 Feb 2010 14:57:44 +0000 admin http://www.spmguild.ru/?p=533 О чем и зачем
Почему эссе? Потому, что этот материал на достаточно частную тему – психологические аспекты управления программными проектами. Потому, что трактовка рассмотренных вопросов отражает субъективный опыт автора и не претендует на полноту.
Для чего написана эта статья? Для того чтобы обнародовать еще одну попытку ответить на традиционные для России вопросы: «кто виноват?» и «что делать?». Вдруг кто-нибудь еще не знает правильных ответов?
Кто виноват в том, что, спустя 30 лет после объявления «кризиса программирования», компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» пришла к следующим неутешительным выводам?
«Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения – на 122%»
Что делать, для того, чтобы, все-таки, производить необходимые программные продукты с удовлетворительным качеством и в приемлемые сроки?
Начну сразу с ответов.
Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов – объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».
Что делать? Управлять людьми. Успех, а равно и провал, проектов по производству ПО на 100% лежит в области психологии.
Все, что написано далее, посвящено не тому, чтобы доказать или обосновать приведенные выше выводы (автор осознает непосильность для себя подобной задачи), а тому, чтобы поделиться с заинтересовавшимся читателем теми жизненными наблюдениями, которые, в конце концов, привели к данным выводам. Впрочем, совсем уж субъективные иллюстрации из личного опыта, которые, на мой взгляд, могут быть опущены без ущерба для понимания остального содержания статьи, выделены мелким шрифтом и оформлены в виде сносок.
Как должно солидным людям, давайте договоримся о понятиях. Поскольку была выбрана форма эссе, а не академической монографии, то автор может позволить себе вольность и дать свои определения терминов, которыми нам предстоит оперировать, не приводя многочисленное цитирование первоисточников и углубленный анализ различных трактовок понятий.
Вспоминается книга по теории вероятностей, в которой было приведено около 200 различных определений понятия вероятности.
Разумеется, это не мои определения, а то, что сложилось и укрепилось в голове под влиянием многих авторов за годы программирования.
Программирование – процесс отображения определенного множества целей на множество машинных команд и данных, интерпретация которых хотя бы на одном компьютере обеспечивает достижение поставленных целей.
Цели могут быть любые: воспроизведение звука в динамике ПК, расчет траектории полета космического аппарата на Марс, печать годового балансового отчета и т.д. Важно то, что они должны быть определены. Это звучит банально, но сколько бы раз об этом не твердили ранее, по-прежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели.
Свежая цитата из жизни: «Была бы разработана хорошая программа, а какой процесс автоматизировать с ее помощью, мы найдем». Могу добавить только одно: «Ни один ветер не станет кораблю попутным, если капитан не знает, куда плыть».
Это отображение может быть очень простым, например, перфорирование машинных команд и данных на перфокартах. А может быть многоступенчатым и очень сложным, когда сначала цели отображаются на требования к системе, требования – на высокоуровневую архитектуру и спецификации компонентов, спецификации – на дизайн компонентов, дизайн – на исходный код. Далее исходный код при помощи компиляторов и сборщиков отображается на код развертывания, код развертывания – на вызовы функций ПО окружения (ОС, промежуточное ПО, базы данных), которое может располагаться на множестве компьютеров, объединенных в сеть, и только после этого – в машинные команды и данные.
Профессиональное программирование (синоним производство программ) – деятельность, направленная на получение доходов при помощи программирования.
Принципиальным отличием от просто программирования является то, что имеется или, по крайней мере, предполагается некоторый потребитель, который готов платить за использование результатов программирования. Отсюда следует важный вывод о том, что производство программ это всегда коллективная деятельность, в которой участвуют минимум два человека: программист и потребитель.
Профессиональный программист – человек, который занимается профессиональным программированием. Профессионального программиста следует отличать от профессионала (мастера в программировании). Разброс профессионального мастерства в программировании достаточно широк и далеко не каждый, кто зарабатывает на жизнь программированием, является мастером, но об этом позже.
Обозримое будущее – ближайшие 5-10 лет, на которые автор готов экстраполировать действие закономерностей и выводов, изложенных в статье. Возможно, что за это время удастся осуществить прорывы или в искусственном интеллекте, или в теории доказательства правильности программ, которые могут революционно изменить состояние дел в программировании.

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

Гуру программирования Ф. Брукс в 1975 году писал:
«Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов».
Некоторые психологи, которые работают с программистами, идут дальше и даже утверждают, что программирование – это высшая форма творчества.
Творчество – это интеллектуальная деятельность человека, законы которой нам неизвестны. Если бы мы знали законы творчества, то и картины, и стихи, и музыку, и программы уже давно бы создавали компьютеры. Творческое начало это то, что роднит программирование с наукой и искусством.
Творчество в программировании начинается с определения целей программы и заканчивается только тогда, когда в ее коде, написанном на каком-либо языке программирования, поставлена последняя точка. Попытки разделять программистов на творческую элиту, архитекторов и проектировщиков, и нетворческих программистов-кодеров не имеют под собой объективных оснований. Даже если алгоритм программы строго определен математически, два разных программиста его закодируют по-разному, и полученная программа будет иметь разные потребительские качества.
Пример из личного опыта. Когда я работал в Центре управления полетами, нам для долгосрочных прогнозов траекторий КА потребовалась более точная модель вращения Земли. Некоторые думают, что Земля равномерно вращается вокруг неподвижной оси со скоростью 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 год). А аутизм тогда еще даже не придумали…
Аутизм сейчас популярная тема не только среди профессиональных психологов, но и в обществе. Про аутистов даже сняты художественные фильмы: «Человек дождя» и «Меркурий в опасности». Поэтому позволим себе отослать заинтересовавшегося читателя к многочисленным профессиональным и не очень источникам информации, которые в большом числе присутствуют в Интернете. Остановимся только на тех качествах шизоидного типа личности, на которые мы будем ссылаться в дальнейшем.
  • Они ориентированы на свой внутренний мир, а не на окружающих их людей, они с трудом идут на установление контактов с другими людьми, их реакции часто необычны и непонятны окружающим, а привычки и пристрастия – устойчивы и с трудом поддаются изменению.
  • Для них характерно сочетание противоречивых черт в личности и поведении: холодности и утонченной чувствительности, упрямства и податливости, настороженности и легковерия, апатичной бездеятельности и напористой целеустремленности, необщительности и неожиданной назойливости, застенчивости и бестактности, чрезмерных привязанностей и немотивированных антипатий, рациональных рассуждений и нелогичных поступков, богатства внутреннего мира и бесцветности его внешних проявлений.
  • Они могут повторять одно и то же действие снова и снова. Они хотят жить так, чтобы в окружающем их мире ничего не изменялось и чтобы события всегда происходили в привычном для них порядке. Даже незначительное изменение в этом порядке их очень расстраивает.
  • На работе они часто неуправляемы, так как трудятся, исходя из собственных представлений о ценностях в жизни. Однако, в определенных областях, где требуется художественная экстравагантность, одаренность, нестандартность мышления, символизм, они могут достичь многого.
“Аутист видит в компьютере близкое существо,
– считает Эми Клин, ассистент профессора Центра детского развития при Медицинской школе Йельского университета. –
Компьютеры бескомпромиссны и негибки, а люди, с которыми нам приходится иметь дело, отличаются теми же качествами”.
Аутизм ограничивает способность таких людей к общению, но вознаграждает их даром невероятной концентрации и творческой продуктивности.
Аутистическая природа программирования это не просто еще один факт, а, по-видимому, самый важный из всех фактов, которые необходимо учитывать, если мы хотим успешно производить программное обеспечение.
Каждый программный проект это потенциальная катастрофа. И если мы не будем постоянно прилагать усилия к тому, чтобы этой катастрофы избежать, мы неотвратимо к ней придем. Мы подробно писали о специфической сложности программных проектов и непредсказуемости их главной составляющей – программистов. Что же позволяет нам при разработке ПО с уверенностью смотреть в завтрашний день? Ответ прост – управление на макро уровне. В статистической динамике газа мы абстрагируемся от броуновского движения каждой из молекул и оперируем усредненными характеристиками: скорость потока, температура, давление. Аналогично, в программном проекте мы можем в разы ошибиться при оценке трудоемкости реализации каждого отдельного функционального требования. Но наши ошибки будут как в меньшую, так и в большую сторону. Поэтому для проекта в целом они будут компенсироваться.
Это следствие закона больших чисел. Главное, чтобы оценки элементарных работ были независимы между собой. Например, закон больших чисел не сработает, если все ваши оценки поражены оптимизмом.
В моей практике ошибка суммарной трудоемкости проекта составляет не более 30%. Производительность участников проекта также может отличаться в разы, но средняя производительность по всем участникам вещь достаточно стабильная и прогнозируемая. По моему опыту оптимальное с точки зрения макроуправления количество человек в группе разработчиков – 4-6. Если проект большой, то необходимо провести его архитектурную декомпозицию на минимально связанные подсистемы, разработку которых следует вести отдельными группами со своими руководителями и планами.
Задачей любого управления является достижение некоторой цели. В нашем случае целью управления является успешное завершение проекта. Если кто-то думает, что успех проекта это реализация в программе 100% требований к назначенному сроку и в пределах выделенного бюджета, то это не так. Успех проекта живет в головах людей. Успех это в первую очередь чувство удовлетворения заказчика.
У вашего проекта нет заказчика? Ваш проект ожидает катастрофа. И еще, из личного опыта. Я видел проект, в котором были реализованы в срок все требования, заказчик оплатил работы по проекту, но остался неудовлетворенным. Вряд ли такой проект можно назвать успешным, поскольку упущенная выгода для компании-разработчика вследствие отказа заказчика от новых совместных проектов в сотни раз превысила прибыль от этого пилотного проекта. И наоборот, был случай, когда заказчик остался доволен проектом, в котором было реализовано чуть более половины требований. В этом проекте мы только на середине поняли, что не успеваем к фиксированному сроку, очень важному для бизнеса нашего клиента. Но поскольку между заказчиком и нашей компанией были установлены исключительно открытые и доверительные отношения, то заказчик признал проблемы объективными и пересмотрел требования к системе. Он добавил несложные, но критичные для его бизнеса, новые требования, а реализацию оставшихся требований перенес в новый совместный проект.
Но не только. Успех это еще и чувство удовлетворения людей, которые выполняли проект. Вряд ли стоит называть проект успешным, даже если заказчик остался доволен его результатами, но при этом из компании ушли все профессионалы, участвовавшие в этом проекте. Я сознательно не касаюсь здесь вопросов экономической эффективности проекта и не потому, что «джентльмены о деньгах не говорят», а потому, что это самостоятельный и непростой вопрос совсем из другой области.

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

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

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

То, что важным фактором программистского проекта является психология, начали писать более 30 лет назад, книги Венберга и Де Марко ничуть не утратили своей актуальности и сегодня. Но понимание того, что психология является решающим фактором успеха или неуспеха проектов разработки ПО, пришло только в последние годы. Радикальным решением проблем кризиса программирования поочередно объявлялись поиск лучшего языка программирования (1960-е годы), технологии программирования (1970-е годы), инструментария программирования (1980-е годы), системы качества (1990-е). И только центральному и ключевому фактору – фигуре самого программиста – внимание почти не уделялось.
«Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте».
Это вывод Алистэра Коуберна, который базируется на результатах анализа очень разных программных проектов, реализованных за последние 20 лет. Проекты отличались друг от друга по количеству программистов, по срокам выполнения, по применяемой технологии – от самой тяжелой (CMM 5-го уровня) до полного ее отсутствия. Коуберн не обнаружил статистически значимой корреляции успеха или неуспеха проекта ни с одной из перечисленных характеристик.
Не правы те, кто утверждает, что нет разницы между управлением программными проектами и проектами в любой другой отрасли промышленности, например, в строительстве или авиастроении. Разница есть и она принципиальная.

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

Управляем катастрофой
До сих пор мы только констатировали объективно существующие трудности и проблемы, которые связаны с разработкой программных проектов. Читатель давно уже в праве ожидать от нас ответа на вопрос «что делать?». Короткий ответ – управлять людьми, которые вовлечены в проект. И круг таких людей достаточно широк. Оставшаяся часть статьи будет посвящена управлению программными проектами, а если точнее, то работе менеджера проекта 14 по управлению людьми, как внутри проекта, так и вне него. Начнем по порядку.
Над входом в храм Аполлона в Дельфах написано «Познай себя». Начинайте проект с себя. Вы – менеджер проекта. Если это ваш первый проект, то поздравляю вас с приобщением к благородной профессии. «Управление благородно по своей сути. Менеджмент ничего не имеет общего с деятельностью бюрократа, сидящего наверху. Менеджер делает самую необходимую в компании работу. Благодаря нему становится возможным выполнение самых грандиозных проектов. Нет более почетной работы, чем та, которую делает настоящий менеджер».
Но даже, если у вас сверхвысокий IQ , это не поможет вам в управлении людьми. Чтобы управлять людьми, нужны совсем другие качества. Менеджер должен обладать сверхвысоким EQ – коэффициентом эмоционального интеллекта (Emotional Intelligence). Вот три компонента эмоционального интеллекта:
  1. Понять свои собственные чувства.
  2. Научиться управлять ими.
  3. Научиться распознавать эмоции других и управлять ими.
Загляните в себя, есть ли у вас необходимые качества. В силу аутистической природы программирования хороший программист, как правило, этими качествами не обладает. Из хороших программистов выходят, как правило, плохие менеджеры проектов. Аутисты предпочитают не общаться с другими людьми и не испытывать потребности в таком общении, они не интересуются другими людьми, стремятся быть в одиночестве. Недостаточный EQ и шизоидные наклонности могут привести к параноидальному стилю управления: чрезмерной бдительности, подозрительности, озабоченности скрытыми мотивами, повышенной тревожности [11]. Такие руководители считают подчиненных некомпетентными симулянтами, которые не любят свою работу и стремятся избежать ее, если у них есть такая возможность. Руководители подобного типа практикуют строгий контроль через активное личное наблюдение, формальные правила и ограничения. Ведут себя агрессивно, в особенности с теми подчиненными, которые высказывают свое мнение. «Кнут и пряник» для них единственные инструменты мотивации подчиненных.
Метод «Кнута и Пряника» – алгоритм, описанный в известной монографии Кнута и позднее модифицированный русским программистом Пряником. Программистский фольклор (И. Одинцов, «Профессиональное программирование. Системный подход», BHV, Санкт-Петербург, 2002)
Эти инструменты, может быть, полезны, когда мы управляем стадом баранов, но для управления командой эйнштейнов категорически не годятся. Эйнштейны очень быстро разбегаются, если, конечно, их не огородить колючей проволокой. Мы еще вернемся к вопросу мотивации эйнштейнов.
В истории нашей удивительной страны был такой опыт – сталинские «шарашки».
Если у вас недостаточный EQ , не отчаивайтесь. В отличие от IQ , который формируется в ранней молодости и затем практически не меняется, EQ можно повышать на протяжении всей жизни.
Призыв 1. Повышайте свой эмоциональный интеллект, если вы хотите руководить успешными программными проектами.
Поймите свои собственные мотивы. Ответьте себе на вопрос, почему вы беретесь именно за этот проект. Если единственным ответом является: «Потому, что мне поручили», знайте, что катастрофа не за горами. Помните, что вам предстоит поставить на кон свою репутацию и вложить в проект душу. «Вполнакала проекты не делаются» – очень точная формулировка И. Ставинского. Поэтому нужно четко понимать, в чем будет ваш выигрыш в случае успешного завершения проекта.
Призыв 2. Поймите свои личные цели, достижение которых связано с успешным завершением проекта.
Эти цели не обязательно должны быть материальными: повышение оклада или должности. Это могут быть идеальные цели: познать новое, сделать то, что до вас никто не делал, обеспечить существенные конкурентные преимущества вашей компании или, наконец, осчастливить все человечество. Главное, чтобы для вас лично эта цель была значимой настолько, чтобы стремление к ее достижению могло бы поддерживать в вас состояние постоянного горения от начала до завершения проекта.
Как мы отмечали ранее, главная цель управления проектом – вызвать у заказчика чувство удовлетворения. Степень удовлетворенности – субъективная величина, которая является отношением субъективной оценки достижений к субъективной же оценке ожиданий или потребностей. Отсюда следует:
Призыв 3. Продавайте свой проект от начала до завершения работ.
Понимание этого правила пришло ко мне достаточно давно, но формулировку его я заимствовал у Тома Питерса.
Долгое время, работая в научном коллективе, я не мог понять, почему умным и талантливым ученым, раз за разом, урезают финансирование очень перспективных направлений, а другие деятели от науки получают ассигнования на все новые и новые «мыльные пузыри». Так продолжалось до тех пор, пока мне не попалась фраза, приписываемая великой Раневской: «Не важно, милочка, что Вы из себя представляете. Важно, что о Вас говорят». Эта истина все расставила по своим местам.
Продавать проект следует в первую очередь заказчику. Если, после заключения договора на разработку ПО, вы планируете следующую встречу с заказчиком на приемо-сдаточных испытаниях, то вы прямой дорогой идете к катастрофе. Вы должны работать над тем, чтобы заказчик постоянно испытывал чувство удовлетворения от начала проекта до его завершения. Этого можно добиться, если вы разрабатываете проект итерационно: чуть-чуть спроектировали, чуть-чуть закодировали, чуть-чуть протестировали и продали этот результат заказчику. Продали – это означает – убедили (снова психология) заказчика, что вы представили ему нечто большее, чем то, на что он мог бы рассчитывать на текущем этапе проекта. Если во время приемо-сдаточных испытаний критика заказчиком того, что вы произвели, это, скорее всего, признак неизбежной катастрофы, то замечания на ранних итерациях это весомое свидетельство движения вашего проекта к успеху. С радостью принимайте их и тщательно анализируйте.
Я выделил эти слова курсивом потому, что часто не очень компетентные замечания заказчика могут ухудшить конечный результат проекта. Если вы профессионал, вы обязаны найти аргументы и убедить заказчика в том, что он не прав. Ну и, естественно, не забывайте анализировать, как эти изменения могут повлиять на сроки и бюджет проекта и, в случае их изменения, не забудьте согласовать это с заказчиком.
Даже если вы не будете уверены в их положительном влиянии (вы ведь можете что-то не знать о бизнесе заказчика), оперативно совершенствуйте свой проект и вновь представляйте результаты заказчику. Тем самым заказчик становится соучастником вашего проекта и соавтором будущего результата. А какой же родитель не любит ребенка, которого он сам растил и воспитывал. Это обратная связь, которая необходима любой системе управления, если вы хотите, чтобы она обладала устойчивостью. Это гарантия того, что на приемо-сдаточных испытаниях заказчик будет ожидать ровно то, что вы ему представите. Управляйте ожиданиями заказчика и формируйте у него адекватную оценку представленного вами результата.
Заказчик далеко не единственный человек, которому вы должны постоянно продавать свой проект. Заказчика окружают люди, которые могут существенно влиять на формирование его мнения. Например, будущие пользователи вашей программы. Вы просто обязаны продавать ваш проект и им. Так же полезно продать проект экспертам в той области ИТ, к которой относится ваш проект. Заручитесь их поддержкой, она особенно пригодится вам, если заказчик не является специалистом в ИТ.
Очень важно продавать проект вашему руководству, если заказчик проекта со стороны. Руководство должно быть постоянно уверено, что проект завершится в срок и в полном объеме. Сделайте проект прозрачным, пусть руководство видит все, от плана проекта до исходного кода программ и скриптов. Руководство, конечно, не поймет, как продвигается ваш проект, но избавится от присущей ему фобии, что от него что-то скрывают. Разработайте для руководства небольшой и ясный набор индикаторов (об индикаторах проекта чуть позже), который будет отражать продвижение проекта к цели, и регулярно представляйте отчет по их изменению, чтобы руководство могло следить за прогрессом проекта.
И если уж речь зашла о руководстве, то уместно привести здесь еще одно правило.
Призыв 4. Не позволяйте руководству принимать других решений в вашем проекте, кроме двух: остановить проект или сменить менеджера.
По всем остальным вопросам в проекте принимать решения должен менеджер, а руководство вправе лишь высказывать свои рекомендации. Если это не так, то вы идете к катастрофе. Джоель Спольски так описывает последствия вмешательства руководства:
«…Руководители разных уровней с удовольствием запускали руки в каждый стряпающийся пирог, раздавая указания направо и налево в стиле, который я стал называть порулил и убегай. «Порулил и убегай» потому, что начальники появлялись на горизонте вероломно, отдавали глупые распоряжения как именно все, черт побери, должно быть сделано, без какого-либо предварительного размышления, и покидали комнату, оставляя всех собирать осколки».
Если вам не удалось оградить проект от подобных вмешательств, вам, скорее всего, придется собирать осколки до его завершения.
А теперь о самом главном в управлении программным проектом – управлении проектной командой. Управлять людьми – значит побуждать их к правильным действиям. А побуждать их можно, только управляя мотивами. Согласно теории мотивации для того, чтобы человек совершил какое либо действие он должен испытывать некую потребность и предполагать, что, выполнив это действие, он в той или иной степени эту потребность удовлетворит. Поэтому управление мотивами осуществляется, как правило, в двух направлениях: 1) формирование правильных потребностей; 2) формирование правильной оценки степени их удовлетворения.
Как манипулировать сознанием людей хорошо понимали идеологи коммунизма. Вспомним, как искренне испытывали чувство счастья миллионы советских людей на ударных стройках пятилеток. Агитационно-пропагандистское обеспечение этих проектов эффективно занималось формированием правильных потребностей и правильных оценок степени их удовлетворения.
Я отношу себя к сторонникам гуманистического направления в теориях мотивации и исхожу в своей практической деятельности из структуры потребностей, которую описывает пирамида А. Маслоу. Мои многолетние наблюдения показывают, что потребности нижнего уровня пирамиды (физиологические и безопасности) для программистов, как, впрочем, и для других работников интеллектуального труда, играют несущественную роль. Это означает, что если эти потребности удовлетворены процентов на 50-70, то их дальнейшее удовлетворение слабо мотивирует работу программиста. Для программистов гораздо большее значение имеет удовлетворение потребностей принадлежности, самоуважения и самоактуализации. Причем, чем выше квалификация программиста, тем на более высоком уровне пирамиды Маслоу находятся мотивирующие его потребности. Попробуйте уговорить суперпрограммиста перейти на техническое сопровождение системы, даже если вы пообещаете ему в два раза большую зарплату. А вот уговорить его перейти на проект в области сверхновых технологий вполне возможно, даже при некоторой потере в доходах.
Об этом же пишет Э. Йордан:
«Деньги, выгода, комфорт и тому подобное являются факторами «гигиены» – их отсутствие вызывает неудовлетворенность, однако они не могут заставить людей полюбить свою работу и дать им необходимые внутренние стимулы. Что действительно может дать такие стимулы, так это ощущение значительности достигнутых результатов, гордость за хорошо выполненную работу, более высокая ответственность, продвижение по службе и профессиональный рост – все то, что обогащает работу».
Об этом же более 30-ти лет назад писал Вейнберг:
«Творчески работающему программисту присуща глубокая внутренняя мотивация». На мой взгляд, это еще одно следствие аутистической природы программирования.
Призыв 5. Имейте ясное представление о мотивах каждого участника проекта, чтобы эффективно управлять проектной командой.
Как я уже отмечал ранее, потребности каждого программиста зависят от его возраста, опыта и квалификации. Позволю себе привести свою экспертную оценку распределения мотивирующих потребностей для профессиональных программистов.
Пропуск в той или иной графе свидетельствует не об отсутствии соответствующей потребности, а о том, что при помощи дополнительного удовлетворения этой потребности не получится мотивировать данного специалиста. Например, для профессионала материальные потребности и потребности безопасности не играют существенной роли, поскольку, если они в достаточной степени не удовлетворены, он просто меняет работу и больше не думает о них. Конечно, как и любая другая модель, это распределение не верно, но оно может быть полезно для руководителя программистского коллектива.
Команда успешного проекта это команда победителей. Успешный проект должен сделать победителем всех его участников.
Призыв 6. Рассматривайте работу команды над проектом как корпоративную игру, в которой каждый участник, стремится к достижению своих личных целей, продвигая проект к успеху.
Управление командой начинается с ее формирования.
Призыв 7. При наборе персонала убедитесь, что человек сможет сделать то, что нужно в вашем проекте и хочет то, что вы сможете ему дать.
Вроде все просто, однако, это не так. Сможет это не только знает и умеет, но еще и захочет.
Я, например, не знаю, как мотивировать суперпрограммиста переписать библиотеку DLL с C++ на Java, если эта работа больше чем на 2-3 дня.
А часто бывает ситуация, что не знает и не умеет, например, если технология совершенно новая, но хочет. И этого стремления, как правило, бывает достаточно, чтобы освоить новую технологию и успешно решить поставленную задачу. Главный вывод, который отсюда следует это то, что на серьезный проект, надо набирать разных программистов. И начинающих, и звезд. Если вы берете в проект суперпрограммиста, то должны быть уверенным, что вы сможете эффективно использовать его квалификацию и найдете достойную задачу, которая его заинтересует.
В настоящее время нет каких-либо формальных методик определения квалификации программиста. Мой опыт показывает достаточно значимую корреляцию хороших способностей к программированию и сверхвысокого значения IQ . Высокий балл диплома и престижное математическое или техническое образование свидетельствует об общих способностях кандидата успешно осваивать новый материал. Диплом о престижном высшем образовании немаловажен для хорошего программиста, хотя и не является необходимым условием.
Я знаю достаточно успешного рок-музыканта, который, вообще не имея высшего образования, в настоящее время не менее успешно работает ведущим программистом в серьезной зарубежной компании разработчике ПО.
При отборе кандидатов только очное интервью «глаза в глаза» и личный опыт работы с людьми позволит вам создать эффективную программистскую команду. О практике проведения интервью могу рекомендовать работы, в которых изложены подходы, во многом совпадающие с моим опытом.
Программисты любят и умеют программировать. Пусть они этим и занимаются. Но в каждом проекте много других работ: бизнес-анализ, проектирование эргономики, графический дизайн, разработка пользовательской документации. Эти работы с программированием не имеют ничего общего. Для них требуются совершенно другая квалификация и другой склад мышления. При кустарном производстве программ эти задачи, как правило, поручаются программистам, которые это делать не умеют и не любят. Получается обычно плохо и дорого. В силу своего аутистического склада программист просто не в состоянии увидеть свою программу чужими глазами – глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса – кустарным творением программистов – когда для того чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает программа, чем разбираться в том, что она делает для пользователя.
Призыв 8. Не загружайте программистов несвойственной для них работой.
Включайте в проектную команду, бизнес-аналитиков, эргономистов, художников-дизайнеров, документалистов. Разделение труда – залог перехода от кустарного производства к более эффективному промышленному производству.
Теперь, когда цели определены, команда собрана, пора приступать непосредственно к созданию программной системы. Поскольку, разработка ПО, как мы отмечали выше, корпоративная игра, то первое, что мы должны сделать, это договориться о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды в проекте. Повторим вслед за автором: «Каждому проекту своя технология». И чем больше и ответственней проект тем «тяжелей» должна быть технология. Технология может меняться вместе с развитием и ростом проекта, но на каждом этапе она должна быть определена и описана . Бессмысленно спрашивать с программиста ответа за то, что ему не поручено.
Существует удобная для руководства формула: «ты в ответе за все». Для того, чтобы избавиться от неугодного работника – удобно, но организовать эффективную работу невозможно.
Призыв 9. Договоритесь о правилах игры – нормах и регламентах, которые определяют права и ответственность членов проектной команды.
Регламенты и стандарты требуются еще и для того, чтобы все участники проекта разговаривали на одном языке, а ваш проект не превратился в проект строительства Вавилонской башни. Иначе, например, если не определено или не исполняется соглашение по правилам кодирования, программисты быстро перестанут понимать друг друга.
Главная задача менеджера – обеспечить максимально эффективное использование знаний и способностей каждого участника проекта для решения проектных задач. Набранная вами группа специалистов это еще далеко не та команда, которая способна быстро и качественно достигать поставленные цели, умеющая самостоятельно принимать нестандартные и эффективные решения. В силу аутистической природы программирования набранная вами группа это собрание индивидуалистов-эйнштейнов, которые, как правило, самодостаточны и не нуждаются ни в руководстве, ни в общении. Для того, чтобы из группы получилась команда, необходима общность представлений участников о нормах поведения в коллективе и ожиданиях от каждого из его участников. Каждый участник команды должен понимать, какое трудовое поведение приемлемо, а какое порицается, каковы должны быть отношения в группе, стиль и методы работы. У меня выработалось определенное представление о правильных нормах поведения, которые я настойчиво внедряю в своих проектах. На мой взгляд, программист может считать себя профессионалом только тогда, когда:
  1. Получает удовольствие от своей работы, гордится ее результатами и стремится, чтобы эти же чувства испытывали все коллеги.
  2. Четко осознает свои личные и общие цели, понимает их взаимообусловленность, настойчиво стремится к их достижению.
  3. Занимает активную позицию, стремится расширить свою ответственность и увеличить личный вклад в общее дело.
  4. Постоянно приобретет новые профессиональные знания и опыт, выдвигает новые идеи, направленные на повышение эффективности достижения общих целей, добивается распространения своих знаний, опыта и идей среди коллег.
  5. Уверен в себе и в своих коллегах, объективно оценивает их достижения и успехи, внимательно относится к их интересам и мнениям, активно ищет компромиссы при противоречиях.
  6. Является оптимистом, при этом твердо знает, что окружающий мир несовершенен; воспринимает каждую новую проблему, как дополнительную возможность подтвердить собственный профессионализм в своих глазах и во мнении коллег.
Основные усилия по мотивации участников проектной команды я направляю на то чтобы стимулировать правильное поведение.
Призыв 10. Постоянно работайте над строительством команды, мотивируйте правильное поведение участников проекта.
Очень важно, чтобы каждый член проектной команды знал, или хотя бы имел при желании возможность узнать о проекте не меньше, чем его менеджер. И не стоит ничего скрывать, ни проблем с заказчиком, ни разногласий с руководством. Трудно ожидать самостоятельные, нестандартные и эффективные решения от человека, у которого «шорами» ограничено видение проблемы.
Ошибкой являются попытки управления проектом на микро-уровне: мотивирование достижения формальных индивидуальных показателей, например, реализация программистом функциональных требований, количество написанных им строк исходного кода или плотность выявленных ошибок. В творческой деятельности формальные подходы не работают.
Вспоминается эпизод, когда в коллектив из кандидатов и докторов наук за год работы создал систему формальных показателей, которая, по их мнению, позволяла оценивать эффективность научной деятельности подразделений института. Назывался труд «Методика подведения итогов социалистического соревнования» – около 100 показателей и более 100 страниц методических указаний по их расчету. Не сработало! Уже через три месяца самые «продвинутые» руководители научились работать на методику, а не на науку, и стали получать самые большие премии.
Де Марко по поводу одной из своих коллег говорил:
«я слабо представляю, какой вклад она вносит в мой проект, но за 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)”. Работая за одним компьютером, мы сделали эту задачу за день. Запомнилось искреннее удивление моего коллеги: «А что, так можно?». – «Так нужно», – терпеливо отвечал я. Правда, это опять о необходимости обучения.
И не о наличие отдельного кабинета, о котором пишет Де Марко.
Вспоминается работа в НИИ, когда рабочие столы в комнате стояли настолько плотно, что расстояния между столами устанавливались с учетом индивидуальных особенностей комплекции каждого работника. Откровенно говоря, это было не очень удобно, но, как мне кажется, это не сказывалось на эффективности коллективной разработки программ. На мой взгляд, отдельный кабинет для программиста не только не обязателен, но и вредит коллективной работе в проекте, поскольку резко снижает неформальные коммуникации.
В творческой деятельности обязательным элементом ответственности является свобода выбора пути решения стоящей проблемы. Свобода не только необходимое условие творчества, но и важный мотивирующий фактор. Даже если вы уверены в существовании более правильного решения, вы не в праве настаивать на нем, вы можете высказать свое мнение только в виде рекомендации. Предоставьте членам проектной команды право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет. Впрочем, вы ведь тоже можете ошибаться.
Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов свободы. Бессмысленно заставлять программистов работать больше, устраивать сверхурочные авралы и субботники. Работать больше, это совсем не значит – работать продуктивнее. Скорее наоборот. Излишнее давление и суета приводят к непродуманным решениям и многочисленным последующим переработкам. «Хорошо управляемое предприятие – это спокойное место. Зато «фабрика, отличающаяся “кипучей” деятельностью и “трудовым героизмом” работников, который бросается в глаза любому посетителю, является на самом деле плохо управляемой». Это не я сказал, это говорит управленец «в законе».
Если программист адекватно мотивирован для того, чтобы выполнить порученную работу, то он будет стремиться сделать ее максимально быстро и с необходимым качеством. Многие программисты, особенно молодые, по собственной инициативе готовы тратить на решение задачи по 12-16 часов в сутки. Это неправильно, эффективность работы резко снижается, и при злоупотреблении сверхурочной работой программист уподобляется мухе, бьющейся головой о стекло, вместо того чтобы методично искать правильное решение.
Вспоминаются молодые годы, когда причины большинства ошибок, которые не удавалось локализовать в течение многочасовых ночных поисков, всплывали в голове, спустя некоторое время после того, как я, отчаявшись, наконец, бросал данную задачу. Обычно мне хватало времени только для того, чтобы дойти от места работы до проходной. Поэтому, если я замечаю систематические сверхурочные переработки кого-либо из сотрудников, то, как правило, обращаюсь к нему со следующими словами: «Уважаемый коллега, Вы не справляетесь с работой в рабочее время? Давно бы сказали мне, я бы нашел Вам задачу полегче». Сверхурочные работы не только не эффективны. Я уже давно принял истину: мы живем не для того, чтобы работать, а работаем для того, чтобы жить. Многое в жизни бывает только раз: молодость, первая любовь, маленькие дети. Пренебрежение к личной жизни приводит, как правило, к стрессам и неизбежным последующим проблемам в профессиональной сфере.
Еще одно распространенное заблуждение менеджеров: оптимизм программистов. Я не имею в виду начинающих программистов, я говорю об опытных. На мой взгляд, заниженные оценки сроков решения поставленной задачи, как правило, являются следствием морального давления менеджеров. Программисту в силу своего аутистического нежелания общаться с другими людьми, легче согласиться с навязываемыми руководством сроками, чем объяснять начальству, почему оно не право.
Отношение менеджера и членов успешной проектной команды должны строится не на принципах подчинения, а на принципах партнерства. Партнерство не может быть без доверия. Если в проектной команде нет доверия, это путь к катастрофе.
Призыв 14. Не мешайте программистам. Доверяйте им. Обеспечивайте им свободу творчества. Предоставляйте им право на ошибку. Не оказывайте на них давление.
Повторюсь, управляйте проектом на макро-уровне. Не бойтесь, если одна молекула временно летит медленнее, чем остальные, или не совсем в ту сторону. Главное, чтобы это не было системой, чтобы среднее движение всех молекул было направлено к цели и осуществлялось с необходимой скоростью.
Важнейшим неформальным макро-показателем состояния проекта являются коммуникации, их качество и количество. Если угодно, то по моей экспертной оценке коммуникации, включая наставничество и консультации, в успешном проекте занимают 30-50% рабочего времени. Только благодаря эффективным коммуникациям можно достигнуть синергетического эффекта, который отличает команду от просто группы. Мне неоднократно приходилось убеждаться, что освоение новой информационной технологии парой программистов, которые осуществляют интенсивный обмен знаниями, происходит минимум в 3 раза быстрее, чем в случае, когда ту же работу выполняет один программист. Недостаточное количество коммуникаций свидетельствует, как правило, об отсутствии команды, каждый углублен в свою задачу и не интересуется, что делают его коллеги. В результате будет сделано не то, что нужно, а то, что будет сделано, вряд ли удастся интегрировать в единую систему. Если через день после получения недельного задания у программиста не возникло уточняющих вопросов, жди беды. Скорее всего, он с головой ушел в «проектирование дома, забыв уточнить, для чего он предназначен». Учитывая шизоидную несклонность программистов к общению, менеджеру требуется прилагать значительные усилия для того, чтобы мотивировать необходимый уровень коммуникаций.
Эффективность коммуникаций напрямую связана с доброжелательностью межличностных отношений. Не стоит ожидать плодотворного обмена информацией, если участники проекта поставлены в условия конкуренции или разделены барьерами должностной иерархии. Доброжелательность это не отсутствие споров и дискуссий, а нацеленность в спорах и дискуссиях на поиск консенсуса (интегрированного решения проблемы, которое объединяет лучшие стороны всех предложений), а не на выяснение межличностных отношений.
Меня давно перестали напрягать обсуждения в рабочее время членами проектной команды вопросов, не связанных непосредственно с проектом. Я рассматриваю их как способ установления открытых и доверительных отношений между коллегами, без которых немыслимы эффективные коммуникации по производственным вопросам. Кроме того, это способ отвлечься от зацикленности, от длительных и безуспешных попыток решить задачу, способ вытеснить проблему в подсознание. Все, кто занимался творческой деятельностью, понимают необходимость данной фазы в интеллектуальном процессе. В психологии это называют фазой инкубации проблемы.
Для успешного проекта характерно постоянное ощущение его участниками чувства удовлетворения и гордости за результаты своей работы, чувства оптимизма. Только наблюдая и анализируя общение участников проектной команды, можно получить информацию об их удовлетворенности состоянием дел. Нет ничего более гибельного для проекта, чем равнодушие или уныние его участников.
Призыв 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”, March, 2000
  19. А. Коуберн, “Каждому проекту своя методология”,Humans and Technology Technical Report, TR 99.04, Oct.1999 (русский перевод)
  20. Питер Ф. Друкер, “Эффективный управляющий”.
]]> http://spmguild.org/lib/533/feed/ 0