Не оставляйте проблемы на самоопределение

в 21:27, , рубрики: bottlenecks, управление проектами

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

Детская игра

Идея очень проста для рассмотрения на примере линейной системы. Представьте себе что у вас есть группа детей которым поручено делать бумажные самолётики (назовём их Энди, Боб, и Клэр). Этапы для изготовления следующие:

  • Задача Энди — складывать бумагу пополам для 10 самолетиков в минуту
  • Задача второго, Боба, формировать крылья, он может это делать со скоростью 5 единиц в минуту
  • Клэр тестирует полет собранных самолётиков по 20 в минуту

Что произойдёт через время если все дети будут работать настолько быстро настолько могут? Если ответ не напрашивается сразу же, то посмотрите этот ролик (небольшой мультик о работающих людях). (будет интересно)

(Описание: Если у вас проблемы из-за того, что Энди и Клэр не помогают Бобу с крыльями, а значит вы потратили недостаточно времени на корпоративную среду. Вместо этого представьте, что задача не самолетики бумажные делать, а завершение части утомительной документации по ISO9001. Так же представьте, что они работают по контракту и получают штрафы за не выполнение объёмов. Все представленные ситуации имеют одинаковую проблему подходящую для нашего рассуждения.)

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

Что будет если пробка перестанет существовать? Если вы смотрели видео – знаете ответ. Энди имеет достаточно материала для того чтобы сделать еще несколько самолетиков поэтому он может взять перерыв. Клэр может поспешить чтобы сделать. Но вот с Бобом иначе: он не может спешить чтобы поспеть за Энди, и он не может сделать запас для Клэр. С другой стороны на Боба очень высокое давление чтобы он работал настолько эффективно насколько может.

Узкие места в софтверных компаниях

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

В конечном итоге, люди странные… В каком-то смысле мы можем абстрагироваться и использовать их как «ресурсы», но я бы не советовал, если вы хотите иметь много друзей. Но как отметил Том де Марко в Slack [amzn]: мы не взаимозаменимы. Это значит, что вы не можете с легкостью заменить одного сотрудника другим, во всех ситуациях кроме простейших, к примеру делании бумажных самолетиков, наверное. Невозможность взаимозамены имеет корни в более фундаментальных проблемах работы с людьми: мы не механические детали, мы сложные части сложной системы. Мы имеем обратную связь, в отличие от машин, имеющих проблемы статистически или на пределе рассчитанного. Оба примера подходят, и, что наиболее важно в аналогах, мы испытываем стресс.

Описав проблемные места, давление оказываемое на них, их наличие в более сложных структурах (и некоторые оговорки к модели) – уже время ответить на важный вопрос: кто должен нести ответственность за отслеживание состояния этих проблем?

Золотое правило

Никогда не оставляйте проблемные места на самоопределение

Почему?

Вы уже видели эти составляющие. Давайте повторим. Собственно проблемное место:

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

Для понимания происходящего когда проблемы оставляют на самоопределение используем упрощенный пример. Рассмотрим отдельного сотрудника, назовем его Бобом, он Senior.

Боб может быть консультантом, единственный сотрудник (наверняка с редкими навыками, использующий необходимые ему инструменты), единственный менеджер департамента, или любой иной схожий вариант. Фактически, Боб находится на самоопределении. И есть одно важное условие: Боб – узкое местом. Если Боб даст слабинку, ошибется или напутает – это скажется на всех. Наверняка никто не беспокоится о Бобе пока он сам не обратит на себя внимание.

У Боба две задачи: он должен делать свою работу, и он должен каким-то образом убеждаться, что его собственная работа контролируема. Как Боб должен распоряжаться своим временем? У него две противоречивые задачи. Как и каждый, должен объять необъятное, поэтому он должен или вертеться или облажается. (Так же, как Деминг говорил: меняться вовсе не обязательно. Выживание не обязанность.) Предположим он хочет выполнять свои задачи, для этого он должен:

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

(Отступление: большинство организаций даже не пробуют измерять эффективность – они в лучшем случае измеряют финансовые затраты и прибыль которую получают от вложений из расчета на сотрудника. Как мы уже отметили всеобщая полная занятость не есть залогом максимальной производительности. “The Goal” [http://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884271781/] Эли Голбратта содержит намного больше об этом).

Основополагающий конфликт «узкого места»

Наш протагонист Боб борется с собственными конфликтами и должен сделать максимум возможного. Что произойдет если он выберет «путь борьбы»? Тогда он сделает больше чем в его силах, но это не самое важное. Он может сделать более значимую ошибку – сделать то чего не требовалось, только потому, что он не остановился подумать можно ли их избежать. Или сделает ошибки по не внимательности – пропустит моменты которые мог увидеть, остановись он и подумай глобальнее. Оба варианта требуют более эффективного управления. Но Боб и так, собственно, сам себя контролирует, что же будет если он выберет вариант решать проблему? Теперь появляется что-то более глубокое. Каждый раз как он себя контролирует, он не делает свою работу. Стоит напомнить: Боб является узким местом, он находится под сильным давлением необходимости эффективно качественно, и надеемся эффективно. Время которое он использует на контроль и улучшения своей работы – он ее на самом деле не делает.

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

Что происходит когда люди оказываются под давлением? У них начинается стресс. И что происходит с людьми при наличии стресса?
Кажущееся сложным и не правдоподобным объяснение на самом деле отлично работает: увеличение производительности под давлением на самом деле ее уменьшает.

Интересная ситуация получается. Когда Боб не пытается себя контролировать – его производительность будет падать в долгосрочной перспективе по сравнением с остальными. А если он пытается управлять собой – его производительность упадет уже скоро, благодаря тому, что он использует свои ресурсы на управление, а не работу. И тут, получается, Боб связан по рукам: его производительность будет уменьшаться в любом случае.

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

  • выполнения задач – чтобы получать больше результатов, или
  • управления – чтобы быть более эффективным

Ничего не напоминает? Это замкнутый цикл, который поджидает нас на каждом шагу, как бы это ни было печально.

Надежда на будущее

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

  • Больше внимания уделять проблеме узких мест в организации: эта концепция интуитивно всем понятная, но тем не менее делают выводы из нее не часто. Видя несколько показательных примеров (и они не редки в реальной жизни) того, что может пойти неправильно в случае наличия узких мест может помочь нам обратить на это необходимое внимание
  • Защитная ретроспектива: выделение процента времени сотрудников которые есть узкими местами на регулярное, стабильное улучшение есть обязательным. Никто не может иметь права решить что он «слишком занят» для пересмотра процессов, чтобы уйти в штопор. Необходимо доверять собственному менеджеру в том, когда внимание и улучшение действительно необходимы
  • Экспертные оценки: пробовал это самостоятельно, и это может быть действительно эффективно. Сбор мнений объективных людей на регулярной основе может остановить вас от ошибки когда-то.
  • Делайте работу более наглядной: вполне не сложно перерабатывать, но без наличия простого способа контроля того, над чем работают люди, проблемные места будут продолжать существовать, им будут добавлять работы, и не делать истинной работы. Вовлекайте в это так же других.
  • Создание культуры вовлеченности: слишком много часов в неделю когда сотрудники могут работать над одним и тем же. Будьте менее склонны заставлять делать больше и больше задач в то время как намного более важные ждут пересмотра их работы.

Это рекомендации в основном по использованию сотрудников и процессов с явными узкими местами («по использованию» не в понимании ресурса, а использовано в качестве «как не потратить зря их время».) Большая часть рекомендаций относится к управлению временем и ресурсами.

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

Для дополнительного изучения

Если вы желаете узнать больше про узкие места, идеи которые я использовал идут из Theory of Constraints. Там много информации, но я рекомендую читать оригинальное издание для бизнеса, новеллу The Goal [amzn] которая объясняет как находить и убирать узкие места. Ее продолжение It's Not Luck [amzn] поясняет почему даже сложные организации имеют несколько действительно узких мест и раскрывает их различные типы. Я упоминал дважды Slack [amzn] в статье – это не про ограничения, но содержит много полезных идей как управлять ресурсами. Если вы заинтересованы или необходимо больше ссылок и информации, спрашивайте в комментариях.

Автор: Alliceinwonders

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js