Текст книги "Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий"

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

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

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

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

Почему так? Почему нельзя сразу сказать точную стоимость разработки? Допустим, вы решили построить уютный коттедж. Выбрали несколько подходящих компаний, которые могут это сделать. И в первом разговоре с прорабом задаете ему вопрос: «Сколько стоит дом?» Тут велик шанс, что вы получите обтекаемый ответ: «От 300 тысяч до 50 миллионов». Слишком мало данных для оценки, потому и такой ответ. Бюджет на основании этого вы вряд ли спланируете.

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

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

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

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

«Назовите точную стоимость без проектирования и аналитики и впишите ее в контракт, бу-бу-бу. А еще нарисуйте нам пять вариантов дизайна. Прямо к завтрему». Я рекомендую отказаться от таких клиентов. Шалаш без плана построить можно. Высотный дом – нет.

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

В заказной разработке после агрегации нам нужно:

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

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

3. Написать бэклог (или, в зависимости от контракта, – ТЗ, которое затем будет разделено на бэклог).

4. Рисовать. Кодить. Запускать версию за версией. При этом без проблем отклониться от изначального плана: что-то сделать раньше, что-то убрать на следующие этапы.

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

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

Цели прототипа:

▶ согласовать структуру сложных страниц с заказчиком;

▶ проверить, будет ли проект удобен для конечных пользователей с точки зрения персон;

▶ убедиться, что все участники проекта одинаково представляют зафиксированные в структуре идеи, а сами идеи жизнеспособны – понятны и удобны для пользователя;

▶ предложить альтернативные решения для нежизнеспособных идей (самое время).

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

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

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

Думайте, как этим будут пользоваться реальные люди

Будет ли это удобно? Решит ли это их проблему? Поставьте себя на их место.

Выравнивайте за собой везде и всегда

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

Используйте реальный контент

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

Пишите комментарии по неочевидным элементам

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

Не шутите в аналитических документах

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

Используйте метод прогрессивного джипега

Сначала накидываем общую картину, без детализации, основными блоками. Затем – постепенно детализируем каждый блок до нужной степени.

Бывают ситуации, когда на главной странице нужен супер-вау-эффект. Что делать в таких ситуациях? Рисовать в промо-блоке большой зачеркнутый прямоугольник с подписью: «Здесь будет креатив» – как-то не очень удобно, плюс порождает сотни вопросов у заказчика. Двигать этот вопрос на этап дизайна (мол, потом разберемся) – не всегда экологично: а, собственно, зачем тогда в этой схеме прототип? Совсем без прототипа – велик риск не попасть в ожидания на дизайне, и в дальнейшем поиметь множество проблем с перестановкой блоков на готовом макете.

Мы поступаем следующим образом:

1. Перед началом прототипирования проводим брейншторм. На нем сразу придумываем какую-то фишку проекта. На брейншторм обязательно зовем дизайнера и аналитика.

2. Дизайнер накидывает карандашный скетч идеи, которую мы придумали.

3. Привлекаем студийного копирайтера: он готовит тексты для страницы.

4. Аналитик делает прототип: вставляет реальные тексты, схематично показывает идею.

5. Презентуем прототип и скетч заказчику вместе с дизайнером.

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

Агрегация есть, прототип готов и утвержден – самое время перейти к техническому заданию на разработку проекта. ТЗ – артефакт известный. Это толстый документ, в котором очень детально описано, что за проект в итоге получится. Беда с этим документом в том, что им очень неудобно пользоваться. Огромный объем сурового технического текста со специальной терминологией крайне сложно читать. А уж представить себе итоговую картинку в голове, понять, как это будет работать физически, – практически нереально. Особенно если опыта в чтении таких ТЗ немного.

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

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

В чистом Scrum-е как такового технического задания нет. Там есть бэклоги. Бэклог – это список функционала (по-другому, фич), отсортированный по приоритетам, по которым идет разработка. Можно менять фичи в любой момент, и это не вызывает проблем на стороне команды. Приоритеты при этом регулярно пересматриваются.

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

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

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

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

Разработка прототипа и ТЗ к нему обычно съедает около 12 % бюджета проекта. На первый взгляд – много (и это реально много!). Но это не более трудозатратно, чем создание традиционного «железобетонного» технического задания на разработку сайта, которое пытается учесть каждый чих. К тому же, в первом случае процесс прогнозируем по срокам и позволяет избежать гораздо большего вылезания из сроков и бюджета.

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

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

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

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

Типовая структура нашего технического задания содержит следующие разделы:

1. Общие сведения. Здесь самое важное – приоритеты документов проекта. Наше ТЗ – приложение к прототипу сайта. В случае расхождения технического задания и прототипа – приоритет имеет техническое задание. В случае расхождения утвержденного дизайна и технического задания – приоритет имеет дизайн. Итого: что позднее сделали, то и принимается за истину. У сметы – максимальный приоритет.

2. Назначение и цели создания сайта. Пара слов: что делаем и для чего. Например, интернет-магазин на 1С-Битрикс с функциями доставки и онлайн-оплаты. Плюс сюда же мы добавляем цели, которые берутся из Агрегации.

3. Требования к верстке.

4. Настройка прав доступа. Например, два пользователя, администратор и контент-менеджер.

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

6. Описание структуры страниц. Название страницы, что на ней будет по пунктам, описание механики работы каждого пункта.

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

8. Описание уведомлений. Это те письма, которые получают на почту пользователи и администратор сайта. Или SMS. Например, уведомление об успешном оформлении заказа. Или о том, что поступила новая заявка.

Ради общего развития рекомендую изучить ГОСТ 2.105–95 – общие требования к выполнению конструкторских и технологических документов.

Когда дело касается разработки сложных проектов вроде интернет-магазинов не обойтись без интеграций со сторонними системами. Например, нужно, чтобы товары передавались из 1С на сайт, а сайт отдавал в складскую систему заказы. А еще нужно, чтобы заказы передавались в CRM. Операторы колл-центра будут забирать их оттуда, обзванивать клиентов и подтверждать заявки. В подобных проектах должны быть описаны интеграционные протоколы – о них поговорим отдельно в главе 12.

4.3. Продуктовые техники

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

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

Итак. Есть самолетик – неважно, реактивный или винтовой. Самолет пытается взлететь по взлетно-посадочной полосе. Но полоса хитрая. В виде конвейера. Самолетик – вперед. Полоса – назад. Этот – вперед, та – назад. Скорости совпадают. Взлетит или не взлетит?

Прелесть загадки (несмотря на то, что она не совсем корректно сформулирована – самолетик все же двигается с ускорением, его скорость не постоянна) в том, что ответ на нее зависит от множества факторов. Однако есть четыре силы, действующие на самолет. Подъемная сила Y, вес самолета G, сила тяги P и сила сопротивления Q. Две из них, грубо говоря, «помогают» лететь. А две – мешают.

А теперь интересная аналогия. Взлетит ли ваш проект?

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

И да. Иногда достаточно просто очень мощного двигателя.

Painkillers – продукты, которые из «отвратительно» делают «нормально». Например, позволяют подать электронную декларацию вместо того, чтобы терять полдня в потной очереди. Была какая-то боль. Кто-то пришел и ее решил. Тут важно найти сегмент с сильной болью, например, проводя проблемные интервью. 7–8–9–10 из 10 по шкале, где 10 – самое отвратительное, что могло бы с вами случиться – это как раз нужные нам люди.

Delighters – продукты-витаминки. Которые из «нормально» делают «отлично!». Например, продукты линейки Apple. Проблемы-то особой не ощущалось. Тут кто-то раз – и придумал iPod, AirPod и вот это вот все. Главное, чтобы пользователь кайфанул. И перестал использовать старый продукт. Однако мы помним про 4 силы. Старые привычки будут нам мешать, и продукт нам нужно сделать в три раза лучше, чем у конкурентов. Причем, «лучше» – с точки зрения субъективного восприятия пользователя. Та еще задача.

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

https://gameconstructor.ru/?p=119

Статья «47 игровых механик» – в тему.

Кстати, прикрутить к хреновому, скучному B2B-продукту геймификацию, и считать, что «вот теперь взлетит» – гиблая затея.

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

1. Составьте список самых рискованных гипотез на вашем проекте.

2. Проранжируйте от наиболее опасного к наименее опасному.

3. Проверьте свои предположения сверху вниз: от наиболее рискованных к наименее.

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

Каким именно образом проверять гипотезы – RAT не говорит. Это может быть и интервью с потенциальными пользователями (они врут), и изучение конкурентов, и общение с экспертами. А может быть запуск какого-то простого «пилота» (пилотного проекта).

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

1. Есть рынок. А на рынке есть сегмент с сильной потребностью (болью).

2. Мы можем сделать продукт, закрывающий эту потребность (хватит экспертизы, денег, серверных мощностей).

3. Они это купят. У нас.

4. Мы на этом заработаем. Иначе можно просто раздавать людям деньги – будет быстрее и приятнее. Прямо с вертолета скидывать. Тут помогает расчет Unit-экономики.

5. Продукт можно масштабировать. Например, бизнес web-студии масштабировать нельзя: если мы хотим больше зарабатывать – нам нужно больше высококвалифицированных людей. А вот бизнес по аренде самокатов или прокату музыки – можно.

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

https://disk.yandex.ru/i/Ov9s3oHHIj-jvA

Итак. RAT – это просто три шага к проверке самых рискованных гипотез на проекте. И в любом проекте есть пять основных рисков.