Comments 8
самая удобная уже много лет - Матрица Эйзенхауэра. По ней не только задачи (рабочие, учебные и домашние) раскладываю, но и использую при планировании, да и при любом решении, если есть какие-то сомнения. Очень удобная штука.
Мне кажется, матрица эйзенхауэра идеально подходит, чтобы разобраться со своими задачами, с ней моментально все фильтруется и не тратится время.
А вот для постановки задач команде, на мой взгляд, лучше работает матрица про ценность, которую мы можем создать быстро или не быстро, и про обратимые и не обратимые решения (не приходится тратить время на сбор полной картины, понимая что решение обратимое).
домашние
Кому делегируете вынос мусора? Почему у них оно не попадает в категорию "делегировать"?
Допустим, появилось желание завести дома цветы, для их размещения нужно прибить полочку. Поскольку самих цветов тоже ещё нет, то это не срочно и не важно, удаляем. Получаем парадоксальный результат: вроде делали всё по методике, а цветов дома нет.
Ну приоритет полочки лечится - любой блокер не может быть по приоритетам ниже, чем то, что он блокирует. То есть если цветы попали в важно/несрочно, то полочка для них не может быть неважно.
Другое дело, что можно не заносить полку в блокер, купить цветы, поставить посреди кухонного стола, и вот уже полка попало в "важно" самостоятельно - цветы то уже есть, а значит и измеримая польза от расхламления стола.
Ну а мусор он по жизни "делегировать" если есть кому. Обычно его таскают те, кто был бы не против таскать в 2 раза реже, но ответственный за чистоту гоняет чаще.
По эйзенхауэру: разве срочное в ней это "имеющее дедлайн", а не "несущее расходы каждый день, пока не будет выполнено"?
Ну и важно/несрочно на рисунке в "отложить" (пока пока, техдолг), в тексте правда "запланировать", но по сути это одно и то же - в момент около начала исполнения будет процедура перепланирования и снова задачи с понятным дедлайном вытеснят важное, но несрочное.
Ну и собственно эти три матрицы кажется уже в школе преподают. Сложности то появляются в понимании, что такое "высокая ценность", что такое задача и как ее декомпозировать, в какой момент развлекаться приоретизацией и тп.
Например, делаешь ты столы и табуретки. Можно обойтись пятью задачами - сделать стол, и 4 раза сделать табуретку.
А можно веером рассыпать "купить материалы", "собрать стол", 4*"собрать табуретку", "шлифануть стол", 4*"шлифануть табуретку", "покрасить стол", 4*"покрасить табуретку"
И вот уже не стол и первая табуретка стоят в важно-срочно, а остальные 3 в "менее срочно", а купить материалы и собрать - это быстрые победы, шлифовать это основные проекты (важно несрочно), а красить - явно же неважно несрочно. Так что пусть пользователи некоторое время занозы повыдергивают, а крашеная мебель им не светит - мы полочки некрашенные делать раньше начнем, чем табуретки покрасим.
(это наболевшее с позиции внутреннего разработчика. Фичи клепаются, а удобство их использования уходит в низкий приоритет и реализуется практически подпольно)
Спасибо за комментарий. В нем очень много сложных тем. Что делать с тех долгом это вообще вечная драма. А «ценность» чаще всего уходит в задачи бизнеса и метрики продукта. Но есть и другой аспект про удобство, по мне лучше выкатить не идеальную фичу и быстрее «ударить» ее об реальность и пользователей, а потом улучшать и допиливать, если есть интерес к фиче и есть влияние на «бизнес», чем катить только идеально выкрашенную и ровную табуретку, которая может оказаться никому не нужной.
Я не коммерческая разработка. Я выкатываю кусками сразу, как есть польза (на тесте, но живым пользователям или прямо на проде, если это безопасно). А вот дальше начинаются игры в политику. Пользователи выходят с обратной связью, и я или быстро делаю как им хочется (если у меня есть запас по времени до дедлайна) или оформляю их пожелания "в счет будущего развития" в отдельную задачу и вот эта задача на тюнинг имеет все шансы быть никогда не взятой в работу. Так как про нее нечего писать на ревью в части бизнес результатов. А даже если есть что - мы же в прошлом квартале отчитались, что эта функциональность выпущена. Значить говорить про нее в этом - табу, иначе нам зададут уточняющие вопросы, не обманывали ли мы в прошлый раз.
(На случай если кто меня знает, это не текущее рабочее место, тут на удивление норм, это по опыту инхаус работы)
Может быть дело не в методиках, а в путанице с целями.
Цель бизнеса всегда - максимизация прибыли, но на словах часто бизнес подменяет свои цели другими обманчивыми "миссиями", например, сделать хорошо пользователям.
Вот и получается: на словах одно, а как дело коснется денег, то совсем другое.
А в вашем примере возможно просто не хватает аналитики реакции пользователей (если это вообще на что-нибудь влияет), т.е. просто плюс еще одна переменная во время применения описанных методик.
Не усложняй: простые фреймворки, чтобы быстрее принимать решения и приоритизировать задачи