Как 182 выброшенных часа разработки помогли нам выстроить эффективный процесс проектирования веб-проектов?
Разработка технически сложных веб-сервисов, приложений или сайтов — трудоемкая задача, которая предполагает вливание больших бюджетов. Представьте, что вы решили запустить именно такой проект, нашли надежного ИТ-подрядчика с глубокой экспертизой, выделили средства, проговорили ТЗ, обозначили жесткие сроки и регулярно следите за прогрессом.
Казалось бы, все шаги для успеха проекта выполнены...
Именно на такой крючок мы и попались, когда начали разрабатывать розыгрыш со сложной механикой для одного из наших клиентов без четкой постановки задачи. В итоге были впустую потрачены 182 часа разработки, но еще больше времени ушло у руководителя проекта на урегулирование ситуации. Добавьте к этому безмерное количество нервных клеток с обеих сторон.
Хотя может показаться, что такой опыт лишь подорвал нашу репутацию и украл прибыль, на самом деле он позволил нам выстроить эффективный подготовительный процесс — проектирование проектов. Рассказываем, как это было и какие уроки мы усвоили.
Немного вводных фактов
Лето 2019 года, наш постоянный заказчик ставит задачу реализовать механизм акции для привлечения новых клиентов. Мы получаем 4 страницы описания розыгрыша с крупным призом и жесткие сроки — около трех недель на все про все. Акция должна завершиться к Новому году.
Несмотря на сложную механику, где шансы на выигрыш определяют различные параметры, экс-руководитель веб-проектов решил, что все понятно, и запустил проект в работу. Ни дополнительного сбора требований, ни проработанных corner cases (пограничные кейсы, которые нужно учитывать для качественного пользовательского опыта), ни формализации ТЗ с согласованными форматами схем или документов.
«Изначальное ТЗ от любого заказчика — не готовая постановка задачи для разработчика, по крайней мере, без дополнительного сбора требований и уточнения нюансов будущего функционала. Часто это неформализованное видение конечного продукта в общих чертах. Наша задача не развернуть заказчика со словами «иди пиши нормально», а понять его боль (цель, бизнес-задачу, название не столь важно), которую он хочет выразить в виде текста»,
Предпосылки будущего провала
- Оценка проекта в отрыве от ТЗ. Посчитав вводные заказчика окончательным гайдом для разработки, мы просчитали трудозатраты примерно, без привязки к конкретным пунктам ТЗ.
- Мнимая прозрачность. «Вот задача — реализуйте» — путь к миллиону правок, переписыванию техдокументации и неоправданным ожиданиям.
- Спринтовый дедлайн. Простое на первый взгляд ТЗ, уже налаженное партнерство и отсутствие четкого протокола действий привело к тому, что проект сдали не через три недели, а практически через полгода.
В результате проект был завершен не в начале сентября, а в середине апреля 2020 года, когда на мир обрушилась пандемия и акция была уже неактуальна.
Хьюстон, у нас проблема, или Как мы поняли, что что-то пошло не так
После того как программист реализовал решение по полученному ТЗ и мы с радостью сообщили заказчику, что все готово, начался круговорот неожиданных вопросов. Приведем некоторые из них.
«А мы это себе не так представляли»
«Как посмотреть бонусы, начисляемые за платежи? Где формула, по которой они рассчитываются? Как поменять коэффициент для определенных пользователей? Где список всех участников акции?»
Вот лишь некоторые вопросы, по которым наше воображение не совпало с представлениями заказчика. Оказалось, что конкретики для реализации подобных требований просто не было.
«А что, если пользователь сделает X?»
«А как быть с зарегистрированными, но не авторизированными пользователями? Или юзеры приложения смогут зарегистрироваться в акции, если зайдут на лендинг с мобильного устройства: у нас же для приложения уникальный только телефон, а для сайта — email и пароль?»
Эти кейсы не были описаны в ТЗ, и мы даже не знали, что у заказчика архаичная архитектурная специфика с неуникальным номером телефона. В итоге мы проработали варианты дополнительных требований и модернизировали архитектуру.
«А у нас это работает по-другому»
«А мягкое удаление пользователей сайта как-то учитывается для участников акции?»
Опять же, эта функция не упоминалась в ТЗ от заказчика, а мы не предусмотрели отдельные условия для удаленных таким методом пользователей. В итоге пришлось прорабатывать требования, тратить время на разработку нескольких вариантов реализации и допиливать согласованный.
От неоправданных ожиданий к четкому проектированию
По окончании проекта мы сделали 4 основных вывода:
- Видение заказчика не отражает полную картину. Первоначальное ТЗ от заказчика — это скорее вводные данные, которые нужно проработать, чтобы составить четкое ТЗ. Это можно доказать на паре наглядных примеров, после которых отпадут фразы типа «У вас есть подробное описание задачи, нужно только реализовать ее». Мы как подрядчики при этом демонстрируем экспертность, а не интеллектуальное превосходство.
- Четкие требования — меньше места для воображения. Собирать их можно по-разному. Самый простой и эффективный способ — интервью.
- Из «редких случаев» всегда можно гору сложить. Проработка пограничных случаев стала для нас обязательным пунктом чек-листа при подготовке ТЗ. Важно понимать, что форс-мажоры возможны, даже если тщательно погрузиться в тонкости проекта. На них нужно закладывать время — на всякий случай.
- Заранее согласованный формат работы — меньше сюрпризов. Мы уже сделали заготовки схем и документов, но гибко меняем их под заказчика, например, если нужно применить определенную нотацию моделирования.
Эти уроки фактически стали постулатами предпроектной работы, которую мы назвали «Аналитика и проектирование». Она состоит из восьми шагов, которые позволяют нам глубоко погрузиться в проект заказчика, тщательно продумать и спроектировать модель будущего решения, зафиксировать требования и дать точную оценку затрат на разработку.
Семь раз отмерь — один раз отрежь
Сейчас ни над одним проектом мы не начинаем работу без проектирования и аналитики. Тщательный разбор полетов и часы обсуждений позволили нам вывести ключевые этапы предпроектной деятельности, объективно оценивать сроки и грани возможного, чтобы сразу договориться о реальных ожиданиях с обеих сторон.
В результате мы не только повысили внутреннюю эффективность и качество конечного решения, но и нашли способ сэкономить бюджет заказчика.