Текст бизнес-книги "Сделано"

Автор книги: Скотт Беркун

Раздел: Зарубежная деловая литература, Бизнес-книги

Резюме

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

• Управление проектами встречается повсюду и существует с незапамятных времен.

• С «сознанием новичка» перед вами откроется гораздо больше возможностей для обучения.

• Управление проектами может быть должностью, функцией или работой (советы из этой книги применимы ко всем вариантам).

• Программный менеджмент – это четко очерченная роль менеджера проекта в Microsoft, которая опирается на принцип матричной организации.

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

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

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

Упражнения

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

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

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

Г. Вспомните какой-нибудь провальный проект. Чему вы научились и как именно? Перечислите допущенные ошибки. Что можно изменить в следующий раз, чтобы не наступать на те же грабли? Записав это, вы сможете тщательнее обдумать все вопросы и извлечь максимум знаний из своего опыта.

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

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

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

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

Часть первая. Планирование

Глава вторая. Вся правда о графиках работы

Люди склонны опаздывать. Пусть даже всего на несколько минут или всего несколько раз в неделю, но они отстают от графика. (Отрицание – еще одна потрясающая черта человеческой натуры, поэтому я пойму, если вы считаете, что это не про вас.) Старшеклассники опаздывают на занятия, взрослые – на рабочие встречи. Даже друзья приезжают в бар на десять минут позже. Мы считаем, что «прийти вовремя» – это значит прийти не в определенный момент, а в определенный интервал времени. И для одних этот интервал шире, чем для других. Администраторы ресторанов – любопытный пример. Например, они заверяют, что столик скоро освободится[19]19
  Однажды, когда мы с друзьями зашли пообедать в Pizzeria Uno в Питтсбурге, нам сказали, что столик будет готов через десять минут. Ровно через десять минут мой друг Чед МакДаниэль поинтересовался насчет обещанной готовности. Администратор снова ответила, что столик будет готов через десять минут. Чед спросил: «Это те же десять минут или другие?» Шутку она не оценила.


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

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

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

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

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

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

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

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

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

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

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

Однако моя цель в этой главе, да и в книге, не в том, чтобы сравнивать различные методологии. Напротив, я считаю, что нужно овладеть концепциями, на которые они все опираются, чтобы преуспеть с любой из них. Методологию всегда следует адаптировать и корректировать под спецификации каждой команды и проекта, а это возможно, только когда ваши знания намного глубже поверхностных. Итак, если вы прислушаетесь к основным идеям этой главы и книги, вероятность вашей эффективности возрастет, независимо от того, какой методологией вы пользуетесь. Я объясню аспекты некоторых методов, однако если вам нужен подробный анализ, его придется поискать в других источниках[20]20
  Подробное сравнение традиционных методов разработки программного продукта и agile-метода можно найти здесь: Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner (Addison-Wesley, 2003).


[Закрыть]. Хотя методы разработки программного продукта важны, это не палочка-выручалочка. Худшее, что можно сделать, – слепо соблюдать правила, которые явно не работают, просто потому, что они указаны в какой-нибудь известной книге или рекомендуются авторитетным экспертом. Зачастую зацикленность на процессе – тревожный признак: она может свидетельствовать о попытке менеджера уклониться от трудностей и ответственности или погрузиться в бюрократические процедуры, которые заменяют настоящие лидерские действия. Более того, одержимость методологией иногда указывает на слабые стороны организации. Как Том ДеМарко пишет в книге «Человеческий фактор»[21]21
  ДеМарко Т., Листер Т. Человеческий фактор. Успешные проекты и команды. СПб.: Символ-Плюс, 2011.


[Закрыть]:

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

Сосредоточившись на методе и процедуре, вместо того чтобы выстраивать процедуры в помощь людям, МП приступают к планированию, ограничивая вклад отдельных сотрудников. Они акцентируют внимание на правилах и их соблюдении, вместо того чтобы учить сотрудников думать, адаптировать, совершенствовать эти правила. Так что любую методологию следует использовать крайне осторожно: нельзя навязывать ее команде[22]22
  Подробнее о том, как осмыслить изменения в процессе разработки софтверного продукта и управлять ими, см. Watts S. Humphrey Managing the Software Process (Addison-Wesley Professional, 1989).


[Закрыть]. Напротив, методология должна поддерживать, стимулировать команду, помогать ей достичь результата (в главе 10 вы найдете советы на эту тему).

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

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

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

Согласно правилу третей, один день вы должны уделить написанию кода, один день – планированию и один день – тестированию и исправлению ошибок (рис. 2.1). Что может быть проще! Это удобный способ проверить существующий график или составить новый с нуля. Если общее количество времени не делится на три части, должны быть очевидные причины, почему проект требует неравномерного распределения усилий. Дисбаланс в правиле третей (например, тестированию уделяется на 20 % больше времени, чем внедрению) допустим, если он не случаен.

Рис. 2.1. Примитивное правило третей в графике проекта

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

ПОЭТАПНАЯ РАЗРАБОТКА (АНТИПРОЕКТ)

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

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

РАЗДЕЛЯТЬ И ВЛАСТВОВАТЬ (БОЛЬШИЕ ГРАФИКИ = МНОГО МАЛЕНЬКИХ ГРАФИКОВ)

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

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

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

Agile и традиционные методы

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

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

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

Рис. 2.2. Масштабный проект представляет собой последовательность небольших проектов

Вот и все по поводу методологии планирования. В главе 14 и главе 15 мы поговорим о том, как управлять проектом, однако сделаем акцент на функциях менеджера и лидера, а не на подробном применении конкретной методологии. Если вы прочитали последние два параграфа (даже если вы не согласны с моим мнением), то советы из главы 14 и главы 15 будут актуальны и полезны для вас независимо от того, как вы организуете или планируете свой проект.

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

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

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

СТРЕЛЬБА ВСЛЕПУЮ С ОГРОМНОГО РАССТОЯНИЯ

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

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

Барри Боэм в своем эссе 1988 года на тему разработки ПО[23]23
  “Understanding and Controlling Software Costs,” IEEE Transactions on Software Engineering, vol. 14, no. 10, October 1988, pp.1462–77; а также Barry Boehm Software Engineering Economics (Prentice Hall, 1991).


[Закрыть] пришел к выводу, что ошибки графиков растут пропорционально тому, насколько рано сделаны предположения (рис. 2.3). Если общий расчет графика осуществлен рано, он может попасть мимо цели аж на 400 %, причем в обоих направлениях (подозреваю, что ошибки в графике всегда играют против нас, отнимая больше времени, чем мы ожидали). На этапе проектирования, когда многие решения становятся очевидными, диапазон отклонений от графика немного сужается. Только когда проект перейдет в стадию реализации, расчеты становятся обоснованными и реалистичными, но даже тогда остается 20 %-ная вероятность того, что график недостаточно точен.

Рис. 2.3. Диапазон возможных отклонений от сроков проекта (адаптировано из Software Engineering Economics Боэма)

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

ГРАФИК – ЭТО ВЕРОЯТНОСТЬ

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

Мы бурно обсуждали и согласовывали его отличия от графика, который составляли опираясь на конкретные задачи[24]24
  Графики, основанные на задачах программистов, принято называть графиками «снизу вверх». Графики, основанные на решении менеджмента, называются графиками «сверху вниз». Как правило, отличия между ними обговариваются и согласуются.


[Закрыть]. «Генплан» спускали сверху, и он был великолепно «причесанным», с аккуратными колонками, датами и цифрами. Словно некий артефакт, выкраденный из будущего.

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

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

Итак, если все члены команды согласны, что график – это ряд предположений, то проблемы не в нем самом, а в его применении. Если график показывают на встрече команды или отправляют всем по электронной почте, возникает вопрос: насколько реальны указанные сроки? Если, например, не указаны пять самых вероятных рисков и прогнозы по ним, и тот, кто составил график, не может объяснить свои предположения, следует признать, что график возможен, но нереален[25]25
  Любой график – лишь один из многих возможных вариантов. В зависимости от того, какие непредвиденные факторы (ошибка проектирования, политическая революция, нападение пришельцев и т. д.) в нем учитываются, сроки могут быть разными. Без учета вероятных ошибок график не может быть надежным: его автор не проявил достаточно креатива или скептицизма.


[Закрыть]. Команда должна высказать свое мнение – какие соображения и какую информацию можно добавить или изменить, чтобы он стал более правдоподобным.

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

ДЕЛАТЬ ПРОГНОЗЫ СЛОЖНО

На этапе проектирования (глава 5 и глава 6) одна из задач команды – разбить проект на небольшие части. Эти части, которые нередко называют элементами (единицами) работы или иерархической структурой работ (work breakdown structure, WBS[26]26
  Многие учебники и руководства описывают, как выстроить структуру разделенной работы. Я коснусь этой темы в главе 14, однако если вы хотите получить более подробную информацию, начните с http://en.wikipedia.org/wiki/Work_breakdown_structure или Total Project Control, Stephen Devaux (Wiley, 1999).


[Закрыть]), становятся пунктами общего графика проекта. Элементы работы (скрестим пальцы) оптимально распределяются[27]27
  В книге Кента Бека Extreme Programming Explained (Addison-Wesley, 1999) (Бек К. Экстремальное программирование. Разработка через тестирование. СПб.: Питер, 2017) предлагается модель распределения работы для программистов, где они сами выбирают рабочие единицы. В идеале это решение – компромисс между благом проекта и благом членов команды.


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

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

Мир основан на прогнозах

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

Как показывает мой опыт, даже те, кто понимает процесс прогнозирования и верит в него, не любят этим заниматься. Отчасти из-за нестыковки предположений («Как же это сделать, если у меня так мало информации?») с временными рамками («Скажите точно, сколько часов займет эта работа»). Однако никаких поблажек быть не должно: все, кто работает в проектировании и строительстве, решают примерно одинаковые «головоломки», будь то строительство небоскреба, ремонт кухни или запуск космического корабля на другие планеты. Если почитать, как все эти люди делают прогнозы, то вы увидите, что их проблемы и методы не слишком отличаются от сфер разработки или программного обеспечения. Основное отличие в том, сколько времени им дают на расчеты и насколько дисциплинированно они его распределяют (мы обсудим это подробнее в главе 5 и главе 6).

ГРАМОТНЫЕ ПРОГНОЗЫ ЗАВИСЯТ ОТ КАЧЕСТВЕННОГО ПРОЕКТИРОВАНИЯ

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

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

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