Алексей Чаликов – Миллион за миллионом. Инвестиции. Принципы. Богатство (страница 21)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее компания решилась на более глубокие изменения в организации процесса своего функционирования. От устройства работы на основе функциональных подразделений она перешла к работе юнитами.

Юнит – это, по сути, команда, которая обладает всеми необходимыми навыками и ресурсами для решения поставленных перед ней задач.

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

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

Однако у такого подхода к организации рабочего процесса были и свои минусы. Прежде всего это низкий bus factor.

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

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

Кросс-функциональный специалист – это работник, который является экспертом по какому-то конкретному направлению (как и обычный работник), но дополнительно обладает еще и широким набором прочих навыков.

Полная взаимозаменяемость – модель утопичная. Но высокая степень взаимозаменяемости достигается в подобных командах как бы сама собой.

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

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

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

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

Развить такие компетенции – задача действительно непростая. И главный враг на пути к этой цели – такое явление, как токсичность, о котором нам также придется обязательно поговорить.

Наверняка многие слышали известную фразу руководителя Netflix Рида Хастингса: «Не терпите великолепных придурков – цена для работы команды слишком высока».

Я, разумеется, не буду оспаривать утверждение, что токсичному человеку не место в команде. Однако как научиться различать, когда человек ведет команду к результату и требователен к себе и окружающим, а когда он попросту создает диссонанс и занимается разрушением?

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

Что такое вообще команда? Я считаю, что командой является группа лиц, объединенная общими ценностями, целями, ресурсами и осуществляющая деятельность на основе разделенных функций.

Известный американский психолог Брюс Такман выделил следующие фазы жизни любой команды:

1) формирование;

2) шторм;

3) нормализация;

4) работа;

5) расформирование.

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

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

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