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

Преамбула

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

Амбула

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

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

1. Нам нужны ещё соисполнители! На этой технологии специализируется бранч вендора, и сильны Компания#1 и Компания#2…

2. Нам нужно поменять процесс разработки! И это будет Scrum…

3. Нам нужно уже что-то предъявить Заказчику! Бежим искать и покупать готовый MVP…

4. Нам нужно ещё время! Давайте расширять содержание проекта, иначе никак…

5. Нам нужно проактивно документировать то, что можно без ПО, ведь у нас много отчётных документов! Давайте начнём с Disaster Recovery Plan…

6. И т.д.

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

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

• разработчики рассказами о боли

• руководитель проекта от Заказчика о том, что он предупреждал и требовал от всех опомниться ещё два месяца назад

• руководители соисполнителей, что у них то всё очень хорошо и они в сроках

• средний менеджмент — флешками с тонной первички и ссылками на вики, где вся информация есть и была под контролем, а вот топ-менеджмент зажал ресурс

• аналитики, что задача простая и решение очевидно, и почти не нуждается в уточнении анализом

• … а проектирования решения «просто не было«

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

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

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

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

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

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

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

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

• интервьюирование,

• фокус-группы,

• наблюдение,

• опросные листы,

• анализ документов,

• отбор идей,

• мозговой штурм.

Вывод

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

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