Как выделить модуль для подрядчика и сохранить управление основным проектом
Подготовлено
Передавайте подрядчику законченное действие с проверяемым входом и выходом. Решения о продукте, исходные данные и управление основной системой оставляйте у ответственного со стороны партнёра. Если такую границу пока нельзя показать, сначала уточните её, а не оценивайте «модуль вообще».
Разработка отдельного модуля на заказ начинается с вопроса: какой результат можно принять независимо от остальных работ? Название технологии на него не отвечает. Полезнее короткая карточка: что запускает действие, какие данные нужны, какой результат возвращается, кто проверяет его и что остаётся за пределами заказа.
Сначала назовите одно законченное действие
Рассмотрим учебный пример. У партнёра есть сайт с формой обращения и рабочая система, в которой сотрудники разбирают заявки. Нужно подготовить отдельный адаптер: он принимает согласованный набор сведений с сайта, передаёт его в рабочую систему и возвращает результат передачи. Сайт целиком и система учёта клиентов в заказ не входят.
Фраза «сделать интеграцию сайта» оставляет слишком много вариантов. Под ней могут понимать новую форму, перенос всей базы, настройку уведомлений или изменение работы менеджеров. Вместо неё запишите действие: «Передать одну проверенную заявку из формы в рабочую систему и показать результат передачи». Так проще обсудить состав, зависимости и приёмку.
Уточните, где действие заканчивается. Получение данных адаптером ещё не означает, что заявка принята рабочей системой. При этом дальнейший звонок менеджера уже может быть другим процессом. Эти две границы нужно согласовать до оценки.
Если требуется передать не новый ограниченный участок, а весь действующий продукт вместе с поддержкой и накопленной историей, это другой объём. Его полезно рассматривать отдельно — как передачу проекта на сопровождение.
Отделите результат модуля от результата всего проекта
Форма и согласованные данные
Передача и результат операции
Приём заявки и работа сотрудников
Подрядчик отвечает за согласованный участок. У каждого соседнего участка остаётся свой владелец.
В примере результат модуля — передача заявки по согласованным правилам и понятный ответ о её исходе. Результат всего проекта может быть шире: сотрудники видят заявки, назначают ответственных и связываются с клиентами. Эти действия нельзя автоматически включать в ответственность автора адаптера.
| Участок | Что нужно определить | Кто принимает решение в примере |
|---|---|---|
| Форма сайта | Какие сведения собираются и когда они готовы к передаче | Партнёр и ответственный за сайт |
| Адаптер | Как принять согласованные данные, передать их и вернуть результат | Исполнитель модуля; результат принимает назначенный специалист партнёра |
| Рабочая система | Как заявка принимается, проверяется и становится доступной сотруднику | Владелец рабочей системы |
| Общий путь | Как совместно проверить действие от формы до принятой заявки | Назначенный координатор со стороны партнёра вместе с владельцами участков |
| Эксплуатация | Кто получает сообщения об ошибках и что делает после выпуска | Ответственный за сопровождение по отдельной договорённости |
Название роли само по себе не создаёт договорённость. Укажите конкретного принимающего и владельцев соседних частей. Если ответственность ещё не согласована, это открытый вопрос, а не молчаливое обязательство подрядчика.
Опишите границу данными и событиями
Границы программного модуля удобнее обсуждать на одном примере сообщения. В учебной заявке достаточно условных сведений без реальных контактов клиента. Важно понять состав и смысл полей, а не передать настоящую базу.
| Поле карточки | Заполненный учебный образец |
|---|---|
| Действие пользователя | Оставить обращение на сайте и узнать результат его передачи |
| Событие начала | Форма завершила предусмотренную проверку и передала данные адаптеру |
| Вход | Условный номер обращения, тема и согласованный набор сведений для связи; точные поля определяются владельцами систем |
| Выход | Подтверждение приёма рабочей системой с её номером заявки либо понятный известный исход ошибки |
| Владелец данных | Партнёр определяет допустимый состав и условия использования данных |
| Ошибка или неизвестный исход | Описаны различия между отказом в приёме, недоступностью и отсутствием подтверждения; повтор не объявляется безопасным без согласованного порядка |
| Исключения | Новый дизайн сайта, перенос прежней базы, изменение внутренних правил рабочей системы и работа менеджеров |
| Принимающий | Назначенный технический специалист партнёра, который может проверить вход и результат |
Событие начала и подтверждение окончания особенно важны. Например, ответ «получено» может означать только получение сообщения адаптером. Участники должны одинаково понимать, какое подтверждение свидетельствует о приёме заявки целевой системой.
Технический способ передачи выбирают после проверки возможностей обеих систем. Карточка границ не доказывает наличие готового интерфейса, разрешённых доступов или свободного исполнителя. Если нужный вход пока недоступен, запишите, кто должен его предоставить и что после этого можно проверить.
Назовите то, что остаётся у партнёра
Чтобы передать модуль подрядчику и сохранить управление проектом, партнёру нужно оставить за собой продуктовые решения и координацию стыков. Исполнитель не должен угадывать, какие заявки принимать, кому разрешён доступ и кто может менять соседнюю систему.
- Правила продукта. Партнёр определяет, какие обращения обрабатываются и какой результат нужен пользователю.
- Интерфейсы соседних систем. Их владельцы подтверждают возможности, согласованный формат и порядок изменения.
- Допустимые доступы. Права выдаются на нужный участок поддержанным способом; пароль в общей переписке не заменяет согласование доступа.
- Приёмка. Партнёр назначает специалиста, который проверит результат на согласованных примерах.
- Общий выпуск и сопровождение. Установка в основной продукт, наблюдение после выпуска и дальнейшая поддержка имеют своих ответственных и входят в заказ только при явном согласовании.
Если владелец целевой системы ещё не выбран или он не может подтвердить формат, отметьте зависимость прямо. Например: «Для завершения передачи нужен согласованный способ приёма заявки от команды рабочей системы». Это точнее, чем обещание закончить обмен независимо от чужого участка.
Проверьте, действительно ли участок отделим
Перед оценкой задайте три контрольных вопроса. Ответы должны опираться на конкретные материалы, а не только на общее согласие участников.
- Можно ли отдельно показать вход? Есть описание данных и обезличенный пример того, что получает модуль. Понятно, кто подтверждает их смысл и допустимость.
- Можно ли проверить выход? Описан наблюдаемый результат и условие завершения. Принимающий специалист различает успешный приём, известную ошибку и неизвестный исход.
- Можно ли назвать владельца каждого стыка? Известно, кто отвечает за источник, целевую систему, модуль и согласование изменений.
Если на один из вопросов нет ответа, сначала заполните этот пробел. Возможно, достаточно описать формат или назначить принимающего. В другом случае окажется, что выбранный участок слишком тесно связан с основной системой и его границу нужно пересмотреть. Это основание уточнить заказ, а не автоматически расширить его до всего проекта.
Для обсуждения можно скопировать пустую карточку и заполнить её своими данными:
Действие пользователя: Где действие начинается: Входные данные и их пример: Наблюдаемый результат: Что означает успешное завершение: Известные ошибки и неизвестный исход: Владелец исходных данных: Владелец принимающей системы: Что входит в работу над модулем: Что остаётся вне заказа: Кто проверяет результат: Какого входа ещё не хватает и кто его предоставляет:
В карточке допустимы незаполненные пункты, если они названы открытыми вопросами. Не заменяйте отсутствие ответа выдуманным форматом, сроком или ответственным.
Что обсудить до оценки
Для первого разговора полезны одно законченное действие, пример входа, ожидаемый выход и список границ. По ним можно проверить, подходит ли отдельный модуль для вашей ситуации и какие вводные ещё потребуются. Обсуждение соответствующего участка системы не означает автоматическую передачу всего проекта другому исполнителю.
В АИС Сокол предложение по отдельному модулю включает согласование кода, интерфейсов, контрольных примеров и технической приёмки. Объём и возможность выполнения сначала оцениваются. УТП «До результата — без доплат за наши ошибки.» относится к согласованной задаче; изменённые требования оцениваются отдельно.
Если такой участок есть в вашем проекте, опишите одно действие и нужный результат. Первый разговор бесплатный; готовое ТЗ не обязательно.