Должны ли руководители проектов обладать техническим опытом?

Должны ли руководители проекта обладать техническим опытом? Эта тема всегда была на слуху. Некоторые верят, что все необходимое для управления проектом - это сертификация PMP, другие уверены, что нельзя успешно управлять проектом по разработке ПО без полного понимания всех сложностей продукта. Я придерживаюсь такой же точки зрения! Для того, чтобы быть эффективным руководителем проекта, вы должны знать все – от А до Я. Вы должны быть способны разработать все сами.

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

Прогноз усилий

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

Если вы не знаете, что необходимо для достижения полной надежности, то вы не сможете оценить все усилия, необходимые для достижения данного нефункционального требования. Если вы не знаете, как написать Java Server Pages, то вы не сможете предсказать, сколько усилий необходимо для преобразования HTML-прототипа в набор полнофункциональных JSP-страниц.

Планирование задач

Представьте себе, что кто-то передает вам список дел и требуемые усилия, которые необходимо применить для заданного проекта. Смогли бы вы спланировать все задания в логической последовательности? Должны ли разработчики начинать с представительского, информационного или бизнес-уровня? С чего начать при работе с представительским уровнем: с HTML, JavaScript, CSS или сервлетов?

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

Оценка риска

Представьте себе следующий случай - ваш продукт должен быть готов через 5 дней. Команда технического контроля находит дефект в интерфейсе посредством серии CLI-тестов. После изучения проблемы вы понимаете, что вы разработчики работали, обходя данный дефект стороной несколько месяцев.

Зная, что у вас всего 5 дней на выпуск товара, будете ли вы исправлять проблему или задокументируете обходной путь? На данном этапе как сильно вы рискуете, если решите изменить программный интерфейс? Насколько вы уверены в том, что разработчики смогут исправить данный дефект в заданные сроки? Какова вероятность того, что изменение данного интерфейса не вызовет неисправность в вызывающих модулях? Стоит ли исправлять дефект сейчас или выпустить проект и исправить  огрехи в последующих заплатках?

Если вы не видели код данного интерфейса, вы не можете ответить на данные вопросы. Вам придется спросить разработчиков. А потому вы не являетесь тем, кто примет решение - его примут они.

Участие во встречах с клиентом

Встречи с клиентами всегда заканчиваются обсуждением технических аспектов. К несчастью, если вы не можете проявить свою эрудицию с технической стороны, то вы не привнесете ничего в данное обсуждение. Вы не участвуете в них, вы только слушаете и, наверняка, записываете. Рано или поздно клиенты будут сами связываться напрямую с разработчиками. В самом деле, зачем связываться с руководителем проекта, если он не может ответить на вопросы? Легче обратиться напрямую к исполнителям.

Страховка

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

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

Вкратце...

Чтобы быть эффективным руководителем проекта, вы должны  уметь разрабатывать  продукт сами. В противном случае у вас два варианты – либо вы (a) попросите других принять вместо вас  решение, либо вы (b) сделаете вид, что вы понимаете о чем говорите. В первом случае вы координируете проект, а во втором  - вы вредите проекту.