Техническое задание на разработку в Актау

Обсуждение и показы идут по видеосвязи, переписка в мессенджерах, задачи и правки ведём в общем списке - видно, что сделано и что в работе.

Оценку даём до старта и разбиваем проект на этапы: после каждого можно остановиться или изменить план, а не платить за всё авансом.

Договор по законодательству Казахстана, оплата по безналичному расчёту или через Kaspi, акты и счета-фактуры электронные.

Техническое задание для Актау почти всегда упирается в две вещи: связь и адреса. Сотрудники на месторождениях Мангистау работают вахтой, интернет там нестабилен, поэтому в ТЗ нужно прямо описать поведение системы без сети: что сохраняется локально, что синхронизируется потом, как разрешается конфликт данных при одновременном изменении. Если этого пункта нет, разработчик сделает онлайн-версию, и на объекте она окажется бесполезной. Спорить об этом после сдачи бессмысленно и дорого. Мы описываем это на встрече с людьми с объекта, а не только с руководителем.

Второе, адресация. В Актау вместо улиц микрорайоны и номера домов, и стандартная форма адреса с полем «улица» ломается на первом же заказе. В задании фиксируем формат ввода, маску и то, как адрес попадает в маршрутный лист курьера. Отдельно описываем логистику: порт Актау и Курык, паромы в Баку, железная дорога в Иран и Туркменистан дают длинные сроки поставки, и статусы заказа должны отражать реальный путь груза, а не абстрактные «в обработке» и «доставлено».

Хорошее ТЗ описывает и то, чего в проекте не будет. Это защищает обе стороны от бесконечного расширения задач. Мы также закладываем в документ сценарии проверки: как именно заказчик убедится, что пункт выполнен. Готовое задание вы можете отдать любому исполнителю, привязки к нам в нём нет, и это нормально. Стоимость подготовки зависит от количества ролей и сценариев, а не от объёма страниц в документе.

Процессы: как задача решается сейчас и как должна решаться в программе.

Роли и права: кто работает в системе и что каждому доступно.

Функции и экраны: перечень возможностей с описанием ключевых сценариев.

Интеграции: с какими системами и в каком направлении идёт обмен данными.

Смета и этапы: сколько стоит, из чего складывается и в каком порядке делается.

Понятно каждому по-своему, в этом и проблема: заказчик имел в виду одно, разработчик услышал другое.

ТЗ фиксирует не только что будет, но и чего не будет. Второе не менее важно для сметы.

Когда объём описан, любое добавление становится видимым решением, а не спором задним числом.