4 причины, почему проекты никогда не завершаются в срок

03.03.20

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

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

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

В то же время, каждая компания, работающая с ИТ-проектами постоянно предпринимает серьезные попытки снизить уровень неопределённости и повысить тем самым точность оценок длительности заданий. И все же, если бы мы спросили руководителей проектов 40 лет назад, что бы они сказали о своих проблемах? Были бы их жалобы другими? Думаю, нет. Даже если проекты отличаются друг от друга, жалобы практически не меняются.

Это отражает очевидный факт – проектная среда имеет две доминирующие характеристики:

  • Высокая степень неопределенности, гарантирующая сюрпризы в ходе проекта.
  • Обремененность тремя обязательствами: сроки, бюджеты, содержание. И чем выше неопределенность, тем ниже вероятность одновременного выполнения всех трех обязательств.

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

Резервы времени

Вопрос: Достаточно лишь одних резервов времени, так называемой подстраховки, заложенной в оценке длительности каждого задания, для того, чтобы поглотить все отклонения от графика проекта?

Взгляните на рассуждение:

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

Однако….

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

А как вы даете оценку?

Давайте проверим себя: а как вы даете оценку?

Представьте, вас попросили оценить, сколько времени уйдет на выполнение определенного задания.

Учтите следующее:

  • Вы делали нечто подобное 1 или 2 раза, то есть статистики мало и придется давать оценку скорее интуитивно, чем объективно.
  • Вы знаете, что ваша оценка будет переведена в разряд обязательства, то есть возможны взыскания.
  • Вас попросили дать только одно число. И ни каких плюс/минус километр!


Какую оценку вы дадите? Варианты:

  • Гарантирующую 50% вероятности выполнения в срок.
  • Гарантирующую 80% вероятности в срок.
  • Гарантирующую боле 80% вероятности завершения работ вовремя.

Дайте угадаю… большинство из вас дали оценку, гарантирующую 80% или 80%+ вероятность завершения в срок. Верно?

Почему мы даем такие оценки? Все просто:

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

Но сколько же подстраховки заложено в наших оценках? Очевидно, что любая оценка с более чем с 50%-ной вероятностью завершения в срок содержит какую-то подстраховку. Обычно, более или менее качественной оценку можно считать, если она обеспечивает не менее 80 процентов вероятность завершения задания в срок.

Судя по графику + 30% к вероятности добавляет относительно немного подстраховки времени. Это рассуждение верно для нормального распределения вероятностей. Однако, в реальности из-за высокой неопределенности вероятность завершения в срок НЕ симметрична – она имеет длинный хвост.

Незначительное увеличение ВЕРОЯТНОСТИ приводит к ЗНАЧИТЕЛЬНОМУ увеличению ВРЕМЕНИ. Чем выше степень неопределенности, тем длиннее хвост! В конце концов, ни что не может быть сделано со 100% вероятностью! Так ведь? Наша практика показывает, что для большинства ИТ-проектов по меньшей мере половина времени в предварительных оценках – это подстраховка.

Позвольте тогда задать один вопрос… Если все дают оценку с высокой вероятностью завершения в срок, закладывают туда изрядное количество подстраховки, как же так получается, что большинство заданий в проектах не завершаются НАМНОГО раньше срока? Что происходит со всей этой подстраховкой, которую мы так щедро закладываем в оценки?

Давайте разбираться…

Причины потери подстраховки

Причина №1. Закон Паркинсона.

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

Первый Закон Паркинсона гласит: «Работа заполняет все время, отпущенное на неё».

Следствие: Перевод оценки в разряд обязательства приводит к реализации именно данной оценки (но никак не меньшей!)

Причина №2. Студенческий синдром

Нам хорошо известна модель поведения исполнителя, когда всё делается в последний момент. Так называемый «Студенческий синдром». Мы тянем время до последнего, каждый раз находя все более важные или более интересные дела. Да и к чему спешить, ведь до срока еще столько времени! В результате все резервы беспечно теряются.

Причина №3. Опоздания передаются, выигрыш — нет

На рисунке схема проекта зависимых заданий:

  • По плану на проект должно уйти 17 дней
  • Первое задание закончилось на 5 дней раньше.
  • Четвертое задание закончилось на 5 дней позже.

Сколько времени уйдет на выполнение проекта? Хотелось бы, как и планировали - 17, но для указанного типа проектов правильный ответ - 22 (12+5+5=22).

Вывод: Опоздания передаются следующему заданию, выигрыш – нет.

Моделирование условного проекта

Давайте посмотрим на математической модели, как названные три причины влияют на выполнение обязательств по срокам проекта.

Исходные условия:

  • Проект содержит 7 в разной степени зависимых друг от друга этапов.
  • В проекте заняты 10 различных спецов и каждый может выполнять задания только своего типа.
  • Каждое задание длится 20 дней и вероятность выполнения его в срок 80%.
  • В каждом задании 10 дней подстраховки.
  • Плановое время выполнения проекта 140 дней.


Какова вероятность, что проект будет завершен через 140 дней? Запустим симулятор проекта используя генератор случайных чисел и выполним 1000 прогонов.

Несмотря на то, что каждое задание содержит в себе большую подстраховку и высокую вероятность завершения в срок, результаты таковы:

  • Вероятность успеть в срок – чуть более 10%

Почему так? Может быть, мы недостаточно заложили подстраховки? Решит ли проблему увеличение подстраховки в каждом задании?

Давайте порассуждаем:

  • Мы считаем, что всему виной отдельные задания, которые не завершились в срок.
  • В следующем проекте в аналогичные задания, которые «обвиняются» сейчас, будет заложено больше подстраховки.
  • При планировании проекта его время исполнения будет еще больше увеличено.
  • Мы продолжаем работать по-старому. Т.е. все те же явления - Студенческий синдром, Закон Паркинсона, Опоздания в цепи и потеря выигрыша- продолжают расходовать нашу подстраховку.
  • Проект все равно не завершается в срок.
  • Мы снова ищем виновные задания и снова добавляем резервы по времени.

Получаем замкнутый круг! В конце концов рынок ставит предел увеличению времени наших проектов... 

Причина №4. Перескакивание между заданиями

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

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

В итоге получается, что Менеджер по ресурсам пытается всем угодить, а РП сражаются за то, чтобы ресурсы были назначены именно на их проекты. Приоритеты устанавливаются в соответствии с громкостью крика РП. Работа ресурсов постоянно прерывается, специалисты перепрыгивают от проекта к проекту.

Реальный ущерб от перескакивания не в потере времени, уходящего на переключение от задания к заданию, а в сдвиге даты завершения каждого задания! Перепрыгивание ресурсов не помогает НИ ОДНОМУ проекту завершиться раньше назначенного срока. А это в свою очередь, как мы уже знаем, ведет к тому, что люди закладывают еще большие подстраховки, когда их просят дать свои оценки длительности заданий.

Моделирование мульти-проектной среды


Давайте построим модель, в которой рассмотрим среду, где одни и те же ресурсы работают в трех одинаковых проектах одновременно. Исходные данные такие же, как и с одним проектом. Симулятор попытается запустить все проекты одновременно, производя выравнивание по загрузке ресурсов в процессе работы над заданиями таким образом, что:

  • Работа ресурса не прерывается чаще, чем один раз в неделю.
  • Отсутствуют затраты времени на переключения от задания к заданию.

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

В мульти-проектной среде в принципе очень трудно дать надежные оценки. И не забывайте, что мы часто даем обязательства по одному проекту ДО того, как принимаем следующий проект, и мы не можем изменить уже данные ранее обязательства! Но если не 140 дней, то за сколько?

Результат на рисунке:

Симулятор провел оптимизацию и рассчитал, что реально успеть все три проекта завершить за 420-430 дней.  Будем считать это отправной точкой.

Выводы

Сделаем несколько выводов из изложенного, а в следующей статье посмотрим, как мы сможем улучшить эти показатели.

И так, есть, как минимум, 4 основных причины из-за которых мы теряем резервы времени в проектах:

  • Закон Паркинсона.
  • Студенческий синдром.
  • Потеря выигрыша и передача опозданий в цепи зависимых заданий.
  • Перепрыгивание от задания к заданию в мульти-проектных средах.

Вывод: Основной причиной срыва сроков является наша организация работы, а не вселенская неопределенность. Нам нужно решение, которое бы изменило нашу работу. При этом анализ ключевой проблемы указывает на ряд требований, которым должно удовлетворять наше решение.

Решение должно обеспечить, чтобы:

  • Оценка длительности заданий не переводилась в разряд ОБЯЗАТЕЛЬСТВ - это должно значительно сократить количество подстраховки.
  • Выигрыш по времени и опоздания компенсировали друг друга.
  • Перепрыгивания от задания к заданию резко сократились.

И так, что собой представляет решение?

Читайте об этом в моей следующей статье: "Как завершать проекты в срок".

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Krasnodar.

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


Управление проектами менеджмент проектные технологии точность оценок сроки проекта бюджеты содержания

См. также

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

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

02.05.2024    3009    0    biimmap    39    

38

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

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

26.04.2024    4127    0    mrXoxot    5    

29

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

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

23.04.2024    3452    0    user1853337    8    

29

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

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

20.12.2023    3334    0    1СERP    21    

31

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

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

05.07.2023    15085    0    ASchekachev    37    

55

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

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

28.06.2023    6183    0    stnslv    5    

25

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

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

10.02.2023    5244    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5807    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. CheBurator 3126 04.03.20 03:01 Сейчас в теме
а что за "симулятор" используется?
2. CheBurator 3126 04.03.20 03:02 Сейчас в теме
след.статью, плиз, опубликуйте ссылку в конце этой статьи
3. VLikhobabin 98 04.03.20 07:21 Сейчас в теме
1. Программный сималятор расчета вероятностей на основе генератора случайных чисел. Самописный.
2. Следующая статья в работе. Когда закончу - пролинкую в этой статье обязательно!
TheDoriancox; Алексей_mir2mb; mei2015; +3 Ответить
40. AlX0id 12.03.20 08:12 Сейчас в теме
(3)
(1)
мне кажется, bizagi process modeler в состоянии подобное смоделировать, если правильно понимаю о чем речь
4. SirAlexIT 04.03.20 07:24 Сейчас в теме
Хорошая презентация на тему "старых песен о главном". Ставлю плюс за труды и оформление :)
VLikhobabin; +1 Ответить
5. VLikhobabin 98 04.03.20 07:25 Сейчас в теме
6. RustIG 1720 04.03.20 07:31 Сейчас в теме
(0) сроки (планы) не выдерживают не только программисты, а все профессии...
у всех есть ограничения...
задача в таком случае сводится не к тому , чтобы выдержать "сроки, бюджет, качество", а минимизировать потери из-за срыва сроков, максимизировать конечный результат для всех участников процесса...
7. VLikhobabin 98 04.03.20 07:37 Сейчас в теме
(6)все верно! Об этом я собираюсь рассказать в следуюшей статье!
8. RustIG 1720 04.03.20 07:55 Сейчас в теме
(7) Хотите жесткой критики?!. только без обид

статью не оценил :(
подписку на вас еще оставил.... есть надежда...
долго запрягаете, раскачиваете публику... вот эти ваши изыскания про паркинсона и другое оказываются бесполезными, когда вы один на один перед Заказчиком выбиваете оплату, а сроки уже "тю-тю", и качество "не то"...
и всякие правила студента забываются быстрее, чем .... ну в общем, вы поняли :)
9. VLikhobabin 98 04.03.20 08:05 Сейчас в теме
(8)критика - неизбежная часть публичности! Так что все нормально))
По существу - Вы правы, никакая технология не поможет, если проект встал из-за разногласий с заказчиком при сдаче работ. Сами 100 раз попадали в такую ситуацию. Впрочем, на эту тему планирую статью из серии жестких переговоров. Спасибо, что оставили подписку!
Serg_Tangatarov; mei2015; RustIG; +3 Ответить
10. Kutuzov 744 04.03.20 09:00 Сейчас в теме
Голдратта начитались?)
VLikhobabin; +1 Ответить
12. VLikhobabin 98 04.03.20 09:37 Сейчас в теме
17. MuxaH 04.03.20 10:23 Сейчас в теме
(12) Точно, у меня прям де жа вю :)
11. user797130 04.03.20 09:35 Сейчас в теме
Я уже много лет на вопрос о сроках отвечаю "не менее n".
13. VLikhobabin 98 04.03.20 09:40 Сейчас в теме
(11) Я тоже бы так хотел... к сожалению если компания не монополист в данной области, то рынок быстро возвращает на землю - всегда находится тот, кто сделает за "n-1" и за те же деньги...
14. acanta 04.03.20 09:47 Сейчас в теме
(13) 1с - монополист или нет?
15. VLikhobabin 98 04.03.20 09:57 Сейчас в теме
(14) 1С - разработчик бизнес-приложений, продающий свои коробки чз сеть партнеров. А команд, выполняющие проекты вндрения 1С (и не только 1С) - великое множество. Они дают обязательства по выполнению проектов в срок и за фиксированный деньги. И очень часто команды сталкиваются с проблемой невыполнения этих обязательств. Про это и статья )
16. acanta 04.03.20 10:03 Сейчас в теме
(15) ...а не про антимонопольное закондательство в условиях высокой конкуренции субподрядчиков....
18. user797130 04.03.20 10:54 Сейчас в теме
(13) Я - программист. Я отдаю себе отчёт в том, что ВСЕГДА есть тот, кто сделает быстрее меня. Оставим вопрос о качестве, пусть будет "быстрее и лучше меня". Но за те же деньги это будет только в том случае, если человеку это зачем-то нужно, а если нет, то он сделает дороже, чем я. Как правило ОЧЕНЬ дороже.
Но допустим, что кто-то сделает и быстрее и лучше и за те же деньги.
Ну что же.
Поздравим его с выполнением одной задачи и будем дальше тянуть лямку своих восьми сотен...
А если он все мои задачи на себя будет тянуть... Оставим этого дурачка на месте и найдём компанию, где программистам платят достойную зарплату. На все компании дурачков не наберётся.

П.С. Поясню сразу. "Дурачком" я называю гипотетического программиста, который с квалификацией лучше моей готов работать за мЕньшие деньги. Если пересчитывать: то больше задач за мЕньшие сроки - это и есть меньше денег.
Я свой прайс не задираю.
user910421; Jestery; +2 Ответить
19. VLikhobabin 98 04.03.20 11:15 Сейчас в теме
(18) Фишка не в том, кто за сколько делает одно и ту же задачу - всегда есть те кто выше рынка или ниже по тем или иным причинам. В итоге для каждой задачи в данный момент времени будет некая средняя рыночная ценность, но у каждого поставщика своя уникальная себестоимость.
Вопрос в том, как выполнять свои обязательства по срокам и содержанию. Т.е. не важно - дорого вы берете или дешево, быстро вы делаете или не очень - важно выполнять взятые обязательства. Подход "перезакладываться" работает весьма ограничено - рынок ставит предел стоимости и сроков. Подход - "мы самые технологичные, боты пишут за нас код" и т.п. - тоже имеет свой предел и доступен далеко не всегда. О том как же укладываться в срок и пойдет речь во-второй статье )
26. user797130 04.03.20 11:43 Сейчас в теме
(19) Вы уводите разговор в сторону.
Я говорю, что мой ответ - назвать МИНИМАЛЬНЫЙ срок, который ТОЧНО будет потрачен. Всё, что больше - опционально и озвучивается при более полном изучении проблемы.
Именно такой подход и позволяет мне выполнять свои обязательства, избегая "ловушек", упомянутых в посте.
VladimirMelnychenko; shaman77; VLikhobabin; +3 Ответить
28. VLikhobabin 98 04.03.20 11:46 Сейчас в теме
(26) Плюсую. Это ответ эксперта, который дорожит своей репутацией.
30. user797130 04.03.20 12:49 Сейчас в теме
21. acanta 04.03.20 11:20 Сейчас в теме
(18) По причине глобального потепления технической революции и структурных изменений в экономике программист "дурачок" ВСЕГДА.
27. user797130 04.03.20 11:44 Сейчас в теме
(21) Те, которые "всегда" - не конкуренты.
37. Petr54-ru 92 06.03.20 06:51 Сейчас в теме
(18)
П.С. Поясню сразу. "Дурачком" я называю гипотетического программиста, который с квалификацией лучше моей готов работать за мЕньшие деньги. Если пересчитывать: то больше задач за мЕньшие сроки - это и есть меньше денег.
Я свой прайс не задираю.


Посмеялся про "дурачка".

А у меня например есть в заначке ряд своих наработок, которые я смогу использовать в задачах, или могу для задачи скачать на Инфостарте заготовку и ее допилить.

То, что в "большом" мире разработки ПО, называют "reuse".

И если бы я задачу пилил с нуля, то у меня бы ушло условных 12 часов. А так у меня уйдет 4 условных часа, из которых я час потрачу на коммуникацию с заказчиком. Заказчику я выставлю 6 часов, с объяснением что если это с нуля пилить, то выйдет 12 часов, но у меня есть заготовка, которая нам в этом проекте сэкономит половину.

Вообще, у меня идея, что бизнес вынужден доверять своим 1С программистам, как проктологу. И заказчик должен работать с тем программистом, которому доверяет. И в свете этого нужно обеспечивать лояльность заказчика не ценовыми методами.
38. user797130 06.03.20 09:06 Сейчас в теме
(37) Использую такой же подход, считаю его профессиональным. Я говорил про разработку с нуля.
Ведь не может же быть человека, у которого есть заготовки под все 800 задач. =D
Кроме того, у меня же тоже есть заготовки. И "цену" я называю с учётом этого.
20. Yashazz 4762 04.03.20 11:18 Сейчас в теме
Дело просто в квалификации и дисциплине. Известные мне провалы сроков базировались на: совершенно безграмотных "аналитиках" и "консультантах", которые выдавали неточные или вообще неверные данные, ТЗ, советы и указания; узко мыслящих программистах, которые делали чуть ли не хардкод, и всё "по месту", а потом переделывали механику и правили в 20 местах; на слабовольных РП, не умевших защищать работу перед тупыми и нахрапистыми клиентами. Ну и дисциплина - когда люди гоняют в настольный хоккей, пьют пиво, режутся в игрушки, часами треплются о ерунде, а надо работать - это никакие теории не спасут. Только железными палками.
BairamovTM; AlX0id; Vladimir Litvinenko; VLikhobabin; +4 Ответить
23. VLikhobabin 98 04.03.20 11:34 Сейчас в теме
(20) Это по определению должно быть. Профессиональные и личные качества участников команды проекта вопрос HR и РП, который эту команду набирал. Но как быть, если и люди вроде бы толковые и заказчик адекватный, а в согласованные сроки не уложились? Люди же не машины, а процесс внедрения не конвейер (который, кстати у дедушки Форда тоже останавливался). Все ли дело в высокой степени неопределенности на старте проекта?
ps за "железные палки" плюс, но не забывайте и про пряники )))
22. Vladimir Litvinenko 2888 04.03.20 11:32 Сейчас в теме
Одна из самых частых причин - смена требований в процессе выполнения задачи. Даже если задача небольшая из-за смены требований в ходе выполнения она разрастётся до размеров проекта.

В свою очередь причиной этого является плохая проработка задачи, когда оценку хотят получить "вот прям щас" потому что "ну ты же профессионал", а проработку задачи сделать "когда-нибудь потом". То есть никогда. Потому что на постановщика, уже страдающего дефицитом внимания от такого подхода, тоже навалится ещё больше задач на (не)проработку.

Это выливается в две вещи - срыв сроков и абсолютную непротестированность задачи. Не говоря уже про автоматизацию тестирования при отсутствии четких требований и тест-кейсов.

Для решения этих проблем есть метод груминга бэклога, составления сценариев приёмки (UAT) и тест-кейсов. Но так как 1С-разработке (ещё и для веб-разработки характерно) скрамом и ажайлом называют стендапы и отчетность перед красно-оранжевым начальством (бери больше-кидай дальше), то продолжаем искать чёрную кошку в тёмной комнате, строя диаграммы Ганта в розовых очках )
Olenevod; EugeneSemyonov; BairamovTM; check2; kuzyara; VladimirMelnychenko; dsdred; acanta; Yashazz; VLikhobabin; +10 Ответить
24. VLikhobabin 98 04.03.20 11:36 Сейчас в теме
(22) Узнаю опытного проектника ))))
25. Vladimir Litvinenko 2888 04.03.20 11:41 Сейчас в теме
(24) Я вообще программист разработчик, до недавнего времени работавший только на инхаус задачах )) Но проблемы везде одинаковые, так как природа у человека от компании к компании мало отличается, да и культурного разнообразия особо нет ))

Обычно решая задачу фактически решается задача "сдать", а не сделать. Причём "сдать" свою часть работы, а не готовый продукт (или его рабочую часть). За 11 лет работы в 1С встречал только два случая, когда подход пытались изменить. Это были скрам-мастера (не проджект менеджеры - это прям подчеркнуть хочется), и в обоих случаях они покидали команду 1С. Во первых культура не приживается, во вторых продукты на других технологиях манили.

Для решения этой проблемы человек должен быть не только администратором, но и интегратором (в терминах Адизеса). Что-то редко такое встречается, по большей части либо держатся на 1С-ных проектах загнанные администраторы, либо "предприниматели на допинге" с лозунгом "давай навались, бери больше - кидай дальше".
kalyaka; acanta; +2 Ответить
39. Petr54-ru 92 06.03.20 09:57 Сейчас в теме
(22) В русской традиции это называется "каша из топора". Таких заказчиков хватает. Можно и с такими работать, почему нет. Подход простой - раз нет согласованного описания проекта, то проектом управляю не я, а постановщик задачи. А я как таксист, работаю по счетчику. Месяц работы - такая то сумма и только грустно от того, что приходится 5-6 раз одно и то же переписывать. Так то не сложно, но морально это очень тяжело.
41. check2 370 25.03.20 22:48 Сейчас в теме
(22) Не удержался :)
Прикрепленные файлы:
EugeneSemyonov; mei2015; VLikhobabin; +3 Ответить
43. VLikhobabin 98 26.03.20 07:56 Сейчас в теме
29. herfis 508 04.03.20 11:59 Сейчас в теме
Две основные причины срыва сроков сдачи проекта:
- то одно
- то другое
dooD1iez; EugeneSemyonov; user797130; RustIG; e9953; AlexCherdakov; VLikhobabin; acanta; +8 Ответить
32. VLikhobabin 98 04.03.20 13:54 Сейчас в теме
36. e9953 05.03.20 22:11 Сейчас в теме
31. dsdred 3472 04.03.20 13:44 Сейчас в теме
Книга:"Критическая цепь" - Автор:Элияху Голдратт
VLikhobabin; +1 Ответить
33. VLikhobabin 98 04.03.20 13:55 Сейчас в теме
(31) Тс-с-с-с, не раскрывайте интригу, коллега ;)
34. dsdred 3472 04.03.20 13:59 Сейчас в теме
(33)Поздно))
А вообще книга хорошая.
Правда лучше перед ней Цель1 и Цель2 еще прочитать.
35. VLikhobabin 98 04.03.20 14:08 Сейчас в теме
(34) Предлагаю вернуться обязательно к Голдратту в обсуждении 2-й статьи. Я планирую ссылаться на него.
42. check2 370 25.03.20 22:50 Сейчас в теме
Всё правильно написано!!!
44. VLikhobabin 98 26.03.20 07:56 Сейчас в теме
45. biimmap 1986 02.07.23 12:15 Сейчас в теме
Статья хороша! Но почему нет ещё двух причин, которые допустим на многих моих проектах возникают:
1. Кривые данные
2. Волатильность заказчика.

Все ведь ждут розовую кнопку ЗБС и делать ничего не хотят - заняты видите ли
Оставьте свое сообщение