Kitabı oku: «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий», sayfa 9
3.13. Метод красной рамки
Для программистов, если они не шарлатаны, уже привычно работать итерациями. Какая-то функция на экране готова. Какая-то – нет. В новых версиях в каждый спринт, добавляется что-то новенькое. Но в целом можно уже посмотреть, как ведет себя продукт.
Чтобы не возникало вопросов, что уже готово, а что – нет, рекомендую использовать метод красной рамки. Суть в том, что прописывается специальный стиль (например. todo), выводящий тонкую красную рамку вокруг нужного нам элемента. Этот стиль присваивается тем компонентам интерфейса – кнопкам, полям, формам и т. д. – которые отражаются на экране, но еще не реализованы в коде. Таким образом наглядно видно, что в данный момент готово, а что – нет.
Этот метод работает и в заказной итеративной разработке. Заказчику не нужно будет постоянно объяснять, куда можно тыкать, а куда – нет. Если что-то не работает – мы четко разграничиваем ситуации «сломалось, баг» или «все под контролем, еще не реализовано».
Одна из первых итераций портала Северсталь. Поиск, вход, регистрация и переключение языков еще не реализованы.
Итак, плюсы:
1. Заказчик сразу видит, что готово, а что нет – не тратим время на объяснения, почему не работают некоторые поля.
2. Тестировщик понимает, какие блоки еще сырые, и не тестирует их.
3. У разработчиков не остается шанса промотать задачу.
3.14. Потому что карго-культ!
Во время 2-й мировой войны США строили свои военные базы по всяким разным диким островам в Тихом океане. Продовольствие и шмотки возились самолетами, причем часть груза просто сбрасывалась вниз. Ну, и кое-чего перепадало диким человекам, живущим на этих островах. Причем, иногда перепадало столько, что аборигены полностью забивали на свою хозяйственную деятельность, выращивание бананов и скотоводство. Туземцы быстро уловили, что американцы сами ништяки не производят, а все им достается с неба, за верность духам предков.
Война кончилась, американцы свернули базы. И вот представьте их удивление, когда лет через 20, вернувшись на эти острова, они обнаружили марширующих негров с муляжами ружей, наушниками из дерева, копии самолетов из бамбука в натуральную величину, муляжи аэродромов из соломы… В общем, туземцы довольно четко эмулировали действия американцев, с той лишь разницей, что духи предков почему-то не спешили больше сбрасывать с небес ништяки.
Туземцы не понимали, что стоит за происходящим, не понимали, как устроен мир, и почему с неба падает продовольствие. Поэтому выполняли бессмысленные ритуалы, которые не давали результата.
Не тем ли мы занимаемся, когда выполняем ритуалы, вроде стояния у канбан-доски по утрам или планирования с помощью карт Planning Poker, абсолютно не понимая смысла происходящего? Понимаете ли вы, какие выгоды дает каждый компонент?
Возможно, единственная проблема туземцев в том, что они остановились в своих поисках и экспериментах и не получали какую-либо обратную связь. Истина видимо где-то посередине: разбирайтесь в тех методологиях, которые используете, и постоянно экспериментируйте, оставляя только реально работающие подходы. И ништяки повалятся к вам.
Упорство отличается от Упертости. Упорный, если не получилось, пробует другой подход. Упертый продолжает делать то же самое, рассчитывая на другой результат.
3.15. Для тренировки
Итак, мы разобрали Scrum – гибкий простой фреймворк для организации работы команд над современным софтом! Он задыхается в угрюмой, бюрократичной среде и хорош там, где нужно регулярно улучшать продукт, реагировать на изменения в мире и обратную связь. Мобильные и веб-приложения – самое то!
Задание – иди и внедряй!
Попробуйте это внедрить у себя. Посмотрите, что заработает сразу, а что – ни в какую. Проведите несколько спринтов и ретроспектив.
И постарайтесь не скатываться в СКРАМНО («у нас Скрам, НО без итераций») и Карго-культ.
Успехов!
Литература
▶ Джефф Сазерленд, «Scrum: Революционный метод управления проектами».
▶ Фредерик Брукс, «Мифический человеко-месяц».
▶ Антон Макаренко, «Педагогическая поэма».
▶ Скрамгайд в доступном переводе от Сибирикс (QR-код слева).
Пояснения
Канбан-доска – инструмент метода разработки «Канбан», представляет собой доску, разделенную на этапы работ, с задачами в виде карточек, которые перемещают по доске по мере их продвижения по этапам.
Рефакторинг – перепроектирование или переработка кода, изменение его структуры, которые не производят функциональных изменений, но существенно облегчают его работу.
Закон Мерфи – шутливый философский принцип, который звучит как: «Все, что может пойти не так, пойдет не так».
Story Point – метод оценки сложности задач, когда за 1 балл принимается самая простая задача, а все остальные оцениваются относительно нее.
Автотест (автоматизированный тест) – это скрипт, имитирующий взаимодействия пользователя с приложением, для локализации ошибок в работе сайта, приложения или ПО.
Смоук-тест – минимальный набор тестов на явные ошибки, который обычно проводит программист. Без прохождения такого теста нет смысла затевать более глубокое тестирование.
Продуктив – уже запущенный сайт, живущий на сервере заказчика.
Коммит – в системах управления версиями коммит добавляет последние изменения в часть исходного кода в хранилище, делая эти изменения частью основной версии хранилища.
Confluence – софт для для командной работы, удобный для распределенных команд за счет опций совместной работы.
SingularityApp – мощный хаос-менеджмент планировщик, разработанный в студии «Сибирикс». Существует в виде онлайн-версии для ПК и приложения для смартфонов на Android и iOS.
Википедия проекта – база знаний, где хранятся подробные руководства функционала продукта.
Консистентность документации – цельность документации и согласованность документов друг с другом.
Swagger – язык описания интерфейсов для описания RESTful API, который используется для проектирования, создания, документирования и использования веб-сервисов RESTful.
UML – это специальный язык для описания разных бизнес-процессов, структур и прочих вещей, для которых необходимо последовательное описание. В запутанных ситуациях с большим количеством сущностей может сильно помочь. UML включает несколько видов диаграмм: диаграммы последовательности, компонентов, объектов, структуры, синхронизации и так далее.
Язык описания сценариев Gherkin – человеко-читаемый язык для описания поведения системы, который использует отступы для задания структуры документа (пробелы или символы табуляции). Каждая строчка начинается с одного из ключевых слов и описывает один из шагов. Обработчик разбивает файл с тестами на функции, сценарии и входящие в них шаги.
Часть 4
Аналитика и продуктовые техники
Большинство удачных идей оказывается неудачными.
Британские ученые подсчитали, что 92 % стартапов проваливаются в течение 3 лет. Главная причина – продукт нафиг никому не сдался (42 %).
Я чувствую так же. Мы плотно работали со стартапами с 2010 года. Некоторые из них живы, и даже неплохо живут. Но, оглядываясь назад, я вижу кладбище.
Наверное, всем, кто работал в заказной разработке достаточно долго, знакомо это чувство. Много времени, сил, энергии, интеллекта и отваги вкладывается в какой-то проект, в какую-то идею… И где это все годика через 4? Пшик, очень жаль…
Другое дело, когда проект создавался под конкретную задачу, было заранее понятно, что есть сегмент пользователей, у которых в нем есть потребность, и посчитана экономика. Зачастую это обычные, работающие бизнесы, решившие поглубже залезть в интернет или автоматизировать рутину. Тут, несмотря на кризисы, выживаемость и успешность близки к 95 %. Пойман Product Market FIT (PMF) – состояние, когда клиенты довольны продуктом и рекомендуют друзьям. А сам бизнес растет.
Я уже говорил об этом во введении, об экологичном пути руководителя проектов, но скажу еще раз. Моя религия и пятнадцать лет опыта выращивания руководителей проектов говорят, что если вы только осваиваете управление digital-проектами и не имеете глубокого технического бэкграунда, то самый экологичный путь стать первоклассным специалистом – это поработать некоторое время в тестировании и аналитике.
В этой части мы посмотрим на техники управления продуктом, которые помогут минимизировать галлюцинации основателей, нащупать сегменты пользователей, протестировать гипотезы и т. д. Этими инструментами должны хорошо владеть руководители продуктов и аналитики. В маркетянские штуки уходить не будем.
Для руководителей проектов инструменты полезны. Во-первых, для понимания, как Product Owner принимает решение. Во-вторых, на вырост. В-третьих, скорее всего, Product Owner что-то из этих штук сам делать поленится, или его нужно будет возвращать в реальность. А кто будет делать все то, что делать надо, но не делает никто другой – вы уже в курсе.
Итак. Путь к крутому руководителю проектов и продуктов лежит через аналитику. Разберитесь в этом. Погнали!
4.1. Цель аналитики digital-проектов
Если не знаешь, какой херней ты занимаешься на работе, – назови это «Аналитика».
Народная мудрость
К сожалению, вокруг аналитики digital-проектов в последнее время накрутили много хераборы. Методов и подходов стало слишком много. Непонятно, за что хвататься и что применять.
Этап аналитики нужен, чтобы верно понять ожидания заказчика, спроектировать оптимальное решение поставленных задач и грамотно спланировать бюджет.
Если раньше аналитика была вспомогательной функцией, сейчас – стала чуть ли не самоцелью. Я видел команды, которые по полгода играют в «Дизайн-мышление» или еще какой-то новомодный метод, производя только трындеж. Бюрократия – такая бюрократия. Правда, кризис оставил бездельников за бортом.
Давайте исходить из того, что:
Цель аналитики в digital-проекте – получить структуру будущего проекта и четкий план действий: сначала мы делаем это, потом то, а затем – вон то.
Понятно, что и план и структура со временем могут меняться. Понятно, что в сложном проекте лучше семь раз подумать. Поэкспериментировать. Но в какой-то момент нужно перестать анализировать все подряд. И начать писать код.
4.1.1. Что нас ждет в этой главе
Инструментарий руководителя digital-продукта
Для заказной разработки нам понадобится Агрегация требований, прототипирование и подготовка технической документации. Когда есть заказчик (или владелец продукта) – этого достаточно.
Для самого владельца продукта существует ряд дополнительных подходов: HADI-циклы, CustDev, методы сегментации пользователей и различные способы скоринга бэклогов.
Методы дополняют друг друга. Однако стоит к ним относиться как к арсеналу: снаряжаясь на войну, вы не сможете забрать на себе весь арсенал. Вы выберете один или два вида оружия и что-то из защиты. Кто-то возьмет лук, поскольку меткий. Кто-то меч по руке. Но весь арсенал вы на себе не потащите.
Точно так же нет смысла тащить в проект все известные способы приоритизации бэклогов. Выберите один, который вам нравится. И заточите его под вашу ситуацию.
Как этим пользоваться: прочитайте главу один раз. Ознакомьтесь со всеми методами. Выберите те, которые вам понравились. Изучите их подробнее. Начните применять. Время от времени пересматривайте подходы. Возможно, в качестве эксперимента, захочется попробовать какой-либо другой метод.
Итак. Что нас ждет.
Во-первых, мы рассмотрим метод Агрегации требований. Формально он состоит из 5 шагов:
1. Видение проекта. Это основные характеристики будущего продукта. Его цели и задачи – так, как их понимают создатели продукта.
2. Целевые персоны. Здесь мы идем от пользователей. Сегментируем рынок. Выделяем боли и потребности пользователей. Проводим интервью. Строим сценарии поведения и CJM – карту путешествия клиента.
3. Конкурентный анализ.
4. Структура проекта. Какие экраны нам нужны. Что на них будет.
5. Идеи на будущее. Все то, что было бы неплохо сделать.
Во-вторых, посмотрим, как делать регулярную аналитику в продуктовых командах на основе HADI-циклов. Разберем 4 силы, действующие на продукт. Поговорим о фреймворках RAT и JTBD.
В-третьих, поговорим про юнит-экономику продукта. Эта информация будет нужна руководителю проекта, чтобы понимать, на основе чего руководители продуктов принимают решения. На самом деле, метрик бесконечное множество и тут легко запутаться.
В-четвертых, поговорим про техники скоринга и приоритизации бэклогов, так, чтобы галлюцинации основателей действовали минимально.
В-пятых, посмотрим, как UML-диаграммы помогают при проектировании программных продуктов, продумывании взаимодействия с пользователем.
4.2. Агрегация требований в заказной разработке
Эта техника лучше всего работает в заказной разработке. Либо когда уже в общих чертах понятна задача, осталось только вытащить детали из голов стейкхолдеров, примерить их на целевую аудиторию, убедиться, что не допущены ошибки конкурентов и учтены тренды отрасли. Подходит для большинства сайтов и мобильных приложений. Позволяет синхронизировать видение у заказчика и разработчика, а также довольно точно подсчитать бюджет разработки. Это, в основном, – кабинетный анализ, который можно подкрепить интервью с потенциальными пользователями (см. главу о Customer Development) и A/B-тестами. В итоге у нас должна получиться структура будущего проекта. Для фиксации предлагаю использовать формат интеллектуальных карт.
Агрегация требований – основа проекта в заказной разработке. Именно на этом уровне мы понимаем, что на самом деле нужно заказчику и его клиентам. Где границы возможного с точки зрения человеческих и финансовых ресурсов. Как лучше всего сделать сайт или мобильное приложение, какие системы надо сшить друг с другом, чтобы решить поставленные задачи. Как выделиться в конкурентной среде и при том уложиться в реальные для заказчика бюджет и сроки.
Чаще всего, в заказной разработке мы создаем Агрегацию требований в формате интеллектуальных карт. Например, XMind или XMind Zen. Альтернативные программы можно найти в конце главы, в списке литературы.
Агрегация требований РостСельМаш (фрагмент)
По итогам агрегации мы узнаем:
▶ какие цели и задачи у будущего проекта;
▶ что ждет от него целевая аудитория;
▶ что хорошего и плохого в проектах конкурентов;
▶ как все это учесть и совместить, чтобы одно другому не мешало;
▶ как лучше запустить проект: весь сразу или по частям, и с чего начать;
▶ какой будет структура сайта, на основе которой аналитик готовит прототипы и пишет техническое задание;
▶ рассчитываем довольно точно сроки и бюджет проекта.
4.2.1. Стейкхолдеры
Стейкхолдеры (stakeholder) – заинтересованные в проекте лица. В заказной разработке от них исходит большая часть требований.
Однако бывает, что стейкхолдеры явно не определены. Прячутся за корпоративной иерархией. Влияют, но не отвечают.
В процессе реализации проекта власть в организации, если взять ее за 100 %, как-то перераспределяется. Как только появятся первые результаты проекта – все, кто хоть как-то был затронут этим решением, выскажут свое мнение. Иногда этих мнений слишком много. Или мнения слишком громкие. Или противоречивые. Придется разбираться. Чем раньше, тем лучше.
Проекты, в которых заинтересовано первое лицо компании-заказчика, проходят гораздо ровнее. Нужно четко понимать, кто у заказчика Альфа, кто Бета. Проекты, в которых внутри заказчика постоянные споры и конфликты, и нет никого умного, кто мог бы во всем разобраться и принять твердое, окончательное решение, с треском проваливаются. Либо идут медленно и печально. Либо требуют молоть языком больше, чем писать код.
Итак. В заказной разработке важно как можно раньше выявить стейкхолдеров. Выявить их интересы. Скрытые и явные конфликты. Понять иерархию стаи. Заручиться поддержкой Альфа- и Бета-стейкхолдеров.
4.2.2 Видение проекта
Первый шаг Агрегации требований – это видение проекта или его основных будущих характеристик. Здесь мы определяем, какой продукт мы делаем, и что он из себя представляет. Видение должно быть конкретным: если при смене названия бренда видение клиента останется прежним, оно никуда не годится.
Обозначаем перечень и ожидания заинтересованных лиц (стейкхолдеров). На этом этапе целесообразно рассматривать стейкхолдеров только со стороны заказчика, поскольку пользователям сайта посвящена отдельная вкладка. Чаще всего заинтересованные лица делятся на несколько уровней:
▶ собственники и управленцы (могут совпадать, но не всегда);
▶ представители отделов продвижения и продаж;
▶ обслуживающий персонал (операторы, контент-менеджеры, администраторы).
Разумеется, у всех у них очень разные ожидания от будущего проекта. Важно обозначить главные направления, добраться до сути: зачем на самом деле создается проект, как он должен изменить жизнь причастных к его эксплуатации людей.
Необходимо развернуто зафиксировать суть ожидания и кратко обозначить, какие пути решения мы видим для него на этом этапе. В ходе дальнейшего анализа, в том числе после получения отклика со стороны заказчика, список решений может корректироваться. Часть идей может быть отложена до будущих этапов развития сайта.
На этапе видения определяются цели и задачи проекта. Цель – чего именно хотим достичь. Увеличение конверсии, увеличение числа интернет-заказов, оптимизация работы менеджеров. Задачи – что конкретно будем делать. Семантическая разметка, фишки в юзабилити, интеграция с CRM.
Важно! Не нужно писать сюда все бизнес- и жизненные цели, о которых упоминал заказчик – только то, что реально касается разрабатываемого проекта, может быть объективно оценено и измерено. К примеру, если пишешь о росте конверсии, сразу подумай, какие наши действия к этому гарантировано приведут, и как вы с заказчиком измерите «было-стало».
Вкладка формируется на основании данных, полученных при изучении первичных материалов от заказчика, его брифования, общения со стейкхолдерами. С поправкой на опыт и здравый смысл.
Кстати, про здравый смысл и галлюцинации!
4.2.2.1. Галлюцинации основателей
Мы с тобой свернули не туда вообще
И все закончится для нас теперь так себе.
Znaki
Вы когда-нибудь пробовали отговорить основателя от его идеи? Большинство из них настолько сильно убеждают себя, что на их продукт есть спрос, и настолько харизматичны (или властны), что проще дать сделать то, что они хотят, чем объяснить, почему нет.
Вот несколько галлюцинаций основателей, которые мешают:
▶ «Мы знаем нашу целевую аудиторию, просто сделайте, как мы сказали». По факту, аудиторию они не знают, а мантра «мы все знаем», повторенная несколько раз, дает ложную уверенность контроля. Типичный итог – отсутствие потребности в продукте. Нет сегмента покупателей.
▶ «Мою идею украдут». Сразу тревожный звоночек. Идеи не стоят ничего. Артемий Лебедев писал про «Идею на минус миллион» и вообще считает, что идеи имеют отрицательную ценность.
▶ «Мой продукт должен быть идеальным». Перфекционизм. Во-первых, это дорого. Во-вторых, за этим прячется боязнь показать продукт рынку. А вдруг обидят?
В ту же копилку:
▶ Тантрический стартап: три года без релиза, ни дня без чендж-реквеста!
▶ Обратная связь от пользователей откладывается на месяцы.
▶ «Сделайте нам прибыльный проект за процент от будущей прибыли». Нет денег на фоне повышенной хитрожопости. Либо нет денег на разработку. Либо на маркетинг. Либо на то и другое.
▶ Усложнители. Затея либо сразу настолько сложная, что в деталях путается даже сам основатель. Либо пытаются использовать какую-то технологию там, где она нафиг не нужна. Блокчейн для учета шкурок крупного рогатого скота, например. Фаза анализа проблемы и потребности пропускается, идем сразу в архисложное решение.
▶ Немасштабируемые продукты.
▶ Подражатели. Уже давно замечал, что заявки на разные типы стартапов приходят волнами. Был когда-то всплеск на социальные сети. Аналоги купонаторов. Скандинавских аукционов. Как-то осенью нас засыпало заявками «Продайте долю в игре в соцсетях». Потом были маркетплейсы. Где-то людей «Бизнес-молодость» зомбирует, честное слово!
Давайте исходить из того, что у основателя есть определенная стратегия, видение, а наше дело – помочь все это реализовать по красоте, исходя из нашего опыта и знаний.
4.2.2.2. Почему брифы – зло
Я не люблю письменные брифы. В своей работе мы их почти не используем. Брифы не дают ясной картины. Теряется много важных деталей. И главное!
Брифы мешают строить долгосрочные отношения с клиентом!
С другой стороны, я понимаю заказчиков. Вернее, менеджеров на стороне клиента, которых отправили «найти подрядчика». Они (агентства), блин, все одинаковые! Гораздо проще заполнить один раз анкету. Разослать в сотню агентств. Получить КП-шки. Распечатать, отсортировать по «Итого:». И положить их боссу на стол. Минимальная ответственность. Минимальная трудоемкость. Божественный КПД – результата можно целую кучу навалить.
С одной стороны, так было и будет всегда. С другой стороны – понятна степень заинтересованности проектом. Агентствам нужно уметь под это подстраиваться.
Любые проекты, стоимостью в миллионы и длительностью в месяцы, обязательно обсуждаются устно. И не один раз. Есть примерный и понятный круг вопросов, с которых можно начать. Однако нужно иметь достаточно опыта, чтобы погружаться в глубину по любому из вопросов.
Компания
Какие есть компетенции?
В чем суть бизнеса? Что приносит доход?
Узнаваем ли бренд? Какова лояльность аудитории?
Какие есть сложности?
Продукт
Сильные стороны. Почему это должны купить?
В чем отличие от аналогов?
Есть ли товары-заменители (не прямые)?
Жизненный цикл. Как часто пользуются? Как долго?
Покупатель (ЦА)
Кто он?
По сегментам аудитории: объем группы, темпы роста и т. д.
Чего он хочет? Потребности?
Какая цена приемлема?
Как привык потреблять? Получать информацию?
Конкуренты
Кто конкуренты? Какие у них сильные стороны?
Насколько наполнен рынок?
Чем вы лучше других? (Осторожнее с этим вопросом – тут горят пуканы!)
Каковы преимущества? Есть ли уникальные продукты, фичи?
Какие есть трудности и барьеры?
Планы развития?
Это общие направления вопросов, которые нужно адаптировать под каждый конкретный проект после изучения вводной информации. Может быть много нюансов.
Например, на e-commerce-проектах возникает несколько десятков вопросов по экономике, налогам, логистике, возвратам, интеграциям с внешними системами и т. д. Нужно включить вопросы по всему, что кажется непонятным и странным в проекте. А также затронуть все вопросы, ответы на которые лягут в основу вкладок Видение и Анализ целевых персон.
Итак. Ни один бриф не заменит голову. Письменные брифы – скорее, зло. Какова альтернатива?
