Я тимлид в команде разработки и частично исполняю роль операционного менеджера. Это новая для меня роль, операционному менеджменту намеренно не учился, поэтому опираюсь на интуицию, которая часто подводит. Благо, я стал замечать когда вхожу в роль операционного менеджера, что уже делает половину успеха.
Для ведения задач мы используем таск-трекер, в котором наглядно представляется прогресс по задаче. Интуиция подсказала, что работа операционного менеджера заключается в том, что нужно как можно быстрее двигать карточки из колонки "open" в колонку "done". Такой фокус внимания на карточках дал свои результаты - количество закрытых задач было очень большим. Беда в том, что наши закрытые задачи слабо связаны с количеством и качеством рабочих продуктов, которых ждут от команды. А зарплату платят именно за рабочие продукты.
Планирую сдвинуть фокус команды на получение рабочих продуктов и их качество. В описании каждой задачи будет отражено какой артефакт, какого качества будет получен в результате выполнения этой задачи. Такое описание позволит лучше оценивать приоритет задач и брать в работу только самое важное.
Понял, что мои компетенции по операционному менеджменту находятся в области осознанной некомпетентности. Поэтому внес изучение операционного менеджмента в список проектов, в которые инвестирую время.
Очень интересная ситуация про то, что таски плохо связаны с рабочими продуктами. Я в теории понимаю как это может быть, но в целом странно. Я нечто подобное наблюдал у нас, мне помогала “шпаргалка” про явное связывание задачи с целевыми действием, то есть что изменится в физическом мире. Часто связь выражалась в виде цепочки действия (job story) от нашего действия (в нашей системе) и до действий целевой системе.
Помогала вот такая цепочка и в случае наших задач явный DoD — то есть весь пакет проверки и приемки для запуска цепочки.
Мне кажется, что привязав “плотнее” карточки к рабочим / реальным вещам (заземлив их) получится ускорить не только проход карточек, но и проход самих продуктов.
Спасибо за комментарий! Похоже, я некорректно написал в тексте. Под рабочим продуктом подразумевал как раз результат в физическом мире. Связь задачи с рабочим продуктом безусловно есть, только мы ее осознанно не выявляем. Обсуждаем работу которую надо сделать, а изменения в физическом мире, которые она вызовет, игнорируем.
Беда в том, что наши закрытые задачи слабо связаны с количеством и качеством рабочих продуктов, которых ждут от команды.
Сергей, а вы попробуйте (хотя бы для себя) расписать какие вы считаете у вас рабочие продукты, какие задачи закрывает команда и как результаты этой работы связаны с тем, что ожидают от вашей команды. Если вы считаете, что проводимая работа не связана с количеством и качеством продуктов, то что произойдёт с продуктом если её не делать? Если вдруг на продукт это и вправду не влияет, то где тогда скажется отсутсвие результатов вашего труда?
Попробуйте провести эту работу с карандашом. Должно быть увлекательно.
Это обсуждается в операционном менеджменте как разница между output (объём выпуска) и outcome (полезный результат, тут важно слово value – польза). Операционный менеджмент работает, если увеличивать скорость получения полезного результата. То есть производить нужное-полезное, а не просто быстро-быстро производить ненужное с вкраплениями нужного.
