Аутсорс разработки — недооценка масштабов проекта
Habr ·
Мы занимаемся заказной разработкой ПО уже 20 лет. И, конечно, в нашей работе и в обсуждениях с коллегами по рынку регулярно всплывают истории о том или ином проекте, который или вообще не стартовал, или испытывал проблемы, а то и вообще завершился неудачно. Эта статья - часть серии статей, в которых хочется поделиться с сообществом полученным опытом. Скоуп этой статьи - заказная разработка ПО при объёме проекта от 10 до 100 млн руб. в год. Я обсудил тему с коллегами и мы попробовали сформировать несколько тезисов, которые касаются именно фазы запуска проекта, и выявить те ошибки, которые уже на старте подкладывают под проект бомбу замедленного действия. Сегодня поговорим об одной из самых, наверное, неприятных проблем - качественной недооценке масштаба проекта заказчиком. Не уровня 20%, а в два-три раза. Я буду описывать тему с позиции "заказчик - исполнитель" в формате аутсорса, то есть - мы имеем два отдельных не аффилированных юрика и попытку законтрактовать проект по фикспрайсу. Практически всё это в не меньшей степени применимо и к инхаусу (отношения функциональный заказчик - отдел разработки) и к T&M проектам - в них всё равно есть общее бюджетирование и кратная недооценка объёма проекта всё равно ведёт к провалу. Начну с конца. Способ избежать проблемы есть, и он известен с середины прошлого века. Это жуткий и ужасный вотерфолл. Если действительно специфицировать задачи и действительно написать план проекта по RUP-у (то есть - не mind map на 20 пунктов, а реальный план пунктов на 400), то точность предсказания взлетает до... до какого числа? Мой опыт говорит, что детальное планирование поднимает точность оценки до +-30% ( хотя - кого мы обманываем? до +10...+40%, если честно ), и управляемость резко возрастает. Читать далее
Мы занимаемся заказной разработкой ПО уже 20 лет. И, конечно, в нашей работе и в обсуждениях с коллегами по рынку регулярно всплывают истории о том или ином проекте, который или вообще не стартовал, или испытывал проблемы, а то и вообще завершился неудачно. Эта статья - часть серии статей, в которых хочется поделиться с сообществом полученным опытом. Скоуп этой статьи - заказная разработка ПО при объёме проекта от 10 до 100 млн руб. в год. Я обсудил тему с коллегами и мы попробовали сформировать несколько тезисов, которые касаются именно фазы запуска проекта, и выявить те ошибки, которые уже на старте подкладывают под проект бомбу замедленного действия. Сегодня поговорим об одной из самых, наверное, неприятных проблем - качественной недооценке масштаба проекта заказчиком. Не уровня 20%, а в два-три раза. Я буду описывать тему с позиции "заказчик - исполнитель" в формате аутсорса, то есть - мы имеем два отдельных не аффилированных юрика и попытку законтрактовать проект по фикспрайсу. Практически всё это в не меньшей степени применимо и к инхаусу (отношения функциональный заказчик - отдел разработки) и к T&M проектам - в них всё равно есть общее бюджетирование и кратная недооценка объёма проекта всё равно ведёт к провалу. Начну с конца. Способ избежать проблемы есть, и он известен с середины прошлого века. Это жуткий и ужасный вотерфолл. Если действительно специфицировать задачи и действительно написать план проекта по RUP-у (то есть - не mind map на 20 пунктов, а реальный план пунктов на 400), то точность предсказания взлетает до... до какого числа? Мой опыт говорит, что детальное планирование поднимает точность оценки до +-30% ( хотя - кого мы обманываем? до +10...+40%, если честно ), и управляемость резко возрастает. Читать далее