Pull to refresh

Comments 5

Насчёт нереалистичности: тут у каждого свой опыт, но в нашем случае (специализируемся на дизайне сложных интерфейсов) примерно 20% заказчиков приходят как раз за предпроектом.

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

Наверное, излишне говорить, что это лучшие клиенты: самые чёткие, самые быстрые, самые требовательные и самые заинтересованные в результате.

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

Но мы не настоящие сварщики, а узкоспециализированные, конечно.

Если у вас внедрена обязательная предварительная оценка с описанием всех действий и результатов на каждом шагу - мой вам респект

Аванпроект — это совокупность работ, которые выполняют перед проведением опытно-конструкторских работ с целью технико-экономического обоснования целесообразности разработки продукции и путей её создания, производства и эксплуатации[1], а также вид исходной технической документации, содержащей обоснование разработки продукции и её показателей, исходные требования и предложения по разработке, производству и эксплуатации продукции.

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

Проведение кодревью и ведение документации существенно влияют на сроки софтверных проектов, поэтому обсуждать это на 6 этапе, после оценки (5 этап) - прямой путь к срыву сроков.

В остальном отличная статья

Подумал. Вот 2 основные причины в моем опыте, почему оно не делается:

  1. Заказчик не обладает соответствующими ресурсами для качественного выполнения работ, формирует ТЗ по принципу "как смогла" и выставлет его на тендер. Дальше уже интеграторы "на опыте" смотрят, реалистично сделать то, что в ТЗ или риски слишком велики.

  2. Реактивное управление в компании: решения принимаются внезапно на уровне "ГД сказал сделать" и прдпроектное обследование скатывается в режим "денег заложим, а там что-нибудь придумаем"

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

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

Это хотелки. Можно считать их критериями успешности проекта. Но каким образом убедиться, что все те действия, которые перечислены в последующих пунктах, приведут к желаемому эффекту? Да и вообще что они достижимы?

Sign up to leave a comment.