Оценка программного проекта. Введение

26.11.13

Управление проектом

Создание точной оценки - дело простое и прямолинейное... когда вы понимаете, как ее создать. В этом цикле статей про оценку программных продуктов я перескажу своими словами замечательную книгу Макконнелла "Сколько стоит программный проект" через призму своего опыта и применимости к 1С в целом. Начнем с основ, терминологии и принципов.

Оценка, цель и обязательство

Оценкапрогноз относительно того, сколько времени или денег потребуется для реализации проекта/задачи. Но оценку постоянно путают с целью и обязательством.

Оценка - это как некоторая функция от задания, если на входе задание1, то на выходе оценка1, задание2 - оценка2. Больше никакие параметры не участвуют. Оценка не зависит от харизматичности консультанта или программиста, не зависит от сроков проекта и нетерпеливости РП/Клиента, не зависит и от мотивации и демотивации. Это всего лишь результат подсчета. 

Цель - это то, куда нам надо прийти (что сделать), чтоб получить профит, это сдача макета 20го числа, это получение рабочей сборки продукта в конце этого месяца, это ускорение отчета в 2 раза, это необходимость уложится в бюджет итп. Обычно цель слабо зависит от задания и вообще сперва появляется цель, а уже потом образуются задания. 

Обязательство - обещание предоставить требуемую функциональность на согласованном уровне качества к конкретной дате/за конкретное количество часов/конкретное количество денег. Обязательство может совпадать с оценкой, быть больше (добавляем риски, закладываем прибыль) или меньше (политика) и в общем случае оценка и обязательство не равны.

 

Если у нас происходит такой диалог:

- за сколько сделаешь этот отчет?

- дня за 4

- а чо как долго то? Клиенту он нужен после завтра

- ну я постараюсь успеть, но не могу обещать, что будет работать прям стабильно

Оценки в данном примере нет. Цель – послезавтра, а взятое исполнителем обязательство – сперва 4 дня, а потом - успеть к послезавтра.

Почему нет оценки? Оценка - это всегда вероятностное значение. Шансов, что отчет будет сделан ровно за 4 дня немного (с точки зрения математики вероятность сделать за 4 дня = 0%).

График оценки выглядит вот так:

 

И когда исполнитель принимает решение, какая вероятность его устраивает и по срезу говорит время – это превращение оценки в обязательство.

Что же делать, если оценка, цель и обязательства расходятся?

Если оценка меньше цели, то все нормально.

Если оценка больше цели, то стоит смотреть диапазон. Быть может мы успеем к цели с вероятностью 70%, что нас может устроить и это и берем за обязательство. Но может быть, что вероятность закончить к цели = 0%. Тут нужно менять задачу, не оценку, а именно задачу, потому что оценка это всего лишь производная от задачи. Нужно дать больше информации по задаче (чтобы уменьшить диапазон), найти альтернативы или готовые компоненты/решения. При невозможности изменить задачу придется менять цель – сдвигать срок, договариваться с клиентом или еще что-нить.

Повторюсь. Если оценка нас не устраивает то мы можем:

1)      Принять на себя риски и принять вероятность завершения пониже (меняем обязательство)

2)      Изменить входные условия, изменить задачу, найти готовое (меняем оценку через изменение задачи)

3)      Договориться с клиентом (изменить цель)

Но что не стоит делать, так это продавливать оценку. Все-таки чаще всего оценку дают программисты – интроверты с проблемами в коммуникациях, а спрашивают консультанты и РП – в рабочие обязанности которых входит проведение совещаний и продавливание своего решения. И получается, что более корректные оценки дают те, кто менее убедителен.

Про другие смертные грехи в оценке можно прочитать тут.

 

О точности оценки.

Что лучше недооценить задачу или переоценить?

Очевидно, что лучше получить точную оценку, но когда это сложно…

Аргументы против переоценки:

Закон Паркинсона – работа занимает все отведенное ей время

Студенческий синдром – если времени много, то можно попрокрастинировать слегка

Создание давления на разработчиков. При горящих сроках работают вроде б быстрее

Аргументы против недооценки:

Снижение эффективности планирования – возникают ошибки в планировании команды, сроков, контрольных точек, координации.

Сплошь оптимисты – по статистике разработчики оценивают объем работы на 20-30%, если еще и недооценивать это…

Плохая техническая база – начинаем торопиться на начальных этапах, плохо подготавливаясь к проекту, плохо собирая требования, плохо анализируя возможные решения, в итоге страдает архитектура и есть шансы потом все переделывать

Доп. действия при отставании – приходится тратить больше времени на пересогласования, на отчеты перед руководителями, переоценки, выбор требований, которые попадут в релиз, вместо того, чтоб сделать все, переделка…

 

Сравнивая аргументы достаточно очевидно, что лучше перебздеть, чем недобздеть. Особенно учитывая, что закон Паркинсона не доказан научно, и не несет доп. ущерба, студенческий синдром можно срезать с помощью буферов, а давить на разработчиков - плохо.

 

Далее: Откуда берутся ошибки в оценке

Управление проектом Оценка Прогноз Планирование

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2771    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14301    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5852    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

Предыдущие мои статьи на тему управления проектами носили концептуальный характер – ради чего мы делаем проекты, почему мы не получаем поддержку от коллектива пользователей, где найти помощь и мотивацию, как победить сложного заказчика. Теперь от концепций перейдем к технологии. Первая часть будет посвящена вопросам декомпозиции проектных задач на подзадачи для выявления узких мест нашего проекта.

10.02.2023    4699    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2747    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4186    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10667    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13092    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. poyson 27.11.13 12:47 Сейчас в теме
2. ander_ 27.11.13 13:04 Сейчас в теме
3. пользователь 03.01.14 11:43
Сообщение было скрыто модератором.
...
Оставьте свое сообщение