Миллион за миллионом. Инвестиции. Принципы. Богатство. Алексей Чаликов
Читать онлайн книгу.
специалистов по изолированным группам?
Но вернемся к нашей истории. Типовая производственная задача для компании, о которой я рассказываю, выглядела как разработка и внедрение новой фичи для потребителей в программное обеспечение сервиса. Топ-менеджеры очень быстро поняли, что фактически над каждой конкретной мини-задачей работают самое меньшее три специалиста, каждый из которых относится к своим отделам. Но все они сидят в разных местах и практически не общаются между собой.
Ключевой характеристикой для работы каждого бизнеса является показатель Time to market. В целом данная характеристика демонстрирует, насколько быстро компания воплощает свои идеи, замыслы, насколько она является гибкой и мобильной.
В реальности Time to market практически всегда далек от идеального. Происходит это по нескольким причинам.
Во-первых, при организации работы компании по отделам у каждого специалиста в условной группе, который принимает участие в работе над конкретной задачей, на самом деле очередь из задач.
Например, если мы берем тестировщика, он сначала должен завершить тестирование одной разработки, а затем перейти к следующей, протестировать ее, перейти к третьей и т. д.
Таким образом, когда конкретная доработка уже готова, она некоторое время ждет, пока тестировщик завершит активности по другим задачам. Иначе говоря, уже на стадии тестирования у нас будут накапливаться разрывы, а Time to market – увеличиваться за счет этого.
Во-вторых, самому тестировщику при подобной организации работы может быть непросто. Ему приходится каждый раз переключать контекст, то есть, переходя к новому тестированию, предварительно «въезжать», о чем вообще идет речь, с какой проблемой сталкивались пользователи и что было сделано, чтобы решить эту проблему. На это тоже нужно время.
В-третьих, при классической организации работы совсем не идеальным образом будет строиться и общение специалистов из разных отделов, задействованных в конкретной задаче.
В описываемой компании это происходило следующим образом: разработчик IOS ставил задачу бэкендеру, в которой он полностью описывал всю логику, формат данных и т. д. Бэкендер читал указанное задание, делал его так, как понял, и передавал в тестирование.
Однако мы прекрасно понимаем, что описание чего-либо просто по своему определению не бывает полным. Всегда будет то, что можно понять двояко, а можно не понять совсем. И когда задача доходит до тестирования, неизбежно возникает большое количество дополнительных вопросов. Указанные вопросы тестировщик адресует IOS-разработчику, который уточняет свое техзадание, вновь передает его бэкендеру, тот вносит изменения и опять передает результат разработчику с учетом его предыдущих замечаний.
Благодаря всему этому в производственном цикле появляется «лишняя» стадия. А это вновь крайне отрицательно сказывается на показателе Time to market.
Однако и это еще не все негативные моменты классического подхода к организации рабочего процесса. Совершенно понятно, что любая задача состоит