#статьи

VPN – это безопасно?
Делимся комментариями нашего руководителя направления IT Support Максима Закамскова для онлайн-журнала CHIP.

Правда ли, что VPN-сервисы продают трафик третьим лицам?
В соглашении с пользователем (EULA) сервис, как правило, указывает, какие данные он собирает и с какой целью использует. Например, ExpressVPN пишет, что не собирает и не регистрирует историю просмотров, направление трафика, содержание данных или DNS-запросы подписчиков, подключенных к VPN. Но во время регистрации могут собирать некоторую личную информацию, например, адрес электронной почты и платежную информацию, т.е. то, что необходимо для предоставления услуги.

Есть ли разница между бесплатными и платным VPN с точки зрения безопасности?
Разница между бесплатным и платным VPN может быть незначительной. Как правило, платный VPN предоставляет больший объем трафика и скорость подключения. Что касается безопасности, то ее может и не быть. При этом важно помнить, что приложения для VPN могут запрашивать самые разные разрешения в мобильном устройстве, например, доступ к звонкам/контактам/местоположению и прочие данные, и отказываться работать без их предоставления. Это может создать опасность утечки.

Насколько безопасно пользоваться банковскими приложениями, вводить пароли на других сайтах и в приложениях во время использования VPN?
С одной стороны, может показаться, что это безопасно, поскольку трафик между банковским приложением и информационной системой банка зашифрован отдельно. Но при использовании VPN нужно понимать, что в данном случае появляется дополнительный посредник в передаче трафика. Он может воспользоваться фактом прохождения «интересных данных» и попытаться провести атаку на них.


Чтобы ознакомиться с полной статьей, а также ответами специалистов из VK, REG.ru и других компаний, жмите на кнопку 👇

🧐А вы пользуетесь VPN?

#статьи #кейсы

Мы подготовили серию статей о зарубежном проекте, который ведем уже более 9 лет. Здесь будем публиковать резюме и прикреплять ссылку на полный материал, если вы захотите узнать подробности 💙

Почему добавление процессов и инструкций на проекте может быть эффективнее новых фич или технологий

Часть 1. Предыстория
Уже 9 лет мы сотрудничаем с клиентом из Великобритании, который предоставляет ПО для госпиталей. Система обеспечивает ряд шагов бизнес-процесса. Общий программный комплекс состоит из 8 подпроектов. Алексей – наш программист – отвечает за 2 подпроекта и различные интеграции с другими.
На старте на разработку и саппорт накладывало свой отпечаток то, что мы «унаследовали» систему после нескольких предыдущих команд с разными подходами к организации работы. При этом саппорт состоял из трех линий:
1️⃣ Команда поддержки на телефоне и в чатах на стороне Великобритании: клиент создает задачу в Jira на доработку.
2️⃣ Технические специалисты на стороне клиента. Задача второй линии – провести исследование на боевом сервере, понять, что не так, суть ошибки и что надо сделать, чтобы улучшить ситуацию.
3️⃣ Наша команда. Задача третьей линии – реализовать кодовое изменение и сделать деплой улучшения на сервер.

Однажды глава третьей линии саппорта сообщил, что через пару месяцев покидает свою должность. После обсуждения было принято решение передать руководство нашему коллеге – Алексею.
На тот момент он работал с системой уже 7 лет и хорошо знал её особенности:
🔹 участвовал в разработке многих компонентов,
🔹 познакомился с профилированием производительности, использованием памяти диска, работой с базами данных,
🔹 изучил технологии LINQ (проект очень длительный, и в то время это была самая современная технология), Entity Framework, Dapper и многие другие вещи.
Нужно было срочно – за 6 недель – разобраться в подводных камнях, принимая проект от бывшего ведущего «саппортовца».

Завтра мы опубликуем вторую часть этой истории и расскажем, что предприняла наша команда, чтобы сократить время фикса проблем с 2–4 часов до 1 минуты. Уже сейчас вы можете прочитать полную статью в прикрепленной ссылке.

#статьи #кейсы

Значение процессов и инструкций на проекте

Начало истории в предыдущем посте.

Часть 2. Что мы сделали
Перед нами стояла задача быстро разобраться в подводных камнях поддержки масштабного проекта – более 100.000 строк C#. Это был сложный челлендж!
Итак, что мы делали:
1️⃣ Поняли, что мы постоянно имеем дело с внушительным объемом запросов от пользователей на саппорт и нужно что-то менять. Теперь при их выполнении собирали статистику по типам и частоте запросов.
2️⃣ Закрыли устаревшие задачи, которые были созданы более 2 месяцев назад. Вместе с тем нашли 30-40 задач без метки саппорта: выбрали их из треда «без метки», добавили метку – иначе они не отображались в задачах саппорта.
3️⃣ Нашли первое место для улучшения: сделали отдельный проект в Jira. До этого задачи саппорта создавались в том же проекте, что и задачи для разработки, но с пометкой Support.
4️⃣ Обновили админки во всех госпиталях до единой версии, так как она стала средством доставки фиксов. Сама админка не участвовала в бизнес-процессах, только настраивала их, поэтому можно было обновить все админки до последних версий.
5️⃣ На основании собранной статистики поняли: нужно временно начать перерабатывать, чтобы впоследствии ускорить работу. Иногда для ускорения каких-либо действий саппорта в таких длительных проектах нужно 3-4 часа программировать, чтобы потом сэкономить 5–7 минут при изучении определенных типов запросов, в первую очередь повторяющихся.
6️⃣ Создали специальную страницу-саппорт с инструкциями и готовыми кнопками: «Как фиксить различные классы проблем в админке». В итоге время фикса некоторых классов проблем сократилось с 2–4 часов до 1 минуты. Причем за 3 месяца по этому алгоритму не удалось исправить только один-единственный (!) баг.

Результаты
Самый главный результат – снизилась нагрузка на саппорт c 9–10 запросов в день до одного.
Как выглядел процесс создания задачи в саппорте ранее: Завести баг в джире, слинковать с джирой заказчика, передать на обработку, подтвердить закрытие, спросить у пользователя, закрыть в джире заказчика.
Как выглядит процесс теперь: Когда пользователь позвонил, сразу ввести номер пациента, нажать готовую кнопку для исправления бага, спросить пользователя о результатах.
➡️Это позволило 99% запросов исправлять за 1 минуту, и это могла делать первая линия саппорта. А после обновлений до последних версий многие баги исчезли. Вместо 12–16 часов на саппорт мы стали тратить всего 2 часа.
Также ежедневно отправляем автоматический отчет по всем задачам саппорта, которые находятся в реализации, в том числе просрочены более чем на 2 дня. Это позволяет понимать, какая задача «подвисла», мотивирует на поиск и устранение причин.

Выводы
1️⃣ Вопросам саппорта незаслуженно уделяют мало внимания, хотя работа с ними может серьезно улучшить процессы.
2️⃣ Добавление процессов и инструкций часто может быть более эффективным, чем введение новой фичи или технологии.
3️⃣ Затратив немного времени на обучение пользователей перед началом использования какой-то программы или оборудования, можно избежать многих проблем.

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

Также приглашаем поделиться впечатлениями, какие посты в Телеграме вам интереснее – короткие или длинные? А может быть, вы предпочитаете читать лонгриды, переходя по ссылке на сайт или Telegraph? Нам интересно и важно узнать ваше мнение 💙

#полезное

❓ Готовы ли вы к цифровой трансформации? Боитесь начать или столкнулись с какими-то проблемам в процессе?

Каждая компания подходит к цифровой трансформации с разных стартовых позиций. Поделимся опытом команды SimbirSoft и поговорим лишь о некоторых рисках, с которыми бизнес может столкнуться, а может и нет. Чуть подробнее рассказывали Rusbase.

Во-первых, можно столкнуться с кадровыми рисками. Например, руководитель может понять, что не хватает специалистов, способных правильно выстроить процессы, обучить действующих сотрудников работе с новыми технологиями, а также управлять их адаптацией. А значит их срочно надо найти, нанять и быстро включить в решение поставленных задач.
Во-вторых, в век цифровых технологий возрастают риски управления данными. Среди наиболее частых – утечка информации, нарушение конфиденциальности, несанкционированный доступ с разными целями к данным компании или сотрудникам.

Также на старте есть риск неверно обозначить показатели, по которым можно будет определить успешность проекта цифровизации. Избежать этого помогут регламенты и другие правила, рекомендации и инструкции, документация с четко прописанными KPI (дорожные карты, спринты и пр.), а также обучающие материалы для повышения квалификации сотрудников.

Управление этими рисками можно сделать легче, если использовать следующие инструменты (подходят для любого бизнеса):

📌CRM – для выстраивания системы взаимодействия с клиентами,
📌корпоративная база знаний – для хранения регламентов и другой информации, предназначенной сотрудникам компании,
📌таск-трекеры – для постановки задачи и контроля их исполнения подразделениями и ответственными лицами,
📌корпоративные мессенджеры – для обмена сообщениями и материалами между сотрудниками,
📌HR-системы – для автоматизации процесса отбора, найма, адаптации и управления персоналом, обеспечения контроля карьерного роста и развития сотрудников внутри компании,
📌инструменты шифрования и VPN – для безопасного подсоединения сотрудников к корпоративным системам и локальной сети, а также защиты информации.

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

👉🏻 Главное – ИТ-решения должны окупиться и принести выгоды для бизнеса.

Аккаунт-менеджеры – люди, которые остаются на связи с клиентами в любое время и делают всё для комфортного и продуктивного взаимодействия на проекте. Этот пост посвящён именно им 💙
Что их вдохновляет? Как удаётся разбираться во всех тонкостях? Какие задачи выполняют? – В нашем видео из первых уст 😎

​​Продолжая разговор о CRM, хотим поделиться дизайном такой системы для одного из наших клиентов ✨

Наши специалисты разрабатывают интерфейсы и бережно упаковывают их в анимированные кейсы. Результаты работы вы можете увидеть на площадке Dribbble: https://s.simbirsoft.com/B7c6. В каждом видео вы найдете концепцию, основной функционал и детали.

Смотрите и делитесь своими впечатлениями 💥

#статьи

Ошибки бизнеса на IT-проектах. Часть 1
Операционный директор SimbirSoft Дмитрий Петерсон поделился с РБК.Pro, какие ошибки допускает бизнес на проектах разработки. О том, как избежать их, расскажем в следующем посте.

Ошибка №1. Отсутствие чёткого понимания целей проекта
Важно донести до подрядчика цели проекта, чтобы команда смогла выбрать оптимальное решение и план его реализации.
В целом оптимальна итеративная разработка, когда процесс поделен на небольшие этапы и по итогам их выполнения специалисты производят анализ промежуточных результатов. Это помогает снижать неопределённость и при необходимости корректировать требования к продукту.

Ошибка №2. Неполные требования к IT-продукту
Все предпочтения лучше обговорить до старта работ. Внимательно отнеситесь к вопросам команды и старайтесь отвечать на них детально.
Если уже по ходу проекта выяснится, что устройства имеют технические ограничения, то необходимо будет заново проводить аналитику задачи и изучать возможные риски. Скорее всего, это приведёт к увеличению стоимость и сроков проекта.

Ошибка №3. Несвоевременное предоставление необходимых ресурсов
Обратная связь по определённому комплексу работ или предоставление доступов к внутренним системам заказчика в некоторых случаях может занимать до месяца (!). В это время подрядчик будет вынужден выставить счёт за простой своих специалистов, а в крайнем случае – распустить команду.

Ошибка №4. Проблемы в коммуникациях
Не только руководитель команды разработки должен оперативно отвечать на вопросы и предоставлять необходимые разъяснения. Клиенту важно назначить со своей стороны человека, который будет связующим звеном с подрядчиком: например, сообщать об изменениях в базах данных или напоминать руководителю о необходимости выбора прототипов.
Двусторонняя заинтересованность во взаимодействии повышает продуктивность работы и атмосферу на проекте.

Ошибка №5. Избыточный контроль
Безусловно важно обговорить стртегически важные аспекты разработки будущего продукта, а также метрики промежуточного контроля. Но неоправданно высокое внимание клиента к тактике достижения результатов: например, методам решения задач – снижает уровень инициативности и демотивирует команду.

#статьи

Ошибки бизнеса на IT-проектах. Часть 2
При разработке IT-системы важна заинтересованность в качестве и успехе проекта как подрядчика, так и заказчика. Сегодня расскажем, как бизнес может помочь команде, чтобы работа над продуктом была продуктивной и результативной.

Совет №1. Точно определить требования к системе, расставить приоритеты и впоследствии своевременно сообщать об их изменении
Аналитику важно детально объяснить цель каждого требования к разрабатываемому ПО, чтобы он мог точно выразить его в спецификации. Тогда у команды на каждом этапе работы будет та информация, которая соответствует ожиданиям клиента.

Совет №2. Ознакомить аналитиков и разработчиков с особенностями бизнеса
Оптимальный вариант реализации проекта зависит от специфики бизнеса. Например, иногда лучше начать с адаптации действующего решения, чтобы обеспечить непрерывность бизнес-процессов. В других случаях подойдёт разработка MVP, чтобы проверить гипотезы в короткие сроки. К тому же, обратная связь сотрудников компании поможет получить более эффективное IT-решение, так как они знакомы с «внутренней кухней» бизнеса.

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

Совет №4. Стремиться к единому пониманию оценки и её наполнения и давать своевременную обратную связь
Эксперты подрядчика готовят детализацию оценки, декомпозируют крупные пласты работы на более мелкие задачи и предоставляют полную информацию об ограничениях и особенностях проекта. Когда некоторые пункты вызывают вопросы, исполнители обязаны дать необходимые пояснения. Если по итогам оценки клиент понимает, что он планировал затратить меньше ресурсов, возможно упростить структуру продукта или отказаться от менее важных функций.
Во время реализации команде также важно понимать, что она движется в правильном направлении. По ходу проекта у специалистов могут возникать и дополнительные предложения по улучшению продукта, которые они не смогут внедрить, если представитель заказчика не даст своевременную обратную связь.

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

Напоминаем, что с полной статьёй вы можете ознакомиться здесь👇

#подкасты

Процесс онбординга в hh.ru
В нашем подкасте «Чистый код» вместе с руководителем мобильной разработки hh.ru Александром Блиновым мы поговорили о том, как сделать качественный мобильный продукт и что для этого необходимо. Здесь хотим поделиться фрагментом выпуска про онбординг – процесс включения сотрудника в рабочие процессы компании. Этот опыт будет полезен для любого бизнеса, где перед началом работы необходимо системное погружение новичка.

– В hh.ru процесс онбординга постепенно эволюционировал – сейчас это комплексная система. В продуктовой разработке кроме погружения в технологический стек, необходимо понимание бизнес-процессов на проекте. Чтобы сотрудник успел постичь всю информацию за 3–6 месяцев, мы разделили этот срок на части.
Для изучения технологической стороны и знакомством с продуктом мы подготовили презентацию, которая на данный момент насчитывает около 4 часов. Мы предлагаем изучить её за несколько дней. В каждую логическую часть мы поместили ту порцию информации, с которой человек может качественно ознакомиться: например, как устроен проект, как устроена биосистема и т.д.
После теоретического погружения мы предлагаем фичу для рефакторинга – перепроектирования кода. Для этого сотруднику не надо будет участвовать в бизнес-процессах, взаимодействовать с продакт-менеджером или дизайнером, он будет разбираться с чужим кодом и постигать самые сложные части нашего проекта: как работает многомодульность, стековая машина и т.д.
Уже после такого технического задания мы поручаем новичку разработку продуктовой фичи, где он погружается в бизнес-специфику. Чтобы сотруднику было легче входить в процессы, сначала он утром и вечером созванивается с тимлидом на ежедневной основе. Постепенно период увеличивается до двух дней, ещё позже – до двух недель. На таких встречах ментор помогает разбираться в проблемных вопросах и возникших трудностях. Благодаря этому сотрудник развивается.
Также в Miro мы подготовили разветвлённое дерево компетенций, после прохождения испытательного срока человек оценивает себя по нему. После ментор перепроверяет и анализирует эту информацию и отмечает те места, которые необходимо прокачивать для дальнейшего роста. При этом мы учитываем баланс внутри команды: кто-то может быть больше развит в аналитике, кто-то хорошо разбирается в биосистеме и т.д. В итоге мы получаем групповую синергию, когда каждый дополняет друг друга. Кроме того, это снижает bus factor («фактор автобуса») – так называют количество членов команды, при постоянном отсутствии которых работа попадет в кризисное положение.

Резюме:
1. Ознакомьте сотрудника с важными теоретическими аспектами работы и компанией в целом.
2. Определите для него набор задач, где он может не контактировать с клиентами или не включаться в основные бизнес-процессы для тренировки полученных знаний.
3. Поручите задачу, которая предполагает внедрение в общий процесс и взаимодействие с другими членами команды и/или вашими клиентами.
4. Составьте ИПР, который будет интересен для самого сотрудника и полезен в рамках вашего бизнеса.
На протяжении всего погружения приставленный ментор должен направлять нового сотрудника и помогать ему в возникающих сложностях.


Как вам кажется, такой процесс онбординга оптимален или некоторые этапы можно сократить?
😎 Чем быстрее включить сотрудника в полноценную работу, тем быстрее он вырастет как специалист.
😇 Надо давать новичку время, чтобы он в комфортном темпе ознакомился со спецификой бизнеса.

​​#статьи

Time&Material или Fixed Price?
Когда выгодно заказывать IT-продукт с повременной оплатой, а когда – по «фиксе»? В блоге наша команда PM разобрала по полочкам этот вопрос, все подробности вы можете прочитать по ссылке. В нашей выжимке – условия, при которых оптимален тот или иной вариант.

Fixed Price (фиксированная модель) подходит:
🔹для небольших проектов, продолжительность разработки которых не превышает трёх месяцев;
🔹если у клиента есть строго ограниченный бюджет, жесткие сроки (например, в государственных проектах) и чёткое видение результата, прописаны подробные требования к проекту и отсутствуют переменные факторы;
🔹если со стороны заказчика есть один человек, ответственный за принятие решений и приёмку конечного результата;
🔹если разрабатываемое решение прежде всего ориентировано на внутреннее пользование и нет большой необходимости учитывать мнение пользователей.

«Фикса» хорошо подходит для стандартизированных решений. К примеру, если у клиента есть необходимость переноса производственных процессов в коробочное решение без добавления дополнительного функционала.

Time&Material (повременная модель) подходит:
🔹для проектов любого масштаба длительностью от нескольких месяцев и выше;
🔹для проектов с гибкими требованиями, когда объём работ нельзя точно определить заранее и качество продукта – на первом месте;
🔹при создании уникальных IT-продуктов для внешней аудитории, когда при каждом принятии решения необходимо учитывать мнение пользователей;
🔹для проектов повышенной сложности – например, внедрение/изменение архитектуры существующего ПО в большой корпорации;
🔹когда есть проверенный подрядчик с большим опытом, широкой экспертизой и профессиональной командой.

T&M подходит проектам с высоким уровнем неопределенности, в том числе продуктовым.

Из практики
Одному нашему клиенту для собственного производства необходимо было разработать IT-решение для детектирования объектов, распознавания элементов продукции и их параметров. Реализация решения была основана на технологиях machine learning. Поскольку подобные задачи по своей природе можно назвать исследовательскими и невозможно точно оценить сроки и бюджет на реализацию таких уникальных IT-продуктов, совместно с клиентом выбрали формат работы – Т&М. Это позволило команде провести необходимые работы и определить наиболее эффективный подход в решении задачи. С клиентом согласовывалось время, которое можно затратить на исследования, и перечень задач, которые команда собирается исследовать в течение этого периода.
В результате заказчик понимал, сколько времени и средств занимает данная задача, мог планировать и контролировать затраты на реализацию проекта.

​​#статьи #подкасты

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

Почему сложно развивать крупный продукт инхаус-командой?
Многие современные организации, особенно финтех и банки, пронизаны IT-системами. Это неотъемлемая составляющая их бизнеса, которая определяет их преимущества.
Аутсорс-команда живет в высококонкурентном поле, стремится быть на шаг впереди других во всём: совершенствовать процессы, инструменты, коммуникации, не только работать по чётко по техническому заданию, но и предвидеть желания и IT-потребности своего клиента. Есть только один путь, чтобы оставаться востребованным, – предоставлять лучший сервис. Внутренняя команда, как правило, изолирована от внешнего IT-мира и конкуренции. У них нет такой движущей силы, которая заставляет идти в ногу со временем: «заказчик» не уйдёт от неё, даже если используются не самые современные инструменты или принципы разработки. В этом и состоит ключевое отличие от аутсорсинга.

Пример
Один молодой банк несколько лет назад решил создать своё приложение с нуля. Руководители поставили перед собой амбициозную цель – занять лидирующие позиции в рейтинге Markswebb. Они сформировали внутреннее IT-подразделение с достаточно большим штатом программистов и установили запрет на аутсорсинг.
В первые 2–3 года они очень бурно развивались, наладили процессы и работали строго по Agile. Их приложение заняло второе или третье место. Но позже процесс развития продукта затормозился. Собственники столкнулись с неэффективностью внутренних коммуникаций и обратились к нам. Несмотря на отличную базу, мы обнаружили ряд проблем. Например, некоторые разработчики продолжали вручную выполнять операцию, которую можно было легко автоматизировать. Опираясь на этот опыт, банк изменил подход к аутсорсингу: теперь задачи по разработке выполняют распределенные команды, состоящие как из внутренних, так и внешних специалистов. Выбранный способ в итоге подтвердил свою эффективность.

Чтобы вам было удобнее, мы готовим наши материалы в разных форматах. Прочитать подробнее о балансе инхаус и аутсорсинга можно в статье, а послушать – в подкасте.

А какой контент больше нравится вам?
📜 Ничто не заменит старое доброе чтение
🎙 Подкасты – находка современности
😉 Я человек настроения: сегодня чтение, завтра подкасты)

​​#полезное

Flutter в новых условиях
Раньше для реализации больших банковских приложений и приложений со сроком эксплуатации в 3–5 лет и более мы советовали выбирать нативную разработку – Android, iOS. Если клиенту требовалось протестировать прототип, рекомендовали Flutter.
В новых обстоятельствах, когда бизнесу нужно сосредоточиться на оптимизации бюджета и получении прибыли здесь и сейчас, большую актуальность приобретает кроссплатформенная разработка на Flutter.

Почему Flutter?
1. Экспертиза Flutter растет, как и количество разработчиков.
2. Благодаря высокой скорости отрисовки экранов и плавности интерфейса Flutter позволяет добиваться более качественного UX. Также вы получаете одинаковый UI (пользовательский интерфейс) на Android- и iOS-платформах. Flutter помогает правильно нарисовать тот или иной элемент для каждой версии, а в результате вы получаете единообразие в приложениях.
3. Разработка на Flutter дешевле и быстрее, чем на нативном Android или iOS. Для второго варианта понадобится четыре IT-специалиста. Это две маленькие «команды», которые будут писать одно и то же, но на двух разных языках программирования. Тот же результат можно получить с помощью двух Flutter-разработчиков.
4. Возможно написать приложение один раз и компилировать его для нескольких платформ. К тому же, если потребуется, всегда есть вариант написать модули для вызова нативных функций. С помощью минимальных доработок продукт можно пересобрать и в веб-сайт. Даже если вы хотите, чтобы интерфейс веб-версии отличался от мобильного приложения, достаточно будет переделать только UI, а данные и бизнес-логика останутся прежние.

Кому стоит обратить внимание?
Такой вариант разработки подойдет разным типам приложений кроме узкоспециализированных приложений под конкретное «железо». Более всего Flutter предпочтителен для ситуаций, когда нужно максимально ускорить разработку и сэкономить при этом.

Как крупные компании применяют Flutter?
Приложение Alibaba создано для электронной торговли B2B. На платформе хранится огромный пул изображений и сложных структур, которые запускаются через единую базу кода на Android или iOS. В связи с этим компания решила обновить приложение, чтобы упростить навигацию для клиентов. Для этих целей выбрали Flutter, который обладает высоким FPS, бесшовным интерфейсом, а также позволяет ускорить разработку и упростить дальнейшее обслуживание программы.

#полезное

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

С какой целью можно использовать цвета в интерфейсе ИТ-продукта в российской культуре

🟦 Синий
Ассоциируется с консервативностью, надежностью, стабильностью. Располагает пользователя к доверительным отношениям.
Варианты использования: гиперссылки, кнопки, фон.

🟥 Красный
В первую очередь ассоциируется с предостережением, опасностью, но при использовании теплых оттенков также воспринимается как цвет любви и смелости.
Варианты использования: указать на ошибку, выразить эмоцию (лайки в ВК становятся красными при нажатии и т.д), привлечь внимание к элементам (скидка, новая цена).

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

⬛️ Черный
Универсальный цвет, который сочетается со всеми остальными. При этом он символизирует авторитет, силу и элегантность. Идеален для люксовых товаров и продуктов.
Варианты использования: текстовый контент.

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

🌸 Розовый
С середины прошлого столетия цвет связывают с продуктами, рассчитанными на женскую аудиторию. Ассоциируется с легкостью, молодостью и романтикой. Пудровые оттенки этого цвета используются в ретро тематике.
Варианты использования: цвет ссылок, фона, нумерации страниц, стилизации кнопок.

🟨 Желтый
Один из самых энергичных и динамичных. Это цвет солнца, тепла, счастья. Часто используется в тематике детских товаров, так как ассоциируется с радостью и надеждой.
Варианты использования: кнопки, уведомления о новых поступлениях, акциях и пр.

🟧 Оранжевый
Это цвет динамики, целеустремленности и уверенности. При этом он хорошо подчеркивает творческое направление — им любят акцентировать креативность, комфорт и лояльность.
Варианты использования: элементы фона, анимации, слайдеры, визуализация хедера.

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