Итеративная и инкрементальная разработка проектов. реферат. информационное обеспечение, программирование. 2012-09-07

Другие методологии управления проектами

Список методологий, проанализированных в данной статье, является довольно исчерпывающим. Другие важные методологии, которые следует принять к сведению, включают Adaptive Framework, PRiSM, Critical Path Method, Critical Chain Project Management, Crystal, PERT, Rational Unified Process, Extreme Programming, Rapid Applications Development, Outcome Mapping и многое другое.

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

«Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

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

отчёт о проделанной работе с момента последнего Scrum’a;
список задач, которые сотрудник должен выполнить до следующего собрания;
затруднения, возникшие в ходе работы.

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

Когда использовать Agile?

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

RUP

А теперь вернемся к RUP.

Безусловно, RUP – итеративная методология. Хотя выполнение всех фаз или какого-то минимального числа итераций нигде в RUP не оговаривается, весь подход ориентирован на то, что их достаточно много. Только при этом можно настроить процесс для последующих итераций, основываясь на результатах начальных. Ограниченное количество итераций не позволяет использовать в полной мере все преимущества RUP. Вместе с тем, RUP можно использовать и в «практически каскадных» проектах, включающих реально всего пару итераций: одну в фазе Построение и одну в фазе Передача. Кстати говоря, именно такое количество итераций, как правило, реально используется в каскадных проектах. Ведь проведение испытаний и опытной эксплуатации системы предполагает внесение исправлений, которые могут предполагать определенные действия, связанные с анализом, проектированием и разработкой, то есть фактически являются еще одним проходом через все фазы разработки.

Что касается формальности методологии, то здесь RUP представляет пользователю весьма широкий диапазон возможностей. Если выполнять все работы и задачи, создавать все артефакты и достаточно формально (то есть с официальным назначением рецензента, с предоставлением рецензентом достаточно полной рецензии в виде электронного или бумажного документа и т.д.) проводить все рецензирования, RUP представляет собой крайне формальную, тяжеловесную методологию. С другой стороны, RUP позволяет разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте. А выбранные артефакты могут выполняться и рецензироваться с произвольной степенью формальности. Можно требовать детальной проработки и тщательного оформления каждого документа. Можно требовать предоставления столь же тщательно выполненной и оформленной рецензии. И даже по старой практике утверждать каждую такую рецензию на Научно-техническом совете предприятия. А можно ограничиться электронным письмом или наброском на бумаге. В последнее время популярным становится выполнение ряда документов на доске с помощью мела (по старинке) или фломастеров (более новый подход) (12). А, кроме того, всегда остается еще одна возможность — сформировать документ «в голове». Попросту говоря, продумать соответствующий вопрос, принять соответствующее решение. И, если это решение касается только Вас, то ограничиться, например, комментарием в коде программы.

Таким образом, RUP — итеративная методология с очень широким диапазоном возможных решений в части формализации процесса разработки.

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

А теперь попробуем разобраться с классическим вопросом: «Что такое хорошо и что такое плохо?».

Этапы оценки проекта

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

Рассмотрим основные шаги оценки проекта.

Шаг 1. Оценка потребностей рынка и аудитории

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

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

Шаг 2. Оценка бизнес-идеи

Оценка бизнес-идеи — творческий процесс, который зависит от отрасли и специфики проекта. Для каждой отрасли процесс оценки бизнес-идеи будет отличаться, но есть универсальные рекомендации:

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

Шаг 3. Оценка плана управления проектом

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

В случае реализации непродолжительного проекта (3–9 месяцев) рекомендуем производить оценку и обновление плана каждые 2–3 недели.

Что такое итеративный процесс?

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

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

А что же такое неитеративный процесс?

В случае неитеративного процесса вы и ваша команда работаете вместе над разработкой конечного продукта. При этом вы необязательно пробуете новые идеи. Как правило, для неитеративных процессов требуется больше времени на этапе разработки концепции и создания продукта, чтобы на этапе тестирования всё работало так, как и было задумано.

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

Допустим, вы работаете с дизайнерским агентством над созданием электронной книги. Сначала необходимо предоставить полный текст этой книги. Затем дизайнерское агентство возьмёт этот текст и на его основе создаст варианты оформления. И в завершение ваша команда выполнит техническое редактирование электронной книги, чтобы всё было в порядке с точки зрения форматирования и вёрстки. Это пример каскадной модели, поскольку каждый очередной этап начинается после завершения предыдущего (нельзя приступить к вёрстке электронной книги, пока не будет разработан её дизайн).

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

Есть ли разница между инкрементным и итеративным подходом?

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

В случае итеративного процесса ваша команда занимается проработкой и совершенствованием проекта на основе обратной связи или новой информации. Итеративный подход основан на принципе проб и ошибок: в результате этих постоянных изменений проект со временем становится всё лучше.

При инкрементном проектировании, которое иногда называют инкрементной разработкой, вы добавляете новые функции и усовершенствуете продукт на базе исходной версии или первого полученного результата. В случае инкрементного проектирования команда целенаправленно создаёт базовую версию продукта, чтобы как можно скорее выпустить его (как это было, например, в старой мантре Facebook: «двигайся быстрее, сокрушая всё на своём пути»). Затем разработчики дорабатывают и улучшают исходную версию, навешивая на неё новые элементы и функции. Этот процесс продолжается до тех пор, пока конечный продукт не будет обладать всем необходимым функционалом.

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

Попробовать управлять проектами с помощью Asana

«Spiral Model» (спиральная модель)

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

Спиральная модель предполагает 4 этапа для каждого витка:

планирование;
анализ рисков;
конструирование;
оценка результата и при удовлетворительном качестве переход к новому витку.

Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование. На проекте по разработке СЭД для ОДУ Сибири СО ЕЭС два совещания об изменении кодификации разделов электронного архива занимают в 10 раз больше времени, чем объединение двух папок программистом. Государственные проекты, в которых мы участвовали, начинались с подготовки экспертным сообществом дорогостоящей концепции, которая отнюдь не всегда бесполезна, поскольку окупается в масштабах страны.

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

PRINCE2

Методология управления проектами PRINCE2 часто ошибочно принимается за структуру PMBOK PMI (Project Management Body of Knowledge), которая дает рекомендации по традиционной методологии водопадной модели.

В то время как PMBOK не является официальной методологией, PRINCE2 – это отдельный метод. Фактически он был создан как стандарт для управления проектами в области информационных систем правительства Великобритании.

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

ПРОЦЕССЫ

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

Методология содержит семь процессов, разделенных на 45 подпроцессов. Этапы исключительно детализированы и сосредоточены на всех аспектах проекта.

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

ИСПОЛЬЗОВАНИЕ МЕТОДОЛОГИИ

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

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

Заметки [ править ]

^ Ларман, Крейг (июнь 2003 г.). «Итеративная и инкрементальная разработка: краткая история» . Компьютер . 36 (6): 47–56. DOI : 10,1109 / MC.2003.1204375 . ISSN 0018-9162 . S2CID 9240477 . Мы занимались инкрементальной разработкой еще в 1957 году в Лос-Анджелесе под руководством Берни Димсдейла . Он был коллегой Джона фон Неймана., так что, возможно, он выучил это там или считал это совершенно естественным. Я действительно помню, как Херб Джейкобс (в первую очередь, хотя мы все участвовали) разрабатывал большую симуляцию для Motorola, в которой использовалась техника, насколько я могу судить … ‘
^ DOD-STD-2167 Разработка программного обеспечения для оборонных систем (4 июня 1985 г.) на everyspec.com
^ Farcic, Виктор (21 января 2014). «Модели разработки программного обеспечения: итеративная и инкрементная разработка» . Технологии разговоров .
^ a b Итеративное и постепенное развитие: краткая история , Крейг Ларман и Виктор Басили, IEEE Computer, июнь 2003 г.
^ Кендалл, Фрэнк; Гилмор, Дж. Майкл; Халворсен, Терри (02.02.2017). «Работа системы оборонных закупок» . Проблемы Министерства Обороны . Заместитель министра обороны по закупкам, технологиям и логистике. С. 12–14. Архивировано из оригинального 09.08.2017 . Проверено 9 августа 2017 .
^ USAID. «ADS Глава 201 Операционная политика программного цикла» . Проверено 19 апреля 2017 г.
^ «Разница между водопадом и инкрементальной моделью» . 19 мая 2016 года.[ постоянная мертвая ссылка ]
^ a b Белфиоре, Майкл (9 декабря 2013 г.). «Ракетчик» . Внешняя политика . Проверено 11 ноября 2018 года .
^ «Эксклюзивный взгляд на ранее секретную новую Mega Factory Rocket Lab!» . Повседневный космонавт . 11 октября 2018 . Проверено 11 ноября 2018 года .
↑ Кларк, Стивен (28 сентября 2008 г.). «Наконец-то сладкий успех для ракеты Falcon 1» . Космический полет сейчас . Проверено 11 ноября 2018 года . первая частная ракета на жидком топливе, успешно достигшая орбиты.
^ Бергер, Эрик (2018-06-25). «Российская ракета« Протон », которая предшествовала« Аполлону », наконец, прекратит полеты. Технические проблемы, рост SpaceX — это способствующие факторы» . arsTechica . Проверено 26 июня 2018 . Быстрый рост недорогих альтернатив, таких как ракета SpaceX Falcon 9, привел к тому, что количество запусков Proton в конкретный год сократилось с восьми или около того до одного или двух.
^ Fernholz, Тим (21 октября 2014). «Что потребовалось SpaceX Илона Маска, чтобы разрушить Boeing, обойти NASA и стать серьезной космической компанией» . Кварц . Проверено 11 ноября 2018 года . Но SpaceX всегда считала себя технологической фирмой, и ее столкновения с НАСА часто принимали форму, которую разработчики компьютеров — или любой, кто знаком с проблемным развертыванием healthcare.gov — признали бы поколениями. SpaceX следовала итеративному процессу проектирования, постоянно улучшая прототипы в ответ на испытания. Традиционное управление продуктом требует четкого и полного выполнения плана — рецепта перерасхода средств.
^ Gruss, Майк (2015-04-24). «Эволюция плана: руководители ULA объясняют логику выбора дизайна Vulcan» . Космические новости . Проверено 25 апреля 2015 года . ULA объявило 13 апреля, что разработает ракету, получившую название Vulcan, с использованием поэтапного подхода, первая итерация которого, по сути, представляет собой Atlas 5 с новой первой ступенью.

Эта статья включает в себя список общих ссылок , но он остается в значительной степени непроверенным, поскольку в нем отсутствует достаточное количество соответствующих встроенных ссылок . Пожалуйста, помогите улучшить эту статью, добавив более точные цитаты. ( Сентябрь 2010 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

Укрепление силы воли

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

Такой пример: раннее утро, совершенно не хочется вставать с постели. В сознании борются две стороны вашего «Я», активная и пассивная. Одна говорит: «Не хочу!», другая отвечает: «Надо!». Так вот, в подобном случае необходимо сосредоточиться, принять за факт, что активная сторона – это вы сами, а пассивная – кто-то посторонний, и твердо скомандовать: «Быстро встать и начать заниматься делами!». С вероятностью на 90% вы выполните команду своей силы воли. Ну, а если с первого раза не получится, то со второго – обязательно выйдет. Даже самая малая победа на пути воспитания воли – это шаг вперед. Сделав его, нужно как можно дольше удерживаться на достигнутом уровне, чтобы затем сделать новый шаг. Бывает, что человек срывается, откатывается назад в работе над собой. Не стоит отчаиваться и ругать себя, нужно просто начать все сначала.

Еще один прием по самовоспитанию: на протяжении 2 недель необходимо ежечасно (можно использовать будильник) останавливаться и задавать себе вопрос: «Чем я сейчас занимаюсь, контролирую ли свои действия, действую разумно или плыву по течению, подобно листку в реке?».

Данные упражнения нужно выполнять время от времени для профилактики или же при наступлении хандры, депрессивного состояния, лени, прокрастинации. Упражнения позволят вернуть господство вашего активного волевого «Я». Необходимо всегда помнить о том, что эта часть вашего сознания и есть вы.

Пять шагов итеративного процесса

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

1. Составление плана и требований

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

2. Анализ и проектирование

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

3. Реализация

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

4. Тестирование

После получения первой итерации производится её тестирование наиболее подходящим способом. Например, если вы работаете над улучшением веб-страницы, вам следует произвести A/B-тестирование относительно текущей версии веб-страницы. Если вы создаёте новый продукт или функцию, можно протестировать удобство их использования на потенциальных клиентах.

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

Читать: Что представляет из себя схема «планирование, исполнение, проверка и принятие необходимых мер» (PDCA)?

5. Рассмотрение и оценка результата

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

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

Соответствующие и нерелевантные затраты

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

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

Наиболее типичные ошибки при оценке работ в проектах 1С

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке.
Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, — то вам будет полезно понять методы оценки работ.
Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет».
Типичные ошибки распределю по классам.

Что в итоге

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

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

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

Удачи в проектах!