Миллион за миллионом. Инвестиции. Принципы. Богатство

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

Но вернемся к нашей истории. Типовая производственная задача для компании, о которой я рассказываю, выглядела как разработка и внедрение новой фичи для потребителей в программное обеспечение сервиса.

Топ-менеджеры очень быстро поняли, что фактически над каждой конкретной мини-задачей работают самое меньшее три специалиста, каждый из которых относится к своим отделам. Но все они сидят в разных местах и практически не общаются между собой.

Ключевой характеристикой для работы каждого бизнеса является показатель Time to market. В целом данная характеристика демонстрирует, насколько быстро компания воплощает свои идеи, замыслы, насколько она является гибкой и мобильной.

В реальности Time to market практически всегда далек от идеального. Происходит это по нескольким причинам.

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

Например, если мы берем тестировщика, он сначала должен завершить тестирование одной разработки, а затем перейти к следующей, протестировать ее, перейти к третьей и т.

д.

Таким образом, когда конкретная доработка уже готова, она некоторое время ждет, пока тестировщик завершит активности по другим задачам. Иначе говоря, уже на стадии тестирования у нас будут накапливаться разрывы, а Time to market – увеличиваться за счет этого.

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

На это тоже нужно время.

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

В описываемой компании это происходило следующим образом: разработчик IOS ставил задачу бэкендеру, в которой он полностью описывал всю логику, формат данных и т. д.