Базовые знания кода дают аналитику огромный буст: в скорости выполнения задач, взаимоотношении с коллегами, пользе для клиента. Например, становится легче оценивать выполнимость «хотелок» клиентов и сразу озвучивать риски. За два года работы на проектах внедрения, я получила большой опыт общения с инженерами и разработчиками. Стала понимать, что существуют тяжелые для системы действия:  реализация сложной зависимости или большие сценарии, где необходимо сделать много параллельных шагов. 

Однако иногда можно «заиграться» и начать выполнять работу за разработчика. Я сталкивалась с ситуациями, когда дискоммуникация с коллегами могла привести не только к неудачному результату, но и к негативным последствиям для бизнеса. Так что еще раз подтвердила для себя, что аналитиков не зря называют «связующим звеном». Ведь грамотная коммуникация, в том числе при разделении задач, необходима для эффективной работы.

Вика Анисимова

 Системный аналитик Naumen Service Management Platform

В статье делюсь тремя кейсами, где знания кода и отсутствие очерченных границ работы принесли больше вреда, чем пользы, и рассказываю, как это исправила. Надеюсь, мои примеры помогут найти баланс и очертить границы зон ответственности между разработкой и аналитикой.

Кейс 1. Про главенство своих задач

На одном проекте у клиента было множество интеграций с внешней системой. Мне нужно было доработать существующие методы и написать пару новых. Когда мне дали эту задачу, то посоветовали сходить к другому аналитику команды, чтобы узнать подробности.

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

Проблема: Как выяснилось после — в данном кейсе это была задача для разработчиков :) Но так как методы я уже реализовала, разработчиков попросила сделать только код ревью. Он прошел успешно, я завершила задачу. Да, был получен хороший опыт написания интеграционных методов, но мне пришлось пожертвовать временем и в моменте брать меньше профильных задач.

Решение: Теперь в подобных ситуациях я поступаю так: всегда уточняю, что требуется от меня перед тем, как начать выполнять задачу. Все интеграции отдаю на разработку. Это помогает мне освободить время под другие задачи, сфокусироваться на создании моделей решения и не перерабатывать. Погружаться в новые сферы круто, но делать это нужно с умом, не влезая в задачи других специалистов. 

Кейс 2. Про скорость работы

Недавно был случай, когда от другого аналитика внедрения пришел запрос для разработчика — можем ли мы сбросить пароль сотрудника при входе в систему по ссылке. Разработчик сразу же начал предлагать варианты, не разобравшись зачем это нужно и почему есть такая потребность. 

Проблема: Автору запроса ни один из вариантов не подходил, а ситуация уже начала перерастать в конфликт. Тогда разработчик предложил подключить меня, так как я владею экспертизой по платформе. Я прочитала запрос и не поняла, зачем клиенту надо сбрасывать пароль пользователя при входе в систему. Пообщавшись с автором запроса, выяснила, что пароль нужно сбросить только при первом входе. Варианты разработчика действительно никак не покрывали этот кейс, так как он пытался решить вопрос «как сбрасывать пароль при каждом входе». 

Решение: Первое — уточнять все вводные по задаче на старте. Второе — предлагать решения, когда ясна цель клиента. В этой ситуации разработчик потратил время впустую. Здесь была важна именно экспертиза аналитика для того, чтобы предложить оптимальное решение. 

Кейс 3. Про понимание друг друга

Около месяца назад меня попросили завершить починку неверно работающего функционала — раньше этим занимался другой аналитик. По его словам, осталось только написать текст для пользовательской ошибки и передать в разработку. Оказалось, чтобы починить то, что не работает, придется забрать у пользователя часть рабочего функционала. Мне показалось это решение не логичным и я пошла общаться с разработчиком. Меня заранее предупредили, что разговор может быть сложным. Диалог действительно пошел тяжело — переделывать решение всегда неприятно, поэтому разработчик ожидаемо отстаивал реализованное решение. 

Конфликт: Разработчик не чувствует экспертизы от аналитика, поскольку не видит ценности в новом решении: «если предыдущий аналитик утвердил решение, то зачем что-то менять? Мне нужно получить только текст пользовательской ошибки и завершить задачу».

Решение: Чтобы аналитику и разработчику понять друг друга, важно помнить, что у вас одна цель — принести пользу клиенту. А еще полезно быть базово погруженным в деятельность коллеги.

В этой ситуации взяла на себя роль валидатора. Так как у меня есть базовое понимание кода, предложила разработчику совместно обсудить риски текущего решения и как их можно минимизировать в новом. После моих аргументов у коллеги появилось доверие к моей экспертизе и мы реализовали нужный функционал. 

Круто базово знать код: уметь его читать и написать простой скрипт. Так как сможете говорить с разработчиком на одном языке, эффективнее закрывать задачи и находить более удобные решения для клиента. Но, как показал мой опыт, знание кода иногда вредит — в случае когда нет четкого разделения задач. Есть риск стать «человек-оркестром» — тем, кто забирает на себя часть задач и стирает границы зон ответственности между аналитикой и разработкой. От этого может пострадать не только качество результата, но и коммуникации.

Развиваться в смежных направлениях полезно, но это должно быть в меру. Расширяйте возможности, но не распыляйтесь: не спекулируйте на знании всего и вся и не нарушайте рабочих границ, даже если кажется, что сможешь сделать задачу сам.