Требуют ли ИТ-проекты особого управления?
23 апреля 2009 в 15:33

Требуют ли ИТ-проекты особого управления?

Вчера в ходе 16-го CIO-Форума из уст одного из докладчиков, уважаемого ИТ-директора, прозвучало утверждение о том, что ИТ-проекты требуют особого подхода к управлению и что традиционные методики управления проектами (например, PMBok) не могут быть применены успешно к ИТ-проектам. Что меня удивило, многие из тех, кто был в зале (в основном ИТ-руководители), услышав это, одобрительно закивали.

Как вы считаете, насколько справедливо данное утверждение? В самом ли деле ИТ-проекты — это нечто особенное?

552
Комментарии (57)
  • 23 апреля 2009 в 17:08 • #
    Игорь Цесельский

    Михаил, полагаю, что и да и нет.
    Точно так же как и проекты в сфере строительства и тп
    Скажем так - есть своя специфика. И есть общие подходы к УП..
    Реакция зала - понятна, это выражение корпоративной солидарности и понятное желание выделить "особенность" своей сферы.
    Да и само монятие "проекты в сфере IT" требует уточнения.
    Проекты WEB-строительства и разработки ПО очень существенно отличаются от проектов развертывания и строительства СПД и DATA центров.

  • 23 апреля 2009 в 17:59 • #
    Наталья Сыч

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

  • 23 апреля 2009 в 18:13 • #
    Михаил Зырянов

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

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

    Вместе с тем, положение с ИТ-проектами, в частности, по внедрению информационных систем, критическое. По словам другого докладчика, 85% проектов такого рода заканчиваются неудачей, а оставшиеся 15% завершаются относительно успешно - но после пересмотра сроков и/или бюджета проекта (разумеется, в пользу увеличения).

  • 23 апреля 2009 в 18:31 • #
    Наталья Сыч

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

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

  • 24 апреля 2009 в 00:23 • #
    Сергей Кузин

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

  • 24 апреля 2009 в 01:46 • #
    Борис Вольфман

    Сергей!
    Документирование необходимо в первую очередь самому разработчику до того: систематизировать свои мысли. Лучшая документация для программиста - комментарии.
    Борьба с неопределенностью - План управления рисками,
    Прекрасно описаны в PMI, в RUP в MSF.
    40% нужно закладывать на новые разработки, 20% на программирование по имеющемуся шаблону (новая форма, отчет и т.п.).
    Управление требованиями и изменениями - основа управления ИТ-проектами.
    Закладывай изменения требований в начале проекта, делай устойчивую архитектуру к изменениям требований - тогда ты профессионал (не я придумал).
    Не понимаю, когда проекты выполняются редко, а что тогда делает разработчик?
    Профессионал всегда должен документировать, хотя бы для того, чтобы у себя списывать хорошие практики.
    Успехов.

  • 24 апреля 2009 в 12:35 • #
    Сергей Кузин

    Приветствую, коллега!
    Не все ИТ проекты связаны с разработками.

  • 26 апреля 2009 в 23:36 • #
    Борис Вольфман

    Сергей! Слово Проект подразумевает создание чего-либо нового или РАЗРАБОТКУ.
    Я согласен, что разработка предполагает не только изменение программного кода, новые релизы, патчи и т.п., проект может предполагать только настройки добавляющие функциональность в действующей системе, проектирование ЛВС и т.п. но это все, что создается, должно документироваться, хотя бы для того, чтобы в отпуске не тратить деньги на роуминг.
    Вывод -ИТ-проект и разработка - слова синонимы если руководствоваться определением проекта по PMI.

  • 27 апреля 2009 в 07:49 • #
    Сергей Кузин

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

  • 27 апреля 2009 в 21:53 • #
    Борис Вольфман

    Сергей! Мне кажется, мы с Вами вместе занимаемся флудом. Мы в рубрике ИТ-проекты. Причем тут музыка, пиво, голое колено?

  • 23 апреля 2009 в 19:48 • #
    Константин Куличенко

    На самом деле очень много it директоров устали от долгих, сложных разработок с использованием методологий PMBok, RUP.
    Хотят быстрых и эффективных.
    Мы своем клиентам предлагаем вести проект по scrum (agile) - методологии,. Используя данную технологию, IT директор может эффективно и в минимальные сроки показывать результат. Бизнес вовлечен в процесс. Достижение первого значимого результата происходит достаточно быстро.

  • 23 апреля 2009 в 20:11 • #
    Владимир Скрипачев

    Считаю, что для ИТ-проектов различного направления (разработка ПО, создание информационной инфраструктуры предприятия и т.п.) подойдет унифицированный процесс (RUP). Доводилось использовать на практике. Весьма эффективно.

  • 23 апреля 2009 в 20:20 • #
    Михаил Сидоров

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

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

    Особенности ИТ-проекта связаны исключительно с особенностями производства наукоемкого высокорискового мягкого товара.
    Но внешнее оформление должно безусловно быть в рамках PMI.
    Паспорт проекта, освоенный объем и т.п.
    Если ИТ-проект связан с другими проектами компании, вопрос использования единой методологии управления проектами даже не обсуждается.
    Если он автономный, не связан с бизнесом компании, то кому он нужен?
    Даже для софт-компании ИТ-проект выпуска нового релиза должен быть связан с проектами маркетинга, продаж, тиражирования и т.п.
    Вывод однозначный:
    Оболочка должна соответствовать PMI, а внутреннее исполнение учитывать специфику вида деятельности.
    PS! Еще один аргумент: ИТ-проект должен быть прозрачным для Заказчика.

  • 24 апреля 2009 в 16:01 • #
    Михаил Зырянов

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

    Как правило, заказчиками серьезных ИТ-проектов являются бизнес-подразделения и их руководители. Но бывают и инфраструктурные проекты, которые выполняются, конечно, в интересах бизнеса, но имеют сильную ИТ-специфику. Например, проекты по созданию или модернизации центров обработки данных (по сути, внутренних вычислительных центров).

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

  • 27 апреля 2009 в 00:04 • #
    Борис Вольфман

    Михаил! Тогда пожалуйста конкретизируете, кого Вы называете уважаемый ИТ-директор. Какие процессы обеспечивает его ИТ-подразделение. Если только support, то пусть работают по ITIL, Но внедрение ITILa оформляют в форме отдельного проекта. Если они даже одну команду меняют в бизнес-приложении, то они должны протестировать новую функциональность, регресс организовать, сборку архивировать, чтобы было чего восстановить после сбоя и т.п. - ПРОЕКТ. Я бы честно говоря не называл ИТ-директорами руководителей подразделений, которые максимум на что способны, проинсталировать видеоконференцсвязь. Хотя там также нужно не только привинтить, но и обучить пользователя, написать инструкцию, обеспечить техническую поддержку. Максимум на что они тянут в должности - руководитель группы. У меня встречный вопрос - эти мелкие работы окупают зарплаты исполнителей?

  • 27 апреля 2009 в 00:42 • #
    Михаил Зырянов

    ИТ-руководители, как правило, различают масштаб проекта. Небольшие доработки в модулях бизнес-приложений или, например, работы по плановой замене сервера или коммутатора зачастую оформляются как "задания", но не как "проекты". Критериями здесь являются в первую очередь бюджет и трудоемкость. Отчасти это оправдано, так как подобные "мелкие" работы, насколько я знаю, охватываются ITIL.

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

    Крупные проекты, в которых участвуют ИТ-директора, - это, например, внедрение бизнес-приложений масштаба предприятия или крупного подразделения (ERP, CRM, SCM, BI и пр.). В такие проекты практически всегда вовлекаются сотрудники других подразделений, часто - высокопоставленные менеджеры, в том числе представители правления или совета директоров. В таких случаях, как правило, создаются проектные команды.

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

  • 27 апреля 2009 в 01:14 • #
    Борис Вольфман

    Михаил! Давайте вернемся к Вашему вопросу:
    Как вы считаете, насколько справедливо данное утверждение?
    В самом ли деле ИТ-проекты - это нечто особенное?

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

    На одном обсуждении один идеолог PMI очень метко парировал одному владельцу крупной компании: А что, если мы не будем внедрять проектный подход?
    - Тогда придут "западные высокоорганизованные команды и вас уберут с рынка".

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

  • 27 апреля 2009 в 19:50 • #
    Михаил Зырянов

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

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

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

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

  • 27 апреля 2009 в 21:40 • #
    Борис Вольфман

    Михаил!
    Вы мне не ответили на вопрос: вид деятельности ИТ-директора.
    И с какими пунктами PMI он не согласен: Паспорт проекта, План управления рисками, План управления качеством ???
    Что касается наших разногласий по поводу supporta - то они отсутствуют, есть разногласия в интерпретации некоторых взаимных высказываний - не более.
    Скажу больше, так как я представляю разработку - с полной ответственностью могу заявить, что она уникальна.
    Не просто создать коллектив, способный разрабатывать программный продукт, развивать его, обеспечить тиражирование и т.п., но еще сложнее инвестировать разработку с малой долей уверенности, что результат будет положительным.

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

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

    Культура проектного управления низка у ВСЕХ без исключения. Она будет низкой до тех пор, пока финансирование не будет проводиться в строго в рамках проектов.

    По поводу "бюрократии" нужна конкретика: Что лишнее - устав, План управления рисками, определение целей проекта ???

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

    Нечего Заказчиков "грузить" проектом - лучше грузить результатом.

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

    Михаил! Предлагаю Вам организовать КРУГЛЫЙ стол по данному обсуждению и осветить это в Вашей прессе. Не забудьте меня пригласить и квалифицированного ИТ-Директора. Лет 10 тому назад я участвовал в таком круглом столе со своей реальной ФИО - Женя Зиндер организовывал, и Вы принимали активное участие. Но что обсуждали - не помню.

  • 28 апреля 2009 в 00:11 • #
    Михаил Зырянов

    Борис, рад снова общаться с Вами! Относительно круглого стола подумаем, спасибо за хорошую идею!

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

    Затрудняюсь точно воспроизвести критику, которую высказывал тот ИТ-директор, но если коротко - "традиционные методики управления проектами в приципе не годятся для управления ИТ-проектами".

    Относительно уникальности разработки я в курсе - сам по образованию разработчик программных систем.

  • 28 апреля 2009 в 20:37 • #
    Борис Вольфман

    Еще один аргумент неприятия проектного подхода Заказчиками и ИТ-Исполнителями я добавлю:
    Если следовать рекомендациям PMI, то стартовать проект без оценки прибыльности затруднительно.
    ИТ-Исполнитель - как правило авантюрист (формулу -" срок названный программистом умножить на 2 + 2 месяца" все знают).
    Дать реальный срок, трудоемкость и стоимость - заказ не получить. Заказчик считает, что Исполнитель накручивает сроки, стоимость. Конкуренты не-проектные естественно устраивают демпинг.
    Результат стандартный - сроки провалены, функционал не соответствует ожидаемому, качество вне конкуренции.
    Обращаю внимание, что и Исполнитель и Заказчик могут прекрасно знать PMI, но один не получит Заказа, а у другого нет денег оплатить проектную разработку.

    Также я обращаю Ваше внимание на термин: ПРОЕКТНО_ПРОЦЕССНЫЙ подход. То есть каждая задача проекта должна реализовываться в соответствии с типовым процессом: например: системный анализ - это не только написать ТЗ, но и согласовать с Заказчиком, Архитектектором и Тестировщиком.
    Процессы - кирпичики, из которых строится проект.
    Функциональный руководитель отвечает за правильность процессов, менеджер - за исполнение проекта. Двоевластие этих ролей и обеспечивает компромиссный треугольник: качество-сроки-функции.
    Эту философию понимают очень немногие - выучить PMI недостаточно, нужно наступить на грабли и сделать ВЫВОДЫ.
    И основная проблема ИТ-руководства - опытные ИТ-Директора не изучают новые методики, а молодые сертифицированные супер-менеджеры не имеют опыта.
    Это я все о проблемах проектного управления.
    Не думаю, что в строительстве другие проблемы. Просто ИТ супер динамически развивается и проблемы отцов-детей гипертрафированы.
    Спасибо.

  • 24 апреля 2009 в 08:25 • #
    Валентина Майорова

    Я думаю здесь надо подходить индивидуально.

  • 24 апреля 2009 в 12:38 • #
    Сергей Кузин

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

  • 24 апреля 2009 в 13:33 • #
    Валентин Дроздов

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

  • 24 апреля 2009 в 16:05 • #
    Михаил Зырянов

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

  • 24 апреля 2009 в 20:27 • #
    Ирина Булычева

    ИТ проекты очень индивидуальны. Простое документирование часто приводит к формализму без реальной пользы.

  • 27 апреля 2009 в 00:11 • #
    Борис Вольфман

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

  • 27 апреля 2009 в 10:18 • #
    Ирина Булычева

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

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

  • 28 апреля 2009 в 20:45 • #
    Борис Вольфман

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

  • 1 мая 2009 в 09:19 • #
    Ирина Булычева

    Борис! Моя классификация документирования как раз не надумана, а дана на личном опыте неоднократных успешных внедрений после провалов проектов другими фирмами, которые обязательно применяли формализованный подход, но, формальное документирование - часто эквивалентно его отсутствию и не гарантирует результат работы.
    Предложение ориентироваться на себя - не подходит.
    Лично я могу и без документирования разобраться. В основном, так и приходится.. Так что, если буду документировать, как достаточно для меня - остальные не поймут, это точно.:)
    Поэтому, документирую для заказчика, чтобы было понятно именно ему. Для себя включаю только принципиальные моменты, когда возможна различная трактовка.

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

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

    Должна быть простая архитектура со слабыми связями, устойчивая к изменениям требованиям в процессе испытаний у Заказчика.
    И никакие комментарии и debug не помогут (наоборот могут ввести в заблуждение), если архитектура неадекватна, а таких реализаций БОЛЬШИНСТВО.

  • 1 мая 2009 в 10:06 • #
    Ирина Булычева

    Вообще-то, я постоянно разрабатываю документацию. По стандартам. Совет запоздал. :)
    Мы о разном.
    Тема - Требуют ли ИТ-проекты особого управления.
    Я о том, что - да, требуют индивидуального подхода.

  • 1 мая 2009 в 10:11 • #
    Борис Вольфман

    В чем индивидуальность. Строитель так же может сказать - этот гвоздь с другой стенки и требует индивидуального подхода.

  • 2 мая 2009 в 16:57 • #
    Ирина Булычева

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

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

    Ирина! Проблемы, которые Вы обозначаете - интернациональны: посмотрите RUP и Вы найдете ответы на многие вопросы:
    Управляйте требованиями, Управляйте изменениями, Управляйте документированием и обеспечивайте устойчивость архитектуры и не изобретайте новые термины.
    Каждый документ должен быть ориентирован на своего Читателя.
    Если пишете документ для Заказчика, не нагружайте техническими деталями и особенностями реализации.
    Очень не просто описать программный продукт простым языком, доступным для Заказчика.
    И ГОСТы при документировании не игнорируйте. Для Заказчика я бы рекомендовал ГОСТ34.
    Успехов.
    Обратил внимание на Вашу 2-у специальность "Главный бухгалтер" и предлагаю провести аналогию:
    Несколько листиков баланса и отчета о прибылях и убытках и грамотный Заказчик может оценить состояние предприятия в малой зависимости от его вида деятельности.

  • 1 мая 2009 в 09:52 • #
    Ирина Булычева

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

  • 1 мая 2009 в 10:06 • #
    Борис Вольфман

    Так проблема была извините в другом: в понимании предметной области, а не в наличии комментариев простых и непростых.
    И другая проблема, с которой лично я постоянно сталкивался: незнание Заказчиком своей предметной области. И Вы стратегически неверно действуете (или я неверно Вас интерпретировал).
    Вы обязаны у каждого индивидуального Заказчика выделять общие с другими Заказчиками требования и затем учитывать незначительные особенности. ЦЕНТРИЧНОСТЬ разработки. И обучать Заказчика как его задачи решать с помощью своих программ..
    Успехов.

  • 1 мая 2009 в 16:43 • #
    Ирина Булычева

    "...Вы обязаны ..."
    Это кому я обязана?
    Обязана я делать то, за что мне платят.
    А платят мне именно за то, что успешно внедряю проекты, проваленные из-за отсутствия индивидуального подхода.

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

    Ирина! Полностью с Вами согласен, что Вы не обязаны, так же как и я не обязан Вам рекомендовать использовать конструкторы: АГРЕГАЦИЯ и ОБОБЩЕНИЕ в Вашей работе. Допускаю, что Ваши Заказчики требуют от Вас исключительно индивидуального подхода (не учитывать особенности и специфику их деятельности, а именно все делать индивидуально).
    Я желаю только успехов Вам, если в каждом конкретном случае Вы игнорируя традиционные методики управления проектами, разрабатываете свои.
    Но я пока не увидел в Вашей работе ничего оригинального, не описанного в традиционных методиках.
    Также считаю бесперспективным каждый проект делать с 0, не заимствуя по крайней мере у себя лучших практик предыдущих проектов. Подозреваю, что Вы именно так и делаете, но подсознательно и спорите со мной ради спора, не более.
    Иначе, у Вас не было бы успешных проектов.
    А ввиду серьезной загруженности над индивидуальными подходами Вы досконально не изучили PMBok и делаете вывод, что ИТ-проект требует индивидуального подхода.
    Повторяю, учитывать особенности и индивидуальный подход - для меня разные вещи.

  • 24 апреля 2009 в 22:02 • #
    Vitaliy Chigiryov

    Мое мнение в том, что особого управления требуют люди разрабатывающие IT-проект в конкретное решение.

    Аргумент за: Вы же не будете нанимать дураков?

    Аргумент против: Мне не доводилось управлять IT проектом

  • 1 мая 2009 в 23:17 • #
    Кирилл Васильев

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

  • 2 мая 2009 в 09:02 • #
    Ирина Булычева

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

  • 2 мая 2009 в 23:54 • #
    Кирилл Васильев

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

  • 3 мая 2009 в 00:15 • #
    Ирина Булычева

    Автоматизация бухгалтерского учета - это совсем небольшая часть работы по проектам, которыми я сейчас занимаюсь (УПП, УСО и т.д.).
    Мой опыт внедрения управленческого учета с разработкой бюджетирования с нуля, а также, разработка дополнительных специализированных производственных подсистем к этим программам с самостоятельной разработкой ТЗ, предполагает достаточное понимание сложности IT-проектов.
    До этого был серьезный опыт разработки и руководства по IT проектам другого профиля, с обязательной работой по ГОСТ.

  • 4 мая 2009 в 01:28 • #
    Борис Вольфман

    Ирина! Если Вы человек-оркестр: в одном лице: руководитель проекта, аналитик (пишете ТЗ), ведущий инженер-программист и главный бухгалтер и технический писатель, то я с Вами согласен: Ваш подход индивидуальный и не соответствует традиционным методикам управления проектами. аналитик и программист не совмещаются одним исполнителем.
    Повторно рекомендую Вам более тщательно ознакомиться с традиционными методами управления проектами чтобы минимизировать наступление на грабли, на которые наступили до Вас очень много наших коллег прежде, чем разработать PMBok, RUP, MSF и т.п. и наступают и будут наступать те, кто игнорирует все лучшее, что есть в традиционных методиках управления проектами.
    Просто их ни в коем случае нельзя воспринимать как догму, а исключительно, как руководство к действию.
    Успехов в борьбе со сложностью.

  • 14 мая 2009 в 13:58 • #
    Ruben Girgidov

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

    Обсуждать имеет смысл только в рамках проектов одного типа.

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

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

    К стати я тут нарвался на очень верное на мой взгляд замечание PMI стандарт не является лучшим, он является универсальным и как все универсальное в каждом конкретном случае хуже специализированных методов (респект Ирине).
    Другой вопрос, что можно работать в стиле не знаешь как, действуй по PMBook и будет результат или по крайней мере, будешь знать, чем прикрыть скажем тылы.

  • 20 мая 2009 в 18:47 • #
    Максим Смирнов

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

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

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

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

  • 2 июня 2009 в 11:30 • #
    ОтДебильногоСайта Фа

    IT-проекты отличаются не качественно, а количественно. Но довольно сильно.

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

    Да, не удобно в этом случае полностью оформлять проект по PMBoK. Но пока лучше вариантов не видел. Сокращение документирования увеличивает риски проекта, хоть ты тресни ;)

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

  • 3 июля 2009 в 17:05 • #
    Ruben Girgidov

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

  • 22 июля 2009 в 09:20 • #
    ОтДебильногоСайта Фа

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

  • 23 июля 2009 в 01:39 • #
    Ruben Girgidov

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

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

    2. событийность модели рекламной компании, например, мы даем рекламу на телевидении в течении 2 недель, в процессе этой рекламы мы делаем опросы населения о продукте если в течении 2 недель мы не узноваемость бренда до 10% рекламу мы или прекращаем или на оборот добавляем к ней рекламу на радио. Другими словами есть события, которых мы ждем, чтобы повести проект в одном или в другом направлении.

    Это я и называю спецификой рекламных проектов в IT такого не бывает (по крайней мере, я не слышал)

  • 23 июля 2009 в 09:19 • #
    ОтДебильногоСайта Фа

    В проектах автоматизации очень похоже, только дороже на стадии итераций.

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

    А дальше внедрение, и как в прокате рекламы есть ожидаемые контрольные события. Только не на внешнем рынке, а на предприятии (выход на нормативы оформления документов, прохождение контроля в определенных областях, запуск отдельных схем учета и т.п.)

  • 26 июля 2009 в 00:31 • #
    Ruben Girgidov

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

  • 6 июля 2009 в 14:00 • #
    Владимир Либерзон

    Михаил,
    песня знакомая, ее поют все руководители, не заинтересованные брать на себя ответственность и отвечать за плановые показатели. Независимо от отрасли, области приложения, формы собственности и т.д. И конечно подобные утверждения приветствуются коллегами, которые тоже не хотят ни за что отвечать. Ничего удивительного.
    В любой отрасли нужно учитывать ее специфику. Если это подразумевается под особым управлением, то конечно.
    Как было верно замечено во многих обсуждениях, IT проекты бывают разные - разработка софта, внедрение какой-либо системы, организация call центра - все эти совсем разные проекты относятся к IT и специфика у них разная.

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

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


Выберите из списка
2018
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008