Составление технического задания
в Самаре

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

Зависит от команды. Поставляем структурированные документы, диаграммы и API-схемы в Figma, Notion, Markdown — или в удобном для вас формате.

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

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

Роли сотрудников, справочники, документы и отчёты. Отчёты описывают вместе с данными, из которых их считают.

С процесса: что происходит сейчас и где теряется время. Автоматизация беспорядка усиливает беспорядок.

Нужны ключевые. Остальные добавляют после того, как система наполнится данными.

Составом полей и правилами ведения: кто заводит запись и кто её правит.

Нужно: сотрудник видит свой участок. Общий доступ ко всему приводит к ошибкам.

Описываем их отдельно: список, фильтр, действие и подтверждение.

Нужно: формат файла, проверки и поведение при ошибках в строках.

Описываем, какие объекты хранят историю. Хранить всё подряд дорого и неудобно.

Нужно: события и получатели. Лишние уведомления отключают в первую неделю.

Состав инструкций закладывают в документ как результат работ.

Нужно, если учёт вёлся в таблицах: правила разбора и сверка итогов.

Можно: первый участок показывает, как пойдёт остальное.

От нескольких недель. Число ролей и документов задаёт объём.

Документ, схему данных, таблицу ролей и перечень отчётов.

Нужно, если внутри есть маршруты: кто и в каком порядке утверждает.

Списком шагов с ролями и сроками. Маршрут, зашитый в код, устаревает через полгода.

Описываем возврат автору с причиной и повторный запуск.

Нужно: кто согласует в отпуске. Без этого маршрут встаёт.

Задаём срок на шаг и правило напоминания.

Нужно, если оно есть: кто согласует одновременно и что считается решением.

Описываем, что происходит при правке после части согласований.

Нужно: кто, когда и с каким решением. При споре это единственный след.

Описываем способ: отметка в системе или электронная подпись.

Нужно, если документ выходит за пределы системы.

От нескольких дней. Число типов документов задаёт объём.

Нужно: подразделения, должности и подчинённость задают права и маршруты.

Из кадровой системы обменом или ведётся в системе. Ручное ведение в двух местах расходится.

Нужно: сотрудник может работать за двоих. Это влияет на доступ и маршруты.

Описываем порядок: перевод сотрудника меняет права и открытые задачи.

Нужно: прежние должности и подразделения. Отчёты за прошлые периоды считаются по ним.

Описываем отзыв доступа и передачу открытых задач.

Нужно, если подрядчики работают в системе: ограниченные права и срок доступа.

Через связь подразделения с руководителем. Жёсткий список имён устаревает за месяц.

Нужно, если от них зависят сроки задач.

Описываем правило принадлежности сотрудников и документов.

Нужно: это самый частый сценарий на внутреннем портале.

От нескольких дней. Согласование с кадровой службой занимает дольше.

Описание справочника, правил обмена с кадровой системой и порядка изменения прав.

Нужно: по каким объектам ищем и что показываем в результатах.

Людей, документы и заявки. Эти три сценария закрывают большую часть обращений.

Нужно по типу объекта и дате. Общий список читают плохо.

Описываем правило: в выдачу попадает только доступное пользователю.

Нужно, если документы текстовые. Сканы без распознавания поиск не видит.

Описываем подсказки и переход к разделам. Пустая страница заводит в тупик.

Нужно числом при заданном объёме данных.

От нескольких дней вместе с индексом.