Структурное руководство проектом. Серебряная пуля?
 Издательство: КУДИЦ-ОБРАЗ |
ООО ИК СИБИНТЕК
"Кстати, если вампиры на вас все же нападут, [...] с серебряными пулями лучше не баловаться. Ерунда все это, сам пробовал" Емец Д.А. Таня Гроттер и трон Древнира |
Оказывается, серебряная пуля для ИТ проектов появилась уже 10 лет тому назад! А теперь про нее можно прочитать и по-русски. Вот только так ли она действенна, как принято считать?
Увы, разработка программного обеспечения остается одним из самых рискованных занятий. Процент неуспешных проектов, в том числе не уложившихся в сроки или бюджет, наиболее высок именно в области информационных технологий и именно среди проектов, связанных с разработкой ПО. Можно долго рассуждать, почему проекты проваливаются. А можно подумать о том, почему же часть проектов все-таки выполняется успешно. И по второму пути идут очень и очень многие. Существует масса рекомендаций касательно того, как нужно выполнять проект, чтобы "наверняка" или "почти наверняка" выполнить его в срок, в рамках бюджета и удовлетворить все пожелания Заказчика.
Чтобы тебя заметили в такой ситуации, новая методология должна называться как-то очень необычно. Ну, например, "эКСтремальное Программирование", "Кристально ясная", или хотя бы "Рациональный Унифицированный Процесс". А что делать, если новый метод называется просто "Структурное руководство проектами"? Ничего выдающегося... Приходится придумывать запоминающееся название для книги, описывающей вашу методологию.
Именно так и поступил Фергус О'Коннэл, дав своей книжке с достаточно скучным названием "Как успешно руководить проектами" подзаголовок "Серебряная пуля". Собственно, под этим названием она и известна среди англоязычных специалистов. А теперь ее можно прочитать и по-русски (Фергус О'Коннел. Как успешно руководить проектами. Серебряная пуля. М.: КУДИЦ-ОБРАЗ, 2003. - 288 с.).
Для тех, кто не знает. Серебряная пуля - это не только радикальное средство от вампиров.
Этот термин достаточно давно и активно используется в ИТ как символ технологического прорыва, который позволит разрабатывать ПО намного быстрее и качественнее. Дело в том, что Фред Брукс в 1987 году опубликовал очень широко известную статью под названием "No Silver Bullet" - "Серебряной пули не существует" - в которой доказывал, что нет и не предвидится никакого существенного прогресса в процессе разработки программного обеспечения.
Назвать книгу с описанием своей методологии "Серебряная пуля" - это серьезная претензия. И нельзя сказать, что она необоснованна. Как-никак, на английском первое издание "Серебряной пули" вышло в 1993 году. На русский язык книга переведена с третьего издания, вышедшего в 2001 году. Значит, интерес к ней не пропал. Значит, в ней действительно есть что-то важное и полезное, не потерявшее своего значения за 10 лет достаточно бурного развития ИТ. Но, с другой стороны, ведь и спустя десять лет мы говорим все про те же проблемы...
Сам автор говорит, что он написал книгу не про Методологию, а просто про методологию. В чем разница? Чем структурное управление проектами отличается от многочисленных методологий разработки ПО, хотя бы от упомянутых выше?
Самое главное отличие состоит в том, что это книга написана для руководителей проектов. И ТОЛЬКО для руководителей проектов. В ней нет попыток объять необъятное и дать рекомендации и ценные указания всем участникам разработки. Конечно, никто не запрещает читать ее аналитикам или программистам. Но в узко профессиональном смысле они не найдут там почти ничего, адресованного именно им. Зато если вы руководите проектами или собираетесь этим заниматься, то эта книга для вас. В ней описано, что должен сделать человек, руководящий проектом. В каком порядке. И как проверить, что он сделал все как надо.
Суть структурного руководства проектами заключена в 10 этапах, через которые нужно пройти, выполняя проект:
И если вы сумеете выполнить их, успех вашему проекту гарантирован.
При внешней простоте формулировок и некотором сумбуре (часть перечисленных этапов являются скорее принципами, которых нужно придерживаться, чем стадиями разработки в традиционном понимании) здесь скрыты очень серьезные вещи.
Начнем по порядку с первого этапа. Начиная любой проект, вы должны явно представлять, чего вы хотите добиться. Собираетесь ли вы просто заработать на жизнь себе и семье, выполнив проект с минимально необходимым качеством и, соответственно, с минимально необходимыми усилиями? Хотите ли вы освоить новые технологии? Или вы хотите, чтобы этот проект стал переломным в вашей карьере? Для вашей организации?
А что получат от участия в проекте остальные его участники? А что получит Заказчик? Чему будет радоваться он?
Сформулировав для себя ответы на эти, казалось бы, лирические вопросы, вы сможете соотносить каждый свой шаг с реальными целями. И оценивать его именно с этой точки зрения. Приближает ли он вас к достижению цели или ведет в сторону от нее?
Конечно, думать о чем-то, кроме текущих задач, может только достаточно опытный руководитель. Но если вы не будете пытаться, вы этому никогда и не научитесь. Зато, освоив этот прием, вы сможете значительно успешнее планировать работы, решать проблемы с мотивацией (как это теперь называется) ваших сотрудников, договариваться с Заказчиком и многое другое.
Второй этап, я думаю, уже вызвал возмущение среди многих приверженцев современных методологий, которые выучили, что "водопад - это плохо" (имеется в виду водопадный стиль разработки, когда сначала осуществляется анализ, потом последовательно проектирование всей системы, разработка кода, сборка и комплексная отладка). Но обратите внимание на этап 9! Основной особенностью структурного управления проектами является то, что задачи, которые необходимо выполнить для выполнения проекта, выявляются как можно раньше. Как только вы поняли, что вам придется это делать - запишите! Вот, собственно, и вся суть этапа.
При этом, как и в большинстве современных методологий, разработка ведется итерациями. На ближайшую итерацию (обычно, длительностью от 4 до 6 недель) составляется точный и детальный план. На остальные - более общий и приблизительный. Но если вы знаете, что через три итерации вам придется настраивать СУБД для обеспечения максимальной производительности системы, то и запишите это прямо сейчас! У вас будет лишнее время, чтобы подумать, кто и как будет выполнять это работу.
Третий этап (скорее, это все-таки принцип) я, честно говоря, считаю одним из самых принципиальных с точки зрения успешного выполнения проекта. По мнению автора, всякая попытка разделить руководство проектом между несколькими людьми, например, разделив его на техническое и административное, и даже просто наличие слишком сильного неформального лидера в коллективе приводят почти со 100 процентной вероятностью к провалу проекта. Но не менее пагубно сказывается на проекте и любое нежелание руководителя брать ответственность на себя. Руководитель проекта должен помнить днем и ночью, что он отвечает за все! Совсем необязательно и даже совсем нежелательно Руководителю делать все самому. У него есть более важные занятия. Но в любом случае, перед Руководством и Заказчиком за все в проекте отвечает именно он! Я бы добавил, что если вы не согласны отвечать за все, лучше не занимайтесь руководством проектами. Найдите себе более спокойное занятие вроде укрощения диких зверей или одиночных плаваний через океан.
Пожалуй, я бы добавил к данному разделу, что Руководитель проекта должен обладать достаточными полномочиями. Мало того, чтобы все управление проектом шло через единственного Руководителя. Этот Руководитель должен обладать существенными правами в части формирования цели и планов выполнения проекта, возможности непосредственно договариваться с Заказчиком, поощрения и наказания участников и много чего еще. Только в таких условиях единоличная ответственность за выполнение проекта не раздавит, а мобилизует руководителя проекта.
Четвертый этап можно считать развитием принципов предыдущего. У каждого дела внутри проекта должна быть фамилия. Это позволяет более-менее равномерно загрузить сотрудников. Это гарантирует персональную ответственность за выполнение каждой задачи. Здесь, конечно, имеется в виду ответственность внутри команды, для внешнего мира Руководитель отвечает за все.
Возможных исполнителей для каждой задачи можно разделить на несколько категорий. Лучший вариант, если человек заведомо может и при этом хочет выполнить именно эту задачу! Несколько хуже, если его приходится уговаривать (возможно, в следующий раз уговоры не подействуют). Если он недостаточно квалифицирован, но, тем не менее, готов взяться за задачу - его можно обучить (если на это есть деньги и время). Значительно хуже, если он не хочет за нее браться или не может с ней справиться даже после обучения. Хорошо, если для такого сотрудника есть другие задачи, которыми он хочет и может заниматься. Если нет - увы!
При назначении исполнителей необходимо учитывать их общую загрузку. Возможно, человек, на которого вы рассчитываете, уже участвует в других проектах. Или выполняет какие-то другие обязанности. Значит, в вашем проекте он не сможет участвовать пять дней в неделю.
И еще один момент, о котором часто забывают. Административная работа тоже требует времени! И чем больше участников в проекте, тем больше времени нужно на администрирование. Соответственно, и нагрузку на себя руководитель должен планировать с учетом административных задач. Чтобы сократить объем административных задач для Руководителя (например, если он превосходит естественные возможности) можно ввести среди участников проекта внутреннюю структуру и назначить руководителей групп. В этом случае административную работу придется планировать и для них. Причем учтите, что если у вас нет обученных и проверенных руководителей групп, в начальный период вам придется тратить на работу с ними существенно больше времени, чем на рядовых подчиненных!
Пятая стадия - планирование резерва.
Как бы тщательно вы ни планировали, в проект надо заложить определенный резерв на случай непредвиденных ситуаций. Увы, руководство и Заказчики редко соглашаются с этим тезисом. Возможный вариант преодоления такой ситуации - подготовьте несколько планов с разным временем выполнения, штатом и бюджетом (но каждый с запасом). Пусть лучше они выбирают из предложенных планов, а не ковыряются в единственном. Так больше шансов на то, что они не будут возражать против резервов.
А помимо резервов стоит иметь заранее заготовленные планы, что вы будете делать, если что-то пойдет не так. Впрочем, это обычно называется управлением рисками. И в любом руководстве по управлению рисками все это описано более детально.
Пятая стадия знаменует завершение планирования очередной итерации. Теперь пора браться за выполнения планов. И здесь правила не сложнее.
Стадия шесть. Определите, кто из исполнителей требует какого контроля с вашей стороны. Идеальный исполнитель выполняет все, что ему поручили. За другими приходится следить, контролировать скорость выполнения, помогать принимать технические решения... С первыми работать приятно. А с остальными - необходимо. Увы, надо больше времени уделять тому, что необходимо. Таким образом, стадия переходит в принцип: "уделяйте больше внимания тем, кому ваша помощь необходима".
Стадия семь. А здесь, наоборот, принцип превращается в набор работ. Вы должны знать все, что происходит в проекте. И поэтому рабочий день Руководителя начинается с того, что он выясняет, завершены ли работы, которые должны были быть завершены. Начаты ли работы, которые должны были быть начаты. И у кого какие проблемы возникли.
Кроме того, в понедельник хорошо собрать всех (или хотя бы руководителей групп, если проект слишком велик) и обговорить планы на неделю. А в пятницу подвести итоги недели.
Ну а еще нужно контролировать ход проекта по косвенным признакам. Если люди получают удовольствие, - скорее всего, все идет нормально. А вот если есть проблемы в личных отношениях, никто не радуется, то это подозрительно.
Даже если проект пока идет по графику.
Стадия восемь. Информация о ходе выполнения проекта должна быть доступна всем: участникам проекта, Руководству и Заказчику. Может быть, не все должны знать все в полном объеме. Но лгать нельзя никому. Идеальное решение, это еженедельный отчет. Желательно сделать его многоуровневым. Так чтобы на самом верхнем уровне можно было получить ответ на вопрос "Проект в графике?". А на нижнем - сведения по отдельным задачам.
Если все в курсе состояния дел по проекту, то все и действуют адекватно этому состоянию. То есть, если вдруг обнаружилось некоторое отставание, то участники хорошо сработавшейся команды стараются повысить производительность или задержаться после конца рабочего для даже не рассчитывая на оплату сверхурочных. Кстати говоря, и с Заказчиком проще договориться о продлении сроков проекта, если он был в курсе возникавших проблем.
И так до конца итерации. Потом повторить все с самого начала. Не забудьте проверить, не изменились ли ваши цели! Спланируйте следующую итерацию. И выполните ее.
И вот после последней итерации вы, наконец, завершили этот проект! Как пишут в рекламе, вы это заслужили! Но пока все еще в памяти, не забудьте подвести итоги. Что оказалось не так, как вы предполагали изначально? Почему?
На этом книга не заканчивается. В ней приведена масса же конкретных рекомендаций по другим достаточно важным проблемам, часто встающим перед руководителями проектов. Это особенности работы при необходимости одновременно вести несколько проектов. Это принципы разработки и рецензирования планов проекта. Это способы снятия напряжения, приемы разрешения проблем и принятия решений, ведения переговоров и многое другое. И в заключение достаточно полный курс для освоения MS Project.
Надо отметить, что для иллюстрации этапов и принципов управления проектами автор использует много интересных примеров из истории экспедиций Амундсена и Скотта к Южному полюсу и из истории Гражданской войны в США.
Но вернемся к началу.
Сумел ли автор найти серебряную пулю? Неужели разработка ПО остается рискованной только потому, что не все прочитали эту книгу?
Честно говоря, странное ощущение осталось у меня после этой книги. С одной стороны, ну что здесь нового? Все содержание книги можно пересказать в одной фразе. Тщательно управляйте проектом!!! Именно так, с тремя восклицательными знаками. И это - чудодейственная серебряная пуля?
А с другой стороны, разве этого не достаточно, чтобы гарантировать успех? Ведь успешные проекты были во все времена, с использованием всех методологий разработки. И отличались они ни чем иным, как наличием качественного управления. Оно часто было практически незаметно. Начальник не драл глотку и не стучал кулаком по столу. Просто каждый знал, за что отвечает лично он. Когда он должен это сделать. И чем будет заниматься после.
А если вдруг происходило какое-то неприятное и вроде бы совершенно непредвиденное событие, то оказывалось, что к нему все в существенной мере уже готовы. А недостающие детали быстро уточняются и доводятся до всех участников. И проект, лишь слегка поскрипывая на, казалось бы, непреодолимых буераках, весело катит вперед к успешному завершению.
Но если все так просто, то почему же мы никак не забудем про проекты, не уложившиеся в график, в смету, а то и вовсе завершившиеся пшиком? И даже не исследовательские, экспериментальные, прорывные, а такие скромные, типовые проекты...
Потому, что научить правильному стилю руководства очень сложно. Если вы прочитали книжку по UML, то, худо-бедно, вы будете рисовать и понимать UML диаграммы. Если вы прочитали руководство по IDEF1, вы будете понимать диаграммы в нотации IDEF1. А если вы прочитали книжку по структурному управлению проектами, вы, конечно, можете выучить 10 стадий. Но не факт, что вы сумеете их применить.
Вы не верите? Начнем с ключевой стадии. Готовы ли вы признать, что, если проект провалился, то это именно вы лично как руководитель проекта привели его к провалу?
На словах все мы готовы согласиться с тем, что Руководитель должен отвечать за проект.
А на деле часто думаем примерно так: "Но ведь я хороший! Это вот только подчиненные мне достались так себе, если не сказать прямее… Иванов в три раза дольше, чем было запланировано, возился со своим модулем! А Петрова вообще в декрет ушла! А кем я ее заменю? А Сидоров? Ну, переназначили его пять раз на новую задачу до того, как он предыдущую доделал. Но ведь это для проекта так нужно было, а он обижается! И после этого, вы скажете, что я плохо руководил, и поэтому проект затянулся на три года вместо шести месяцев? Да дали бы мне нормальных программистов, я бы... А если я планы не писал, так это для того, чтобы больше времени самому программировать. Если бы не я, вообще неизвестно, закончили ли бы мы этот проект хоть когда-нибудь!"
К сожалению (для проектов, но к счастью для нас самих), человеку свойственно оправдывать самого себя. Поэтому подчиненные валят все на начальников, а начальники - на подчиненных. И далеко не у всех хватает характера и навыков реально проанализировать "А что я сделал не так? А как это можно было сделать лучше?" И еще у меньшего числа людей получается после честных ответов на эти вопросы в следующий раз действительно сделать все лучше, чем в предыдущий. А то ведь тоже нередко можно услышать: "Нет, писать детальные планы - это не для меня!"
Так что серебряные пули есть. Просто они не всем помогают. И если у героя, которому принадлежат слова, взятые в качестве эпиграфа, с ними ничего не получилось, то надо еще разбираться, в чем проблема: в пулях или в герое.
Если же вы все-таки сумеете переломить себя и тщательно спланировать проект… Пусть даже не в MS Project, и даже не на бумаге, а в голове по дороге на работу… Если вы будете помнить, кто из разработчиков чем занят, и тщательно продумывать, кому какую следующую работу лучше назначить… Короче, попробуйте, а вдруг у вас получится!
Ну и еще одно замечание. Даже с самыми замечательными серебряными пулями, чтобы проект был выполнен качественно и в срок, нужно много пота.В том числе от Руководителя проекта. Не скажу, что это гарантирует успех. Скажу по-другому, это делает успех возможным.
Так что не надейтесь, что, прочитав эту книгу, вы получите чудодейственное средство, с помощью которого вы решите все ваши проблемы. Но знакомство с ней позволит вам если не качественнее выполнять ваши обязанности, то, по крайней мере, сравнить свои навыки и привычки как руководителя с опытом неплохого специалиста.
