25% проектов не вписываются в бюджет, 31% — в сроки

    Каждый четвёртый веб-проект не вписывается в отведённый ему бюджет, а почти в каждом третьем случае разработчики не могут закончить работу к дедлайну. Такую мрачную статистику выявило новое исследование, проведённое компанией New Bamboo, которая занимается разработкой ПО на Ruby on Rails. В опросе участвовали около ста IT-менеджеров и директоров компаний.

    Главной причиной подобной безалаберности называют слишком большое количество сторон, участвующих в проекте и желающих повлиять на него. И это при том, что около половины веб-проектов создаётся силами собственного IT-подразделения компании и только 28% отдаётся на аутсорсинг.

    Неприглядная картина веб-разработки дополняется и другими цифрами. Оказывается, даже после всех согласований, возможного дополнительного финансирования и продления сроков 21% проект всё равно не соответствует требованиям заказчика. Печальные цифры сохраняются не только для крупных, но и для совсем мелких проектов. Ситуация усугубляется, если заказчик требует усложнить преокт и добавить в него модные современные технологии: социальные сети, приложения электронной коммерции, фичи Веб 2.0.

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

    Комментарии 37

      0
      Интересно, а кто делает оставшиеся примерно 20% проектов (те что не делают аутсорсеры и внутренние команды)?
        –3
        поминусуйте меня пожалуйста! я хочу работать!!!(((((
          0
          По моему опыту - если работаешь с фрилансерами, то проценты срыва сроков даже занижены.
          Это особенно актуально, когда работает над проектом больше 2-х фрилансеров...
            0
            мне кажеться если проект не вписываеться в сроки это прежде всего вина менеджера, в независимости от того где он допустил ошибку, в подборе персонала или в распределении нагрузки и т.п.
              0
              Я писал про именно фриланс - менеджер не в состоянии контролировать фрилансера по причине его удаленности.
              В постах на хабре не раз писалось про ТОП-10 отговорок фрилансеров, почему работа не была выполнена в срок. Это как раз из этой серии...
                0
                "менеджер не в состоянии контролировать фрилансера по причине его удаленности." - вы пропустили слово "плохой" в этой фразе, есть достаточно методов, которые позволяют отслеживать прогресс удаленно. Всякие milestones и т.п., я не фиг спец., но если всерьез покопаете наверняка найдете лит-ру по этой теме.
            +1
            Например в случае с нашей студией, действительно большинство проектов не завершаются в срок, но 99% - это вина заказчиков, которые строят из себя ОЧЕНЬ занятых людей, и не могут найти пол часа что бы ознакомиться с ТЗ или подписать акт. И это я еще молчу про то, насколько они опаздывают с оплатой и сколько времени приходиться буквально силой выбивать у них контент...
              +1
              +1, особенно милая их особенность - наполовину поменять ТЗ, когда над ним уже не первый месяц идёт работа...
                +2
                Ну это-то как раз естественно. Если вы делаете что-то новое, то понять в чём проблема зачастую невозможно пока работа не аделана на 60-70%, а если вы делаете то, что уже 100 раз сделано - то зачем вы это делаете?

                Другое дело что заказчик должен понимать что новое ТЗ => новые сроки и новые деньги.
                  0
                  да это понятно. другое дело, что иногда бывает такая ситуация, что вдруг решают поменять то, что в предыдущие две ревизии полностью устраивало.
                  Но в целом вы правы, конечно (:
                  0
                  Если вы заранее предполгаете, что ТЗ поменяется, то как советовали выше, донесите до заказчика, что такие изменения будут стоить денег и увеличат сроки разработки. Также стоит использовать одну из гибких методик разработки и при анализе требований определять возможность их изменения.
                  0
                  может если вести проект по почасовой оплате, ситуация будет иной? Скажем, в договоре указывается кол-во часов по ТЗ * стоимость человекочаса. В первоначальную стоимость проекта заклаываются часы по ТЗ, все, что сверху - отдельные платежи. Отбивает желание переплачивать напрочь :)
                    0
                    Наймите грамотного МП и составьте нормальные договоры.
                      0
                      А договор составить такой, что работы начинаются только после внесения предоплаты? ТЗ идет приложением к договору. Вот и пожалуйста, срок идет только когда все урегулировано и оплачено. По поводу простоев заказчика во время работы, так же прописывается в договоре. Скажем если заказчику предоставляют макет дизайна, то в течении скажем 3 дней он обязан высказать все пожелания. Если в течении этих дней он ничего не ответил, это его вина и срок автоматически продлевается. Главное все это точно прописать в договоре.
                      Все тоже самое с изменениями в ТЗ во время работы. Есть изменения, которые можно внести после сдачи. И тогда договориться с заказчиком, что это будет сделано после сдачи и заключить отдельный договор. А если надо сразу исправить, опять вносится дополнение к договору и продлеваются сроки.
                      +3
                      Мне кажется, что правильнее будет сказать: 90% проэктов не вписываются в бюджет и в сроки...
                      Какие-то цифры у вас заниженные )))
                        0
                        Абсолютно с вами согласен - цифры либо занижены, либо взят какой-то очень узкий сегмент рынка с низкой турбулентностью.
                          0
                          я вот и в строительстве работал , и в айти... даже не могу вспомнить такого проэкта, который вписался бы в заданные параметры.... Может у буржуев все получше налажено ?
                            0
                            очень может быть, подозреваю это данные как раз по буржуям, до которым нашим управленцам еще рости и рости
                              0
                              Обычно строительство приводят как раз в качестве образца, по крайне мере у буржуев, в управлении проектами. :)
                            0
                            статья продолжается следующим высказыванием одного Таннера:
                            "Используя комбинацию Ruby on Rails и Agile методы, проекты можно успешно и вовремя сдать, не превышая бюджет. Решение (проблемы) (или причина) лежит в ожидании больших успехов и достижения их путем применения повторяемых, гибких и упровляемых методов"
                            Надеюсь правильно перевел.
                            +1
                            Кстати очень полезны такие исследования в качестве аргументов перед разными заинтересованными сторонами: в разговорах о необходимости следовать указаниям project manager'a, а не считать разработку ПО таким же занятием как строительство сарая.
                              0
                              Ну, в принципе, статистика довольно интересная, если не считать, что об этом и так многие знают по личному опыту. Но мне было бы интересно узнать, что этим хотел сказать автор, и какие выводы он делает для себя из этой статистики?
                                0
                                По поводу влияния множества заинтересованных сторон - вообще это прямая обязанность руководителя проекта учитывать эти возможные воздействия. Под это подогнано достаточно много теории, да и практика наработана гигантская.
                                А для совсем маленьких проектов достаточно анализировать возможность влияния на проект и заинтересованность в удачном завершении проекта. Таким образом, можно выделить "лузер юзеров", у которых при удачном завершении проекта будут неприятности (их уволят в результате автоматизации или сократят полномочия и так далее) - у этой группы пользователей большие возможности влияния на проект и отрицательная заинтересованность в его удачно завершение. На другом конце стоят потенциальные "доноры" или "спонсоры", которые могут сильно повлиять на проект и кровно заинтересованны в его успешности - это надо обязательно использовать.
                                  0
                                  может, прежде чем что либо обсуждать, автор приведет подобную статистику и по другим видам человеческой деятельности?
                                    0
                                    Статистика любопытная, но вообще есть еще такая штука - "управление рисками". Как показывает практика, три четверти проблем со сроками решаются двумя способами - не полагаться на сроки, которые разработчики называют руководителю и не позволять заказчикам делать устные "добавления, примечания" и вводить новые функции. Подписание ТЗ и акта сдачи-приемки работ по каждому этапу работ сильно снижает риск не успеть в срок.
                                      0
                                      Адекватное планирование — вот чего не достает в этом случае. А то пеняют на факт, когда план кривой.
                                      0
                                      Знаете, бывают совсем интересные срывы сроков: приходишь к программисту (я как проджект), вместе пишете тз, вместе определяете время. Это время умножается на ТРИ и еще накидывается пару-тройку деньков сверху и называется клиенту. И что вы думаете: и эти дедлайны срываются.

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

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

                                          Но безусловно, я считаю, что все это не причина для срывов, а просто недоработки менеджера проекта.
                                            0
                                            если все было бы ровно и предсказуемо ваша профессия бы вымерла,
                                            но безусловно она не вымрет и с таким подходом у вас все будет хорошо. :)
                                        0
                                        Какой-то слишком оптимистичный процент про сроки-то.
                                          0
                                          Значит сроки нужно умножать на пять, а не на три. :)
                                            0
                                            У проекта прежде всего должен быть один ответственный, который может не побояться и на тупого заказчика наехать, если надо, а не только сопли жевать. Короче, опытный ми влиятельный человек.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Наша компания http://www.pmbox.ru занимается разработкой ПО для организации совместной работы, help desk и управления проекта и уже несколько лет, в общем мы «в теме» ). Поэтому есть что сказать:

                                                Что надо чтобы проекты завершались в срок:

                                                1. Проектом надо управлять. Это значить, что должно быть хотя бы минимальное образование в области управления проектами. Сейчас это выглядит так, есть «менеджер проекта», который даже определение, что такое «проект» сказать не может. Команда проекта часто вообще не в теме, что они работают в проекте, об образовании можно умолчать, его нет или компания не тратит деньги на обучение своих сотрудников. Конечно так не везде, но думаю, в области веб разработки в России это встречается часто.

                                                2. Для управления проектами нужен инструмент. Соответственно специализированное ПО и методология его использования. Можно конечно все делать на бумаге (или в гугле докс), но это достаточно муторно и затратно по времени. Если вы управляете проектами, то вам нужен инструмент «лопата», который вы и будете «копать» свой проект.

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

                                                4. Работа с заказчиком. Большинство людей (да и заказчиков) очень хорошо понимают язык денег. Если вы подписали договор с заказчиком по уже утвержденному ТЗ, то сразу жестко обговаривайте стоимость изменений в проекте. Новое требование – отражение в ТЗ, работа над ТЗ стоит денег и соответственно приостановление проекта и перенос сроков. В этом случае, будет проблема с планированием ваших ресурсов, распределением их по проектам, за что и надо штрафовать заказчика. Оплата лучше всего, должна быть привязана к вехам проекта, сделали дизайн, согласовали, подписали акт, оплатили, ТЗ и так далее. Часто сделать правильное ТЗ очень затратно и не всегда оправданно, как вариант применение «прототипирования».

                                                Понятно, что в работе над проектом одного инструмента, только для ведения проектов будет мало. Как правильно минимально нужны инструменты организации совместной работы, управления заявками/запросами клиента, средства обмена информацией участников проекта, система уведомлений по событиям в проекте. Задача менеджера проекта организовать эффективную работу команды с помощью различных инструментов, методологий и регламентов.

                                                Если все будет организованно правильно то процент завершенных проектов у вас будет выше среднего по индустрии (соответственно и денег) )
                                                  0
                                                  Если работать "вовнутрь" - уже начинаешь задумываться, лучше это или хуже, чем на клиентов под крылом аутсорсинговой компании, потому что управляющие проектов внутри компании - гораздо более "творческие" люди, и очень тяжело выбить из них ТЗ и доказать, что если оно принято и согласовано - все крупные переделки и "небольшая смена концепции" будут только после 100% завершения, никто не хочет этого слушать, а соответственно, дедлайны отодвигаются на сроки, несоизмеримые с теми изменениями, которые насыпаются
                                                    0
                                                    И к чему интересно упоминается RubyOnRails?

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

                                                    Самое читаемое