Современные it продукты содержат множество зависимостей.
Здесь можно выделить два класса проблем:

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

Проблемы совместимости могут быть как на уровне ОС и оборудования, так и библиотек среды окружения где будет работать приложение

При слиянии (меrge) разных потоков разработки могут возникать конфликты, разрешение которых потребует длительного времени и привести к деффектам.

Часто конфликты случаются в случае рефакторинга кода или параллельной работы над одними и теми же компонентами разынми рабочими группами.

Чтобы предотвратить риск или смягчить его последствия рекомендуется:

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

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

Выбранный компонент не обладает достаточной гибкостью – чтобы удовлетворить текущим или новым требованиям заказчика.

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

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

Заказчик может предъявлять различные требования к “живучести” приложения и репликации данных при возникновении сбоев.

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

На текущий момент тестовых данных нет вообще. Если удастся получить данные для тестирования системы, то они могут быть низкого качества (мало, неполные, не по всем тест-кейсам), что не позволит провести качественное тестирование.

Распространенная проблема,

У legacy продуктов – стоимость добавления новой функциональности зачастую растет экспоненциально.

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

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

Необходимо иметь staging – точную копию среды для проверки процедуры развертывания

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

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

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

Внешние стейкхолдеры [укажите какие] не дадут быстрый ответ [о чем?], а будут долгое время думать, консультироваться, что затормозит ряд работ [каких, на сколько].

В команде нет специалиста по локализации, а также ни одного native speaker на английском языке. И хотя терминология простая, могут быть неприятные ляпы с локализацией на англ.

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

Прошлый опыт подсказывает, что руководство и маркетинг склонны делать несогласованный с R&D необоснованные публичные заявления, которые потом приобретают статус новых обязательств.

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

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

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

По текущим данным [указать подробнее данные и источник] есть риск того, что система не будет соответствовать требованиям по безопасности данных [указать конкретные тесты, показатели, причины].

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

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

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

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

Пока сложно сказать, с чем именно мы столкнемся, но у [указать члена команды] может не хватить опыта по [указать навык].

В проекте открыта вакансия [указать позицию], мы планируем проект исходя из предположения, что он будет найден и нанят, но последний опыт [указать причины опасений] подсказывает, что это условие может быть не выполнено…

Менеджер проекта ранее не имел дела с проектами в этой предметной области [указать область], что затрудняет принятие решений по проекту.

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

Кто внес это требование? [укажите спорную функциональность и дайте ссылку на текст требования].

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

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

Качество выявленных требований к продукту [название продукта] в проекте низкое [почему?], каждый разговор с представителями заказчика показывает, что есть ряд ожиданий [каких?], которые мы не видим и не планируем. Кроме того, очень многое [что именно?] помечено как TBD, что тоже может стать источником проблем. Все это может сделать невозможной сдачу-приемку, выявится большой объем доработок и изменений.