Как разработка корпоративной системы решает главные проблемы бизнеса

Как часто вы утверждали техзадание, а через три месяца разработки получали вовсе не то, что представляли? Бизнес говорит: «нужно приложение для курьеров», а разработчики слышат: «сделайте всё и сразу, мы пока не знаем, как именно». И начинается: недели уточнений, переписывание требований, а потом внезапно выясняется, что заложенный бюджет не покрывает и половины нужного функционала. Разработка корпоративной системы, это не про код, а про формализацию того, чего вы на самом деле хотите.

Вы когда-нибудь утверждали техзадание, а через три месяца разработки получали вовсе не то, что представляли? Бизнес говорит: «нужно приложение для курьеров», а разработчики слышат: «сделайте всё и сразу, мы пока не знаем, как именно». И начинается: недели уточнений, переписывание требований, а потом внезапно выясняется, что заложенный бюджет не покрывает и половины нужного функционала. Разработка корпоративной системы, это не про код, а про формализацию того, чего вы на самом деле хотите.

Главный враг, не технология, а расплывчатое «сделайте удобно»

Мы вели проект для туристического бизнеса: опытный заказчик, чёткое видение ниши, много идей. Начали с составления функциональных требований, но, как часто бывает, решили, что прототип и дизайн можно делать почти параллельно. Прототип плавно перетёк в дизайн, разработчики взяли макеты в работу до их финализации. А потом у заказчика появился новый сотрудник, который начал переделывать всё под себя. Идеи были толковыми, но они не обсуждались на этапе сметы. Мы влезли в доработки сверх техзадания, проект затянулся на месяцы, а туристический сезон уже открылся. Пока мы «улучшали» функции, которые, возможно, вообще были не нужны, пользователи не получали даже базовой версии. Бизнес-задача «дать туристам возможность покупать экскурсии» утонула в бесконечных хотелках. Ключевой урок: если бизнес не может сформулировать «достаточно хорошо для старта», разработчик не сможет оценить ни сроки, ни бюджет. Это не вина разработчика, это следствие отсутствия жёсткой рамки: прототипа и фиксированного техзадания.

Почему «хотелки» по ходу разработки, это путь к бесконечному ремонту велосипеда

Худшее, что можно сделать с проектом, разрешить доработки до запуска первой рабочей версии. В том же туристическом проекте мы начали делать улучшения по ходу разработки: новый сотрудник заказчика предлагал добавить кэшбэк, потом, реферальную программу, затем, сложную систему чатов. Каждая «мелочь» требовала пересмотра архитектуры, согласования с уже написанным кодом и повторного контроля качества. В итоге время ушло на функции, которые не были утверждены в первоначальной смете. Когда мы наконец сказали «стоп» и запустили первую рабочую версию (минимально жизнеспособный продукт) без этих доработок, оказалось, что базовый функционал уже решает 80% задач пользователей. Заказчик получил реальную обратную связь, и это помогло скорректировать дальнейшие шаги. Мораль: если вы не ставите шлагбаум на изменения до релиза первой версии, вы не разрабатываете корпоративную систему, вы оплачиваете бесконечное прототипирование. Разработка должна быть итеративной, но каждая итерация должна начинаться только после выхода в продуктив.

Прототип и техзадание, не задержка, а единственный способ не выбросить деньги на ветер

Самое удивительное: этап, который все считают «бумажной волокитой», на самом деле экономит больше всего времени. В проекте для сервиса выноса мусора мы поступили иначе. Заказчик пришёл с идеей, мы провели несколько созвонов, составили ментальную карту приложения, заказчик отрисовал прототип со своим дизайнером, а мы описали его в техзадании, задавая уточняющие вопросы и подсказывая, как лучше с точки зрения пользовательского опыта и требований маркетплейсов. Только после утверждения дизайн-макетов и техзадания мы приступили к разработке. И хотя у заказчика возникли проблемы с выводом средств для курьеров (потребовалось менять архитектуру оплаты уже по ходу), это было единичное изменение, которое мы согласовали отдельно, выйдя за пределы оплаченных часов. В итоге проект был запущен в срок, бизнес получил инструмент, который реально работает, а не бесконечно «улучшается». Разработка корпоративной системы без прототипа и техзадания, это как строить дом без чертежей: стены будут, но когда они рухнут и сколько это будет стоить, вопрос к вашему терпению.

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

Пять шагов, которые спасут бюджет корпоративной системы

• Шаг первый: нарисуйте сценарий «как есть». Не абстрактные «нужна система», а конкретика: кто, когда и зачем нажимает кнопку. Опишите три типовые ситуации: идеальную, штатную и аварийную. Только так вы поймёте, что система реально должна делать.
• Шаг второй: соберите «стоп-сигналы». Сядьте с теми, кто будет работать в системе ежедневно. Задайте один вопрос: «Что бесит больше всего в текущем процессе?» Ответы станут красными флажками: ни в коем случае не повторяйте эту ошибку в новой разработке.
• Шаг третий: нарисуйте прототип самому. Не делегируйте дизайнеру. Возьмите бумагу, маркер и накидайте экраны. Задача не в красоте, а в логике. Когда вы сами проведёте пользователя по маршруту, обнаружатся провалы в требованиях, которые не видны на словах.
• Шаг четвёртый: превратите прототип в «тест-драйв». После того как прототип утверждён, проведите имитацию работы: вбейте настоящие данные и посмотрите, как система реагирует. Это единственный способ поймать нестыковки до того, как написана первая строка кода.
• Шаг пятый: зафиксируйте границу «стоп». В техническом задании пропишите чёткий маркер: «После утверждения макетов любые изменения, отдельная заявка и отдельный бюджет». И придерживайтесь этого правила железобетонно. Только так вы не уйдёте в бесконечные доработки.

Частые вопросы

Как оценить бюджет на разработку корпоративной системы, если бизнес требует точную цифру до старта работ

Точная оценка без прототипа и техзадания невозможна. Лучший подход, разбить проект на этапы: сначала оплатить прототипирование и формирование требований, затем получить твёрдую смету на разработку. Это даст бизнесу предсказуемость, а вам, возможность не переплачивать за бесконечные правки.

Почему IT-подрядчики отказываются работать без подробного технического задания и как это связано с качеством системы

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

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

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

Обсудить проект со студией Атма