{"id":14284,"url":"\/distributions\/14284\/click?bit=1&hash=82a231c769d1e10ea56c30ae286f090fbb4a445600cfa9e05037db7a74b1dda9","title":"\u041f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0444\u0438\u043d\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0442\u0430\u043d\u0446\u044b \u0441 \u0441\u043e\u0431\u0430\u043a\u0430\u043c\u0438","buttonText":"","imageUuid":""}

На каких слонах стоит Evrone?

Вспоминая проекты, которыми мы занимались на самом старте Evrone, мы часто задаёмся вопросом — а как они повлияли на нас? Какой опыт мы вынесли и как используем его сейчас? Сегодня расскажем про три принципа, которые мы пронесли с первого дня основания до настоящего момента.

Честность и открытость по отношению к клиенту

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

Мы делаем это не потому, что хотим казаться экспертами, а из-за того, что хорошо понимаем и бизнес, и разработчиков.

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

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

И если для этого требуется честно сказать клиенту, что он собирается наступить на грабли, мы это сделаем.

Баланс между надёжностью и готовностью к экспериментам

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

Конечно, подобные вещи достаточно быстро отлавливаются и исправляются. Но зачем исправлять чужие ошибки, если можно их избежать?

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

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

Полная прозрачность процессов

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

Мы уверены, что хороший сервис — это когда клиент всё время в курсе происходящего. У него просто не должно возникать вопроса «а всё ли в порядке?». Именно поэтому ему доступно столько инструментов отчётности.

Кроме спокойствия, клиент получает ещё и технологический консалтинг — каждую задачу мы объясняем и разбираем, если это требуется. Всё-таки наши клиенты — эксперты в своём продукте, но не обязательно в IT. Как, например, основатели Depst, которые пришли к нам с дизайн-макетами и идеями, которые мы должны были бережно перенести на технологическую платформу.

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

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

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

0
Комментарии
-3 комментариев
Раскрывать всегда