– Опыт – это ловушка. Если в своей жизни опираться исключительно на привычки, опыт и традиции, то это приведет к топтанию на месте и разочарованию. Человечество движется вперед. Беда в том, что те самые топчущиеся на месте не двигаются вместе с нашей цивилизацией, а потому очень быстро оказываются на ее отшибе.
– Когда мы считаем, что в чем-то очень хорошо разбираемся, мы подспудно начинаем верить в то, что в «изученной» нами сфере не могут произойти события, не укладывающиеся в границы известного нам.
– Именно в этом и состоит суть стереотипного мышления и ограниченного взгляда на жизнь. И рано или поздно это оставит человека в дураках, несмотря на все его былые заслуги. Рано или поздно наш опыт придет в противоречие с объективной реальностью. И если мы будем продолжать держаться за известное и искать все ответы на новые вызовы в своем прошлом, то очень быстро проиграем.
– «Брось заниматься ерундой и учи английский!» – совет, который я дал бы себе 20-летнему. И этот совет актуален для всех вне зависимости от возраста.
Глава 7
Кросс-функциональность, или Почему важно быть «расческой»
I
Давайте поговорим о нашей мотивации и эффективности. Что нас вообще может мотивировать в какой-то профессиональной деятельности? Безусловно, существуют такие универсальные мотиваторы, как получение денег, достижение личных целей, карьерный рост и пр. Это понятно, верно практически для всех людей и лежит, что называется, на поверхности.
Однако если задуматься, то и сама наша работа, наша деятельность также является мощным мотиватором. Любой работник, любой профессионал стремится принести пользу. Ровно так же каждый из нас будет испытывать гордость, когда сможет указать на что-то со словами: «Смотрите, это сделал я, и оно отлично работает!»
Проблема в том, что подобная положительная мотивация не всегда превращается в эффективность.
Когда-то разработчики одной широко известной в нашей стране интернет-платформы были сгруппированы по отделам. IOS-разработчики, backend-разработчики, Android-разработчики, QA-специалисты и другие – все они сидели в разных местах офиса и мало общались друг с другом.
Подобный подход к организации рабочего процесса следует считать традиционным. Действительно, у большинства работодателей принято объединять специалистов, выполняющих какую-то определенную функцию, в отдел. В результате в компании работают несколько изолированных друг от друга отделов, каждый из которых отвечает за определенное направление деятельности.
Но если посмотреть на типовую производственную задачу, можно легко увидеть, что эффективность ее выполнения будет зависеть от работы различных отделов и от их умения взаимодействовать друг с другом. Однако можем ли мы ожидать какого-то эффективного взаимодействия, если сами взяли и разделили специалистов по изолированным группам?
Но вернемся к нашей истории. Типовая производственная задача для компании, о которой я рассказываю, выглядела как разработка и внедрение новой фичи для потребителей в программное обеспечение сервиса. Топ-менеджеры очень быстро поняли, что фактически над каждой конкретной мини-задачей работают самое меньшее три специалиста, каждый из которых относится к своим отделам. Но все они сидят в разных местах и практически не общаются между собой.
Ключевой характеристикой для работы каждого бизнеса является показатель Time to market. В целом данная характеристика демонстрирует, насколько быстро компания воплощает свои идеи, замыслы, насколько она является гибкой и мобильной.
В реальности Time to market практически всегда далек от идеального. Происходит это по нескольким причинам.
Во-первых, при организации работы компании по отделам у каждого специалиста в условной группе, который принимает участие в работе над конкретной задачей, на самом деле очередь из задач.
Например, если мы берем тестировщика, он сначала должен завершить тестирование одной разработки, а затем перейти к следующей, протестировать ее, перейти к третьей и т. д.
Таким образом, когда конкретная доработка уже готова, она некоторое время ждет, пока тестировщик завершит активности по другим задачам. Иначе говоря, уже на стадии тестирования у нас будут накапливаться разрывы, а Time to market – увеличиваться за счет этого.
Во-вторых, самому тестировщику при подобной организации работы может быть непросто. Ему приходится каждый раз переключать контекст, то есть, переходя к новому тестированию, предварительно «въезжать», о чем вообще идет речь, с какой проблемой сталкивались пользователи и что было сделано, чтобы решить эту проблему. На это тоже нужно время.
В-третьих, при классической организации работы совсем не идеальным образом будет строиться и общение специалистов из разных отделов, задействованных в конкретной задаче.
В описываемой компании это происходило следующим образом: разработчик IOS ставил задачу бэкендеру, в которой он полностью описывал всю логику, формат данных и т. д. Бэкендер читал указанное задание, делал его так, как понял, и передавал в тестирование.
Однако мы прекрасно понимаем, что описание чего-либо просто по своему определению не бывает полным. Всегда будет то, что можно понять двояко, а можно не понять совсем. И когда задача доходит до тестирования, неизбежно возникает большое количество дополнительных вопросов. Указанные вопросы тестировщик адресует IOS-разработчику, который уточняет свое техзадание, вновь передает его бэкендеру, тот вносит изменения и опять передает результат разработчику с учетом его предыдущих замечаний.
Благодаря всему этому в производственном цикле появляется «лишняя» стадия. А это вновь крайне отрицательно сказывается на показателе Time to market.
Однако и это еще не все негативные моменты классического подхода к организации рабочего процесса. Совершенно понятно, что любая задача состоит как бы из нескольких частей и все эти части имеют различную продолжительность.
Вернемся к предыдущему примеру. Чтобы сформировать техзадание, IOS-разработчику нужно в среднем 2 часа. А вот бэкенд-программисту потребуется уже в среднем 16 часов на реализацию данного задания.
Что будет делать IOS-разработчик, пока не готов бэкенд? По сути, просто ждать. Конечно же, в реальности он займется другими задачами, но если мы говорим о решении конкретной проблемы (например, рассматриваемая нами задача настолько приоритетная, что руководители выделили людей исключительно под ее решение, освободив от других), то получается, что IOS-разработчик бо́льшую часть времени никак не способствует решению той задачи, под которую его, собственно, выделили. Он вынужден ждать, пока бэкенд будет готов.
Таким образом, при классическом способе организации труда у нас неизбежно появляются люди, которые просто ждут готовности других частей задачи и в это время никак не способствуют ее решению.
Помимо изложенного, в описываемой мною компании существовала еще одна проблема, которую условно можно назвать «планирование релиза». Это когда собиралась группа специалистов из разных отделов и составляла некий список задач, которые должны попасть в следующую версию программы.
В результате, пока все задачи из указанного списка не были завершены, новая версия программного обеспечения не выходила. Таким образом, Time to market даже самой маленькой и простой входящей в список задачки становился равен Time to market самой долгой и сложной фичи.
Это вновь нерешаемая с точки зрения традиционного способа организации трудового процесса проблема. Не будем же мы обновлять мобильное приложение дважды в день, как только у нас появится очередная «заплатка».
Однажды руководство компании, осознав все указанные проблемы и поняв, что это резко негативно сказывается на качестве их продукта, решило найти способ существенно ускорить Time to market для своих задач.
