Очень интересно, но ничего не понятно

Факт номер 1: каждый из нас обожает моменты, когда приходит начальник/коллега/заказчик, протягивает папочку/флешку/картинку, мы смотрим, а там – ба! – пошаговое описание задачи/проекта, что нам предстоит реализовать. С четкими дедлайнами, просчитанными рисками, полными ТЗ и красивыми графиками.

Факт номер 2: в реальной жизни такое происходит с избранными 1 раз в сотню лет. А может, в пару сотен. Но это не точно. И только с самыми избранными.

Что же делать, если такая удача пока не улыбнулась, а работать с четкими и понятными задачами по-прежнему хочется? Учиться их делать такими самостоятельно.

Возьмем самый банальный, но самый распространенный в сфере разработки пример – сделайте мне....

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

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

Шаг №1: брифование

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

То, что у заказчика есть хоть какое-то понимание желаемого проекта – отличный старт. Без сарказма. Задача менеджера – разложить входные данные по функциям, понять, чего еще не хватает для формирования хотя бы первичного, но целостного видения проекта, и задать эти вопросы заказчику. При таком подходе – об общего к частному – не стоит сразу заваливать бедолагу вопросами о мелочах: «какого цвета будет кнопка на карточке товара, сколько позиций будет в списке товаров, будет ли наценка у доставки». Мы все это спросим, но в шаге 4.

После получения ответов мы уже можем провести оценку в формате «от-до». Очевидно, что погрешность будет «+- много», но такая оценка необходима. Либо заказчик с ней смирится, и вы продолжите углубляться в проект, либо согласится упростить функционал для удешевления проекта. Не стоит отбрасывать исход, когда заказчик после первичной оценки отказывается в целом от задумки из-за её стоимости – это его право.

Шаг №2: декомпозиция

Многие идеи выглядят гениально и просто, пока мы мыслим глобально.

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

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

Декомпозиция шаурмы, 21 век н.э

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

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

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

• Интернет-магазин (площадка для покупателей);
• B2b-кабинет (хороший ЛК для партнеров может быть трудозатратнее в реализации и дороже, чем весь интернет-магазин);
• Маркетинговая поддержка (никто не зайдет на новый сайт просто потому, что он классный, ведь никто о нем не знает и не узнает без дополнительных мероприятий по привлечению трафика);
• Человеческие ресурсы (кто-то должен готовить контент для пресс-релизов, сайта, поддерживать его актуальность, принимать заказы, общаться с покупателями и поставщиками, юридически сопровождать проект);
• Приложение (на крупном рынке без него сейчас никуда, пользователи слишком привыкли к приложениям и оформлению покупок через них).

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

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

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

Шаг 3: маркетинговые исследования, анализ рынка и конкурентов

Многие идеи выглядят гениально и просто, пока мы не погружены в тему.

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

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

Если коротко, по итогу анализа проект из суперпозиции (он одновременно может быть как успешен, так и не успешен) обретает вполне подкрепленный фактами статус:

• Идеальный – продукция/услуги пользуются высоким спросом, конкурентов нет/конкурентов мало/конкуренты есть, но их продукты сильно устарели;
• Реальный – продукция/услуги пользуются средним/высоким спросом, конкурентов мало, но есть 1-2 «выскочки», которые постоянно поддерживают актуальность своих продуктов, развивают их;
• Печальный – продукция/услуги пользуются любым спросом, конкурентов очень много, борьба за трафик неминуема, потребуется вложение больших бюджетов на ее ведение, сроки окупаемости «за горизонтом»;
• Фатальный – продукция/услуги не пользуются спросом, конкурентов нет, бороться ни с кем не надо, но и не за что – трафика нет, окупаемость любых вложений не прогнозируема.

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

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

Шаг 4: проектирование

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

У Waterfall, например, ТЗ стоит во главе угла, проектирование должно быть максимально подробным и всеобъемлющим, каждый этап работ должен быть конкретизирован и следующий этап может стартовать только после завершения предыдущего. Изменения в ТЗ в процессе реализации не вносятся, а если вносятся – обновляется все ТЗ. Продукт запускается после готовности и тестирований.

Манифест водопадной модели разработки ПО

• Следуйте правилам;
• Нет ТЗ — нет продукта;
• Чем подробнее ТЗ, тем лучше продукт;
• Следите, чтобы не было изменений.

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

Манифест гибкой разработки ПО

• Люди важнее инструментов;
• Качество продукта важнее документации;
• Взаимодействие с заказчиком важнее контракта;
• Готовность к изменениям важнее установленного плана.

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

Брифование и декомпозиция здесь снова вам в помощь, да пребудет с вами Agile/Scrum/Waterfall (любимое подчеркнуть).

Шаг 5: реализация.

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

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

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

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