Я сел рядом с фармацевтом и почти час просто смотрел, как она работает. Данные клинических исследований, карточки пациентов, графики лечения, даты повторных визитов — всё это жило в одной гигантской таблице Excel. Прокрутка, фильтр, копировать, вставить, снова прокрутка. Каждый день. Именно тот день заставил меня собрать для этой команды нормальную CRM вместо Excel — и это оказался один из самых приятных проектов за мои десять лет в инженерии.
Таблица, на которой держалась вся исследовательская группа
Об одном про таблицы не предупреждают: они масштабируются ровно до того момента, пока не ломаются. И ломаются тихо.
В файле были сотни строк. Каждый пациент, каждый цикл лечения, каждый запланированный визит — всё в сетке, которая для этого никогда не создавалась. Фармацевты выстроили целый рабочий процесс клинических исследований поверх инструмента, придуманного для бухгалтерии.
А потом я увидел то, что и решило судьбу проекта. Она случайно затёрла строку коллеги. Не заметила. Никто не заметил — два дня. Два дня клинических данных исчезли, потому что курсор промахнулся на одну ячейку, а рядом не было ни отмены, ни истории версий, ни страховки. В исследованиях это не «неудобство». Это настоящая проблема.
Я посмотрел на эту таблицу, и внутри стало тихо. Не злость. Просто очень ясная мысль: я могу это починить.
Сначала смотреть, потом писать код
Я чуть не совершил классическую ошибку — чуть не ушёл домой строить то, что, как мне казалось, им нужно.
Вместо этого остался и продолжил наблюдать. И процесс в моей голове оказался совсем не похож на процесс на их экране. Фармацевты не мыслят компонентами и API-запросами. Они мыслят пациентами и сроками. Мне пришлось забыть собственный словарь, чтобы заговорить на их языке.
Поэтому я расписал то, что они реально делают, а не то, какой «должна быть CRM» по мнению разработчика:
- карточки пациентов, которые не исчезают молча;
- учёт лечения, который обновляется у всей команды в ту же секунду;
- планирование визитов, которое живёт в системе, а не в чьей-то голове;
- поиск и отчёты, которые отвечают на вопрос за секунды, а не за бесконечную прокрутку.
И только после этого я открыл редактор.
Стек: Vue.js и Firebase
Стек был намеренно скучным — и в этом весь смысл.
- Vue.js на фронтенде — быстрый, реактивный интерфейс, которым команде реально приятно пользоваться.
- Firebase на бэкенде, где всю тяжёлую работу делает real-time база данных.
Именно real-time тихо убил главную боль. Когда один фармацевт менял запись о лечении, все остальные видели это мгновенно. Больше никакой пересылки «последней версии» файла по почте. Больше никаких двух копий, где кто-то случайно «побеждает».
А под капотом — самые неромантичные основы: аутентификация, CRUD, поиск, отчёты. Ничего для слайда на конференции. Всё, что реально нужно бизнесу.
Результат: на 40% быстрее, ноль потерянных записей
Цифры пришли быстро, как только таблица исчезла:
- Время обработки упало на 40%. Не потому что фармацевты вдруг стали быстрее, а потому что система перестала их тормозить.
- Около двух часов в день ручного ввода данных просто испарились.
- Ноль потерянных записей. Целый класс катастроф «случайно затёр строку» перестал существовать.
- Процесс стал на 100% цифровым. Таблицу не улучшили. Её просто не стало.
Последняя строчка важнее, чем кажется. Я не собрал таблицу получше. Я убрал процесс, из-за которого таблица вообще казалась необходимой.
Разница между разработчиком и инженером
Vue и Firebase — всего лишь инструменты. Я мог взять с десяток других стеков и прийти к тому же результату. Настоящая работа началась там, где я сел, замолчал и стал смотреть, как людям тяжело, — а потом собрал то, что сделало их день по-настоящему лучше.
Если сжать весь проект в три правила:
- Поговори с пользователями до первой строки кода. Их настоящая боль никогда не там, где ты её себе придумал.
- Меняй процесс, а не только инструмент. Быстрая таблица — всё ещё таблица.
- Меряй результат в сэкономленном человеческом времени. 40% и два часа в день что-то значат для человека. Строки кода — нет.
Для меня именно здесь и проходит граница между разработчиком и инженером. Разработчик выкатывает фичу. Инженер меняет то, как люди работают.
Прямо сейчас где-то в вашей компании кто-то ведёт критически важные данные в таблице. Он не жалуется. Он перестал жаловаться годы назад и просто смирился. Найдите этого человека. Соберите этот инструмент. Вы не просто напишете код — вы измените то, как он работает.