Серия «IT, как оно есть»

Есть одна штука, которую я заметил не только в IT, а вообще в жизни.

Когда что-то пошло не так, людям почти никогда не нужна “победа”. Им нужна нормальная человеческая опора. Чтобы не чувствовать себя идиотом, которого тихо развели, а потом ещё и сделали виноватым.

И вот тут появляется вечный спор. Что важнее, когда сервис облажался: компенсация или честность?

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

Почему так?

Потому что мозг ненавидит неопределённость. Не саму проблему, а ощущение, что ты не понимаешь, что происходит.

Представьте бытовую ситуацию, вы ждёте доставку, а срок уже прошёл. И вам пишут: “извините за неудобства”. И ВСЁ! Никакой информации. Никакого плана. Никакого понимания.

В этот момент у вас в голове начинается кино…
“Они меня игнорят.”
“Они потеряли заказ.”
“Они просто тянут.”
“Они сейчас скажут, что я сам виноват.”

И раздражение растёт не потому, что задержка. А потому что вы в подвешенном состоянии. В так называемой неопределенности.

Теперь другая версия, вам пишут: “Да, задержка. Курьер поехал не туда, мы пересобираем маршрут. Новый срок — в 19:40. Если не успеем — вернём деньги автоматически.”

С точки зрения результата это всё ещё неприятно. Но психологически это в разы спокойнее. Потому что у вас есть три вещи: понятная причина, понятный срок и понятный сценарий “если не получилось”. В таких ситуациях важно помнить, все ошибаются, мы же люди ;)

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

Но есть ГРАНИЦА.

Когда человек реально потерял ресурс, честности становится недостаточно. Потому что извинение не возвращает: время, деньги, возможность и нервы.

Если из-за сбоя вы опоздали на рейс, сорвали встречу, потеряли заказ, зависли в важном процессе, то “мы честно признали” уже не звучит как забота. Это звучит как: “ну да, бывает”.

И вот тут компенсация становится не подарком, а признанием ущерба.

Люди хотят не “плюшку”. Люди хотят справедливость. Чтобы в мире снова стало ровно. Чтобы было ощущение: “да, меня не бросили”.

Но есть ещё одна коварная вещь. Компенсация может не просто не успокоить, а разозлить ещё сильнее.

Когда до неё было:
молчание,
шаблонные ответы,
перекладывание вины,
“сам виноват”,
или попытка сделать вид, что проблемы нет.

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

Поэтому если говорить честно, правильная формула почти всегда такая:

Сначала — честность.
Потом — действие.
И только потом — компенсация.

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

Самый быстрый способ: признать проблему без оправданий и сказать, что вы делаете сейчас, дать понятный срок и обозначить, что будет, если срок сорвётся.

Люди могут простить многое. Но они почти никогда не прощают ощущение, что их держат за дураков.

И вот здесь для нас важно сказать одну вещь, уже в контексте благотворительности. В помощи неопределённость бьёт ещё сильнее. Потому что ты не просто “ждёшь доставку”. Ты помог. Ты вовлёкся. Ты следишь. И если что-то пошло не так, самое неприятное это не сама ошибка, а тишина… Когда человек остаётся в неведении: дошло или не дошло, помогло или не помогло, что сейчас происходит, почему задержка, кто вообще отвечает. И в этот момент мозг начинает додумывать худшее, и это убивает доверие к помощи в целом.

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

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

Поэтому сейчас мы как раз и думаем над механизмами, которые будут снимать это напряжение: чтобы донор не оставался один на один с тишиной, чтобы были понятные обновления, понятные сроки и понятная ответственность. Не потому что все обязаны быть идеальными, а потому что уважение к человеку начинается с ясности.

Есть жизненная ситуация, в которую попадал почти каждый взрослый человек. У тебя есть задача, которая для тебя ВАЖНА. Она влияет на планы, деньги, нервы, семью и парой на работу. А делает её другой человек или другая сторона. И в этот момент случается самое неприятное.

Для тебя это приоритет.
А для них это “одна из множества задач”.

И вот оно, чувство, которое сложно признать: зависимость от кого-то. Ты можешь быть самым компетентным, самым собранным, самым ответственным. Можешь всё сделать идеально со своей стороны, но итог всё равно не в твоих руках.

В жизни это просто всюду.
Ты ждёшь ответ от человека, который “подумает завтра”.
Ты ждёшь документ, который “уже почти готов”.
Ты ждёшь решение, которое формально простое, но почему-то тянется бесконечно.

И самое обидное даже не в том, что медленно. А в том, что ты не можешь ускорить это силой. Ты можешь попросить, можешь напомнить, можешь быть вежливым или даже жёстким. Но если это не их приоритет, твой срок превращается в их “как получится”.

И вот здесь появляется парадокс. Результат ждут от тебя. Даже если 90% этого результата зависит не от тебя. В предпринимательстве и в стартапах ровно то же самое, только масштабы и ставки другие.

Ты можешь сделать свою часть за полдня (реально быстро).
Но дальше начинается мир зависимостей:

• Одобрение в Apple Store;

• Проверка в Google Play;

• Модерации, внешние сервисы, подрядчики;

• Интеграции, где “маленькая правка” занимает дни;

• Компании, которые отвечают по своим регламентам и живут в своих приоритетах.

И вот тут есть жесткая правда: пользователь не будет разбираться, кто именно затормозил. Он не откроет карту зависимостей. Он не будет читать, что “мы ждём согласование”. Он увидит только итог. И этот итог для него — работает или нет.

Поэтому часть работы в стартапе — это не только “сделать”. Это управлять тем, что ты не контролируешь. И когда ты это понимаешь, меняется отношение к планированию. Оно становится системой, где ты заранее признаёшь: часть мира будет тормозить, и это нормально. Не потому что все плохие. А потому что так устроены процессы, компании, регламенты и человеческая природа.

И тут есть одна штука, которую редко проговаривают, но она очень практичная.

Иногда умнее не “ускорять” то, что не ускоряется, а не стоять в ожидании. Если ты знаешь, что зависимость не в твоих руках, у тебя остаётся два выбора:

• Первый — злиться и смотреть на часы.

• Второй — параллелить.

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

Жаль, что запараллелить получается не всегда. Но когда получается — это реально спасает психику. Потому что ожидание убивает не временем. Оно убивает ощущением бессилия.

И вот самый “взрослый” вывод, который я лично для себя вынес.

Если ты строишь планы так, будто всё зависит от тебя, реальность будет постоянно тебя ломать. Если ты строишь планы, учитывая зависимость от других, ты не становишься слабее, ТЫ становишься устойчивее.

Закладывать буфер — это не трусость.
Иметь план Б — это не паника.
Делать параллельно — это не суета.
Это уважение к тому, как устроен мир.

И да, это неприятно. Потому что хочется справедливости: “я сделал свою часть, значит всё должно идти дальше”. Но взрослость, как будто, начинается там, где ты признаёшь: мир не обязан идти по твоему дедлайну. Даже если ты прав.

Вопрос только в том, научишься ли ты жить в этой системе так, чтобы она не съедала тебя.

А теперь вопрос, который мне реально интересен. Только ответь честно, пожалуйста, я для себя хочу понять, правильно ли я мыслю.

Что бесит сильнее: когда ты облажался сам или когда всё слетело из-за другого, а объяснять и отдуваться всё равно тебе?

Фраза “сделайте как у больших” звучит логично! Пользователь привык к банковским приложениям, маркетплейсам и другим крупным сервисам. Там всё быстро, аккуратно, предсказуемо. Кажется, что самый короткий путь к качеству это повторить их решения ;)

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

Контекст на входе, это про то, в каком состоянии человек вообще читает ваш интерфейс. Большому бренду доверяют по умолчанию: “там всё должно быть нормально”. В новом сервисе, особенно если есть платежная система или чувствительные данные, пользователь чаще начинает с настороженности. Один и тот же паттерн может восприниматься противоположно. В привычном сервисе “два клика и готово” считывается как удобство. В неизвестном сервисе это иногда считывается как “слишком легко, значит опасно”. Контекст решает, как человек интерпретирует даже идеальный дизайн.

Лишняя сложность, у крупных продуктов много задач, много сегментов, много исключений. Поэтому в интерфейсе появляются слои: дополнительные разделы, сложные фильтры, глубокая навигация, многочисленные статусы. Стартапу на старте обычно нужна обратная вещь: один ключевой сценарий, минимальное количество развилок и ясная логика. Когда мы копируем форму большого продукта, мы часто тащим не “качество”, а перегруз. Пользователь путается, команда тратит время на “обвес”, что неэффективно :│

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

Внешняя "дороговизна" держится на инфраструктуре. Плавность, скорость, “идеально всё работает”, умные подсказки и рекомендации, стабильные релизы это не только дизайн. Это архитектура, мониторинг, тестирование, процессы выпуска, безопасность, поддержка. Если копировать внешний вид без внутренней базы, возникает эффект витрины. Витрина обещает уровень, который продукт пока не подтверждает. А несоответствие ожиданий в приложениях наказывается жёстко: пользователь не разбирается, почему это случилось. Он просто уходит ;(

Стратегия и “дизайн наперёд”, вы не знаете, зачем у крупных приложений кнопка стоит именно там. Большие компании часто строят интерфейс не только под “сегодня”, но и под “завтра”. Они заранее оставляют место под будущие разделы, под вторую кнопку, под изменение сценария, под новую механику, которая появится через квартал. Иногда элемент интерфейса кажется странным, пока не понимаешь, что в будущем он станет частью более крупной структуры. Вы можете скопировать расположение и логику, которые у них оправданы будущим развитием, а у вас этого будущего в продуктовой логике просто нет. В итоге пользователь получает не “как у больших”, а “как будто кто-то расставил элементы без причины”.

Потеря идентичности, когда продукт похож на всех, его сложнее запомнить. Стартапу важно быть узнаваемым. Не ради красоты. Ради ясности: кто вы, зачем вы, почему вы существуете, почему вам можно доверять. Если интерфейс собран из чужих решений, продукт выглядит как копия. Особенно в сферах, где важна ответственность и прозрачность, ощущение “слишком похоже, но непонятно кто за этим стоит” может стать критичным.

Поэтому мы для себя сформулировали простой принцип. Копировать можно, но копировать нужно не пиксели, а принципы!

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

И по-хорошему начинать надо не с “давайте скопируем экран”, а с построения своего пользовательского сценария. Как человек вообще приходит в продукт.

Есть фраза, которую я всё чаще слышу, и она звучит очень уверенно: “ИИ ошибается реже человека. Значит, давайте доверим ему решения”. Тут важный вопрос, лучше эксперта или среднестатистического человека, который не разбирается в конкретном вопросе? И я понимаю, почему людям нравится эта идея. Она обещает простоту. Убираем человеческий фактор. Ставим систему, которая “по цифрам” работает лучше, и всё.

Но реальность, как обычно, сложнее. Потому что слово “доверить” — оно не про точность, а про ответственность. Я бы начал с честного: ИИ действительно иногда стоит доверять больше, чем человеку, но в конкретных типах задач.

Где ИИ реально сильнее человека по опыту нашей команды (всё же мы сами разрабатываем несколько ИИ под свои задачи):

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

Ещё один сильный сценарий — когда у тебя огромный объём данных, а тебе нужно вытащить из него главное. Не “прочитать всё”, а выудить основные моменты: что важно, где риски, какие есть аргументы, что упущено, какие вопросы стоит задать, чтобы не сделать глупый выбор. Иногда ИИ реально помогает даже на уровне “подскажи, какие факторы я не учёл”. Но опять же, он не принимает решение за тебя. Он помогает тебе быстрее подойти к моменту, когда ты можешь принять решение сам.

И, наверное, самое практичное (по нашему мнению) — это черновая и повторяющаяся работа. Там, где процессов много, они стандартные, и в них не должно быть исключений. Там, где всё одинаково, и именно поэтому человек начинает уставать, пропускать мелочи, и у него замыливается глаз. Вот здесь ИИ идеален: как уверенный исполнитель стандартных процедур. Он не “вдохновляется” и не “проваливается” в усталость. Он стабильно делает одинаковое одинаковым. А человеку остаётся то, что человеку нужнее: контроль, смысл и ответственность.

ВАЖНО! Ни в коем случае не отдавайте ИИ работу в той области, в которой вы сами не разбираетесь. Потому что он может наделать ошибок уверенно и красиво, и самое обидное: даже если вы “проверяете”, не факт, что вы вообще поймёте, что ошибка там есть. Проверка работает только тогда, когда у проверяющего есть компетенция. ИИ — это классно, это круто, он реально ускоряет и облегчает, но ведущая роль всё равно должна оставаться за человеком. Это инструмент, а не замена мышления. Если начать доверять ему больше, чем себе и людям, смысл человеческого участия теряется: мы должны не деградировать, а становиться умнее. ИИ должен ускорять процессы и освобождать голову для более сложных задач, а не создавать ситуацию, где мы перестаём учиться и постепенно отказываемся думать.

Есть ощущение, что делать IT-продукты стало проще (всеобщая реклама курсов создала образ простоты входа в IT): открыл ноутбук, собрал команду, запустил приложение. Но если говорить именно про приложения для смартфонов как про продукт, то вход туда сегодня один из самых жёстких. Не потому, что «всё уже занято», а потому, что у пользователей давно сформировалась планка качества, и она выросла не постепенно, а резко. Мы живём в мире, где почти каждый день человек пользуется лучшими продуктами: банковскими приложениями, маркетплейсами, навигацией, крупными соцсетями. И это не «просто приложения», а годы опыта, огромные бюджеты, инфраструктура и команды, где каждый отвечает за свой кусок качества.

Пользователь редко задумывается, какая команда стоит за конкретным приложением. Он не различает «сделано корпорацией» и «сделано стартапом из пяти человек». Он сравнивает по ощущению. Если работает быстро, не лагает, понятно устроено, не пугает — значит, «нормально». Если тормозит, выглядит криво, где-то непредсказуемо себя ведёт — значит, «плохое». И чаще всего это даже не эмоциональная придирка, а здравый механизм самозащиты. Медленное и неровное приложение кажется небезопасным. Особенно если внутри есть деньги, данные, документы, любая чувствительная информация (хотя чувствительные данные чаще всего находятся на стороне крупных сервисов помощи, которые помогают стартапам не хранить критически важные данные у себя).

И вот здесь появляется главный парадокс. С одной стороны, войти в создание приложений стало проще с точки зрения обучения, насмотренности и инструментария. Можно смотреть на лучшие сервисы, учиться интерфейсам, логике, сценариям и фишкам. Можно брать примеры того, как устроены экраны, навигация, тексты, подсказки. Это в первую очередь относится к frontend (фронтенд, то есть «внешняя часть» приложения, которую видит пользователь, экраны, кнопки, интерфейс, анимации, визуальная логика). С этой стороны рынок даже помогает новичкам: лидеры задают стандарты, и ты видишь, что «нормально» и «удобно» в 2026 году.

Но с другой стороны, есть backend (бэкенд, то есть «внутренняя часть» продукта: серверы, база данных, логика обработки запросов, безопасность, интеграции, платежи, уведомления, права доступа). И вот этим мало кто делится, потому что именно там спрятана главная сложность. Там не видно ошибок сразу, но именно там рождаются самые болезненные проблемы в разработке: падения, потери данных, некорректные статусы, странные списания, задержки, дубли, рассинхроны. И пользователь, если он столкнулся с таким один раз, редко даёт второй шанс. Он не будет читать, что «мы маленькая команда, и это MVP» (минимально жизнеспособный продукт, который закрывает потребности пользователя без траты лишних средств и используется для тестирования жизнеспособности продукта). Он просто уйдёт туда, где уже «как надо».

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

И именно поэтому входные барьеры такие высокие. Ты конкурируешь не с «другими стартапами». Ты конкурируешь с ощущением нормы, которое создают крупные компании. Даже если ты делаешь уникальную идею, пользователь будет воспринимать её через призму привычных стандартов: «работает ли так же гладко, как мой банк», «насколько тут всё понятно, как в маркетплейсе», «не раздражает ли меня это, как раздражают плохие сервисы». Никакой скидки на размер команды в голове у человека нет. Это неприятная правда для тех, кто захочет начать свою разработку приложений.

При этом у этих барьеров есть и позитивная сторона. Они заставляют команду взрослеть быстрее. Продуктовое мышление растёт, потому что приходится смотреть на лидеров рынка и постоянно задавать себе вопрос: «какую планку мы реально должны выдержать, чтобы нас воспринимали всерьёз». У менеджмента расширяется кругозор, потому что приходится понимать связь между «мелкой правкой» и «ощущением качества». У разработчиков повышается внутренняя требовательность: стандарты тестирования, контроль ошибок, подход к скорости, к интерфейсу, к деталям. И да, это тяжело. Но это делает сильнее.

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

Есть миф: “Ну вы же тестировали. Значит, багов быть не должно”. Мы бы тоже хотели жить в этом мире. Но реальность разработки такая, тесты ловят многое, но не ловят всё. Особенно в стартапе, где команда небольшая, а приложение должно работать у людей на тысячах разных устройств и в сотнях разных сценариев.

Какие бывают баги? Самые понятные — “грубые”, кнопка не нажимается, экран не открывается, платеж не проходит. Их обычно видно практически сразу. Но самые неприятные те, которые появляются редко и “по настроению”. Например:

• баг проявляется только на старом Android, а на новых всё идеально;

• всё ломается только при плохом интернете, когда связь то появляется, то пропадает;

• ошибка случается, если человек сделал действия в необычном порядке;

• баг возникает в момент, когда на сервер одновременно пришло много запросов;

• “что-то пропало”, потому что в одном месте обновилось, а в другом не успело.

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

И дальше начинается настоящая работа, которую пользователь не видит. Мы пытаемся воспроизвести баг (и ловить его по логам), если о нем узнали, но не поняли когда точно и при каких обстоятельствах он случился. Потому что пока он не воспроизведён, он как призрак: “вроде был, но где неизвестно”. Обычно мы начинаем с простого, что делал человек, на каком устройстве, в каком месте приложения, был ли интернет, обновлялось ли приложение, происходило ли что-то параллельно. Потом пробуем повторить шаги один в один. Если не получается, то усложняем условия: слабее интернет, другой телефон, другой порядок действий, другие настройки.

Часто баги всплывают только тогда, когда появляется реальная база пользователей. И это нормально: тысяча людей (хотели бы мы такой онлайн ;) )за день создаёт больше уникальных комбинаций действий, чем небольшая команда тестировщиков за неделю. Пользователь делает то, что разработчик никогда бы не придумал: закрывает приложение на середине, разворачивает телефон, кликает быстрее, чем мы успеваем моргнуть, уходит в метро, возвращается через час и ждёт, что всё продолжится “как было”. Самое крутое в большом количестве пользователей — среди них всегда есть достаточно неравнодушных, чтобы быстро находить баги. Они часто пишут, где и когда столкнулись с ошибкой (дают точные данные, в каких логах искать), и это сильно упрощает их исправление.

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

P. S. Баг (англ. bug — «жук») — это термин, который используется в программировании и означает ошибку в программе

Если смотреть со стороны, многие приложения кажутся до смешного простыми. Открыл, нажал кнопку, что-то заполнил, что-то отправил – всё. «Ну что там делать, пять экранов и одна форма, господи». И это нормальная реакция обычного пользователя. Но внутри команды программистов ты очень быстро узнаёшь правду: чем проще выглядит приложение снаружи, тем, скорее всего, сложнее оно устроено изнутри. Особенно, если оно не просто «крутится», а стабильно работает, держит нагрузку, не теряет данные и умеет адекватно развиваться. Вот там начинается мир, о котором большинство вообще никогда не задумывается, – мир бэкенда.

Что такое бэкенд по-человечески?

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

За одной кнопкой «Отправить» может стоять:

сервер, который принимает запрос;

очередь, в которой этот запрос ждёт своей обработки;

сервис, который проверяет корректность данных;

база, где это всё записывается;

отдельный сервис, который шлёт уведомление;

ещё один, который пишет в лог, что именно произошло.

Пользователь видит только экран «сработало» или «не сработало». Всё остальное существует где-то в тени: очереди, логи (записи о том, что происходило в системе в конкретный момент) и т.д. Любое мало-мальски серьёзное приложение живёт на очередях. Например, человек отправил пожертвование, а у вас в этот момент одновременно ещё сотни людей что-то делают в приложении. Всё это нельзя обрабатывать в лоб, иначе в какой-то момент всё подвиснет намертво. Поэтому запросы выстраиваются в очереди: сначала одно действие, потом другое, где-то параллельно, где-то последовательно. Для пользователя «всё работает» или «ничего не работает». Для бэкендера между этими двумя состояниями тысячи вариантов.

Если нет грамотного логирования, все эти ситуации превращаются в одну правду: «у меня ничего не работает, исправьте». Хороший бэкенд – это когда за каждой такой фразой можно найти конкретный запрос, конкретную ошибку.

Почему «простое приложение» не значит «простая работа»?

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

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

Да, это иногда обидно. Вы горбатились месяц, сделали сервис устойчивее, быстрее, более масштабируемым, а пользователю кажется: «Ну они просто сидели и думали». Но есть и плюс, причём очень серьёзный.

Во-первых, скорость развития. Парадоксально, но чем больше времени потрачено на нормальный фундамент, тем быстрее потом можно добавлять «простые функции». Если бэкенд кривой, любая новая задача превращается в мини-ремонт с проводкой.

Во-вторых, масштабируемость. Сегодня у тебя тысяча пользователей, завтра десять тысяч, через год сто (ПОЖАЛУЙСТА, мы бы были рады такому). Если бэкенд к этому не готов, приложение начинает «сыпаться» при первой же серьёзной нагрузке. Хороший бэкенд – это запас по прочности, который никто не видит, пока он не понадобится.

В-третьих, предсказуемость. Когда у тебя настроены логи, мониторинг, ты знаешь, что если что-то пойдёт не так, ты хотя бы поймёшь, где искать.

И, наконец, доверие. Пользователь может не знать, что у вас там с очередями и архитектурой, но он очень хорошо чувствует другое: «здесь всё стабильно» или «здесь всё время что-то ломается».

Почему про бэкенд почти никто не думает?

Пользователю это не нужно – и это нормально. Его задача – решить свою проблему в приложении. Всё остальное – ваша ответственность. Но внутри команды полезно иногда честно признавать: «Да, есть огромный кусок работы, который никто никогда не похвалит в лоб». Никто не напишет: «Спасибо, что у вас такие классные очереди и структурированные логи». Максимум скажут: «Спасибо, что всё работает».

Хороший бэкенд тем и отличается, что о нём не думают. Пока всё стабильно, всем кажется, что это «само собой разумеется». И только когда что-то с ним случается, внезапно становится видно, насколько он был важен. На самом деле это сердце приложения. Его не видно на экране, о нём не пишут в рекламных заголовках, но именно от него зависит, будет ли всё это жить, расти и выдерживать реальную жизнь.

P.S. У нас очень крутой бэкендер, поддержите его работу своей активностью, это моя личная просьба ;)