Дорогие вы мои… решения Говорят, что не ошибается только тот, кто ничего не делает. Вот и в нашей практике встречались не самые удачные решения. О самых «дорогих» из них рассказывает Оксана Новицкая, директор по развитию Облакотеки. Читайте, как делать не надо ⬇️ ⏪ Есть решения, которые в моменте выглядят абсолютно разумными. Команда соглашается, сроки горят, ресурсы ограничены, и мы бежим внедрять. А через год-другой именно эти «рациональные» шаги обходятся нам дороже всего. Причем платим мы еще и временем, нервами, замедлением развития сервиса и полной потерей гибкости. В какие ловушки мы уже попадали? 1️⃣ «Это временно» Пожалуй, это самая дорогая фраза в построении сервисов. Когда-то и мы решили, что сейчас важнее скорость. Упростили модель, сознательно пошли на архитектурные компромиссы. Думали, что потом перепишем. Звучало рационально, но со временем сервис вырос, появились крупные клиенты и критичные интеграции. Тут пришло понимание, что это стало фундаментом. А что дальше делать-то? Переписывать? Трогать код страшновато: слишком много зависимостей и высокий риск все поломать. Переписать все заново — долго и дорого, поэтому приходится дописывать уже к тому, что есть. Все это замедляет каждое решение и делает любую инициативу тяжелее вдвое. 2️⃣ Размытая оргструктура Пока команда маленькая, границы ответственности не так уж важны. Все решения принимаются и согласовываются на лету. Потом сервис растет, людей становится больше, и уже не совсем понятно, кто и за что отвечает. Типичный вопрос: «Кто инициирует переработку кода — продукт или платформа?» Это результат жизни в режиме «по ходу дела разберемся». В итоге в коллективе появляются напряжение и скрытые конфликты. Теперь приходится считаться с тем, что организационная архитектура так же важна, как техническая. 3️⃣ Желание сделать универсальное решение Хочется ведь, чтобы подходило всем: большим клиентам и маленьким, опытным инженерам и новичкам. Мы добавляли настройки, расширяли сценарии, дорабатывали возможности под редкие кейсы. Сервис становился все более сложным. В итоге интерфейс перегружен, документация разрастается, а большинство пользователей используют минимум возможностей. Вот в чем парадокс: чем универсальнее продукт, тем выше порог входа. А потом техподдержку и базу знаний приходится использовать как навигатор по собственному сервису 😀. 4️⃣ «Технари сами во всем разберутся» Мы думали, что наша техническая аудитория поймет все без подсказок. На практике оказалось иначе. Интерфейс нашего сервиса довольно нагруженный, с не самым свежим дизайном и множеством технических терминов. Даже партнеры с хорошим бэкграундом теряются при простых действиях: скажем, не сразу понимают, как получить IP для машины. Результат — тикеты в поддержку, ожидание ответа, вовлеченность сотрудников первой и второй линии. В сумме на обработку одного запроса уходит час или больше. То есть плохой UX в техническом сервисе напрямую влияет на надежность процессов и операционные затраты, а не только на визуальное впечатление. Простой и понятный интерфейс для аудитории помог бы избежать большинства таких обращений и сэкономить время команды. Мы не были наивными, а лишь пытались балансировать и искать компромиссы. Как выяснилось — строить облака без ошибок невозможно. Но можно раньше замечать, когда временное становится вечным. А какое ваше самое «дорогое» решение за последние пару лет? Делитесь в комментариях, устроим сеанс коллективной терапии ⬇️. #Оксана_объясни