Преамбула

Это слишком серьёзный текст, чтобы его читать человеку без чувства юмора.

Амбула

Итак, когда идёт реактивная эскалация, и в этот момент почему то все всегда знают "что делать" и "кто виноват". Но существенная проблема в том, что никто не обладает полнотой картины. И принимать решение на этой стадии просто рано. После того как выяснили, что кризис не в процессах менеджмента или не только в них, начинают предлагать "решения" ровно с того понимания (point of view), которое родилось в "углу обозревателя". Мы все становимся сразу экспертами по решению. К сожалению, диванными. И ваш покорный слуга - и близко не исключение. Мы все видим только то, что позволяет наша призма приоритетов и личных ограничений. И как в известной карикатуре Павла Кучински об ограничениях в современной подаче информации, готовим решения на основе своих предпочтений и ограниченного угла обзора.

А необходимо просто открыть дверь и встать на порог

Для примера, и именно из этого проекта, несколько заявлений ("решений") от заинтересованных лиц.

Нам нужны ещё соисполнители! На этой технологии специализируется бранч вендора, и сильны Компания#1 и Компания#2...
Нам нужно поменять процесс разработки! И это будет Scrum...
Нам нужно уже что-то предъявить Заказчику! Бежим искать и покупать готовый MVP...
Нам нужно ещё время! Давайте расширять содержание проекта, иначе никак...
Нам нужно проактивно документировать то, что можно без ПО, ведь у нас много отчётных документов! Давайте начнём с Disaster Recovery Plan...
И т.д.

Потом и задним числом, и опосредовано, ты понимаешь, что "декабристы будят Герцена". Но (!) imho революция в проекте всегда ведёт к негативному сценарию закрытия. И тут с данным списком заявлений не поможет ни priority, ни severity, ни их комбинация.

И руководитель проекта должен в этом случае пробежать по всем участникам существовавшего до этого момента процесса и собрать всё, чем будут делиться:

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

И это всё хорошо...

Но ситуация проблемна не этим. Команды нет. Есть личности. Есть профессионалы. А общая командная игра в проекте напоминает известную карикатуру про неполитические проекты с несбалансированной и неконтролируемой "политикой" внутри.

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

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

Мгновение, и я начал понимать, что правы в советах и предлагаемых решениях (и в этот момент "заявления" превращаются именно в решения) абсолютно все.

И нужна смена парадигмы процесса разработки, и нужны ещё ресурсы, и как минимум необходим работоспособный PoC из вне, так как на исследования внутренними ресурсами в проекте уже нет времени. В общем необходимо делать по максимуму в проектных решениях, чтобы проектные группы потратили минимум времени и ресурсов. И это не парадокс. Это просто практика "приличного" руководителя проектов, когда под планированием понимается не Gantt Pushing, а работа над "что, если". И ей приходится учиться заново в каждом новом проекте. И я учился.

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

Замечу, что аналогия этого облегченного сбора требований - некоторый квазипресейл "нового" проекта. И если данный пресейл не успешен, негативный сценарий закрытия проекта неизбежен.

Теперь немного теории, которую я на тот момент просто не знал. Сегодняшнее мое представление об облегченном сборе требований в полном виде выглядит так:

интервьюирование,
фокус-группы,
наблюдение,
опросные листы,
анализ документов,
отбор идей,
мозговой штурм.

Вывод

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

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

Заметки на полях: «Облегчённый сбор требований»