В моей картине мира приоритет каждой задачи – уникален. Его можно выразить одним числом, но оно не должно повторяться. Уникальное значение приоритета равносильно выстраиванию задач в общую очередь: сверху самые важные задачи, внизу – то, без чего никто не сдохнет. Мысль не нова, не я первый придумал такой способ приоритезации, но замолвить об этом словечко хочется.
Итак, почему очередь лучше, чем приоритеты вида 1,2,3?
Мысль первая
Если число задач превышает возможности команды, то все эти коды приоритетов рано или поздно сводятся к двум: «нужно делать» и «не нужно делать». Естественно, не явно, но сводятся. Что означает «приоритет 3»? Это значит, что приступать к этой задаче стоит, когда выполнены все задачи с приоритетом 2. А эти задачи не могут выполняться, пока есть задачи с приоритетом 1. Вы можете вспомнить, когда у вас не было задач с приоритетом 1? Все команды, с которыми я так или иначе сталкивался, львиную долю своего времени уделяли задачам только первого приоритета. Задача с приоритетом 3 как правило мариновалась до тех пор, пока для заказчика она не будет иметь приоритет 1. В итоге все сводится к реактивной методике – FDD (Fuck-up Driven Development).
Мысль вторая
В системе приоритетов «1,2,3», стоимость повышения приоритета не очевидна для заказчика. Если заказчику кажется, что команда выполняет его задачи не так быстро, как ему хотелось бы, то появляется великое искушение выбрать какую-нибудь задачу и сказать: «Парни, теперь у нее приоритет 1». Сказать легко. Но подобные трюки не проходят бесплатно – повышение приоритета одной задачи неизбежно отражается на выполнении других, и механизм очереди способен это наглядно показать. Если задача действительно важная, то мы берем и поднимаем ее выше. Естественным образом все задачи между старым и новым местами в очереди сдвигаются вниз. Многие ненавидят этот механизм...
Мысль третья
Человек не способен эффективно выполнять больше одного дела одновременно. Наиболее эффективный режим – взять ОДНУ задачу, сделать, взять еще ОДНУ, сделать, и т.д. Таким образом, если число задач превышает допустимую область значений параметра «приоритет», то неизбежно у нас будет несколько задач с одинаковым значением этого параметра. Хорошо. Перед нами куча задач, с приоритетом 1, так все-таки, какую из них взять первой? Не понятно? Конечно! Нужно ввести еще тучу параметров, определяющий серьезность, стоимость, возврат инвестиций, бизнес необходимость, значимость для репутации… Потом обязательно придумать страшенную формулу, по которой рассчитывать очки кармы для каждой задачи. И все равно, какую из этой кучи начать делать первой? Конечно! Нужно собраться и обсудить. В итоге будет решено, что 5 задач из этой кучи все-таки самые важные и на каждую из них нужно назначить 20% ведущего разработчика… Это дорога в ад.
Делать 5 задач одновременно – самый лучший способ искренне затрахаться, без всякого полезного результата.
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92)
cartmendum- cartmendum
Comments
В моей религии число одновременно активных задач на человеке индивидуально и решается совместно.
Я не знаю, почувствовали ли Вы, но "обезьянки против роботов" стали бомбой. Наверное, им не быть в топах яндекса (туда попадают всякие бездомные собаки, тимати, тёмы лебедевы и пр). Потому что целевая аудитория сильно шире. Тем не менее, волна пошла. У вас есть реальный шанс сформировать вокруг себя российское IT-сообщество (имхо его сейчас ещё нет). А то ходят слухи о всяких джагах и пр, но они все мёртвые по ходу. Из живых тем только hackdays на ум приходят.
Такой шанс выпадает не всем. Пользуйтесь. Люди за Вами пойдут. Может получиться очень и очень интересно.
P.S. Вы не думали написать книжку? Или публиковаться в журналах? Думаю, уровень доверия у публики был бы очень высок.
То, что обезьянки популяризовались, я уже заметил по счетчику просмотров: 2500 просмотров первой части и по 1000 второй и третьей. За месяц, для слайдкаста, где нет ни одной сиськи - не плохо.
Вести за собой кого-то - об этом я пока и не думал. Я не на столько крут и опытен, что бы говорить всем куда и как надо идти. Честно говоря, я и сам-то пока не чень понимаю, куда эта вся индустрия должна попасть.
Про книжку думаю... Есть мысль собрать "курс естествознания для менеджера проекта" в единое целое и опубликовать. Ну и еще мне предложили чего-нибудь в PMMagazine опубликовать. В начале декабря это чего-нибудь им пошлю, то есть в первом квартале следующего года опубликуют.
Еще раз спасибо за лесть :)
Хрен с ней с индустрией. Главное, чтобы люди обменивались хорошими практиками. Вам это интересно, иначе бы вы не занимались докладами, конференциями, не писали бы о инженерии в блоге и пр.
Вам интересно рассказывать. А слушать? Если да, то это и есть шаги к комьюнити.
Тогда я встал и спросил его: дяденька, а где ты видел хороших программистов? Таких, чтобы писали быстро, понятно и безглючно. В сказках? Во сне? А ну-ка покажи-ка мне хоть одного!
В общем, подобных вопросов дяденька больше не задавал.
Безусловно, выстроить все задачи в порядке убывания уникального приоритета - звучит заманчиво. Но как это сделать? Боюсь, что эта задача превратится в нечто, что ты сам описал как "ввести еще тучу параметров, определяющих серьезность, стоимость, возврат инвестиций и т.п.... потом обязательно придумать страшенную формулу, по которой рассчитывать..." уникальный приоритет, а не карму.
И ещё одно замечание. Описанные мысли верны для одно-конвейерной системы. Если же у нас 20 конвейеров (работников), то вполне допустимо будет иметь 20 задач с приоритетом 1, которые мы распределим по одной на каждого.
Сейчас я делаю симбиоз из TFS и доски. Думаю, получится софтинка, которую потом в опенсорс вывалю.
С уникальным приоритетом согласен, нужно сделать оговорку, что приоритет должен быть уникальным в пределах одного конвеера (я их пайплайнами называю).
А вообще6 вспмню о себе:
Программировать - минимум 4 часа между переключениями, и не мешайте мне, сволочи.
Тестирование и ТП - полчаса-полтора часа чтоб переключиться.
Инфраструктура - 1-2 параллельно.
Раз в итерацию мы тупо берем пять задачек сверху и уходим в себя на неделю. А то, что в общей куче осталось - пусть хоть пять раз на дню перетасовывают.
Соответственно, единственный момент, когда текущее состояние приоритетов влияет на работу - это небольшой промежуток времени, посвященный планированию следующей итерации (пока где-то 2 часа в неделю).
Какие то вы все сферические в вакууме. Если такое творить - без пулемета никак. Хотя, неделя. Может и можно, если пару раз показать что эффективно. Но в себя уходить надо как минимум на другой конец города. Ведь подойдут же, все такие вежливые...
P.S. Все нормальные в это время спят.
Приоритеты ставят третьи лица - в некоторых условиях как раз без этого никак. У нас все заказчики - это коллеги из других департаментов той же компании. Для приоритезации нужен человек, способный исходя из текущей стратегии компании понять, что важнее подготовить цифры для маркетингового исследования, прикрыть дырку от хакеров или вложится в инфраструктуру. И это получается реально большая работа.
Всегда полезно составить списочек из 5-7 задач, отсортировать их по своим приоритетам и отправить заказчику с эстимэйтами на утверждение. Почти всегда заказчик его утвердит с мелкими изменениями:
- ему лень вникать
- все задачи делать надо, а тут умный человек советует.
Проверенный способ разгребать список из супер-топ-хай-эмергенси-первоочередных задач.
Кстати, большое количество задач с одинаковым приоритетом дает возможность самостоятельного выбора. "Вася, какая из задач #1122, #1223, #12, #32" тебя больше всего привлекает?
Но идея конечно же правильная. Именно по этому ITIL-овские парни и предлагают поддержку выстраивать в несколько линий обороны.
И еще один момент. "Вася, какая из задач #1122, #1223, #12, #32" тебя больше всего привлекает?" - так я пробовал. Потом поговорил с этим Васей на чистоту, а он сказал, знаешь, не надо так делать. Мне так или иначе приходится вникнуть во все 4, и они у меня потом крутятся в голове, пока я их все не сделаю.
Так что все индивидуально. Если парень практикует GTD, то ему можно давать выбрать. Если он не способен контролировать крутящееся у него в голове, то лучше не пытаться.
А каков смысл приоритета 1,2,3 у бага?
Есть есть 100 задач, то как просто определить что нужно делать (и составить последовательность решения этих задач), а что делать будем потом? Возможно (я не уверен), что приоритеты как раз помогают решать эту задачу. Как вы думаете?
Я работаю над созданием программ (использую систему trac). Приоритеты не использую. В трак забиты все задачи, которые вообще надо бы когда-нибудь решить. Есть milestone-ы: версия 31, версия 32, версия 33 и т.д. При планировании что будет сдеално в новой новой версии системы, выбираются задачи, которые жизненно необходимы для выпуска именно этой версии - логика простая: все что можно сделать потом должно быть сделано потом. Проблема в том, что мало удобно выбирать все эти задачи - нужно просмотреть все существующие.
Сейчас наша работа это не выпуск продукта, а деятельность, которая ближе к поддержке: со всех сторон постоянно приходят новые запросы. Запросы, в отличие от багов, должны быть выполнены почти все (а не так, что 100 багов из 1000 починили, и хватит). По своей сути каждый запрос - это относительно небольшая задача (1-3 дня работы), но их много...
И приоретизировали мы все при помощи доски: