Рецепт эффективного решения задач от ex-менеджера AGIMA или как работает потоковая система

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

Помочь здесь способен Канбан-метод. Как именно он повышает эффективность процессов в команде и как свести блоки в потоковой системе к минимуму, рассказал сообществу Heg.ai Иван Михеев.

Ваня — ex-менеджер одного из крупнейших digital production AGIMA, а сейчас — CTO & Co-founder онлайн-платформы для бронирования многодневных туров Youtravel.me. Сообщество Паши Хегай активно помогает стартапу в развитии сервиса за счет большого количества участников, которые консультируют по вопросам развития бизнеса и поиска инвестиций для выхода на американский рынок.

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

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

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

Вся работа с интеллектуальным трудом в потоковых системах хорошо описывается Канбан-методом: его основная идея заключается в эволюционном совершенствовании процессов. Этот метод систематизирует подход к работе и повышает эффективность труда.

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

Для IT-сектора это компания, заказавшая приложение, для HR — департамент, который получает нанятого сотрудника. В канбан-методе эта метрика оценки эффективности называется lead-time (время выполнения). Также есть показатель cycle-time (время цикла) — время реализации конкретного подэтапа.

Еще один важный показатель системы — work in progress (WIP). Есть прямая зависимость показателя lead-time от количества задач, которые находятся на канбан-доске. Чем больше их появляется, тем выше становится lead-time. Получается, что чем меньше работы запускается в системе, тем быстрее задачи по ней двигаются.

Это можно описать в терминах системного анализа, рассмотрев четыре показателя:

• Start work — сколько задач поступило в систему.
• Work in progress — сколько задач в процессе исполнения.
• Blocked work — сколько задач заблокировано.
• Idle time — сколько времени простоя.

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

Как ускорить lead-time:

• Первое — сокращать WIP limit
• Второе — увеличивать количество участников
  
• Третье — растить качество специалистов
  

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

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

Распространенные ограничители:

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

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

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

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

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

Сначала мы пробовали ставить все задачи по порядку, это помогало до тех пор, пока их не стало больше 50 в моменте. Потом мы решили ввести 5-бальную систему, в итоге это сработало, но также краткосрочно. А потом и вовсе все задачи начали превращаться в high, а те, что помечались как midle, просто протухали. В итоге мы пришли к тому, что весь наш процесс работы над задачами — это воронка, которая в начале растет с невероятной скоростью, а на входе в систему жестко ограничивается (WIP Limit).

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

Появилось два основных класса обслуживания: Expedite и Standart, которые помогают гибко приоретизировать очередь, разделяя задачи на сверхсрочные (такие не задерживаются на доске больше недели) и обычные, согласно принятым всеми критериям.

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

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

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

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

• Первая причина задержки сроков — недостаточно изученное описание кейса на стартовой позиции.

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

• Вторая причина затянутости выполнения задач — неопытность разработчиков.

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

• Третья причина — большой объем задачи изначально.

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

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

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

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

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

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

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

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

Экспертные статьи от участников сообщества по темам образования, маркетинга, венчурных инвестиций и предпринимательства читайте в нашей колонке на vc.ru. Узнать про нетворкинг и как его применять в жизни и карьере, можно в Инстаграм и Телеграм.