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

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

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

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

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

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

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

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

Резюме

Управление качеством – это управление восприятием потребителем степени соответствия продукта его ожиданиям.

Отсюда возникают необходимые практики:

– управлять ожиданиями: аккуратно обещать и всегда делать чуть больше;

– управлять восприятием: давать клиентам маленькие радости;

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

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

Вопросы для самостоятельной проработки:

– обещаете ли вы клиентам сроки и деньги на встречах? Каковы последствия таких обещаний?

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

– подходит ли метод Story Mapping для разработки проектного видения в вашей отрасли? Если да, то попробуйте его применить на ближайшем проекте;

– возьмите 2–3 случайных задачи из вашей системы учета задач. Проверьте, отвечают ли они критериям SMART. Перепишите формулировку задачи, если это необходимо. Распечатайте чек-лист SMART и повесьте в комнате менеджеров;

– сделайте ревизию списка плановых доработок ваших проектов. Точно ли эти доработки необходимы? Каковы ваши критерии необходимости?

Управление рисками

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

Какие виды рисков я рассмотрю в этой главе:

– конфликт внутри команды;

– конфликт с клиентом;

– игнорирование сигналов;

– нарушение сроков или бюджета.

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

Конфликт внутри команды

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

По разрешению и предотвращению конфликтов есть хорошая методичка[23] и сборник практических упражнений[24] с рекомендациями по анализу результатов. За деталями обращайтесь к первоисточникам, а у меня, как обычно, краткое содержание.

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

Источники конфликтов можно объединить в три группы:

– инструментальные: плохо настроенные процессы, противоречивые задачи;

– конфликты интересов: дележка ресурсов (деньги, время, персонал, власть);

– личные конфликты вокруг самоидентификации, недостатка уважения или лояльности, предательства, утраты доверия и т. д.

Способы решения конфликтов тоже довольно типовые:

– силовой. Одна сторона просто склоняет другую силой. В итоге одному хорошо, второму не очень. Метод используется, если сила подкреплена легальными источниками и силовой метод уже принят в сообществе как нормальный. Метод разрушителен, если подавляемая сторона никак не может выразить свою позицию: в этом случае получается система без обратной связи, что может привести к краху проекта и гигантским убыткам, см. пример про Samsung Motors в книге С. Финкельштейн «Ошибки топ-менеджеров ведущих корпораций». Обычно применяется, когда в компании есть человек с абсолютной властью или просто локальный менеджер-самодур;

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

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

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

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

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

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

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

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