Эффективное планирование задач по принципу - RUN & DEV
Рассказ о том, как я погружаюсь в новые проекты быстро, не теряя задачи по пути выполнения и легко ими руковожу.
Контекст, в которых подход полезен:
- Нужно принять дела от прошлого специалиста на ходу
- Стоит задача написать стратегию
- Проект уже действует и в нём есть операционные задачи, которые требуют внимания
- У вашего руководителя/заказчика нет времени на то, чтобы встретиться несколько раз
- Вы и есть этот руководитель и нужно разом распланировать огромный эпик, чтобы потом разбить его на спринты
В целом, контекст стандартный! Ошибки , которые я допускала постоянно:
- Не раскидывала задачи между собой по блокам
- Раскидывала задачи по блокам, но получалось некорректно из-за того, что задачи не были рассортированы по срочности и объему
- Не записала с слов
- Записывала с слов
Ну, что делаем? А я вам покажу!
Есть у меня мысль, что подход существует, и давно, но я не смогла о нем найти ни одной живой статьи. Может быть - плохо гуглила. Еще вероятнее - называется он совершенно по-другому. 100% это откуда-то из другой сферы, далеко не из управления.
Суть подхода:
Разделить все задачи на RUN и DEV
RUN - добежать. Срочно. Здесь и сейчас. Нет времени объяснять. Это низко висящие фрукты или горящие таски с прошлого спринта - не важно. Вы не можете начать делать что-то ЭДАКОЕ, пока у вас течет крыша или пока не работает коллтрекинг, или пока у вас заблокирована почта. Это те задачи, которые нужно выполнить в операционном режиме, чаще всего - делегировать, но обязательно проконтролировать.
DEV - развить. От слова Develop. Когда крыша не течет (или ее хотя бы начал кто-то чинить) вы можете оглядеться вокруг - что происходит с проектом прямо сейчас, но принесет свои плоды позднее? Эти задачи про тесты гипотез, расширение воронки трафика, запуск нового продукта. Если их не начать сегодня спустя квартал вы оглянетесь и поймете - "Черт, я ведь только тушил пожары!"
Что будет если пренебречь DEV задачами на всех этапах жизни проекта:
Если вы забудете о DEV-задачах, то упретесь в рутину, как специалист. Начнете ныть, что вас съела бытовуха, всюду стоят грязные кружки, света милого вы не видите, вы не растете в этом (браке) проекте. Эти последствия можно наглядно отследить на примере уборки: что будет если всю неделю вы только и будете ходить, да подбирать с пола мелкие крошки? Основной уборки не случится, чистота дома не наступит, но скорее всего вы ощутимо утомитесь и пошлёте куда подальше эту затею, не достигнув цели.
Как реализовать-то тогда?
Двигаемся по шагам, далее вы начнете интуитивно разделять задачи между собой:
- Запасаемся временем и фокусом внимания на брифинг, внутри которого вам будут спускать задачи. Писать нужно быстро, возможно все в кучу, работать вы с этим будете потом.
- Заранее пропишите свои зоны ответственности и узнайте о задачах в рамках каждой. Был у меня проект, который сказал - "Да нет у нас рутины, спокойно пишем стратегию". Да, конечно! Насыпалось столько, да еще и с просроченными дедлайнами, что мысль о стратегии улетела на месяц в ящик.
- Спросите о рутинных задачах - "Что мне нужно делать в проекте каждый день? А каждую неделю? А каждый месяц? Когда планерки? Есть ли регулярные платежи/встречи/отчетности?"
- Узнайте о блоках задач на далекую перспективу (те самые DEV) - "К каким результатам мы хотим прийти? Что является целью? Какой продукт у нас выходит через полгода? Открывается ли новый филиал в ближайший год?". Вам надо быть в курсе всех долгосрочных планов.
- После брифинга - отдых. Мозг должен оцифровать чем его только что пенетрировали, а вы должны отлететь подальше и посмотреть на ситуацию сверху.
- А теперь - открываем планировщик! И пишем DEV - векторы. Я работаю в миро, с помощью диаграммы Ганта.
7. Далее - внутри каждого вектора развития вычленяем первостепенные задачи, которые запустят процесс и собираем их вместе с задачами RUN, где нам нужно потушить пожары.
8. Ставим дедлайны. Можно для пущей эффективности применить формат матрицы Эйзенхауэра (но это для задротов, таких как я)
И стартуем в первый спринт!
Что важно на долгосрочную перспективу, чтобы это работало:
- Постоянно возвращаться к DEV-векторам, отрывать свой взгляд от крошек на полу. Я делаю это раз в месяц-полтора, вытаскивая задачи из больших эпиков, чтобы процесс двигался.
- Делегировать операционку, иначе вы зашьетесь.
- Мыслить шире, дальше и выше. Станьте визионером. Что будет с проектом через год? Начинайте смотреть в будущее, к водопадам из луж.