Как я неделю не подключал новые сервисы и наконец понял, где у нас ломается работа

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

В какой-то момент я поймал себя на странной привычке: почти любую внутреннюю проблему я пытался решить новым сервисом.

Заявки теряются? Нужно посмотреть CRM получше. Команда забывает задачи? Наверное, нужен другой таск-трекер. В таблицах бардак? Может, пора внедрить базу данных. В чатах невозможно найти решение недельной давности? Значит, нужен корпоративный портал, база знаний, бот, нейросеть, что-нибудь с красивым лендингом и тарифом команда плюс.

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

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

К понедельнику у нас было 11 активных таблиц, 16 рабочих чатов, 4 доски с задачами, 3 папки с документами, которые все считали главными, и одна таблица, которую никто не трогал, но все боялись удалить. В команде было 7 человек. Это небольшой масштаб, но хаос уже вел себя как крупная компания после трех слияний.

Самое неприятное открытие случилось не в пятницу, а в первый час. Я понял, что мы не работаем в системе. Мы работаем в воспоминаниях о системе.

День первый: я составил карту хаоса и перестал верить названиям файлов

Начал я не с таблиц и не с задач. Я начал с инвентаризации. Не в смысле аккуратно выписал все инструменты. Это было бы слишком красиво. Я просто попросил команду прислать мне ссылки на места, где у нас хранится рабочая информация.

Через сорок минут у меня было 38 ссылок. Потом еще пять. Потом один человек вспомнил про старую таблицу, где якобы были нормальные исходные данные по оплатам. Потом выяснилось, что нормальные исходные данные лежат не там, а в копии этой таблицы, которую сделали перед отпуском. Классика: перед отпуском человек не отдыхает, а создает параллельную вселенную.

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

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

Я быстро разделил все рабочие места на четыре слоя:

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

С болотами было больнее всего. Их нельзя просто удалить, потому что внутри иногда действительно лежали важные куски. Например, в одной старой таблице нашлась колонка с причиной отказа клиента. Ее перестали заполнять полгода назад, но там было 147 строк, и по ним стало понятно, что мы часто проигрывали не из-за цены, а из-за длинной паузы между первым разговором и расчетом.

Я думал, что первый день уйдет на сортировку. На деле он ушел на расследование происхождения данных. Самый частый вопрос был не где лежит файл, а почему мы ему верим. Вечером я сделал грубое правило: у каждого типа данных должен быть один источник правды. Не самый красивый, не самый новый, не тот, где удобнее фильтровать, а один официальный. Если данные нужны в другом месте, туда они копируются или подтягиваются, но не переизобретаются руками. Например, список клиентов живет в одной таблице. Статусы задач живут в таск-трекере. Оплаты живут в финансовой таблице. Контакты подрядчиков живут в отдельной вкладке, а не в личных сообщениях у того, кто однажды с ними переписывался. На этом этапе я чуть не сорвался и не начал искать сервис для управления справочниками. Но эксперимент есть эксперимент. Я просто добавил лист Справочники в старую таблицу и сделал нормальные выпадающие списки.

Не героично. Зато работает.

Таблицы: я лечил не формулы, а поведение людей внутри ячеек

Во вторник я открыл главную таблицу по клиентам. В ней было 612 строк и 43 колонки. На первый взгляд все выглядело терпимо. Цветные статусы, фильтры, комментарии, даты, ответственные. Через десять минут стало понятно, что таблица не ведется, а имитирует порядок. В колонке статус было 19 вариантов. В работе, работаем, в процессе, ждем ответ, ждём ответа, думают, клиент думает, пауза, пока молчат, зависло. Технически это разные значения. Для человека одно и то же настроение. Я выгрузил уникальные значения по ключевым колонкам и получил маленький музей человеческой импровизации. Менеджеры не портили таблицу специально. Они просто писали так, как говорили в жизни. Проблема в том, что формулы не понимают интонацию. Сначала я сделал словарь статусов. Не для красоты, а чтобы у каждого статуса было последствие. Если статус ничего не меняет в работе, он не нужен. Например, статус клиент думает бессмысленный, если после него нет даты следующего действия. Он просто успокаивает менеджера. Вроде задача не брошена, она думает вместе с клиентом. Я оставил восемь статусов: новая заявка, квалификация, расчет, предложение отправлено, согласование, договор, оплата, закрыто. Отдельно добавил отказ и архив. Для зависших случаев ввел не статус, а признак блокировки с причиной. Это важная разница. Статус показывает этап процесса, блокировка показывает проблему.

Потом я занялся идентификаторами. До этого мы искали клиентов по имени, телефону, названию проекта или вообще по памяти. Я добавил простой ID клиента и ID проекта. Не UUID на 36 символов, а нормальный человекочитаемый код вида CL-2026-017 и PR-2026-041. Да, можно было сделать умнее. Но мне нужно было, чтобы менеджер мог продиктовать код голосом и не возненавидеть меня.

Таблицы я чистил в несколько проходов:

Убрал объединенные ячейки, потому что они красивые только до первой сортировки.
Развел вводимые руками данные и расчетные поля по разным зонам, чтобы никто случайно не переписал формулу.
Добавил проверку данных для статусов, ответственных, источников заявки и типов проектов.
Поставил условное форматирование не для радуги, а для тревожных мест: просроченное следующее действие, пустой ответственный, сделка без суммы, проект без ID.
Добавил технические колонки с датой последнего изменения, возрастом сделки и количеством дней без следующего шага.
Сделал лист Ошибки, куда через фильтры и формулы выпадали строки с явными проблемами.
Закрыл редактирование справочников для всех, кроме двух человек.

Самое полезное было не условное форматирование и не формулы. Самое полезное было поле Следующее действие. Раньше у нас было много статусов, но мало конкретики. После звонка менеджер мог поставить согласование и уйти. Теперь он должен был указать действие и дату: отправить расчет, позвонить, запросить реквизиты, передать в производство, проверить оплату.

К среде утром таблица начала раздражать команду. Это хороший признак. Плохая таблица всем удобна, потому что ничего не требует. Рабочая таблица начинает спорить с человеком. Она подсвечивает пустоты, ругается на странный статус, не дает записать источник заявки как инста, инстаграм, Instagram и от Маши одновременно.Была еще одна техническая проблема: в нескольких таблицах одни и те же данные копировались руками. Например, сумма сделки была в таблице продаж, в финансовом файле и в плане производства. Расхождения доходили до 18 процентов, потому что скидку могли учесть в одном месте и забыть в другом. Я не стал строить сложную интеграцию. Я просто выбрал таблицу, где сумма появляется первой и подтверждается ответственным. В остальных местах оставил ссылку на строку и подтягивание через поиск по ID. Это не идеальная архитектура, но она убрала главный грех: разные люди перестали вручную переписывать одну и ту же цифру. В конце дня я сделал странную вещь. Открыл старые комментарии в ячейках. Там оказалась настоящая история компании. Не отчеты, не презентации, а короткие человеческие следы: клиент просил не звонить после 18, обещали скидку при повторном заказе, дизайнер уже видел этот проект, оплату задержали из-за смены юрлица. Часть комментариев я перенес в карточки задач, часть в заметки по клиенту, часть удалил. Комментарий в ячейке удобен, пока его помнит автор. Через месяц он превращается в пыль под ковром.

Чаты и задачи: я перестал искать виноватых и начал искать потерянные решения

С чатами все оказалось хуже, чем с таблицами. Таблица хотя бы притворяется структурой. Чат честно признается, что он поток. У нас были чаты по проектам, чат отдела продаж, чат с подрядчиками, чат для срочного, чат для не срочного, чат для руководителей, чат, который когда-то создали на один запуск, но он выжил и стал местом для всего подряд. В одном чате обсуждали макеты, оплату, отпуск, баги на сайте и где заказать пиццу. Пицца, кстати, находилась быстрее всего. Я не стал переносить всю переписку в задачи. Это бесполезный подвиг. Переписка нужна как контекст, но не как система управления. Я сделал проще: выделил типы сообщений, которые обязаны покидать чат. Решение должно уходить в задачу. Срок должен уходить в задачу. Файл должен уходить в папку или карточку. Деньги должны уходить в финансовую таблицу. Контакт должен уходить в справочник. Жалоба клиента должна уходить туда, где ее увидит не только человек, которому не повезло получить сообщение. До этого у нас было любимое командное заклинание: вроде обсуждали. После ревизии я начал считать эту фразу сигналом аварии. Если обсуждали, но нигде не зафиксировали, значит, не обсуждали. Просто группа людей временно синхронизировала тревожность.

С задачами я сделал отдельную чистку. У нас в старой доске висело 286 карточек. Из них 41 была без срока, 23 без исполнителя, 37 дублировали другие задачи или были похожи до степени семейного скандала. Еще были карточки с названиями поправить, проверить, срочно, обсудить, финал. Такая задача не помогает работать. Она заставляет человека вспоминать, что он имел в виду в прошлой жизни. Я ввел правило для названия задачи: глагол, объект, результат. Не лендинг, а подготовить первый экран лендинга для согласования. Не клиент, а отправить клиенту расчет по проекту PR-2026-041. Не правки, а внести правки из письма от 14 июня в коммерческое предложение. Статусы тоже пришлось переделать. До этого у нас была доска с колонками надо, делается, готово, потом. Потом была самая честная колонка. Там жили задачи, которые не умерли только потому, что никто не решался их похоронить.

Я оставил рабочий поток из пяти состояний:

Входящие: задача еще не разобрана, у нее может не быть срока и исполнителя, но жить там она может только один рабочий день.
К работе: задача понятна, есть владелец, результат и срок.
В работе: исполнитель реально делает задачу, а не просто забрал ее морально.
На ожидании: задачу нельзя продолжить без внешнего ответа, файла, оплаты, решения или доступа.
Готово: результат можно проверить без звонка автору задачи.

Самый спорный статус был на ожидании. Его пытались использовать как санаторий для неприятных задач. Поэтому я добавил обязательную причину ожидания и дату следующей проверки. Если задача ждет клиента, должно быть понятно, кто и когда его дернет. Если ждет доступ, должно быть понятно, у кого он запрошен. Если ждет решения руководителя, руководитель должен увидеть это не случайно, а в отдельном фильтре. В четверг я связал чаты и задачи через ссылки. Не автоматизацией, а дисциплиной. Когда в чате появлялось решение, в задаче появлялась ссылка на сообщение. Когда в задаче менялся срок, в чат уходило короткое сообщение с причиной. Не все обновления, не шум ради шума, а только то, что влияет на других. Параллельно я закрыл старую дыру с файлами. До этого финальные документы лежали где угодно. Коммерческое предложение могло быть в личной папке менеджера, в общей папке проекта, в чате или вложением к письму. Я ввел правило: файл считается рабочим только если он лежит в папке проекта и связан с задачей или клиентом по ID. Все остальное черновик, даже если называется финал_точно_последний.

Тут я впервые за неделю почувствовал, что порядок начинает экономить время. Не вдохновлять, не мотивировать, а тупо экономить. Один менеджер нашел нужное КП за 20 секунд вместо обычных пяти минут с фразой сейчас поищу. Другой не стал дергать дизайнера, потому что увидел в задаче ссылку на макет и последнее согласование. Мелочь, но из таких мелочей складывается рабочий день.

Права доступа: неприятный слой, о котором вспоминают только после проблемы

В пятницу я занялся тем, что обычно все откладывают. Доступами.

Это скучно, пока не становится дорого. У нас были документы, открытые всем по ссылке. Были подрядчики, которые закончили работу год назад, но все еще могли смотреть папки. Был бывший сотрудник, который не редактировал ничего, но формально имел доступ к таблице с клиентами. Были личные аккаунты, на которых держались важные файлы. Был один файл, владельца которого уже никто не мог быстро найти.

Я не устраивал охоту на ведьм. Почти всегда такие вещи появляются не из злого умысла, а из удобства. Нужно было срочно показать макет, дали доступ по ссылке. Нужно было быстро отправить таблицу подрядчику, открыли редактирование. Потом проект закончился, люди переключились, доступы остались. Цифровая пыль не видна, пока не включишь фонарик. Я сделал простую ревизию по владельцам. У каждого важного файла должен быть владелец внутри команды, а не просто человек, который когда-то его создал. У каждой папки должен быть понятный принцип доступа. Если папка проектная, доступ получают те, кто реально участвует в проекте. Если папка справочная, большинство смотрит, редактируют единицы. Если внутри персональные данные, никаких открытых ссылок. Самым технически неприятным было не закрыть доступы, а не сломать работу. Когда начинаешь все запирать, легко превратить порядок в бюрократический квест. Поэтому я шел от риска. Сначала клиентские данные, финансовые файлы, договоры, доступы к рекламным кабинетам, потом проектные материалы, потом архивы. Параллельно я завел реестр критичных доступов. Без пафоса. Просто файл, где видно, какие аккаунты и папки важны, кто владелец, кто администратор, кто имеет запасной доступ, что делать при увольнении или смене подрядчика. Раньше это знание жило в голове у двух человек. А голова человека, как выяснилось, плохое место для хранения инфраструктуры бизнеса. Она может уйти в отпуск, заболеть или обидеться.

Отдельно я проверил уведомления. Это неожиданно важная часть порядка. У нас люди пропускали задачи не потому, что были безответственными, а потому что их уведомления превратились в белый шум. В одном чате за день могло быть 180 сообщений, из них реально рабочих для конкретного человека пять. Через пару месяцев мозг честно перестает это читать.

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

К вечеру пятницы стало видно, что неделя без новых сервисов дала странный эффект. Я не сделал ничего блестящего. Не внедрил платформу, не автоматизировал весь путь клиента, не нарисовал красивую схему будущей архитектуры. Я просто убрал часть мусора, назвал вещи своими именами и заставил старые инструменты работать чуть честнее.

Зато в понедельник следующей недели мы впервые открыли рабочую доску и не начали с вопроса, а где это лежит.

Вывод

Главный результат этой недели был не в том, что таблицы стали аккуратнее. Аккуратные таблицы сами по себе никому не нужны. Результат был в том, что мы перестали путать инструмент и процесс.

До эксперимента мне казалось, что порядок появится после внедрения нормальной системы. Теперь я думаю наоборот: если команда не умеет договариваться о статусах, владельцах, сроках, источниках данных и правилах фиксации решений, новая система просто станет дорогим контейнером для старого бардака. За семь дней я не решил все проблемы. Часть таблиц все еще страшно открывать без кофе. В некоторых задачах до сих пор встречаются названия, за которые внутренний редактор хочет бить линейкой по пальцам. В чатах иногда всплывает легендарное сделаем потом. Но теперь у нас есть способ быстро понять, где именно течет.

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