ИТ-архитектура. Практическое руководство от А до Я. Первое издание - страница 61

•Достаточно знаний и умений для того, чтобы сделать шаг

•Шаг кратковременный по времени

•Шаг имеет низкий уровень риска

•Шаг поведенческий-конкретный

•Понятно, что будет успехом шага

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

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

•Не изобретайте велосипедов.

•Громко скажите «спасибо» руководству за поддержку, коллегам за помощь и терпение и т. д.

Проекты, реализуемые без использования каких-либо методов, часто терпят крах по следующим десяти причинам:

•Проект представляет собой решение, приводящее к проблеме

•В конечном результате заинтересована только группа, работающая над проектом

•Никто ни за что не отвечает

•План проекта недостаточно структурирован

•План проекта недостаточно детализирован

•На реализацию проекта выделено недостаточно средств

•Выделенных ресурсов недостаточно для выполнения работ

•Проект не сверяется с планом его реализации

•Отсутствует взаимодействие между членами рабочей группы проекта

•Проект отклоняется от поставленной цели

При ведении любого проекта, в том числе и ИТ проекта, наиболее важными элементами являются процесс коммуникации всех вовлеченных подразделений и департаментов. Чем разнороднее участники (финансисты, представители бизнеса, ИТ и т п) тем важнее организовать коммуникацию на «одном» языке для всех участников проектной команды. В противном случае результаты проекта и его этапы могут быть похожи на диаграмму.

Если подытожить результаты данной главы, то можно сделать следующие, на мой взгляд важные выводы по методологии и техники управления проектами:

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

•Методология «PRINCE2» – тоже самое, но задаются вопросом «… а на кой нам это нужно если дохода нет?…»

•«Вот „бабули“, больше нет – крутись как хочешь, но к завтрашнему утру чтобы было все готово. Что конкретно готово не знаем – но клиент сказал – ВСЕ». Это больше подходит на пример использования гибких методов управления проектами.

•«Пашем как молотилка» – метод «SCRUM»

•«KANBAN» присмотрит за тем, чтобы работники не были перегружены, а то «… сдохнут кони раньше времени…»

•Методологии «LEAN» и «SIX SIGMA» присмотрят за вопросом «… а не много ли косячат?…»

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