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

Таблица, на которой держалась вся исследовательская группа

Об одном про таблицы не предупреждают: они масштабируются ровно до того момента, пока не ломаются. И ломаются тихо.

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

А потом я увидел то, что и решило судьбу проекта. Она случайно затёрла строку коллеги. Не заметила. Никто не заметил — два дня. Два дня клинических данных исчезли, потому что курсор промахнулся на одну ячейку, а рядом не было ни отмены, ни истории версий, ни страховки. В исследованиях это не «неудобство». Это настоящая проблема.

Я посмотрел на эту таблицу, и внутри стало тихо. Не злость. Просто очень ясная мысль: я могу это починить.

Сначала смотреть, потом писать код

Я чуть не совершил классическую ошибку — чуть не ушёл домой строить то, что, как мне казалось, им нужно.

Вместо этого остался и продолжил наблюдать. И процесс в моей голове оказался совсем не похож на процесс на их экране. Фармацевты не мыслят компонентами и API-запросами. Они мыслят пациентами и сроками. Мне пришлось забыть собственный словарь, чтобы заговорить на их языке.

Поэтому я расписал то, что они реально делают, а не то, какой «должна быть CRM» по мнению разработчика:

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

И только после этого я открыл редактор.

Стек: Vue.js и Firebase

Стек был намеренно скучным — и в этом весь смысл.

  • Vue.js на фронтенде — быстрый, реактивный интерфейс, которым команде реально приятно пользоваться.
  • Firebase на бэкенде, где всю тяжёлую работу делает real-time база данных.

Именно real-time тихо убил главную боль. Когда один фармацевт менял запись о лечении, все остальные видели это мгновенно. Больше никакой пересылки «последней версии» файла по почте. Больше никаких двух копий, где кто-то случайно «побеждает».

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

Результат: на 40% быстрее, ноль потерянных записей

Цифры пришли быстро, как только таблица исчезла:

  • Время обработки упало на 40%. Не потому что фармацевты вдруг стали быстрее, а потому что система перестала их тормозить.
  • Около двух часов в день ручного ввода данных просто испарились.
  • Ноль потерянных записей. Целый класс катастроф «случайно затёр строку» перестал существовать.
  • Процесс стал на 100% цифровым. Таблицу не улучшили. Её просто не стало.

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

Разница между разработчиком и инженером

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

Если сжать весь проект в три правила:

  • Поговори с пользователями до первой строки кода. Их настоящая боль никогда не там, где ты её себе придумал.
  • Меняй процесс, а не только инструмент. Быстрая таблица — всё ещё таблица.
  • Меряй результат в сэкономленном человеческом времени. 40% и два часа в день что-то значат для человека. Строки кода — нет.

Для меня именно здесь и проходит граница между разработчиком и инженером. Разработчик выкатывает фичу. Инженер меняет то, как люди работают.

Прямо сейчас где-то в вашей компании кто-то ведёт критически важные данные в таблице. Он не жалуется. Он перестал жаловаться годы назад и просто смирился. Найдите этого человека. Соберите этот инструмент. Вы не просто напишете код — вы измените то, как он работает.