Как за два кризисных года мы увеличили команду вдвое

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

1. Провели реформу косвенных

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

2. Стажировки

Активно взялись за стажировки. За эти 2 года через наши проекты прошло около 120 человек, 80 из них продолжают с нами работать и сейчас. Мы берем только скилловых стажеров, которые прошли курсы и занимались самообразованием. За каждым стажером закрепляем ментора, который помогает развиваться и контролирует задачи.

3. Усиление подбора

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

Результаты

За 2022–2023 годы мы наняли порядка 300 человек. Из них 200 человек пришли в департамент разработки. При этом, мы сохранили аутсорс на докризисном уровне, а прошлый год стал рекордным по оборотам.

О наших планах на будущее читайте в полной версии статьи.

Учимся различать виды мотивации сотрудников

Пост по материалам доклада Александра Шутая, руководителя направления PHP в AGIMA, о том, как мотивация влияет на качество работы.

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

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

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

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

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

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

P. S.13 апреля Саша выступит на «Стачке» в Ульяновске. Тема: Как совместить работу в IT с жизнью. Приходите!

Рецепт создания ИИ-ассистента, который быстро отвечает пользователям по базе знаний

Ребята из компании AGIMA AI недавно сделали для NL International бота Nelly, который умеет моментально находить ответ на любой вопрос пользователя. Работает это так: человек заходит на сайт компании, понимает, что ему нужна консультация, и пишет в чат. Тут же он получает список статей, в которых, скорее всего, найдет ответ на свой вопрос.

В отдельной статье подробно описываем весь ход работы над ассистентом, а здесь приведем только те технологии, которые использовали. Их пять:

• Chatwoot — интерфейс оператора с открытым исходным кодом и база знаний.

• Rasa — фреймворк с открытым исходным кодом для создания чат-ботов.

• Botfront — визуальный интерфейс для создания чат-ботов на RASA.

• Qdrant — векторная база данных для хранения векторных представлений статей из базы знаний.

• Datapipe — ETL, с помощью которого мы извлекаем статьи из Chatwoot, обрабатываем их и помещаем в Qdrant.

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

Найти слабое звено: делаем команду эффективнее без перегруза

Слабое звено — это участок работы, из-за которого рушится весь процесс. Выявить его помогает теория ограничений, она же ТОС (Theory of constraints). Ее разработал, а затем подробно описал физик Элияху Голдратт в 1984 году.

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

1. Найти узкие места. Это самые слабые звенья во всей производственной цепочке, те моменты, которые тормозят завершение проектов.

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

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

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

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

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

Главные принципы инклюзивного дизайна 

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

Чтобы соответствовать высокому уровню доступности по WCAG, необходимо придерживаться 4 принципов.

1. Воспринимаемость

• Всегда должна быть текстовая альтернатива нетекстовому контенту.

• Капча должна быть представлена в нескольких формах.

• Нельзя пренебрегать контрастностью.

2. Понятность

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

3. Управляемость

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

4. Надежность

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

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

Как мы определяем грейд руководителей проектов

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

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

Для подготовки к тесту достаточно нашей Wiki, базы знаний. Все регламенты в ней разбиты по уровням: как раз для джунов, миддлов и сеньоров. На сегодняшний день у нас более 200 вопросов для разных уровней. Но на самом «экзамене» ответить нужно на 20. Тестирование проходит онлайн в системе INDIGO.

В тестах мы используем вопросы разных типов: с одним ответом, с несколькими, с полем для свободного ввода. У каждого вопроса свой вес. Считается, что успешно пройденный тест — это 80% правильных ответов. Любой вопрос можно разобрать после тестирования. А если сотрудник не согласен с результатом — то и оспорить.

Плюсы такой системы:

• помогает адаптировать стажеров;

• помогает менеджерам проанализировать свой опыт;

• мотивирует больше читать и погружаться в профессию;

• она не привязана к зарплате и не давит на человека;

• позволяет в игровой форме запоминать регламенты.

Кроме того, тестирование помогает нам улучшать качество базы знаний. Как — рассказываем в нашем блоге.

Прекрасный и ужасный Kubernetes

Сегодня на очереди пост по докладу Василия Мермера из Fland о кубернизации приложений. В полной версии Василий в деталях рассказывает о плюсах и минусах Kubernetes, о критериях хорошего приложения и его жизненном цикле.

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

? Помещают внутрь Supervisorctl несколько процессов.

? У каждого свои лог-файлы для разных мест.

? Состояние лежит рядом в виде файла.

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

Чтобы ехать хорошо и быстро, нужно правильно написать, собрать и доставить код.

? Если конвейер CI/CD построен правильно, мы успешно доедем до финиша.

? Чтобы было куда доставить код, нужен правильно приготовленный Kubernetes.

? Приложение должно быть написано в соответствии с 12 факторами:

? И еще 7 факторами:

• наблюдаемость (observable);

• прогнозируемость (schedulable);

• обновляемость (upgradable);

• минимальные привилегии (least privilege);

• контролируемость (auditable);

• защищенность (securable);

• измеримость (measurable).

Финансовые и нефинансовые системы мотивации

Это главные тезисы доклада Андрея Рыжкина, консультанта AGIMA, с митапа «TeamLead: Как управлять командой разработки и качеством на проекте». Мы подготовили серию таких постов, и сегодня делимся первым.

Профессиональная мотивация соотносится с уровнями пирамиды потребностей Маслоу, известной нам еще со школы:

Для мотивации на каждом уровне можно использовать финансовые и нефинансовые инструменты. И вот какие.

1. Физиологические потребности

?Финансовые инструменты: уровень зарплаты. Если сотрудник получает достаточно, он думает о более высоких потребностях по пирамиде.

?Нефинансовые инструменты: нет переработок и проблем с рабочим местом. Если работать приходится 24/7 — нет времени на сон и остальную жизнь. Мотивация падает.

2. Защищенность

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

3. Принадлежность

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

4. Уважение

? Индивидуальные премии.
? Авторитет в компании, карьерный рост, корпоративные подарки.

5. Самоактуализация

? Премия по показателям компании/отдела/команды.
?Руководящая должность, партнерство, признание в экспертной среде, социальная значимость работы.

Платформенные интеграции во Flutter

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

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

Сперва нужно выбрать тип канала в зависимости от потребностей:

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

• EventChannel: для передачи потоков данных из нативного кода во Flutter.

• BasicMessageChannel: для отправки простых сообщений между Flutter и нативным кодом.

Для интеграции нативных SDK чаще всего используют MethodChannel:

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

class CartPage extends StatelessWidget {
  static const MethodChannel _channel = MethodChannel('co.wawand/stripe');

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      // Widget...
    );
  }
}

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

Что такое матрица компетенций и зачем она нужна

Матрица компетенций (МК) — инструмент управления рисками. Она помогает распределять ресурсы, определять грейды спецов и мотивировать команду.

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

Например, у вас работают три человека. Каждый должен уметь верстать (навык 1), дизайнить (навык 2) и вести переговоры (навык 3). Судя по МК из нашего примера, Дарья не очень хорошая верстальщица, зато хороший дизайнер и менеджер. Михаил тоже поможет с дизайном, но в нашем случае ему мы доверим верстку. Таким образом МК показывает реальную расстановку сил в коллективе.

Как использовать МК:

• МК помогает сбалансировать навыки в команде. По таблице вы поймете, что ваша команда делает хорошо, а что плохо. В соответствии с этим вы будете выбирать проекты, набирать команду или обучать коллег.

• С помощью МК можно мотивировать сотрудников. Таблица с навыками удобно перекладывается на систему грейдов. Планировать развитие каждого члена команды проще.

• С помощью МК удобно бороться с Bus-фактором. Это ситуации, когда все ключевые навыки сосредоточены в руках одного человека. Матрица это наглядно покажет.

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

Идеальная продуктовая команда

Пост про идеальный состав продуктовой команды. Но сперва давайте выясним, а нужна ли вам она вообще?

Мы считаем команду продуктовой, если:

• она работает над одним продуктом/его частью;

• можно прогнозировать работу команды;

• она имеет необходимые компетенции для запуска продукта и его развития;

• она стремится к самоорганизации.

Такая команда вам не нужна, если:

• Ваша компания бюрократизирована. Согласовать изменения — это как пройти через все круги ада. А задачи появляются и приоритизируются, потому что «так сказали сделать наверху».

• У вашего продукта есть конечная цель. Например, имиджевый сайт, который нужно запустить, но развивать не планируется (только актуализировать контент и поддерживать).

• Ваш продукт — это пока неподтвержденная гипотеза. Только ПОСЛЕ ее валидации стоит собирать Product-команду, ДО — рановато.

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

Вот базис продуктовой команды:

Но такая команда встречается нечасто, т. к. требует значительных финансовых затрат.

Продуктовая команда — единственно правильный вариант, когда «страшно, очень страшно, если бы мы знали, что это такое. Мы не знаем, что это такое». То есть, когда нужно запускать и развивать продукт, но непонятно, куда и как.

Подробнее об этом поговорим на онлайн-митапе «Как разрабатывать продуктовую стратегию» 29 марта в 18:00. Детали и регистрация тут.

5 полезных расширений VScode для работы с документацией

1. Draw.io Integration
   
   Хорошо подходит для работы со сложными диаграммами: сперва можно создать диаграмму в десктопной версии Draw.io, а потом доработать ее в VScode с помощью расширения Draw.io Integration.

2. Quarto
   
   Quarto — крутая штука для работы с документацией под R, Python, Julia и Observable. Расширение Quarto для VScode поможет редактировать и рендерить QMD-файлы. В нем есть режим предварительного просмотра, который позволяет менять код документа и одновременно просматривать результат.

3. Jupyter
   
   Jupyter — один из самых популярных фреймворков для создания заметок, особенно в Python. Кстати, Jupyter классно работает вместе с документацией Quarto для Python. Расширение VScode Jupyter интегрирует заметки Jupyter в редактор VScode и поддерживает ipynb-файлы.

4. Markdown All in One
   
   С расширением Markdown All in One удобно редактировать документацию в формате Markdown. Оно располагает два окна рядом: редактор кода и тут же результат.

5. Mermaid
   
   Mermaid особенно полезен, если вам нужно создать структуру кодовой базы или динамическую диаграмму. В VScode есть два расширения для работы с файлами Mermaid — Mermaid Preview и Markdown Preview Mermaid Support.

Этот топ расширений составил автор этой статьи, а ее перевод читайте у нас в блоге.

Как джуниору найти работу, если опыта — ноль

Стажировка — для продуманных

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

Нюансы: зачастую стажерам не платят или платят мало — нужна подушка безопасности.

Курсы — для общительных

EdTech — это не только про знания, но и про связи. Если повезет, ментор позовет на стажировку. Правда, для этого нужно сильно выкладываться. Зато некоторые платформы сами устраивают студентов на практику.

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

Пет-проект — для самостоятельных

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

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

Тестовые задания — для терпеливых

Мы уже рассказывали про тонкости работы с тестовыми. Ключевой момент тут — можно набраться опыта прямо на выполнении подобных заданий. Рано или поздно очередное тестовое «выстрелит». 

Нюансы: далеко не всем важно длинное портфолио, а тестовое покажет ваши способности.

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

Выбираем продуктовые метрики на примере мобильного приложения для грузоперевозок

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

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

2. «Разбиваем» процесс взаимодействия с приложением на ключевые этапы: регистрация, размещение заказа, поиск перевозчика, выполнение заказа и т. д.

3. Определяем метрики на каждом этапе через призму эффективности каждого. Например:

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

• Размещение заказа — оцениваем среднее количество заказов на пользователя, время, которое требуется пользователям для размещения заказа, процент пользователей, не завершивших размещение.

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

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

Больше об этом в нашем тг-канале.

Фишки Google Apps Script

Недавно мы выпустили большую статью про полезные фишки Google Apps Script. Делимся одним из примеров, как с помощью API-запроса можно тянуть данные из таск-трекера и CMS (у нас Bitrix) и интегрировать их в любые таблички. Пример в формате JS:

/** Функция обращения к таск трекеру по API */
function taskTrackerAuth() {


 const sourceUrl = 'https://your_taskTracker_url/rest/tempo-timesheets/4/worklogs/search';
 const options = {
   'headers': { 'Authorization': 'Basic *******************' },
   'method': 'post',
   'contentType': 'application/json',
   'Accept': 'application/json',
   /** Полезная нагрузка настраивается индивидуально, то что указано тут можно очистить */
   'payload': JSON.stringify({'from': [],'to': [], 'worker': [], 'projectKey': [], 'taskKey': [], 'filterId': [] }),
 }


 const taskTrackerResponse = UrlFetchApp.fetch(sourceUrl, options);
 const data = JSON.parse(taskTrackerResponse.getContentText());


 //Вывод сообщения о получении данных
 if (data.length > 0) {
   SpreadsheetApp.getActiveSpreadsheet().toast('Данные Timesheets получены', '(V)_O_o_(V)', 2);
 } else {
   SpreadsheetApp.getActiveSpreadsheet().toast('Данные Timesheets не получены', '(V)_O_o_(V)', 2);
 }
}

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

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

Мобильные сторы: что учитывать при деплое

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

Собрали в таблице основные нюансы:

Больше о подготовке к деплою и о требованиях к приложению — в нашей статьей. А про новости мобильной разработки — в телеграм-канале.

Адаптация в новой бизнес-отрасли по Фейнману

Быстрое погружение в новую предметную область — необходимый скилл продакта в агентстве. Делимся классной методикой дип-дайва в контекст продукта. Ее автор — Ричард Фейнман.

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

2. Выявляем пробелы и восполняем их
   
   Поиск пробелов потребуется для ресерча, пополнения нашего банка знаний и его систематизации. Тут нам как раз потребуется артефакт из первого шага.

3. Объясняем ребенку
   
   Представьте, что вам нужно рассказать про новую предметную область десятилетнему ребенку. Придется отбросить сложную терминологию и объяснить всё кратко — у детей невысокая концентрация внимания. Если гипотетический ребенок вас поймет, вы разобрались в теме.

4. Рассказываем историю
   
   Объединяем свои записи в одну историю, переходим от простого к более сложному и раскрываем основную идею. Помним про простоту и краткость, но метафоры и примеры тоже пригодятся. Можно сделать аудиозапись своего рассказа и прослушать ее. Стоит обратить внимание на неоднозначные формулировки и на эпизоды, где вы сбиваетесь. Это маркеры тех мест, которые нужно проработать.

Метод Фейнмана несложный, полезный и универсальный. Так что, рекомендуем.

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

Как меняется рынок мобильной разработки в 2024 году

Наш Head of Mobile Миша Вассер вместе с другими экспертами мобильной разработки ответил на вопросы Практикума о трендах сферы и прогнозах на этот год. Собрали в этом посте главное.

1. У iOS-разработки есть будущее
   
   Apple вносит послабления в свои ограничения. Недавно платформа разрешила российским разработчикам принимать платежи вне App Store. Возможно, вскоре iOS-разработчикам вновь станет проще жить.

2. Flutter — лидер кросс-платформы
   
   В 2023 году доля кросс-платформенной разработки увеличилась с Flutter во главе. Но нативная разработка всё-таки перевешивает — ее по-прежнему выбирает бигтех и частично средний бизнес.

3. RuStore набирает ход, а вот российские ОС нет
   
   RuStore приземлила у себя крупные бренды, например Сбер и Альфа-Банк, и развивает собственные инструменты для разработчиков по примеру Google. А вот отечественные операционки затихли. «Аврора» и «РОСА Мобайл» будто сами тормозят развитие внутренними ограничениями.

4. SwiftUI продолжит набирать популярность
   
   Тренд на SwiftUI у нас пока до конца не оформился, и UIKit всё еще востребован. Но с каждым обновлением SwiftUI становился всё лучше.

5. Битва Compose и XML
   
   Compose чаще встречается в вакансиях, некоторые компании переходят на него: он удобнее и функциональнее. Но XML пока остается базой.

Ссылку на полный материал оставили выше. А если хотите больше новостей о мобильной разработке, заглядывайте в телеграм-канал Саши Ворожищева, Head of Flutter/iOS.  

Путь к успешному продукту: User-Centric Thinking

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

Почему это важно?

• Увеличение лояльности
  
  Логичная цепочка: у пользователей была проблема → ваш продукт ее решил → вы получили лояльных пользователей.

• Снижение рисков
  
  Чем больше мнений пользователей вы соберете, тем ниже риск создать невостребованный продукт.

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

Давайте проверим, насколько вы User-Centric :)

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

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

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

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

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

Три основных принципа работы с иконками

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

Принцип 1. Визуальная связанность

Все иконки должны иметь общий визуальный стиль. Определите общие элементы: например, форму, толщину линий и пропорции. Уделите внимание цветовой схеме и уровню детализации.

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

• скругления углов;

• диагональные элементы;

• симметричность;

• замкнутые/незамкнутые контуры;

• наслоение элементов;

• принципы заливки элементов.

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

Принцип 2. Разборчивость иконки

Иконка должна быть читаема в любых размерах. Вот наглядный пример:

Принцип 3. Понятный и простой образ

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

Все правила работы с иконками собрали в этой статье. А еще мы иногда показываем примеры классных иконок в телеграм-канале нашей дизайн-команды. Приходите :)