Скотт Беркун - Сделано

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

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

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

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

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

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

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

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

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

Сосредоточившись на методе и процедуре, вместо того чтобы выстраивать процедуры в помощь людям, МП приступают к планированию, ограничивая вклад отдельных сотрудников. Они акцентируют внимание на правилах и их соблюдении, вместо того чтобы учить сотрудников думать, адаптировать, совершенствовать эти правила. Так что любую методологию следует использовать крайне осторожно: нельзя навязывать ее команде [22]. Напротив, методология должна поддерживать, стимулировать команду, помогать ей достичь результата (в главе 10 вы найдете советы на эту тему).