Искусство управления IT-проектами - читать онлайн книгу. Автор: Скотт Беркун cтр.№ 33

читать книги онлайн бесплатно
 
 

Онлайн книга - Искусство управления IT-проектами | Автор книги - Скотт Беркун

Cтраница 33
читать онлайн книги бесплатно

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

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

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

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

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


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

Рис. 4.3. Основной график рассмотрения и корректировки концептуального документа


Как только концептуальный документ будет готов, стадия планирования завершится (см. рис. 4.3). Команда должна располагать информацией, необходимой для успешного проектирования в соответствии с поставленными целями. Если работа над концепцией велась в той последовательности, которая показана на рис. 4.2, команда должна приступить к проектированию, поскольку основные направления ей были известны заранее.

Перечень неудачных положений концепции (которых следует избегать)

За свою профессиональную карьеру мне приходилось читать десятки концептуальных документов и самые плохие из них содержали одни и те же стереотипы. Плохо составленные концепции не имеют целостности, не предлагают никакого плана и не выражают совокупности мнений. Вместо этого в них излагаются размышления и прописные истины. Если в концепции нет четкого взгляда на то, что должно быть сделано, руководители команд никогда не станут работать с душой, обрекая проект на провал. Герой фильма «Бойцовский клуб» («Fight club») Тайлер Дурден (Tyler Durden) говорит: «Если вы воткнете себе сзади перья, то все равно не станете курицей». Если вы создаете документ с надписью «концепция» на титульном листе, это еще не означает, что в результате вы получите именно концепцию. Можно делать все по правилам, проводить совещания, пользоваться формализованными документами и все же упустить всю суть, ради которой и создается концептуальный документ. Точно так же, как титул «руководитель проекта» не означает волшебного превращения всего, что вы делаете в действии руководителя, присваивание какому-нибудь документу название концептуального не означает, что он возымеет описанный выше эффект.

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


Таблица 4.1. Типичные примеры неудачных концептуальных положений

Искусство управления IT-проектами
Примеры концептуальных положений и целей проекта

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

Вернуться к просмотру книги Перейти к Оглавлению Перейти к Примечанию