Читать книгу Искусство управления IT-проектами - Скотт Беркун - Страница 9

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

К примеру, я знаю одного веб-разработчика, который искренне верит в то, что его работа не похожа ни на какую другую за всю мировую историю. Он считает, что его проект и управление задачами непохожи ни на что из ранее существовавшего, поскольку в процессе веб-разработки он должен принимать сложные инженерные решения, связанные с проектированием и согласованием, а также проверкой изменений буквально в течение нескольких часов или даже минут, а потом публиковать результаты своей работы во Всемирной сети. Он с гордостью перечисляет технологии, которыми овладел, – 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» (Мифический человеко-месяц), касающейся разработки программ, проводит схожие параллели между командами хирургов и программистов. Несмотря на то что при разработке веб-сайтов или баз данных жизни мало что угрожает, люди из разных команд могут столкнуться с многими схожими ситуациями и сложностями.