Комментарии 2
А как быть, если диагностику просто не дают делать? Когда PM фокусируется только на скорости — типо, "давай быстрее в спринт!111", и вместо сбора и агрегации информации ты постоянно клепаешь задачи по сырым вводным? В таких условиях любая попытка разобраться в хаосе воспринимается как «лишняя аналитика», если, например, полезть к разрабам с попытками дособирать информацию
Отличный вопрос! Потому что он максимально приближен к реальности и выходит за рамки любых методологий. Да и диагностика не всегда возможна в идеальных условиях. Когда мы говорим о каком-то подходе, то чаще всего рассчитываем на "хеппи пас" т.к. все пограничные ситуации покрыть просто невозможно! Иначе все сводится к борьбе приоритетов.
Если говорить именно о ситуации когда продакт гонит паровоз вперед ради красивого дашборда с метриками, то нужно адаптироваться и менять подход:
1. Диагностируй "на лету". Каждая задача - это возможность задать дополнительные вопросы. Например, это новое требование или доработка старого? Есть ли связь с бизнес-целью? Это не замедляет, а помогает лучше понять контекст.
2. Фиксируй вводные как есть. Если задача пришла из головы продакта - так и фиксируй: источник, дата, статус проработки. Это нужно не для отчетности, а чтобы через две недели не доказывать, что никто этого не уточнял. Это снимает с тебя ответственность за последствия и помогает управлять изменениями без истерик.
3. Документируй фактический процесс, а не идеальный. Раз ты не можешь выстроить структуру заранее, то строй её постфактум. Каждую итерацию фиксируй: откуда пришло изменение, почему оно появилось, что было непонятно на старте. Через несколько недель у тебя получится карта реального процесса требований.
Диагностика хаоса - это не про то, чтобы всех усадить и построить идеальный процесс с предварительным сбором всей информации. Это про то, чтобы даже в хаосе сохранить смысл, связность и управляемость. Адаптируйся!)))))
Системный аналитик и управление хаосом на проекте. Часть 1: диагностика хаоса