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

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

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

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

4.2.12. Что делаем после агрегации

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

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

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

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

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

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

4.2.12.1. Прототипирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.12.2. Пишем ТЗ. Годные шаблоны

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