Написан пост с оценкой того, как часто приходится выполнять работы в методологическом времени (обсуждать методы работы в инженерном процессе) и сколько процентов вашего рабочего времени занимает работа в методологическом времени.
Обсуждать методы работы удается лишь время от времени, причем по моей собственной инициативе, так как обычно у меня очень много технических задач – ожидается, что основное время я в инженерной роли, и это же соответствует и моей основной квалификации (инженерная, не менеджерская). Я пока лишь интересуюсь менеджментом, прохожу курсы, читаю книги.
Довольно часто замечаю что мы используем несовременные методы. Например, отметил несколько антипаттернов, описанных в книге “Team topologies”. Отмечаю использование водопадного подхода, upfront планирования и повсеместное использование термина “требования” – что также является антипаттернами в современной системной инженерии.
К сожалению, у меня нет ни менеджерского опыта ни полномочий для изменения методов работы на уровне организации. Иногда удается рассказать своему тимлиду о замеченных мною проблемах, но это редко приводит к изменениям. Отчасти потому что я недостаточно убедителен, отчасти из-за недостаточной менеджерской квалификации тимлида и его чрезмерной загрузки инженерными задачами.
Тем не менее, медленно удается что-то менять на уровне команды. Например, совершенствовать метод выпуска версий/релизов нашего софта:
- Постепенно “пропитываю” команду знанием, что тесты (даже ручные) должны быть легко выполняемыми – команда не должна тратить много ресурсов на прогон всех тестов перед очередным релизом (многие наши старые тесты были и есть second-class citizens, заброшенные, не описанные, не продуманные, не отчуждаемые, не повторяемые – нередко тесты приходится буквально переизобретать раз за разом).
- Разрабатываю фреймворк для автоматического и автоматизированного тестирования, добавил некоторое количество тестов с формальным критерием pass/fail.
- Составил чеклист выпуска версии софта (релиза). Чеклист оказался очень удобным для меня лично, когда я “веду” релиз. Однако если кто-то другой отвечает за релиз, то чеклист не выполняется (так как “нет времени”).
- Добавил практику документирования релизов, в частности написания integration guide с описаним того, что другим командам нужно изменить в их коде при переходе на новую версию нашего софта – за это я получил множество благодарностей. Однако опять же, оказывается, что только я могу писать эту документацию качественно – другие члены команды либо не достаточно погружены в детали, либо не умеют выделять и описывать важное, либо перегружены, либо не разделяют моего мнения о важности качественного описания.
Таким образом, я работаю в методологическом времени, но “выхлоп” от этой деятельности пока ограничен повышением качества моей собственной работы, небольшим улучшением работы команды, и пока отсутствующим улучшением в организации уровнем выше команды.
Фокусируясь пока на уровне команды, для более ощутимого изменения методов работы мне нужно:
- полномочия (требовать чего-то от членов команды);
- время на обучение членов команды;
- время на лидерство (обосновывать почему важно работать качественно);
- убедительность и влияние за пределами команды для получения ресурсов на предыдущие пункты; для этого, мне нужно больше знаний о функционировании фирмы и больше контактов за пределами команды.
