Разумный метод управления

Качество внутри (управление продуктом)

Чувствую, как некоторые читатели уже приготовились закидать меня помидорами, приговаривая: «Юра думает, что надо просто ублажать клиента всякими фантиками, но ничего хорошего из этого не выйдет, продукт и внутри должен быть сделан как следует!». Я прямо слышу советские лозунги из серии: «это не культура должна опускаться до уровня рабочих, а рабочих надо подтягивать до высокого уровня культуры».

Специально для этого у меня есть график управления качеством на протяжении всего проекта:

На графике по оси X отложено время от начала проекта. Скорее, время от того момента, когда про проект начали думать. По оси Y – сила влияния этапов проекта на его качество. Давайте рассмотрим этапы по очереди:

Продажа

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

Если речь идет про запуск массового продукта или создание бизнеса с нуля, под этапом «Продажа» понимается принципиальное решение: начинать проект или нет. Фактически, это исследование рынка и оценка потенциала идеи. Самое важное на этом этапе – честность с самим собой, умение оценить проект максимально объективно, не увлекаясь лишними фантазиями. Как мы говорили раньше, люди с предпринимательской жилкой часто искрят новыми идеями, и это отвлекает от получения прибыли. Именно поэтому в команде, принимающей решение об инициации проекта, должен быть хладнокровный зануда, который все подробно посчитает, оценит риски, привлечет экспертов и даст объективную картину. Как говорил один известный предприниматель: «меняю одного финансового директора на двух директоров по маркетингу».

Из своего опыта я понял, что материальный мир – довольно инерционная штука. Да, человек, заряженный на реализацию идеи, обязательно воплотит ее в жизнь, но она проявится в материальном мире не мгновенно, а с временной задержкой. Представьте, если бы все наши мысли сбывались мгновенно. Вот пришел вам в голову образ розового слона, а он – раз, и появился в вашей комнате. И так по всей планете 7 миллиардов раз. Так вот, на реализацию каждого проекта нужно время. Даже просто на проверку бизнес-идеи нужно минимум 2–4 месяца плотной работы. Каждый раз при появлении мысли о старте нового проекта ответьте себе на вопрос: вам точно не жалко потратить на это несколько месяцев жизни? Кстати, наличие миссии помогает ответить на этот вопрос максимально быстро.

На эту тему есть прекрасная цитата из Сунь-Цзы:

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

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

Подбор команды

Это второй фундаментальный шаг к успеху в управлении качеством. На вопрос о причинах провала проекта многие студенты на курсе по менеджменту отвечают: «нам дали слабых специалистов или не дали их в достаточном количестве».

Здесь один мой коллега придумал хорошую аналогию. Как-то раз он, будучи менеджером проектов, ехал в поезде в Крым, отдохнуть в отпуске. От нечего делать достал компьютер и решил вспомнить юность: поиграть в WarCraft (одна из самых популярных компьютерных игр на протяжении долгих лет). Его, как менеджера, поразило 100 % выполнение задач виртуальными участниками команды. Дал задачу строить дом – дом построят, послал рубить деревья – идут и рубят. А после выполнения задачи всегда просигнализируют. При таком поведении участников команды у менеджера остается достаточно времени на разработку стратегии, анализ рисков и корректировку тактики, в зависимости от ситуации. Это должно быть естественным поведением команды. Но в реальности многие менеджеры сталкиваются с тем, что специалисты делают что-то, отличающееся от изначальной задачи, делают это с задержкой, с ошибками, или вообще неожиданно пропадают из вида. В такой модели ни о какой стратегии и рисках речи быть не может: менеджер вынужден регулярно ночевать на работе и фехтовать с постоянно возникающими проблемами.

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

Сбор требований

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

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

Так вот, задача первичного сбора требований – сфокусироваться именно на ДНК проекта, обнаружить самые важные свойства продукта и запланировать их реализацию в первую очередь. Для этого этапа есть полезная техника под названием Story Mapping. Возможно, техника не нова, но в наши дни ее популярнее всех описал Jeff Patton в своем блоге (для любителей изучения первоисточников даю ссылку на общую концепцию^[17] и детали^[18]).

Краткая суть Story Mapping такова:

– осознайте миссию и УТП продукта. Кому и зачем он нужен, какие проблемы решает, каковы его уникальные свойства, на чем он будет зарабатывать и куда тратить;

– проработайте ключевые персоны. Персона: это прототип конкретного человека, представителя целевой аудитории. Желательно, чтобы ключевых персон (и, соответственно, сегментов целевой аудитории) было 2–3, чтобы фокус продукта не рассеивался. Задача этого этапа – понять, как ведут себя персоны, какие у них есть проблемы, чем вы можете им помочь. На практике я всегда стараюсь пожить «в шкуре» персоны. Например, перед стартом консалтингового проекта для гипермаркета мебели я специально ездил в гости к людям, которые похожи на представителей целевой аудитории и долго разговаривал с ними про то, как они покупают мебель. Я сидел с ними рядом и смотрел, как они ищут и заказывают мебель в интернете, уточнял, почему они делают именно так, а не иначе. Это заняло у меня всего несколько дней, зато обеспечило успех при продаже нашей концепции проекта клиенту. Когда мы делали проект по созданию терминалов для покупки товаров в сети магазинов электроники, я лично ходил по разным магазинам и смотрел, как народ пользуется этими терминалами, в каких случаях ругается от неудобства, как ищет товар в большом каталоге. Такой подход экономит много времени при создании проекта и заметно лучше, чем абстрактные опросы фокус-групп;

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

– проработайте весь скелет: список функций, которые нужно реализовать, чтобы привести активности в движение. На этом этапе не увлекайтесь рюшечками: каждая функция должна быть реализована в минимально достаточном виде для обеспечения активности. Помните про понятие «скелет». Фактически, этот скелет и будет первой версией продукта, на которой вы сможете проверить жизнеспособность бизнес-модели. Если вы, например, создаете бизнес с нуля, то бета-версией будет такое состояние предприятия, при котором оно начало зарабатывать хоть какие-то деньги, когда прошла от начала до конца первая сделка. Момент запуска бета-версии в любом проекте очень важный, можно сказать, переломный. Идея, наконец-то, материализовалась. У команды, появляется первая обратная связь. Становится понятно, будет у проекта жизнь или нет. На этом этапе бизнес можно показывать инвесторам (если хотите привлечь инвестиции) и получить намного более выгодные условия, чем в любой другой предыдущий момент. Если вы делаете на заказ B2B-проекты, то бета-версия позволяет разрядить напряжение в отношениях между вами и клиентом. Кроме того, бета-версия позволяет более осознанно детализировать дальнейший план работ по итогам изучения обратной связи от пользователей и собственных ощущений от продукта;

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

Интересные психологические моменты:

– Story Mapping воспринимается как игра, а не как работа. Это позволяет быстрее вовлечь команду в проект и сделать рабочий процесс интереснее;

– в Story Mapping надо обязательно «играть» с заказчиком (если вы делаете B2B-проект), потому что:

– это сближает клиента с вами, вы теперь в одной команде;

– вы получите информацию из первых уст;

– вы сможете немного скорректировать в ходе игры бурную фантазию клиента, но благодаря фиксации итогов Story Mapping на бумаге и личному участию заказчика в процессе игры, вы будете надежно защищены. Заказчик будет уверен в том, что он сам все придумал и всячески будет защищать разработанный концепт. В-четвертых, это просто интересная практика, которая является для клиента той маленькой радостью, притягивающей клиента к вам;

– Быстрый старт. Техника Story Mapping позволяет сфокусироваться на том, чтобы как можно быстрее сделать бета-версию и проверить жизнеспособность проекта. Это полезно по нескольким причинам:

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

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

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

В общем, я крайне рекомендую изучить технику Story Mapping в подробностях и применить на практике: мне и моим клиентам она подарила несколько успешных проектов. Для тех, кто освоил Story Mapping, есть второй уровень развития. В современном мире бизнес все больше становится мультиканальным: покупатели взаимодействуют с бизнесом и с ноутбука, и с помощью мобильного браузера, и по телефону, и в магазинах, и на сайтах рекомендаций. В общем, стандартная воронка продаж превращается в карту прыжков, карту взаимодействия. Если вы хотите сохранить ваш бизнес в боевом состоянии, вам надо научиться планировать этот Customer Journey Map (CJM). Про CJM есть хорошая статья^[19] Алексея Копылова и серъезный философско-аналитический отчет от Google со смешным для русского слуха названием ZMOT^[20].

Постановка задач

На эту тему есть поговорка: «качество выполнения задачи на 99 % зависит от качества ее постановки». Жаль, что эта поговорка не очень популярна среди менеджеров. На курсе по управлению проектами одно из домашних заданий состоит в том, чтобы прислать пример постановки задачи специалисту. Я специально прошу прислать хотя бы одну случайно выбранную задачу, чтобы студент не старался в поисках самой качественной, а показал свой обычный уровень. К сожалению, большинство нарушает самые базовые принципы постановки задач: отсутствует плановый срок выполнения, нет пояснений, зачем вообще задача нужна, не хватает ссылок на необходимые источники данных. И это какая-то эпидемия.

Профессора детской психологии в таких случаях рекомендуют составлять визуальные списки действий и вешать их на видном месте. Поэтому я рекомендую всем менеджерам распечатать и повесить на видном месте расшифровку аббревиатуры SMART^[21]. А еще лучше – настроить систему управления задачами вашей компании так, чтобы в форме постановки задачи было пять полей:

– что конкретно надо сделать;

– как проверить выполнение результата;

– какие ресурсы есть для выполнения задачи;

– зачем вообще нужна задача;

– когда задача должна быть выполнена.

Такая настройка возможна в популярных приложениях JIRA и Redmine (буду благодарен, если читатели в комментариях поделятся своим практическим опытом настройки других таск-менеджеров в формате SMART). Подход с настройкой пяти полей задачи я считаю самым эффективным. Посмотрите на любое рабочее место человека, который делает много похожих активностей (например, кассиры в супермаркетах или операторы колл-центров): у них всегда на видном месте есть удобная пошаговая подсказка в электронном или в бумажном виде. Благодаря этому в сетевых магазинах очередь проходит так быстро, а кассиры при этом не забывают предложить вам собрать 125 наклеек и получить за это сковородку.

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

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

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

Управление требованиями

Еще один занудный регулярный труд по управлению качеством в течение всего проекта – это постоянное управление требованиями. Я бы даже заменил «управление требованиями» на «отклонение требований».

Как обычно происходит: сначала вы продумываете скелет проекта, он обладает минимальным необходимым набором функций и представляет из себя вполне цельный продукт. Но со временем клиенты, консультанты, инвесторы, участники команды и другие люди начинают кидать в общую переписку письма вида «парни, смотрите, что я нашел у наших конкурентов!»… На встречах происходит бурное обсуждение похожих проектов и выдвигается список с десятком новых функций проекта. Еще больший поток потенциальных новинок появляется после запуска бета-версии: клиенты начинают со знанием дела писать письма и давать советы о том, как надо развивать продукт. На эту тему есть прекрасный доклад^[22].

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

– какие накладные расходы это повлечет помимо расходов на разработку новинки: обновление документации, обновление процессов, обучение сотрудников и клиентов, закупка оборудования, обновление маркетинговых материалов и т. д. до бесконечности;

– действительно ли это изменение настолько остро необходимо? С какой вероятностью оно окупит все описанные выше инвестиции? Оно востребовано большинством из ваших лучших клиентов? Если нет – забудьте об этом!

Да, в книге Getting Real коллеги имели ввиду разработку интернет-приложений, но, исходя из моего опыта, эти правила применимы и в оффлайн-бизнесе: изменения в оффлайн-проекте стоят намного дороже изменений в интернет-программе. В общем, стоит прислушаться к товарищам, которые построили компанию размером всего в 30 человек с оборотом более 20 млн долларов в год. Причем, эти 30 человек почти не ходят в офис и работают из дома. Мы в Команде-А пользуемся продуктом 37signals для управления проектами. Продукт настолько простой, что ты не замечаешь, как им пользуешься. По-моему, это идеальный сервис.

Настроить радар

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

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

Совокупность мероприятий по настройке «проектного ПВО» в классической литературе про менеджмент называется «управление рисками», поэтому, для наглядности и простоты восприятия я вынес эту тему в отдельную главу. Хотя, в менеджменте довольно тяжело выделить какие-либо строго очерченные области знаний. Если вдуматься, и тайм-менеджмент, и управление клиентом, и управление командой – это все про управление качеством.