[ЗВУК] [МУЗЫКА] В прошлой лекции Степа рассказал вам про контроль результатов команды и про способы этого контроля, такие, как, например, демонстрация продукта. А в этой лекции мы с вами поговорим про контроль процессов. Зачем вообще контролировать процессы? Почему недостаточно контролировать только результат? Мы поговорим, как их можно контролировать, а также познакомимся с картами Шухарта и с различными метриками. Итак, допустим у вас, у вашей команды получился какой-то неплохой результат. Вы довольны, руководство довольно, и команда даже довольна. Но ваша же задача в том, чтобы этот процесс успеха, он был цикличным. То есть как гарантировать, что в следующий раз-то у вас все получится на самом деле? И здесь есть замечательная книжка, которая называется «Дао Toyota: 14 принципов менеджмента». И я всем рекомендую, эта книга уже стала классикой по менеджменту. И там есть потрясающая фраза. Она говорит о том, что правильный процесс на самом деле дает правильные результаты, и что Toyota — это компания, ориентированная на процесс. Ребята из Toyota считают, что на самом деле вам беспокоиться нужно не про результат, вам беспокоиться нужно про процесс. И в первую очередь [НЕРАЗБОРЧИВО] контролировать ваши процессы, а они, собственно, сами по себе уже принесут вам результаты. Итак, есть такая замечательная штука, и называется она Value chain mapping — это отображение цепочки создания стоимости. Это некоторый процесс, который определяет основные виды деятельности, связанные с поставкой ваших услуг или вашего продукта, для того чтобы впоследствии их как-то прооптимизировать, как-то повысить их эффективность. Например, в рамках вашей большой компании у вас есть один небольшой [НЕРАЗБОРЧИВО]. У вас есть колл-центр, и его задача — обзванивать определенных клиентов, собирать с них какую-то информацию и вносить в CRM. Все очень просто. Можно выделить три ключевых блока из этой истории. Первое. Это оператор, когда звонит, первое, что он делает — он дозванивается, то есть он ждет время, пока снимут трубку на другом конце провода. Второе — это, собственно, разговор, и третье — это внесение информации в какую-то из ваших систем. Согласитесь, что сам по себе дозвон, время, которое потратит в этот случай оператор, его нужно минимизировать по максимуму, потому что это время, потраченное впустую. Процессы, вообще говоря, делятся на два типа. Первое — это поддерживающие основную работу, но не приносящие напрямую ценность, например, планирование, ретроспектива, тимбилдинги. Я ни в коем случае не умаляю важность этих процессов, я лишь говорю о том, что эти процессы напрямую не связаны с конечным товаром или услугой, которую вы предоставляете рынку. И второе — это процессы, направленные на доставку конечной ценности. Так вот, наша задача как руководителей по факту — это минимизировать трудозатраты на первый тип процессов, при этом оставив их в качестве и в необходимости, и второе — это повысить трудозатраты на вторые, те, которые напрямую влияют на наши продукты. Так вот, здесь мы будем говорить еще с вами про сроки. Не про две-три недели, про четыре, а, скорее всего, про месяц, два, три, четыре, то есть то время, за которое метрики более-менее становятся объективными. Итак, возьмем все тот же пример с колл-центром. Допустим, у вас есть несколько ребят, которые звонят, вы собрали какую-то статистику за несколько месяцев и усреднили их значения. Получили, что время дозвона, то есть время, пока на другом конце не снимут трубку, составляет пять секунд. И теперь ваша задача — понять, как это вообще, нормально это, ненормально? А что сделать-то с тем, чтобы это улучшить? Здесь нам на помощь приходят контрольные карты Шухарта. Контрольные карты Шухарта, вообще говоря, это некоторый процесс выявления точек выхода процесса из стабильного состояния, для того чтобы впоследствии это нестабильное состояние привести к стабильному. Работает для всех видов процессов, как для поддерживающих, так и для процессов, непосредственно связанных с вашим продуктом. Итак, вернемся к вашему колл-центру. Согласитесь, что вы в повседневной жизни, когда звоните маме, бабушке, друзьям, коллегам, вы, скорее всего, ожидаете разное время, пока подойдут к телефону. И этот процесс для вас вариативен, то есть вы не можете гарантировать, что следующий дозвон, скажем, уложится в одну секунду. Нет. Поэтому первое, что нужно делать — это уменьшать вариативность. Вы не можете думать про то, что нормально ли пять секунд или ненормально, если вы не можете контролировать этот процесс. Завтра в любой момент он может стать 40 секунд или 45 секунд и так далее. Поэтому первое, на чем мы сосредотачиваемся — это на уменьшении вариативности. Например, в случае с колл-центром можно поставить АТС и дозваниваться в фоне без оператора до клиента, и когда клиент возьмет трубку, уже подключать в этот момент оператора. Тогда у вас резко снизятся лишние трудозатраты, и скорее всего, вариативность будет минимальной. Второе, о чем стоит думать — это изменение средней, вокруг которой колеблется метрика вашего процесса. Грубо говоря, в тот момент, когда у нас уже все стабильно, вы получили время дозвона одну секунду, можно подумать, как сделать из одной секунды полсекунды и так далее. В случае с процессами, которые поддерживают вашу работу, такие, как, например, планирование, то очень хороший пример — это когда команда планирует, называют все время разные оценки. В этом случае у вас вариативность зашкаливает, вы не можете контролировать, а какая же в итоге будет оценка. Возьмете среднюю — она, скорее всего, будет неправдой. Поэтому в этом случае вам нужно подумать над какой-нибудь механикой, которая позволит эту вариативность уменьшить. Например, разбейте задачи на какие-нибудь мелкие подзадачи, оценивайте их, суммируйте итоговые оценки. Скорее всего, в этом случае вариативность у вас сильно упадет. Но я всем рекомендую начинать не с каких-то сложных инструментов, а просто постройте график простейших ваших метрик и посмотрите, а что же с ними происходит. Скорее всего, вы уже много интересного найдете. И второе: автоматизируйте все ваши метрики там, где это возможно. Вообще говоря, у нас бывают два типа метрик в процессе. Это когда метрика понятно, но ее либо тяжело, либо невозможно автоматизировать. Скорее всего, вы просто еще до этого пока не добрались. И в этом случае я вам рекомендую делать все, чтобы эти метрики автоматически собирать. Например, у нас в компании есть такой процесс, когда продажник звонит своим клиентам. И если он звонит из офиса, он звонит через АТС, и все его метрики собираются автоматически, все хорошо. Но в какой-то момент он выезжает на встречу, выходит, так сказать, «в поле» и начинает тоже звонить клиентам. И в этот момент он звонит со своего мобильного телефона. И в этом случае нормальная практика — это попросить его снять срез звонков, где-то зафиксировать либо делать это как-то автоматически. Но вы должны учитывать эти метрики, в ином случае у вас не будет объективной картины. И второй тип метрик — это когда сама по себе метрика плохо формализуется, например, настроение команды. Согласитесь, очень тяжело собирать настроение команды. Но тем не менее есть разные способы, как это можно оцифровать. При этом согласитесь, что вычислять среднюю величину — это какая-то немножко странная история. Если у вас есть десять человек, и один человек дико унылит и отравляет атмосферу, а у девяти человек все хорошо, скорее всего, у этих девяти человек скоро все станет плохо. Такие ребята могут потопить работу целой команды или даже целого отдела, поэтому усреднение здесь не работает. И нам здесь на помощь приходят несколько инструментов, таких как, например, ретроспектива и тет-а-тет. Что такое ретроспектива? Ретроспектива — это некоторый процесс, в рамках которого команда собирается и обсуждает удачные и неудачные процессы, которые были за прошлый период. Эти процессы связаны как непосредственно с работой, так и с некоторыми процессами, которые влияют на доставку конечного продукта. Если мы говорим про программного обеспечение, например, то это вполне может быть, например, разворот вашего программного обеспечения где-то на серверах. То есть это вполне себе рабочий процесс, о котором стоит поговорить. Ретроспектива, она должна быть очень комфортной, люди должны собираться и максимально доверчиво друг другу рассказывать про различные идеи или про то, что их беспокоит, как можно что-то улучшить. Как правило, ретроспектива состоит из четырех этапов. Первый — это подготовка, второй — это выступление, мозговой штурм, третий — это голосование, и четвертый — это конкретный план действий. При этом ретроспектива обладает очень интересной особенностью. Помимо того, что она собирает какие-то просто общие мысли, какие-то метрики и так далее, она также собирает мнения различных членов команды, и она очень эффективна в тот момент, когда команда сплоченная. При этом очень важно на ретроспективах уметь слышать и вычленить различные эмоции, которые люди доносят, связанные с опытом или связанные с их чутьем, чуйкой и так далее. Например, я приведу одну очень грустную историю. 28 января 1986 года произошла авария в мировой космонавтике, произошла авария «Челленджера». На 73-й секунде взорвались внешние топливные баки, и это унесло жизни семи астронавтов. К сожалению, за несколько лет до этого было известно, что эти топливные внешние баки обладают некоторыми дефектами. Вы об этом можете прочитать на Википедии, и обязательно это сделайте. Более того, инженеры, которые сопровождали весь процесс, говорили, что запуск назначен на утро, которое будет холодным, и это определенные риски. Они не гарантировали, что все будет хорошо, но их, как видится, никто не послушал. О чем это? О том, что на ретроспективе, возможно, кто-то даже будет вам говорить, что, скорее всего, это проблема, что не нужно идти таким путем. Постарайтесь вычленить как можно больше информации и поработать с ней. Тет-а-теты. Зачем нужны они, тет-а-теты, если, казалось бы, есть ретроспектива? А все дело в том, что какая бы ни была сплоченная команда, доверчивая, открытая и так далее, все равно есть моменты, про которые нельзя сказать вслух. Это будет очень нетактично или по разным другим причинам. И в этот момент вам важно разговаривать с каждым членом команды, вытаскивать из них информацию, что они думают про ваши процессы, что можно улучшить, над чем можно поработать. Можно их даже приглашать и нужно их приглашать, чтобы поработать над этим вместе. И обязательно с ретроспектив и с тет-а-тетов уходите с какими-то решениями. Нельзя просто поговорить, что все плохо, это плохо, то плохо, и на этом разойтись. Скорее всего, дальше будет только хуже. Обязательно вырабатывайте конкретные идеи, решения, которые вы в следующую итерацию возьмете в обработку. Итак, мы это делаем все не просто так. Мы хотим, чтобы наши процессы стали лучше со временем. И ровно в тот момент, когда вы будете думать про ваши процессы, собирать метрики, задайте себе следующие вопросы. Какие из наших процессов работают хорошо? Какие идеи из прошлого или из настоящего работают хорошо, а от каких стоит отказаться? Какие практики нужно развивать, а что, наоборот, нужно перестать развивать прямо сейчас, потому что это лишняя трата времени, а выхлопа никакого? А в следующей лекции мы с вами поговорим о том, как же непосредственно перейти к корректировке работы команды, и мы замкнем с вами цикл Деминга.
