Ричард Клейтон написал болезненный, но поучительный пост под названием Неудачи в микросервисах - пожалуйста, избегайте наших ошибок, где заканчивает его словами:
Лично я предпочел микросервисную архитектуру; мы просто не могли этого сделать.
Чтение слов Ричарда напомнило мне множество похожих ситуаций из моей собственной истории, как инженера-программиста, так и менеджера по разработке. Вы когда-нибудь пробовали интегрировать новую технологию или концепцию в свой проект, но у вас ничего не получалось?
Я сделал. Это расстраивало в основном потому, что я знал, что делаю. У меня были ответы на все вопросы, по крайней мере, я так думал. Тем не менее, я не мог этого сделать. Хотя я не могу точно сказать, были ли проблемы, с которыми столкнулся Ричард, из-за недостатка навыков, я могу поделиться некоторыми наблюдениями, основанными на моем опыте неспособности внести аналогичные изменения.
Я считаю, что навыки Долг начинается, когда люди предпочитают придерживаться существующих решений, потому что не верят в возможность применения новых знаний с пользой. Это случается, когда мы вкладываем время в получение знаний, но забываем о том, чтобы укрепить доверие на этом пути, как внутри нашей команды, так и внешне с нашими коллегами.
Увеличение долга в профессиональных навыках - это результат деятельности организации, в которой падает доверие.
Чтобы избежать увеличения дефицита навыков в моей команде, я начал тесно сотрудничать с моими товарищами по команде в отношении методов, которые мы можем использовать, чтобы завоевать доверие в организации как внутри команды, так и с другими командами в организации. Я расскажу об этих методах, в том числе о том, как распределить эти усилия для предотвращения узких мест, но сначала давайте убедимся, что мы используем один и тот же словарь.
Определение долга навыков
Навык - это способность, основанная на знаниях, практике, способностях и т. Д. Делать что-то хорошо. Это означает получение знаний и их практическое применение достаточное количество раз, чтобы научиться не только делать это хорошо, но и когда это правильный инструмент для работы.
Я определю долг навыков, любезно одолжив и корректировка определения Мартина Фаулера Технический долг:
У вас есть часть функциональности, которую вам нужно добавить в свою систему. Вы видите два способа сделать это: один основан на ваших имеющихся знаниях, но вы знаете, что это не тот инструмент, который подходит для работы - вы уверены, что в будущем он сделает дальнейшие изменения труднее или даже невозможными. Другой результат - более чистый дизайн, но потребуется больше времени для внедрения, поскольку он требует нетривиального обучения в дополнение к самой работе.
Как определить, подвергает ли ваша команда риску ваши текущие навыки?
Увеличение долга навыков приводит к стагнации. На этом этапе ваши товарищи по команде больше не поверят, что изменения возможны или желательны. Когда люди делают одно и то же слишком долго, не имея возможности изменить это, это может убить любую форму инноваций или рост людей.
«Я не узнал ничего нового, поэтому решил бросить» - это синдром таких обстоятельств.
В какой-то момент в нашей профессиональной жизни мы понимаем, что здание организация программного обеспечения в конечном итоге занимается проблемами людей, а не проблемами программного обеспечения. Он начинается с решения проблем наших клиентов и продолжается созданием среды, в которой можно было бы создавать программное обеспечение, в то время как наша команда остается довольной и очень увлеченной своей работой.
Итак, обратите внимание на следующее поведение:
- Беспомощное мышление - ваша команда ждет, когда кто-то приедет, чтобы решить проблему, например эксперт в каком-то фреймворке, который вы хотите использовать. До тех пор команда будет избегать любых действий, выходящих за рамки их зоны комфорта.
- Рост цинизма и отсутствия сочувствия - опытные инженеры будут все более цинично относиться к способности команды наверстать упущенное. Постепенно вы увидите лагеря внутри команды людей, которые считают себя лучше других, и общение будет это отражать. Вы увидите, как парное программирование выполняется одними и теми же людьми. Вы увидите, что люди делают заметки во время встреч только от людей, которых они уважают в команде. Люди будут избегать обучения или наставничества других товарищей по команде, так как они сочтут это пустой тратой времени.
- Отражение вины - обвинение чаще происходит внутри команды, например «У нас дерьмовый код, и никто не заботится» - или - обвиняя руководство в нехватке времени, например, «Они не дают нам времени делать все правильно».
Кому должен принадлежать долг вашей команды?
Укрепление доверия - это образ мышления, точно так же, как стремление написать высококачественный код или предоставить нашим клиентам высококачественный продукт. Таким образом, ответственность должна быть распределена. Это должно стать основной ценностью команды.
Многие инженеры-менеджеры считают, что они должны нести ответственность за то, чтобы владеть навыками своей команды. Это еще более распространено, если технический менеджер также является самым техническим человеком в команде. Об этом я подумал, когда впервые был инженером. Сегодня я вижу это по-другому.
Управление задолженностью по навыкам включает в себя множество умственных задач, таких как поддержание морального духа на высоком уровне, решение, когда инвестировать в сокращение этого долга, отслеживание его, чтобы команда чувствовала, что все под контролем, получение необходимой поддержки со стороны руководства и т. д. Он также включает в себя множество технических проблем, позволяющих получить эти знания, потратить время на обучение, рефакторинг существующего кода, чтобы он соответствовал новой парадигме и т. Д.
Я вижу две области, которые команде необходимо решить для управления долей навыков: технические и отношение. Начнем с первых, и я считаю, что они должны владеть этим.
Право собственности на технические лидеры -
Это самые техничные люди в команде. Я считаю, что технические руководители должны тратить не менее 20% своего времени на обучение других товарищей по команде или других команд в организации.
Нам не нужно больше архитекторов программного обеспечения. Нам нужно больше учителей и наставников, чтобы усилить наших сотрудников, а не нашу программную архитектуру.
Что должны отслеживать технические лидеры?
- Кто в настоящее время становится узким местом из-за своего уникального опыта?
- Кто в настоящее время не может предоставлять определенные функции из-за отсутствия знаний или опыта?
- Где слабое место команды с точки зрения технических навыков?
- Во время анализа проекта команда подумала и сообщила следующее:
- [1] Что происходит в случае аварии? Есть план отката?
- [2] Каков план перехода?
- [3] Есть ли вехи в этом процессе? Можем ли мы создать их, чтобы снизить риск?
- [4] Не хватает ли обучения другим, чтобы добиться успеха в этом? Можем ли мы начать с этого?
- [5] Каковы сроки?
Результатом каждого вопроса является предложение о том, как исправить это в будущем. Это может быть проверка кода или парное программирование. Это может быть покупка книг для команды и еженедельное 30-минутное собрание, чтобы поделиться тем, что каждый человек взял из книги. Это может быть поиск интересных встреч для других товарищей по команде.
За этим должны следить технические руководители. Они должны предоставить руководителю инженерного отдела предложения о том, как решить каждую проблему, чтобы команда могла продолжать работать в том же темпе в течение длительного времени. И да, они должны попросить дополнительное время для обучения или ресурсы, если это необходимо.
Собственность инженерных менеджеров -
Когда я был инженером, и один из технических руководителей в команде подошел ко мне и сказал: «Качество нашего кода ухудшается с каждой минутой», я любил отвечать: «Почему? Что ты собираешься с этим делать? »
Это был плохой ответ, не потому, что я считаю, что это неправда. Это показывает, что для них не было очевидным, что я этого от них ожидаю. Это не было явным, поэтому каждый подумал, что другой человек позаботится об этом. Если это ваш случай, исправьте это.
Что должны контролировать технические менеджеры?
- Есть ли в команде ощущение, что все под контролем?
- [1] Задолженность по навыкам может быть возможностью для роста, если она не погружает команду в состояние аналитического паралича.
- [2] В разговоре с командой 1: 1 спросите их: «Что сегодня не работает хорошо? Что мешает вам работать над нашим продуктом? Вы чувствуете, что за последние 3 месяца стало лучше? Если нет, что мы можем сделать, чтобы это исправить? »
- Люди заняты своей работой? Люди счастливы? Есть ли позитивный настрой, даже когда есть пробелы в знаниях?
- Вы создаете у команды привычки к обучению?
- Есть ли место, где каждый может высказать свое мнение, или оно принадлежит очень немногим?
- Является ли текущий недостаток навыков или технический долг признаком отсутствия найма? Хотя это не должно мешать команде учиться, иногда это явный признак того, что вам нужно больше технических руководителей, чтобы сбалансировать эти обязанности.
- Другим командам комфортнее работать с нами? Чувствуют ли они себя более расслабленными и уверенными в нашей способности осуществить большие преобразования? Вы можете многое узнать, проведя один на один с менеджерами инженеров из других команд и спросив их мнение со стороны.
- Чему вы можете научиться у других команд? Достаточно ли вы делаете, чтобы попросить о помощи?
- Чему вы можете научить другие команды? Вы мотивируете и стимулируете своих товарищей по команде делиться с другими командами? Я настоятельно рекомендую прочитать Культуру помощи IDEO.
Я думаю, что инженеры-менеджеры должны тесно сотрудничать с техническими руководителями команды, чтобы убедиться, что ожидания оправданы, и у них есть необходимые ресурсы (в основном время), чтобы общаться с разными товарищами по команде и помогать им совершенствоваться.
Технические менеджеры должны уделять особое внимание тому, как люди разговаривают и реагируют.
Нашим конкурентным преимуществом всегда будет способ совместной работы и адаптации нашей организации, а не архитектура, реализованная для текущего решения. Снижение долга по навыкам - это не только инвестирование времени в общение и укрепление доверия, но и получение определенных знаний и опыта.
Я хочу поблагодарить Darragh Curran за его большой вклад, мысли и отзывы о ранних черновиках этой публикации.
PS ты проверял мои сайд-проекты?
1. SoftwareLeadWeekly - бесплатное еженедельное электронное письмо для занятых людей, которым небезразличны люди, культура и лидерство.
2. Leading Snowflakes - Руководство инженерного менеджера: практические инструменты и методы для программистов, которые хочу вести.
