Comments 9
Жаль, что у пунктов не расставлены веса, что влияет в наибольшей степени. Я наверное к тому, что желание низкой цены — самая распространенная причина урезания сроков.
Проблема не столько в срывах сроков разработчиками, сколько в рисках, в том числе тех, на которые бесправный в большинстве случаев исполнитель повлиять не может.
Выглядит это например так: «за сколько сделаете в простейшем виде?». Ответ обычно «за X дней, без этого, этого и этого». После чего все соглашаются, что это, это и это не нужно, и проект идёт в реализацию. Через X дней всё готово, из того что обсуждали. Однако выясняется, что то, что исключили, было очень нужно, потому что заказчик еще прикупил систему B, которая без тех фич, что выбросили — не нужна. На испытаниях у заказчика финального продукта акт не подписывается, так как «система нефункциональна». В лучшем случае всё выливается в доп. соглашение, но формально срок сорван. Какой-нибудь топ-топ-топ у заказчика ставит себе галочку — подрядчик подвел. А свои менеджеры сто отговорок найдут.
Всякое конечно бывает, но нельзя напрямую (без рассмотрения рисков) связывать просрочку проектов только с ошибками в оценке.
Проблема не столько в срывах сроков разработчиками, сколько в рисках, в том числе тех, на которые бесправный в большинстве случаев исполнитель повлиять не может.
Выглядит это например так: «за сколько сделаете в простейшем виде?». Ответ обычно «за X дней, без этого, этого и этого». После чего все соглашаются, что это, это и это не нужно, и проект идёт в реализацию. Через X дней всё готово, из того что обсуждали. Однако выясняется, что то, что исключили, было очень нужно, потому что заказчик еще прикупил систему B, которая без тех фич, что выбросили — не нужна. На испытаниях у заказчика финального продукта акт не подписывается, так как «система нефункциональна». В лучшем случае всё выливается в доп. соглашение, но формально срок сорван. Какой-нибудь топ-топ-топ у заказчика ставит себе галочку — подрядчик подвел. А свои менеджеры сто отговорок найдут.
Всякое конечно бывает, но нельзя напрямую (без рассмотрения рисков) связывать просрочку проектов только с ошибками в оценке.
Ответ обычно «за X дней, без этого, этого и этого». После чего все соглашаются, что это, это и это не нужно, и проект идёт в реализацию.— «это, то что нужно» где-либо зафиксировано? если да, то ИМХО затем тот факт что
заказчик еще прикупил систему B, которая без тех фич, что выбросили — не нужнавообще не должен волновать исполнителя. А в целом, это больше чисто российская, мне кажется, специфика, нет еще увы должного уважения к документу, договору, в котором по идее должны быть обозначены все эти возможности.
Это всего лишь один из возможных «например», иллюстрирующий мысль о том, что срок или просрочка всего проекта не всегда связаны только с оценками или ошибками в оценках. В иллюстрации конечно много из «российской специфики», но я вам скажу и восточные партнеры (был у меня один сингапурец) — большие любители порезать ценник.
Конечно, наибольшая часть ИТ-проекта — это трудозатраты и сроки, связанные с ними. Но если например заказчик фидбэк выдает с задержкой в месяц на еженедельные билды (вот это уже англоязычные товарищи есть одни), то это риск, и срыв сроков здесь не вина исполнителя. А проект выезжает из договорной даты. И деньги за этапы соответственно.
Конечно, наибольшая часть ИТ-проекта — это трудозатраты и сроки, связанные с ними. Но если например заказчик фидбэк выдает с задержкой в месяц на еженедельные билды (вот это уже англоязычные товарищи есть одни), то это риск, и срыв сроков здесь не вина исполнителя. А проект выезжает из договорной даты. И деньги за этапы соответственно.
Мне кажется существенная проблема планирования это то что перепутаны такие вещи как прогноз и обещание.
Никто не может угадать абсолютно точно когда закончится проект, зависящий от миллиона факторов. Я считаю погрешность 30% это потрясающе точный прогноз для больших проектов.
Я думаю что давать обещание на дату завершения проекта, который зависит от миллиона факторов, глупо. Расчитывать на такое обещание тоже глупо. А вот спрогнозировать вполне можно. Некоторые даже умеют делать это очень точно — в пределах 100% погрешности.
Прогнозы можно использовать для выбора между разными альтернативами и попытаться прикинуть, какой вариант скорее всего окажется выгоднее, его и использовать. Для этого и нужны прогнозы — они подсказывают направление движения.
Ошибка прогнозов это не проблема, это нормальная ситуация, которую невозможно избежать.
Можно только улучшать точность с помощью исторических данных и чеклистов как написано в статье. А ещё в разных областях можно повысить точность прогнозов с помощью прототипирования, симуляции, тестирования, учений и других методов ускорения обратной связи.
Никто не может угадать абсолютно точно когда закончится проект, зависящий от миллиона факторов. Я считаю погрешность 30% это потрясающе точный прогноз для больших проектов.
Я думаю что давать обещание на дату завершения проекта, который зависит от миллиона факторов, глупо. Расчитывать на такое обещание тоже глупо. А вот спрогнозировать вполне можно. Некоторые даже умеют делать это очень точно — в пределах 100% погрешности.
Прогнозы можно использовать для выбора между разными альтернативами и попытаться прикинуть, какой вариант скорее всего окажется выгоднее, его и использовать. Для этого и нужны прогнозы — они подсказывают направление движения.
Ошибка прогнозов это не проблема, это нормальная ситуация, которую невозможно избежать.
Можно только улучшать точность с помощью исторических данных и чеклистов как написано в статье. А ещё в разных областях можно повысить точность прогнозов с помощью прототипирования, симуляции, тестирования, учений и других методов ускорения обратной связи.
Мне кажется, что помимо объективных проблем трудности оценки трудозатрат, в постсоветских реалиях добавляется ещё и проблема откатов. Разработчик нередко вынужден закладывать в трудозатраты откат, который увеличивая бюджет, не позволяет заложить в оценку запас прочности, адекватный рискам (ведь надо ещё и конкурентоспособную цену назвать).
Мой (скромный) опыт говорит о том, что хорошо и стабильно оценивать сроки получается при сочетании трех параметров: опыта, контекста и мотивации. По пунктам:
-Опыт. Тут все просто и очевидно: человек, который никогда не оценивал сроки, делает это хуже; человек, у которого уже есть опыт оценки и работы со своей оценкой, со временем оценивает лучше. То же самое верно для команд.
-Контекст. Под контекстом я имею в виду любое окружение: технологии, команду, тип проекта. Человек, который всю жизнь работал с одним языком программирования, может серьезно ошибиться с оценкой проекта на другом языке; человек, долгое время работавший в стабильной команде, может серьезно ошибиться, выставляя сроки для другой команды (или выставляя сроки для себя после перехода в новую команду), и так далее.
-Мотивация. Если у людей нет стимула выставлять максимально точную оценку, они и не будут этим заниматься.
Слаженная, стабильная команда, которая занимается более-менее типовыми проектами и мотивирована выставлять максимально точные оценки, способна стабильно и регулярно выполнять работу в оговоренный срок.
P.S. «Зацикленность клиента на низкой цене приводит к перерасходу бюджета проекта» — это проблема всего бизнеса, а не проблема оценки сроков при разработке ПО. "Просто посмотрите, сколько подрядчиков при тендере на строительство шоссе называли условия лучше, чем конкурент, чтобы заполучить контракт и потом превысить смету на два миллиарда долларов и срок — на полтора года. Это бизнес. Когда речь идет о том, чтобы оставить свою компанию на плаву, ты пойдешь на всё".
-Опыт. Тут все просто и очевидно: человек, который никогда не оценивал сроки, делает это хуже; человек, у которого уже есть опыт оценки и работы со своей оценкой, со временем оценивает лучше. То же самое верно для команд.
-Контекст. Под контекстом я имею в виду любое окружение: технологии, команду, тип проекта. Человек, который всю жизнь работал с одним языком программирования, может серьезно ошибиться с оценкой проекта на другом языке; человек, долгое время работавший в стабильной команде, может серьезно ошибиться, выставляя сроки для другой команды (или выставляя сроки для себя после перехода в новую команду), и так далее.
-Мотивация. Если у людей нет стимула выставлять максимально точную оценку, они и не будут этим заниматься.
Слаженная, стабильная команда, которая занимается более-менее типовыми проектами и мотивирована выставлять максимально точные оценки, способна стабильно и регулярно выполнять работу в оговоренный срок.
P.S. «Зацикленность клиента на низкой цене приводит к перерасходу бюджета проекта» — это проблема всего бизнеса, а не проблема оценки сроков при разработке ПО. "Просто посмотрите, сколько подрядчиков при тендере на строительство шоссе называли условия лучше, чем конкурент, чтобы заполучить контракт и потом превысить смету на два миллиарда долларов и срок — на полтора года. Это бизнес. Когда речь идет о том, чтобы оставить свою компанию на плаву, ты пойдешь на всё".
только мне текст показался категорически нечитабельным?
Sign up to leave a comment.
Что мы знаем и чего не знаем об оценке трудозатрат в разработке ПО