Когда мы разрабатываем или модернизируем вашу систему, одной из ключевых задач становится её описание, то есть разработка документации. Документация делает систему понятнее, удобнее, прозрачнее. Так её проще передавать другим командам или онбордить в неё новых людей. Мы подготовим для вас всю требуемую документацию с учетом ваших бизнес-задач — по вашим шаблонам или по шаблонам ГОСТ, единичный документ или полный комплект.
Мы не готовим документацию на систему, которую не разрабатывали или не модернизировали.
Перед началом проекта мы обсуждаем с вами какие задачи должна решать документация и каким требованиям она должна отвечать. Мы согласовываем параметры будущего комплекта документации, например, какие документы включить, как их оформить, каким нормам, шаблонам и формулировкам следовать (ГОСТ или вашим), какие функции, модули или подсистемы отразить.
Разработка руководства пользователя, написание руководства администратора и эксплуатационной документации для программных продуктов. Пишем понятно для конечного пользователя и точно для технического специалиста.
Продукт без документации — как прибор без инструкции. Пользователи либо не используют функции, либо используют неправильно. Служба поддержки отвечает на одни и те же вопросы по кругу. Новые сотрудники обучаются у коллег, а не по документу — и ошибки воспроизводятся.
Разработка эксплуатационной документации решает эти задачи системно. Хороший мануал сокращает нагрузку на поддержку, ускоряет онбординг и снижает количество пользовательских ошибок. Это измеримо.
Документация пишется для людей, а не для галочки. Если руководство написано так, что пользователь не может найти ответ на свой вопрос — оно не работает, независимо от объёма.
Документацию пишет технический писатель, который сначала сам работает с продуктом. Не по описанию от разработчика, а руками. Это единственный способ написать так, как пишет живой пользователь — с теми же вопросами и теми же затруднениями.
Разработка руководства пользователя строится вокруг задач, а не функций. Не «Кнопка Создать» — а «Как создать новый проект». Пользователю нужен результат, а не перечень элементов интерфейса. Структура документа отражает реальные сценарии работы.
Скриншоты — обязательная часть. Текст без иллюстраций работает хуже для интерфейсных продуктов. Мы делаем скриншоты из актуальной версии продукта, а не из макетов — чтобы соответствие было точным.
Написание руководства администратора требует другого подхода. Здесь читатель — технический специалист, который уже понимает базовые концепции. Документ нужен для точных инструкций: как настроить, как откатить, какие параметры влияют на что. Без лишних объяснений.
Формат финального документа согласовывается с заказчиком. Word, PDF, Confluence, Notion, встроенная справка в продукте — под каждый формат адаптируем структуру и навигацию. Для онлайн-документации важна поисковая доступность разделов, для PDF — логичное оглавление.
После написания — проверка с реальными пользователями. Даём документ тому, кто будет им пользоваться, и смотрим, находит ли он ответы на типовые вопросы. Правки по итогам тестирования входят в стоимость.
Разработка технической документации на программные продукты и информационные системы. Составление технической документации по ГОСТ 34, ГОСТ 19 и внутренним стандартам. Рабочая документация для госсектора, корпоративных заказчиков и команд разработки.
Написание технической документации — задача, которую откладывают до последнего. Продукт запущен, команда переключилась на следующий проект, а документации нет. Через год никто уже не помнит, почему принято то или иное архитектурное решение. Через два — новая команда тратит месяцы на разбор системы.
Для госзаказчиков и корпоративных клиентов техническая документация — условие приёмки. Без неё акт не подписывают, независимо от качества самой системы.
Разработка технической документации на старте, а не в конце — правило, которое экономит деньги. Писать доку параллельно с разработкой дешевле, чем восстанавливать её по факту запуска.
Техническая документация по ГОСТ — не просто заполнение шаблонов. Стандарты определяют структуру и состав, но не содержание. Качество документации определяется тем, насколько точно она описывает реальную систему.
Разработка технической документации начинается с инвентаризации: что уже есть, что нужно создать, какой стандарт применяется. Для государственных систем — ГОСТ 34. Для программных изделий — ГОСТ 19. Для систем с требованиями к информационной безопасности — добавляются профили защиты.
Рабочая документация ГОСТ 34 включает несколько десятков возможных документов. Не все нужны для каждого проекта. Мы согласовываем состав документации с заказчиком и проектируем минимально необходимый комплект, который закроет требования приёмки.
Составление технической документации ведём параллельно с разработкой, а не после неё. Технический писатель участвует в рабочих встречах, фиксирует принятые решения, задаёт вопросы разработчикам и архитекторам. Это позволяет документировать логику решений, а не только их результат.
API-документация — отдельное направление. Здесь стандарт — OpenAPI (Swagger). Описываем эндпоинты, параметры, форматы данных, коды ответов и примеры запросов. Документация генерируется автоматически из кода или пишется вручную — зависит от стека и требований к детализации.
По итогам работы заказчик получает комплект документов в согласованном формате — Word, PDF или интерактивная документация в Confluence. Для государственных контрактов — с подписями и штампами в соответствии с регламентом.
Составление технического задания на разработку ПО, веб-приложений и информационных систем. Написание ТЗ с фиксацией требований, пользовательских сценариев и ограничений. Результат — документ, по которому разработчики работают без лишних вопросов.
Разработка ТЗ — этап, который большинство заказчиков хочет пропустить. Логика понятна: кажется, что можно сразу перейти к разработке, а требования уточнять по ходу. На практике это приводит к тому, что проект стоит вдвое дороже плана, сдаётся с опозданием на несколько месяцев, а на выходе получается не то, что нужно.
Причина — разрыв между тем, что заказчик имеет в виду, и тем, что разработчик реализует. Без зафиксированных требований каждый трактует задачу по-своему. И каждый — по-своему прав.
Написание технического задания на разработку закрывает этот разрыв. Аналитик собирает требования от всех заинтересованных сторон, формализует их в однозначных формулировках и согласовывает с командой разработки до начала работы. Это сокращает количество итераций и делает оценку сроков предсказуемой.
ТЗ — не формальность для договора. Это рабочий инструмент команды разработки. Хорошо написанное техническое задание позволяет разработчику не задавать вопросы каждые два дня, тестировщику понять, что считать корректным поведением, а заказчику — принять работу по чётким критериям.
Составление технического задания начинается с серии интервью. Аналитик разговаривает с заказчиком, будущими пользователями системы, иногда с техническим директором. Задача — не записать пожелания, а выявить реальные потребности. Пожелание «сделайте удобнее» — не требование. Требование — «пользователь должен завершить оформление заказа за не более чем 3 шага».
После интервью — анализ и структурирование. Требования разбиваются на функциональные блоки, каждый блок описывается с точки зрения входных данных, логики обработки и ожидаемого результата. Для сложных сценариев — диаграммы последовательностей или BPMN-схемы.
Разработка технического задания на проектирование включает описание архитектурных ограничений. Какие интеграции нужны с существующими системами. Какой стек допустим. Какие требования по нагрузке и безопасности. Это не всегда очевидно заказчику, но критично для разработчиков.
Отдельный раздел — нефункциональные требования. Производительность: сколько пользователей должна выдерживать система одновременно. Надёжность: какой допустимый downtime. Безопасность: какие данные обрабатываются и какие требования к их защите. Без этих требований разработчики делают выбор самостоятельно — и не всегда тот, который нужен заказчику.
Написание ТЗ на разработку завершается согласованием с командой. Разработчики читают документ и задают вопросы — это нормально. Вопросы на этапе ТЗ стоят в разы дешевле, чем те же вопросы на этапе разработки. После согласования ТЗ становится приложением к договору.
Стоимость и сроки зависят от сложности проекта. Простое ТЗ для небольшого веб-приложения — 3-5 дней. ТЗ для корпоративной системы с несколькими модулями и интеграциями — 2-4 недели. Оценку даём после первого брифинга.
Тендерная документация и закупочная документация по ФЗ-44 и ФЗ-223 для IT-закупок. Готовим полный комплект документов для участия в государственных и корпоративных тендерах по информационным технологиям.
Тендерная документация для IT-закупок отличается от стандартных закупок оборудования или услуг. Техническое задание на разработку программного обеспечения по ФЗ-44 должно описывать требования к функционалу, архитектуре, интеграциям и производительности — и при этом соответствовать формальным требованиям закона о контрактной системе.
Закупочная документация по ФЗ-223 имеет больше гибкости в части требований, но свои особенности в процедурах. Корпоративные заказчики — крупные компании с государственным участием — устанавливают собственные регламенты, которые нужно знать и учитывать.
Ошибки в тендерной документации стоят дорого: отклонение заявки, штрафные санкции или оспаривание результатов. Мы готовим документы, которые проходят проверку.
ТЗ для IT-закупки — самый сложный документ в составе тендерной документации. Требования к программному обеспечению должны быть сформулированы так, чтобы любой квалифицированный подрядчик мог их однозначно интерпретировать. При этом требования не должны ограничивать конкуренцию — это прямое нарушение ФЗ-44.
Тендерная документация по IT проходит двойную проверку — на соответствие закупочному законодательству и на техническую корректность. Нередко эти требования противоречат друг другу: юридически корректная формулировка технически некорректна, и наоборот. Наша команда совмещает обе компетенции.
Обоснование начальной максимальной цены для IT-услуг — отдельная задача. Разработка программного обеспечения слабо поддаётся стандартным методам расчёта. Метод сопоставимых рыночных цен требует корректных аналогов. Метод нормативный и затратный — редко применимы. Мы готовим обоснование, которое выдержит проверку контрольных органов.
Закупочная документация по ФЗ-223 даёт больше свободы в части требований, но корпоративные регламенты крупных заказчиков могут быть жёстче федерального закона. Знание специфики конкретных корпораций — от РЖД до Газпрома — позволяет готовить документы, которые соответствуют внутренним стандартам с первого раза.
Типичная ошибка заказчиков — вписывать в ТЗ требования к конкретному продукту или производителю. Это прямое нарушение антимонопольного законодательства. Мы формулируем функциональные требования, которые обеспечивают нужный результат без указания конкретных брендов.