Далеко не все владельцы бизнеса, менеджеры продуктов и менеджеры по продажам, связанные с разработкой ПО, пришли на свою позицию из программистов. Этот пост в основном для них. Но, возможно, он будет полезен и разработчикам ПО, которым постоянно приходится отвечать им на два стандартных вопроса:
Почему ты не можешь дать точную оценку трудоемкости разработки?
Почему ты не можешь завершить все работы в два раза быстрее?
В одной серьезной компании, в которой я участвовал в создании нового направления бизнеса, заказной разработки ПО, я даже провел небольшой семинар, чтобы ответить на эти вопросы сразу всем людям бизнеса.
Оценка это всегда вероятностная величина
Потому что оценка всегда делается в условиях неопределенности. Поэтому одно число это ни разу не оценка. Оценка это всегда, как минимум, два числа. От … и до…
Дальше ваш выбор, по какой цене разработку продавать.
Хотите войти к потенциальному стратегическому заказчику? Можно продаться по оптимистической оценке, получить гарантированные убытки и рассматривать эти убытки, как инвестиции в развитие бизнеса.
Хотите гарантированную прибыль – продавайте по пессимистичной оценке.
И еще оценки от Х/2 до 2Х на стадии обработки RFP – это очень хорошие оценки. Потому как, неопределенность.
Что такое неопределенность
Попробую объяснить на примере. Представте себя на месте разработчика, которому надо дать оценки. Оценки приходится давать всегда. Вопрос только в мере их неопределенности — ширине доверительного интервала.
Тест. Хороший ли ты оценщик?
Приведите оценки от… и до… для следующих величин:
Количество городов в СНГ, которые, имеют метро.
Температура плавления этилового спирта (°С).
Длина реки Днепр (км).
Максимальная продолжительность жизни Галапагосской черепахи (лет).
Касса первого викенда в СНГ фильма «Сталинград» (млн. руб).
Температура плавления этилового спирта (°С): -114,15.
Длина реки Днепр (км): 2200 км.
Максимальная продолжительность жизни Галапагосской черепахи (лет): 177.
Касса первого викенда в СНГ фильма «Сталинград» (млн. руб): 565.
А теперь посчитайте, сколько раз вам удалось накрыть реальное значение и сколько — уложиться в диапазон от Х/2 до 2Х.
Откуда берется неопределенность в разработке ПО
Еще один пример. Оцените трудоемкость разработки простенькой функции для ввода контактного телефонного номера нового клиента.
Скажу сразу ответ 20 мин – неправильный. Правильный ответ должен содержать две оценки.
Может ли вводиться несколько номеров?
Должна ли быть проверка номеров на действительность?
Простая или сложная проверка?
Если реализуем простую проверку, то не захочет ли клиент заменить ее на более сложную?
Должна ли проверка работать для иностранных номеров?
Можно ли воспользоваться готовым решением?
Каково должно быть качество реализации? Вероятность ошибки после поставки?
Сколько времени потребуется на реализацию и отладку? (зависит от конкретного исполнителя).
Последний вопрос особенно интересен. Потому что, когда мы делаем оценку трудоемкости, мы не знаем, кто из бойцов войдет в команду проекта. Вася, Петя или новый разработчик, который выйдет через две недели. А человеческий фактор – это самая значимая неопределенность в разработке ПО. Сошлюсь на отраслевой опыт — Barry Boehm, et al. «Software cost estimation with COCOMO II». Englewood Cliffs, NJ:Prentice-Hall, 2000.
Вот диаграмма влияния человеческого фактора, рассчитанная согласно этой методике.
Диаграмма представляет влияние факторов профессионализма проектной команды на трудозатраты по проекту. Поэтому, если у вас слабые аналитики, то это может увеличить трудоемкость проекта в полтора раза. А самая худшая оценка трудоемкости о всем факторам будет отличаться от наилучшей в 22 раза. Вот такая она отраслевая статистика.
И последнее. О сроках
Вот еще законы того же Бари Боэма, которые он вывел еще в середине 80-х.
Существует оптимальное, с точки зрения затрат, время выполнения графика для первой поставки: T = 2,5 (N ч.*м.)^1/3.
Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время.
Кривая стоимости резко растет, если запланированный график короче оптимального. Практически ни один проект невозможно завершить быстрее, чем за ¾ расчетного оптимального графика вне зависимости от количества занятых в нем!
Как-то так.
Успехов.
Автор: craft_brother
