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

На самом деле ее существование прекратилось из-за банального – из-за бизнеса. Все дело в деньгах. Просто настал период оптимизации, и так как System Team не занималась непосредственно реализацией бизнес фичей как таковых, (занималась, но объем их был невелик) поэтому тима была оптимизирована. Ребят раскидали по другим командам, либо на другие проекты внутри компании. Ну и остался я, собственно, один, как основатель и идейный вдохновитель новой “идеологии” на проекте;) А в целом-то работы еще было много, и если бы не оптимизация, то работали бы мы еще долго и интересно.

На самом деле, я сейчас вспоминаю, как это было в течение года - это было прикольное время, на самом деле, интересный опыт.

Кстати говоря, за то продолжительное время, что я непосредственно не писал код, на самом деле немного писал, особенно на старте существования System Team, ребята даже шутили в команде, что пришел Паша со своим PR-ом и протер пыль на каком-то сервисе;) Код не писал, да, но мне приходилось предлагать идеи, что и как можно сделать, и причем они (идеи) должны были быть рабочими;) Где какой-то, например, клауд-ресурс использовать для решения той или иной задачи и т.д. То есть в виду наличия опыта мне приходили какие-то идеи, но конкретной реализацией я не занимался.

Так вот за этот период я до совершенства отточил навык делегирования;) И сейчас, когда у меня уже нету своей команды, и всё надо делать самому, приходится перестраиваться, потому что немного отвык.

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