Сначала — описать процесс, а потом — попробовать его в деле. Не наоборот!

Я наконец описал процесс работы с задачами в новом проекте и завтра буду раскатывать на команду первую версию.

Поймал себя на мысли, что за последние две недели в новом проекте я просто нырнул в задачи: что-то делал, что-то комментировал, наблюдал, но совсем не понимаю что и когда будет.

Совсем забыл то, что однажды уже выучил, когда работал шеф-редактором в контент-проектах— в начале описать процесс [как что-то должно работать], а потом делать работу [проверить как он работает в реальности].

Помню, как я «героически» [как я думла] бросался в бой с места — и да, иногда получался классный результат, но потом его было просто невозможно повторить.

Повторение процесса со стабильным результатом— это почти всегда то, чего хочет бизнес. Особенно если у вас команда из людей с разным опытом. Так вот. Тогда я начал делать по-другому, сначала:

— описывал, как должен работать процесс и какие этапы

— в каждом этапе: кто инициатор, какие критерии результата и как передаётся ответственность

— И только после этого — запускаем в работу.

Это давало три бонуса: 1. Результат можно повторить — даже если меня нет в команде. 2. Можно делегировать или уйти в отпуск — без ощущения, что всё развалится 3. Можно сравнивать ожидание и реальность — и видеть, где была ошибка в предположениях.

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

То попробуйте вначале описать процесс, а уже потом попробовать работать по нему и корректировать от реальности.