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

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

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

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

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

Благодаря всему этому в производственном цикле появляется «лишняя» стадия. А это вновь крайне отрицательно сказывается на показателе Time to market.

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

Вернемся к предыдущему примеру. Чтобы сформировать техзадание, IOS-разработчику нужно в среднем 2 часа. А вот бэкенд-программисту потребуется уже в среднем 16 часов на реализацию данного задания.

Что будет делать IOS-разработчик, пока не готов бэкенд? По сути, просто ждать. Конечно же, в реальности он займется другими задачами, но если мы говорим о решении конкретной проблемы (например, рассматриваемая нами задача настолько приоритетная, что руководители выделили людей исключительно под ее решение, освободив от других), то получается, что IOS-разработчик бо́льшую часть времени никак не способствует решению той задачи, под которую его, собственно, выделили. Он вынужден ждать, пока бэкенд будет готов.

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

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

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

Это вновь нерешаемая с точки зрения традиционного способа организации трудового процесса проблема. Не будем же мы обновлять мобильное приложение дважды в день, как только у нас появится очередная «заплатка».