Как успешно убить проект без аналитики и дизайна

Очевидно, что без грамотного технического задания подступать к разработке бессмысленно, аналитика и UX/UI дизайны важны, однако не все заказчики это понимают. Еще до создания студии YuSMP Group, мне приходилось управлять проектами, в которых проигнорировали ТЗ и предварительные дизайны. Проекты были разными, а вот результат всегда один — заказчики теряли время и деньги.

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

Как успешно убить проект без аналитики и дизайна

Кейс 1. Времени нет, погнали разрабатывать

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

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

Когда я начал рассказывать клиенту про дизайны и аналитику, клиент не стал меня слушать: «Нет времени, погнали разрабатывать».

И мы запустили разработку. Я как мог, выяснял требования и ставил задачи команде (мы пытались работать по Scrum), но когда мы показали клиенту пробную версию мобильного приложения, оказалось, что мы все сделали не так. Несмотря на то, что я общался и фиксировал все результаты встречи, мы с клиентом неправильно понимали друг друга все это время.

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

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

Сейчас я бы предложил двигаться по Scrum, но обязательно с техническими требованиями, кликабельным прототипом, сделав в самом начале дизайн-концепт.

Кейс 2. Нам достаточно только экранов приложения

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

Когда предложил аналитику для описания алгоритмов поведения системы, ответили: “Нам достаточно экранов приложения». Тогда я не стал спорить с заказчиком и мы успешно согласовали все экраны.

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

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

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

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

Кейс 3. Начали за здравие, закончили за упокой

Даже если заказчик никуда не спешит и не отказывается от техзадания, все может пойти не так. Таким примером стал еще один проект: мы сделали аналитику и дизайн, показали кликабельные прототипы и всё последовательно передавали в разработку.

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

В результате множества итераций у нас все смешалось в аналитике и дизайне: команда уже не понимала, что изменяла, а что нет.

В итоге пришлось приостановить проект для нормализации аналитики и дизайна и только потом двигаться дальше. Было упущено время проекта, а компании пришлось компенсировать клиенту расходы.

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

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

1111
6 комментариев

хипстеры из веб-студий продолжают переизобретать промышленную разработку

вы бы хоть что современное применили, типа Event Storming

а то ведь всё бред сивой кобылы

"Я как мог, выяснял требования и ставил задачи команде (мы пытались работать по Scrum), но когда мы показали клиенту пробную версию мобильного приложения, оказалось, что мы все сделали не так. Несмотря на то, что я общался и фиксировал все результаты встречи, мы с клиентом неправильно понимали друг друга все это время."

в скраме мобильной разработке спринт длится не больше 2-х недель, истории сдаются по мере готовности, а не целиком всем приложением, и в целом расхождения на 1-м спринте это вполне нормальная ситуация, первые спринты именно нужны для того, чтобы сработаться с заказчиком

"аналитика" — это процесс работы с ЦИФРАМИ
https://en.wikipedia.org/wiki/Business_analytics

когда вы работаете с отдельными фактами и отдельными явлениями — потребностями, интересами, требованиями, задачами, история — то это называется "анализ", а не "аналитика"
https://en.wikipedia.org/wiki/Business_analysis

"Как надо было сделать: сразу настаивать на техническом задании вместе с дизайнами и кликабельным прототипом"

в скраме нет никакого технического задания, есть бэклог продукта и бэклог спринта, что вы несёте

3
Ответить

Рад, что у вас есть время на едкие замечания, всего наилучшего)

Ответить

не нашёл в артефактах Impact Map и Story Map — а это основные инструменты менеджмента затеи — целеполагания и планирования

1
Ответить

Дизайн по мелочёвка каждый может,серьёзное не каждому дано.

Ответить