Книга: Искусство управления IT-проектами

Правильно расставляйте приоритеты

В качестве руководителя проекта большую часть своего времени я тратил на составление разнообразных списков приоритетов, расставляя задания по степени важности. Я был убежден, что несмотря на все знания, которые за мной числились, вся моя деятельность, фактически, сводилась к составлению этих списков. Я сгребал в кучу все, что нужно было сделать, включая требования, характеристики, ошибки, в общем, все, а затем расставлял все это по степени важности для проекта. Целыми днями я занимался правкой этих списков, включая в них новую информацию, затевая вокруг них обсуждения и споры с другими специалистами, и всегда доводил свои списки до полного совершенства. После этого я упорно вел команду в соответствии с указанным в них порядком следования заданий. Иногда в этих списках фигурировал мой ежедневный распорядок работы, иногда – прикидки, чем будут заниматься группы людей в течение ближайших месяцев. Но процесс и эффект от него оставались прежними.

Я уделял так много времени составлению списков, поскольку знал, что правильная расстановка приоритетов – это залог прогресса. От четкого определения понятий, что является главным, а что второстепенным, от влияния этих понятий на каждый шаг в работе команды зависит успешная реализация всего замысла. Расстановка приоритетов должна отражаться в каждом посланном вами электронном сообщении, в каждом заданном вопросе и на каждом проводимом совещании. Каждый программист или тестировщик должен вкладывать свою энергию в те дела, которые напрямую ведут к успеху. А кто-то должен определять, что это за дела, и заставлять команду ими заниматься.

Больше всего к пустой трате времени при работе над проектом приводит путаница в заданиях и в очередности их выполнения. Многие недоразумения и оплошности происходят из-за того, что некто А предполагает одни приоритеты (добиться результата как можно быстрее), а некто Б – другие (добиться стабильности в работе продукта). Такое случается с программистами, тестировщиками, маркетологами, как, впрочем, и со всеми остальными специалистами команды. Если подобных конфликтов удастся избежать, то останется больше времени на достижение реальных целей проекта.

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

Возражения вряд ли возникнут или окажутся кратковременными, если список приоритетов будет вывешен на стене, чтобы каждый мог познакомиться с согласованной очередностью действий. Списки приоритетов дают всем возможность усвоить общую логическую структуру, исходящую из принятых решений. Если приоритеты ясны и понятны, то не нужно тратить время на их тщательное разъяснение.

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

Оглавление книги