Читать книгу Миллион за миллионом. Инвестиции. Принципы. Богатство - Алексей Чаликов - Страница 10

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 для своих задач.

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

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

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

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

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

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

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

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

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

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

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

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

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

II

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

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

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

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

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

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

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

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

2) шторм;

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

4) работа;

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

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

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

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

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

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

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

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

Эта проблема не новая. Бертран Рассел, философ, математик, лауреат Нобелевской премии, больше 100 лет назад сказал: «Проблема этого мира в том, что глупцы и фанатики слишком уверены в себе, а умные люди полны сомнений».

Многие со мной согласятся, что в каждой команде найдется хотя бы один человек, который всегда против, у него есть свое мнение, он знает, как надо, и всем оппонирует: «Мой метод лучше! Я это точно знаю». Но при этом оказывается, что реального опыта у него нет. О чем-то он прочитал в книжке, что-то посмотрел в интернете и пр.

В чем основы подобного поведения?

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

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

Что же делать, если человека с токсичным поведением не удается быстро вывести из команды? Бесполезно в чем-то убеждать данного специалиста и давать обратную связь – такие люди ее не воспринимают! Выход только один: грузить задачами и требовать результата. Задачи для носителя токсичности должны быть на пределе его возможностей. Только так возможно минимизировать его негативное воздействие и даже превратить в хорошую часть команды.

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

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

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

III

Многие из нас помнят старую бюрократическую мудрость: «Любое серьезное организационное изменение – это гарантированный геморрой при негарантированном результате». Может, и не стоит пытаться работать по-другому? Может, стоит работать как все?

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

Зачем это все менять? Жили же как-то наши предки с такой рабочей культурой, и мы проживем…

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

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

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

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

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

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

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

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

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

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

И для эффективного решения как раз таких задач нам и нужны кросс-функциональные команды.

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