«Нам нужно больше людей», как часто вы слышите этот аргумент?
Если бы у нас было больше людей, немного больше времени и денег - мы бы достигли всех целей, которые поставили перед собой. Мы закончим все проекты, которые мы взяли на себя. Наши клиенты наконец получили бы то, что им обещали ... мы.
Видите шаблон? Кажется, здравый смысл - это цена, которую мы должны заплатить, чтобы получить работу менеджера. Мне тоже пришлось заплатить.
Проработав два года инженером в Productive Mobile, я перешел на позицию менеджера по продукту. В начале сбивала с толку и была беспорядочной. Слишком много вовлеченных сторон, слишком много проектов приходилось вести. Сегодня, год спустя, я чувствую себя намного комфортнее на работе. Я далеко не там, где хочу быть, но, возможно, принципы, которые я использовал могут вам пригодиться.
Большая идея
Мы не используем 100% наших ресурсов. Получить больше людей / денег / времени - все равно, что налить больше воды в протекающее ведро. Вместо этого мы должны устранить утечку.
Мы можем сделать более полезную работу с теми же ресурсами.
Давайте поговорим о том, что такое работа и куда мы ее прикладываем.
Система
Мы можем думать о компании, команде или проекте как о Системе. У нее есть много действующих лиц, которые взаимодействуют друг с другом. У нее есть свои входящие и исходящие данные. Превращение входящих данных в исходящие является целью системы.
Productive Mobile - B2B стартап, занимающий программным обеспечением. У нас есть отдел продаж, продукции и обслуживания клиентов. И наша цель ... создавать программное обеспечение?
Виды работы
В то время, когда я начал работать как владелец продукта (Product owner), у нас было две цели. Мы хотели достигнуть двух целей командой из четырех инженеров.
У нас имелось виденье того, как клиенты должны использовать наш продукт и как они его используют в действительности. Все наши клиенты зависели от нашей команды "безупречного опыта покупателя" ( Customer Success team). Они изо всех сил пытались использовать наш собственный софт, что бы сделать корпоративную систему клиента более удобной.
Поскольку наши цели были настолько далеки друг от друга, любая функция, которую мы создавали, была одновременно и полезной и ненужной. Сделав нашу платформу более гибкой для Customer Success team, она в тоже самое время стала менее соответствующей здравому смыслу. Новые функции для новых клиентов были бесполезными для нашей внутренней команды. И кто был виноват, что мы движемся недостаточно быстро? Продакт!
Я почувствовал, что это была моя работа согласовать наши цели. Чтобы это работало на всех. Это было не так. После нескольких месяцев работы в качестве Product owner я убедил старшее руководство принять решение. Не было очевидно правильного, но мы приняли решение.
Мы не знаем, что полезно, а что нет, пока не знаем цель с которой создается система.
Забегая вперед скажу, что сегодня мы выпустили версию, которая успешно используется Customer Success team и они не могут дождаться, когда она доберется до клиента. Время, необходимое для обработки сложных случаев сократилось с недель до дней, иногда даже часов. В качестве следующего шага мы теперь четко видим путь к упрощению платформы и для клиентов. Я очень горжусь тем, чего мы достигли.
Мы сделали это, сосредоточившись на одной задаче.
Полезная работа - это работа, превращающая входящие данные в исходящие. Бесполезная работа - это все остальное.
Феномен членства в спортзале
Чтобы найти цель системы, нам нужно взглянуть за ее пределы. Иронично, не правда ли? Цель определяется тем, с чем система взаимодействует. Цель пассажирского самолета не в том, чтобы летать, а в том, чтобы перемещать людей из пункта А в пункт Б. Инженерный отдел призван сделать бизнес успешным, написание кода - это средство, а не самоцель.
Цель не имеет ничего общего с внутренностями системы. Ищите это вне Системы.
Хорошим примером компании с четко поставленной целью является LambdaSchool. Они обучают людей становиться разработчиками. Их цель - не «научить», а помочь своим клиентам стать профессиональными разработчиками. Им платят только тогда, когда их клиент получает работу.
Мой любимый плохой пример - любой спортзал в Берлине. Их цель - продать вам членство. По сути поймать вас в ловушку на год или более. Это далеко от целей самих клиентов.
Каждый спортивный зал работает одинаково. Они продают тренинги, секции, время своих тренеров. Они продают «членство в спортзале». Они сосредоточены на том, что находится внутри их системы, на вещах, которые они могут контролировать. На чем они должны сосредоточиться, так это на результатах своих клиентов.
Измерения
Как только мы знаем цель, измерения становятся проще. Вот метрики, которые мы можем использовать для системы в целом:
- Сколько полезной работы выполняет система в течение определенного периода времени, называется пропускной способностью этой системы;
- Сколько работы застревает в системе, но будет выпущено в какой-то момент - это незавершенное производство;
- Какие ресурсы расходуются на то, чтобы превратить входящие данные в исходящие, это операционные расходы.
Каждый рабочий центр (отдел, стадия проекта) должен оцениваться только по его вкладу в показатели системы. Если эта работа помогает превратить входящие данные системы в исходящие - отлично! Если нет - это пустая трата времени.
Насколько хорошо работает система, определяется тем, как быстро и по какой цене она может превратить входящие данные в исходящие. Действующие лица внутри системы никогда не должны измеряться изолированно. Их вклад в работу системы в целом является важным.
Вот хороший пример измерения системы. Я спросил Эд Хилла, основателя консалтинговой фирмы Synchronous Solutions, как они отслеживают успешность проекта. Читая его ответ, подумайте, что может быть целью консалтингового агентства, для чего они нанимаются?
Вот ответ Эда:
«В качестве первого шага в каждом проекте я прошу владельца компании (или старшего сотрудника) установить измеримые цели. Чистая прибыль, показатели обслуживания клиентов, сроки поставки, качественные показатели - вот типичные примеры. Мы также просим их сформулировать показатели в областях, которые не поддаются измерению, таких как уровни хаоса, моральный дух сотрудников и лидерские качества ключевых сотрудников. Мы работаем над тем, чтобы установить базовые показатели по этим метрикам. Затем мы отслеживаем и документируем фактическую производительность по этим базовым показателям. Успех измеряется эффективностью по отношению ко всем установленным целям, а не только к прибыли».
Пример вредных измерений пришел от Рикардо Х. Мендеса. Он был техническим директором и сам основал несколько компаний. Вот что он сказал на эту тему:
«Несколько раз в разных компаниях я сталкивался с ситуацией, когда команде приходилось что-то создавать только потому что отдел продаж уверяли нас, что клиент требовал этого, либо в том, что это требуется для закрытия продажи. Они думали, что это могло помочь, и они лгали об этом, потому что это улучшало их шансы на продажу. В одном случае клиенту не только не была нужна эта функция, он активно негодовал из за нее. Спустя время ее откатили назад.
Это расточительно.
Причина, по которой отдел делает такие вещи, заключается в том, что для них нет риска, и это увеличивает их шанс получить вознаграждение. Если доход от продаж зависит от комиссионных, а разработка - это фиксированный доход, то стимулы ваших отделов будут смещены. Неправильные стимулы приведут к потерям».
В примере Рикардо, вклад продаж измеряется изолированно, а не в системе в целом. Возможно лучшие показатели могут выглядеть так:
- Чистый объем продаж для проектов, которые практически не требуют изменения продукта;
- Или лучше: чистый объем продаж для проектов, которые были выполнены вовремя и в рамках бюджета;
- Или даже лучше: чистый объем продаж для проектов, которые достигают целей, установленных заказчиком.
С такими показателями отдел продаж будет сотрудничать с другими отделами и клиентами. Это то, что мы хотим. Мы хотим, чтобы показатели успеха одного отдела были напрямую связаны с показателями успеха организации в целом.
Что дальше?
Самым важным для меня опытом за этот год было то, что основные принципы разработки все еще применимы. Если фрагмент кода работает неэффективно, использование более современного компьютера не поможет.
Мы не добиваемся лучших результатов, бросая больше людей и ресурсов на решение этой проблемы. То, что работает это возвращение к истокам. Составление схемы системы, понимание ее цели, ее входящих и исходящих данных. Как только это будет сделано, мы можем приступить к поиску путей улучшения системы.
Но как мы это делаем? Что мы меняем и как? Я расскажу об этом в следующей части серии.
Перевод статьи https://hackernoon.com/systems-thinking-in-management-c3ed049e8d91
