{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Менеджерские принципы, приводящие в аналитику

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

Это достаточно универсальные правила, подходящие и для менеджера, и для аналитика, и для других участников команды. Делимся ими, но предупреждаем, самого Алексея они в итоге привели в аналитику.

Потратив пять минут сейчас, вы экономите час работы команды в будущем

Этот принцип применим ко всем участникам команды. Если разобрать его глубже, то из него вытекают более конкретные правила:

1. Инциденты не должны повторяться. Последствия инцидентов нужно устранять здесь и сейчас, чтобы не возвращаться к ним в будущем.

2. Информация должна храниться унифицировано. Типовые формулировки при постановке задач, тегирование, связь с другими задачами, наличие чейнджлогов и подробных описаний в вики требуют дополнительного времени на оформление, но значительно снижают издержки поиска информации для всей команды.

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

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

4. Думайте на несколько шагов вперёд. Хорошо продуманные решения сделают масштабирование и кастомизацию системы гораздо проще. Разумеется, здесь придётся постоянно искать компромиссы, так как без костылей порой не обойтись, но даже эти костыли можно и нужно попробовать сделать пригодными для дальнейшего использования.

Научитесь общаться

Важен не сам факт вашей коммуникабельновсти – важно превратить общение в эффективный рабочий инструмент. И следующие правила помогут в этом:

1. Разговаривайте с людьми на одном языке. С бизнес-заказчиком общайтесь на «человеческом», а с разработчиками – на «техническом». Для этого потребуется более глубокое погружение в предметную область с вашей стороны, но это и отличает лидера от статиста. Степень этого погружения определяется индивидуально. Например, вам не обязательно уметь читать код разработчика, но если вы изучите базовые принципы процесса разработки, — работа с git, ветками, коммитами — то обсуждать процессы выкатки релиза станет проще.

Старайтесь придерживаться того же стиля общения, что и собеседник, использовать аналогичные фразы и словосочетания. Например, у одного из моих заказчиков была очень популярной фраза «делать в моменте». И если вместо этой фразы использовалась «делать в реальном времени», то по лицам собеседников было видно, что они не совсем понимали, о чём идёт речь.

2. Никаких конфликтов! Сохраняйте спокойствие даже в сложных ситуациях. Не поддавайтесь на провокации со стороны собеседника и не провоцируйте его своими неосторожными словами. Умейте признавать вину, если вы неправы. Старайтесь проявлять нейтралитет в любых ситуациях.

3. Будьте честными. Разумеется, в рамках ваших обязательств по NDA. Акцентируйте внимание на тех моментах, о которых вы действительно рассказываете честно, и тогда собеседник со временем станет более расположенным к вам. Возможно, даже начнет делиться информацией, которая ранее была для вас закрытой.

4. Называйте пессимистичные сроки. Это особенно актуально при работе с инцидентами. Если вы озвучите время устранения 15 минут, а устраните инцидент через 30 минут — вы автоматически станете «медленным и проблемным» исполнителем.

А если для этого же инцидента вы озвучите время устранения в 1 час, то устранив его за 30 минут, станете «ответственным и надежным» исполнителем. Самое трудное здесь – озвучить больший срок. Зачастую мы скованы рамками SLA, да и заказчики могут не совсем адекватно на это отреагировать. Однако, если к этому моменту вы заработаете репутацию честного сотрудника, то лояльный заказчик вместо возмущения будет спокойно организовывать альтернативные способы работы на время инцидента.

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

Осторожно: принципы приводят в аналитику

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

Так что могу точно сказать, принципы отрабатывались и проверялись в боевых условиях. К счастью, большинство решений приносили положительный результат. Где-то тут начались побочки. Я стал ловить себя на мысли, что начинаю все глубже погружаться в суть будущих доработок системы, обсуждать и совместно прорабатывать их с аналитиками. И вдруг менеджмент стал казаться скучным, а задачи превратились в рутину. Решение нашлось.

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

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

Приятный бонус – тайм-менеджмент. Даже в рамках одного проекта приходится прорабатывать несколько задач параллельно. А уж если аналитик ведет несколько проектов, то навык мгновенно переключаться между ними становится жизненно необходимым.

Вывод будет такой: в ситуациях неопределённости очень важно вовремя менять проекты или свою роль на них, не задерживаясь долго на чём-то одном. Можно поучаствовать одновременно в нескольких разных проектах на разных ролях. Подобная смена деятельности покажет вам, что получается лучше, а что – хуже. И главное – чем вам интересно заниматься, а чем – нет.

Алексей Аксянов
Системный аналитик «Технократии»

Подписывайтесь на наш Telegram-канал «Голос Технократии», где мы пишем о новостях из мира ИТ и высказываем свое мнение о важных событиях.

0
1 комментарий
Инна Тарбаева

Как приятно читать такие статьи! Жаль что далеко не все руководители воплощают эти идеи в реальность.

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда