Решебник начинающего руководителя проекта

Результат важнее процессов!

Исходя из этого выставляй приоритеты, разрешай споры и фокусируй работу.

Повторим в очередной раз главное, что надо запомнить из этой главы:

– Главное – результат.

– Результат должен быть получен в определенный срок.

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

– Обсуждение деталей проекта должно проходить в контексте планируемого финального результата.

Помни об этом постоянно, пока выполняешь роль менеджера.

За что отвечаю я? \ Роль менеджера проекта

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

Так случилось, что в IT основной ресурс, используемый при выполнении проектов, – это интеллект. Мы не будем называть членов команды «ресурсами», потому что это обидно. Но на наших с тобой графиках и расчетах проекта будет именно так.

Давай прикинем, какие бывают роли в проектах и какого вклада ждать от каждого представителя команды.

– Разработчик – «производитель» программного кода и, собственно, создатель программного продукта. Именно он создает осязаемый результат. Главный его вклад – регулярное производство новых функций и возможностей в финальном продукте.

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

– Аналитик, дизайнер, архитектор, проектировщик – довольно близкие по смыслу роли. Это специалисты, способные представить будущий продукт в виде модели: процессов, сценариев, дизайнов интерфейса, модулей, сервисов, объектов и компонент. Зачем? Да чтобы уменьшить вероятность ошибки в разработке.