• Тупые пользователи – вот кто проваливает проекты!

    Posted on March 15th, 2010 Александр Орлов 6 comments

    Слушательница нашего новосибирского тренинга Анна Сартакова опубликовала любопытный обзор исследований успешности проектов. В очередной раз увидел статистику от Standish Gorup и снова порадовался:

    Результат завершения проекта 1995 2002 2004 2006 2008
    Завершены успешно 16% 34% 29% 35% 32%
    Вышли за рамки запланированного бюджета, сроков, либо не достигли цели 53% 51% 53% 46% 44%
    Потерпели неудачу 31% 15% 19% 19% 24%

    Что еще пишут исследователи:

    Исследователи также пишут, что были названы и такие забавные причины как “brain-dead users, only brain-dead users” (тупые пользователи, это всё тупые пользователи!).

    Однозначно! Тупые пользователи – с ними ничего нельзя поделать!

    Ну и напоследок товарищ Роберт Голдсмит, конечно, сказал правду:

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

    Кроме тупых пользователей портят всю малину неадекватные заказчики! Которые все время меняют требования!

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

    Анна Сартакова “Такая вот статистика”

    Захотелось поделиться некоторой интересной информацией, которую удалось собрать в процессе написания главы диплома:

    1. Статистика завершения IT-проектов за последние годы

    По данным исследования The Standish Group, в 2008 году только 32% всех IT – проектов были завершены успешно, в то время как 44% проектов вышли за рамки запланированного бюджета и сроков, а 24% проектов и вовсе потерпели неудачу (рисунок 1).




    Рис. 1 - статистика завершения IT – проектов в 2008 году

    Если посмотреть динамику завершения проектов за 2002-2008 гг (рис.2), то можно увидеть, что есть небольшие изменения в лучшую сторону, но в целом последние годы “топчемся на месте”, в то время как если сравнить с 1995 годом, то есть существенный прогресс (таблица 1).


    Таблица 1 – Статистика завершения IT – проектов за 1995-2008 гг.

    Результат завершения проекта 1995 2002 2004 2006 2008
    Завершены успешно 16% 34% 29% 35% 32%
    Вышли за рамки запланированного бюджета, сроков, либо не достигли цели 53% 51% 53% 46% 44%
    Потерпели неудачу 31% 15% 19% 19% 24%

    Рис. 2 - Динамика завершения IT – проектов за 2002-2008 годы

    2. Причины успехов и неудач проектов по версиям различных исследователей

    В отчёте за 2006 год исследователи The Standish Group приводят следующие причины успешного завершения проектов:

    Таблица 2 – Ключевые факторы успеха проектов

    Ключевой фактор успеха Процентная доля фактора
    Высокая степень вовлечённости заказчика и пользователей в процесс разработки проекта 15,9%
    Заинтересованность и поддержка топ менеджмента 13,9%
    Понятно и однозначно сформулированные требования к продукту 13%
    Качественное, эффективное планирование 9,6%
    Реалистичные ожидания 8,2%
    Планирование мелкими вехами 7,7%
    Компетентный персонал 7,2%
    Чёткие цели и концепция проекта 2,9%
    Заинтересованная, замотивированная проектная команда 2,4%
    Другое 13,9%

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

    Таблица 3- ключевые факторы проблем проектов (выхода проектов за рамки сроков и бюджета, недостижение цели).

    Фактор Процентная доля фактора
    Низкая степень вовлечения заказчика или пользователей в процесс разработки проекта 12,8%
    Недостаточно определённые требования 12,3%
    Изменение требований в процессе разработки проекта 11,8%
    Недостаточная поддержка проекта топ менеджментом 7,5%
    Использование неподходящей технологии 7%
    Недостаточное обеспечение проекта ресурсами 6,4%
    Нереалистичные ожидания 5,9%
    Недостаточно ясные цели 5,3%
    Нереальные временные ограничения 4,3%
    Использование новой технологии 3,7%
    Другое 23%

    В качестве ключевых факторов, ведущих проект к неудаче, были названы следующие:

    Таблица 4 – ключевые факторы неудач проектов.

    Фактор Процентная доля фактора
    Неполные требования 13,1%
    Низкая степень вовлечения заказчика или пользователей в процесс разработки проекта 12,4%
    Недостаточное обеспечение проекта ресурсами 10,6%
    Нереалистичные ожидания 9,9%
    Недостаточная поддержка проекта топ менеджментом 9,3%
    Изменение требований в процессе разработки проекта 8,7%
    Недостаток планирования 8,1%
    Цель проекта перестала быть актуальной 7,5%
    Недостаток управления IT 6,2%
    Некомпетентность в используемой технологии 4,3%
    Другое 9,9%

    Все эти причины исследователи почерпнули из опросов Топ-менеджеров, руководителей проектов, а также других сотрудников компаний, ведущих IT – проекты. Исследователи также пишут, что были названы и такие забавные причины как “brain-dead users, only brain-dead users” (тупые пользователи, это всё тупые пользователи!).

    Авторы отчёта в качестве главной рекомендации приводят итеративный процесс разработки, причём итерации должны быть короткими по времени и завершаться созданием промежуточного продукта или его компонентов. Хотя такой процесс давно предусмотрен в различных методологиях разработки (RUP, Agile), проекты всё равно терпят неудачи!

    В то же время, президент консалтинговой компании «Go Pro Management, Inc» Роберт Голдсмит считает, что реальными причинами проблем и провалов проектов разработки ПО являются:

    1. Бюджет и сроки проекта назначаются без учёта объёма выполняемой работы;
    2. Сложность описания реальных бизнес требований на старте проекта. В индустрии существует распространённое мнение о том, что в процессе разработки продукта требования к нему непрерывно меняются, ввиду чего в процессе выполнения проекта увеличиваются его сроки и бюджет. Автор же считает, что на самом деле стремительного изменения бизнес-требований не происходит, а проблема в том, что разработчики не могут распознать реальные потребности бизнеса заказчика;
    3. Также автор приводит различные психологические факторы, содействующие срыву сроков и провалу проектов, такие как рефлексивность: пользователи (или заказчик), зная статистику завершения IT – проектов, не верит обещаниям разработчиков завершить проект в заданный срок, поэтому и не старается добиваться от них соблюдения обещаний по срокам, и получается замкнутый круг :)

    Исходная информация на английском языке:

    1. Статистика завершения IT-проектов 2009, The Standish Group ;
    2. Отчёт The Standish Group за 2006 год ;
    3. Ещё отчёт за 2006 год;
    4. Отчёт The Standish Group за 1995 год;
    5. Отчёт The Standish Group “Chaos rising” 2004 год (ссылки нет, отчёт можно скачать после регистрации на сайте Standishgroup)
    6. Роберт Голдсмит, статья “Drowning in CHAOS?”, Go Pro Managemeing, Inc, 2008;

    Спасибо за внимание, прошу прощения, если что-то перевала не совсем корректно :)

     

    6 responses to “Тупые пользователи – вот кто проваливает проекты!”

    1. Отчеты Standish Group могут показаться забавными, но тем не менее нужно уметь их правильно “читать”. Дело в том, что все любят на основе этих отчет кричать “IT загибается”, “все проекты проваливаются” и тому подобное. При этом мало кто задумывается, что значат эти цифры.

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

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

      Третья группа это так называемые провальные проекты. Откуда пошло такое название? Standish Group называет эту группу проектов canceled. Но трактовка этого понятия у них несколько другая. Отмена проекта не означает его провал, а означает перезапуск! То есть проект был начат, что-то пошло не так и было решено вернуться к началу (проект был отменен). Но на второй итерации все пошло хорошо и он был закончен успешно (но это уже другой проект).

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

      Стоит заметить, что исследование The Standish Group неоднократно подвергались (и подвергаются) сомнению в зарубежной литературе. Если кому-то будет, интересно, могу об этом тоже написать. Кроме того, с факторами тоже не все так просто, но это уже тема для следующего обсуждения.

    2. > на самом деле стремительного изменения бизнес-требований не происходит

      Люто, бешено завидую биздеву.
      Хуже то, что и в геймдеве встречаются личности, верящие в то, что правильный дизайнер сразу пишет итоговое ТЗ на весь проект; в таких случаях сроки и бюджет, может, выдерживают, но по качеству получается только и исключительно треш. Ну или добротный клон например.

    3. Поэтому стоит обратить внимание и на вторую группу проектов, которые они называют challenged. Эти проекты тоже успешны в каком-то измерении (время, бюджет, удовлетворенность заказчика).

      Это вообще за пределами нашего отечественного понимания.
      У них такое возможно не только с проектами. У них это возможно с целыми фирмами. Я несколько лет назад работал на контору, которая была “перезапущена” именно таким образом. Они набрали инвестиций и стартанули. У них некоторое время всё шло нормально, но потом они где-то совершили ошибку и бизнес разорился. Так они пошли к инвестеру и повинились. Инвестер их простил и дал снова нужную сумму. Фирма была пересоздана и запущена вновь.
      Вот такие чудеса бывают в зарубежном бизнесе. У нас бы, наверно, давно всех на органы распродали. ;)

    4. @ Юрий Дайбов

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

    5. @ golergka

      Интересно, а что сказали первые инвестеры? Просто, имхо, у нас не работает принцип “ну не шмогла я” (с). Возможно, венчурное инвестирование как-то может позволить такое развитие ситуации, но я не уверен, что у нас это возможно.

    6. @ Юрий Дайбов
      Настолько близко я ситуацию не знаю; первая компания, в принципе, не совсем провальная, сейчас (сотрудников вывели, burn rate понизился) может даже на ноль вышла.

    Leave a reply

    You must be logged in to post a comment.