Как новичку, как мне заставить людей действовать в соответствии со всеми их громкими разговорами?

Я «новичок» в ИТ-отделе небольшой производственной компании. У нас есть небольшая команда из 3 разработчиков приложений + 1 роль разработчика базы данных/dba-ish. Я работаю здесь несколько месяцев, так что я приближаюсь к моменту, когда начал завоевывать доверие и признание своих коллег.

Во время моего интервью было много разговоров о желании быть более Agile. Об этом до сих пор много говорят , но никаких действий. Честно говоря, мне все равно, Agile мы или нет, но нам действительно нужно начать делать некоторые вещи, которые являются просто передовой практикой, Agile или нет. Такие вещи, как модульное тестирование и проверка кода. Да, давайте сначала начнем с этих двух, так как они самые выгодные.

Теперь я проверяю код, к которому прикасаюсь, прежде чем изменять его. Отчасти потому, что я увидел преимущества, а отчасти потому, что боюсь что-либо сломать в унаследованной кодовой базе. Мой менеджер очень доволен этим. Он мне сам так сказал. Остальной команде, кажется, нравится идея тестирования и закрытых проверок, но они не предприняли никаких действий, чтобы начать это делать . Я думаю, это может быть потому, что они просто не знают, как это сделать, но возможно, что они думают, что «у них нет времени». (Кстати, тот факт, что нет времени, совершенно не соответствует действительности. Менеджмент знает, что это авансовые инвестиции, которые окупаются, и полностью поддерживает эти усилия.)

Честно говоря, меня немного расстраивает то, что я слышу так много разговоров, но не вижу никаких действий со стороны моих товарищей по команде. Как новый парень, как я могу подтолкнуть их к действию, не взъерошивая перья? Я не хочу быть тем парнем .

Это не дубликат предложенного вопроса, потому что этот парень спрашивал , следует ли и как ему продвигать свои идеи. Это не мои идеи (хотя я с ними согласен, очевидно). Мой вопрос касается того, как заставить моих коллег действовать в соответствии с их словами .

Может показаться, что им просто нравится «идея тестирования и закрытых проверок», потому что они не хотят спорить об этом.
Что ты имеешь в виду @MarkRogers?
Они могут быть не в настроении или не иметь энергии, чтобы изменить то, как они работают, поэтому они просто поддерживают эту идею на словах, продолжая делать то, что они уже делали. Надеясь, что в конце концов кто-то другой поймет это за них или проблема исчезнет. Классический уклон.
Я не знаю @MarkRogers. Возможно, вы правы, но они, кажется, искренне заинтересованы в улучшении ситуации. Или, по крайней мере, они заинтересованы в том, чтобы поговорить об улучшении ситуации. Хм
Если они искренне заинтересованы, но ничего не происходит, это может быть потому, что никто не чувствует себя комфортно, беря инициативу в свои руки. Ты тот парень? Если да, составьте план и разместите его. Они поддержат вас и, возможно, будут благодарны за ваше лидерство. Если вы не желаете взять на себя инициативу, то немного лицемерно критиковать их за то, что они этого не делают, независимо от того, как долго длится ситуация. Смотрите на это как на возможность, а не как на проблему.
Всем, кто заинтересован, после сегодняшнего утреннего стендапа я предложил добавить колонку «Обзор» на нашу канбан-доску. Все согласились, что это хорошая идея, что мы и сделали, и я показал всем, как комментировать набор изменений. Как получится. Спасибо всем за отличные советы. Мне жаль, что я не буду ставить галочку, но я чувствовал, что все ответы были одинаково полезны.

Ответы (3)

Честно говоря, меня немного расстраивает то, что я слышу так много разговоров, но не вижу никаких действий со стороны моих товарищей по команде. Как новый парень, как я могу подтолкнуть их к действию, не взъерошивая перья? Я не хочу быть тем парнем.

Использование таких фраз, как «большой разговор» и «подтолкнуть их», действительно может сделать вас тем парнем , поэтому вы не хотите идти на это.

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

Если вы приняты, вы можете рассказать о том, что вы предлагаете, почему вы считаете это важным (надеюсь, не только потому, что вы считаете это «лучшей практикой», но больше о том, почему это принесет пользу команде/компании в их конкретном контексте) и как вы все можете приступить к реализации этих идей.

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

Вот в чем дело. Они знают преимущества, иначе не было бы столько разговоров об этом... Хотя пилотный проект - хорошая идея. Мне это нравится. Возможно, я смогу это сделать.
Знание того, что что-то будет улучшением, и желание воспользоваться этим, а также возможность найти ресурсы, необходимые для его принятия, часто являются очень разными вещами. Теоретически практика должна быть идентична теории; на практике это не всегда возможно, и когда это возможно, вам обычно приходится делать это постепенно.
Я получил случайный голос, который привлек мое внимание к этому. Я забыл обо всем этом до сих пор. Я просто хочу сказать спасибо. К тому времени, когда я ушел из этой компании, тестовый охват рос, и мы выпускали продукт 2-4 раза в неделю.

Остальной команде, кажется, нравится идея тестирования и закрытых проверок, но они не предприняли никаких действий, чтобы начать это делать.

Они действительно знают, как проводить модульное тестирование?

Если вы никогда не делали этого раньше, может быть не просто начать делать это. Особенно, если у вас есть многолетний опыт без тестирования.

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

Если это недостаток знаний, вы можете рассмотреть способы помочь с этим. Хороший способ — попросить кого-нибудь о помощи и заняться парным программированием при работе с кодом, который вы не понимаете (полностью). Вы можете обсудить, что вы делаете, и посмотреть, сможете ли вы написать тесты с другим человеком, объясняя, что вы делаете.

Обратите внимание, что видеть написанный тест (обзор кода) и знать, как подходить к написанию теста, не обязательно одно и то же.

Если это просто проблема «нам нравится говорить об этом и звучать модно, ничего не делая», вы можете попробовать, когда происходит такой разговор, предлагать или спрашивать об очень конкретных, практических вещах (а не просто сетовать на отсутствие проверки кода или модульного тестирования). , тоже):

  • «Мужик, я бы хотел, чтобы мы были более проворными».
  • «Ну, вы хотите просмотреть код друг друга? Сегодня днем ​​я свободен, и у меня есть коммит, который я делаю»
Они вполне могут не знать . Некоторое парное программирование может быть отличным курсом действий. Я не уверен, что сделал бы это для тестирования устаревшего кода, но, возможно, с небольшим количеством кода с нуля. Спасибо. Солидный совет.
Люди @ThatGuy, скорее всего, тоже не выйдут и не скажут этого. Сказать новому парню: «Эй, мы, более старшие люди, не знаем, как сделать что-то, что вы считаете базовым и чего хочет руководство», маловероятно. Устаревший код, с которым вы не знакомы, идеально подходит для этого, вы можете сказать что-то вроде: «Я надеюсь написать несколько тестов на унаследованном коде, и вы лучше знакомы с этой кодовой базой — вы можете мне помочь?» и снова, просто говорите о процессе, как вы это делаете. Людям обычно нравится лесть, и просьба о помощи — отличный способ заручиться поддержкой в ​​будущем.
Это довольно хороший аргумент. Дело принято.

Чтобы обзоры кода были практичными, вам нужна система, которая их упрощает. Например, как это делает GitHub с запросами на слияние или как GitLab с запросами на слияние. Я много слышал о Геррите, но не пользовался им. Установите один из них или аналогичный (сначала даже просто на свой компьютер), иначе это просто не будет практично.

Вот пример представления кода коллеге с помощью GitHub.

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

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

Процесс точно такой же с GitLab (бесплатный клон GitHub), но они называют запросы на слияние запросами на слияние. Я не знаю, с Герритом и другими, я думаю, что аналогичная функциональность существует.

Мы реализовали эту идею в двух командах за последние 3 года. Это самая популярная практика, которую мы внедрили. Ребята, которые этим занимаются, любят это делать и время от времени присылают мне запросы на слияние даже после того, как я перешел в другую команду. В своих новых командах я стараюсь распространять практику именно так, как описал выше.

Что касается модульного тестирования:

  • Получите работающую систему непрерывной сборки, которая выполняет модульные тесты как часть сборки.
  • Предложите коричневую речь за обедом, демонстрирующую примеры хороших модульных тестов и плохих модульных тестов. Поместите контент, который вы использовали, в общедоступный репозиторий.
  • Напишите хорошие модульные тесты и назначьте Merge Requests товарищу по команде, который, скорее всего, поддержит вашу идею.
  • Лоббируйте практику выполнения каждым (как минимум) одного модульного теста в неделю. Обязательно измеряйте и отслеживайте прогресс (я использую простой лист Excel).

Что касается улучшения качества кода:

  • Получите инструмент статического анализа, интегрированный в систему непрерывной сборки. Например, SonarQube.
  • Внесите исправления в проблемы, поднятые инструментом статического анализа, и назначьте запросы на слияние товарищу по команде, который, скорее всего, поддержит эту идею.
  • Предлагайте покупать книги, которые, как известно, являются хорошим ресурсом в вашей области, пусть они лежат на вашем столе и поощряйте других брать и брать их в любое время.
  • Лоббируйте практику внедрения каждым (как минимум) одного исправления проблем, поднятых инструментом статического анализа, в неделю. Обязательно измеряйте и отслеживайте прогресс (я использую простой лист Excel).

Обратите внимание на общий шаблон в обоих приведенных выше примерах:

  1. Получите настройку инструмента, которая поможет эффективно достигать ваших целей
  2. Используйте код-ревью как способ показать пример
  3. Подготовьте дополнительные вспомогательные материалы
  4. Лоббируйте внедрение улучшений небольшими управляемыми шагами

Все эти идеи — настолько маленькие и простые постепенные изменения, что их очень легко продать.

Настройте и используйте вариант, адаптированный к вашей среде.

Спасибо за это. Я больше убежден, что если это произойдет, мне придется учить этому. Это определенно поможет.
Как новичку, как мне заставить людей действовать в соответствии со всеми их громкими разговорами?
СпросиСетьПолитика конфиденциальности1y, 0v