Управление проектами - это философия управления, а не инструмент или техника
Управление проектамиГлоссарийФорумКонтакты

Управление проектами: советы, которые помогут вам принять процесс

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

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

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

Информация, изложенная  здесь, основана на опыте, приобретенном за более чем 15 лет разработки и управления более 100 сложными проектами.

Следование этим принципам повысит ваши шансы на успешное принятие любого процесса и обеспечит прочный фундамент для его развития.

Что такое процесс, и зачем он нужен?

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

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

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

Сколько процессов достаточно? Для успешного применения любого процесса важно понимать, какую его часть следует использовать первоначально. Риск попытки сделать сразу слишком много при помощи процесса может быть столь же высоким, как и при отсутствии всяких действий, особенно если ваша компания является гибкой и при этом пытается стать более процессно-ориентированной. Перегрузка вашей группы новым набором обязанностей и методов, к которым она не готова или не привыкла, легко может разрушить ваши планы. Но если вы не начнете изменений, вы так и будете иметь те же самые проблемы. Ниже приведены несколько советов, как найти верное равновесие.

  • Фактор риска. Что такое фактор риска проекта? Безусловно, создание программного обеспечения для искусственного сердца намного более рискованно, чем развертывание третьего поколения веб-сайта, и процесс с самого начала должен соответствовать риску. Первое потребовало бы широкомасштабных, чрезмерных и всесторонних проверок и балансировок качества, в то время как последнее можно  было бы легко настроить на лету после развертывания без потери качества. Реально оценивайте ваши риски, и как дорого обойдется последующая борьба с ними, чтобы использовать это как основу для принятия решения о том, сколько чего вам требуется. Никто не знает вашу среду, проект и группу лучше вас, поэтому используйте здравый смысл при выборе наиболее подходящего варианта.
  • С каким объемом может справиться ваша группа, и что ей нужно больше всего? Влияние на группу нередко недооценивается. Любой процесс хорош ровно настолько, насколько ваша группа может им управлять, и, независимо от конечной выгоды, сначала потребуются дополнительные усилия на изучение новых задач, которыми ваша группа еще не привыкла управлять. Для достижения успеха вы должны получить всеобщую заинтересованность и готовность к процессу. Если этого не будет, то группа будет просто делать вид и коллективно вращать глазами на совещаниях по проекту. Чтобы справиться с этим, выявите их наболевшие проблемы в текущем способе работы и начните с участков процесса, непосредственно решающих эти проблемы.
  • Начните с малого. Начните с нескольких участков, которые вы считаете наиболее важными, включающими в себя наболевшие проблемы, чтобы ваша группа увидела немедленную выгоду. Будет легче добавить больше слоев процесса позже, когда группа поймет их пользу и не будет считать просто дополнительными уровнями бюрократии. Крайне важно получить заинтересованность, и если вы начнете с малого, ваша группа поймет смысл нового процесса и осознает его пользу, что облегчит его дальнейшее развитие.

Группа и среда

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

  • Роли и обязанности. В любом процессе есть роли, определенные для каждого сотрудника, и важно, чтобы каждый человек точно понимал роль, которую он будет играть, и чувствовал себя уютно в этой роли. Спросите людей, уютно ли им в их роли, задавайте вопросы и слушайте! Когда ваша группа настроится на работу, убедитесь, что участникам группы  дано право делать то, что они должны делать, и что все в группе понимают свои роли. Если разработчики отказываются сообщать руководителю проекта нужную ему информацию, то возникнет проблема. Если руководитель проекта в ответ устанавливает мягкие контрольные точки в плане проекта, то при наличии проблемы о ней будет неизвестно до тех пор, пока не станет слишком поздно. Поэтому убедитесь, что роли четко определены для всех, и что все знают, кто руководит группой.
  • Полная открытость. Об этом нельзя сказать достаточно. Назначение любого процесса – решать проблемы как можно раньше (дешево), что можно сделать только при прозрачности каждого этапа и доступности точной информации о состоянии проекта. Эгоизм разработчиков, распри в группе и оборонительное поведение создают среду, в которой никакой процесс не будет эффективным. Важно, чтобы члены группы с готовностью признавали ошибки, сообщали о проблемах и не создавали своими действиями неблагоприятную среду. Чтобы сделать это, вы должны свести стороны вместе и открыто обсудить проблему. Скажите, что проблемы вынесены на обсуждение для общей пользы проекта и организации. Вознаградите тех, кто признает свою вину и укажет на ошибки. Нередко можно снять напряжение, начав с признания своих ошибок, и тогда другие последуют за вами. Подавайте личный пример, и вы сможете создать открытую среду, в которой люди спокойно рассматривают ошибки и даже критику.
  • Прозрачность. Подобно вышесказанному, прозрачность означает, что люди спокойно раскрывают информацию группе. Разработчики будут настроены скрывать код до последнего момента, так как они знают, что он не готов: проектировщики не выносят, когда люди видят незаконченную работу. Поймите, почему ваш разработчик или проектировщик  дергается, когда начальная работа выставляется напоказ перед группой, и вначале будьте осторожны с критикой, пока все не привыкнут к этому. Высказывания типа; "Это очень хорошо, но как насчет..." бесценны, поэтому используйте их! Основная цель любого хорошего процесса – как можно более раннее обнаружение проблем. Вы должны обсудить это с группой и убедиться, что все понимают, что это можно сделать только при условии полной прозрачности всех аспектов проекта.

Подходящие инструменты

Нельзя контролировать то, что нельзя измерить. Убедитесь, что вы используете подходящие средства для управления процессами и для отслеживания и передачи информации о вашем проекте.

  • Управление процессом. Имеется много превосходных инструментов для управления требованиями, качеством и разработкой. Как и с самим процессом, обдумайте, сколько и чего вам нужно, перед началом покупки инструментов. Укрепите критические участки процесса. Управление требованиями часто требует максимального внимания, но требованиями можно легко управлять в документе word, в то время как качество часто игнорируется. Надежная база данных, позволяющая отслеживать качество характеристик от внедрения до завершения и выявлять любые возникающие ошибки, будет бесценной для качества, разработки и для проекта в целом.
  • Отслеживание проекта. Важно, чтобы руководитель проекта имел инструмент, который можно использовать для отображения прогресса проекта и его различных комментариев. Ищите инструменты, обеспечивающие нужный уровень детализации (высокий уровень для руководства) и более детальный для отдельных отделов и для самого руководителя проекта. Например, Microsoft Project – это превосходный инструмент для управления проектами на основе очень строгих правил. Но многие проекты управляются на основе исключений, что делает сложным применение строгих инструментов управления проектами в изменчивой среде. Хорошая альтернатива – ПО для календарного планирования, такой как Календарный планировщик, позволяющий управлять различными уровнями детализации в легко используемом календарном формате и предоставляющий  группе информацию о состоянии проекта.

Масштаб

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

  • Будьте реалистичны. Все хотят получить все прямо сейчас, особенно отделы продаж и маркетинга. Заранее задавайте этим отделам трудные вопросы о том, какие характеристики должны получить ваши клиенты, в сравнении с тем, что они хотят иметь. Иногда вы обнаружите, что продавцы дали обещание одному клиенту и пытаются сохранить репутацию, когда в общей схеме эта характеристика оказывается не столь важной для целей компании. Сосредоточьтесь на том, что вы действительно должны сделать, дайте им знать, что они не могут иметь все, и заставьте их выбирать. Убедитесь, что цели компании всегда представлены в требованиях. Здесь пригодится документ о видении компании.
  • Документ о видении компании. Он может по-разному называться в различных методологиях, но документ о видении компании, по сути, является высокоуровневым обзором вашего проекта. Считайте его описанием задачи самого проекта. В нем компания может четко определить цели проекта, кто входит в число заинтересованных лиц, и каковы высокоуровневые требования. Это будет ваш исходный документ для установки масштаба проекта. Он должен быть высокоуровневым, детали можно описать в другом месте. Убедитесь, что требования отражают цели, и что по мере прогресса выполняемая работа будет соответствовать данным целям и требованиям. Их можно изменять только после того, как заинтересованные лица согласуют и утвердят изменения.
  • Не увеличивайте масштаб без изменения графика и бюджета! Это кажется довольно просто, но это одна из самых распространенных ошибок. Люди всегда пытаются добавить «маленькие» вещи, требующие "минимальных усилий". Они суммируются, но их влияние часто не учитывается, что в итоге приводит к несоблюдению графика или бюджета. Орган управления изменениями – ваша основная защита от этого.

Требования

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

  • Проблема никогда не будет проще, чем прямо сейчас. Когда вы проверяете требования, вам нужно проверять их досконально, а не просто пробегать глазами. Обдумайте и попытайтесь представить, что в них говорится. Часто проблемы находятся на поверхности. Потратьте время на выполнение внимательной проверки и продолжайте исправлять требования, пока все не поймут, что они правильные. Сравните расходы на переписывание предложения в текстовом редакторе с расходами на переписывание сотен строк кода, повторное тестирование и развертывание, и вы поймете, что это ваш последний шанс легко устранить проблему.
  • Заранее подключайте ваших клиентов! Убедитесь, что клиенты участвуют в самых ранних этапах выработки требований, и поддерживайте их участие. Часто клиент запрашивает что-либо, и затем разработчики забывают это выяснить. Это большая ошибка! Вернитесь к клиентам с объяснениями того, как вы представляете себе характеристику, и используйте модели, чтобы клиенты могли ее отчетливо представить. Создание даже простого чертежа или чего-то подобного не только позволяет клиенту легче понять все, но и помогает вам выявить проблемы, не рассмотренные ранее.
  • Обеспечение качества начинается с требований. Отдел обеспечения качества должен участвовать с самого начала проекта, а не только в конце, как это часто бывает. Позвольте сотрудникам отдела обеспечения качества беспрепятственно рассмотреть документы о видении компании и требованиях. Нередко эти сотрудники видят возможные проблемы, не замечаемые другими отделами.

Орган управления изменениями

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

  • Что это такое? Орган управления изменениями – это собрание, в котором представлены основные отделы и иногда клиенты, имеющее возможность обсудить проект со всех сторон. Они должны гарантировать, что все знают о состоянии проекта, и могут обсудить то, какое влияние любые изменения в требованиях или графике будут иметь на  соответствующий отдел.
  • Кто в него входит? Обычно в него входят следующие отделы: Маркетинг, Продажи, Обеспечение качества, Операционный отдел, Разработчики, ИТ, Управление проектами, Клиенты -  в основном, все, кто заинтересован в проекте, или на кого влияет проект. В зависимости от сущности проекта отделы маркетинга или продаж часто представляют клиента. Здесь самое важное правило заключается в том,  что если кто-то является заинтересованным лицом в проекте, то не стоит проводить собрание без него. Если он не может присутствовать, перенесите собрание.
  • С чего начать? Обычно хороший способ начать – предоставить всем краткую обновленную информацию о том, что они делают в отношении проекта. Это помогает устранить темные углы, обратить внимание на сферы разногласий и облегчить напряжение этих иногда спорных совещаний, дав всем легкую тему для рассмотрения и, может быть, немного похвастаться для начала.
  • На чем сосредоточиться? Ключевая проблема на первом совещании органа управления изменениями – это масштаб. Что входит и что не входит в него? Это породит противоречие между тем, что хочет отдел продаж и маркетинга, и тем, с чем могут справиться ответственные за выполнение проекта. После установления масштаба нужно перейти к состоянию. По-прежнему ли требования верны? Были ли изменены приоритеты? На правильном ли мы пути? Более важно, чтобы была представлена каждая группа, так что если отдел маркетинга скажет: "Нам нужно это", разработчики скажут о том, как это повлияет на график в реальном времени. Это поспособствует прозрачности и предотвратит внесение изменений без обсуждения всеми их последствий. Орган управления изменениями одновременно контролирует и информирует.
  • Как часто? Полезно проводить совещания при необходимости. Это зависит от сущности проекта, но лучший вариант – один раз в 1-2 недели. Если проводить совещания реже, то коммуникаций будет слишком мало, и появится слишком много возможных областей с отставаниями по срокам, более же частые совещания будут отнимать слишком много рабочего времени.
  • Чего нельзя делать? Не позволяйте совещаниям переходить в споры и поиск виноватых. Орган управления изменениями – это инструмент, обслуживающий все отделы. В нем люди должны открыто говорить о проблемах. Это место для реальной работы, а не для хождения кругами. Иногда это сложно обеспечить, но не поддавайтесь соблазну пустить все на самотек. Для успеха проекта нет более важных совещаний, чем эти.

Итоговый анализ

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

  • Оставьте свой эгоизм за дверью. Нигде более так не важны откровенный разговор и способность представить и принять конструктивную критику. Это совещание не должно быть заполнено самомнением, это должно быть откровенное обсуждение ошибок, сделанных всеми, или участков процесса, которые нужно улучшить. Чтобы задать тон, попытайтесь начать совещание с обсуждения сделанных ошибок или усвоенных уроков самым старшим человеком в собрании. Это помогает задать правильный тон и облегчить напряжение.
  • Делайте заметки, затем действуйте. Это время учиться, но нередко люди обсуждают проблему, а затем уходят и ничего не делают. Это шанс предпринять корректирующие действия, чтобы сэкономить время и деньги в следующем проекте. Поэтому делайте заметки и пускайте их в ход по горячим следам.
Следуйте этим советам при принятии любого процесса или при управлении любым проектом, и вы повысите свои шансы на успех.

Newer news items:
Older news items:

 

Предложения

Copyright ©2014, PMToday.ru. При копировании материалов наличие прямой индексируемой ссылки на сайт обязательно.