Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Давно подумывал об эксперименте, где заставив управленцев сыграть в любую стратегию, попробовать оценить их навыки управления.
По результатам уволить всех топов с MBA-дипломами и нанять корейских киберспортсменов )))
Как вариант, но предполагается, что любой руководитель должен уметь играть в стратегию лучше рядовых сотрудников. Хотя бы из-за того, что управление подразумевает умение стратегически мыслить. Конечно до рекордсменов старкрафта необязательно дотягивать, но в пошаговую цивилизацию вполне.
Есть мнение, что Quake очень стратегическая игра: нужно решить, пойти за бронёй или оружием, или срочно гнаться за противником, чтобы ему не дать забрать mega-health. Кроме того, нужно предугадывать действия оппонента, как на микро-уровне (куда стрелять ракетой), так и на макро (в какой корридор он побежал?).
То есть, пока руководитель меня в Quake не обыграет, он мне не начальник?
То есть, пока руководитель меня в Quake не обыграет, он мне не начальник?
Quake — стратегическая игра, но помимо планирования задач есть еще и исполнение задачи (механический навык прицеливания, распрыжки, рокетджампов).
Так что если вас в «Quake» вас обыграет начальник, значит он ещё и как исполнитель лучше вас.
Лучше пример с Overwatch — там есть пересонажи, которым требуется минимальный механический навык (например Winston), и знание когда и на кого напасть приносит больше результата.
Так что если вас в «Quake» вас обыграет начальник, значит он ещё и как исполнитель лучше вас.
Лучше пример с Overwatch — там есть пересонажи, которым требуется минимальный механический навык (например Winston), и знание когда и на кого напасть приносит больше результата.
В комментарии неверное предположение, что умение хорошо играть в стратегии коррелирует с умением стратегически мыслить. Но мысль проверять стратегическое мышление интересна.
Идея на счёт оценки срочности/важности менеджерами: выдать каждому конечное число баллов для оценки. Слил все — новые задачи становятся не важными и не срочными. Либо перекидывай оценки с других задач.
И, по-моему, можно добавить ещё тегов :)
И, по-моему, можно добавить ещё тегов :)
У меня в систему приоритетов всегда вмешается ещё трудоёмкость задачи, т.е. сколько на неё надо потратить времени. Пример. Вы делаете срочную важную задачу длительностью, допустим, в полдня. В этот момент приходит срочная неважная на 10 минут делов. И как быть в парадигме матрицы Эйзенхауэра?
Так что срочность задачи (которую можно измерить во времени) надо каким-то образом «взвесить» на время исполнения задачи.
Так что срочность задачи (которую можно измерить во времени) надо каким-то образом «взвесить» на время исполнения задачи.
если внедрить понятие business value? или это усугубит?
Чтобы определить, в каком порядке выполнять задачи из пула, нужны и срочность, и важность, и оценка трудозатрат, и business value, и ещё несколько критериев, типа суммарной производительности команды, эластичности сроков и т. д.
Частный случай, описанный Tysha, я бы решал примерно так.
Исходя из производительности и загруженности команды, сколько задач мы успеем к сроку — обе, только важную, только быструю?
Можно ли большую задачу разрезать на две и выдать клиенту частями?
Можем ли мы подвинуть сроки у какой-то из задач?
Можем ли мы расширить команду?
Есть ли у нас время выяснять это всё? Если нет — неважная задача идёт нафиг, чтобы не рисковать плюшками, сулимыми важной задачей (и не выкинуть в мусорку неделю работы над ней в случае срыва сроков)
Частный случай, описанный Tysha, я бы решал примерно так.
Исходя из производительности и загруженности команды, сколько задач мы успеем к сроку — обе, только важную, только быструю?
Можно ли большую задачу разрезать на две и выдать клиенту частями?
Можем ли мы подвинуть сроки у какой-то из задач?
Можем ли мы расширить команду?
Есть ли у нас время выяснять это всё? Если нет — неважная задача идёт нафиг, чтобы не рисковать плюшками, сулимыми важной задачей (и не выкинуть в мусорку неделю работы над ней в случае срыва сроков)
Матрица Эйзенхауэра — подход (в изложенном в статье виде) давно устаревший. Кроме срочности и важности, как Вы правильно заметили, есть ещё ресурсоёмкость (начиная с потребного времени), а также эластичность / непредсказуемость. В современном виде это выглядит примерно так:
1) Срочность <—> Потребное время выполнения
2) Важность <—> Стоимость
3) Эластичность <—> Непредсказуемость
Если с первыми двумя пунктами всё более-менее понятно — срочность считается не как «срочность в чистом виде», а как срочность минус потребное время выполнения, важность по тому же принципу относительно стоимости — то про третий пункт следует сказать особо.
Собственно, это возможность декомпиллировать задачу или объединить её с иными (в том числе, чужими) — в противопоставлении с неопределённостью её статуса. То есть, чем задача «покладистей», тем выше её приоритет. Что прекрасно выражает старая армейская мудрость: «Не спеши выполнять приказ, дождись следующего, что его отменяет».
Соответственно, чем проще передать задачу другим людям, объединить её с иной задачей или разбить на подзадачи, имеющие самостоятельную ценность — и чем меньше вероятность изменения или полной отмены этой задачи по ходу её выполнения — тем она приоритетней.
Вот как-то так, если не вдаваться в подробности.
1) Срочность <—> Потребное время выполнения
2) Важность <—> Стоимость
3) Эластичность <—> Непредсказуемость
Если с первыми двумя пунктами всё более-менее понятно — срочность считается не как «срочность в чистом виде», а как срочность минус потребное время выполнения, важность по тому же принципу относительно стоимости — то про третий пункт следует сказать особо.
Собственно, это возможность декомпиллировать задачу или объединить её с иными (в том числе, чужими) — в противопоставлении с неопределённостью её статуса. То есть, чем задача «покладистей», тем выше её приоритет. Что прекрасно выражает старая армейская мудрость: «Не спеши выполнять приказ, дождись следующего, что его отменяет».
Соответственно, чем проще передать задачу другим людям, объединить её с иной задачей или разбить на подзадачи, имеющие самостоятельную ценность — и чем меньше вероятность изменения или полной отмены этой задачи по ходу её выполнения — тем она приоритетней.
Вот как-то так, если не вдаваться в подробности.
Ух ты! А где о таком подходе можно больше почитать?
Матрица Эйзенхауэра — подход (в изложенном в статье виде) давно устаревший.
Весь цимес этого подхода сосредоточен в квадрате «важно, но не срочно», т.е. долгосрочное планирование. Если долгосрочное планирование проводится тщательно, то количество срочных задач значительно уменьшается и появляется возможность их своевременной реализации.
Вот этот подход и устарел, в первую очередь. Потому что сейчас время течёт очень быстро, всё стремительно меняется, долгосрочное планирование становится всё более проблематичным в силу постоянно растущего потока новой информации и новых задач. Стратегическая расстановка приоритетов «из будущего» теряет приоритет в силу пункта 3).
Повышается «мощность» информационного шума, фундаментальные, системообразующие процессы наоборот тормозятся в связи с ростом продолжительности жизни людей, IMHO роль долгосрочного планирования только возрастает.
Рост непредсказуемости только повышает требования к способности создавать и адаптировать стратегии. Иначе окажешься в ситуации Кэрролловской Алисы — вроде и бежишь со всех ног, но на месте.
Производственные цепочки удлиняются, поэтому грамотное планирование становится всё более необходимым. Чтобы разработать новую модель BMW, сделать под нее конвейер и комплектующие, надо больше планирования, чем для разработки Нивы или консервной банки. А то что за последние 50 лет не смогли ничего придумать лучшего, чем переставить двигатель у боинга с потерей балансировки — это оно и есть — показатель кризиса планирования «из будущего».
Квадрант «важно и срочно» имеет не меньшее значение, так как туда попадают все ошибки долгосрочного планирования. Соответственно по каждой задаче из этого списка стоит проводить разбор полётов на тему «как избежать повторения этой ситуации в будущем»
За много лет работы следую правилу, что задачи, которые можно решить за 10 минут, должны быть решены в тот же день. Во-первых, позволяет не накапливать задачи, во-вторых, иногда полезно отвлечься на 10 минут от основной задачи.
Не программист.
Не программист.
Аристотель, «Никомахова Этика»
Всякое искусство и всякое учение, а равным образом поступок и сознательный выбор, как принято считать, стремятся к определенному благу. Поэтому удачно определяли благо как то, к чему все стремится.Без понятия «наивысшее благо» или максимизации функции полезности/блага получается «социальный аспирин», о котором писали ранее. Для более глубокого понимания нужно вводить понятия миссия компании и общее дело команды.
…
Если же у того, что мы делаем, существует некая цель, желанная нам сама по себе, причем остальные цели желанны ради нее ..., то ясно, что цель эта есть собственно благо, то есть наивысшее благо.
Разве познание его не имеет огромного влияния на образ жизни? И словно стрелки, видя мишень перед собою, разве не вернее достигнем мы должного?
Некогда читал заметки автора системы Планфикс, где они придумывали как правильно сделать приоритеты задач в системе.
На то время я тоже искал ответ на вопрос как эффективно ставить приоритеты?
Там ребята пришли к выводу что единственно верная система — это плоский список задач.
Вообще слово Приоритет если изучить его этимологию означает «Первый». Сколько задач одновременно могут быть первыми? :)
И вот когда заставляешь всех работать по такому списку, где физически не возможно 2 задачи поставить на 1е место ) Вот тогда люди реально начинают думать. А разработчики реально понимают что надо делать.
В идеале. В реальности конечно и эту систему можно сломать и изуродовать. Но ничего лучше пока не нашел.
Еще это называется Backlog в мире Agile. Который вам как то не по душе. Судя по некоторым мыслям проскакивающим в тексте.
Например. Иногда подключаюсь к проектам/командам, в которых творится хаос, не понимание между руководством и разработчиками, полная чехорда. Одни орут что сроки не исполняются, другие что задачи не внятные. И просто привожу все задачи к плоскому списку ) Не сразу, но спустя 1-2 месяца ситуация самоорганизуется )
Плоский список задач — это проще чем матрица ) Играть с матрицей кончил лет 10 назад.
Я боюсь представить что будет когда вы узнаете что такое OKR )
На то время я тоже искал ответ на вопрос как эффективно ставить приоритеты?
Там ребята пришли к выводу что единственно верная система — это плоский список задач.
Вообще слово Приоритет если изучить его этимологию означает «Первый». Сколько задач одновременно могут быть первыми? :)
И вот когда заставляешь всех работать по такому списку, где физически не возможно 2 задачи поставить на 1е место ) Вот тогда люди реально начинают думать. А разработчики реально понимают что надо делать.
В идеале. В реальности конечно и эту систему можно сломать и изуродовать. Но ничего лучше пока не нашел.
Еще это называется Backlog в мире Agile. Который вам как то не по душе. Судя по некоторым мыслям проскакивающим в тексте.
Например. Иногда подключаюсь к проектам/командам, в которых творится хаос, не понимание между руководством и разработчиками, полная чехорда. Одни орут что сроки не исполняются, другие что задачи не внятные. И просто привожу все задачи к плоскому списку ) Не сразу, но спустя 1-2 месяца ситуация самоорганизуется )
Плоский список задач — это проще чем матрица ) Играть с матрицей кончил лет 10 назад.
Я боюсь представить что будет когда вы узнаете что такое OKR )
Так все эти матрицы и нужны для того, чтобы выстраивать линейную систему приоритетов (какой же ещё она может быть?..). Это метод сортировки, не более.
Метод группировки, см. ниже
Согласен. Но у каждого человека своя матрица в голове.
И какие бы там матрицы не придумали — плоский список в любом случае создаст порядок и приоретизацию.
А какими там матрицами задачи будут подниматься вверх, а какими вниз — дело вкуса. В команде из 5 человек будет 5 матриц, часть из которых будет очень не понятной, но в ходе обсуждения люди быстро договорятся что надо поднять. И так наступит порядок.
Я не против этой матрицы. Если надо можно обосновать и через нее. Но из своей практики могу сказать что главное это плоский список. А до матрицы Важности и Срочности обычно дело не доходит. Просто люди договариваются и спокойно работают над тем что приоритетно. А все что второстепенно падает вниз… иногда закрывается так и не дойдя не до каких матриц. И это хорошо.
И какие бы там матрицы не придумали — плоский список в любом случае создаст порядок и приоретизацию.
А какими там матрицами задачи будут подниматься вверх, а какими вниз — дело вкуса. В команде из 5 человек будет 5 матриц, часть из которых будет очень не понятной, но в ходе обсуждения люди быстро договорятся что надо поднять. И так наступит порядок.
Я не против этой матрицы. Если надо можно обосновать и через нее. Но из своей практики могу сказать что главное это плоский список. А до матрицы Важности и Срочности обычно дело не доходит. Просто люди договариваются и спокойно работают над тем что приоритетно. А все что второстепенно падает вниз… иногда закрывается так и не дойдя не до каких матриц. И это хорошо.
Это ж за менеджер, который не знает важности и срочности задачи? Менеджер и должен собирать в один список как бизнес задачи, так и технические от команд и выставлять сквозные приоритеты.
Тезисно
1. Важность и срочность необходимо аргументировать. Каждый раз, для каждой задачи. Автор привел их определение, но почему-то, против моих ожиданий, не сказал, что это обязанность инициатора в задаче написать, почему, по каким узаконенным признакам, эта задача считается столь важной/срочной. Если инициатор этого не пишет, то задача по умолчанию не важная и не срочная. Исполнитель может поднять ей приоритет, а может и не поднять.
2. Деление по важности и срочности годится только для предварительной группировки (не сортировки) задач. Получаем четыре группы, но внутри каждой группы задачи не упорядоченны.
3. После группировки можно присвоить приоритет задачам. Приоритет задачи — это не важность или срочность, а ее положение в общем пуле задач. То есть приоритет является производной величиной. Например, можно взять за правило назначения приоритета:
— 100-299 — низкий приоритет
— 300-499 — обычные текущие задачи
— 500-699 — важные задачи
— 700-899 — срочные задачи
— 900-999 — критические задачи, всё упало, все на абордаж!
По умолчанию назначается нижняя граница. Задачи могут иметь один приоритет, если нет значения, в каком порядке их выполнять. Задачам стоит дать разный приоритет, если из каких-либо соображений одну стоит сделать раньше другой.
4. Задачи делаем в порядке убывания приоритета, но тут надо не забывать про взаимосвязи задач — сдача в тираж, конечно, срочная и важная задача, но не стоит ее делать прежде, чем будет готов продукт.
1. Важность и срочность необходимо аргументировать. Каждый раз, для каждой задачи. Автор привел их определение, но почему-то, против моих ожиданий, не сказал, что это обязанность инициатора в задаче написать, почему, по каким узаконенным признакам, эта задача считается столь важной/срочной. Если инициатор этого не пишет, то задача по умолчанию не важная и не срочная. Исполнитель может поднять ей приоритет, а может и не поднять.
2. Деление по важности и срочности годится только для предварительной группировки (не сортировки) задач. Получаем четыре группы, но внутри каждой группы задачи не упорядоченны.
3. После группировки можно присвоить приоритет задачам. Приоритет задачи — это не важность или срочность, а ее положение в общем пуле задач. То есть приоритет является производной величиной. Например, можно взять за правило назначения приоритета:
— 100-299 — низкий приоритет
— 300-499 — обычные текущие задачи
— 500-699 — важные задачи
— 700-899 — срочные задачи
— 900-999 — критические задачи, всё упало, все на абордаж!
По умолчанию назначается нижняя граница. Задачи могут иметь один приоритет, если нет значения, в каком порядке их выполнять. Задачам стоит дать разный приоритет, если из каких-либо соображений одну стоит сделать раньше другой.
4. Задачи делаем в порядке убывания приоритета, но тут надо не забывать про взаимосвязи задач — сдача в тираж, конечно, срочная и важная задача, но не стоит ее делать прежде, чем будет готов продукт.
Вот перестала у клиента работать база – чинить надо срочно или нет? По критерию – нет, т.к. базу нужно поднимать и сейчас, и завтра, и через неделю.
Через неделю клиент разорвёт контракт, или организация-подрядчик разорвёт контракт с исполнителем. Если клиент готов мириться с недельным простоем, то это, действительно, несрочно.
Начнем со срочности, т.к. она приоритетнее важности.
Что-то мне подсказывает, что такой подход к делу вызывает «Эффект дырявого стека» очень хорошо описанного Максимом Дорофеевым в его «Джедайские техники» пункт 2.3.2. Благодаря этому подходу каждое новая входящая задача автоматически становиться более важной и срочной чем та, которая поступила 5 минут назад и соответственно шанс ее выполнения резко падает.
Не зря в статье есть много реальных замечаний
К сожалению, многие менеджеры склонны называть срочными задачами все подрядили
Менеджеры, поняв систему приоритетов, начинают лепить срочность и важность всем задачам подряд, особенно когда за менеджером или клиентом не закреплен конкретный программист.А вот maxxannik очень точно подметил
И просто привожу все задачи к плоскому списку ) Не сразу, но спустя 1-2 месяца ситуация самоорганизуется )— плоский список задач и поможет избежать такой ситуации.
Также автор лихо перемешал задачи с проектами:
А есть задача клиента, решив которую, вы получаете проект. Есть центральная задача этапа проекта, которая переводит его из тестирования в эксплуатацию.Кажется здесь идет речь именно о проекте, а не о задаче.
ИМХО, статья сильно запутывает в отношении того, на что нужно действительно обращать внимание.
кроха сын к отцу пришел,
и спросила кроха
Важно — это хорошо?
срочно — это плохо?
папа репу почесал
и ответил крохе
чтоб на харбе почитал
на одном из блохов
и спросила кроха
Важно — это хорошо?
срочно — это плохо?
папа репу почесал
и ответил крохе
чтоб на харбе почитал
на одном из блохов
Программисту становится сложно выбирать.
О, как это знакомо :) Сначала все задачи плавно стали Major. Потом Critical, потом Blocker. Мы уже шутим: пора вводить "Critical Blocker" :-D
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что важно, а что — срочно?