Распределение задач и планирование

Было в моей работе такое время, когда я год работала единственным тестировщиком на всех проектах и частично мне помогал ПМ. В ту счастливую пору необходимости письменного планирования задач у меня не было по причине того,что
1. вся команда сидела в одной комнате и могла спросить, чем я занимаюсь
2. На документирование уходило драгоченное время, которого было очень-очень мало и так
3. Я и так знала,чем мне заниматься, и моей работой не руководил никто,кроме меня самой.
Однако,с появлением нескольких людей в команде тестеров и большого количества проектов, возникла-таки необходимость в документированном планировании работы отдела. Я задумалась об этом тогда, когда вопросы типа "Что мне сегодня делать?" от членов команды начали меня сердить по причине того, что то,что я запланирвоала себе, нужно было отодвинуть, дабы проанализировать ситуацию и придумать им задачу :)

Взяв за основу формат эксель-расписания, который использовался на моем предыдущем месте работы, я продолжила его импрувить.
1. Определила каждую строку экселя = 0,5 часа.
Чтобы визуальный вид длительности задач был примерно пропорционален их распределению в дне. К сожалению, не всегда получается сохранять пропорции, но я стараюсь :)
2. Добавила поле TOTAL к каждому дню, которое содержит общее количество часов.
Это было вызвано тем, что в моей компании свободный график, и можно работать в один день 5 часов, а в другой 13. все решает сам человек. Соотвественно, задачи тоже должны быть распределены на все время человека, которое он планирует потратить в день. Это также полезно для планирвоания бюджета - у нас QA могут не знать, сколько часов в день или сколько бюджета выделено на определенный проект. Но это должен знать человек, который распределяет задачи.
3. Цветовая индикация.
Каждый проект имеет свой цвет в плане. Это делает план более веселым :) А с практической точки зрения - проще посмотреть время, потраченное на работу над каждым проектом и те, для кого написан план, могут определить свои проекты, не читая их названия. Становится еще удобнее, если цвет проекта в экселе каким-то образом связан ассоциативно с проектом - например, основной цвет логотипа продукта. И ребята всегда знают, в какой проект им заносить свое время в системе учета времени.
4. Положила в SVN.
При коммите отправляю уведомление о том, что план был изменен и для кого.

Единственная серьезная проблема, которая возникает - это суппорт. Изза непредвиденных задач приходится переставлять некоторые между людьми или менять им дни выполнения. Это решается довольно просто - отложенные задачи я храню на страничке Template, которую копирую каждый раз при написании плана на новую неделю + в экселе довольно просто переставлять задачи - скопировал и вставил на другой день :)

В общем случае план выглядит примерно так (план работы остальных сотрудников находится на том же листе, ниже):

Естественно,что такие задачи, как репродюс кастомерских багов, добавляются не в начале недели, а по мере возникновения :)

О мечтах. Очень бы хотелось найти такую систему, в которую бы можно было настроить доступ нескольким пользователям с определенными правами, чтобы можно было перемещать задачи драг-энд-дропом, чтобы при перетягивании задач программа детектила, что ты ее переметил туда, где теперь в сумме получается больше 8ми часов,к примеру, и цветом выделяла эти дни... Но, к сожалению, все, что я встречала, было однопользовательским максимум с возможностью экспорта в ХМЛ,а о драг-энд-дропе и других желаемых функциях нет и речи :(

Планирование неопределенности, или почему задачи с пятницы всегда переносятся на понедельник?!

В силу своих обязанностей я каждую неделю пишу план работы каманды QA на неделю. (Следует сказать,что вместо методологии разработки - только хаос). Столкнулась с тем, что задачи с пятницы редко когда не приходится переносить на понедельник в связи с изменением в расписании.

Переносить задачи приходится потому, что возникают непредвиденные (для меня в момент написания плана) дополнительные задачи, например, баги от юзверей; заказчику предоставилась возможность презентовать свой продукт на конференции или тренинге,и ему срочно нужен новый билд с пофикшенными багами #x, #y, #z ("Да,я знаю,что вы должны были в пятницу выложить билд с пофикшенными 10 тикетами, но мне нужны только 5 и завтра!"); фидбек билда, запланированного на тестирование, а потом его внезапный приход, когда программист справился быстрее,чем ожидал и обещал; и т.д. и т.п, все то,с чем маленькая аутсорсовая компания сталкивается довольно часто.

Я думала о том,что было бы хорошо планировать какое то резервное время (так называемая "неопределенность") с учетом рисков, которые могут возникать, на n часов в неделю в зависимости от проектов, над которыми ведется работа. Такой подход позволил бы выдерживать эстимейты и приходить к концу недели с выполненным планом. Но в плане пустые поля уж точно будут выглядеть странно.
Строгие эстимейты, пожалуй, должны привязываться к итерациям, а не к неделям (в моей компании итерация редко длится неделю), ведь это гораздо критичней. Однако недели складыаются в итерации...

В данный момент ведение плана и организация работы, как есть сейчас, устраивает всех, кроме меня - с такой организацией работы отдел тестирования с трудом проэстимейтит выполнение какой-либо задачи и с еще большим трудом завершит ее в срок.

Думая о том, как решить эту проблему, я нашла несколько вариантов, которые имеют свои плюсы и минусы.

1. Заключение "мирного договора" между программистами и тестировщиками.

Такой договор может быть составлен на основе мастер тест плана или в любом другом виде. Суть в том, что документ должен определять сколько билдов мы ждем на тестирование и примерное время их выдачи. Также могут быть описаны правила поведения обеих сторон при появлении, снова-таки, форс-мажорных обстоятельств - например, время, которое тестировщики готовы дать программистам на переделывание фидбекнутого обещанного ранее билда. Не успел - извини...

Однако такой подход не приемлем для ПМов и вообще пагубно сказывается на фактической разработке, хоть и делает программистов более дисциплинированными.

2. Приоритизация задач.
При появляении новой внезапной задачи просить ПМа приоритизировать ее (если реально сложно сделать это самому), при этом обьяснив, что работа над проектами А и В сдвигается на n дней,если делать новую задачу срочно и всеми тестерами. Здесь могут найтись новые варианты распределения людей по задачам :) Пожалуй, у этого метода минус только в том, что необходимо отвлекать ПМа от его обязанностей. А с другой стороны, он ведает всей информацией о приоритетах и планах, так что без него тут не обойтись.

3. Планирование буфера неопределенности на основе имеющейся статистики.

Собрать информацию о подобных факапах за последние n месяцев, посчитать среднее количество часов в неделю (не арифметическое) и планировать работу не на 40,к примеру,часов, а на 40 минус среднее.

Минус - все равно недостаточно точно будет :(