Меня зовут Станислав Тюленев, я ведущий инженер-разработчик в одной из продуктовых команд Domclick. В статье я расскажу о том, как новичку в команде не бояться говорить о своих проблемах или идеях, и при чем тут «техсоветы».
Contents
Предисловие
Поработав несколько месяцев в новой команде и ознакомившись со всеми используемыми там инструментами и практиками, наступает момент, когда проходит первоначальная эйфория и вы критически переосмысливаете выстроенные процессы.
Так было и со мной. Я стал замечать все больше и больше вещей, которые меня раздражали, огорчали или просто не выглядели оптимальными. При этом я понимал, что это мое субъективное личное мнение, так как это не повлияло напрямую на производительность системы. Но у нас не было времени и места, где мы могли бы говорить о ране. Во время утренних митингов казалось неуместным их высказывать, а уж тем более при планировании спринта с техническим лидом и владельцем продукта (PO).
Это усугублялось тем, что как новый член команды я не хотел прослыть выскочкой и как-то критиковать сложившиеся устои.
Далее я рассмотрю только три аспекта из тех, в которых видел проблемы. Почему именно каждый из них заставил меня страдать, расскажу вкратце. Но только по своим ощущениям, намеренно опуская техническую часть.
-
Журналы событий и ошибок, которые месяцами живут и накапливаются в Sentry. Как и в процессе чтения всех сообщений Telegram, здесь меня угнетало чувство незавершенности.
-
Примечания в запросах на слияние на основе формата кода. С отзывом согласен, но вкус терпеть не могу. Без настроенных в проекте трейнеров считаю эти комментарии пустой тратой времени и нервов. Все, что можно сделать автоматически должно выполняться автоматически.
-
Желание использовать Pydantic вместо Marshmallow. Написание логики с использованием данных в словарях было мучением. Я предпочитаю IntelliSense на основе классов.
Время действовать
Находясь в таком положении, считая себя на правах птицы, я видел три вопроса, которые, на мой взгляд, должны были быть предприняты по очереди:
-
Смиритесь, так как это не критично влияет на производительность системы, ловите дзен и отдавайтесь течению.
-
Обратитесь за поддержкой к большинству разработчиков и выявите проблемы с вашим непосредственным наставником или руководителем и надейтесь, что они решат все в административном порядке.
-
Начните публичное обсуждение проблем и попытайтесь решить их самостоятельно.
К счастью или нет, смириться мне не удалось. Поддержки среди простых коллег я не нашел. Все были увлечены решением бизнес-задач, и только у меня было свободное время, чтобы жаловаться, так как опыт не очень доверял мне задачи. В личных беседах, возможно из-за суматохи, все предложения встречались сухо. Я должен был быть активным.
Собравшись с духом, я должен был пойти к бригадиру с покаянием.
Совет — заранее подготовьте список своих проблем, чтобы не вспоминать о них на ходу. Перечислите возможные решения.
По первому вопросу долгой дискуссии не было. Мы быстро пришли к компромиссу, что ситуацию проще разрешить. Хуже точно не будет. Осталось обсудить детали.
По второму и третьему вопросам я сразу сказал, что никакого предварительного компромисса с командой найдено не было, каждый думал по-своему.
Технические консультации
я предложил “технический совет”где каждый может высказаться «за» или «против», и поэтому мы примем демократический согласованное решение. Справедливости ради нужно отметить, что в целом в коллективе царила дружеская атмосфера. Получить коммерческую поддержку в лице ПО не составило труда. Остается только организовать и провести первую встречу.
Я провел отдельный чат в Telegram, попросил PO организовать часовую встречу для всех разработчиков, техлида и тимлида, а также приложил список всех моих вопросов. Пришлось самой проводить первую встречу. Удивительно, но в виде живого чата с командой мне все же удалось убедить большинство в этом. что предлагаемые решения проблем принесут нам пользу. Возможно, сказалось то, что все были готовы к этому разговору, так как встреча была запланирована заранее. В конце встречи мы закрыли почти половину всех изначально обозначенных тем.
Для упомянутых выше проблем были приняты следующие решения:
-
Мы просмотрели все ошибки в Sentry и сразу же выявили устаревшие и неразобранные ошибки (и журналы уровней ошибок). Пазлы разбросаны по распиловочным журналам. Действительно, мы нашли несколько багов, которые внезапно сработали давно, но все же остались в коде продукта. Мы договорились повторять эти действия раз в месяц. Обсуждение и принятие стандарта того, что мы должны регистрировать по ошибке, а что нет.
-
Мы запустили задачу по поиску, подбору и настройке конкретного трейнера в проекте. Впоследствии я сделал кое-какую предкоммиттерную начинку и накрутил проверки формата кода на этапе сборки в CI/CD.
-
Подтверждено, что в новом коде я буду использовать Pydantic в пробном режиме. А на следующем техническом совещании, после показа примеров, мы вместе решим, использовать его дальше или нет.
Что произошло дальше
А потом оказалось, что не только у меня есть вопросы, которые хотелось бы обсудить. Формат этих встреч оказался полезным и стал запланированным еженедельным мероприятием. Они оживили дискуссию и мало кого оставили равнодушными. Сегодня на встречах мы не только рассказываем о своих болях, но и обсуждаем наилучшие возможные решения, связанные с технической частью нашего продукта. Темы для обсуждения может предлагать любой участник, голосовать тоже.
выводы
Помимо очевидных преимуществ открытой системы технических предложений в коллективе, «технический совет» имеет и второстепенные преимущества:
-
Улучшить общую позитивную атмосферу процесса разработки.
-
Улучшить коммуникацию внутри команды.
-
Повышайте уровень знаний и навыков каждого члена команды.
-
Повысить вовлеченность каждого члена команды в разработку технических стандартов.
Вместе все баллы дают улучшить качество продуктов, разработанных ИТ-командой. При таком подходе каждый голос будет услышан.
После шести встреч мы стали проводить их реже, потому что к тому времени все наболевшие вопросы были решены. Теперь мы встречаемся каждые две недели. И чаще всего на них мы обсуждаем и планируем технический долг, на который официально отводится 20% времени. Вот так у меня теперь есть определенное время в моем расписании, когда я могу сказать все, что думаю, и ничего не получить взамен. Сейчас я не представляю, как можно по-другому решить эти проблемы. Но могу с уверенностью сказать, что этих встреч мне было мало на прежних работах.
Инструкция
Друзья, не скрывайте недостатки проекта, даже если считаете его только недостатком. Возьмите инициативу в свои руки и мир вокруг вас станет лучше.
PS Я благодарю свою команду за то, что они приняли меня, как если бы они были моими.
