Comments 11
Чтобы выяснить, что именно делал Игнатий для того, чтобы процедура отрабатывала корректно и на слайде отображались актуальные данные, потребовалось 4 человеко-часов работы двух других аналитиков.
Всего 4? Игнатий был образцом документирования и сохранения информации о своей работе!
Автор, по-моему, Вы не понимаете значение слова "disclaimer".
Крик души вижу я в этом материале. Поддержу, причём со стороны эксплуатации. Ибо решение проблем пользователей (админов прикладного сервиса в админке) по алгоритму:
выяснить белые
IP-адреса сервиса;уточнить, что слушает эти адреса - железо, и какое - F5, cisco, etc; ПО - nginx, IPVS, etc;
если ПО - глянуть в логи, что там, ИНОГДА помогает локализовать проблему;
выяснить, на какие хосты проваливаются запросы с фронта;
изучить логи ПО, на которое проваливается фронт;
если проблема дальше - идти дальше; И так - пока не будет найден проблемный узел (узлы/ПО).
вообще не впечатляет.
Мониторинг - работает. Все сервисы на читающие запросы отвечают 200, проблемы возникают при редактировании/создании материалов и заливке больших мультимедиа-файлов. Или при выдаче видео-контента, там свои тараканы были в те времена.
В эскплуатации отсутствие документации - это вообще штатная ситуация. :(
По существу же.
Необходимы правила/стандарты/шаблоны ведения документации. Чтобы документация воспринималась именно документацией, а не сборником сочинений на свободную тему.
А дело не в документации, отсутствии желания её писать или читать, и даже не в мнимой "ценности пока это знаешь только ты". Для того, чтобы это победить, нужен простой советский...
Умение декомпозировать в голове задачи. Для того, чтобы описать последовательность шагов Игната, нужно не раз в неделю с горящей пятой точкой что-то там хардкодить, а сесть и подумать, почему вообще что-то надо хардкодить. Разложить процесс на этапы, немношк напрячься - и вот с одной стороны в голове сформировался алгоритм, как это работает, с другой - как это должно работать. И тогда записать не сложно, в этом нет никакой проблемы. Это одна сторона проблемы.
Другая сторона - при реализации приложения / отчета была допущена ошибка. Во время декомпозиции не подумали, что что-то надо написать, кроме своего имени в Jira при списании человекочасов. Не подумал исполнитель, не подумал заказчик, как итог - вот такая вот ситуация. И дело не в том, что у кого-то KPI не было - не было понимания, что эту работу надо сделать в принципе.
Иными словами, с аналитическим и структурным мышлением порой сложно у специалистов. В статье описаны шаги, как починить сломанное, а вот как предотвратить поломку - это гайды из другой области. К сожалению. Мне бы хотелось, чтобы подобные проблемы решались просто чек-листом, но без понимания причинно-следственной связи это будет работа из-под палки
Вообще, по поводу документации, мозги встают на место на 5-7 год работы в любой компании с ОПО и численностью более 1k.
Благодарю. Это важно!
Без документации проект живёт до первого отпуска разработчика. Потом начинаются гадания по коду и поиски того самого скрипта, который "все помнят, но никто не видел"
А я пока воюю с руководителями и РП за часы в бюджете на обновление функциональных моделей процессов на этапах проекта, следующих за моделированием.
Почему-то все искренне считают, что ФМ - это фантики, которые можно продать заказчику и дальше жить без них.
Сделайте документацию частью процесса
Мотивируйте команду
2й шаг самый важный. Потому что если не убедить начальство в том, что качественное документирование необходимо, то дальше можно и не продолжать. Нет, можно, конечно, сражаться в одиночку, но скорее всего исход будет не завидный. Впрочем, есть шанс сперва заручиться поддержкой коллег (3й шаг), но это скорее только среди других аналитиков и, возможно, тестировщиков. Всех прочих (в основном разработчиков) почти наверняка придётся мотивировать следовать уже утверждённому процессу.
Документация как навык выживания