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

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

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

ВНИМАНИЕ!

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

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

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

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

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

• какую роль в нашем бизнесе играет этот проект?

• какие потребности или желания есть у клиентов?

• какие функции или услуги мы могли бы предоставить, чтобы удовлетворить эти потребности?

• что побудит клиентов приобрести наш продукт или услугу? Что станет причиной покупки?

• во сколько обойдется этот проект (люди / ресурсы)? Какие сроки намечены?

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

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

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

• как проект поможет нам соответствовать конкурентам или обойти их?

• каковы рыночные сроки этого проекта?

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

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

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

Однако если рассматривать бизнес-интересы изолированно от всего остального, они отражают лишь треть того, что нужно. Качество продукта влияет на продажи, однако оно опирается не на маркетинг[31]31
  Эндрю Стеллман, один из технических редакторов этой книги, угрожал мне физической расправой, если я не дам ссылку по качеству программного продукта, так что вот она: W. Edwards Deming, Out of the Crisis (MIT Press, 2000) и Philip Crosby, Quality Is Free (Signet Books, 1992) (Деминг Э. Выход из кризиса: новая парадигма управления людьми, системами и процессами. М.: Альпина Паблишер, 2017).


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

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

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

Когда я изучал информатику в Университете Карнеги – Меллон, мы часто обсуждали с преподавателями и студентами новые программные продукты, анализировали их компоненты и отличия. Во главе угла стояла разработка, а точнее – количество новых технологий, применяемых в продукте. В целом мы считали, что большинство продуктов – отстой. Лишь немногие из них избежали нашей критики. Мы удивлялись, почему рынок завален посредственной продукцией, и даже придумывали теории заговора, чтобы объяснить злонамеренные решения, которые, как нам казалось, принимались против разработки и, следовательно, были абсолютно бессмысленными. Зачастую всю вину мы сваливали на маркетинг этих компаний[32]32
  Фейсал Джодат, один из технических редакторов этой книги, пригрозил мне смертью от сарказма, если я не укажу на иронию того, что после всего этого я пошел работать в Microsoft.


[Закрыть] (но, честно говоря, мало кто из нас понимал, что такое маркетинг). Даже в первые годы моей работы в отрасли такие дискуссии были не редкостью. Хотя анализ был намного более тщательный, потому что приходилось конкурировать со многими продуктами и сайтами, которые обсуждались.

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

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

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

• Какова цель проекта?

• Как он будет работать? Как будет работать каждый из компонентов?

• Как мы его построим? Как проверим, что он работает так, как нужно?

• Насколько надежны, эффективны, расширяемы и высокопроизводительны наши системы или те, которые мы можем построить? Не лежит ли пропасть между ними и требованием проекта?

• Какие технологии и архитектура уже есть в нашем распоряжении? Воспользуемся ли мы какими-либо новшествами в этой области, которые скоро появятся, но пока еще не доступны?

• Какие процессы и методы подходят этой команде и этому проекту?

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

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

• Сколько времени займет реализация и какой уровень качества нужен?

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

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

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

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


[Закрыть].

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

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

• Что люди делают в реальности? (Не то, что нам кажется, и не то, что они говорят.)

• Какие проблемы клиенты испытывают с вашим продуктом? На чем они «тормозят», что их смущает или расстраивает?

• Что им нужно сделать или что они хотят сделать, но не получается?

• Как разработать все проще, безопаснее, быстрее и надежнее для них?

• Какие идеи по совершенствованию функциональности продукта больше всего улучшат пользовательский опыт?

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

• Какие основные идеи и концепции должен использовать проект, чтобы донести нужную информацию до пользователей?

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

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

Помимо ценности для стратегического планирования, диаграмма Венна[34]34
  Диаграмма Венна (также называемая диаграммой Эйлера – Венна) – схематичное изображение всех возможных отношений (объединение, пересечение, разность, симметрическая разность) нескольких (часто трех) подмножеств универсального множества. Прим. ред.


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

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

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

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

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

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

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

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

БАЛАНС СИЛ

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

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

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

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

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

• Зачем нужен этот проект? Почему именно мы подходим для его осуществления? Почему его следует выполнить именно сейчас?

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

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

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

• Кто наши потенциальные клиенты и какие функции, сценарии и типы продукта нужно им предоставить, чтобы они стали фактическими клиентами? (Демографический профиль новых клиентов.)

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

• Можем ли мы создать технологию и приобрести знания, необходимые для создания такого продукта? (Да / нет / возможно.)

• Открывает ли новый продукт или линия продуктов значительные возможности? Или же удовлетворяет определенные потребности?

• Есть ли надежные бизнес-модели для применения наших знаний и технологий для решения выявленных проблем и удовлетворения потребностей? (Покроет ли прибыль расходы за прогнозируемый период времени?)

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

• Что делают конкуренты? Каковы их стратегии и как нам с ними соперничать?

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

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

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

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

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