Привет, Хабр!
Меня зовут Максим Пермяков, я руководитель центра компетенции (далее — ЦК) систем клиент-сервер в компании «Спортмастер». А с 2020 года также являюсь руководителем ЦК системного анализа.
В этом посте я хочу рассказать вам про роль системного аналитика в нашей компании и поделиться опытом создания и развития ЦК.
Начну немного издалека. Меня можно считать классическим разработчиком: закончил факультет прикладной математики, получил квалификацию «математик — системный программист» и уже на втором курсе начал работать по специальности именно программистом. Это был 1999 год и в то время не было деления по специальностям, как сейчас. Все были «тыжпрограммистами» — универсальными солдатами. Днем делали все — от сетей 1С до сайтов на PHP, а вечером еще меняли картриджи в принтере.
До прихода в «Спортмастер» я 12 лет проработал в банке. У нас были заказчики на стороне бизнеса, для которых мы разрабатывали финансовые приложения. И, что важно, прорабатывали их полностью — от базы данных до клиентской части приложения. Я получал большое удовольствие от своей работы, т.к. участвовал в получении результата целиком.
Когда меня друг позвал попробовать себя в «Спортмастере», то я искренне не понимал, что они там в этом ритейле вообще делают. С банком-то всё понятно, там всегда много разработки. А в ситуации со «Спортмастером» я шутил, что до обеда они покупают кроссовки за доллар, продают за два, вносят в 1С, а после обеда что там делать?
Придя в компанию, я был сильно удивлен количеством задач, их сложностью, нагрузкой и размерами ИТ «Спортмастера». Оказалось, что программное обеспечение, которое позволяет компании улучшать бизнес-процессы и получать прибыль, очень тяжело купить на рынке, потому что подходящего ПО попросту нет. Конечно, есть бухгалтерия, там всё хорошо с автоматизацией на стандартной системе 1С, всех всё устраивает. Но есть набор специализированного ПО, которое прогнозирует, обсчитывает, автоматизирует внутренние процессы. Оно слабо представлено на рынке. В ответ на этот вызов мы решили развивать собственное направление разработки ПО. Под разработкой подразумевается и аналитика, и разработка, и тестирование.
Сейчас в IT работают уже более тысячи человек. В компании полным ходом идет процесс трансформации и реорганизации.
Раньше мы использовали классический проектный подход: сотрудника могли выделить на один проект на 30%, на второй — на 20%, на третий — на 50%., и достаточно редко он на 100% был вовлечен в одну задачу. При таком подходе были свои минусы, связанные со сменой приоритетов. Но главной болью было то, что иногда конечной целью было не работу хорошо сделать, а найти крайнего. Извечная проблема, кто виноват — разработчик или аналитик.
С началом трансформации мы начали делать продукты с помощью команд, состоящих из разработчиков, аналитиков и тестировщиков. Цель команды — общий результат. С переменой подхода мы поняли, что во взаимодействии аналитиков и разработчиков есть огромная зона для улучшений, поработав над которой мы можем вывести конечный результат на качественно новый уровень.
Я изначально видел в аналитиках помощников, но глобально нам было сложно выстроить совместную работу. Работу программистов мы строили от общих знаний и стандартов, а также практик Code Review и Code Style. Начиная с этапа найма мы четко знали, какие знания нужно проверять, на какие курсы нужно сходить разработчику конкретного уровня. Мы понимали, как оценить его навыки и какие смежные технологии можно освоить. А в аналитике мы видели отсутствие базиса. При этом у меня, например, было четкое понимание, что аналитик — это отдельная профессия. Т.е. это не человек, который почему-то не может программировать или тестировать. А человек, у которого, с одной стороны, скиллы направлены на общение, а с другой — сильный технический бэкграунд.
Мы приняли решение создать центр компетенций системных аналитиков. Перед нами стояла задача выработать в системном анализе общие подходы, проработать понятные грейды и прозрачные планы развития, настроить обучение, а также общение сообщества аналитиков через внутренние клубы. Для нас были важны люди, процессы и инструменты.
И вот что мы делали в этом направлении.
Первое, что мы сделали — создали ядро центра компетенции. Сейчас в него входят 7 человек.
Все ребята очень разные по своему опыту и знаниям. Тем не менее команда у нас получилась дружная и сплоченная, и сильные стороны каждого позволили сделать большой шаг вперед.
Вместе мы начали описывать роль системного аналитика. Что он делает, какими знаниями обладает, какие задачи перед ним стоят. Проработали и описали процесс взаимодействия ядра центра компетенции с продуктовыми командами.
Для того чтобы поддерживать это взаимодействие, мы ввели встречи один на один между представителями ядра и сотрудниками продуктовых команд. Цель этих встреч — обсуждение роста и развития сотрудника, донесение обратной связи, прояснение состояния сотрудника, обсуждение накопившихся проблем и достижений. Важно помнить, что:
Важным фокусом для нас стало обучение. Я считаю, что через обучение можно закрыть множество проблем. Но важно подчеркнуть, что это дорога с двусторонним движением. Важно, чтобы сотрудник сам хотел учиться и развиваться. И понимал, что в IT, помимо базовых знаний, приходится постоянно изучать что-то новое.
У нас появились курсы и программы, созданные несколькими образовательными площадками специально для нас. Мы наладили работу с онлайн-курсами — это очень удобно для тех, кому нужно подтянуть базовые навыки.
Например, если сотруднику необходимо подтянуть знания по SQL или Figma — он может записаться на курс, выделить на него рабочее время и заполнить пробелы в знаниях. А мы предоставляем учебную базу, сервера, оплачиваем обучение. Курсы, которые реализуют специфику применения инструмента в «Спортмастере» мы проводим сами.
Одним из важных шагов стал запуск внутреннего клуба аналитиков, на котором ребята делятся своим опытом, рассказывают про новые изученные инструменты, про удачные практики в своих командах, получают опыт выступлений и модерации встреч. Клубы помогают не только делиться опытом, но и развивать центр компетенций всем вместе, а не только с помощью ядра.
Вместе с сотрудниками, которые активно участвовали во внутренних клубах мы организовали первый митап по системной аналитике, почитать про который и посмотреть видео докладов вы можете здесь.
Т.к. компания активно растет и развивается, в нее приходят много новых сотрудников. Совместно с HR мы проработали процесс онбординга и наставничества. У каждого нового сотрудника есть ментор, который погружает в продукт, отвечает на вопросы «зачем и почему», помогает следовать процессам. Если он сам не знает ответ на вопрос, то поможет найти того, кто знает. Для самого ментора это также важный шаг карьерной лестницы, т.к., совершенствуя других, вы совершенствуете и себя тоже.
Если у сотрудника есть ментор, то, как правило, сотрудник:
В результате выстроенного процесса в нашей компании остаются работать примерно 95% новичков.
После выстраивания работы с людьми мы задумались над общим вектором развития команд с точки зрения аналитики. И проработали такой документ как дорожная карта.
Она содержит блоки, связанные с:
Для каждого блока мы расписали цель и критерии достижения. Мы не ставим жестких дедлайнов, т.к. важно не выполнение работ «ради галочки», а выстраивание процессов, развитие аналитики и создание разделяемых и дорабатываемых артефактов. Своя дорожная карта есть у каждого центра компетенций и у самого продукта. Выбирая важные для команды векторы развития, мы в комплексе получаем дорожную карту развития команды.
Одним из важных пунктов дорожной карты является внедрение практики ревью требований, которая необходима для:
Ценность ревью требований заключается в повышении качества продукта и уменьшении стоимости исправления дефектов. Мы проработали инструменты для проведения ревью, его визуализацию на доске в Jira, роли в ревью, длительность и время его проведения. Также уделили достаточно времени культуре ревью. Поговорили с ребятами о том, что важно фокусироваться на задаче, а не человеке; что замечания нужно формулировать не как команду, а как предложение или запрос; что, критикуя, нужно предлагать и т.д.
Внедрение дорожных карт оказалось сложной задачей, т.к. нужно привносить новые практики и не сломать то, что есть. Ведь команды делают реальный продукт, работают, и любые организационные изменения, изменения подходов не должны были это нарушить.
Т.к. продуктовых команд становилось всё больше, а сотрудникам Core нужно было уделять время как развитию центра компетенций, так и работе с людьми, мы ввели такую роль как куратор.
Куратор — это сотрудник, который:
Как правило, у одного куратора не более 3-4 продуктовых команд и не более 10 сотрудников.
За довольно непродолжительное время у нас получилось внедрить несколько важных инструментов.
Мы провели несколько семинаров по PlantUML, установили плагины для Confluence, показали, как с ними работать и разобрали основные диаграммы. Я давно пользуюсь этим инструментом, т.к. плохо рисую диаграммы и страдал, когда их нужно было переделывать. Командам инструмент понравился и его начали активно использовать. Например, одна из популярных диаграмм — sequence-диаграмма, удобно составляется с помощью PlantUML.
Мы даже пошли немного дальше и стали складывать код диаграмм в систему контроля версий в Git, а из нее уже отрисовывать в Confluence. Мы автоматически генерируем некоторые диаграммы и на странице описания системы поддерживаются актуальные данные. Внедрение прошло легко – все команды, взявшие этот инструмент в свою работу, сделали это по своей воле. С нашей методологической помощью, но без навязывания.
При этом я считаю, что системный аналитик не должен быть экспертом по Git, мерджить код лучше всех и т.д. Но ему важно понимать, какие существуют системы ветвления, их преимущества и недостатки. Это напрямую связано с тем, как мы выкатываем продукт в production — можем ли отменять задачи, есть ли feature toggle. Также важно понимать, как устроена связка работы в Jira и Git, где мастер-ветка, которая показывается в Confluence, как именно происходило изменение. Какая задача пришла и как она повлияет на процесс, и т.д.
Поэтому в процессе работы с Git мы познакомили аналитиков с этим инструментом через рассказ о том, что такое система контроля версий, зачем она нужна.
Из других инструментов мы используем Miro и Figma. Есть команды, которые в этих инструментах достигли экспертного уровня. Помогли им пройденные курсы, обмен опытом на клубе аналитиков и практические задачи, на которых они смогли применить свои знания. После этого инструменты активно пошли «в народ», т.к. команды увидели, что они не сложные и дают результат.
Подводя итог, после создания ЦК мы проработали роль системного аналитика, ввели роли куратора и ментора, составили первую версию дорожной карты, проработали грейды и индивидуальные планы развития для сотрудников, начали проводить встречи один на один, выстроили процесс онбординга и процесс обучения, начали использовать новые инструменты. И на этом останавливаться точно не собираемся.
Сейчас нам удается договариваться с бизнесом и показывать ему важность развития команд, выделять на это квант времени, но так было не всегда. Были времена, когда приходилось доказывать, выбивать какое-то время на технические рефакторинги, оптимизацию системы, которые давали реальный результат. Понятно, почему люди из бизнеса с осторожностью идут на это – часто им кажется, что основное внимание должно быть направлено на создание новых фичей. Но жизнь все-таки гораздо более сложная штука.
Сейчас мы собираем всех аналитиков в центре компетенций и последовательно формируем с их помощью продуктовые команды, а также продолжаем развивать процессы и изучать новые инструменты.
Меня зовут Максим Пермяков, я руководитель центра компетенции (далее — ЦК) систем клиент-сервер в компании «Спортмастер». А с 2020 года также являюсь руководителем ЦК системного анализа.
В этом посте я хочу рассказать вам про роль системного аналитика в нашей компании и поделиться опытом создания и развития ЦК.
Начну немного издалека. Меня можно считать классическим разработчиком: закончил факультет прикладной математики, получил квалификацию «математик — системный программист» и уже на втором курсе начал работать по специальности именно программистом. Это был 1999 год и в то время не было деления по специальностям, как сейчас. Все были «тыжпрограммистами» — универсальными солдатами. Днем делали все — от сетей 1С до сайтов на PHP, а вечером еще меняли картриджи в принтере.
До прихода в «Спортмастер» я 12 лет проработал в банке. У нас были заказчики на стороне бизнеса, для которых мы разрабатывали финансовые приложения. И, что важно, прорабатывали их полностью — от базы данных до клиентской части приложения. Я получал большое удовольствие от своей работы, т.к. участвовал в получении результата целиком.
Когда меня друг позвал попробовать себя в «Спортмастере», то я искренне не понимал, что они там в этом ритейле вообще делают. С банком-то всё понятно, там всегда много разработки. А в ситуации со «Спортмастером» я шутил, что до обеда они покупают кроссовки за доллар, продают за два, вносят в 1С, а после обеда что там делать?
Проблемы и поиск решения
Придя в компанию, я был сильно удивлен количеством задач, их сложностью, нагрузкой и размерами ИТ «Спортмастера». Оказалось, что программное обеспечение, которое позволяет компании улучшать бизнес-процессы и получать прибыль, очень тяжело купить на рынке, потому что подходящего ПО попросту нет. Конечно, есть бухгалтерия, там всё хорошо с автоматизацией на стандартной системе 1С, всех всё устраивает. Но есть набор специализированного ПО, которое прогнозирует, обсчитывает, автоматизирует внутренние процессы. Оно слабо представлено на рынке. В ответ на этот вызов мы решили развивать собственное направление разработки ПО. Под разработкой подразумевается и аналитика, и разработка, и тестирование.
Сейчас в IT работают уже более тысячи человек. В компании полным ходом идет процесс трансформации и реорганизации.
Раньше мы использовали классический проектный подход: сотрудника могли выделить на один проект на 30%, на второй — на 20%, на третий — на 50%., и достаточно редко он на 100% был вовлечен в одну задачу. При таком подходе были свои минусы, связанные со сменой приоритетов. Но главной болью было то, что иногда конечной целью было не работу хорошо сделать, а найти крайнего. Извечная проблема, кто виноват — разработчик или аналитик.
С началом трансформации мы начали делать продукты с помощью команд, состоящих из разработчиков, аналитиков и тестировщиков. Цель команды — общий результат. С переменой подхода мы поняли, что во взаимодействии аналитиков и разработчиков есть огромная зона для улучшений, поработав над которой мы можем вывести конечный результат на качественно новый уровень.
Я изначально видел в аналитиках помощников, но глобально нам было сложно выстроить совместную работу. Работу программистов мы строили от общих знаний и стандартов, а также практик Code Review и Code Style. Начиная с этапа найма мы четко знали, какие знания нужно проверять, на какие курсы нужно сходить разработчику конкретного уровня. Мы понимали, как оценить его навыки и какие смежные технологии можно освоить. А в аналитике мы видели отсутствие базиса. При этом у меня, например, было четкое понимание, что аналитик — это отдельная профессия. Т.е. это не человек, который почему-то не может программировать или тестировать. А человек, у которого, с одной стороны, скиллы направлены на общение, а с другой — сильный технический бэкграунд.
Мы приняли решение создать центр компетенций системных аналитиков. Перед нами стояла задача выработать в системном анализе общие подходы, проработать понятные грейды и прозрачные планы развития, настроить обучение, а также общение сообщества аналитиков через внутренние клубы. Для нас были важны люди, процессы и инструменты.
И вот что мы делали в этом направлении.
Люди
Первое, что мы сделали — создали ядро центра компетенции. Сейчас в него входят 7 человек.
Все ребята очень разные по своему опыту и знаниям. Тем не менее команда у нас получилась дружная и сплоченная, и сильные стороны каждого позволили сделать большой шаг вперед.
Вместе мы начали описывать роль системного аналитика. Что он делает, какими знаниями обладает, какие задачи перед ним стоят. Проработали и описали процесс взаимодействия ядра центра компетенции с продуктовыми командами.
Для того чтобы поддерживать это взаимодействие, мы ввели встречи один на один между представителями ядра и сотрудниками продуктовых команд. Цель этих встреч — обсуждение роста и развития сотрудника, донесение обратной связи, прояснение состояния сотрудника, обсуждение накопившихся проблем и достижений. Важно помнить, что:
- Встречи должны быть запланированными и регулярными.
- Встречи должны быть конфиденциальными. Это важно для создания доверительных взаимоотношений между руководителем и сотрудником.
- Встречи проводятся в первую очередь для сотрудника.
- Лучший способ показать человеку, что он для вас важен — сесть рядом, взять лист бумаги и делать на нем пометки по ходу разговора. Если за мной записывают — это круто, значит, меня слушают и слышат. Т.к. последнее время многие работают в онлайне, то мы создали личные кабинеты сотрудникам, в которых мы вместе фиксируем итоги, договоренности, открытые вопросы и проблемы.
Важным фокусом для нас стало обучение. Я считаю, что через обучение можно закрыть множество проблем. Но важно подчеркнуть, что это дорога с двусторонним движением. Важно, чтобы сотрудник сам хотел учиться и развиваться. И понимал, что в IT, помимо базовых знаний, приходится постоянно изучать что-то новое.
У нас появились курсы и программы, созданные несколькими образовательными площадками специально для нас. Мы наладили работу с онлайн-курсами — это очень удобно для тех, кому нужно подтянуть базовые навыки.
Например, если сотруднику необходимо подтянуть знания по SQL или Figma — он может записаться на курс, выделить на него рабочее время и заполнить пробелы в знаниях. А мы предоставляем учебную базу, сервера, оплачиваем обучение. Курсы, которые реализуют специфику применения инструмента в «Спортмастере» мы проводим сами.
Одним из важных шагов стал запуск внутреннего клуба аналитиков, на котором ребята делятся своим опытом, рассказывают про новые изученные инструменты, про удачные практики в своих командах, получают опыт выступлений и модерации встреч. Клубы помогают не только делиться опытом, но и развивать центр компетенций всем вместе, а не только с помощью ядра.
Вместе с сотрудниками, которые активно участвовали во внутренних клубах мы организовали первый митап по системной аналитике, почитать про который и посмотреть видео докладов вы можете здесь.
Т.к. компания активно растет и развивается, в нее приходят много новых сотрудников. Совместно с HR мы проработали процесс онбординга и наставничества. У каждого нового сотрудника есть ментор, который погружает в продукт, отвечает на вопросы «зачем и почему», помогает следовать процессам. Если он сам не знает ответ на вопрос, то поможет найти того, кто знает. Для самого ментора это также важный шаг карьерной лестницы, т.к., совершенствуя других, вы совершенствуете и себя тоже.
Если у сотрудника есть ментор, то, как правило, сотрудник:
- Быстрее погружается в команду, процессы и продукт.
- Быстрее становится самостоятельным. Значит, быстрее приносит ценность команде.
- Быстрее переходит из чужого в своего для команды.
- Не чувствует себя брошенным. Это увеличивает вероятность того, что человек останется надолго в компании
В результате выстроенного процесса в нашей компании остаются работать примерно 95% новичков.
Процессы
После выстраивания работы с людьми мы задумались над общим вектором развития команд с точки зрения аналитики. И проработали такой документ как дорожная карта.
Она содержит блоки, связанные с:
- Налаживанием обмена опытом между командами
- Выстраиванием процесса ревью требований
- Выстраиванием процессов внутри команды и взаимодействия со смежными командами
- Проработкой общих подходов к написанию требований
- Созданием глоссария продукта
- Работе с новыми сотрудниками и т.д.
Для каждого блока мы расписали цель и критерии достижения. Мы не ставим жестких дедлайнов, т.к. важно не выполнение работ «ради галочки», а выстраивание процессов, развитие аналитики и создание разделяемых и дорабатываемых артефактов. Своя дорожная карта есть у каждого центра компетенций и у самого продукта. Выбирая важные для команды векторы развития, мы в комплексе получаем дорожную карту развития команды.
Одним из важных пунктов дорожной карты является внедрение практики ревью требований, которая необходима для:
- Выявления неоднозначных или непроверяемых требований
- Выявления конфликтов между требованиями
- Обмена знаниями
- Уменьшения возвратов на этап анализа
- Поддержания общего стиля документации
- Повышения читабельности требований
Ценность ревью требований заключается в повышении качества продукта и уменьшении стоимости исправления дефектов. Мы проработали инструменты для проведения ревью, его визуализацию на доске в Jira, роли в ревью, длительность и время его проведения. Также уделили достаточно времени культуре ревью. Поговорили с ребятами о том, что важно фокусироваться на задаче, а не человеке; что замечания нужно формулировать не как команду, а как предложение или запрос; что, критикуя, нужно предлагать и т.д.
Внедрение дорожных карт оказалось сложной задачей, т.к. нужно привносить новые практики и не сломать то, что есть. Ведь команды делают реальный продукт, работают, и любые организационные изменения, изменения подходов не должны были это нарушить.
Т.к. продуктовых команд становилось всё больше, а сотрудникам Core нужно было уделять время как развитию центра компетенций, так и работе с людьми, мы ввели такую роль как куратор.
Куратор — это сотрудник, который:
- Занимается развитием сотрудников продуктовых команд по направлению ЦК, помогает проходить дорожную карту
- Совместно с сотрудником прорабатывает грейды и составляет индивидуальный план развития
- Проводит встречи один на один, дает обратную связь сотруднику
- Помогает с адаптацией новых сотрудников в команде
- Является связующим звеном между ядром ЦК и продуктовой командой
Как правило, у одного куратора не более 3-4 продуктовых команд и не более 10 сотрудников.
Инструменты
За довольно непродолжительное время у нас получилось внедрить несколько важных инструментов.
Мы провели несколько семинаров по PlantUML, установили плагины для Confluence, показали, как с ними работать и разобрали основные диаграммы. Я давно пользуюсь этим инструментом, т.к. плохо рисую диаграммы и страдал, когда их нужно было переделывать. Командам инструмент понравился и его начали активно использовать. Например, одна из популярных диаграмм — sequence-диаграмма, удобно составляется с помощью PlantUML.
Мы даже пошли немного дальше и стали складывать код диаграмм в систему контроля версий в Git, а из нее уже отрисовывать в Confluence. Мы автоматически генерируем некоторые диаграммы и на странице описания системы поддерживаются актуальные данные. Внедрение прошло легко – все команды, взявшие этот инструмент в свою работу, сделали это по своей воле. С нашей методологической помощью, но без навязывания.
При этом я считаю, что системный аналитик не должен быть экспертом по Git, мерджить код лучше всех и т.д. Но ему важно понимать, какие существуют системы ветвления, их преимущества и недостатки. Это напрямую связано с тем, как мы выкатываем продукт в production — можем ли отменять задачи, есть ли feature toggle. Также важно понимать, как устроена связка работы в Jira и Git, где мастер-ветка, которая показывается в Confluence, как именно происходило изменение. Какая задача пришла и как она повлияет на процесс, и т.д.
Поэтому в процессе работы с Git мы познакомили аналитиков с этим инструментом через рассказ о том, что такое система контроля версий, зачем она нужна.
Из других инструментов мы используем Miro и Figma. Есть команды, которые в этих инструментах достигли экспертного уровня. Помогли им пройденные курсы, обмен опытом на клубе аналитиков и практические задачи, на которых они смогли применить свои знания. После этого инструменты активно пошли «в народ», т.к. команды увидели, что они не сложные и дают результат.
Итоги
Подводя итог, после создания ЦК мы проработали роль системного аналитика, ввели роли куратора и ментора, составили первую версию дорожной карты, проработали грейды и индивидуальные планы развития для сотрудников, начали проводить встречи один на один, выстроили процесс онбординга и процесс обучения, начали использовать новые инструменты. И на этом останавливаться точно не собираемся.
Сейчас нам удается договариваться с бизнесом и показывать ему важность развития команд, выделять на это квант времени, но так было не всегда. Были времена, когда приходилось доказывать, выбивать какое-то время на технические рефакторинги, оптимизацию системы, которые давали реальный результат. Понятно, почему люди из бизнеса с осторожностью идут на это – часто им кажется, что основное внимание должно быть направлено на создание новых фичей. Но жизнь все-таки гораздо более сложная штука.
Сейчас мы собираем всех аналитиков в центре компетенций и последовательно формируем с их помощью продуктовые команды, а также продолжаем развивать процессы и изучать новые инструменты.