Нужно учиться на ошибках

«Люди, уникальность которых [среди животных] заключается в способности учиться на чужом опыте, также отличаются отсутствием склонности к подобному обучению».

Дуглас Адамс (Douglas Adams)

При изучении истории разработки проектов возникает один простой вопрос: почему кто бы то ни было охотно страдает от ошибок и разочарований, которых можно было бы избежать? Если перед нами открыта как древняя, так и современная история работы над проектами и нам платят за то, чтобы мы совершали разумные поступки, независимо от того, откуда мы черпаем вдохновение, почему поощрения за извлечение уроков истории столь редко проявляются со стороны организаций? Хотя проекты завершаются или закрываются (а ведь многие проекты по разработке именно так и заканчиваются^[2]) ежедневно, практически ничего не делается для изучения причин произошедшего. Создается впечатление, что менеджеры большинства организаций крайне редко поощряют людей за поиски сведений в этом направлении. Возможно, в этом проявляется страх перед тем, что будет найдено (и страх перед ответственностью за это). А может быть это просто отсутствие интереса с чьей-либо стороны к анализу неприятных или печальных событий, в то время как время вместо этого может быть потрачено на продвижение к следующему, новому изделию.

В книге Генри Петроски (Henry Petroski) «To Engineer Is Human: The Role of Failure in Successful Design» (Vintage Books, 1992) автор описывает множество прорывов в разработках, происходивших благодаря провалам. В частности, такое случается из-за того, что провалы заставляют нас пристальнее к чему-нибудь приглядываться. Они требуют от нас пересмотра подзабытых предположений (трудно притворяться, что все в порядке, когда прототип горит ярким пламенем). Как говорил Карл Поппер (Karl Popper^[3]), есть только два вида теорий: неправильные и несовершенные. Без провалов мы самонадеянно забываем, что наше понимание вещей не настолько совершенно, насколько мы думаем.

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

Возможно, именно поэтому компания «Боинг», одна из крупнейших фирм по разработке и производству авиационной техники, ведет черную книгу уроков, извлеченных из конструкторских и инженерных просчетов.^[4] Боинг ведет эту документацию со дня основания компании и использует ее для помощи современным конструкторам в извлечении уроков из прошлого. Любая организация, организовавшая подобную практику, не только повысит свои шансы на осуществление успешных проектов, но также поможет создать среду, в которой можно будет открыто обсуждать промахи и противостоять им, вместо того чтобы не признавать их существования и прятаться от них. Пожалуй, разработчикам программного обеспечения неплохо было бы завести свою собственную черную книгу.

Веб-разработка, кухни и пункты первой помощи

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

К примеру, я знаю одного веб-разработчика, который искренне верит в то, что его работа не похожа ни на какую другую за всю мировую историю. Он считает, что его проект и управление задачами непохожи ни на что из ранее существовавшего, поскольку в процессе веб-разработки он должен принимать сложные инженерные решения, связанные с проектированием и согласованием, а также проверкой изменений буквально в течение нескольких часов или даже минут, а потом публиковать результаты своей работы во Всемирной сети. Он с гордостью перечисляет технологии, которыми овладел, – CSS, XHTML, Flash, Java, – утверждая, что каких-нибудь 50 лет назад они могли бы озадачить самые светлые умы человечества. Я уверен, что вам тоже попадались подобные люди. А может быть и у вас складывались ситуации, когда казалось, что еще никто и никогда не решал такие сложные проблемы.

Я предложил бы этому разработчику пройти как-нибудь в разгар рабочего дня на кухню его любимого кафе. Побывать на кухне интересно по многим причинам (почитайте замечательную книгу Энтони Бурдэйна (Anthony Bourdain) «Kitchen Confidential» (Ecco, 2001), но мое внимание привлекла производительность работы. Когда впервые сталкиваешься с такой оперативностью управления и скоординированностью действий команды, какие бывают в час пик на профессиональной кухне, начинаешь по-другому относиться к сложности собственной работы. Повара зачастую просто жонглируют сковородками, на которых жарятся блюда из разных заказов, находящиеся в разной степени готовности, и протискиваются между плитами, расположенными в противоположных концах кухни, а официанты тем временем носятся туда-сюда, сообщая о все новых и новых запросах и капризах посетителей.

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

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

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

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

Мир медицины, особенно травматология, являет собой превосходный образец командной работы, принятия решений в критических ситуациях и результатов реализации проектов, которые ежедневно влияют на судьбы многих людей (на рис. 1.1 дается примерное сравнение этой и других областей работы). Атул Гаванде (Atul Gawande) в своей превосходной книге «Complications: A Surgeon’s Notes on an Imperfect Science» (Picador USA, 2003) написал следующее:

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

Это высказывание, как и многие другие в весьма поучительной книге Гаванде, справедливо и в отношении разработки программного обеспечения. Фред Брукс (Fred Brooks) в классической книге «The Mythical Man-Month» (Мифический человеко-месяц), касающейся разработки программ, проводит схожие параллели между командами хирургов и программистов. Несмотря на то что при разработке веб-сайтов или баз данных жизни мало что угрожает, люди из разных команд могут столкнуться с многими схожими ситуациями и сложностями.

Роль управления проектами

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

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

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

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

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

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

Управление программами и проектами в Microsoft

В конце 80-х годов компания Microsoft решала непростую проблему увязывания инженерных работ с маркетинговыми и бизнес-задачами каждого подразделения (кто-то может сказать, что Microsoft и многие другие компании до сих пор не могут решить эту проблему). Некий мудрец по имени Джейб Блюменталь (Jabe Blumenthal) додумался до того, что должна быть специальная должность, и ее исполнитель будет занят выполнением этих двух функций, одновременно играя роль лидера и координатора. Он должен был работать над проектом с первого дня планирования и до последнего дня тестирования. На такую должность следовало бы взять того, кто достаточно хорошо разбирается в программировании, чтобы снискать уважение программистов, но это также должен быть человек, не обделенный талантами и имеющий заинтересованность в более широком участии в создании конечного продукта.

Чтобы работать в этой роли, этот сотрудник должен иметь склонность к такой разносторонней деятельности, как составление технических условий, обсуждение маркетинговых планов, составление календарных планов, управление командами, осуществление стратегического планирования, выполнение классификации ошибок и дефектов, поддержание командного духа, а также выполнение ряда других необходимых функций, которыми кроме него больше некому как следует заняться. Эта новая роль в компании Microsoft получила название руководителя проектов. В его непосредственное подчинение попадали не все специалисты команды, но руководителю проектов давались существенные полномочия по руководству и управлению проектом. (В теории управления это примерно соответствует идее матричной организации управления,^[5] при которой существуют две линии структуры подчиненности специалистов: одна основана на функциях специалиста, а другая – на конкретном проекте. Таким образом, программист или тестировщик может иметь двойную подчиненность: основную, в соответствии со своей функциональной ролью, и второстепенную, но не менее серьезную, в соответствии с проектом, над котором он работает.)

Джейб сыграл эту роль в разработке продукта под названием Multiplan (который впоследствии перерос в Microsoft Excel), и опыт оказался удачным. В результате улучшились процессы проектирования и разработки, а заодно улучшилась и координация усилий с бизнес-командой, и настроение в коридорах Microsoft существенно повысилось. Постепенно, после множества совещаний и собраний большинство команд компании приняли эту роль. Чтобы вы ни говорили плохого или хорошего о появившихся в результате этого программных продуктах, но идея все-таки была стоящей. Определив роль для рядового универсала, причем не в качестве какого-то мальчика на побегушках или лакея, а в качестве лидера и ведущего команды, компания Microsoft навсегда изменила динамику работы команд разработчиков. Именно в этой роли руководителя проектов я выступал большую часть периода своей работы в этой компании, работая с командами, создававшими помимо всего прочего, Internet Explorer, MSN и Windows. Со временем я даже стал руководить командами руководителей проектов.

На сегодняшний день я не слышал, чтобы многие компании преуспели в переопределении и ввели какие-то особые формы управления проектами. Я много общался с представителями разных фирм, занимающихся веб-разработкой и разработкой программного обеспечения, но всего лишь несколько раз слышал о наличии у них похожей должности (обычно речь шла о сотрудниках, которые решали инженерные или деловые вопросы или, в редких случаях, – вопросы проектирования). Многие компании в организации работ использовали командную структуру, но лишь немногие определяли роли, в которых заведомо пересекались инженерная и деловая соподчиненности. Сейчас в Microsoft работают более 5000 руководителей программ (всего в этой компании более 80 000 человек), и хотя сам смысл идеи был несколько размыт и искажен, ее основное содержание можно найти во многих командах компании.

Независимо от того, что написано в моей визитке или каким сведениям от Microsoft вы верите, а каким нет, мои ежедневные функции сводились к функциям руководителя проектов. Проще говоря, это означало, что именно я нес по мере сил ответственность за успешную реализацию проекта и за всех его участников. Во всех главах данной книги описываются основные задачи, связанные с этой деятельностью, от исходного планирования (главы 3 и 4) до составления технических условий (глава 7) и процесса принятия решений (глава 8) и заканчивая руководством разработкой продукта и его выпуском (главы 14 и 15).

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