⌘89. Палиця з двома кінцями

Операційна діяльність і взагалі весь потік у практично будь-якому робочому процесі майже завжди може бути оптимізовано, а іноді навіть повністю автоматизовано.

Але є одна помилка, яку часто припускають керівники, така собі палиця з двома кінцями.

Енергійний керівник, який нещодавно отримав посаду та управління командою, хоче автоматизувати та оптимізувати максимальну кількість процесів. І це добре.

Але часто він хоче це зробити відразу, навіть не попрацювавши всередині певного процесу хоча б місяць. Адже багато кастомних (читай – унікальні для кожної галузі, компанії, команди) процеси містять велику кількість “але” і “якщо”, які можна виявити тільки зіткнувшись з ними.

Суть палиці з двома кінцями в тому, що, з одного боку, швидка оптимізація – дуже добре. Вона заощаджує час, дозволяє доопрацьовувати себе в процесі та не створювати з керівника bottleneck, на якій стопаються всі процеси.

Менше замикатися в операційній системі і більше фокусуватися на розвитку команди, продукту або послуги та досягненні глобальних цілей.

А з іншого боку, швидка оптимізація – погано.
Наведу приклад із власної практики.

Уяви собі департамент, у якому є три команди. Є керівник департаменту та тимлід у кожній команді.

До департаменту щодня прилітає по 5-10 завдань від інших департаментів. Кожне завдання може відноситися до однієї з трьох команд усередині департаменту, або відразу до двох і навіть трьох. Також, кожне завдання може бути неправильно складене, не мати цінності та корисності для бізнесу тощо.

Підхід “швидкої оптимізації” говорить нам, що потрібно дати можливість постановникам завдань одразу обирати виконавцями одну (або кілька) з команд та перекласти відповідальність на тимлідів.

Практика роботи з таким потоком завдань уточнює, що “швидка оптимізація” одразу призведе до кількох проблем:

1. Керівник департаменту (за замовчуванням має більшу поінформованість про цілі бізнесу та ситуацію в компанії в цілому), не помітить завдання, які не потрібно було робити взагалі. Так, згодом тимліди навчаться розбиратися в цьому краще, але спочатку даремно буде витрачено безліч людиногодин.

2. Керівник департаменту замкнеться на своїх завданнях та взагалі не буде в курсі завдань команди. Глобально в цьому немає нічого поганого, але локально і точково йому буде складніше швидко вникнути та допомогти з вирішенням завтиків у виконанні завдань командою.

3. Перекладаючи на постановника завдання необхідність вибирати відповідну команду, а на тимліда – вирішувати, його команді виконувати завдання, або перекинути на іншого тимліда (і ще переконати його, що це правильне рішення) – теж не найкраще рішення, яке може призвести до втрати якості виконання завдань. “Не та” команда робитиме не те, що має/не те, що в неї краще виходить.

У прагненні зменшити операційну систему і автоматизувати все, що тільки можна, немає нічого поганого. Навпаки, це правильний підхід.

Головне – робити це тільки після того, як прожив цю операційну систему і точно знаєш весь фарватер і підводні камені.