Аналитик VS разработчик | Как делить задачи без конфликтов
Базовые знания кода дают аналитику огромный буст: в скорости выполнения задач, взаимоотношении с коллегами, пользе для клиента. Однако иногда можно «заиграться» и начать выполнять работу за разработчика.Делимся тремя кейсами, где знания кода и отсутствие очерченных границ работы принесли больше вреда, чем пользы, и рассказываем, как это исправить. Надеемся, примеры помогут найти баланс и очертить границы зон ответственности между разработкой и аналитикой.
Про главенство своих задач
На одном проекте у клиента было множество интеграций с внешней системой. Мне нужно было доработать существующие методы и написать пару новых. Когда мне дали эту задачу, то посоветовали сходить к другому аналитику команды, чтобы узнать подробности.Аналитик поделился, что методы, которые уже реализованы, можно взять за пример и переписать под свои задачи. Он объяснил, что это можно сделать самостоятельно. Я изучила все, что уже есть, и реализовала нужные методы.
Проблема: как выяснилось после — в данном кейсе это была задача для разработчиков :) Да, был получен хороший опыт написания интеграционных методов, но мне пришлось пожертвовать временем и в моменте брать меньше профильных задач.
Решение: теперь в подобных ситуациях я поступаю так: всегда уточняю, что требуется от меня перед тем, как начать выполнять задачу. Все интеграции отдаю на разработку. Это помогает мне освободить время под другие задачи, сфокусироваться на создании моделей решения и не перерабатывать. Погружаться в новые сферы круто, но делать это нужно с умом, не влезая в задачи других специалистов.
Про скорость работы
Был случай, когда от другого аналитика внедрения пришел запрос для разработчика — можем ли мы сбросить пароль сотрудника при входе в систему по ссылке. Разработчик сразу же начал предлагать варианты, не разобравшись зачем это нужно и почему есть такая потребность.Проблема: автору запроса ни один из вариантов не подходил, а ситуация уже начала перерастать в конфликт.
Тогда разработчик предложил подключить меня, так как я владею экспертизой по платформе. Я прочитала запрос и не поняла, зачем клиенту надо сбрасывать пароль пользователя при входе в систему. Пообщавшись с автором запроса, выяснила, что пароль нужно сбросить только при первом входе. Варианты разработчика действительно никак не покрывали этот кейс, так как он пытался решить вопрос «как сбрасывать пароль при каждом входе».
Решение: первое — уточнять все вводные по задаче на старте. Второе — предлагать решения, когда ясна цель клиента. В этой ситуации разработчик потратил время впустую. Здесь была важна именно экспертиза аналитика для того, чтобы предложить оптимальное решение.
Про понимание друг друга
Меня попросили завершить починку неверно работающего функционала — раньше этим занимался другой аналитик. По его словам, осталось написать текст для пользовательской ошибки и передать в разработку. Оказалось, чтобы починить то, что не работает, придется забрать у пользователя часть функционала. Мне показалось это решение не логичным и я пошла общаться с разработчиком.Диалог пошел тяжело — переделывать решение всегда неприятно, поэтому разработчик ожидаемо отстаивал реализованное решение.
Проблема: разработчик не чувствует экспертизы от аналитика, поскольку не видит ценности в новом решении: «если предыдущий аналитик утвердил решение, то зачем что‑то менять? Мне нужно получить только текст пользовательской ошибки и завершить задачу».
Решение: чтобы аналитику и разработчику понять друг друга, важно помнить, что у вас одна цель — принести пользу клиенту. В этой ситуации взяла на себя роль валидатора. Предложила разработчику совместно обсудить риски текущего решения и как их можно минимизировать в новом. После моих аргументов у коллеги появилось доверие к моей экспертизе и мы реализовали нужный функционал.
