И вот допустим у нас опять ситуация когда мы ждем Frontend. Что в это время делать остальным платформам? А ничего! Сходить погулять, попить кофе, заняться рефакторигом вон того класса, а то чет неудобно. Еще хорошо бы тестами вот этот функционал покрыть.
Другими словами, мы занимаемся менее важными вещами, от которых можно быстро вернуться к важной и единственной задаче. Мы не берем новую бизнес задачу, пока Frontend не закончит. Удивительно, но в таком случае скорость поставки возрастает в разы. Именно в этом идея объединения в одну команду фронтов и мобильщиков, даже несмотря на то, что у них фундаментально разные подходы.
Про этот феномен очень круто и понятным языком написано в книге “Цель, процесс непрерывного улучшения”. Везде ее рекомендуют как must have литература, кто в будущем хочет стать тимлидом. На самом деле ее можно прочитать даже если и не планируете. Она написана как история директора завода которому нужно спасти
Очень интересная история. И для меня там было две основных идеи. Первая – 100% загруженность разработчиков не значит максимальная продуктивность, а скорее наоборот двигаться будете в итоге медленнее. Страшная идея для тех, кто на аутсорсе. Вторая – компания двигается со скоростью самого медленного звена. Это значит от того, что вы сегодня не доработали один час изменится примерно нихрена.
Поэтому когда устраиваетесь в продуктовую компанию, спрашивайте как происходит разделение на команды. Чаще всего если менеджеры действительно знают свое дело, они будут объединять людей по фича командам. Для меня это индикатор, что в компании ориентируются на результат, нежели на загруженность разработчиков.
Опять-таки, это если мы говорим про большую компанию. Если в мелких нет такого разделения, то это ок)