Трекинг задач. Больше учить, а не контролировать.

Основная проблема при организации работы в QA — нужно помнить всё и даже то, что было давно. Чем больше задач на входе, тем быстрее всё уходит в лёгкий хаос и таски начинают подвисать, и время на переключение между задачами начинает стремительно расти. Вместе с этим растет уровень стресса, а эффекстивность стремится к нулю. Прокрастинация довершает дело и приоретизация задач начинает строится на «хочу» вместо «надо». И вроде бы задачи делаются, но дело стоит.

В Agile и Lean, для организации используется доска задач и бумажки с тасками, которые на неё крепятся. Доска разбивается на несколько колонок или секторов, упрощая — «входящие», «в процессе», «сделано» и «завершено». Во «входящие» ставятся все задачи, приходящие из вне. Дальше задачи с учетом приоритетов и загруженности команды переносятся в колонку «в процессе» и закрепляются за кем то. В зависимости от команды задачи могут идти в общем пуле, либо раскидываться по конретным людям сразу, что довольно рискованно. Когда задача сделана — она переносится либо в «сделано», либо в «завершено» в зависимости от того требуется ли подтверждение или нет. Например, при успешной проверке, дополнительное подтверждение не требуется, мы ведь доверяем тестировщику? Но при разработке тестового сценария неплохо бы посмотреть нескольким людям на результат. После этого на следующий день, после релиза или любой другой выбранной точки бумажка с таской выбрасывается.

Использование доски и бумажек позволяет физически видеть загрузку, что в целом может мотивировать команду, до тех пор пока на доске не окажется вся пачка офисной бумаги. А в QA это очень быстро происходит, если учитывать задачи на тестирование, тест кейсы и внутреннюю разработку. Использование Jira и вообще трекеров задачу не решает. Там происходит точно такая же свалка задач за которой перестают следить, только намного проще и быстрее.

Для того, чтобы этого не происходило все участники команды должны уметь работать с задачами. Тут есть несколько моментов, которые этому мешают – отсутствие такой практики вообще, отсутствие системы для трекинга, нежелание тратить время на написание комментариев (в открытую объясняемое нелюбовью к бюрократии, а в подсознании боязнью наказаний за обнаруженные недочеты), неумение выражать свои мысли, непонимание смысла и ценности такой работы.

Технические проблемы легко решить – установить любую систему – dotProject, Eventum, Jira. В целом не имеет значения, но с психологическими стопорами так легко может и не получится. Что же тогда делать?

Контроль — это решение. Логично, есть люди как ресурс, которые что то делают. Что, как и когда делать им говорят. Зачем разбираться в первопричинах отказа говорить о своей работе? Процесс регистрируется в задачах, записи контролируются. Но в результате время будет тратиться только на контроль, да и психологически это будет только давить, в худшем случае работа будет незаметно саботироваться, в обычном выполняться формально. Требовать от наемных рабочих горячей любви к компании за зарплату бесполезно (корреляции между деньгами и лояльностью чаще всего нет), программы мотивации работают, но они не нацелены на конкретного работника и в среднем по больнице температура то нормальная, но…

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

  • «прозрачность работы», «контролируемость» является пустым звуком в большинстве случаев. Ведь это ничего не приносит тому, кто описывает свою работу. И лучшим аргументом становится часто то, что от того, как описана задача зависит работа всех участников. Потому что в случае отпуска (неприятные события лучше не упоминать, мне кажется). Описание в задаче будет единственной помощью для остальных.
  • Показать на своём примере как можно работать с задачами, и пример должен быть не один. Кому то может не понравится писать много текста о работе, кому то напротив захочется записать много данных. Разные вариации описания своей работы позволяют остальным выбрать наиболее близкий, понятный и приятный стиль.

Leave a Reply

Your email address will not be published. Required fields are marked *