Документирование проблем при работе над проектом

Posted on Sunday 13 September 2015 under , by Rustam Sydykov

Привет, народ!

Не уверен, писал ли я на эту тему или нет, но мне кажется она важной: как документировать проблемы при работе над проектом. Формально - это одна из обязанностей менеджера проектов (МП), технический специалист (ТС) не должен вести подобного типа документацию. Но иногда бывает, что МП по каким-либо причинам этого не делает, поэтому я самостоятельно начинаю документировать различные проблемы для своей же безопасности.
Не секрет, что часто большие проекты не всегда идут гладко: то возникают какие-то проблемы (в худшем случае – проект приходится закрывать), то происходить выход за границы бюджета, либо отставание по срокам. Вот тут-то начальство и другие люди, участвующие в проекте, начнут искать, на кого “повесить всех собак”. Как раз для эти случаев у меня наготове обычно два документа: “Incident log” (“журнал проблем”) и “Lessons learnt” (“выученные уроки”). Сразу же подчеркну: содержание этих документов должно “тонко подстраиваться” под каждую конкретную ситуацию! Т.е. то, что с вас потом будут спрашивать. Вы сможете потом подтвердить документально все факты и так же их “количественные” и “качественные” характеристики.
По моему опыту, в случае проблем/инцидентов всех интересуют следующие вещи:

  1. Когда это произошло. Если проблема не решается быстро, надо знать, как долго она тянется. Либо, если решение проблемы не зависит от вас, как долго вы ждёте действий от кого-то другого;
  2. Относится это напрямую к области вашей ответственности или нет. Вполне возможно, что кто-то “спихнул” проблему на вас и вы кучу времени потратили на “разруливание ситуации”, на которую вы не должны были тратить время. Но это же забирает время и ресурсы!? Такая классификация позволяет в дальнейшем доказать, что задержки были вызваны не непосредственно вашими действиями, а внешними факторами. Из последнего моего проекта 11 из 23 проблем не относились к тем изменениям, которые я и моя команда сделали. Порядка 55 часов было потрачено, чтобы решить проблему и доказать, что она возникла не из-за нас. Это огромная цифра;
  3. Краткое описание ситуации и проблемы – тут важно правильно всё написать, чтобы потом избежать “переопределения” ситуации и разговоров о том, что было “это”, а не “это”;
  4. Влияние на проект (“критическое”, “среднее”, “малое”, “незначительное” и т.п) – для установки приоритетов для решения проблем;
  5. Влияние на бизнес (“критическое”, “среднее” и т.п.) – иногда вышестоящие менеджеры не в курсе, насколько значительно происшествие. Категоризация позволит избежать “получения по шапке” за малозначимое событие;
  6. Статус инцидента – “закрыт” или всё ещё “открыт”;
  7. Причина/что вызвало происшествие – краткое описание как можно в более простых терминах причины события. Более детальная и “техническая” информация заносится (так, по крайней мере, я делаю) в другой документ – “Lessons learnt” (“Выученные уроки”). Об этом чуть позже;
  8. Сколько времени потребовалось на диагностику причин проблемы, причём это не включает в себя время, потраченное на устранение. Во время последнего проекта это время колебалось между 1 часом и 1 днем. Суммарно потратили 152 часа (на все инциденты), среднее время для нахождения причины – 7 часов. Это время надо учитывать особенно в том случае, если проблема была вызвана не вами. А вот решение проблемы может практически и не занять много времени;
  9. Время, потраченное на устранение инцидента и его последствий – максимально точное время потраченных усилий. Опять же, из последнего проекта – 39 часов суммарно, 2.5 часа в среднем на проблему. Разница существенная между диагностиком и устранением. “Дельта” показывает начальству, куда ушло время. Особенно, если оно было зря потрачено на “бодание” между различными командами. В нашем случае так часто и было;
  10. Действия, предпринятые для устранения проблемы в короткий срок – что было сделано, чтобы вернуть какой-либо сервис в нормальную работу. Вполне возможен “костыль”, если надо что-то сделать очень быстро. Но это должно быть описано и задокументировано. Инцидент может быть не закрыт, если бизнес не удовлетворён решением проблемы;
  11. Действия для недопущения проблемы в будущем. В отличие от предыдущего пункта, после этого инцидент можно формально будет считать закрытым.

Как я уже сказал, содержимое этого документа определялось вопросами от вышестоящего начальства по поводу проблем в процессе внедрения проекта. Вполне возможно, что что-то можно добавить, а что-то можно удалить. “Документ” – понятие вполне “живое” содержимое может меняться со временем.
По п.11: в него можно добавлять ссылки на документ “Lessons learnt”, но об этом чуть позже.

Засим раскланиваюсь,
Рустам.