«Это же ваша программа»: когда знание о доработках уходит в отпуск

Две истории из одного чата

Это обычные сообщения из чата аналитиков 1С, и в них нет ничего исключительного. Исключительных историй про носителей знаний не бывает: они одинаковые. Человек ушёл, вместе с ним ушло понимание, почему система устроена так, а не иначе.

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

Почему знание оседает в одном человеке

Никто не планирует зависеть от одного сотрудника. Это получается само:

• Документацию не пишут, потому что бизнесу нужна функция, а не её описание. Доработку сдали, пользователи работают, описание отложили «на потом».
• Автор доработки помнит её без документации. Пока он на месте, проблемы нет, и писать описание незачем.
• Следующая доработка ложится поверх предыдущей. Через год их десятки, и связь между ними есть только в голове одного человека.
• Подрядчики меняются. Каждый знал свою часть и ушёл вместе с ней.

В чатах это называют точно: «один программист подсаживает бизнес на себя, и без него ничего не работает». Чаще всего без злого умысла.

Во что это обходится

Пока носитель знаний на месте, цена невидима: он просто отвечает на вопросы. Она становится заметной в трёх ситуациях.

Третья ситуация самая дорогая. Доработку, назначение которой забыто, страшно трогать и невозможно выбросить. Она переезжает из релиза в релиз только потому, что никто не помнит, можно ли без неё.

Как сделать знание о конфигурации общим

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

Вопросы вместо звонка отпускнику

Чат-эксперт отвечает на вопросы по проиндексированной конфигурации: откуда берётся значение, что делает документ при проведении, какие объекты затронет изменение, где заканчивается типовое и начинается доработка. В ответе названы объекты конфигурации и стоят отметки источников, так что его можно проверить.

Это ровно те вопросы, с которыми раньше шли к единственному человеку. Он остаётся в команде, но перестаёт быть единственным способом получить ответ.

Инструкции появляются вместе с доработкой

Вторая половина проблемы в том, что описание новой доработки некому писать. В 1Yes Аналитик инструкции собираются из решения: по настройке и для пользователя. Их можно скачать и передать тем, кто будет работать с доработкой.

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

Что остаётся за человеком

Система хранит, как конфигурация устроена. Почему она устроена именно так, какие были договорённости с бизнесом, что не стали делать и по какой причине — это знание тоже стоит записывать, и за это по-прежнему отвечают люди. Разница в том, что теперь им не нужно держать в голове ещё и устройство системы.

Когда это не сработает

• Индекс устарел. Если конфигурацию дорабатывают, а индекс не обновляют, система знает прошлое состояние. Обновление индекса — регулярная услуга, а не разовая работа.
• Вопрос про данные, а не про устройство. Для индексации нужны структура и код, продуктивные данные не нужны. Почему у конкретного документа такая сумма, система не скажет.
• Инструкции есть только у новых доработок. Система собирает их для решений, которые проработаны в ней. Описание старых доработок она не достанет из ниоткуда, но ответить на вопросы по ним сможет.
• Система может ошибаться. Для этого в ответах есть источники: спорное утверждение проверяется по объекту, на который оно ссылается.

С чего начать

1. Замер конфигурации. Передаём скрипт-отчёт 1С, по нему считается объём индексации.
2. Индексация. Система разбирает структуру метаданных, связи объектов и доработки.
3. Первые вопросы. Лучше всего взять те, на которые сейчас может ответить только один человек в команде.