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