Управление ИТ-проектами

Управление ИТ-проектами

Уважаемые господа! Известно, что бОльшая часть ИТ-проектов заканчиваются неуспешно. Как минимум, проекты не завершаются в заданные сроки и бюджеты. Есть предположение, что главная причина этого — в недостаточно эффективном управлении проектами. В связи с этим вопрос: используете ли Вы «стандартные» методики управления проектами (PMBoK, PRINCE2 или хотя бы RUP) в своей практике и если используете, то насколько жестко их придерживаетесь?

324
Комментарии (63)
  • 22 мая 2009 в 19:48 • #
    Александр Дублин

    Много работал в ИТ консалтинге. Практически не встречал строго следования какой либо методологии на проектах спустя 3 месяца после начала.

  • 22 мая 2009 в 20:51 • #
    Ruben Girgidov

    Встречал, сам работал, и реализовывал в проектах до полугода (длиннее проекты делать просто нельзя). Хотя вы правы, очень часто через 3 месяца о методологии все забывают.
    Другой вопрос, что если делать грамотно, то можно сделать проект из под проектов по не более, чем 3 месяца каждый, тогда следующий подпроект будет по своей методике. :)
    Да и итерации ни кто не отменял.
    Еще раз подчеркну, что это касается только разработки ПО, внедрение это совсем другая песня.

  • 22 мая 2009 в 22:00 • #
    Игорь Цесельский

    Я правильно понял, что по вашему мнению "длиннее полугода проекты делать просто нельзя" относится только к разработке ПО?
    Моя практика - все крупные проекты по проектированию сетей связи, электрики и слаботочки в строительстве имеют срок не менее 6 месяцев (до 3 лет).
    Да и при разработке ПО в интересах МО сроки были не меньше.
    Прокомментируйте свой вывод.

  • 25 мая 2009 в 16:15 • #
    Ruben Girgidov

    Я наверное не очень точно выразился, хотя и старался.
    Конечно, я скорее имел в виду проекты по разработке ПО
    Проекты могут быть и дольше, но тут играет роль психологический фактор, если сделать проект больше полугода, то все расслабляются, по этому разбиваем большой проект на несколько по 6 месяцев.
    НО ОЧЕНЬ ВАЖНО Это должны быть именно отдельные проекты, а не разные стадии одного проекта.
    Еще раз повторюсь, все выше написанное относится к проектам разработки ПО.
    Для других видов IT проектов все не много не так, но в любом случае, психологический аспект ни кто не отменял.

  • 25 мая 2009 в 21:09 • #
    Борис Вольфман

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

  • 22 мая 2009 в 22:15 • #
    Александр Дублин

    ДАЙТЕ увидеть хоть краешком глаза ИТ проект со всеми докуметами в соответствии с PMBOK.
    Заплачу.

  • 25 мая 2009 в 16:22 • #
    Ruben Girgidov

    врать не хочу, но такие проекты были в Quest Software (сам в них принимал участие), Знаю, что RUP (написанный, как мне кажется, во многом на основе PMBook) в полном объеме применяли в компании STARSOFT (но могу и врать).
    Из моего опыта.
    RUP применялся, но не в полном объеме, т.к. там была куча лишних документов, которые годились для очень больших проектов, а для нас в тот момент хватило и основных спецификаций, тем не менее, делали устав, описание спонсоров, конечных заказчиков и т.п.

  • 28 мая 2009 в 03:23 • #
    Игорь Цесельский

    За посмотр заплатите?
    А что это вам даст?
    Уверенность в том, что такие проекты в природе есть?
    Не тратьте деньги, они есть)

  • 2 июня 2009 в 10:23 • #
    Александр Дублин

    Рад, если они есть. Просто ни разу не видел.

  • 2 июня 2009 в 13:23 • #
    Игорь Цесельский

    Хорошо это дело было поставлено в "Институт Сетевых технологий", Санкт-Петербург. IT-проекты в интересах МО.

  • 3 июня 2009 в 16:17 • #
    Александр Дублин

    От непосредственных участников этих проектов слышал только негативное. И потом для МО они делали преокту по 34-му госту.

  • 3 июня 2009 в 18:13 • #
    Игорь Цесельский

    Там очень много было проектов для МО за очень большой период.
    И лично я с большим недоверием отношусь к бывшим участникам чего-либо (проектов в частности), от которых исходит только негатив.
    Это, как правило, просто неудачники и плаксы)
    И с чего бы вообще обсуждать детально проекты оборонной тематики?

  • 3 июня 2009 в 19:18 • #
    Александр Дублин

    Да, закончим. Приятно было познакомиться.

  • 4 июня 2009 в 01:18 • #
    Игорь Цесельский

    Взаимно)

  • 22 мая 2009 в 19:52 • #
    Борис Вольфман

    Михаил! 50% провала программных проектов - требования. Главная задача Управления проектами - снизить риски несоответствия потребностей пользователя реализованному функционалу.
    Философия Вами перечисленных методик (я бы MSF добавил) предполагает гибкость адаптивность к практическим особенностям.
    Следовательно, жестко придерживаться методик невозможно, так как будешь противоречить самим методикам.

  • 22 мая 2009 в 20:43 • #
    Ruben Girgidov

    ну почему, если методика завязана на адаптивность, то можно жестко следовать адаптивности к изменению требований.

  • 22 мая 2009 в 23:59 • #
    Борис Вольфман

    Рубен. Я хотел немного другую мысль изложить. Методика, в отличии от инструкции, определяет принципы и рекомендации на общие случаи, а не однозначную последовательность действий, которым необходимо следовать. Как говорят в преферансе- не догма, а руководство к действию.
    На основании методики (RUP, MSF ...) в конкретном подразделении с конкретной орг.структурой с конкретным типом задач разрабатывается регламент (инструкция) которой необходимо жестко следовать или не следовать.
    У меня не получалось, руководствуясь исключительно RUPом разработать Порядок разработки программных продуктов: фазу СТАБИЛИЗАЦИЯ взял из MSF, фазы ИНИЦИАЦИЯ, ПЛАНИРОВАНИЕ, ЗАВЕРШЕНИЕ (PMI), ИСПЫТАНИЯ (ГОСТ 34).

  • 25 мая 2009 в 16:26 • #
    Ruben Girgidov

    На 100% согласен.
    тут важно не перегнуть палку, у меня однажды был случай, когда я ругаясь на RUP выкинул пару документов, т.к. нужны не были и вообще полный бред, а потом героически их сам изобрел :), а в целом Я также работаю.

  • 25 мая 2009 в 21:58 • #
    Александр Дублин

    Некоторое уточнение: методология определяет принципы и рекомендации на общие случаи, а методика - руководство к действию.
    (по Далю так)

  • 22 мая 2009 в 22:14 • #
    Александр Дублин

    При этом на требованиях очень сильно экономят. Посмотрите на объявления. Если бизнес-аналитику, который отвечает за требования предлагают сейчас не более 100к рублей, то у кодировщика этих требований от этой сумы зарплата только начинется.

    Чаще всего программер сам себе задачу ставит. Результат соответствующий.

  • 23 мая 2009 в 00:25 • #
    Борис Вольфман

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

    Архитектор "сидит на двух стульях", включая кодирование и общая сумма больше.

    Вторая мысль (не более): Исторически (34 ГОСТ) сложилось, что работа аналитика закончилась разработкой ТЗ, а в философии RUP - она только началась.

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

  • 23 мая 2009 в 10:05 • #
    Леонид Дубина

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

  • 23 мая 2009 в 14:50 • #
    Александр Дублин

    Я сам бывший БА (хотя бывших БА, как и бывших кгбэшников не бывает: мозг работает в определнном направлении).

    Завязал с этим, так как все мои работы очень нравятся КЛИЕНТАМ моих клиентов и они пишут благодарственные письма по этому поводу, а вот непосредственные пользователи всегда не рады тому, что и как сделано.
    Например из публично доступного, программа Луч (www.ndc.ru), по прошествии 7 лет НДЦ до сих пор считает её конкурентным преимуществом (а сколько внутри копий было сломано).
    Для себя я уже давно сделал вывод, что проектируемые сценарии и процессы должны быть удобны и полезны БИЗНЕСУ и КЛИЕНТАМ, и уже после этого стоят чьи либо личные или ведомственные интересы.
    Все с этим соглашаются на старте, но в процессе работы - начинают плакать и строить интриги.

  • 25 мая 2009 в 22:48 • #
    Леонид Дубина

    Не очень понял, чем отличаются "КЛИЕНТЫ моих клиентов" и "Непосредственные пользователи".
    Если КЛИЕНТЫ, это те кто платит деньги, то позиция понятна и естественна - кто платит, тот и танцует.
    Однако если "Непосредственные пользователи" недовольны, то это вряд ли идет на пользу БИЗНЕСУ и КЛИЕНТАМ.
    Но мой вопрос задавался под другим углом. Меня интересует возможность оперативного, но как можно более всеобъемлющего анализа работы БА, чтобы уменьшить количество неизбежных ошибок. Метод "сделать самому и сравнить" не предлагать.

  • 26 мая 2009 в 09:02 • #
    Александр Дублин

    клиенту удобно подойти в 8-30, сотруднику (непосредственномупользователю) хочется на работуприходить в 9-00.
    Что делаем?

  • 25 мая 2009 в 21:00 • #
    Борис Вольфман

    От "зарытых" ошибок никто не застрахован: ни БА, ни архитектор, ни тестер. Но чтобы выявить "зарытые" ошибки БА как можно раньше, должен быть в кратчайшее время сделан прототип и передан Заказчику на согласование. А контролер должен только: проверить есть согласующая виза
    Заказчика и соответствует ли продукт требованиям БА. Категорически запрещено контролеру и архитектору оценивать работу БА с точки зрения семантики. Иначе не будет делегирования ответственности.

  • 25 мая 2009 в 22:52 • #
    Леонид Дубина

    То есть успешниый проект предполагает не менее 2 (предварительную и окончательную) итераций?

  • 25 мая 2009 в 23:12 • #
    Борис Вольфман

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

  • 22 мая 2009 в 20:42 • #
    Ruben Girgidov

    использую, нечто вроде Scrum или резанного XP, но все очень зависит от требований клиентов, некоторым нужен один тип управления (RUP), некоторым вообще все равно, тогда я использую свою, отработанную методику.

    на сколько я понимаю, RUP достаточно четко следует PMBook.

  • 23 мая 2009 в 00:20 • #
    Михаил Зырянов

    Кстати, вот что я "нарыл" в Сбербанке: http://www.osp.ru/cio/2009/05/7050447/

  • 23 мая 2009 в 00:58 • #
    Борис Вольфман

    Михаил. Сбербанк только в 2008 разработал стратегию, а на рынке банковских услуг только "ленивый" банк не обслуживает клиента дистанционно.
    В Альфа-банке я уже лет пять своими счетами управляю из дома, в машине, ресторане (коммуникатор). А Сбербанк разработал стратегию.
    Прекрасно понимаю, что ИТ-проблемы Сбера и мелких российских банков различного уровня масштабируемости.
    Сделать сервис и БЕЗОПАСНОСТЬ для нескольких сотен клиентов и в масштабе страны для различных компетенций и возрастов - три большие разницы.
    Предлагаю поинтересоваться: каков порядок и практика согласования ТЗ и сдачи релиза в полном соответствии с ТЗ.
    Особенно хочется отметить личное участие Президента банка в ИТ-развитии и отражение личного участия Президента банка в ИТ-журнале..
    Предлагаю взять интервью у руководителя функционального подразделения зарубежного банка аналогичных масштабов.

    И причем тут КРИЗИС?

  • 23 мая 2009 в 23:35 • #
    Михаил Зырянов

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

    Интервью с иностранными банками мы брали, вот недавнее: http://www.osp.ru/cio/2008/09/5273401/. Скоро появятся еще, готовим.

  • 24 мая 2009 в 00:15 • #
    Борис Вольфман

    Михаил:
    Цитата из Вашей статьи:

    "В декабре 2008 года на их основе был утвержден перечень стратегических ИТ-проектов. В этот список вошли, в частности, проекты, нацеленные на радикальное увеличение числа частных и корпоративных клиентов, работающих с банком удаленно посредством различных каналов связи. Например, будут и дальше развиваться сети банкоматов и терминалов, система Internet-банкинга и мобильного банкинга, контакт-центры. В перспективе планируется перевести на удаленные каналы взаимодействия с банком от 70 до 80% всех транзакций клиентов."

    Я утверждаю, что задача удаленной работы клиентов во многих банках давно решена и не нужно эти проекты замораживать.
    В группе Банковское дело запросил информацию о возможности удаленной работы клиентов: Интернет-банкинге для новой компании.
    https://professionali.ru/Topic/1272561#reply1275800
    Получил около 10 приглашений со стоимостью месячного обслуживания от 500 до 3000 руб. в месяц.

    В Альфа-банке погасить кредит - три клика: вставить банковскую карту, выбрать функцию меню, вставить деньги.
    В сбербанке три окошка нужно посетить, несколько чеков подписать и т.п.
    Я бы по другому переформулировал Ваши слова:
    Кризис предоставляет возможность Сбербанку попытаться догнать продвинутые банки по удаленному обслуживанию клиентов.
    Но я связываю "виртуальную" активность Сбербанка с приходом нового начальника - Грефа, который жестко контролирует ИТ и требует реального внедрения, а не разработки концепции до 2010 года.

  • 25 мая 2009 в 17:30 • #
    Ruben Girgidov

    в силу необходимости столкнулся с Bank Of Ameriсa, и их системой удаленного управления счетами, по сравнению с ними все, что делают наши банки это сложно, бредово и абсолютно не юзабельно, к моему величайшему сожалению.

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

  • 25 мая 2009 в 21:14 • #
    Борис Вольфман

    Рубен. Могу поделиться опытом работы со Сбером. Но только не для общего обозрения. Уникальность превосходна, но есть ньюансы.

  • 26 мая 2009 в 16:03 • #
    Ruben Girgidov

    ужасно интересно, напишу в личку.
    Как говорится: "Дьявол кроется в мелочах"

  • 28 мая 2009 в 15:00 • #
    Виктор Таланов

    Причин провала ИТ проектов много. Не использование методологий одна из этих причин и (ИМХО) не самая важная.

    Теперь отвечу на вопрос:
    ДА, я использую PMBoK (реже другие). Правда есть большое "НО". Применение в ПОЛНОМ объеме методологии на маленьком и среднем проекте может привести к провалу, и НЕ применение методологи в большом проекте тоже приведет к провалу. Т.е. любую методологию нужно применять с головой - это 100% зона ответственности руководителя проекта. Отсюда ответ на вторую часть вопроса: я жёстко не придерживаюсь методологии.

  • 2 июня 2009 в 13:24 • #
    Игорь Цесельский

    PMBoK не методолгия, это типовая практика.

  • 29 мая 2009 в 12:35 • #
    Юрий Нестеркин

    Однажды кто-то сказал: "Отклонения от методологии имели многие успешные проекты. И все неудачные".
    В моей практике основная проблема была не в использовании или неиспользовании какой-либо методики, а в наличии в проектах звеньев, которые могут по своему желанию следовать правилам или игнорировать их (например, руководство заказчика, приближённые товарищи и т.д.).
    По вопросу. Я не стараюсь жестко придерживаться МЕТОДОЛОГИИ. Я стараюсь контролировать процесс выполнения требований в рамках сроков и бюджета проекта. Отсюда большая нагрузка ложится на руководителя проекта и аналитика.
    К вопросу оплаты участников проекта. На моей памяти ещё ни один проект не провалился из-за невозможности кодировщиков что-то запрограммировать (криворукость не в счёт). А вот из-за ошибок постановки задач и методологии - сколько угодно. Поэтому такие соотношения в оплатах считаю "конструктивным дефектом" проетов.

  • 29 мая 2009 в 19:15 • #
    Ruben Girgidov

    Отвечу с конца
    На моей практике были такие проекты, которые развалились из-за не возможности что-то запрограммировать (лично вытягивал такой проект), там были кривые руки у архитектора, этот гений такого придумал, что это просто не возможно было отладить ни в какие разумные сроки, убил бы тогда аналитика и архитектора, сколько мне этот проект крови выпил :(.
    А вот в том, что вы сказали на счет звеньев, вы правы на 100%. Соотношение между провалами в из-за таких звеньев и провалившихся из-за разработчиков 1 к 7-10 по моей практике.

    Методологий куча и всегда можно сказать, что вот он провалился, т.к. не следовал такой-то методологии и что?
    Обвинение в не следовании методологии это демагогия, используемая, когда хотят кого-то очернить в глазах профанов.

  • 30 мая 2009 в 17:31 • #
    Борис Вольфман

    Юрий! Если Вы контролируете процесс выполнения требований в рамках сроков и бюджета - значит Вы придерживаетесь методологии. Наибольшие риски - не обеспечить требования. А методология говорит - управляете рисками по приоритетам, что Вы и делаете, на основании Вашего опыта и профессионализма.
    Также необходимо обеспечить устойчивость архитектуры, но это обязанность team-leader. Как начальнику обеспечить устойчивость архитектуры, не знаю, как исполнителю обеспечить устойчивость архитектуры - знаю профессионально, но не скажу.

  • 3 июня 2009 в 10:01 • #
    Юрий Нестеркин

    Если так - согласен.
    Видимо, я не совсем правильно выразился. Лучше было бы сказать, что в каждом случае выбираем тот (не люблю слово методология) способ управления, который обеспечивает выполнение проекта.
    А устойчивость... Интересно было бы побеседовать на эту тему, уж больно она широкая.

  • 31 мая 2009 в 08:22 • #
    Борис Вольфман

    Михаил и все остальные участники дискуссии. Скажу одну крамольную мысль, с которой надеюсь найти солидарность профессиональных разработчиков:
    Все без исключения стандартные методики управления проектами есть систематизированное обобщение опыта конкретных профессионалов, на конкретных проектах, направленное на определенные цели, например на увеличение доходов авторов или возможность контроля за состоянием конкурентов. Но не обязательно - повышение эффективности выполнения конкретного проекта.
    Недавно беседовал с однокашником, с которым заканчивал (35 лет назад) "Прикладную математику". Он руководит подразделением программирования в Лос-Анжелосе последние лет 20.
    Выяснилось, что мы не договариваясь закончили оба курсы по PMI для ТОП-менеджеров, RUPом владеем и используем все это на практике.
    Его слова: "Не будем о грустном. Владельцы заставляют использовать PMI и RUP и работа, которую можно сделать за день, делается за месяц".
    Я из этого делаю один вывод: если руководство компании капиталистическое идет на такие потери, значит ему прозрачность разработки дороже эффективности отдельного разработчика.
    Второй вывод: Как только руководство посчитает, сколько стоят накладные расходы по следованию методологии, оно перейдет на упрощенные схемы, типа Agile или дешевое индусское программирование.
    Но так как бум "индусского программирования" уже прошел: допускаю возможность зацикливания эволюции процессов управления проектами.
    Ничего не могу сказать об управлении проектами в других ИТ-процессах и работах.
    Поэтому, чтобы не "флудить" для других менеджеров, приглашаю разработчиков профессионального ПО в группу с аналогичным названием. И в первую очередь, Михаила, профессионально инициирующего тематику управления проектами, для которого, я уверен, особенности управления программными проектами не менее интересны и важны в работе.
    Примерный список тем прилагается.

    Всех остальных также приглашаю.

  • 2 июня 2009 в 13:29 • #
    Игорь Цесельский

    RE "прозрачность разработки дороже эффективности отдельного разработчика." И это прекрасно.
    Более того - это естественно, тк IT - это индустрия.
    Левше не место на конвейере.
    Не надо стремиться в рамках проекта сделать лучше, чем запланировано, надо сделать не хуже.
    Получиться лучше - анализ - почему и использовать резервы в планировании следующего проекта.
    Так, собственно, и идет развитие отрасли.

  • 2 июня 2009 в 20:13 • #
    Борис Вольфман

    Игорь!
    Развитие отрасли идет по немного модифицированному алгоритму: создает решение с нуля левша в sturt-upе, а подхватывают рабочие лошадки, проектно-ориентированные, которые в конце концов забывают, кто им лыжню накатал.

  • 2 июня 2009 в 23:53 • #
    Игорь Цесельский

    Start-up выдает экономически приемлемый результат в лучшем случае 1 на 1000. Кроме того, отрасль и в этих случаях зачастую покупает его, чтобы положить под сукно.
    А рабочие лошадки на то и рабочие, чтобы тянуть отрасль.

  • 3 июня 2009 в 01:37 • #
    Борис Вольфман

    Игорь! Вы мне льстите. Я подозревал, что это не просто, запрограммировать, чтобы еще лет двадцать эксплуатировалось, несмотря на отсутствие windows, SQL-сервера и автора. Хотелось бы поинтересоваться, источник цифры 1000, и как оценивалась экономика. Ведь старт-ап требует еще венчурных вливаний. Раньше, чем через пять лет не ждите +.

  • 3 июня 2009 в 15:32 • #
    Борис Вольфман

    Игорь!
    Также хочу добавить про старт-ап: специалисты по управлению венчурным капиталом прекрасно знают, что коэффициент выхода в старт-апе низкий, но зато, если уж изобрел перпетум-мобиле или Google-поисковик, то все расходы на безрезультатные старт-апы окупаются.
    Также имею особое мнение по поводу Левши и рабочих лошадок.
    ИТ-разработка на 80% - искусство, на остальные 80% - ремесло, которое обязано подчиняться проектному управлению.
    Также в коллективе разработчиков 80% делает левша, остальные 80% - рабочие лошадки.

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

  • 3 июня 2009 в 13:43 • #
    Михаил Зырянов

    Борис, я с Вами согласен. Более того, считаю это закономерным. Общепринятая в сообществе методика представляет собой ТИРАЖИРУЕМЫЙ продукт, который, как и всякий подобный продукт, может оказаться не максимально эффективным, если речь идет о конкретном случае (проекте).

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

    В общем, для достижения максимальных результатов может потребоваться "заказная" методика.

  • 31 мая 2009 в 20:35 • #
    Антон Еременко

    Уважаемые участники дискуссии.

    Я работаю в американской компании, пишу программы для телекома. Компания имеет сертификат CMMI Level 5. Хочу поделиться своим опытом.

    Следование методике обязательно для успешного выполнения проекта.

    Все известные продукты созданы с использованием методик ведения проектов.

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

    Следование методике (процессу) ведения проекта, действительно, требует много сил и денежных средств.

    К примеру, у нас в компании разделены функции руководителя проекта, который отвечает за проект в целом, и ответственного за ведения проектной документации, который следит за правильным выполнением процедур.

    Примерно 30% до 50% процентов рабочего времени исполнители проекта тратят на выполнение работ по созданию проектной документации и на участие в процедурах, таких как обсуждение технического задания и т.д.

    Дорого, да очень дорого. Но к сожалению другого способа отслеживать сроки, бюджет и качество выполнения проекта я не знаю.

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

    надеюсь, что все со мной согласятся, что иметь такие документы как:

    • описание прецедентов использования
    • модель предметной области
    • архитектурный дизайн
    • UML диаграммы классов
    • описание API
    • схема БД
    • описание тест кейсов

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

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

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

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

  • 2 июня 2009 в 20:29 • #
    Борис Вольфман

    Проблемы использования правильных методик для меня сегодня немного другие:
    Как убедить Заказчика, что разработка стоит именно столько, сколько нужно потратить человеоко-часов на все правильные процессы + 5% прибыль?
    как обеспечить синхронизацию разработки с бизнесом компании?
    Как сражаться с конкурентами, которые называют сроки существенно меньшие, на практике - делают проект гораздо дольше и с большими потерями?

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

  • 2 июня 2009 в 23:59 • #
    Михаил Зырянов

    Борис, боюсь, что все совсем не так: ИТ-специалистов, в том числе разработчиков, в стране сильно не хватает, а цены на заказную разработку в России высокие.

    Вот что говорят наши эксперты:
    http://www.osp.ru/cio/2006/02/379845/
    http://www.osp.ru/cio/2005/09/379588/ (в самом низу)

    Более того, ИТ-директора рассказывали, что незадолго до кризиса стоимость труда разработчиков настолько возросла, что дешевле было нанять разработчиков в США, чем в России, при этом качество разработки было бы существенно лучше.

  • 3 июня 2009 в 01:18 • #
    Борис Вольфман

    Михаил! По моим неофициальным даным, годовой доход квалифицированного разработчика в США от 100000$ и более. Нет у меня даных, что разработчик в России имел до кризиса от 8000 у.е.
    Думаю, труд российского программиста дороже американского по другим причинам: производительность, ответственность, производственная дисциплина и т.п.
    Причина дефицита разработчиков не только в отсутствии ВУЗовской подготовки, но и в неэффективной организации разработки.
    На первом месте - требования, на втором - слабое разделение функциональных обязанностей, соответствующих квалификации. Архитектор, как правило кодирует, аналитик расписывает детальные требования, а тестировщик - разрабатывает тест-кэйсы и тестирует.
    В результате - дефицит квалифицированных кадров.
    И не нужно забывать о не всегда обоснованной смене технологий. В тех же Штатах Кобол еще до сих пор эксплуатируется.
    Также, мне сегодня не известно, кто готов оплачивать разработку. Как я писал ранее, настройки прикладных програмных продуктов я к разработке не отношу.
    Был бы искренне благодарен, если бы Вы хотя бы намекнули, кто готов Заказать и ждать программное решение, разрабатываемое в полном соответствии с РУП, PMI или другой методике.

  • 3 июня 2009 в 10:19 • #
    Юрий Нестеркин

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

  • 3 июня 2009 в 15:48 • #
    Антон Еременко

    Борис, Средняя зп по отрасли в США $63 000, а что касается производительности, то она гораздо выше, да и продукты зачастую более качественные. И это все не смотря на то, что 30% рабочего вермени разработчики тратят на исполнение процедур разработки ( заполнение всяческих метрик, участие в обсуждении разных документов и тд).

  • 3 июня 2009 в 23:30 • #
    Борис Вольфман

    Антон! Наши цифры не противоречат друг другу.
    Скажу больше: от 10 до 20 % времени разработчики должны тратить на свободное плавание и саморазвитие, тренинги. Это принято у мировых лидеров: google, microsoft и т.п.
    Для борьбы с главным врагом разработчика "СЛОЖНОСТЬЮ" все меры хороши: agile рекомендует пиво, я возил ведущих архитекторов по дорогам Европы и т.п., некотрые отвозят генераторов на корабль и т.п.

  • 3 июня 2009 в 10:44 • #
    Пышнов Владимир

    Использую стандартные методики из классического менеджмента. Чем проще методика, тем лучше. К тому же роль личности в истории никто не отменял :)

  • 15 июня 2009 в 19:23 • #
    Татьяна Павлова

    На мой взгляд - главная причина неуспеха IT - проектов в недостаточно эффективном взаимодействии между людьми-участниками этого проекта.

  • 23 июня 2009 в 10:53 • #
    Николай Желтовский

    В свою очередь причина недостаточного взаимодействия - недостаток опыта в руководстве проектами.

  • 23 июня 2009 в 11:38 • #
    Татьяна Павлова

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

    Если любой проект рассмотреть с точки зрения : сроков выполнения, качества, стоимости работ , объема работ.
    То существует правило : 50% на 50% .
    Половину этих параметров контролирует к заказчик, а вторую половину подрядчик. Несоблюдение этого правила - тоже причина неуспеха IT - проектов.

  • 23 июня 2009 в 20:26 • #
    Николай Желтовский

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

  • 30 июня 2009 в 18:23 • #
    Валерий Лубневский

    Думаю, что коренная проблема в коммуникациях между Закзчиком (бизнесом) и Исполнителем (аналитиками и программистами). Нет понимания - нет хорошо проработаных тебований, большие объимы переделок, нет заинтересованных пользователей и т.д и т.п.
    Нужно значительно больше работать вместе заказчику и исполнителю!