Итерационный подход

Очень сложно решать задачи, связанные с параллельностью работы пользователей. При диагностике мы ищем узкие места. Но часто в подобных ситуациях узких мест много.
Может быть даже целый каскад значимых узких мест, и количество их непредсказуемо.
Для бизнеса это плохо слабой предсказуемостью трудозатрат. Пока одно узкое место не расшито — можно не увидеть причин следующего узкого места, а значит и не оценить его стоимость. Такие проблемы решаются многоитерационным способом. Как говорят профессионал — это тот, кто много раз наступил на грабли.
Нам нравится считать себя профессионалами, и поэтому мы не сможем вам дать формулу подсчёта стоимости при итерационном подходе. Это вызывает сильное непонимание у бизнеса, и часто звучат фразы типа “не надо юлить и разводить нас на деньги”. Правильным ориентиром будет: сначала предварительная оценка эффекта от расшивания самого узкого места. Если количество блокировок не уменьшится, то это вовсе не означает, что не стало лучше. В апдексе будет например видно, что интенсивность ввода данных возросла. И только вследствие возросшей интенсивности появились новые блокировки.
Затем будет следующая итерация, где мы оцениваем суммарную интенсивность блокировок, группируя их по месту исполнения кода.
Используя правило Парето (расшифровать про 20-80), выясняем новое наиболее узкое место с учётом количества пользователей, которые страдают от этих блокировок, таблиц на которых возникают эти блокировки.
Можно не знать, как работает бизнес-логика приложения, но при этом понять, что избыточные блокировки часто возникают из-за отсутствия используемой аналитики, по которой различается конкурирующая активность различных пользователей. Например, мы часто видим, что во многих решениях закрытие месяца происходит по предприятию в целом, а не по организации в частности. Нет измерений и индексов с ведущей организацией. Из-за этого все организации вынуждены ждать ту, которая закрывает месяц в настоящее время.
Некоторые блокировки можно было бы вообще избежать при более активном взаимодействии программистов и бизнеса. Не зная точно, нужно ли накладывать блокировку, и не желая выяснять у бизнеса, программист использует пессимистичный стиль “пусть будет блокировка на всякий случай”. Мы часто переспрашиваем бизнес, а нам нередко отвечают “да мы эти таблицы вообще не используем, их можно отключить”.
Ещё одной итерацией в нашей практике часто бывает ситуация, когда якобы кто-то всех блокирует и всем плохо, но никто не знает — кто и что делает. Эта задача также легко программно решается, используя собираемые логи об активности пользователей. При желании можно написать код, который будет управлять наложением блокировок, анализируя текущую ситуацию более продвинуто, например оценивая роль сотрудника в компании, критичность бизнес-операции для бизнеса.
Я не буду пересказывать книжку “1С-Эксперт”, так как там достаточно большой раздел посвящён решению проблем с блокировками.
Главное здесь — не хвататься за всё сразу, а расставить приоритеты по каждому конкретному случаю и решать каждый случай отдельно, не позволяя другим сотрудникам компании пытаться всё смешать в одну кучу. Не позволяйте им обобщать и выбрасывать важные различия в деталях.