Про задачки простые и не очень

clip_image002Одно из подразделений разработки в нашей компании использовало так называемые задачи-какашки (см. первую картинку). Это такие мелкие задачки, которые можно взять и быстро сделать. Что следует из быстро сделанной задачи? Правильно: рост удовлетворения, мотивации, и повышение уровня гормона «шиловжопин» ( (с) Cartmendum). Ну и задача, однако, тоже выполнена. Закидывались эти задачки в очередь команде тимлидом по какому-то набору принципов, из которого нам сейчас интересно только одно правило:

clip_image004

То есть количество таких задач должно быть ограничено. Причем, в разработках есть разные agile и прочие водопады, которые с помощью спринтов дополнительно позволяют ограничить объем задач на единицу времени. То есть хочешь, не хочешь, а более другими вещами заняться тоже придётся. В итоге, и фокус сохраняется, поскольку очередь задач конечна (это вообще достаточно важно), и мотивация от того, что нет выбора, что сделать (хотя выбор по прежнему иллюзорен ;) ), и приходится делать эту «мерзскую задачслу» прямо сейчас, тоже не сильно падает, поскольку чуть-чуть ее отложить можно.

В общем, в разработческом мире с этим если и не порядок, то хотя бы видимый порядок. А что в админском мире? А у нас получается следующая картина:

1) Нет никакой ложки никакого SCRUM‘а

2) Есть мнение, что задача, которая делается чистым временем полчаса, не должна делаться 2 недели. Это мнение ничем не обосновывается ничем, разве что «ну тут же полчаса»

3) График, показывающий сколько дней задачи валяются в беклоге выглядит вот так:

clip_image006

То есть ряд задач не выполняется вообще (внимание, вопрос: что это за класс задач обычно? ;)).

Как итог, количество таких мелких и приятных задач потенциально бесконечно, а тяжелые и неинтересные задачи как раз и сваливаются в категорию задач «More than month». Ну и часть проектов сдается с запозданием

Есть ли способы сохранять возможность ковырнуть мелкую задачу в промежутках между «тяжелыми», не откладывая последние навсегда? Вот, что пришло в голову за какое-то время:

1) Все-таки поставить ограничитель. Варианты:

a. Честность исполнителя

b. Физический ограничитель: количество таких-то задач не более, чем X%

c. Другой физический ограничитель: мы берем на неделю такие-то задачи, а остальные… Через неделю приходите

2) Забить на это дело: задачки ж выполняются, отчеты пишутся. А что проекты не в срок сдаем – так смотрите, сколько текучки – не успеваем, добавьте ресурсы.

3) Выполнять все строго по порядку. Не позволять изменять приоритет задачи в ближнем горизонте ни под каким соусом.

4) Считать задачи определенного типа более приоритетными, чем другие. То есть, если есть такая задача есть в беклоге, то за другие браться запрещено. По сути, это 1b, но с плавающим процентом.

У меня есть ощущение, что таксономия выше не полная. Есть ли у зала еще варианты?

Оценить плюсы и минусы этих вариантов, как я их вижу, я попробую чуть позже.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s