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

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

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

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

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

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

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

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

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

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