Из ранее опубликованного мною на LinkedIn
Многие ПМы, имеющие опыт управления проектами в различных областях, наверное, заметили сложность софтверных проектов по сравнению с другими видами проектной деятельности, например с инфраструктурой.
Для себя я выделил несколько причин (в жизни их значительно больше):
• Заказчику сложно полностью сформулировать описание своих потребностей, а аналитики зачастую не обладают достаточным бизнес опытом и практикой что бы помочь Заказчику разобраться и самим все правильно описать. В результате рождаются документы с размытыми трактовками и неясными рамками.
• Размытые трактовки в проектной документации могут с легкостью расплываться по трудочасам, а это приводит к расползанию рамок проекта. Например, фраза «Создать отчет» может означать 2 часа работы или 200, что становится ясным только на этапе написания ТЗ или, что хуже, на этапе производства.
• Заказчики неадекватно оценивают сложность проекта. Зачастую сами себя зажимают бюджетом и не готовы к управлению запросами на изменения. Часто их не предупреждают, что это надо делать и буфер надо иметь. Они считают, что их RFP содержал исчерпывающую информацию о требованиях и на этапе Анализа они дали всю информацию. При этом Заказчики также уверены, что «небольшие» доработки будут сделаны за счет Исполнителя в сроки, ранее оговоренные контрактом. К сожалению, в таких проектах всегда возникают проблемы, которые приводят к конфликтам.
• Очень длительные согласования с Заказчиком (что связано со сложностью продукта) всегда приводят к срыву сроков. К сожалению, Заказчики очень редко адекватно отдают себе отчет в этом. Техническое задание, не согласованное вовремя ВСЕГДА приводят к срыву сроков.
Прошу поделиться Вашим опытом по данной теме.
P.S. Закончив этот материал, я понял, что существует всего одна причина – сложность реализуемого продукта. Сложность заключается в свободе реализации. Если на инфраструктурных проектах есть жесткие технологические рамки, то на софтверных проектах можно включить фантазию и реализовать «Все пожелания Заказчика», а это приводит к тому, что Заказчик теряется в своих желаниях и фантазиях.
Многие ПМы, имеющие опыт управления проектами в различных областях, наверное, заметили сложность софтверных проектов по сравнению с другими видами проектной деятельности, например с инфраструктурой.
Для себя я выделил несколько причин (в жизни их значительно больше):
• Заказчику сложно полностью сформулировать описание своих потребностей, а аналитики зачастую не обладают достаточным бизнес опытом и практикой что бы помочь Заказчику разобраться и самим все правильно описать. В результате рождаются документы с размытыми трактовками и неясными рамками.
• Размытые трактовки в проектной документации могут с легкостью расплываться по трудочасам, а это приводит к расползанию рамок проекта. Например, фраза «Создать отчет» может означать 2 часа работы или 200, что становится ясным только на этапе написания ТЗ или, что хуже, на этапе производства.
• Заказчики неадекватно оценивают сложность проекта. Зачастую сами себя зажимают бюджетом и не готовы к управлению запросами на изменения. Часто их не предупреждают, что это надо делать и буфер надо иметь. Они считают, что их RFP содержал исчерпывающую информацию о требованиях и на этапе Анализа они дали всю информацию. При этом Заказчики также уверены, что «небольшие» доработки будут сделаны за счет Исполнителя в сроки, ранее оговоренные контрактом. К сожалению, в таких проектах всегда возникают проблемы, которые приводят к конфликтам.
• Очень длительные согласования с Заказчиком (что связано со сложностью продукта) всегда приводят к срыву сроков. К сожалению, Заказчики очень редко адекватно отдают себе отчет в этом. Техническое задание, не согласованное вовремя ВСЕГДА приводят к срыву сроков.
Прошу поделиться Вашим опытом по данной теме.
P.S. Закончив этот материал, я понял, что существует всего одна причина – сложность реализуемого продукта. Сложность заключается в свободе реализации. Если на инфраструктурных проектах есть жесткие технологические рамки, то на софтверных проектах можно включить фантазию и реализовать «Все пожелания Заказчика», а это приводит к тому, что Заказчик теряется в своих желаниях и фантазиях.