“Да, нужна”, - заявляет автор и хочет реабилитировать проектную документацию после многолетней борьбы с мега-ТЗ, архивами из Excel-файлов и инструкциями, которые никто не читает. Предложение - начинать с минимального набора: цель проекта, участники, ключевые процессы, решения, вопросы, риски и ссылки на источники актуальной информации. Документация здесь нужна прежде всего, чтобы команда не восстанавливала контекст заново при каждом изменении. Еще - принцип постепенного восстановления: если на проекте хаос, не нужно останавливать всю работу ради создания идеальной базы знаний — достаточно документировать наиболее рискованные и часто используемые участки по мере движения. В целом, посыл такой: полезность документа определяется не объемом и красотой шаблона, а тем, помогает ли он кому-то принять решение или выполнить работу.
Кто отвечает за сбой: четыре роли, которые руководителю нельзя путать
Вот возник инцидент - и задача часто автоматом достается или тому, кто первым заметил проблему, или самому компетентному специалисту. Но ведь ни один из них не обязан быть владельцем всей ситуации. И автор предлагает разделять 4 роли: обнаруживший фиксирует сигнал, стабилизатор ограничивает ущерб, эксперт предоставляет знания, а владелец ведет инцидент до закрытия. Совмещать роли можно, но это должно быть осознанным решением, а не, как бывает, “раз уж начал, доведи до конца”. Но выводы шире темы инцидентов: участие в задаче, экспертность и ответственность за конечный результат — разные…
Упс!…
