Это не то, что я хотел

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

Я в своё время очень быстро выяснил, что сколько есть в мире людей — столько же существует способов решить одну и ту же задачу. Особенно острым это ощущение было, когда в результате работы человека получалось вовсе не то, что я себе представлял.

Что делать в такой ситуации? Человек работал, старался. Сказать ему, что он сделал что-то не то, — это обесценивание его труда. Более того, это было бы перекладыванием ответственности с себя на исполнителя. Цитируя одного футболиста: мои ожидания — это мои проблемы.

✅ Делегирование ≠ снятие ответственности

Делегируя задачу, я передаю ответственность за её исполнение другому человеку, но ответственность за результат остаётся на мне. Всё, что должен сделать исполнитель, — это выполнить задачу так, как ему сказали. Так вот, если он сделал "не то, что было нужно", то это ошибка руководителя, который недостаточно ясно и конкретно объяснил, "что было нужно".

Моя ответственность как заказчика заключается в том, чтобы дать исполнителю максимально чёткие и понятные критерии выполнения задачи. В agile это называется definition of done (DoD) — критерии того, что задача считается завершённой. Исполнитель должен понимать, по каким признакам я буду судить о том, выполнена задача или нет. В противном случае открывается широкий простор для манипуляций и прокрастинации с обеих сторон.

✅ Как формулировать DoD?

Для формулирования критериев приёмки задачи достаточно задать себе простой вопрос: "Как я пойму, что эта задача готова?" Затем просто запишите всё, что придёт в голову, и уберите лишнее. Постарайтесь, чтобы записи были максимально конкретными и наблюдаемыми со стороны. "Результат должен удовлетворять моё чувство прекрасного" — так себе критерий, потому что исполнителю будет сложно в него попасть.

Конечно, какие-то детали можно и нужно опускать. Не стоит в красках описывать каждую мелочь. В некоторых случаях DoD может быть даже расплывчатым (например, для R&D-задач я почти всегда ставил довольно абстрактный DoD). Однако тут важно понимать уровень самостоятельности и ответственности исполнителя. Для опытного Senior-специалиста задача с не самыми конкретными критериями может быть вполне приемлемой, а для джуна — смерти подобной.

✅ DoD - это забота о себе и сотрудниках

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

Посмотрите на этот процесс с другой стороны. Руководитель, который ставит чёткие и понятные критерии выполнения задачи, в первую очередь заботится о своих сотрудниках. Исполнителям будет гораздо комфортнее выполнять конкретные, хорошо проработанные задачи с зафиксированным ожидаемым результатом, чем "пойди туда — не знаю куда, принеси то — не знаю что". Соответственно, у людей от такого подхода заметно снижается стресс и повышается продуктивность (привет, обезьянка Тима Урбана). Да и себе вы заметно упростите жизнь, потому что результат выполнения задачи будет проще оценивать.

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

Никита Ульшин про IT | #management #agile