⭐️Первая очевидная вещь
Единственная выполняемая разработчиком функция: реализация требований заказчика в ПО.
Требования можно называть как угодно: бизнес-процессом, задачей, хотелкой, фичей, еще как.
Суть не меняется. Это требование к работе ПО, которое реализует разработчик.
⭐️Вторая очевидная вещь
Единственная выполняемая аналитиком функция: реализация требований заказчика в ПО.
Вопрос не в том, как правильно разграничить ответственность в рамках общей функции, а как эффективно использовать возможности.
⭐️Главная идея: степень взаимодействия должна зависеть от жизненного цикла, на котором находится продукт⭐️
Для задач разработки и развития – степень взаимодействия должна быть максимальной.
👉Привлечение разработчика к сбору и анализу требований позволит на ранних этапах
➡️сформулировать ограничения – накладываемые выбранным стеком разработки, ресурсами и конфликтами с существующими реализациями
➡️заложить точки вариации – по сути, начать работу с бэклогом уже на стадии проектирования системы.
👉Привлечение аналитика к разработке архитектуры позволит заложить у него понимание структуры и даст в дальнейшем возможность сократить участие разработчиков в проработке задач в других жизненных циклах проекта.
Подобный подход потребует двух сильных специалистов, но ведь на самом деле, никто не планирует разработку серьезной функциональности парой джунов, так?
Разграничивать ответственность на данном этапе максимально неэффективно – как минимум, это ведет к увеличению количества итераций «всё хуйня, переделывай», а как максимум – к ошибкам в проектировании.
Идеальным результатом такого взаимодействия, помимо работоспособного продукта, должна стать функциональная база знаний по данному продукту, которая позволит оперативно проводить онбординг в задачи для последующих стадий жизненного цикла.
В рамках сопровождения/поддержки задачи чаще носят изолированных характер. В таком случае, хорошая база знаний по продукту позволит
➡️использовать аналитиков средних и низких грейдов, в том числе для проектирования решения
➡️как следствие, использовать разработчиков средних и низких грейдов для реализации решения
Получается, что плотное и правильное взаимодействие сильных специалистов на ранних этапах жизни проекта приведет к логичному сценарию: специалисты уровнем ниже способны эффективно решать задачи, а не те же самые синьоры пытаются разобраться в том, что тут наделали до них, чтобы добавить какой-то элементарный функционал.
Помимо прочего, подобный подход с эффективным погружением в задачи позволяет не держать отдельную команду поддержки для решения задач в рамках каждого продукта, а выделять целых пул специалистов, которые могут оперативно обрабатывать инциденты в нескольких продуктах.
Пожалуй, главным узким местом подобного подхода являются конфликты – когда разработчик не согласен с решением, предложенным аналитиком. Без роли валидатора тут не обойтись и, главный вопрос – финансы.
👉Если они у Вас есть, наймите функционального архитектора, который будет обрабатывать задание ДО его поступления разработчику
👉Если денег нет – обозначьте ответственного за разрешение подобных конфликтов постфактум, поскольку конфликты возникают не для каждой задачи – валидация решений будет происходить реже, но при этом будет прозрачный путь решения спорных ситуаций.
#медведьразмышляет #рольаналитика