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

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

Таблица 3.1. Самые распространенные неудачные методы планирования

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

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

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

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

Рис. 3.3. Обратная связь между уровнями планирования

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

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

Рис. 3.4. Время идет, и будет намного сложнее внести изменения в структуру планирования (хотя это возможно)

ПОВСЕДНЕВНАЯ РАБОТА

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

• Самая важная часть процесса – роли сотрудников. Кто определяет требования? Разработку? Если участвует много людей, как будут приниматься решения? Как будут разрешаться спорные моменты? Если разъяснить все эти вопросы, связанные со взаимоотношениями, многих проблем можно избежать или, что более вероятно, решить их спокойно и в рамках указанных сроков. (Подробнее об отношениях и ролях читайте главу 10.)

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

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

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

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

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

Таблица 3.2. Распространенные методы исследования клиентов

^а Участники фокус-группы всегда стараются быть полезными. Они не хотят никого оскорбить и зачастую проявляют больше позитива и благосклонности к продукту, чем в других условиях.

^б Вспомните, насколько добросовестно вы отвечаете на вопросы. Если вы вообще никогда не участвуете в опросах, подумайте, какой тип людей готов тратить на них уйму времени.

Эксперты по клиентским исследованиям выполняют две задачи: выбирают метод, учитывая вопросы, на которые команде проекта нужно ответить, и применяют разные методы, чтобы противодействовать ограничениям и предубеждениям отдельных подходов. Таблица 3.2 отражает несколько основных методов исследования и их особенности.

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

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

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

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

Он используется во многих проектах, чтобы определить направление работы. Требования – это все, что команда (и клиент) планирует выполнить. В двух словах, заказ пиццы-пепперони – это пример формулировки требований. Вы говорите повару, что конкретно вам нужно. Он может задать вам пару вопросов, чтобы прояснить заказ («Добавим газировку?») или обсудить кое-какие детали («У нас закончилась пепперони, не возражаете, если заменим на салями?»). В более трудных ситуациях разработки получить грамотные требования сложно. Есть множество способов интерпретировать абстрактные идеи («Пусть работает быстро» или «Пусть реже ломается»), но процесс «выуживания» требований, как правило, непрост.

Существуют проверенные методы разработки и документирования требований, и я рекомендую вам познакомиться с ними[35]35
  См. блестящую книгу Exploring Requirements: Quality Before Design, Donald Gause and Gerald Weinberg (Dorset House, 1989).


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

Формулировка проблемы – это одно-два предложения для описания конкретных трудностей, которые испытывают конечные пользователи или клиенты. Узнать их можно из исследований или конкретных запросов клиентам. Записываются они в формате, который определяет потребности с точки зрения клиента (в отличие от разработки и бизнеса). Это позволит учесть мнение потребителя и не исказить его другими подходами.

В качестве примера приведем примерный список формулировок проблем интранета.

• Сложно найти нужные элементы на домашней странице.

• Информационная страница грузится очень медленно, и пользователям приходится ждать.

• Страница запроса к базам данных зависает при работе с большими таблицами, и пользователям приходится начинать все сначала.

• Отсутствует автоматический доступ к защищенным услугам, а ручной доступ занимает много времени.

• Результаты поиска сложно просматривать с таким макетом страницы.

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

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

• Невозможно сохранить предпочтения и настройки домашней страницы.

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

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

ПРОБЛЕМЫ СТАНОВЯТСЯ СЦЕНАРИЯМИ

Поскольку суть проблем отражает сегодняшнюю ситуацию, проекту нужно что-то еще, чтобы отразить, как изменится ситуация по завершении работы. В этих целях формулировки проблем нужно преобразовать в так называемые формулировки функций, или сценарии. Один из самых распространенных из множества методов – сценарии использования[36]36
  См. Alistair Cockburn, Writing Effective Use Cases (Addison-Wesley, 2000).


[Закрыть].

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

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

Возможные функции Проекта Х:

• самые нужные элементы домашней страницы будет легко найти;

• результаты поиска отразятся в удобном для пользователей виде, допускающем беглый просмотр;

• появится автоматизированный доступ к защищенным услугам;

• на странице регистрации будет легко вводить информацию без ошибок;

• информационная страница будет загружаться так же быстро, как и домашняя;

• интерфейс запросов к базе данных будет таким же надежным, как другие компоненты системы;

• пользователи смогут видеть статус сервера электронной почты в простом и удобном формате;

• система будет запоминать предпочтения и настройки пользователей.

Формулировки функций должны не описывать конкретную конструкцию, а объяснять, как решение повлияет на клиента. Легче сказать, чем сделать. Большинство креативных людей любят решать проблемы и делают это практически машинально. Опасность в том, что быстрые решения зачастую поверхностны. Дайте проблеме «отстояться». Для этого достаточно попросить коллег записать свои идеи после собрания по планированию и обсудить их позже. Исключите те, которые либо полностью игнорируют проблемы, либо считают их тривиальными.

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

ИНТЕГРАЦИЯ ТРЕБОВАНИЙ БИЗНЕСА И ТЕХНОЛОГИЙ

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

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

• Разные проекты требуют разных подходов к планированию.

• Метод планирования зачастую зависит от того, кто обладает соответствующими полномочиями. Требования, проектирование и бюджет – три сферы, которые влияют на этот процесс.

• Существует ряд традиционных документов по планированию: анализ требований рынка (MRD), документ-видение, спецификации и иерархическая структура работ (WBS).

• Самый эффективный способ планирования предполагает три равноценных подхода: деловой, технический и клиентский. Последний часто искажается и неверно применяется.

• Правильные вопросы наталкивают на правильные мысли и направляют ваши усилия по планированию в нужное русло.

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

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

А. Составьте список людей, за которыми оставалось последнее слово по проектированию, техническим и бизнес-вопросам в предыдущем проекте. Команда с самого начала знала об этом? Для принятия таких решений выбрали правильных людей? Как этот выбор повлиял на проект?

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

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

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

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

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

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

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

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

Глава четвертая. Как правильно написать документ-вИдение

* * *

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

В главе 2 был предложен краткий обзор документов планирования, таких как MRD, видение и WBS. Данная глава посвящена самому важному из них – документу-видению. Я объясню, почему оно стоит всех потраченных на него усилий, какие качества присущи хорошим документам и как извлекать из них ценность на протяжении всего проекта. При грамотном использовании документ-видение становится завершающим этапом планирования (рис. 4.1).

Рис. 4.1. Финальная версия документа-видения знаменует завершение этапа планирования точно так же, как конечные спецификации знаменуют завершение этапа проектирования

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