РП классики. Твердые основания принятия решений

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

Ниже наш со студентами список того, что дает опору при принятии решения: - Нормативно-правовой документ (NDA, договор, Акты сдачи-приемки и т.д.) - Коммерческое предложение, оценка - Устав проекта - Бюджет, смета - Протоколы, Минутки - Проектная документация в письменном виде (ФС, ТЗ, БТ, BRD, FSD, ОТАР и т.д.) - Порядок экскалаций, матрица коммуникаций (иногда как приложение в договоре, иногда отдельно) - Раздел/Приложение договора о критериях приемки (ПСИ) - Дорожная карта проекта и детальный план в MS Excel, MS Project, Jira или любые аналоги - Внутренние регламенты, стандарты (разработки), шаблоны и инструкции (начиная с банального, как зайти на стенд) - Метрики и показатели - ПиМИ (программа и методика испытаний) Особняком стоит Case Study (свои и чужие)

Список не претендует на полноту. По моему опыту, это гигиенический минимум любого IT-проекта в ФинТехе. Мы со студентами не будем разбирать каждый артефакт, остановимся на отдельных элементах.

Начнем с того, к которому у знакомых мне РП диаметрано противоположный подход - метрики. Кто-то пытается мерить все, даже когда невозможно собрать качественные данные, кто-то живет без метрик на “интуиции”. Что мы соберем с моими студентами, в следующем посте.

Предыдущий пост тут. #РПКлассики