Часть 1. Разочарование от нового проекта и фундамент для перемен
Часть 2. Выделенная команда и первый сервис по новому стандарту
Часть 3. Разбиение монолита по DDD
Часть 4. Создание шаблона микросервиса
Часть 5. Свой подход к интеграционным тестам
Часть 6. Что дало создание шаблона
Часть 7. Распиливание, миграции и оптимизации
Часть 8. Добровольный боттлнек, коммуникации и овертаймы за свой счет
➡️ Часть 9. Что нужно, чтобы драйвить такие перемены и оставить бизнес довольным
Часть 10. Почему распустили System Team и что в итоге?

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

Как я говорил, была маленькая ложка дегтя в виде какого-то “360”. Ну, это тоже опыт прикольный. И мне пришлось где-то еще больше улучшить свою риторику. Где-то я понял, что, например, люди могут агриться. В общем, учился. Учился даже на этих ошибках.

Буквально к каждому нужно было находить свой подход. Да, это занимает много времени, иногда много нервов. Но, наверное, иначе это было бы сложно. Можно было бы заходить через Team Lead-ов, например, или только с ними общаться. Но я не уверен, что это был правильный подход конкретно здесь. Да и в целом общаться здесь через Lead-ов не всегда возможно было, потому что они часто были на “тушении пожаров” от заказчика, и у них просто не было времени. Поэтому, как я и говорил, я искал другие точки опоры, общался не только с ними.

Мы придумали с нашим TPO такое понятие как Technical Assessment Tag. И если после первичного обсуждения Epics, Features, Technical Stories и даже User Stories с заказчиком мы принимали решение на эти PBIs вешать такой tag, то когда эти PBIs доходили на рефайнмент в команды, TPO и я в обязательном порядке приходили на такие миты и обсуждали с командами, что мы с этим будем делать. Если напрашивался новый сабдомен – мы старались его выделять.

Если на дизайн такого сабдомена объективно уходило бы много времени и мы видели, что у нас состояние цейтнота, и заказчик хочет, чтобы все было сделано еще вчера, то иногда даже новые фичи делались на старой кодовой базе. Но с обязательной TODO пометкой – перенести, как только появится возможность.

В основном, триггером этого тега был TPO, он присутствовал на всех митах с заказчиком. Я с заказчиком лично даже не общался, он на себя брал эту роль. И когда обсуждались эти фичи, он, присутствуя на этих митах с заказчиком, говорил, цеплять тег на этот или тот PBI. Когда эти PBI приходили в backlog команд, тимлид или Product Owner, формируя бэклог на рефаймент, видели эти теги и, соответственно, добавляли меня на мит.

Этот тег цеплялся в нескольких ситуациях – либо когда он видит, что, скорее всего, тут надо выделять сервис, либо когда он видит, что в рамках реализации этой фичи какая-то сложная коммуникация между другими сервисами. Надо, например, посоздавать какие-то очереди, топики, надо где-то какой-то Blob Storage завести, то есть напрашивается что-то нетривиальное. Он это примерно видит, так как он не просто PO, а Technical PO, т.е. человек с достаточным техническим бэкграундом.

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

Бизнес тоже состоит из разных уровней. Есть такой high-level бизнес, которому вообще все равно что там делать, главное, чтобы было сделано и желательно побыстрее. А есть тот бизнес, который Product Owner, то есть условный медиатор между заказчиком и нами. Вот с этим уровнем и можно договариваться.

Мы ему говорим, что здесь надо нам с ребятами обсудить архитектуру и так далее. В целом он всегда соглашался. Не было такого, когда он сказал бы, не-не, какое еще техническое обсуждение, нам такого не надо.

Вот high-level бизнес (заказчик) иногда выкидывает такие интересные моменты, типа, что вы там мучаетесь, возьмите да сделайте. Что вы там занимаетесь ерундой. Вот уже в такие моменты приходится как-то лавировать и что-то придумывать.

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

Ну, я не знаю, я вот лично себя не вижу каким-то 47-летним кодером, честно. Именно что кодером. Хотя, опять-таки, всякое может быть. Вот, например, в Штатах как раз-таки именно такие кодеры и есть. У меня недавно знакомый там решил работу найти, переехал в Штаты. Пошел на собес. Его пришли собеседовать два дедушки. Один FE-девелопер, второй BE-девелопер. Реально два дедушки, он мне скинул скрин с мита, один седой вообще полностью. У них это так работает.

Но у нас, на нашем рынке, я не знаю, как это работает. Я не видел таких разработчиков. 40 с чем-то видел, да, но 50 и выше.... Ну, в любом случае здесь каждый для себя будет делать какой-то выбор.

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

Наверное поэтому я и оказался на курсах (Технический Лидер), потому что в какой-то момент для себя понял, что кодить бесконечно не буду, и надо развиваться немного с другой стороны. Вот даже сейчас, например, у меня команды нет, хотя я только за, чтобы она была. Сейчас у меня позиция уже не Team Lead, а так называемый BE Owner. Сам себе такой single warrior. То есть человек, который может прийти в какую-то команду, постучать по столу, и попросить сделать не так, а вот так, например. Слежу за техническим состоянием бэкенда на проекте.

И, кстати, за фронтендом тоже. Учитывая, что я Fullstack-девелопер в прошлом, иногда приходится встряхивать фронтенд-гильдию немножко. Если за BE, скажем так, взялись достаточно крепко за наведение порядка, то на стороне FE немного не так. И с этим надо тоже что-то делать. В итоге мы даже придумали новую позицию для этого, для наведения порядка - FE Owner. И я ему уже потом рассказывал какие проблемы неплохо бы решить, с моей точки зрения. Также он предложил свой список проблем для решения.

Например, в то время, когда была инкорпорация нового сервиса аутентификации, на стороне FE тоже было много работы. Я за этим не следил, потому что у меня очевидно хватало работы на стороне BE. И вот, как оказалось, реализация на FE была абсолютно разной на трех FE приложениях. Разные языки, разные библиотеки, отсутствие общих npm пакетов и т.д. Это не совсем хорошо. И собственно приведение аутентификации на стороне FE к какому-то унифицированному виду было первой задачей для FE Owner-а.

Мы уже на финишной прямой – осталась только одна часть. В ней вы узнаете, почему распустили System Team и к каким результатам привела инициатива Павла.