Сформулируйте цели и метрики проекта

Итак, перед вами новый проект. Поскорее бы начать разработку! Но как структурировать свои мысли, чтобы ничего не упустить и эффективно донести их до разработчиков? Для этого существует специальный инструмент – Project Canvas.

Project Canvas. Источник – https://realtimeboard.com

Этот инструмент необходим, прежде всего, вам самим. Заполните канву и держите перед глазами на протяжении всего проекта. Она поможет вам фокусироваться на самом важном и гибко управлять процессом. Иными словами, вы всегда будете видеть, на что следует обратить внимание. Работать с Project Canvas и подобными шаблонами очень удобно в сервисе При заполнении, укажите параметры проекта:

– Какие показатели будут определять успешность проекта?

– Какие ограничения есть у проекта?

– Как проект влияет на ваш бизнес?

Подумайте о целях пользователей

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

При описании продукта всегда концентрируйтесь на целях ваших пользователей:

– Для чего пользователям ваш продукт?

– Как он им поможет?

– Чем это лучше существующих альтернатив?

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

Personas. Источник – https://realtimeboard.com

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

Метод персон эффективен, когда вы работаете с уже существующей аудиторией. Но когда требуется создать продукт с нуля и привлечь новых пользователей, есть более подходящий метод, который называется Jobs To Be Done. Суть метода заключается в том, что не важно, какая аудитория использует продукт, а важно сосредоточиться на «переключении контекста». Не важно, сколько именно лет пользователю смартфона, который в данный момент голоден и не хочет готовить. Он должен быть сыт, и задача цифрового продукта – максимально эффективно переключить его из одного контекста в другой (из голодного сделать сытым). С такой «работой» отлично справится мобильное приложение для доставки еды из ресторана.

«Улучшайте своего пользователя, а не ваш продукт. Не создавайте лучшие камеры, а создавайте лучших фотографов» – Кэти Сьерра

Jobs To Be Done. Источник – https://www.idealizedinnovation.com

Когда вы выявили мотивации и боли аудитории, приступайте к описанию основных функциональностей. Главным сделайте следующий вопрос: «Какие функции необходимы для того, чтобы пользователи выполнили свои задачи с помощью продукта?»

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

Определите ключевые функции

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

Метод скоринга. Скачайте пример на сайте 

Метод скоринга позволяет определить наиболее полезные функций с минимальными трудозатратами:

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

– Оцените их важность для пользователей по 3-балльной шкале (3 – самые важные).

– Поставьте оценки сложности реализации (насколько сами представляете).

– Поделите сумму оценок важности на оценки сложности и получите коэффициенты от 1 до 3. Функции, которые получили наивысший балл, – наиболее приоритетны.

Не забывайте про конкурентов

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

Иногда для объективной оценки сервисов конкурентов стоит дополнительно проанализировать их сайты. Для этого рекомендую использовать . В отчёте вы сможете найти основные источники трафика и похожие сервисы (с точки зрения поисковых систем).

similarweb.com

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

Лучше раньше, чем лучше

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

– Проектирование пользовательского опыта (UX).

– Дизайн интерфейсов (UI).

– Написание «серверной» части кода (бэкенд).

– Написание «клиентской» части кода (фронтенд).

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

tilda.cc

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

У вас большой и сложный продукт? Не описывайте все работы целиком – это отнимет много сил, и задание может со временем потерять актуальность. Лучше отправить задание сегодня и обсудить детали позже с разработчиком, чем писать целый месяц, а в конечном итоге разработчик предложит более простое или готовое решение.

Заметки и истории

От агентств до фрилансеров

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

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

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

От агентств до фрилансеров

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

Выбор зависит от ваших ресурсов и экспертизы

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

– Как собирать и создавать контент для вашего продукта?

– Необходимость подготовки графических материалов (фото / иллюстрации / инфографика).

– Техническая сторона вопроса (домен / хостинг / отказоустойчивость / безопасность).

– Правовое сопровождение проекта и данных.

– Необходимость интеграции с существующими системами.

– Поддержка и контент.

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

Большинство проблем в коммуникациях возникает из-за разницы в ожиданиях и результате.

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

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

Где искать подрядчиков

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

Я не буду рекомендовать такие сайты – вы и сами без труда сможете найти их. Единственный совет: если устраиваете тендер среди топовых компаний, проверяйте наличие международных наград в необходимой области – например, дизайн или фронтенд.

Итак, подрядчиков можно искать:

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

– Сайты рейтингов: смотрите номинации в вашей профессиональной области. Например, «персональный сайт» или «сайт строительной компании».

– Сайты-портфолио: behance.net, dribbble.com.

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

behance.net

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

Запрос на разработку

– Канва проекта перед глазами.

– Бриф написан.

– Список потенциальных исполнителей есть.

Что писать в запросе:

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

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

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

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

– Обязательно планируйте все обсуждения/даты приёмки коммерческого предложения в онлайн-календаре и добавляйте туда контактных лиц от исполнителя. Это позволит не держать в голове все даты и не запутаться.

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

Не судите строго

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

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

Будьте готовы своевременно и вежливо отвечать на поступающие вопросы. Если вы не понимаете, о чём вас спрашивают в письме, или просто не хватает времени ответить, предложите созвониться.

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

Совместная работа с брифом.

Заметки и истории

Сигналы

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

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

В идеале разработчик должен рассказать вам о том, как он выполнял подобные проекты ранее, какие были проблемы и нюансы. А к обсуждению стоимости вернётесь чуть позже.

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

Неудобные вопросы

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

– Как поддерживать продукт после того, как он будет готов?

– Что делать, если потребуется добавить или изменить раздел, когда уже всё готово?

– Что, если не подойдёт качество результатов?

– Что, если проект будет задерживаться или будет готов не полностью?

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

Личная ответственность

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

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

Начинайте собирать материал как можно скорее. Это может занять больше времени, чем вы думали.

Период подготовки материалов

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

Игры со шрифтами

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

Если не до конца понятен объём трудозатрат по какой-либо задаче, есть очень удобный способ создать поле для манёвров – просто купите дополнительное время.

Кроме того, потребуется дополнительное время на выполнение «внезапных работ» или «игр со шрифтами», если наблюдаете у себя пристрастие к таким вещам.

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

Разброс цен

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

Сопоставьте все финальные предложения. В случае большого разброса цен есть риск, что кто-то из разработчиков неправильно понял задание и перезаложился на непонятные работы. Свяжитесь с ним и уточните непонятные детали, чтобы сделать переоценку. Если разброс цен небольшой, в пределах 15—20%, – значит, вы отлично составили задание и можно двигаться дальше. И последний штрих – запрос скидки.

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

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

Момент истины

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

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

Разные продукты для одинаковых целей пользователей.

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

Заметки и истории

Управляемая гибкость

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

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

Вы сможете делить заказы по проектам или отдельным этапам – в зависимости от ситуации.

Рамочный договор и заказы.

С другой стороны, гибкость обеспечивает формулировка предмета разработки: «произведение». Произведением может быть и концепция, и стратегия, и контент. Вне зависимости от того, какие именно будут произведения, не забудьте указать в договоре условия отчуждения прав.

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

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

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

Процесс и результат

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

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

Каскадная и гибкая модели. Источник – http://slideshare.net.

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

Результатами этапов водопадной разработки могут быть:

– Схемы процессов или маршрутов пользователя (UML-диаграммы).

– Дизайн-макеты в виде изображений (или формате графических редакторов).

– Графический или текстовый контент (в соответствующих форматах).

– Программный код (размещённый на определённом сервере).

– Готовый функционал (доступный по определённому url).

– Результаты тестирования (отчёты в виде таблиц).

– Инструкции (в текстовом или видеоформате) и т. п.

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

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

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

Предоставив такую свободу себе и исполнителям, важно не забыть об ответственности с обеих сторон. Обязательно укажите, кто конкретно с вашей стороны и со стороны исполнителя (ФИО, должность, контакты) отвечает за отправку и приёмку результатов, а также требования по срокам и качеству. Не забудьте указать, по каким каналам будет осуществляться передача материалов:

– Электронная почта (укажите все варианты, откуда и куда будет отправляться).

– Онлайн-хранилище (url к папке с материалами).

– Корпоративный таскменеджер (Jira/trello и т.п.).

– Мессенджеры (будьте осторожны: это не самое надёжное хранилище).

– Общая рабочая папка (вы сможете смотреть статистику создания текстовых документов в ней).

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

– Системы контроля версий (после регистрации вы сможете видеть объём кода, который пишут разработчики).

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

Финансовый вопрос

Может возникнуть ситуация, когда подрядчик откажется передавать еще не оплаченный материал. В таком случае осуществляйте 100% предоплату этапов работ, а закрывающие документы подписывайте после приёмки. Выбирая модель разработки, обратите внимание на схему оплаты. Для каскадной разработки подходит Fixed Price, с предварительным утверждением сметы. А для гибких процессов – удобнее использовать Time and Materials с расчетом стоимости спринтов. Среди крупных компаний набирает популярность схема «выкупа команды разработки». Многие агентства и студии даже предлагают перебазировать своих сотрудников в офис заказчика на время проекта. Это дороже, чем удаленная работа с командой, но результат появится быстрее и будет более качественным.

Бумажная усталость

Вы осилили создание всей необходимой документации – поздравляю! Должен получиться примерно такой комплект:

– Рамочный договор.

– Заказ (с требованиями к результатам 1 итерации).

– Приложения к заказу (гайдлайны, исходный материал, и т.п.).

– Календарный план (в случае водопадной разработки).

– Шаблоны закрывающих документов (при необходимости).

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

Совместное обсуждение целей пользователей.

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

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

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

Заметки и истории

Недосказанность всегда против вас

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

Самая большая ошибка, которую здесь можно совершить, – увериться в том, что вас понимают на 100%. Даже если вам так кажется, это всё равно не так. Просто при передаче информации другому человеку она проходит через несколько коммуникационных этапов – и смысл постепенно теряется.

Потери информации в процессе передачи сообщения.

Автор теории – Предраг Мицич.

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

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

В случае гибкой разработки все иначе. Рассмотрим 3 инструмента, помогающие в планировании при гибкой разработке:

– Use Case

– Нагляднее других инструментов помогает описать функционал, но заковывает в «рамки креативности» автора.

– User Story

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

– Job Story

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

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

Во время планирования релиза с командой откройте список «болей пользователей», которые должен закрыть ваш продукт. Каждый участник встречи предлагает свой вариант решения, а вы заносите в таблицу. В процессе генерации идей важно не критиковать решения, а собрать максимальное их количество. Я люблю использовать онлайн-таблицы Google Sheets для подобных задач.

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

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

– Боль/проблему пользователя;

– описание функционала, который эту проблему решает (и как решает);

– Важность для пользователя;

– Важность для бизнеса;

– Сложность реализации;

– Совокупный балл приоритета;

– Критерий приёмки (каким образом функционал должен быть реализован, чтобы уйти в релиз).

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

Вовлечённость

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

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

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

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

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

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

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

Тараканы

Помните, мы составляли список «страхов» в запросе на разработку? Откройте его во время планирования задач с исполнителем и ещё раз обсудите ваши действия в том случае, если страхи оправдаются. Пусть подрядчик помнит, чтó вас беспокоит. Но также спросите и о его страхах. Скорее всего, среди них будут:

– микроменеджмент с вашей стороны;

– отсутствие вовлечённости (противоположная проблема);

– невыполнение обещаний (обычно под этим подразумевается непредоставление материалов в срок или затягивание согласований).

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

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

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

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

Заметки и истории

Постоянная декомпозиция

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

– Use Case: детализация вариантов использования. (Например, описание возможных вариантов использования во время заполнения заявки на получение услуги).

– User Story: разбор отдельных историй на части. (Например, описание истории перехода от заполнения заявки к получению услуги).

– Job Story: дробление крупного контекста на мелкие контексты. (Например, описание переключения от контекста заполнения заявки к контексту получения услуги)

Как видите, степень свободы в реализации решений зависит от выбора фреймворка. Методика приоритизации задач на спринт – аналогичная той, что и для приоритизации функционала в релизе.

Стоит ли участвовать в декомпозиции задач внутри спринта, зависит от того, насколько глубоко хотите погрузиться в разработку и как договорились с подрядчиком.

Вертикальная декомпозиция. Источник – https://creativecommons.org

Я предпочитаю не углубляться в подробности реализации задач, если только разработчики сами этого не попросят.

Усмирение демонов

Допустим, план на спринт готов, критерии приемки чётко сформулированы и команда приступила к разработке. Обсудим несколько базовых правил, чтобы всё шло так, как должно.

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

Если вы не можете избавиться от мысли, что ваше решение задачи самое лучшее и других вариантов быть не может, грамотный исполнитель предложит провести A/B-тест. Зафиксируйте ваше решение в отдельной таблице работы с гипотезами и двигайтесь дальше.

Старайтесь, чтобы у каждой задачи, которая идёт в спринт, был понятный результат, а не «провести исследование как провести исследование». Вообще, в гибкой разработке не принято выделять исследования в отдельные задачи, потому оценивать качество таких активностей и управлять ими затруднительно.

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

Аппетит приходит во время еды

Возможно, у вас появится соблазн сказать: «Давайте пока закроем задачу, а потом немного доделаем!» Покорный исполнитель смирится и отправит задачу в колонку «готово». Но это неправильно. Так вы перестанете управлять сроками и качеством исполнения. Запомните: у задач не может быть статуса «почти сделана». Либо она готова полностью, либо не готова.

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

Планирование внезапных задач при гибкой разработке.

Планирование задач при гибкой разработке может осуществляться постоянно. Используйте бэклог, чтобы вести все текущие задачи и создавать новые. Главное – не забывать обсуждать новые задачи с разработчиками и устранять недосказанность. Не меняйте приоритетность задач, не обсудив причины изменений с исполнителем – иначе появится информационный вакуум. Фактически вы переосмыслите требования к результату, который хотите получить, но чем это обернётся для пользователей – никто не узнает. Надеюсь, вы ещё не забыли, что разрабатываете продукт не для себя?

Далее я расскажу о разных этапах работ, с которыми вы можете столкнуться при углублении в процессы реализации.

UX

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

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

UI

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

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

Бэкенд

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

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

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

Фронтенд

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

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

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

Заметки и истории

Стандарты качества

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

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

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

Между строк

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

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

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

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

Чтобы не забыть

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

Помните: недосказанность всегда работает против вас!

Когда вы постоянно соглашаетесь с исполнителем и не задаёте ему вопросов, велик риск, что он начнёт делать ошибки и удивляться, почему вы недовольны его работой. Раньше же было хорошо, а теперь всё не так. Работа над проектом должна проходить в формате диалога. Даже если вам всё нравится, узнавайте, почему исполнитель предложил именно такое решение.

Иной раз, задавая вопросы, вы сталкиваетесь с тем, что готового ответа на месте не найдётся. Обязательно фиксируйте непосредственно во время обсуждения все вопросы, договорённости, сроки решения и ФИО/контакты того, кто за это отвечает. Если вы общаетесь по скайпу – пишите всё это в сообщениях. Если лично – держите открытой почтовую программу и составляйте на ходу «протокол» совещания. Это позволит впоследствии не ломать голову над тем, кто кому что обещал и почему ничего до сих пор не готово.

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

Заметки и истории