Скотт Беркун – Искусство управления IT-проектами (страница 22)

В чем ценность ведения записей

Дэниел Бурстин (Daniel Boorstin), автор великолепных работ «The Creators» (Vintage, 1993) и «The Discoverers» (Vintage, 1985), как-то сказал, что письменное слово было величайшей из всех технологий, когда-либо изобретенных человеком. Без него нам пришлось бы всецело зависеть от нашей печально известной своей дырявостью памяти,[24] занимаясь такими сложными вещами, как создание динамита (гм, в каком весовом соотношении должны быть нитроглицерин и древесный уголь?) или ядерного реактора (а куда исчезает уран?). Применительно к работе над проектом записи дают возможность однократно определить характер технической работы или зафиксировать общие для всей команды цели, а затем многократно использовать эти сведения. Документирование деталей принятых решений перекладывает с нашей памяти на бумагу все заботы о точности их формулировок и сохранности, после чего их можно восстановить в памяти, всего лишь взглянув на записи. Такая разгрузка памяти позволяет нам решать поставленную задачу полным ходом, имея под рукой ее описание, и пребывать в полной уверенности, что мы всегда, если понадобится (собьемся с курса, столкнемся с разногласиями или запутаемся), сможем вернуться к написанному. Из этого следует, что чем больше в работе сложностей и чем больше прилагаемых к ней усилий, тем выше вероятность того, что запись некоторых деталей решения повысит шансы на ее успешное выполнение.

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

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

Какой по объему концептуальный документ вам нужен?

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

Рассмотрение следующих вопросов поможет вам определить структурную сложность и трудоемкость вашего концептуального документа:

• Много ли обоснованных вопросов имеется у самой команды относительно будущей работы? Насколько люди осведомлены о предстоящей работе и о важности ее результатов?

• Сколько разных людей будет вовлечено в реализацию проекта? Сколько различных организаций представляют эти люди? Каким образом вы сможете правильно оценить ожидаемый вклад каждой организации?

• Насколько подробно вам лично хотелось бы обосновать заложенные в концепцию решения. (Удачно составленная концепция способна сама по себе дать многим вполне достаточное представление о сути проекта.)

• В какой мере вы допускаете влияние сторонних организаций на основную направленность проекта?

• Сколько проницательности, компетентности и рассудительности потребуется от руководителя проекта при принятии ключевых проектных решений? (Очевидно, именно эти свойства будут востребованы при выработке концепции.)

• Насколько глубоко команда сможет вмешиваться в стратегию проекта в процессе работы над его реализацией?

• Какие объемы исследований в процессе планирования проекта ожидает от вас руководство? Как вы будете доводить до руководства результаты этих исследований?

• Возникнет ли в последующем необходимость напоминать команде о целях проекта? Склонны ли сотрудники возвращаться к спорам по отдельным положениям, с которыми они совсем недавно согласились?

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

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

Общекомандные и индивидуальные цели

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

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

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

 Индивидуальные цели. Подраздел общекомандных целей, являющийся сферой ответственности отдельного работника.

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

Рис. 4.2. Три уровня целей

Давайте в качестве примера возьмем некий проект создания корпоративного веб-сайта под названием «Гидра»:

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

• Общекомандные цели. Команда А будет отвечать за создание доступных и простых в применении систем поиска и учета. Команда Б будет отвечать за создание систем инвентаризации, учета внутренних ресурсов и перевозок.

• Индивидуальные цели. Фрэд (из команды А) будет заниматься проектированием и разработкой всех функций, необходимых для поисковой системы. Майк (из команды Б) будет курировать все работы по общему устройству веб-сайта и вырабатывать технические условия на создание интерфейса для «Гидры». Боб (из команды Б) будет заниматься проектированием и разработкой всех функций, необходимых для учета внутренних ресурсов и перевозок.

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