«Мы заплатили подрядчику 3 млн, а через полгода не смогли ничего изменить»: как документация спасает от привязки к вендору
Хотите узнать, как оказаться в ловушке собственного IT-проекта? Закажите разработку «под ключ» и забудьте про документацию. А через год попробуйте сменить подрядчика или просто разобраться, как всё устроено. Наш клиент - проджект-менеджер - прошёл через это. И больше не хочет. Рассказываем, как за месяц мы построили систему, где заказчик владеет знаниями, а не только продуктом.
О чём этот кейс
К нам пришёл проджект-менеджер крупного бизнес-заказчика. У него за плечами - несколько успешно сданных проектов. И одна незаживающая боль.
В предыдущем проекте подрядчик сделал систему. Сдал. Получил деньги. А через полгода заказчик решил доработать функционал с другой командой.
И тут выяснилось, что:
- Технического задания, отражающего реальность, - нет
- Архитектуры, схем, описаний API - нет
- Пользовательских инструкций - нет
- Есть только код и люди, которые его писали
Заказчик стал заложником прошлого подрядчика. Потому что только в их головах - знания о том, как всё работает.
«ФАБРИКА ДАННЫХ» получила задачу: сделать так, чтобы больше такого не повторилось.
Проблема: почему заказчик всегда в зоне риска
Любой проект разработки - это зона неопределённости. Особенно когда речь идёт о документации.
Какие риски несёт заказчик:
Классический подход, который только усугубляет эти риски:
- Сформировали Техническое задание. Утвердили.
- В процессе разработки внесли изменения. В ТЗ - нет.
- Обсуждения шли в мессенджерах и по почте. Где теперь искать то важное решение, которое повлияло на архитектуру?
Итог: документация устарела ещё до сдачи проекта. Знания «растворились» в чатах и письмах. Заказчик получил продукт - и всё. А когда пришло время что-то менять, оказалось, что менять-то некому, кроме тех, кто делал.
Решение: дать заказчику власть над знаниями
Мы предложили клиенту подход, который переворачивает традиционную схему.
Ключевая идея: документация - не приложение к проекту, а его неотъемлемая часть. Она развивается параллельно разработке. И заказчик владеет ею наравне с исполнителем.
Что это значит на практике:
Инструмент, который позволил это сделать - Gramax.
Почему выбрали именно его:
- Лаконичный интерфейс - не нужно учить команду неделями. Быстрое принятие изменений.
- Мультиплатформенность - работают и заказчик, и подрядчик, и тестировщики.
- Развитая поддержка и сообщество - не остаёшься один с проблемой.
- Встроенный ИИ - ускоряет поиск и анализ документации.
Что изменилось для заказчика
До внедрения
- Заказчик получал «коробку». А внутри - чёрный ящик.
- Изменения требований не фиксировались. Через месяц никто не помнил, почему приняли то или иное решение.
- Сменить подрядчика было невозможно без многомесячного «раскопа» в коде.
После внедрения
Главный результат для заказчика
Заказчик теперь не просто принимает работу. Он владеет знаниями о проекте.
На любой стадии реализации в его контуре находится:
- Бизнес-требования (Техническое задание) - что делаем и зачем
- Техническая документация - описание реализации, архитектуры, API
- Пользовательская документация - инструкции для конечных пользователей
Риски, которые мы закрыли:
- Срыв сроков - больше не сюрприз
- Несоблюдение требований - заказчик видит изменения в момент их внесения
- Невозможность развивать решение - документация позволяет любому подрядчику быстро войти в контекст
- Привязка к исполнителю - заказчик может уйти без потери экспертизы
Что в сухом остатке
Вместо заключения: почему это важно для вас
Если вы узнали свою ситуацию - когда после сдачи проекта остаётся только продукт, а не понимание того, как он устроен, - вы не одиноки.
Мы в «Фабрике Данных» проходим через это с каждым вторым клиентом, который приходит к нам после других подрядчиков. Их боль всегда одна: «Мы заплатили, а документации нет. Теперь мы привязаны к ним».
Именно поэтому во всех наших проектах мы начинаем не с кода, а с организации знаний. Грамотное управление проектом и юридически значимая документация - это база, на которой строится прозрачный процесс. А система контроля версий и живая документация - это инструменты, которые защищают заказчика от рисков долгосрочной поддержки.
Поэтому, если вам важно:
- Контролировать соблюдение бизнес-требований на всех этапах
- Иметь исчерпывающую документацию по проекту
- Не зависеть от текущего исполнителя
- Быть уверенным, что в случае смены подрядчика вы не потеряете экспертизу
…то вы знаете, к кому обратиться.
Мы не продаём документацию. Мы встраиваем управление знаниями в процесс разработки. И делаем это так, что заказчик всегда остаётся главным владельцем проекта, а не его заложником.
Вопрос к тем, кто узнал себя
Узнали свою боль? Когда проект сдали «под ключ», а через полгода выяснили, что ключ от другой двери?
Как сейчас защищаете свои интересы как заказчик? Доверяете подрядчику на слово или уже настаиваете на живой документации?