Про ошибки

[Андрей Титов]

Поиск по "ошиб*" на форуме выдал более 100 сообщений, но не нашёл, где это подробно обсуждалось.

В отличие от выполненных задач, данные о совершённых ошибках в действиях, просчётах, предположениях нужно как то формализировать, сохранять и обрабатывать, а не сразу переводить в задачу и ...

Тут с багтрекерами всё понятно. Есть программа, сообщение, скриншот - лучше не бывает. А если это просчёт со сроками или сорванные в процессе переговоры?

Кто как пытался организовать сей процесс?

[ТыжМенеджер]

Ну в управлении проектами есть для этого отдельные механизмы. СБор LL, реестр рисков и так далее. В ITIL тоже есть свои контроли для этого. Я, к примеру, сейчас начинаю post-implementation review проводить для изменений в рамках процесса управления изменениями.
То есть, инструментария дофига, и если не устраивает просто накопление опыта, как наш мозг его себе устраивает, то есть откуда выбрать, мне кажется.

[Lomelind]

Можно просто среди справочной информации вести отдельный блок "как не надо".

Имхо, проблема не в том, куда такую информацию засунуть, а в том, как сделать, чтоб она не была write-only.
А для этого нужно понимать, кто и в каком случае туда вообще должен заглянуть.
И - чтобы что. Чтобы больше так не делать (а для этого ситуация должна быть повторяющейся), или чтоб настучать по голове виноватому (учитывая, что лучше всего задокументировать может именно виноватый...), или чтоб понять, сколько именно факапов уже есть?

[bearbeer]

Lessons Learned, SCRUM ревью и всё-такое.

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

[Женя С]

Круто. Я уже создал пару месяцев назад задачу "разбор факапов", но забыл записывать сами факапы.