Комментарии 37
Интересно, а кто делает оставшиеся примерно 20% проектов (те что не делают аутсорсеры и внутренние команды)?
поминусуйте меня пожалуйста! я хочу работать!!!(((((
По моему опыту - если работаешь с фрилансерами, то проценты срыва сроков даже занижены.
Это особенно актуально, когда работает над проектом больше 2-х фрилансеров...
Это особенно актуально, когда работает над проектом больше 2-х фрилансеров...
мне кажеться если проект не вписываеться в сроки это прежде всего вина менеджера, в независимости от того где он допустил ошибку, в подборе персонала или в распределении нагрузки и т.п.
Я писал про именно фриланс - менеджер не в состоянии контролировать фрилансера по причине его удаленности.
В постах на хабре не раз писалось про ТОП-10 отговорок фрилансеров, почему работа не была выполнена в срок. Это как раз из этой серии...
В постах на хабре не раз писалось про ТОП-10 отговорок фрилансеров, почему работа не была выполнена в срок. Это как раз из этой серии...
"менеджер не в состоянии контролировать фрилансера по причине его удаленности." - вы пропустили слово "плохой" в этой фразе, есть достаточно методов, которые позволяют отслеживать прогресс удаленно. Всякие milestones и т.п., я не фиг спец., но если всерьез покопаете наверняка найдете лит-ру по этой теме.
Например в случае с нашей студией, действительно большинство проектов не завершаются в срок, но 99% - это вина заказчиков, которые строят из себя ОЧЕНЬ занятых людей, и не могут найти пол часа что бы ознакомиться с ТЗ или подписать акт. И это я еще молчу про то, насколько они опаздывают с оплатой и сколько времени приходиться буквально силой выбивать у них контент...
+1, особенно милая их особенность - наполовину поменять ТЗ, когда над ним уже не первый месяц идёт работа...
Ну это-то как раз естественно. Если вы делаете что-то новое, то понять в чём проблема зачастую невозможно пока работа не аделана на 60-70%, а если вы делаете то, что уже 100 раз сделано - то зачем вы это делаете?
Другое дело что заказчик должен понимать что новое ТЗ => новые сроки и новые деньги.
Другое дело что заказчик должен понимать что новое ТЗ => новые сроки и новые деньги.
Если вы заранее предполгаете, что ТЗ поменяется, то как советовали выше, донесите до заказчика, что такие изменения будут стоить денег и увеличат сроки разработки. Также стоит использовать одну из гибких методик разработки и при анализе требований определять возможность их изменения.
может если вести проект по почасовой оплате, ситуация будет иной? Скажем, в договоре указывается кол-во часов по ТЗ * стоимость человекочаса. В первоначальную стоимость проекта заклаываются часы по ТЗ, все, что сверху - отдельные платежи. Отбивает желание переплачивать напрочь :)
Наймите грамотного МП и составьте нормальные договоры.
А договор составить такой, что работы начинаются только после внесения предоплаты? ТЗ идет приложением к договору. Вот и пожалуйста, срок идет только когда все урегулировано и оплачено. По поводу простоев заказчика во время работы, так же прописывается в договоре. Скажем если заказчику предоставляют макет дизайна, то в течении скажем 3 дней он обязан высказать все пожелания. Если в течении этих дней он ничего не ответил, это его вина и срок автоматически продлевается. Главное все это точно прописать в договоре.
Все тоже самое с изменениями в ТЗ во время работы. Есть изменения, которые можно внести после сдачи. И тогда договориться с заказчиком, что это будет сделано после сдачи и заключить отдельный договор. А если надо сразу исправить, опять вносится дополнение к договору и продлеваются сроки.
Все тоже самое с изменениями в ТЗ во время работы. Есть изменения, которые можно внести после сдачи. И тогда договориться с заказчиком, что это будет сделано после сдачи и заключить отдельный договор. А если надо сразу исправить, опять вносится дополнение к договору и продлеваются сроки.
Мне кажется, что правильнее будет сказать: 90% проэктов не вписываются в бюджет и в сроки...
Какие-то цифры у вас заниженные )))
Какие-то цифры у вас заниженные )))
Абсолютно с вами согласен - цифры либо занижены, либо взят какой-то очень узкий сегмент рынка с низкой турбулентностью.
статья продолжается следующим высказыванием одного Таннера:
"Используя комбинацию Ruby on Rails и Agile методы, проекты можно успешно и вовремя сдать, не превышая бюджет. Решение (проблемы) (или причина) лежит в ожидании больших успехов и достижения их путем применения повторяемых, гибких и упровляемых методов"
Надеюсь правильно перевел.
"Используя комбинацию Ruby on Rails и Agile методы, проекты можно успешно и вовремя сдать, не превышая бюджет. Решение (проблемы) (или причина) лежит в ожидании больших успехов и достижения их путем применения повторяемых, гибких и упровляемых методов"
Надеюсь правильно перевел.
Кстати очень полезны такие исследования в качестве аргументов перед разными заинтересованными сторонами: в разговорах о необходимости следовать указаниям project manager'a, а не считать разработку ПО таким же занятием как строительство сарая.
Ну, в принципе, статистика довольно интересная, если не считать, что об этом и так многие знают по личному опыту. Но мне было бы интересно узнать, что этим хотел сказать автор, и какие выводы он делает для себя из этой статистики?
По поводу влияния множества заинтересованных сторон - вообще это прямая обязанность руководителя проекта учитывать эти возможные воздействия. Под это подогнано достаточно много теории, да и практика наработана гигантская.
А для совсем маленьких проектов достаточно анализировать возможность влияния на проект и заинтересованность в удачном завершении проекта. Таким образом, можно выделить "лузер юзеров", у которых при удачном завершении проекта будут неприятности (их уволят в результате автоматизации или сократят полномочия и так далее) - у этой группы пользователей большие возможности влияния на проект и отрицательная заинтересованность в его удачно завершение. На другом конце стоят потенциальные "доноры" или "спонсоры", которые могут сильно повлиять на проект и кровно заинтересованны в его успешности - это надо обязательно использовать.
А для совсем маленьких проектов достаточно анализировать возможность влияния на проект и заинтересованность в удачном завершении проекта. Таким образом, можно выделить "лузер юзеров", у которых при удачном завершении проекта будут неприятности (их уволят в результате автоматизации или сократят полномочия и так далее) - у этой группы пользователей большие возможности влияния на проект и отрицательная заинтересованность в его удачно завершение. На другом конце стоят потенциальные "доноры" или "спонсоры", которые могут сильно повлиять на проект и кровно заинтересованны в его успешности - это надо обязательно использовать.
может, прежде чем что либо обсуждать, автор приведет подобную статистику и по другим видам человеческой деятельности?
Статистика любопытная, но вообще есть еще такая штука - "управление рисками". Как показывает практика, три четверти проблем со сроками решаются двумя способами - не полагаться на сроки, которые разработчики называют руководителю и не позволять заказчикам делать устные "добавления, примечания" и вводить новые функции. Подписание ТЗ и акта сдачи-приемки работ по каждому этапу работ сильно снижает риск не успеть в срок.
Знаете, бывают совсем интересные срывы сроков: приходишь к программисту (я как проджект), вместе пишете тз, вместе определяете время. Это время умножается на ТРИ и еще накидывается пару-тройку деньков сверху и называется клиенту. И что вы думаете: и эти дедлайны срываются.
А потом как-то никто не виноват, кроме проджекта: у программиста творческая работа (он код решил оптимизировать, фичу дописать, столкнулся с непредвиденными трудностями), клиент только к концу проекта начал понимать, что ему нужно.
И только менеджер, в конце концов, как старуха у разбитого корыта. И даже деньги не утешают, потому как проект не рентабельный. Дай бог, что б не в минус.
И, самое то забавное, что систему не придумать: каждый проект и команда, и клиент уникальны. Типовых ситуаций раз-два и обчелся.
А потом как-то никто не виноват, кроме проджекта: у программиста творческая работа (он код решил оптимизировать, фичу дописать, столкнулся с непредвиденными трудностями), клиент только к концу проекта начал понимать, что ему нужно.
И только менеджер, в конце концов, как старуха у разбитого корыта. И даже деньги не утешают, потому как проект не рентабельный. Дай бог, что б не в минус.
И, самое то забавное, что систему не придумать: каждый проект и команда, и клиент уникальны. Типовых ситуаций раз-два и обчелся.
возможно у вас просто нет еще связей с нужными людьми, найти программиста, которому творчество не мешает выполнять работу в срок сложно, но возможно
Какой-то слишком оптимистичный процент про сроки-то.
Значит сроки нужно умножать на пять, а не на три. :)
У проекта прежде всего должен быть один ответственный, который может не побояться и на тупого заказчика наехать, если надо, а не только сопли жевать. Короче, опытный ми влиятельный человек.
НЛО прилетело и опубликовало эту надпись здесь
Наша компания http://www.pmbox.ru занимается разработкой ПО для организации совместной работы, help desk и управления проекта и уже несколько лет, в общем мы «в теме» ). Поэтому есть что сказать:
Что надо чтобы проекты завершались в срок:
1. Проектом надо управлять. Это значить, что должно быть хотя бы минимальное образование в области управления проектами. Сейчас это выглядит так, есть «менеджер проекта», который даже определение, что такое «проект» сказать не может. Команда проекта часто вообще не в теме, что они работают в проекте, об образовании можно умолчать, его нет или компания не тратит деньги на обучение своих сотрудников. Конечно так не везде, но думаю, в области веб разработки в России это встречается часто.
2. Для управления проектами нужен инструмент. Соответственно специализированное ПО и методология его использования. Можно конечно все делать на бумаге (или в гугле докс), но это достаточно муторно и затратно по времени. Если вы управляете проектами, то вам нужен инструмент «лопата», который вы и будете «копать» свой проект.
3. Методология и регламенты. Допустим, вы работаете над веб-проектами. Большинство проектов будут стандартными или иметь общие черты. Обязанность менеджера проекта не только завершить проект вовремя, с определенным качество и в срок (при этом удовлетворить требования всех заинтересованных сторон) но и описать резюме проекта по закрытии. В котором отразить лучшие практики и проблемные места, чтобы в следующем проекте не ходить по тем же вилам. На основании успешного проекта можно создать шаблон и использовать его при следующем похожем проекте.
4. Работа с заказчиком. Большинство людей (да и заказчиков) очень хорошо понимают язык денег. Если вы подписали договор с заказчиком по уже утвержденному ТЗ, то сразу жестко обговаривайте стоимость изменений в проекте. Новое требование – отражение в ТЗ, работа над ТЗ стоит денег и соответственно приостановление проекта и перенос сроков. В этом случае, будет проблема с планированием ваших ресурсов, распределением их по проектам, за что и надо штрафовать заказчика. Оплата лучше всего, должна быть привязана к вехам проекта, сделали дизайн, согласовали, подписали акт, оплатили, ТЗ и так далее. Часто сделать правильное ТЗ очень затратно и не всегда оправданно, как вариант применение «прототипирования».
Понятно, что в работе над проектом одного инструмента, только для ведения проектов будет мало. Как правильно минимально нужны инструменты организации совместной работы, управления заявками/запросами клиента, средства обмена информацией участников проекта, система уведомлений по событиям в проекте. Задача менеджера проекта организовать эффективную работу команды с помощью различных инструментов, методологий и регламентов.
Если все будет организованно правильно то процент завершенных проектов у вас будет выше среднего по индустрии (соответственно и денег) )
Что надо чтобы проекты завершались в срок:
1. Проектом надо управлять. Это значить, что должно быть хотя бы минимальное образование в области управления проектами. Сейчас это выглядит так, есть «менеджер проекта», который даже определение, что такое «проект» сказать не может. Команда проекта часто вообще не в теме, что они работают в проекте, об образовании можно умолчать, его нет или компания не тратит деньги на обучение своих сотрудников. Конечно так не везде, но думаю, в области веб разработки в России это встречается часто.
2. Для управления проектами нужен инструмент. Соответственно специализированное ПО и методология его использования. Можно конечно все делать на бумаге (или в гугле докс), но это достаточно муторно и затратно по времени. Если вы управляете проектами, то вам нужен инструмент «лопата», который вы и будете «копать» свой проект.
3. Методология и регламенты. Допустим, вы работаете над веб-проектами. Большинство проектов будут стандартными или иметь общие черты. Обязанность менеджера проекта не только завершить проект вовремя, с определенным качество и в срок (при этом удовлетворить требования всех заинтересованных сторон) но и описать резюме проекта по закрытии. В котором отразить лучшие практики и проблемные места, чтобы в следующем проекте не ходить по тем же вилам. На основании успешного проекта можно создать шаблон и использовать его при следующем похожем проекте.
4. Работа с заказчиком. Большинство людей (да и заказчиков) очень хорошо понимают язык денег. Если вы подписали договор с заказчиком по уже утвержденному ТЗ, то сразу жестко обговаривайте стоимость изменений в проекте. Новое требование – отражение в ТЗ, работа над ТЗ стоит денег и соответственно приостановление проекта и перенос сроков. В этом случае, будет проблема с планированием ваших ресурсов, распределением их по проектам, за что и надо штрафовать заказчика. Оплата лучше всего, должна быть привязана к вехам проекта, сделали дизайн, согласовали, подписали акт, оплатили, ТЗ и так далее. Часто сделать правильное ТЗ очень затратно и не всегда оправданно, как вариант применение «прототипирования».
Понятно, что в работе над проектом одного инструмента, только для ведения проектов будет мало. Как правильно минимально нужны инструменты организации совместной работы, управления заявками/запросами клиента, средства обмена информацией участников проекта, система уведомлений по событиям в проекте. Задача менеджера проекта организовать эффективную работу команды с помощью различных инструментов, методологий и регламентов.
Если все будет организованно правильно то процент завершенных проектов у вас будет выше среднего по индустрии (соответственно и денег) )
Если работать "вовнутрь" - уже начинаешь задумываться, лучше это или хуже, чем на клиентов под крылом аутсорсинговой компании, потому что управляющие проектов внутри компании - гораздо более "творческие" люди, и очень тяжело выбить из них ТЗ и доказать, что если оно принято и согласовано - все крупные переделки и "небольшая смена концепции" будут только после 100% завершения, никто не хочет этого слушать, а соответственно, дедлайны отодвигаются на сроки, несоизмеримые с теми изменениями, которые насыпаются
И к чему интересно упоминается RubyOnRails?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
25% проектов не вписываются в бюджет, 31% — в сроки