Hello World!
Меня зовут Сергей Павлов, я тимлид по системной аналитике в банке "Открытие” на продукте МСБ “Бизнес-Портал”. Хочу рассказать, как я решал задачи по управлению командой, когда к ней присоединился.
Скажу сразу: тут я не буду описывать графики, капасити, велосити и любые инструменты, связанные с командными метриками. Речь пойдет именно об организации процессов для повышения качества взаимодействия при коллективной работе.
Итак, морозное утро, вежливый голос руководителя мне говорит: “Это команда системных аналитиков, начинай творить добро”. Я смог выдавить только “угу” и сел думать насчет того самого творить и того самого добра.
![… несколько часов четверти суток полу недели спустя … … несколько часов четверти суток полу недели спустя …](https://habrastorage.org/getpro/habr/upload_files/d77/487/1ac/d774871acc21025e17df4256037a12de.png)
Я познакомился с командой (12 системных аналитиков разного уровня от Junior до Senior) и погрузился во внутренние процессы по работе над проектом (матричная структура разделения ресурсов на 14 групп, работа по Scrum).
Обозначил себе ряд острых проблем по направлениям:
Профессиональное развитие системных аналитиков
Единый подход к работе
Онбординг новых сотрудников
Текучка кадров
Экспертная взаимозаменяемость
Менторство Junior специалистов
Проблем достаточно, надо решать. Давайте разберемся вместе, как это было.
Решение
Сейчас всё порешаем, где наша не пропадала!
Демотивацию команды решаем мемчиками и бугагашеньками в чатиках (будет весело);
Отсутствие общей картины развития решаем ссылкой на roadmap;
Не успел погрузиться в процессы за время испытательного срока - ну и скатертью дорожка, “следующий, заходите!”;
Блокировка работы команды в случае отсутствия системного аналитика - тут еще проще. Это проблема продактов, просто ставим в известность сотрудников со стороны бизнеса, что пока процессы переводим на паузу. Как будет системный аналитик, сразу дам вам знать. И разработку можно будет продолжить.
Улыбнулся, выдохнул. Проблема решена!
Нет! Нет и еще раз НЕТ! Конечно же, это не выход из положения и так ни в коем случае делать нельзя.
Как говорила моя бабуленька, когда водила меня в детсад: “Думать надо продуктом!” Т.е. надо понимать, как твои текущие действия помогут в текущей ситуации и какой эффект они дадут в будущем.
Отказываемся от мысли “это их проблема” и вернемся на шаг назад, на тот этап, когда я только составил список проблем и задач.
К сожалению, одной статьи не хватит, чтобы описать все изменения. Но, думаю, смогу уместить в рассказ некоторые из важных нововведений, которые помогли нам вывести системный анализ на новый уровень:
Внедрение ревью в два этапа;
Проработанный процесс онбординга и оффбординга;
Создание “Тайного клуба аналитики”.
Ревью 2х
![](https://habrastorage.org/getpro/habr/upload_files/5f6/0a2/ed6/5f60a2ed62fe332c4b2b7e30dd2ed6e7.png)
Итак, над проектом в тот момент работало 14 групп - это были отдельные миры со своим набором устоявшихся правил. Внезапно из проблемы я решил попробовать сделать профит.
Ревью №1: локальное ревью
Вводим к каждой задаче в обязательном порядке наличие небольшой таблички:
![](https://habrastorage.org/getpro/habr/upload_files/09e/872/094/09e872094944b417d8ba1813ad579bda.png)
Эту табличку заполняет исключительно тот системный аналитик, который работает над конкретной задачей. Его цель получить от разработчиков back и front подтверждение, что задача понятна и вопросов по разработке нет. А когда вопросов нет, значит можно отдавать “в разработку”.
А вот и получен первый профит: системному аналитику можно работать на опережение, не дожидаясь реализации текущих задач.
В организации процесса тестирования похожая ситуация: только происходит согласование, что и как нужно будет проверить, и понятны ли тест-кейсы. Ставим галочку, двигаемся дальше ко второму этапу ревью.
Well Done Bro
Ревью №2: кросс-ревью
К таблице “Review Аналитики” добавляем еще одну строчку:
![](https://habrastorage.org/getpro/habr/upload_files/760/82d/00d/76082d00de1a7bfd778ef26b0e172af5.png)
И тут самое интересное. К задаче приходит системный аналитик из другой команды. Чтобы поставить в этой строчке Done проверяющий аналитик должен:
Понять, о чем эта задача;
Понять, что будет сделано;
Все ли в ТЗ присутствует (маппинги, таблицы, контракты, и т.д.).
Отсюда мы получаем сразу несколько профитов:
Системный аналитик косвенно погружается в процессы соседней команды, знакомится с ее функционалом;
Документация по проекту более структурированная, понятная и наполненная;
Обмен так называемыми “Best Practices”, когда во время кросс-ревью ты замечаешь детали, которые тебе показались оптимальнее предложенных тобой. И в следующий раз ты сделаешь именно так, т.е. лучше.
Онбординг и оффбординг
Разберем проблему текучки системных аналитиков.
Двухнедельный онбординг - звучит как челлендж, но схема продуманная, проработанная и хорошо работающая на практике.
“Го онбордится, я создал!”
Я проработал детально онбординг и запустил его в совершенно новом формате - в форме игры, где тебе предстоит преодолеть 4 локации, а в каждой локации есть свои уровни.
Локации - это сгруппированные рабочие дни: день 1-3, день 4-6, день 7-8, день 9-10.
Уровни - набор указаний, которые необходимо выполнить (важно понимать, что от локации к локации они становятся сложнее. Как и в игре очень легкое начало, а в конце ты уже чувствуешь себя профессионалом и все делаешь с закрытыми глазами).
К каждому указанию прикладывается подробная инструкция, как действовать. Тем самым мы не бросаем нового человека в колодец с кучей документации, а последовательно погружаем его в процессы, архитектуру и нюансы работы в команде.
Оффбординг. Я сейчас не хочу описывать избитый процесс сбора фидбека о работе на последнем “one to one”, он и так есть, это естественно. Вместо этого хочу поделиться интересной практикой.
До своего последнего рабочего дня системному аналитику нужно оставить две подробные видео-инструкции, где:
Аналитик рассказывает о нюансах при работе с confluence и tfs именно в его команде. Как и что именно он обычно делал и описывал. Как и куда ходили задачки, как и с кем они согласовывались. Если вкратце, системный аналитик описывает жизненный цикл задачи именно в его команде;
Аналитик показывает и рассказывает, где и как в продукте работает его часть. Это будет запись экрана интерфейсной части с комментариями о поведении системы, каких-то особых терминов или скрытой работы алгоритмов.
Все это аккуратно упаковывается, обвязывается розовой шелковой ленточкой и дожидается нового системного аналитика, который распакует этот приятный подарок на этапе вышеописанного онбординга.
Профит - колоссальный! Это полностью автономный этап для нового сотрудника, который значительно сокращает время его погружения в продукт.
Тайный клуб аналитики
![](https://habrastorage.org/getpro/habr/upload_files/b48/4d6/92d/b484d692d142814629d7f343b4a8d636.png)
Ну и на сладкое - самое загадочное и настолько же важное мероприятие. Идея заключается в том, чтобы действовать на опережение в вопросе блокирующих работу ситуаций для системных аналитиков уровня Junior и Middle.
Два раза в неделю ровно час мы проводим мероприятие со свободным входом. Участники по очереди рассказывают о текущих в данный момент живых кейсах, в которых они сильно застряли, либо хотели бы спросить экспертного мнения. И в режиме online коллективно начинаем разбирать ситуацию. Тем самым мы одновременно получаем сразу два положительных эффекта:
Задача сдвигается с мертвой точки + довольный аналитик;
Другие участники понимают, какие могут быть проблемы и уже заранее запоминают, как действовать в такой ситуации.
Зачастую бывают случаи, когда разобранные ранее кейсы на прошлых встречах помогали быстро решить проблему на текущих. Т.е. тут срабатывает накопительный эффект. В будущем я хочу расширить аудиторию этого клуба и приглашать на него системных аналитиков из смежных направлений. Я считаю, это будет прекрасный обмен опытом и коллективное развитие навыков.
Profit! Yeah!
Итог
Я стремлюсь к тому, чтобы работа системного аналитика была понятной. И, самое главное, чтобы специалист получал удовольствие от своей работы. Поэтому для меня очень важно собирать обратную связь от всех участников проекта, чтобы можно было оптимизировать процессы не только с точки зрения развития продукта, но и с точки зрения работы над ним.
Хотел бы также рассказать и про другие имеющиеся инструменты для повышения качества работы:
Индивидуальные планы развития и роста системного аналитика;
Поддержание единого инфополя при работе с несколькими командами;
“Строгая гибкость” написания ТЗ;
Выстраивание коммуникаций внутри банка между проектами;
Как провести собеседование в один этап и точно определить, в какую команду идет кандидат;
и т.д.
Но это будет в следующих сериях: как говорится, to be continued ...
Ушел творить добро дальше.
Adios!