Антон Фокин

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

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

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

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

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

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

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

Про второй заход соглашусь — его почти всегда съедает то, что проверка выглядит как «посмотреть глазами», а не как работа с оценкой. Мы ведём это задачей у владельца знаний: календарь фиксирует слот, но не фиксирует объём, и первая же горящая задача его перебивает. В задаче видно, что именно проверено и сколько осталось, — значит, при переносе срока разговор идёт не о занятости эксперта, а о непроверенной части базы. Доживает до конца ровно то, у чего есть исполнитель и приёмка

Спасибо, показатели рабочие — мы бы их тоже свели в одну панель.

Раньше всех срабатывает задержка синхронизации: окно, в котором возможна перепродажа, равно интервалу обмена плюс время обработки, и растёт оно ещё до того, как появятся дубли и расхождения. Те двое — уже последствия, а среднее время ручного восстановления показывает проблему последним, когда её чинит человек.

К четырём я бы добавил пятый, самый ранний: доля событий, ушедших в очередь разбора — не найден SKU, ERP отклонила документ, склад не подтвердил резерв. Журнал видит это до того, как расхождение дойдёт до остатка

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