Сделано
Шрифт:
Три задачи графика
Любые графики, идет ли речь о подготовке вечеринки или обновлении сайта, служат трем целям. Первая – наметить, когда что будет сделано. График – это своеобразный контракт с каждым участником процесса, подтверждающий, что он выполнит свои задачи за определенный период времени. Как правило, это первое, что вспоминают в связи с графиком проекта. Графики зачастую направлены за рамки проектной команды, на внешние цели, а не на внутренние. Их используют, чтобы заключить сделку или согласовать сроки с клиентом. Последний часто платит не только за услугу, но и за своевременность ее оказания (например, UPS или FedEx). Чтобы дать клиентам и партнерам возможность строить планы, опираясь на конкретный проект, следует обговорить, когда произойдут те или иные вещи.
Вторая задача графика в том, чтобы каждый сотрудник рассматривал
Только когда все детали будут записаны с именами людей рядом с каждой задачей, можно сделать реальные расчеты и проанализировать допущения. Это касается даже небольших команд или работников-индивидуалов. График обладает психологической силой, так как публично демонстрирует все обязательства. Сложно забыть или проигнорировать то, что вывешено на доске в коридоре и напоминает всей команде о необходимости выполнения намеченного. Когда есть предварительный график, менеджеры могут поднять вопрос о том, насколько реально выполнить некоторые задачи, и сравнить требования к проекту с имеющимися возможностями.
Этот психологический сдвиг называется функцией принуждения. Функция принуждения – это все, что (при реализации) естественным образом вынуждает изменить мировоззрение, отношение или поведение. Итак, графики – важные вынуждающие функции для проектов. При грамотном применении они обязуют всех тщательно обдумать работу, которую нужно сделать. Эта функция – критически важный шаг к реализации потенциала проекта. Даже если та или иная работа сорвется или займет в два раза больше времени, обязательства и связи, выстроенные в результате предварительного графика, можно соблюсти. Итак, вторая задача графика способна полностью сохранить свою ценность, даже если сам график окажется неточным. К примеру, если проект сильно отстает от сроков, наличие графика все равно позволит довести его до конца.
Третья задача графика – дать инструмент для мониторинга и разделения работы на небольшие части. Если разбить работу на задачи, которые занимают день или два, людям легче понять, что нужно делать. Представьте, что строителям дома дали только одно указание: построить дом за 120 дней. С такой слабой детализацией всем, включая прораба, будет сложно понять ход работы. Но если прораб сможет составить еженедельный график работы, то остальные поймут, какие задачи и когда необходимо выполнить, в чем заключаются приоритеты команды, и смогут задать значимые вопросы, уточнить те или иные допущения. С точки зрения МП, хороший график рисует четкую картину проекта, уже на раннем этапе отмечает трудные места, а также повышает вероятность того, что нужный результат будет достигнут.
Чем масштабнее и сложнее проект, тем важнее график. В крупных проектах больше зависимостей между людьми, а решения и сроки сильнее влияют друг на друга. Проблемы в работе намного проще распознать членам небольшой команды. Когда у последней срывается график, это плохо, однако если опоздание составляет полдня, то понадобится еще полдня и дополнительные усилия всего трех человек, чтобы восстановиться. Кто-то останется в офисе допоздна или, если нужно, вся команда может собраться и помочь наверстать упущенное. На крупных проектах, с десятками или сотнями участников и компонентов, отставание на один день может быстро перерасти в серьезную проблему и вызвать сбой в самых неожиданных областях. Зачастую ни о каком восстановлении речь уже не идет. Но и в большой, и в маленькой команде графики дают менеджерам возможность задавать вопросы, вносить коррективы и помогать команде выявлять проблемы и реагировать на них по мере их появления.
С учетом этих трех задач сразу видно, что даже идеальный график не решает всех проблем проектов. График не исправит плохого проектирования или некорректной разработки и не защитит проект от слабого менеджмента, нечетких целей и неэффективной коммуникации. Несмотря на то что составление хорошего графика тоже требует немалого времени, нельзя забывать, что это всего лишь список слов и цифр. Кто-то должен использовать их как инструмент управления и стимулирования проекта. Так что пора заняться терминологией и изучить методологию программного обеспечения – тяжелую артиллерию проект-менеджмента.
Палочка-выручалочка и методология
Существует
Однако моя цель в этой главе, да и в книге, не в том, чтобы сравнивать различные методологии. Напротив, я считаю, что нужно овладеть концепциями, на которые они все опираются, чтобы преуспеть с любой из них. Методологию всегда следует адаптировать и корректировать под спецификации каждой команды и проекта, а это возможно, только когда ваши знания намного глубже поверхностных. Итак, если вы прислушаетесь к основным идеям этой главы и книги, вероятность вашей эффективности возрастет, независимо от того, какой методологией вы пользуетесь. Я объясню аспекты некоторых методов, однако если вам нужен подробный анализ, его придется поискать в других источниках [20] . Хотя методы разработки программного продукта важны, это не палочка-выручалочка. Худшее, что можно сделать, – слепо соблюдать правила, которые явно не работают, просто потому, что они указаны в какой-нибудь известной книге или рекомендуются авторитетным экспертом. Зачастую зацикленность на процессе – тревожный признак: она может свидетельствовать о попытке менеджера уклониться от трудностей и ответственности или погрузиться в бюрократические процедуры, которые заменяют настоящие лидерские действия. Более того, одержимость методологией иногда указывает на слабые стороны организации. Как Том ДеМарко пишет в книге «Человеческий фактор» [21] :
20
Подробное сравнение традиционных методов разработки программного продукта и agile-метода можно найти здесь: Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner (Addison-Wesley, 2003).
21
ДеМарко Т., Листер Т. Человеческий фактор. Успешные проекты и команды. СПб.: Символ-Плюс, 2011.
Одержимость методологией – еще один пример иллюзии высоких технологий. Люди убеждены, что самое главное – технология. ‹…› Но какими бы ни были технологические преимущества, они возможны лишь за счет значительных жертв со стороны команды.
Сосредоточившись на методе и процедуре, вместо того чтобы выстраивать процедуры в помощь людям, МП приступают к планированию, ограничивая вклад отдельных сотрудников. Они акцентируют внимание на правилах и их соблюдении, вместо того чтобы учить сотрудников думать, адаптировать, совершенствовать эти правила. Так что любую методологию следует использовать крайне осторожно: нельзя навязывать ее команде [22] . Напротив, методология должна поддерживать, стимулировать команду, помогать ей достичь результата (в главе 10 вы найдете советы на эту тему).
22
Подробнее о том, как осмыслить изменения в процессе разработки софтверного продукта и управлять ими, см. Watts S. Humphrey Managing the Software Process (Addison-Wesley Professional, 1989).
Соблюдение (или несоблюдение) сроков никогда не зависит только от выбранной методологии. Существуют факторы, которые влияют на все проекты, и МП должны понять их до того, как составлять график работы. Однако прежде чем обсудить это, давайте перечислим компоненты графика.
Как выглядят графики
Есть одно базовое правило для графиков – правило третей. Расчет будет приблизительным или, как говорится, на коленке, однако это самый простой способ понять графики. Если у вас большой опыт их составления, вас сейчас точно передернет – я собираюсь максимально упростить весь процесс. И делаю это с целью буквально на пальцах объяснить, что, почему и как может пойти не по плану и что с этим делать.