Наверное, первый вопрос, который у вас возник: почему именно Шерлок Холмс и доктор Ватсон? Первая причина — их двое, и они работают в тандеме, в идеальном взаимодействии. На протяжении всех книг эти герои дополняли друг друга — точно так же, как аналитик дополняет разработчика. Каждый выполняет свою роль и помогает другому. А вторая причина — это поиск правильных ответов, дедукция. Потому что мы, аналитики и разработчики, тоже занимаемся поиском решений, разбираем ошибки и отвечаем на вопросы пользователей.
Взгляд с обеих сторон баррикад
Меня зовут Холодова Екатерина, я ведущий системный аналитик 1С. Мой общий стаж в IT — целых 17 лет. 10 лет я работала программистом 1С, а потом резко переквалифицировалась в системные аналитики и уже 7 лет работаю в этой роли.
Я побывала по обе стороны баррикад — и как разработчик, и как аналитик. И именно этот опыт позволяет мне отвечать на вопросы о том, как выстроить правильное взаимодействие между ними.
Моего соавтора зовут Пашкевич Герман, он главный разработчик 1С. Его стаж в IT — больше 12 лет. Получив классическое математическое образование, он на четвертом курсе познакомился с 1С-программированием и с тех пор занимается разработкой на платформе 1С, ни разу не пожалев об этом.
Типичные конфликты
У каждого из нас бывают моменты, когда любимая работа начинает раздражать, и хочется все бросить. И дело не в сложности задач, не в коде, не в функционале, а во внешних факторах. Представьте ситуацию: вы, разработчик, погружены в важную задачу, и вдруг к вам обращается аналитик с вопросом о какой-то обработке, которую вы писали год назад в другом проекте.
Вы уже и не помните, что это было, а аналитик считает вопрос простым и ждет быстрого ответа. Или другой пример: у аналитика ошибка в проде, SLA всего час, и он начинает бомбардировать разработчика сообщениями, письмами, звонками.
Почему так происходит?
Для разработчика важно полностью погрузиться в задачу, обдумать решение, а звонки и сообщения сбивают концентрацию. Переключение между задачами требует времени, и чем чаще это происходит, тем больше продуктивности теряется.
Один из американских институтов, изучающих многозадачность, провел исследования и выяснил: частое переключение между задачами отнимает до 40% рабочего времени и увеличивает количество ошибок. Кроме того, попытки делать несколько дел одновременно приводят к снижению мотивации, усталости, прокрастинации и даже выгоранию.
А вот для аналитика многозадачность — это норма. Он постоянно на встречах, общается с заказчиками, переключается между чатами, письмами и вопросами к разработчикам. Еще одна его роль — быть посредником между заказчиком и разработчиком. Он фильтрует запросы, но остаются 5–10% вопросов, которые без разработчика не решить.
Еще аналитики часто знают проект лучше, потому что взаимодействуют с заказчиком напрямую и видят картину целиком. А разработчик может быть подключен точечно и не понимать всех нюансов. Поэтому важно, чтобы аналитик и разработчик общались — иначе могут приниматься неверные архитектурные решения.
Но как же общаться так, чтобы разработчик не начал вас ненавидеть?
Мы хотим поделиться подходом, который помог нам наладить комфортный микроклимат в команде. Но сначала расскажем, что у нас не сработало.
Авторитаризм и копирование чужих методов не работают
Авторитарные решения. Казалось бы, все просто: руководитель устанавливает правила — например, аналитики пишут разработчику раз в три часа, а он отвечает в определенное время. Но на практике сам руководитель может нарушить эти правила в экстренном случае, и все возвращается на круги своя.
Копирование чужих методик. Мы пытались применять готовые решения, но не учитывали специфику нашей команды. У нас высоконагруженная система обработки документов, к нам в день поступает более 200 000 документов на проверку, и SLA у нас занимает не больше одного часа. А мы пытались перенять опыт у коллег, у которых SLA — более трех дней.
Наш подход: анализ проблем и поиск решений
В итоге мы не стали копировать чужой опыт, а разработали свой подход. Мы использовали диаграмму Исикавы, также известную как «рыбья кость». Ее суть в том, что в «голове» обозначается основная проблема, а на «ребрах» фиксируются факторы, которые к ней приводят.
Перед началом работы с диаграммой важно четко сформулировать ключевую проблему. В нашем случае такой проблемой стало недопонимание между аналитиками и разработчиками. В идеале проблема должна быть измеримой, но на тот момент у нас не было данных о снижении продуктивности. То есть мы начали решать проблему превентивно, до появления явных негативных последствий.
Далее мы применили классическую схему 6M, которая включает шесть основных факторов возникновения проблемы:
-
Люди — все участники команды, заказчики и сотрудники смежных подразделений.
-
Оборудование — тестовые стенды, доступы, установка новых платформ (например, новой версии EDT) и другие технические аспекты.
-
Измерения — метрики, особенно в тех областях, где их не хватает.
-
Материалы — документация, база знаний.
-
Методы — методологии и бизнес-процессы компании.
-
Окружающая среда — внешние факторы, неформальные процессы или исторические инструменты, которые нигде не задокументированы (например, когда решение зависит от конкретного человека, работавшего с ними в прошлом).
Это лишь один из вариантов построения диаграммы. Вы можете адаптировать ее под свою команду, выбирая другие факторы. Однако важно помнить: если «ребер» будет больше восьми, работать с диаграммой станет сложно.
После выбора структуры диаграммы нужно перейти к заполнению «косточек» — конкретных причин проблемы (в нашем случае — недопонимания).
Как известно, команды состоят из людей с разными характерами:
-
Молчуны редко высказываются, предпочитают оставаться в тени.
-
Лидеры активно продвигают свои идеи, но не всегда учитывают мнение остальных.
-
Середнячки колеблются между молчунами и лидерами.
Чтобы вовлечь всех, мы дали домашнее задание: подумать над факторами недопонимания. Затем провели совещание с использованием доски Miro, на которой участники анонимно размещали свои идеи на стикерах. Это позволило услышать даже молчунов.
Следующий шаг — группировка стикеров по смыслу. Например, «Мелкие вопросы» и «Отвлекающие вопросы» объединялись в одну категорию.
Количество стикеров в группе показывало, насколько проблема актуальна для команды. Если в группе был всего один стикер, значит, проблема волновала только одного участника.
У нас самыми раздражающими факторами оказались:
-
Мелкие вопросы
-
Срочные вопросы
-
Старая задача
-
Оценка сроков по задаче
-
Подключение на встречи
-
Нежелание читать документацию
-
Непроверенные ошибки
Когда вы проводите такую работу, команда должна быть в полном составе и проговаривать вслух каждый этап. По сути, это своего рода сеанс групповой психотерапии. Когда человек озвучивает свои мысли, он делится переживаниями — и это снижает напряжение в команде. Вы же не просто так начали этот процесс: если есть проблема, ее нужно обсудить открыто.
Есть и другая психологическая причина — сопричастность. Человек гораздо лучше воспринимает идеи, в создании которых он сам участвовал. Если он чувствует свою вовлеченность в процесс, то и решение (даже сложное) примет легче, и выполнять его будет охотнее.
Мы уже говорили, что авторитарные решения не работают. Но если решение принято совместно, если ты сам его поддержал — ты будешь выполнять его гораздо активнее.
Итак, у вас есть список причин проблемы. Следующий шаг — разобрать каждую из этих причин и найти способы их устранить.
Мы выработали следующие решения:
-
Привести в порядок документацию, чтобы меньше вопросов требовало вмешательства разработчика.
-
Ввести ежедневные встречи в 10:30 — время, когда мозг наиболее продуктивен. Разработчики приходят подготовленными и отвечают на вопросы без стресса.
-
Настроить четкие маршруты для заказчиков, чтобы они не шли напрямую к аналитикам или разработчикам.
-
Определить критерии срочности задач, чтобы исключить хаотичные запросы.
И знаете что? Небо не рухнуло. Когда мы перестали постоянно дергать разработчиков, ничего страшного не случилось. Задачи не перестали решаться, но работать стало комфортнее.
У команды появились ресурсы. Снизилось ощущение паники и стресса. Благодаря ежедневным встречам разработчики заранее знают возможные вопросы и успевают изучить код и документацию. У них появилось больше времени на рефакторинг, поскольку стало меньше неожиданных прерываний. Они могут фокусироваться на таких задачах, как оптимизация запросов и улучшение кода.
Думаем, что нам удалось создать здоровый микроклимат в команде и выстроить идеальное взаимодействие между разработчиками и аналитиками.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
