**⌘289. Definition of Done**

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

Знайомся, це – _трактування_.

В ідеальному світі всі задачі з розвитку бізнесу підпорядковані зрозумілому (і невеликому) списку цілей. Це може бути зростання обороту чи чистого прибутку, вихід на новий ринок або впізнаваність бренду.

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

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

Ти можеш поставити задачу "_Написати та опублікувати 10 статей_", а можеш написати "_у кожній статті поставити активне посилання на наш сайт, майданчик для публікації повинен мати трафік за Similarweb щонайменше 500 тисяч унікальних відвідувачів на місяць_".

Відчуваєш різницю? Розумієш, як просто буде виконавцеві довести, що в першому випадку він правильно трактував задачу, хоча позитивного результату це не дасть?

Щоб такого не траплялося, придумали **DOD** (definition of done) – чіткий, ємний і короткий опис наприкінці кожної задачі, який відповідає на питання "що має бути зроблено, щоб задачу вважати виконаною".

Задача може називатися "_Реліз нового сайту_", але в DOD у тебе має бути прописано: "п_адіння трафіку після релізу немає або його компенсовано за 3 місяці, оцінка Google PageSpeed покращилася на Х%, коефіцієнт конверсії зріс на Y%_".

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

Тому саму задачу треба формулювати одним реченням із трьох частин: хто робить, що на виході, до коли. Наприклад: "_дизайнер до п'ятниці показує два варіанти першого екрана лендингу_". Контекст, обмеження й посилання йдуть в опис, а DOD наприкінці фіксує, які варіанти вважатимуться прийнятими: "_обидва відповідають брендбуку, мають одну цільову дію і погоджені з акаунт-менеджером_".

Якщо задачу не вдається стиснути до одного речення, ти ще не вирішив, чого хочеш. Тоді вирішить виконавець – через своє трактування.

Хочеться заперечити, що складна задача в одне речення не влазить? Погоджуюсь, але якщо не влазить, то це майже завжди насправді кілька задач, склеєних в одну. Декомпозуй їх – і в кожної з'явиться своє "одне речення" і свій DOD.

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

[#менеджмент](?q=%23%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%BC%D0%B5%D0%BD%D1%82)
[@chumandriy](https://t.me/chumandriy)