Об эталонном аджайле и мультикультурности

Работали мы как-то на проекте с немцами: огромный концерн, куча юрлиц. Помогали им визуализировать данные из БД на несколько миллиардов записей. И оказалось, что немцы и вправду очень педантичны в работе. Они строго следовали всем правилам и инструкциям. 

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

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

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

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

• Вывод 1. Не стоит слепо следовать даже самым популярным практикам. Подходите ко всему с умом, а не формально. Создавайте свой уникальный фреймворк, который подходит именно вашей ситуации и вашей команде.

• Вывод 2. Для успеха нужны опыт, здравый смысл, смелость сказать начальству «нет» и понимание лучших практик, чтобы собирать свою реальность из правильных «кирпичиков». И, конечно, человеколюбие.

• Вывод 3. Созвоны — зло, если их у команды разработки больше двух в день. Они убивают продуктивность у всех.

Больше об управлении проектами рассказываем в отдельном телеграм-канале.

🏎️Как мы чуть не проиграли в гонке за фичами💨

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

Дано: продукт Y.

Условие: заказчик, который очень спешит выпускать всё новые и новые фичи.

Каждые два спринта мы выпускали что-то новенькое, каждые две недели был большой релиз. Само собой, это влияло на качество кода и в целом на работу. Важен был темп, скорость, а не эффективность приложения.

Начинали мы работать с Y как со стартапом — и тогда эта спешка оправдывала себя. Но когда количество пользователей перевалило за миллион, напряжение возросло.

Представьте: у вас вовсю идет рекламная кампания, а приложение всё сильнее лагает.

Как-то раз нам пришлось даже отключать некоторые фичи, чтобы привести приложение в чувство.

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

Вывод: IT-блок и продакты должны уметь вовремя остановить бизнес, который несется вперед на всех парах. Лучше делать медленнее, но сразу хорошо. В противном случае придется всё переписывать. А это дорого и больно.

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

👉Больше о продуктовой разработке в нашем телеграм-канале «Эффект продакта».

Как CodeStyle спасает Flutter-проекты от хаоса

Разрозненная структура файлов, разные подходы к оформлению и дублирование функциональности — всё это замедляет разработку и повышает вероятность ошибок.
Чтобы победить хаос, сделать работу команды быстрее и проще, попробуйте внедрить CodeStyle — это свод правил, которые делают код читаемым, стандартизированным и удобным для поддержки.

Вот что вы получите:

• Читаемость: новые участники команды быстрее понимают проект.

• Стандартизация: вся кодовая база выглядит так, будто ее писал один человек.

• Поддерживаемость: проще рефакторить и находить ошибки.

Почему CodeStyle особенно важен для Flutter

Flutter на проектах дает гибкость, которая при отсутствии дисциплины превращается в проблему. Например, вы можете столкнуться с:

• разрозненной структурой файлов, которая затрудняет поиск компонентов;

• непоследовательным оформлением кода, которое усложняет его понимание;

• дублированием библиотек и функционала, которое приводит к путанице.

Единый CodeStyle решает эти проблемы и создает прозрачную и предсказуемую структуру проекта.

Как внедрить CodeStyle: 4 шага

1. Обучение

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

2. Автоматизация

Настройте инструменты для проверки кода:

• линтеры (например, flutter_lints) для автоматической проверки стиля;

• pre-commit хуки (Husky или Lefthook) для форматирования кода перед коммитом.

3. Код-ревью

Сделайте ревью обязательным этапом Pull Request. Это улучшит качество кода и поможет следить за соблюдением правил.

4. Командное соглашение

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

Если хотите внедрить эти подходы на своих проектах, читайте подробную статью от нашего Flutter-разработчика Никиты Грибкова. В ней найдете больше примеров, кода и рекомендаций.

🐺🛡️Уроки информационной безопасности на примере сказки «Волк и семеро козлят»

Кратко напомним сюжет сказки.

Жили-были семеро козлят с мамой-козой. Однажды маме нужно было отлучиться по делам. Перед уходом она строго наказывала: «Никому дверь не открывайте, особенно волку!». Но волк оказался хитрым: притворился мамой-козой, подменив голос, проник в дом и проглотил козлят. Мама-коза вернулась, разделалась с волком и спасла своих малышей из его живота. Конец.

Если перенести эту историю в мир IT, станет очевидно, что в ней нарушили правила безопасности, и страшные последствия не заставили себя ждать.

Давайте разберемся, где именно наши козлята оплошали и что здесь пошло не так с точки зрения информационной безопасности.

📢Ошибка 1: отсутствие многофакторной аутентификации

Козлята полагались только на голосовую аутентификацию. Волк провел «фишинговую атаку»: изменил голос и убедил козлят открыть дверь. Если бы мама-коза внедрила второй фактор — например, пароль или «козлиный секретный код», — это предотвратило бы беду.

🔓Ошибка 2: небезопасные дверные системы

Дверь в доме козлят была слишком уязвимой. Возможно, мама-коза использовала устаревший дверной замок «версии 1.0». Современные решения вроде «умных замков» с биометрией или камерой на двери могли бы помочь предотвратить проникновение волка.

🔎Ошибка 3: отсутствие обучения

Мама-коза объяснила правила защиты, но не провела полноценный тренинг по кибербезопасности. Козлята не знали о поддельных голосах, методах социальной инженерии и других угрозах. А профилактика всегда дешевле спасательной операции!

🔥Ошибка 4: отсутствие реакции на инциденты

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

✅Вывод: если бы мама-коза применила передовые практики информационной безопасности, волк остался бы за дверью. Помните: не полагайтесь только на одно средство защиты. Пароли, двухфакторная аутентификация и тренировки по кибербезопасности — ваши лучшие друзья.

А волка просто стоит заблокировать в черном списке навсегда :)

P. S. Подробнее о том, как защититься от самых популярных кибератак, читайте в нашей статье на New Retail. Там эксперты из OZON, F.A.C.С.T, Flowwow и AGIMA поделились реальными кейсами: с какими схемами мошенников они сталкивались и как от них защищались.

Почему лучше верить данным, а не себе

Делимся кейсом с одного нашего проекта.

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

При этом, если фильтры не трогать, они по умолчанию показывают предзаданные параметры. То есть, по сути, при первом визите человек видит на экране только самые популярные продукты.

В какой-то момент у команды встал вопрос: как должна выглядеть выдача, когда меняешь фильтры? Начали рассуждать, дискутировать, иногда даже спорить. И так продолжалось до тех пор, пока один мудрый человек не предложил посмотреть статистику.

И тогда всё стало ясно.

Оказалось, что 60% наших пользователей вообще не пользуется этими фильтрами. Им хватает предустановленных популярных параметров. Они выбирают самый подходящий продукт, а уже потом в нем меняют параметры под себя.

Значит, дальше нужно было работать над фильтрами по умолчанию и над первой витриной.

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

Больше о продуктовой разработке в нашем телеграм-канале «Эффект продакта».

Что мы поняли о пользователях из России, пока делали UX-исследование для гватемальцев

Немногие с ходу вспомнят, где на карте мира находится Гватемала. Она расположена в южной части Северной Америки, на севере граничит с Мексикой и имеет выход сразу к двум океанам — Тихому и Атлантическому.

Недавно нам выпало познакомиться с этой страной и ее жителями поближе — наша команда проводила уникальное UX-исследование для крупного гватемальского девелопера. Глобальной целью было улучшить сайт одного элитного района в столице страны.

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

1. Пользователи в Гватемале ценят личное общение.

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

В работе над сайтом девелопера для нас эта особенность гватемальцев стала сигналом о необходимости разместить контакты на самом видном месте — так, чтобы их можно было найти в один клик.

2. 3D-модели жилья повышают доверие.

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

В России, например, 3D-модели также находят отклик у пользователей, но часто воспринимаются как дополнительная опция, а не обязательный элемент.

3. Карта территории — необходимость.

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

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

Этот случай наглядно показал, как разные группы пользователей могут по-разному воспринимать одни и те же аспекты интерфейса.

4. Всем гватемальцам важна экология.

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

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

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

Как масштабировать бизнес и построить успешный продукт

У AGIMA и ONY вышел третий выпуск подкаста One Two Prod. Гость новой серии — Людмила Пак, Product lead в Ecom.tech (ex. Samokat.tech).

Вместе с ней ведущие подкаста Костя Келлер (дизайн-директор ONY) и Вика Левена (директор по аналитике AGIMA) разбирают секреты успеха диджитал-продуктов.

🎙️ Главные темы выпуска:

• Масштабирование бизнеса: как подготовить компанию к росту, избегая критических ошибок?

• Создание и управление командами: почему правильная структура и роли так важны?

• Работа с подрядчиками и партнерами: как строить долгосрочные и продуктивные отношения?

• Технологии и человеческий фактор: как найти баланс между инновациями и потребностями команды?

• Практические советы для стартапов: что делать, чтобы не сойти с дистанции на старте?

• Выход на международный рынок: с какими вызовами придется столкнуться и как их преодолеть?

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

🎧 Кому полезно послушать?

• Продакт-менеджерам, которые хотят прокачать профессиональные навыки.

• Предпринимателям, которые хотят вывести бизнес на новый уровень.

• Топ-менеджерам, заинтересованным в успешном управлении командами.

📺 Смотрите и слушайте One Two Prod там, где удобно:

• YouTube

• VK Видео

• Mave

• Яндекс Музыка

Делитесь впечатлениями, ставьте лайки и подписывайтесь. Следующий выпуск One Two Prod уже в пути!

5 решений в цифровых продуктах, которые оценят и бумеры, и зумеры

Население активно стареет и меняет пользовательские привычки, зумеры задают новые тренды, а ИИ и Big Data добавляют новые технологические вызовы каждый день. Как в таких условиях создать цифровой продукт, который бы понравился разным поколениям, не раздул бюджет и не устарел в ближайшие годы? Собрали несколько советов в этом посте.

🔹 Отказ от стереотипов. Считается, что зумеры живут в интернете 24/7. Но исследования показывают, что 73% из них специально ходят в офлайн-магазины, чтобы «отключиться» от цифрового мира. Поэтому стоит изучать реальное поведения своих пользователей всех возрастов, чтобы предлагать им подходящие решения.

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

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

🔹 Персонализация — путь к лояльности. Дайте пользователям возможность настраивать интерфейс под себя, скрывать ненужный им контент, управлять фичами.

🔹 Прозрачность. Никто не любит темных паттернов в UX-дизайне. Например, лучше сразу раскрыть все условия покупки и ясно донести их до пользователя. Если вы любитель мутных схем, то вы можете столкнуться с еще одним трендом молодого поколения — культурой отмены.

Еще больше решений, примеров, данных исследований и реальных кейсов — в нашей статье-исследовании. Будет классно, если поделитесь ею с коллегами — от дизайнеров до продакт-менеджеров.

Как защититься от самых популярных кибератак: советы экспертов из крупных компаний

Масштабы киберугроз в России растут: только за 9 месяцев 2024 года зафиксировано более 100 утечек данных. Атаки злоумышленников становятся всё более изощренными. Но есть конкретные шаги, которые помогут уберечь ценные данные и выстроить верную защиту ваших систем.

В новой статье на New Retail эксперты из OZON, F.A.C.С.T, Flowwow и AGIMA рассказали о самых типичных схемах мошенников и методах борьбы с ними. Вот главные тезисы:

📌Атакуют всех: злоумышленники используют старые утечки данных, анализируют оборот компаний и шифруют ценные данные для выкупа. Группировка Conti, к примеру, требует до 4% оборота за расшифровку.

📌 Security by Design. Это принцип разработки, при котором безопасность системы закладывается еще на этапе планирования архитектуры. Он помогает исключить уязвимости и защитить продукт еще до запуска.

📌 Фишинг — одна из главных угроз. Имитация фишинговых атак и проведение тестов на проникновение (пентестов) помогут подготовить команду к реальным угрозам. Строго проверяйте отправителей во входящих письмах и заведите правило не переходить по подозрительным ссылкам.

📌 Автоматизация мониторинга. ИИ-решения и системы автоматической обработки угроз помогут быстро выявлять аномалии и реагировать на них за считаные минуты вместо часов.

Эти и другие советы из статьи помогут защитить корпоративную инфраструктуру и данные, минимизировать риски утечек и сохранить репутацию вашей компании.

Как оформить митинг-репорт так, чтобы всё было по полочкам

Митинг-репорты помогают быстро фиксировать ключевые итоги встречи и спасают от забытых идей и потерянных договоренностей. Пример:

• Договорились о дедлайне, но через неделю никто не помнит о нем.

• Обсудили классное решение, но не записали — идея потеряна.

Четко оформленный репорт решает эти проблемы.

Шаблон митинг-репорта

1. Дата и время встречи. Когда прошло событие.
2. Наименование. Тема или цель встречи (например, «Статус по проекту "N"»).
3. Место. Укажите, где встречались: Zoom, офис или другое.
4. Участники. Перечислите всех присутствующих.
5. Артефакты. Список всех материалов и документов, которыми делились — презентации, записи, план-графики с ссылками или прикрепленными файлами.
6. Вопросы и договоренности. Фиксируйте ключевые обсуждения и принятые решения. Например:

• Утвердили новый дедлайн по задаче X — 19.11.2024.

• Перенесли встречу с заказчиком на 23.11.2024.

• Договорились добавить дополнительный раздел в презентацию.

Итого

Оформление такого репорта занимает 5–15 минут — зависит от сложности встречи и количества вопросов на повестке. Но этот небольшой вклад времени окупается с лихвой: вы всегда знаете, что обсуждалось, и вам не нужно пересматривать длинные записи.

А какой у вас подход к репортам? Делитесь в комментариях своими форматами и лайфхаками.

Почему джуны — это хорошая инвестиция

Большинство компаний неохотно нанимают начинающих разработчиков. Согласно статистике Хабр Карьеры, только 5% опубликованных вакансий ориентированы на джуниор-специалистов. Для сравнения: 50% — на мидлов, 31% — на сеньоров, 8% — на лидов, 6% — на стажеров. На рынке к джунам принято относиться с опаской. Есть стереотип, что они приносят мало пользы, зато требуют много вложений.

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

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

Есть и другие преимущества:

1. Джуны берут на себя рутинные задачи, а значит, мидлы и сеньоры меньше выгорают. К тому же это выгоднее экономически: если кнопки на сайте красит джун, а не сеньор с огромной зарплатой — вы экономите.

2. Джуны лояльнее к компании. Если всё сделать правильно, то джуниор останется в компании надолго. Так вы экономите на найме и закрываете на будущее вопрос с высококвалифицированными кадрами.

Больше об экономике найма джунов и о работе с ними — в большой статье.

Работа тимлида: ожидание vs. реальность

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

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

Это произошло в конце 2022 года, когда зарубежные сервисы массово уходили из страны. И мне пришлось экстренно осваивать навык ведения переговоров. Количество коммуникаций у меня выросло кратно: нужно было помногу общаться с заказчиком, другими подрядчиками и коллегами. Первое время на созвонах приходилось проводить по 6–7 часов в день.

Правда. так продолжалось недолго. Вскоре ситуация с сервисами устаканилась, на проекте появился еще один тимлид, и я смог спокойно погрузиться в новую профессию. Как оказалось, развивать в первую очередь нужно было софт-скиллы. Умение давать обратную связь, поддерживать и учить не поучая — такие вещи не приходят сразу, хоть и кажутся простыми.

Стоит ли идти в тимлиды? Я для себя определился быстро: да, тимлид — это хорошая перспектива. В конце концов вернуться в разработку можно всегда.

Полная история — в нашем блоге.

Как мы шаг за шагом актуализируем корпоративную базу знаний

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

Однако провести ревизию всё никак не получалось. Сделать это без руководителей направлений было невозможно, но у них в приоритете были задачи, связанные с развитием компании. К тому же переписывание Wiki казалось огромной и неделимой задачей.

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

• Пересобрать структуру Wiki и определить правила написания статей.

• Наполнить бэклог статьями, которые нужно актуализировать, и процессами, которые нужно задокументировать.

• Канбанизировать сервис (мы назвали его AGIMA Дума), который будет переваривать бэклог.

• Постоянно развивать сервис, повышая его Throughput и Lead Time.

• Актуализировать имеющиеся статьи, чтобы база знаний снова не превратилась в помойку.

Сейчас мы на четвёртом этапе, и в бэклоге 300+ тикетов. Но процесс стал прогнозируемым. Раз в две недели грумим бэклог, нарезаем тикеты (соблюдая WIP-лимиты), прогоняем по чек-листам новые материалы, еженедельно релизим статьи и онбордим в них нужные категории сотрудников.

Больше об управлении агентством — на странице нашего COO.

Как дизайн влияет на развитие продукта: 5 главных принципов

В продуктовой разработке роль дизайна выходит далеко за рамки эстетики. Дизайн — это не просто красивый интерфейс. Он напрямую влияет на восприятие продукта, его конкурентоспособность и рост дохода компании.

Но как именно дизайнер может формировать продуктовую стратегию? Отвечаем в пяти пунктах.

1. Влияние на прибыль. Хороший дизайн — реальная инвестиция в бизнес-результаты. Исследования говорят: компании, которые активно инвестируют в дизайн, за пять лет заработали больше, чем те, кто этим пренебрегает.

2. Эмпатия. Дизайнеру важно ею вооружиться, чтобы лучше понять свою аудиторию. Можно изучать интерфейсы популярных сервисов, типа OZON, чтобы предугадывать ожидания пользователей, или шерстить отзывы в поисках редких кейсов и инсайтов.

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

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

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

Полная версия статьи с примерами и цифрами — у нас на Хабре.

Внедряем модели машинного обучения в мобильное приложение на Flutter

Если Flutter-приложение нужно сделать более удобным и инклюзивным, скорее всего, придется использовать технологии ML. Вот только несколько примеров задач, в которых машинное обучение наверняка понадобится:

• классификация изображений: чтобы приложение могло распознавать объекты на фотографиях или видео (например, Google Lens);

• обработка естественного языка (NLP): в приложениях с голосовыми ассистентами или чат-ботами ML обрабатывает речь и тексты;

• персонализация: алгоритмы ML анализируют поведение пользователей и предлагают персонализированный контент или рекомендации;

• распознавание голоса: используется в приложениях для конвертации речи в текст и команд.

Существует несколько способов, как интегрировать модели машинного обучения в приложение. Можно воспользоваться ML Kit от Firebase или библиотеками на Dart. Но самое распространенное решение — фреймворк TensorFlow Lite (TFLite). Его главное (но не единственное) преимущество — что он будет работать в том числе тогда, когда смартфон не подключен к интернету.

В отдельной статье разбираем, как настроить модель для работы с TFLite, как интегрировать TFLite во Flutter-приложение и как оптимизировать модели для мобильных устройств.

10 советов, как собрать UI-кит

UI-кит помогает командам поддерживать консистентность интерфейсов и упрощает процессы дизайна. Лера Ган, дизайнер AGIMA, поделилась советами, которые помогут вам собрать хороший UI-кит:

1. Используйте автолайауты. Они избавят от рутины и помогут избежать ошибок.

2. Комментарии к элементам. Добавляйте пояснения к компонентам. Это упростит понимание функциональности и цель элементов для всей команды.

3. Отбор компонентов. Включайте только часто используемые элементы. Избегайте перегрузки интерфейса ненужными компонентами, чтобы сосредоточиться на важном.

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

5. Сетка и отступы. Убедитесь, что сетка и отступы подходят для разных разрешений. Это упростит адаптацию интерфейса на разных устройствах.

6. Единый стиль изображений. Это важно для поддержания целостного внешнего вида, особенно — для иконок и графики.

7. Состояния элементов. Отрисуйте все состояния элементов, чтобы они были готовы к любым сценариям использования.

8. Общение с командой. Обсуждайте все изменения с коллегами. Это предотвратит непредвиденные ошибки.

9. Резервные копии. Всегда важно сохранять резервные копии, чтобы иметь возможность вернуться к прежней версии.

10. Цветовые темы. Протестируйте темную тему интерфейса. Актуально, т. к. пользователи часто используют оба режима.

Это краткая выжимка статьи из нашего блога. В полной версии найдете много примеров и лайфхаков от автора.

Кейс: ИИ-система, которая может принять и проинспектировать груз вместо человека

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

Делимся любопытным кейсом об умной системе, которую разработали в AGIMA AI. В чем суть: теперь, когда на предприятие нашего заказчика привозят груз, его принимает не человек, а система на основе искусственного интеллекта.

Что эта система делает:

✔️ фиксирует сам факт прибытия груза на склад;

✔️ сама определяет тип упаковки;

✔️ находит все дефекты и повреждения;

✔️ измеряет габариты и вес груза;

✔️ заполняет все необходимые отчеты.

Это позволяет экономить деньги и получать более объективную информацию о состоянии груза. Кроме того, систему можно использовать на вредных производствах, потому что человек в этом процессе не нужен.

Как реализована система и как она работает — рассказываем в отдельной статье.

Какие книги читать дизайнеру: мнение экспертов

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

Вот какие книги они упоминают:

• «Дизайн привычных вещей» Дона Нормана;

• «Пиши-сокращай» Максима Ильяхова;

• «Спроси маму» Роба Фитцпатрика;

• «Начни с почему» Саймона Синека;

• «Переломный момент» Малькольма Гладуэлла;

• «Паттерны дизайн-менеджмента» Юрия Ветрова;

• «ВкусВилл. Как совершить революцию в ритейле, делая всё не так» Евгения Щепина;

• «Тайная жизнь цвета» Кассии Сен-Клер;

• «Настольную книгу Project-менеджера» Владимира Завертайлова;

• «То, что мы видим, то, что смотрит на нас» Жоржа Диди-Юбермана;

• «История журнального дизайна» Ольги Рожновой;

• «Об интерфейсе» Алана Купера.

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

Как научить ИИ переносить информацию с бумаги в ERP

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

Мы в таких случаях используем Datapipe — инструмент с открытым исходным кодом. Он помогает нам построить пайплайн обработки данных. Он устроен так:

1. Данные, размеченные модератором в Label Studio, автоматически загружаются в пайплайн.

2. Размеченные данные добавляются в т. н. «замороженный датасет» — он больше не изменяется и используется для обучения ML-моделей.

3. Затем разбиваем данные на две части:

   • Тренировочный набор (train) — для обучения модели.

   • Проверочный набор (val) — для проверки и оценки качества модели.

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

5. Приступаем к последовательному обучению моделей. Сначала обучаются модели для детекции объектов (YOLOv5), а затем применяются OCR-модели (Google Cloud Vision OCR) для распознания текста.

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

Как работает такая система — в нашем блоге.

Нативные инструменты для создания виджетов во Flutter-приложении

Несмотря на все преимущества Flutter, он не всегда оптимально решает задачи, которые требуют глубокой нативной интеграции. Существуют инструменты, разработанные специально под нативные платформы, но недоступные напрямую из Dart. И как правило, в таких случаях на помощь приходит PlatformChannel. 

Но существуют и нативные инструменты, которые интегрируются с Flutter. Они, например, позволяют внедрять Home Widgets — элементы, с которыми можно взаимодействовать напрямую с домашнего экрана

• Инструкция для разработки под Android

• Инструкция для разработки под iOS

Когда виджеты разработаны, их нужно внедрить в приложение. Библиотека home_widget предоставляет набор инструментов для работы с нативными виджетами, данные методы мы можем вызвать при помощи класса HomeWidget. Вот самые важные из методов:

1. Future<bool?> saveWidgetData<T>( String id, T? data ) 

   Метод позволяет сохранить передаваемые данные в хранилище нашего виджета.

2. Future<bool?> updateWidget({String? name, String? androidName, String? iOSName, String? qualifiedAndroidName,})

   Метод вызывается для обновления нашего виджета.

3. Future<T?> getWidgetData<T>(String id, {T? defaultValue,})

   Метод позволяет прочитать данные из нашего виджета. Он может быть полезен, если нужно синхронизировать информацию между виджетом и Flutter-приложением.

Больше подробностей о нативных инструментах с примерами кода вы найдете в отдельной статье.