Книга: Сделано
Назад: ГЛАВА ТРЕТЬЯ. Как понять, что делать
Дальше: ГЛАВА ЧЕТВЕРТАЯ. Как правильно написать документ-вИдение

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

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

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

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

РАЗВЕНЧАНИЕ МИФОВ ПЛАНИРОВАНИЯ

Небольшой проект для внутреннего сайта с командой из одного человека не требует такого же процесса планирования, как проект на 300 человек и $10 млн для отказоустойчивой операционной системы. В целом, чем больше людей и взаимосвязей, тем больше «структурного порядка» они требуют. Однако даже простые проекты, где «в составе» один человек, получают огромную пользу от планирования. Оно дает возможность анализировать принятые решения, выявлять необоснованные допущения и добиваться согласия между отдельными людьми и организациями. Планы играют роль силовой функции против любых видов глупости, потому что требуют решать важные вопросы, пока еще есть время рассмотреть другие варианты. Как говорил Авраам Линкольн: «Если бы у меня было шесть часов, чтобы срубить дерево, четыре часа я бы по­тратил на то, чтобы наточить топор», — а это, на мой взгляд, означает, что грамотная подготовка сокращает объем работы.

Планирование проекта предполагает поиск ответа на два вопроса. Ответ на первый: «Что нам нужно сделать?» — принято называть сбором требований. Ответ на второй: «Как мы это сделаем?» — называют проектированием и спецификациями (рис. 3.1). Требование — подробное описание критериев работы. (К примеру, требование для приготовления ужина — подобрать недорогие ингредиенты и приготовить из них вкусное и питательное блюдо.) Грамотные требования легко понять и сложно переиначить. Могут быть разные способы спроектировать продукт в соответствии с требованиями, но итоговый результат должен сразу показывать, соблюдены они или нет. Спецификация — просто план создания продукта, который соответствует всем требованиям.

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

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

ТИПЫ ПРОЕКТОВ

Несколько критериев влияют на сбор требований и проектирование. Я возьму три простых и разноплановых примера, чтобы проиллюстрировать эти критерии .

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

КАК ОРГАНИЗАЦИИ ВЛИЯЮТ НА ПЛАНИРОВАНИЕ

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

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

ОСНОВНАЯ ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ

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

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

ПЛАНИРОВАНИЕ: ТРИ ПОДХОДА

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

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

ВНИМАНИЕ!

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

БИЗНЕС-ПОДХОД

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

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

Грамотное видение означает, что команда может ответить на следующие вопросы:

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

Маркетинг не ругательство

Самая несправедливая критика в адрес бизнес-аналитиков — что они просто «маркетологи», а этот термин предполагает определенный негативный подтекст в технологическом секторе. У маркетинга плохая репутация. С точки зрения MBA, маркетинг определяют четыре компонента: продукт, цена, размещение и продвижение. Чтобы определить продукт и цену, нужен креативный процесс. Задача — разработать идею продукта (продать ее и получить прибыль), которая соответствует нуждам целевой аудитории. Исследования, анализ и креативная работа необходимы для успеха. Размещение, третий компонент, определяет, как клиенты получат продукт (через сайт, в супермаркете, из багажника машины Фреда). Наконец, продвижение (которое зачастую называют основной целью маркетинга) — это распространение позитивного образа продукта с целью повлиять на людей и потенциальных клиентов. Как ни удивительно, продвижение занимает лишь небольшую часть времени бизнес-аналитика или менеджера продукта (примерно 10–20%). Итак, маркетинговый план показывает намного больше, чем вид рекламы или образцы соглашений по продвижению. И обратите внимание, что четыре прин­ципа маркетинга применяются практически ко всему. Всегда есть продукт (сайт HR), цена (бесплатно), размещение (интранет) и продвижение (электронная почта).

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

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

ТЕХНИЧЕСКИЙ ПОДХОД

Когда я изучал информатику в Университете Карнеги — Меллон, мы часто обсуждали с преподавателями и студентами новые программные продукты, анализировали их компоненты и отличия. Во главе угла стояла разработка, а точнее — количество новых технологий, применяемых в продукте. В целом мы считали, что большинство продуктов — отстой. Лишь немногие из них избежали нашей критики. Мы удивлялись, почему рынок завален посредственной продукцией, и даже придумывали теории заговора, чтобы объяснить злонамеренные решения, которые, как нам казалось, принимались против разработки и, следовательно, были абсолютно бессмысленными. Зачастую всю вину мы сваливали на маркетинг этих компаний  (но, честно говоря, мало кто из нас понимал, что такое маркетинг). Даже в первые годы моей работы в отрасли такие дискуссии были не редкостью. Хотя анализ был намного более тщательный, потому что приходилось конкурировать со многими продуктами и сайтами, которые обсуждались.

Глядя на мир, мы видели только технологии и разработку. Мы не понимали, почему плохо спроектированные продукты иногда хорошо продаются или почему хорошо спроектированные продукты иногда вообще не продаются. Мы также обратили внимание, что клиенты не всегда довольны качеством разработки, и дали этой странности два объяснения. Во-первых, это как-то связано с магическими силами злонамеренных маркетологов. Во-вторых, нам нужны клиенты поумнее. Однако мы мало задумывались о своих ошибочных выводах. Мы упорно продолжали писать код или искали, какие еще продукты «порвать в клочки». Я смог взглянуть на себя со стороны только после того, как послушал нескольких мудрых маркетологов и талантливых разработчиков продукта.

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

Несмотря на столь критический взгляд на технологов, именно отрасль технологий дает множество важных вопросов.

КЛИЕНТСКИЙ ПОДХОД

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

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

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

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

Ниже приведены важные вопросы клиентского подхода.

ВОЛШЕБНЫЙ МЕЖДИСЦИПЛИНАРНЫЙ ВЗГЛЯД

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

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

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

Рис. 3.2. Три подхода к управлению проектами

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

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

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

Много лет назад я сам участвовал в одной из таких глупых баталий. Я был программным менеджером проекта по созданию поисковых фич в Internet Explorer 4.0. К команде присоединились два специалиста по развитию бизнеса, которые вели переговоры по сотрудничеству с крупнейшими поисковиками того времени (Excite, Yahoo!, Lycos, AltaVista и т. д.). Мы спорили с этими коллегами по поводу технических решений, постоянно обсуждали, что лучше для клиента и что лучше для бизнеса. Каждая сторона считала себя авторитетом (я стоял на стороне проектировщиков и разработчиков, а они приводили маркетинговые аргументы). Мы неделями мусолили одни и те же вопросы (например, какие характеристики делают продукт хорошим) и и ни разу не предприняли попытку переосмыслить свои принципы и убеждения. Дошло до того, что мы по­просили нашего менеджера помочь нам достичь компромисса.

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

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

БАЛАНС СИЛ

Если вы работаете в крупной организации, взгляните на распределение сил по всем трем подходам. К примеру, если проектировщики превосходят числом бизнес-аналитиков в пропорции 3:1, в решениях будет преобладать техническая позиция. Соотношение сил — это соотношение количества людей, склонных к определенной точке зрения. Для сбалансированного подхода соотношение должно быть 1:1:1 (проектирование / бизнес / клиенты). Чем меньше баланса, тем больше сил придется вложить в компенсацию его отсутствия.

Конечно, количество людей не определяет степень их власти. Армия Наполеона насчитывала тысячи солдат, но Наполеон-то был один. Допустим, у вас 10 программистов и 1 маркетолог (10:1:0), но маркетолог может обладать не меньшим влиянием на проект, учитывая его должность и статус, чем все программисты вместе взятые. Иначе говоря, менеджер может компенсировать любой перевес в соотношении сил, наделяя полномочиями тех, кто должен оказывать на проект больше влияния. И поскольку природа проекта со временем меняется, разные точки зрения должны получать больше влияния в разное время. Подумайте, как делегировать решения (), чтобы найти нужный баланс для проекта в нужное время.

ПРАВИЛЬНЫЕ ВОПРОСЫ

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

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

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

ОТВЕТЫ НА ПРАВИЛЬНЫЕ ВОПРОСЫ

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

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

А ЧТО, ЕСЛИ НЕТ ВРЕМЕНИ?

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

КАК НЕ НАДО СТРОИТЬ ПЛАНЫ: ПЕРЕЧЕНЬ ОШИБОК

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

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

Не­удач­ный ме­тод

При­мер

По­че­му это про­ис­хо­дит

Про­бле­ма

Сде­ла­ем так же, как в прош­лый раз

«Вер­сия 3.0 бу­дет та­кой же, как 2.0, толь­ко луч­ше!»

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

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

Мы сде­ла­ем то, что за­бы­ли до­де­лать в прош­лый раз

«Функ­ции, ко­то­рые не во­шли в вер­сию 2.0, ста­нут осно­вой вер­сии 3.0!»

Эле­мен­ты, от ко­то­рых вы от­ка­за­лись в прош­лый раз, ско­рее все­го, хо­ро­шо изу­че­ны и ча­стич­но при­ме­не­ны, так что вам не при­дет­ся на­чи­нать с нуля

Остав­ши­е­ся функ­ции вто­ро­сте­пен­ны. Стро­ить на них но­вый ре­лиз — не са­мое ра­зум­ное при­ме­не­ние ре­сур­сов

Бу­дем де­лать то же, что кон­ку­рен­ты

«Наша за­да­ча — ско­пи­ро­вать функ­ции Про­дук­та Х»

Это са­мая про­стая мар­ке­тин­го­вая стра­те­гия. Впол­не удо­вле­тво­ряет па­ра­но­и­ков, скеп­ти­ков и лен­тяев. Ни­ка­ко­го ана­ли­за не нуж­но

Воз­мож­но, кон­ку­рент де­ла­ет это по со­вер­шен­но глу­пым при­чи­нам

Мы сде­ла­ем то, что мод­но

«Вер­сия 5.0 бу­дет на Java, с при­ло­же­ни­ем для мо­биль­ных устройств, с под­держ­кой RSS 4.0»

Тен­ден­ции — это тен­ден­ции, за ними лег­ко и ин­те­рес­но сле­до­вать. Людям нра­вят­ся тен­ден­ции, они укра­ша­ют скуч­ные или не­по­нят­ные про­ек­ты

Ре­во­лю­ции — ред­кое яв­ле­ние. Тех­но­ло­ги­че­ский про­гресс пе­ре­оце­нен в крат­ко­сроч­ной пер­спек­ти­ве, не­до­оце­нен в дол­го­сроч­ной. На пер­вом ме­сте долж­ны сто­ять про­бле­мы кли­ен­тов, а не мод­ные ве­яния

Если мы это сде­ла­ем, кли­ен­ты при­дут

«Про­ект Х ста­нет луч­шим по­ис­ко­ви­ком / ре­дак­то­ром / ви­дже­том / мы­ше­лов­кой в мире»

Бро­сив все силы на про­из­вод­ство, вме­сто того что­бы об­ду­мать, за­чем оно нуж­но, люди ино­гда из­бе­га­ют ре­аль­но­го пла­ни­ро­ва­ния

Не­уже­ли людям нуж­на усо­вер­шен­ство­ван­ная мы­ше­лов­ка? Кли­ен­ты при­дут, если ваш про­дукт им по­ле­зен, а не по­то­му, что вы ре­ши­ли что-то со­здать

ПРОЦЕСС ПЛАНИРОВАНИЯ

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

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

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

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

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

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

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

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

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

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

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

ИЗУЧЕНИЕ ПОТРЕБНОСТЕЙ КЛИЕНТОВ И ДОПУСКАЕМЫЕ ПРОСЧЕТЫ

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

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

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

Ме­тод

Что это?

Плю­сы

Ми­ну­сы

Фо­кус-груп­па

Груп­па по­тен­ци­аль­ных кли­ен­тов зна­ко­мит­ся с про­то­ти­па­ми и вы­ска­зы­ва­ет свое мне­ние в ходе дис­кус­сии

Мож­но од­но­вре­мен­но узнать раз­ные точ­ки зре­ния. До­пус­ка­ет но­вые пред­ло­же­ния и от­кры­тый диа­лог

Эти дис­кус­сии слож­но про­ана­ли­зи­ро­вать и лег­ко не­вер­но ис­тол­ко­вать. Пло­хо под­го­тов­лен­ные ор­га­ни­за­то­ры де­ла­ют ис­ка­жен­ные вы­во­дыа

Опрос

Ряд во­про­сов для по­тен­ци­аль­ных кли­ен­тов

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

На­деж­ность ин­фор­ма­ции низ­каяб. Слож­но со­ста­вить опрос без пред­взято­сти от­ве­тов. Лег­ко ис­ка­зить дан­ные

Вы­езд на ме­сто

Экс­пер­ты или чле­ны ко­ман­ды от­прав­ляют­ся к кли­ен­там и на­блюда­ют за их ме­то­да­ми ра­бо­ты

За­ча­стую это са­мый за­по­ми­на­ю­щий­ся и силь­ный опыт для ко­ман­ды

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

Про­сто­та при­ме­не­ния

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

Под­счи­ты­ва­ет­ся, на­сколь­ко лег­ко людям поль­зо­вать­ся про­дук­том. Это фак­ти­че­ские дан­ные по кон­крет­ным про­бле­мам. Наи­боль­шую цен­ность пред­став­ляют на ран­нем эта­пе про­цес­са, до того как на­чнет­ся про­ект

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

Ис­сле­до­ва­ние рын­ка

Ана­ли­зи­ру­ет­ся ры­нок про­дук­та, что­бы узнать, сколь­ко на нем кли­ен­тов, сколь­ко сто­ят кон­ку­рент­ные про­дук­ты и ка­кой до­ход мож­но про­гно­зи­ро­вать

Един­ствен­ный спо­соб оце­нить биз­нес-си­ту­а­цию на рын­ке или в от­ра­сли

Не объ­яс­няет, по­че­му про­дук­ты успеш­ны, со­сре­до­то­чен на тен­ден­ци­ях и рас­хо­дах, а не на людях и их по­ве­де­нии

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

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

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

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

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

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

СОБИРАЕМ ВСЕ ВМЕСТЕ: ТРЕБОВАНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РЕЗЮМЕ

УПРАЖНЕНИЯ

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

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

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

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

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

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

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

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

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

Назад: ГЛАВА ТРЕТЬЯ. Как понять, что делать
Дальше: ГЛАВА ЧЕТВЕРТАЯ. Как правильно написать документ-вИдение