Проектируй это: как сэкономить до 40% бюджета на разработке

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

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

И после деликатных слов сочувствия я задаю вопрос, который обычно все ставит на свои места: «А можно посмотреть проектную документацию?». На местах все оказывается после ответа, который я слышу чаще всего: «А у нас такой нет».

Тогда я задаю следующий вопрос — почему? Ведь это нормальная практика — брать в поход предварительно изученную карту местности и приступать к стройке только после того, как получим от архитектурного бюро завершенный проект со сметой? Почему в случае с цифровыми проектами компетентные, вроде бы, люди поступают по-другому?

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

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

Впрочем, грешат этим не только заказчики. Многие разработчики подходят к реализации проекта «от дизайна», игнорируя этап составления технической документации. Они просто разрабатывают решение, опираясь на макеты, нередко созданные не совсем компетентными в вопросах UX людьми.

Вместе с тем, существует высокая степень недоверия к экспертным рассказам о специфике работы с технологиями. Возможно, этому способствует укоренившееся в российском бизнес-мышлении суждение «Не обманешь — не продашь». Заказчик с огромной осторожностью относится к словам о необходимости внедрения/использования определенных решений, о сложностях, которые могут возникнуть на пути реализации проекта. Однако часто ни к чему, кроме нарастающей технической безграмотности такая осторожность не приводит.

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

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

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

Реализованная на бэкенде логика сервиса, должна быть прежде описана в строгой форме. Как правило, для этого используются UML-диаграмма (описание всех экранов и элементов, которые должны войти в интерфейс), структурная диаграмма (концептуальная модель, которая описывает атрибуты объектов и их связь между собой) и спецификация требований (сопутствующий текст с четко определенной терминологией). Текст описывает систему, что и как в ней работает, как и что в ней взаимосвязано.

Приниматься за реализацию более-менее сложных проектов без разработанный спецификации требований — это как начинать строительство здания без проектной документации: заведомо провальное дело.

Даже в более-менее обеспеченных документацией проектах мы часто сталкиваемся с неучтенными моментами, поскольку практически любой IT-проект — история длинная и сложная, с огромным количеством постоянно генерируемых вводных.

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

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

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

Это наш принцип. Мы не берёмся за реализацию проекта, если нет детального описания того, что нужно сделать. Существуют исключения, небольшие проекты, когда прототипов или концепции достаточно для старта полноценных работ. Однако при более масштабной разработке проектирование должно быть обязательно выполнено. Тут мы или используем документацию, полученную от заказчика, при необходимости дорабатывая её. Или сами осуществляем все работы по проектированию.

Павел Семёнов,
операционный директор IT-компании RS

#проектирование #разработка #RSdesign #проектирование_сайта #проектирование_интерфейсов