Унифицированный процесс Rational (Rational Unified Process), корпоративный унифицированный процесс (Enterprise Unified Process), гибкая методология разработки (Agile Development Methodologies), унифицированный язык моделирования (Unified Modeling Languages) - они имеют множество различных названий, уровней сложности и размеров, но следование одному из них поможет обеспечить успех в вашем следующем проекте.
Данная статья не является детальным обзором формального процесса. Вместо этого она предоставляет обзор наиболее критических компонентов, общих для всех методов, а также некоторые советы по их успешному внедрению. Хотя многие описания процессов хорошо справляются с разбиением различных компонентов процессов, они не так хорошо покрывают области того, как, к примеру, это влияет на вашу команду, сколько процессов стоит использовать, или предложить практический совет по поводу проблем, встречаемых в реальной жизни при внедрении одного из методов. Будет намного полезнее сделать некоторый экскурс и ввести в принципы процессов читателей. Для более опытных читателей данная статья может представить полезную информацию по улучшению работы, с чем мы встречаемся временами. Информация основывается на опыте и уроках, полученных за многолетний стаж разработки и управления в более сотни сложных проектах. Следуя данным основам, вы увеличите шансы на успех в любом проекте и получите основу для придания ему зрелости. Что такое процесс и почему он необходим Независимо от бизнеса - создание программного обеспечения, дизайн веб-сайта или одежды - у нас у всех есть процессы, которым мы следуем для завершения какого-либо проекта. Иногда все работает, иногда не все так идеально, что зачастую стоит немало денег. Когда мы говорим о принятии нового процесса, то мы говорим о более формальном процессе. Процесс, по сути интегрирован в набор ролей, методов и техник , что помогает достичь следующего: - Снижения уровня риска .
- Более точных оценок сроков и бюджетов проекта.
- Определения проблем на более ранней стадии, вместо того, чтобы определять их позже, когда их решение будет стоить гораздо больше денег, если их вообще можно будет решить.
- Лучшего уровня общения среди членов команды относительно масштаба, требований и статуса проекта.
- Более точного наблюдения за прогрессом проекта и определения ранних отклонений.
- Достижения целей проекта как можно эффективнее и дешевле.
Формальные процессы зачастую создаются и пересматриваются на протяжении нескольких лет пробного периода и могут потерпеть крах при попытке создать идеальный "рецепт" получения оптимального шанса успешного завершения любого проекта. В то время как они были разработаны и широко используемы в разработке ПО, космонавтике и инже нерной индустрии, многие основные принципы не специфичны для любой из этих индустрий и все могут найти в них выгоду. Каков должен быть масштаб процесса? Для достижения успеха важно понимать, сколько работы вам нужно выполнить. Риск того, что вы начнете делать больше за меньшие сроки, может быть аналогичен ничему не выполненному, особенно если вы работаете в более гибкой компании и пытаетесь осуществить переход к подходу, более ориентированному на процессы. Перегружая вашу команду новым набором ответственностей и методов, к которым они не привыкли, вы можете с легкостью замедлить проект. Тем не менее, если вы не станете изменять процесс, то вы продолжите сталкиваться со старыми проблемами. Вот парочка советов для нахождения баланса: - Фактор риска. Каковы факторы риска проекта? Очевидно, что создание ПО для искусственного сердца гораздо рискованнее, чем внедрение веб-сайта третьего поколения, и, следовательно, процесс, по своей сути, должен соответствовать риску. Первая разработка требует частого, чрезмерного и исчерпывающего тестирования качества и сбалансирования, а вторая может быть с легкостью адаптирована после внедрения без потерь. Будьте реалистичны относительно рисков и того, насколько дорого вам будет стоить их разрешение потом - используйте это в качестве основы для определения того, что должно быть выполнено. Никто не знает вашей среды, проекта и команды лучше, чем вы сами - используйте здравый смысл в принятии решения о том, что подходит проекту.
- Сколько может взять на себя ваша команда и что ей больше всего необходимо? Влияние команды зачастую недооценивается. Любой процесс настолько хорош, насколько хорошо его выполняет ваша команда, независимо от общей выгоды - в сущности, необходимо обучение, что повлечет дополнительные затраты усилий в обучении выполнения новых задач, управление которыми еще незнакомо вашей команде. Для того, чтобы быть успешным, вы должны заручиться поддержкой и преданностью каждого. В противном случае ваша команда просто пройдет по всем действиям и негативно отреагирует на собраниях. Для преодоления этого вам необходимо найти то, что является проблематичным в их работе, и начать с тех областей процессов, которые будут иметь к ним отношение.
- Начните с малого. Начните с тех областей, которые вы считаете важными, при этом включайте проблематичные области вашей команды, чтобы преимущества были ясно видны. Впоследствии вам будет легче добавить другие уровни процессов, когда команда увидит все преимущества, а не только дополнительные уровни бюрократии. Получение поддержки критично, и если вы начнете с малого, то у вашей команды тоже будет шанс коллективно поучаствовать в этом, а также увидеть преимущества, что со временем облегчит созревание проекта.
Команда и среда Одним из наиболее недооцениваемых элементов принятия или созревания процесса является команда. Каждая команда имеет различную динамику и будет по-разному реагировать на различные вещи. Зачастую новые процессы навязываются команде. Это не означает, что команда должна диктовать процесс, но, как уже указывалось, поддержка вашей команды относительно ваших решений важна для успеха. Практически не существует примеров, когда процесс преуспевал бы, несмотря на негативное отношение команды. Поэтому вам стоит вовлекать вашу команду в обсуждение того, что вы будете делать, и это вскоре обернется для вас выгодой. - Роли и ответственности. Любой процесс будет обладать ролями, определенными для каждого, и важно, чтобы каждый понимал свою роль и чувствовал себя хорошо в ней. Вам стоит уделить этому некоторое время и поинтересоваться у сотрудников довольны ли они своей ролью, задавать вопросы и выслушивать ответы. Как только ваша команда будет готова, убедитесь в том, что у каждого есть возможность делать то, что он должен, и что каждый знает о том, кто является "полицейским". Если ваши разработчики отказываются передавать руководителю необходимую информацию, то у вас будет проблема. Если в ответ руководитель начнет расставлять мелкие контрольные точки в ваш план проекта, то вы не будете в курсе всего до тех пор, когда уже будет поздно что-либо делать. Потому убедитесь, что все роли четко определены для каждого, и что все знают о том, кто обладает властью в команде.
- Максимальная подробность. Назначением каждого процесса является решение проблем как можно точнее (дешевле), и это может быть выполнено только четкой прозрачностью на каждом этапе для точной оценки статуса проекта. Самомнения разработчиков, внутренние разбирательства в команде и оборонительная позиция - все это создаст такую среду, в которой никакой процесс не будет эффективным. Важно, чтобы члены команды могли признать свои ошибки, оглашать проблемы и делать все таким образом, чтобы не вызывать враждебную обстановку. Для этого вы должны собрать всех и откровенно обсудить проблемы. Демонстрируйте тот факт, что данные проблемы решаются ради всеобщего блага проекта и организации. Награждайте тех, кто осознаёт свою вину и признаёт ошибки. Зачастую напряжение можно снизить путем признания своих собственных ошибок, вероятно, другие последуют этому вашему поступку, поэтому вам стоит быть примером, и вы увидите, что можно создать открытую обстановку, где все чувствуют себя свободнее и могут давать конструктивную критику.
- Ясность. Схоже с тем, что было обсуждено выше - ясность заключается в людском чувстве удобства в разглашении информации группе. Разработчики захотят просидеть до последней минуты за кодом потому, что они знают о его незавершенности и о том, что дизайнеры ненавидят незавершенную работу. Потому вам стоит понимать, почему ваш разработчик или дизайнер дергается, когда их ранняя работа демонстрируется перед группой и к ней относятся с критикой до того, как она завершена. Такие фразы, как "все отлично, но как насчет ..." - бесценны, чаще используйте их! Основной целью любого хорошего процесса является нахождение проблем как можно раньше. Поэтому вы должны обсудить это с вашей командой и убедиться, что все понимают тот факт, что это можно выполнить, только имея ясность во всех аспектах проекта.
Правильные инструменты Вы не можете управлять тем, что вы не можете измерить. Потому убедитесь в том, что у вас есть все инструменты под рукой для управления процессом и есть возможность разглашать детали проекта. - Управление процессом. Существует множество доступных инструментов для управления требованиями, проверки качества и разработки. Так же, как и при любом процессе, вам стоит узнать, что и сколько вам необходимо для выполнения, до того, как вы начнете тратить бюджет. Поддерживайте критические части процесса. Управление требованиями зачастую получает наибольшее внимание, но требования могут быть с легкостью управляемы при помощи одного документа, в то время как проверка качества пропускается. Стойкая база данных, которая позволяет при проверке качества отследить функциональность от реализации до завершения, а также все ошибки, будет незаменима для тестов и разработки, а также для проекта в целом.
- Наблюдение за проектом. Необходимо, чтобы ваш руководитель проектов обладал инструментами, которые могут быть использованы для демонстрации прогресса проекта и его различных комментариев. Найдите инструменты, которые позволят вам получить оптимальное количество деталей (для высшего руководства) и более детальную информацию для независимых отделов и руководителей. К примеру, Microsoft Project является отличным инструментом для управления очень строгими проектами. Тем не менее, многие проекты движутся исключениями, что делает строгие инструменты управления проектами невозможными в использовании в изменчивой среде. Отличной альтернативой является ПО по планированию расписания, как The Calendar Planner , которое позволяет управлять различными уровнями детализации в легком и простом формате. Это позволит без проблем оглашать статус проекта.
Масштаб За средой в команде следует, вероятно, наиболее важный аспект любого проекта. Вы должны концентрироваться на четком определении масштаба проекта на ранних стадиях разработки. Самая большая ошибка - это попытка сделать большее в кратчайшие сроки, имея ограниченный бюджет или сроки, или же попытка определить масштаб, а затем не следовать ему. Это путает разработчиков и вносит в проект хаос. - Реалистичность. Все хотят все и сразу, особенно отдел продаж и маркетинга. Задавайте этим отделам сложные вопросы на ранних стадиях - о том, какую функциональность клиенты ДОЛЖНЫ иметь, в отличие от того, что они ХОТЯТ иметь. Иногда вы можете заметить, что маркетологи наобещали множество функций клиенту и пытаются сохранить лицо, когда в общей схеме данная функция не настолько важна, как цели компании. Концентрируйтесь на том, что вам по-настоящему необходимо сделать - дайте клиентам понять, что они не могут получить все, что они хотят, и заставьте их выбирать. Убедитесь, что цели компании всегда представлены в требованиях. Вот тут подходит документ видения, о котором мы поговорим далее.
- Документ видения. Он может иметь различные названия в различных методологиях, но документ видения, по сути, является обзором вашего проекта с высокого уровня. Относитесь к нему как к выражению миссии проекта. Тут компания может четко определить, какие цели подходят проекту, кто является участником и каковы требования высокого уровня. Это будет вашим основным документов для установления масштаба проекта. Придерживайтесь высокого уровня - детали можно расписать потом. Убедитесь в том, что требования связаны с целями и что, по мере выполнения проекта, работа соответствует данным целям и требованиям. Документ можно изменить, но только если заказчики договорятся, и все участники подпишут и одобрят данные изменения.
- Не стоит увеличивать масштаб без повторноых рассчетов сроков и бюджета. Может, это и кажется простым, но, наверняка, является наиболее частой ошибкой. Люди всегда пытаются добавить "маленькие" вещи, которые вовлекают "минимальные усилия". Это все накапливается, и эффект зачастую не учитывается, что в конце приводит к ошибочному расписанию и бюджету. Комитет по изменениям является вашей основной защитой против данной проблемы, и о нем мы поговорим позже.
Требования Требования в любом проекте запутанны, и множество отличных книг было посвящено данной теме. Это правда, что в тех проектах, которые потерпели крах, причина может быть отслежена в требованиях. Странно, но это так и продолжает быть одной из основных причин, в то время как требования являются наиболее простым и дешевым способом нахождения и решения проблемы. - Решение проблемы с каждым часом стоит дороже. Когда вы пересматриваете свои требования, вам необходимо по-настоящему изучить их, а не просто пробежаться. Подумайте и сформулируйте то, что они пытаются рассказать - вы поймете, что проблемы находятся на поверхности. Уделите время вдумчивому пересмотру и продолжайте пересматривать требования до тех пор, пока все будут считать их верными. Сравните затраты на перепись предложения и на исправления сотен строк кода, повторного тестирования и выпуска -и вы поймете, что это последнее дешевое решение проблем.
- Вовлеченность клиентов с ранней стадии. Убедитесь в том, что клиенты вовлечены с ранних стадий сбора требований, и удерживайте их в проекте. Зачастую клиенты требуют что-либо, и разработчики бросаются на реализацию требуемого запроса - большая ошибка! Возвращайтесь к клиентам с объяснениями того, как вы представляете функциональность, и при любой возможности используйте макеты, чтобы они могли наглядно представить. Вы поймете, что набросок даже самого простого рисунка чего-либо не только позволит клиенту понять больше, но вы также сами при этом найдете проблемы, которых раньше не замечали.
- Проверка качества начинается с требований. Проверка качества должна применяться с самого начала, а не только в конце проекта, что встречается чаще. Пусть документ видения и требования будут пересмотрены - сотрудники, выполняющие проверку качества , зачастую могут найти то, что другие отделы упустили.
Органы управления изменениями При правильном подходе органы управления изменениями могут практически собственноручно управлять даже самыми проблематичными проектами. Тем не менее, если вы не обладаете правильной средой в команде, как уже оговаривалось выше, то они будут неэффективными в лучшем случае, а в худшем - создадут больше вражды. - Что это такое? Проще говоря, комитет управления изменениями - это собрание людей, где каждый из ключевых отделов и иногда клиенты имеют своих представителей, и у них есть шанс обсудить проект со всех сторон. Идея заключается в том, чтобы все были осведомлены о статусе и могли обсуждать влияние изменений требований или расписания на них или на соответствующие отделы.
- Кто участвует? В общем, список участников состоит из отделов маркетинга, продаж, отдела по проверке качества, отдела эксплуатации и разработки, ИТ-отдела, руководства проектов и клиентов - в сущности, все, кто имеет свою долю или каким-то образом зависит от проекта. В зависимости от природы проекта, маркетологи или отдел продаж будут представлять клиента. Самым важным правилом здесь является то, что если кто-то определен в качестве участника проекта, то без него вам не стоит устраивать собрание. Если они не могут присутствовать, то вам стоит изменить расписание.
- С чего начать?Отличным путем старта является предоставление краткой информации о том, что делает каждый участник. Это поможет избежать неизвестности и зачастую укажет области нестыковок, а также поможет снизить напряжение в данных продолжительных встречах , благодаря раздаче каждому легкой темы для освещения и возможности немного похвастаться.
- На чем концентрироваться? Ключевой проблемой на ранней стадии организации комитета является масштаб. Что входит в масштаб? Это будет вопросом, связывающим требования отдела продаж и маркетинга и возможности тех, кто будет это все реализовывать. Когда масштаб будет установлен, то следом идут требования. Остаются ли требования верными? Все ли приоритеты расставлены? Правильно ли вы определили цель? Очень важно то, что все группы присутствуют, потому как , если отдел продаж скажет: "нам нужно это", то отдел разработок сразу может ответить о влиянии данного желания на план. Это представляет ясность, и все будут осведомлены об изменениях, а также могут одновременно управлять и оповещать.
- Как часто? Лучше всего устраивать собрания столько раз, сколько необходимо. Это зависит от природы проекта, но раз в 1-2 недели будет оптимальным решением. Если вы будете встречаться реже, то взаимодействие станет слабее и, следовательно, станет слишком много областей, подверженных ошибкам, а если встречаться чаще, то вы будете тратить слишком много рабочего времени.
- Чего не стоит делать. Не позволяйте собранию переходить в конфликты и трения. Комитет должен служить поддержкой всем отделам - поэтому важно, чтобы это место оставалось открытым для обсуждения проблем. Это место правды, а не споров. Это не так легко, как кажется, но вам стоит держаться спокойно и избегать конфликтов. Эти встречи наиболее важны для успеха проекта.
Обсуждение причин неудачи Обсуждение причин неудачи проводится на собрании после завершения проекта. Это не корпоративная вечеринка, но ее атмосфера зависит от успеха. Это шанс поговорить стратегически о том, что пошло не так и, что более важно, как с этим справляться в будущем. Все хотят обсудить успех, но вы можете научиться большему на ошибках, приведших к краху проекта. Итак, если у вас было много проблем, то вам не стоит упускать эту возможность и разрешить все проблемы, пока все еще свежо в памяти. Также команды должны быть расформированы, и эти собрания помогают им перейти в нейтральную обстановку перед началом следующего проекта. - Самомнение должно быть исключено. Вам стоит знать, где простой разговор и возможность предоставить и принять конструктивную критику наиболее критичны. Это собрание не может быть битвой характеров - оно должно заключаться в скромном обсуждении ошибок, совершенных всеми (мы все делаем их), или областей в проекте, которые необходимо улучшить. В качестве примера возьмите самого старшего в команде и попросите его рассказать о совершенных ошибках и найденных решениях. Это поможет установить верный тон и снизить уровень напряжения.
- Делайте заметки, а затем действуйте.Это время учений, и зачастую люди обсуждают проблемы, но после ничего не улучшают. Это время принятия корректирующих действий и экономии времени и денег в следующем проекте. Поэтому вам стоит записывать советы и использовать их при следующей возможности.
Следуйте данным шагам в любом процессе и проекте, и вы увидите, как это увеличивает ваши шансы на успех. Randy McGowan
Newer news items:
Older news items:
|