60 дней фильмов и сериалов
по промокоду:
VC60
Забрать
60 дней подписки Яндекс Плюс бесплатно для новых пользователей, ранее не оформлявших подписку Яндекс Плюс либо подписки, её включающие, при условии привязки банковской карты. Далее — автопродление: 199 ₽/месяц. Действует на территории РФ. Активировать до 31.10.2021 г. https://hd.kinopoisk.ru/gift. Условия: clck.ru/FMQND.

Рецепт эффективного решения задач от 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

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

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

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

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

Гистограмма количества закрытых задач по неделям после внедрения Канбан-метода

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

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

Как свести ограничения к минимуму

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

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

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

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

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

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

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

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

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

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

Как выявить ограничения на берегу

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

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

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

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

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

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

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

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

{ "author_name": "Сообщество Hegai", "author_type": "self", "tags": [], "comments": 5, "likes": 23, "favorites": 53, "is_advertisement": false, "subsite_label": "life", "id": 266938, "is_wide": true, "is_ugc": true, "date": "Fri, 30 Jul 2021 11:11:18 +0300", "is_special": false }
0
5 комментариев
Популярные
По порядку

> Ключевая метрика оценки эффективности работы — время завершения задачи

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

0

Когда разрабатывается продукт, не зависимо от фреймворка управления проектами, важно уделять должное внимание качеству, тут вы правы на 100%. В данной статье не раскрываются детали именно этапов внутри доски, они могут быть разные, от простого To Do, In Progress, Done до более сложного процесса, которые включает в себя взаимодействие между разными командами/контрагентами и несколько итераций проверки качества. 
В рамках же этой статьи рассматривается именно метрика самого потока. Так как ни кто не говорит о том, что время завершения работы (lead-time) нужно сокращать за счет игнорирования каких-либо этапов процесса, это как раз таки деструктивный путь развития, но некоторые им к сожалению пользуются. 

3

А есть что нить попроще? Урезанная версия. Выше сказанного.. ( формула какая нить).. ред.

0

Это может показаться странным, но формула есть, вернее закон. Закон Литтла как раз таки описывает пропускную способность потока, правда он справедлив для гомогенных систем, где элементы работы однотипны, но тем не менее на нем построены некоторые метрики Канбан-метода. 

3

Прикольно) лайк) я сам странный.. Поэтому всё норм.

Закон Литтла: https://ru.m.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9B%D0%B8%D1%82%D1%82%D0%BB%D0%B0 ред.

1

Комментарий удален

Читать все 5 комментариев
Как "Альфа-Банк" украл мои деньги через своего сотрудника в офисе банка у меня на глазах накануне моего Дня Рождения

Я очень любила «Альфа-Банк» за их креатив. Именно поэтому этот банк так сильно ранил меня и разбил мне сердце. Думаю, окончательно и бесповоротно. И об этом моя препечальная история.

«Яндекс» переименовал «Акрополь» в «Яндекс Банк» Статьи редакции

Компания закрыла сделку по покупке банка за 1,1 млрд рублей в июле 2021 года.

Если Вы не захотите подключаться к МегаФону, Вы услышите шёпотом фразу "Да иди ты на х*й!" и брошенную трубку во время Вашей речи.

Сегодня имел счастье общаться с руководителем отдела продаж по Петербургу Ткаченко Максимом. Около 10 минут он пытался осуществить продажу, в конце начал откровенно давить и обвинять меня во лжи, а потом с неприличными словами, сказанными шёпотом, бросил трубку во время моего ответа. Звонил с мобильного, поэтому перезвонить у него возможность…

ЦБ оштрафовал группу трейдеров за манипулирование рынком — они скупали активы, разгоняли их цену и перепродавали Статьи редакции

Трейдеры получили штрафы от 3000 до 5000 рублей, а доход превысил несколько миллионов рублей.

Суд с «Тинькофф» относительно масштабных «сбоев», приводящих к потере инвесторами своих средств

Всем привет! Меня зовут Валерий, брокерский договор с Тинькофф (дальше буду называть их также «банк», «брокер») № 2057742591. В результате масштабных технических сбоев в работе Тинькофф Инвестиции 24 мая 2021 г., которые, между прочим, самим Банком были признаны, я потерял 70 000 долларов (!) при торговле акциями SPCE. 24-25 мая 2021 в результате…

5 руководителей Skillbox вошли в рейтинг ТОП-1000 лучших менеджеров России

ИД «Коммерсантъ» и Ассоциация менеджеров опубликовали результаты ежегодного рейтинга «ТОП-1000 российских менеджеров». В рейтинг вошли сразу пять топ-менеджеров Skillbox:

Яндекс представил обновленный интерфейс для запуска рекламы мобильных приложений

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

«Модульбанк» и «Ясно» проведут бесплатный воркшоп о синдроме трудоголика

30 сентября первый банк для предпринимателей «Модульбанк» и сервис психологических консультаций «Ясно» проведут второй совместный воркшоп для предпринимателей. Тема — синдром трудоголика. Эксперты «Ясно» расскажут, как владельцу бизнеса правильно отдыхать и не стыдиться этого.

Daniel Chekalov
Фонд «Подари жизнь» совместно с компанией LegalPics запустили сервис по юридической поддержке для родителей

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

Amazon разработала домашнего робота Astro для переноски вещей, видеонаблюдения, воспроизведения музыки и другого Статьи редакции

Стоит $999,99.

Идея линейного города, который за $200 млрд строит Саудовская Аравия: в чём её смысл и почему это уже было в Волгограде Статьи редакции

Концепция, которую применяют саудиты, не нова, её придумали ещё в 19 веке. Однако в мире есть только один крупный город по ней, и он в России.

Планируемый линейный город The Line в регионе Neom Strelcamag
null