Вместо введения

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

Сразу стоит сделать оговорку, что будет в этой статье, а чего в статье не будет. В статье не будет описания архитектурных решений и описаний с обоснованием этих решений. Мы не будем фокусироваться и на стеке технологий, на котором мы создавали микросервисы.

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

Эта статья будет первой из многих. И ее цель в первую очередь – ввести в нашу проблематику в контексте перехода на микросервисную архитектуру и плавно подвести к следующим темам, подробно раскрывающим отдельные аспекты перехода.

От автора перевода

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

1. Мы никогда не сможем взять в работу все проекты, которые хотелось бы.
2. Нужно научиться правильно их выбирать.

В прошлом, когда я был молодым менеджером продукта, один из моих руководителей в корне изменил мою карьеру. Шел второй год моей работы в Airbnb. Я справлялся со своими обязанностями, но не более. Мой новый руководитель Влад Локтев обратил внимание, что завершение проекта, который я вел, откладывалось на недели. Он не был удивлен, помог вернуть проект в нужное русло и завершить его. Но я знал, что на очередной аттестации мне припомнят эту ошибку. Когда пришло время, я действительно получил далеко не блестящие оценки. Влад обозначил мои точки роста, в том числе рекомендовал сфокусироваться на коммуникациях, направленных на контроль статусов задач, и их жесткой приоритизации. После этого разговора я мог бы выйти подавленным. Но вместо этого, наоборот, я почувствовал небывалый эмоциональный подъем и желание действовать – мне стало ясно, что нужно делать.

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

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