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