Миллион за миллионом. Инвестиции. Принципы. Богатство - стр. 56
Вернемся к предыдущему примеру. Чтобы сформировать техзадание, IOS-разработчику нужно в среднем 2 часа. А вот бэкенд-программисту потребуется уже в среднем 16 часов на реализацию данного задания.
Что будет делать IOS-разработчик, пока не готов бэкенд? По сути, просто ждать. Конечно же, в реальности он займется другими задачами, но если мы говорим о решении конкретной проблемы (например, рассматриваемая нами задача настолько приоритетная, что руководители выделили людей исключительно под ее решение, освободив от других), то получается, что IOS-разработчик бо́льшую часть времени никак не способствует решению той задачи, под которую его, собственно, выделили. Он вынужден ждать, пока бэкенд будет готов.
Таким образом, при классическом способе организации труда у нас неизбежно появляются люди, которые просто ждут готовности других частей задачи и в это время никак не способствуют ее решению.
Помимо изложенного, в описываемой мною компании существовала еще одна проблема, которую условно можно назвать «планирование релиза». Это когда собиралась группа специалистов из разных отделов и составляла некий список задач, которые должны попасть в следующую версию программы.
В результате, пока все задачи из указанного списка не были завершены, новая версия программного обеспечения не выходила. Таким образом, Time to market даже самой маленькой и простой входящей в список задачки становился равен Time to market самой долгой и сложной фичи.
Это вновь нерешаемая с точки зрения традиционного способа организации трудового процесса проблема. Не будем же мы обновлять мобильное приложение дважды в день, как только у нас появится очередная «заплатка».
Однажды руководство компании, осознав все указанные проблемы и поняв, что это резко негативно сказывается на качестве их продукта, решило найти способ существенно ускорить Time to market для своих задач.
Самым простым решением была отмена процесса релизного планирования. Вместо нее была внедрена система, аналогичная существующей у Spotify, которая получила название «релизный поезд». При такой системе обновления программного обеспечения выходят по регулярному расписанию (например, один раз в две недели). В каждый новый релиз попадают только те обновления, которые полностью готовы к его дате. Таким образом, отсутствует обязательный план и никому не нужно ждать других.
Далее компания решилась на более глубокие изменения в организации процесса своего функционирования. От устройства работы на основе функциональных подразделений она перешла к работе юнитами.
Юнит – это, по сути, команда, которая обладает всеми необходимыми навыками и ресурсами для решения поставленных перед ней задач.
Например, внутри организации были созданы такие юниты, как «Доставка» и «Мессенджер». Соответственно, указанные команды полностью отвечали за соответствующие направления работы на всех платформах и могли сделать все возможное для их развития. Получилось что-то вроде стартапов внутри большой компании.
Это позволило «пофиксить» ранее описанную проблему низкопродуктивного общения между отделами. Члены каждого юнита теперь сидели вместе и общались между собой на постоянной основе. Соответственно, ответ на любой вопрос можно было получить моментально, а качество коммуникации резко возросло.