Добрый день. У вас тут засланец из вражеского лагеря agile :) В общем тут припекло по работе делать waterfall-style проект. Суть такая: есть сложная система и есть требование повысить ее надежность (есть довольно высокий процент ошибок в обработке потока входящих данных). То есть бизнесовое требование как бы одно - уменьшить процент ошибок (желательно до нуля). Проблема в том, что решений много (5) все они большие (каждое ~месяц), ни одно из них не решает проблему полностью, некоторые взаимосключающие и все не идеальные, нужно задизайнить некую комбинацию решений и представить это как некий план решения проблемы на следующий квартал. За сим вопрос какого рода документацию вы бы делали? Тут челендж в том, что мы получается хотим делать планирование и проектирование совместно. То есть разные варианты дизайна пораждают разные по сути проекты. Я думал так:дизайн-диаграмма + WBS который раскрывает шаги по построению заданного дизайна. Сделать N версий, на основании WBS сделать естимейты по вермени, на основании собственно дизайна - value. И дальше запланировать выполнение варианта-победителя по соотношению value/effort

Конечно, сразу видно - профессионал!

Ааааа-ааа! Зачем удалили ?! Я хотел посмотреть что там !!!

что вы от группы то хотите? по-моему, у вас данное начинание застряло на стадии бизнес аналитики. Документ, который можно смело порекомендовать, - устав проекта.

👍

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

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

Ок, ну то есть совместная таки работа. А по поводу документации что посоветуете?

Я ведь уже написал. Начать с того, чтобы составить устав проекта. Примеры можно найти на просторах интернета.
Если мы говорим про аналитику, то обычно в подобных случаях используются оценочные матрицы (score matrix, не уверен за корректный перевод на русский)

Ясно, буду искать. Спасибо!

Рад помочь!

Было бы неплохо для начала описать верхнеуровневую архитектуру, договориться о принципиальных подходах при разработке и внедрении, провести сравнение решений или swot анализ, выбрать основную платформу, которая по совокупности критериев поможет перекрыть большую часть нужных технологий и потребностей. Далее по хорошему нужно сделать свод всех функциональных и нефункциональных требований включая требования к мониторингу и  производительности, что бы ответить на вопрос "Что мы будем делать?" Затем подготовить системные требования, что бы ответить на вопрос "Как мы будем это делать?" Далее подготовить mindmap  основных работ, которые нужно сделать для  обеспечения сходимости процесса, затем можно переходить на привычные спринты, в рамках которых
отслеживать, достигается результат на каждом блоке и если нет, то вырабатывать меры по преодолению препятствий. Понятно, что не панацея, скорее обобщенный взгляд. Вообще все сложные системы нужно декомпозировать и концентрироваться на проблемном участке. Вероятнее всего и внедрять ничего не нужно, просто внимательно изучить проблемную область. Например, если это интеграция, то поможет отрисовка UML диаграммы с описанием как проходят вызовы между сервисами с настройкой мониторинга прохождения запросов. При этом мы вводили сквозную  систему UID для всех генерируемых запросов что бы можно было отслеживать их прохождение между несколькими слоями интеграций для точного установления мест их потери. Кейс - потеря 20% заказов и второй - не срабатывала активация тарифных планов при передаче корректных команд от платформы управления.

Спасибо за развернутый ответ! У меня сомнения были в той части, что планирование архитектуры получается должно быть до планирования работ. Здравый смысл это и подсказывал, просто начитался в интернете да и мне подсказывали, что в проект не заходят с несколькими решениями, вначале планируют, а потом уже делают архитектуру и тд.

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

На этапе планирования проекта на основании экспертных оценок создаются планы - содержания (WBS, как один из результатов), расписания и ресурсов (грубо и кратко если).

В процессе исполнения фазами могут быть: "Создание архитектуры решения", "Прототипы", "Кодирование" и т.д.

Если на какой-либо фазе становится понятно, что есть риски не "вписаться" в параметры проекта, то  планы корректируются согласно принятым правилам. Собственно это интеграционная работа и управление изменениями.

И, да, это пример из практики сотен проектов в нашей компании. Работает и, на мой взгляд не противоречит, PMBoK или, как вы сказали, waterfall :)

Что за сантабарбора в Чаптере творится 😱 ???

Попытка переворота. Вадим О. просьба вернуть этот телеграмм-канал!

Добрый день. Как вы считаете, для логистической сферы какие характеры проекты (по виду предметной деятельности)?

ИТ проекты или бизнесовын?

В том числе и ИТ, и Бизнесовые

ИТ: управление цепочками поставок, wms