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

26.11.13

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

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

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

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

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

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

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

 

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

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

- дня за 4

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3475    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4745    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3722    0    user1853337    8    

29

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

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

01.04.2024    3009    0    MariaTemchina    6    

22

Кейсы проектов Руководитель проекта Бесплатно (free)

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

20.12.2023    4096    0    1СERP    21    

31

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

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

05.07.2023    15483    0    ASchekachev    37    

55

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

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

28.06.2023    6421    0    stnslv    5    

25

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

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

10.02.2023    5624    0    andironenko    3    

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