Очень интересно, но ничего не понятно. Работа с масштабными задачами без конкретики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#Разработка сайта