Подумайте о веб-и программных проектах, которые вы завершили. Сколько было доставлено вовремя и в рамках бюджета? Сколько оценок были точными? ИТ-проекты печально известны чрезмерным использованием, и вот несколько причин, почему это происходит …
1. Проект плохо определен
Как вы можете оценить время проекта, если вы не знаете, что это за проект? Редко можно найти клиента, который точно понимает, как должна работать их система.
Почти каждый крупный проект, который я предпринял, требовал «гибкости». Другими словами, клиент хочет, чтобы система обрабатывала все, что он хочет, в любой момент в будущем, даже если он не знает, какими могут быть эти функции. Гибкость не является обязательным требованием!
2. Время разработки оценивается непрограммистами
Если вы не программист, не думайте о времени разработки. Проект обречен в тот момент, когда менеджер пишет собственную вымышленную оценку. В лучшем случае они будут совершенно неверными. В худшем случае программисты будут испытывать желание доказать, что они не правы.
3. Оценки разработчика слишком оптимистичны
Разработчики думают с точки зрения кодирования часов. Время проходит быстро, когда вы находитесь в зоне, и вам сложно оценить собственную скорость. Оценивать скорость других разработчиков невозможно.
Многие разработчики слишком оптимистичны. Как правило, они забывают о более мягкой стороне процесса разработки, такой как управление проектами, сопоставление требований, обсуждения с коллегами, отсутствие, проблемы с ПК и т. Д.
4. Проект не рассмотрен должным образом
Будьте осторожны, если оценка развития отдельного объекта превышает неделю. Этот фрагмент следует подразделить дальше, чтобы разработчик мог более подробно проанализировать сложную проблему.
5. Расчетное время используется
Дайте программисту 5 дней на выполнение задания, и это займет 5 дней. Разработка программного обеспечения бесконечно изменчива, и любой код может быть улучшен. Если разработчику потребуется 3 дня, чтобы выполнить задачу, он потратит оставшееся время на ее настройку или выполнение других действий.
К сожалению, это приводит к тому, что оценки становятся минимальным количеством дней разработки. Фактическое время доставки может только ухудшиться.
6. Больше разработчиков! = Более быстрая разработка
100-дневный проект не будет завершен в течение 1 дня 100 разработчиками. Большее количество людей приводит к экспоненциальному увеличению сложности. Узнайте, почему более крупные команды не приводят к более быстрому развитию …
7. Изменения в объеме проекта
Это, пожалуй, самая раздражающая проблема для разработчика. Функция изменена или добавлена, потому что клиент X запросил ее, или генеральный директор считает, что это круто.
Задокументировано ли влияние этой новой функции?…
8. Оценки являются фиксированными
Оценки должны постоянно оцениваться и обновляться по мере развития системы. Программисты часто верят, что они могут наверстать упущенное — это случается редко.
9. Время тестирования забыто
Разработчик не может адекватно протестировать свой собственный код. Они знают, как это должно работать, поэтому они сознательно или подсознательно проверяют определенным образом. В целом можно ожидать, что вы потратите еще 50% времени на тестирование и отладку.
10. Оценки принимаются слишком буквально
Непрограммисты редко ценят сложность разработки программного обеспечения, но лишь немногие компании планируют отставание в расписании. Проект часто находится у подножия огромной нестабильной башни других видов деятельности, таких как печатание литературы, маркетинг, распространение и т. Д.
Задержки развития могут вызвать дорогостоящую цепную реакцию задержек. К сожалению, становится легко обвинить программиста в нижней части кучи. Это не сулит ничего хорошего для будущих проектов — программист либо откажется давать оценки, либо сильно их раздувает.
Сталкивались ли вы с другими причинами, почему смета проекта не удалась?