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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как составить резюме по методу бутерброда

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

1. Упаковка. Оформление

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

2. Первый слой

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

3. Начинка. Опыт работы

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

4. Срок годности. Актуальность

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

5. Реклама бутерброда. Сопроводительное письмо

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

Еще больше советов и лайфхаков от HR — в этой статье. А мы ждем ваши резюме-бутерброды на hr@agima.ru.

Главные особенности новых версий Dart и Flutter

В конце прошлой недели вышло сразу два заметных релиза: Dart 3.3 и Flutter 3.19. Объединили самое интересное в один небольшой пост.

Что нового в Dart:

• Добавили Extension types. С их помощью можно оптимизировать код, который зависит от производительности.

• Интегрировали новую модель взаимодействия с библиотеками JavaScript и заодно добавили пока экспериментальную поддержку WebAssembly во Flutter Web.

• Google выпустил бета-версию Google AI Dart SDK. Так что теперь гипотетически можно интегрировать функции искусственного интеллекта в приложения на Dart или Flutter. Но России в доступных регионах пока нет.

Что нового во Flutter:

• Изменения в скролле. Тут завезли оптимизацию и гибкость в управление поведением.

• Виджет AnimationStyle. Он позволяет юзерам менять стандартное поведение анимации в виджетах. А разработчики с его помощью могут переопределять кривые и продолжительность анимации.

• Adaptive Switch. Компонент выглядит и ведет себя как нативный на macOS и iOS, а в других случаях — как Material Design. При этом он не зависит от библиотеки Cupertino, поэтому у него один и тот же API на всех платформах.

Также недавно мы рассказывали про условные выражения в Dart, про анимацию переходов и про то, как быстро настроить GitLab CI/CD на Flutter-проекте. Подписывайтесь на наш блог, чтобы следить за новостями.

Каким был генеративный дизайн в СССР

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

У нас же генеративный дизайн начали развивать еще в 20 веке. Называлось это кибернетическим искусством. Один из интересных его примеров — ASCII-арт. Это изображения, созданные с использованием символов, цифр, букв или знаков. Мы и сейчас применяем что-то наподобие в переписках — ¯\_(ツ)_/¯. Но в советские годы изображения были, конечно, сложнее.

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

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

Особенности тестирования приложений на Flutter

Тестирование Flutter-приложений в базовых принципах не сильно отличается от тестирования нативных. Но есть несколько интересных особенностей:

• Все элементы Flutter-приложения — виджеты: это упрощает тестирование интерфейса и функциональности, обеспечивает единообразие интерфейса.

• Тестирование на Flutter быстрее: платформенно-специфические функции тестируются отдельно на iOS и на Android, а остальные — на какой-то одной.

• Flutter предоставляет собственные инструменты для тестирования виджетов и интеграционного тестирования.

Есть и сложности:

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

• При тестировании различий UI/UX на разных платформах мы замечаем типичные проблемы: анимация, свайпы и отображение системных диалоговых окон.
  
  Поэтому не стоит фокусироваться на всех кнопках. Лучше обращать внимание только на существенные различия. Тут помогает общение с сообществом.

Чтобы работать с Flutter-приложениями, мы используем FlutterDevTools. Это комплект инструментов для отладки и профилирования в экосистеме Flutter. Также применяем голден тесты, а для автоматизации — Appium. Подробнее про это рассказываем в отдельной статье, а про Flutter — в телеграм-канале.

По сети поползли слухи, что в новой версии iOS поменяется дизайн. Вот что известно:

• Журналисты пишут, что iOS 18 и iPadOS 18 будут визуально напоминать операционную систему гарнитуры Vision PRO.

• В приложении Apple TV на iPadOS 18 появится полупрозрачная боковая панель (такую же в прошлом году уже добавили в приложение tvOS 17.2).

• Дизайн обновится у большинства системных приложений, в том числе у Safari.

• Пока это только слухи, официально Apple представит iOS 18 только в июне.

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

Откуда слухи: [тык].

Value Proposition: ключ к сердцу клиента

Value Proposition (VP) или ценностное предложение — это обещание ценности, которое мы даем клиенту. Это не просто список функций или характеристик продукта, а скорее ответ на вопрос о том, почему клиент должен выбрать именно наш продукт.

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

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

• Объяснить уникальность.
  Чем ваш продукт отличается от конкурентов? Определяем и подчеркиваем это.

• Обеспечить простоту и ясность.
  Предложение должно быть понятным и запоминающимся. 

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

Value Proposition — это не просто маркетинговый слоган, это основа стратегии продукта. VP должно отражаться в каждом аспекте продукта: от разработки до маркетинга.

Для формирования VP очень важно исследовать CX и UX, чтобы лучше понимать боли и желания клиентов. Это поможет сформулировать то самое VP, которое будет взывать к их сердцам и умам.

С удовольствием обсудим примеры удачных и неудачных VP в комментариях. А больше о цифровых продуктах — в нашем канале.

Сжатие графика проекта: 8 способов сэкономить время и ресурсы

Несколько приемов, которые помогут управлять временем и ресурсами на проекте с максимальной эффективностью:

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

2. Увеличение ресурсов. Расширение команды или распределение дополнительных ресурсов могут ускорить выполнение задач.
   

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

4. Упрощение задач. Некоторые задачи можно упростить без ущерба для качества. Пересмотрите требования и найдите более оптимальные решения.
   

5. Сжатие времени в критических задачах. Задачи критического пути можно ускорить с помощью дополнительных ресурсов и внимания. Это может включать работу во внеурочные часы или выходные дни.
   

6. Применение Agile. Agile-подход позволяет гибко реагировать на изменения и фокусироваться на приоритетных задачах, ускоряя разработку.
   

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

8. Пересмотр процессов. Иногда сжатие графика проекта требует пересмотра и оптимизации процессов внутри проекта или компании.

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

Техдолг

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

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

Технический долг — это не просто плохо написанный код. Это любые решения, которые упрощают жизнь сейчас, но могут создать большие проблемы в будущем. Лучше думать о нем, как о чем-то, к чему ты НИКОГДА не вернешься. Пока не наступит момент, когда без глобального пересмотра архитектуры не обойтись.

Как мы объединили два разных екома в одну CRM

Оба интернет-магазина — назовем их А и Б — годами работали самостоятельно, накопили много контактов и клиентов, а потом объединились в одну компанию. Чтобы выстроить продажи, им нужна была общая база данных. Но стек у магазинов отличался, и понадобилась наша помощь.

Помимо стека, были и другие ограничения:

Срок MVP: на всё про всё — полгода.

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

Удобство: нужен был сервис одного окна с понятным интерфейсом.

Поэтому мы остановились на Bitrix24. Первым делом определили, что должно быть в общей CRM и какие данные нам нужны. Потом на этапе ППО выбрали механизм реализации — процесс ETL (Extract. Transform. Load). Он состоит из трех этапов:

• извлечение данных из имеющихся баз,

• преобразование их под новую бизнес-модель,

• загрузка в новую CRM.

>> Подробно про каждый этап рассказываем в отдельной статье.

В итоге пришли вот к такой архитектуре: 

Как видим, у нас было три экстрактора: общий для магазина А и два отдельных для магазина Б (один для Kafka, другой для Json). Два трансформера — для каждого магазина свой, они выдавали одинаковые DTO и передавали их в лоадер. Дальше лоадер закидывал всё в B2B CRM.

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

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

User Guides (руководство пользователя): нужны ли они вообще или это что-то на древнем?

Интуитивно понятные интерфейсы и ML успешно вытеснили пользовательские гайды. Но есть случаи, когда User Guides необходимы:

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

• Инновационные продукты. Новые технологии могут требовать объяснений и инструкций в формате полноценного руководства.

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

1. Видеоуроки и вебинары
   
   ✚ Наглядность, личное общение, возможность задать вопросы
   ✔ Для сложных продуктов, где важно показать процесс в динамике
   

2. FAQ и База знаний
   
   ✚ Доступность, структурированность информации
   ✔ Для продуктов с большой пользовательской базой и типовыми вопросами
   

3. Интерактивные туториалы
   
   ✚ Обучение в процессе использования, «обучение через действие»
   ✔ Для приложений и ПО, где пользователю важен быстрый старт работы
   

4. Чат-боты и виртуальные ассистенты
   
   ✚ Мгновенная помощь, персонализация общения
   ✔ Для сервисов, где важна оперативная поддержка пользователя
   

5. Сообщества
   
   ✚ Обмен опытом, поддержка со стороны сообщества
   ✔ Для продуктов с активными пользователями, готовыми делиться опытом и помогать друг другу
   

6. Инфографика и чек-листы
   
   ✚ Краткость и наглядность
   ✔ Для простых инструкций и напоминаний о ключевых функциях продукта

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

Что такое «авторента» и как она изменила нашу жизнь

«Авторентой» мы назвали инструмент для автоматизации расчета рентабельности.

Мы работаем по формуле «рентабельность всей компании зависит от рентабельности каждого проекта». Поэтому на показателе рентабельности завязана мотивация примерно 60% сотрудников AGIMA.

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

• Справочник для «авторенты». Здесь ставки, роли, привязка пользователей FinPlan и таск-трекера.

• Таск-трекер с подсчетом отработанных часов.

• Finplan для управленческого учета.

• Harvester всё объединяет и проводит первые расчеты. 

• Дашборды тимлидов и РП, где они отслеживают экономику каждого проекта.

• Распределятор. Хранит данные по всем дашбордам тимлидов и РП и распределяет внутренние затраты между проектами.

Результаты:

• Теперь закрываем квартал в среднем за месяц.

• Экономим сотни часов на расчете рентабельности.

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

• Появился полезный сайд-проект — дашборд простоев, — где видим количество «потерянных» денег.

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

Полная версия статьи тут. А больше полезного о рентабельности, метриках и планировании ищите в нашем телеграм-канале для агентств.

Мнение: почему мультиплатформа Kotlin не приживется в мире разработки

Спойлер: из-за нелюбви к изменениям и дефицита специалистов.

Наш руководитель направления Flutter и iOS Саша Ворожищев делится основными тезисами статьи о судьбе Kotlin Multiplatform Mobile (KMM). Автор статьи — разработчик Донн Фелкер (Donn Felker) — не пророчит KMM мировой славы. И вот почему.

• Люди не любят что-то менять. Особенно программисты. Редко встретишь iOS-разработчика, который перешел на Android. И наоборот.

• Кросс-платформа чаще не оправдывает надежд. Мы уже не раз наблюдали попытки создать кросс-платформенные суперхиты — взять к примеру Flash и ActionScript, Mono и Xamarin, —  но ни одна из этих технологий так и не покорила мир программирования.

Сейчас конкуренцию КММ может составить только Flutter. Пока это лучшее кросс-платформенное решение.

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

• Универсальность != эффективность. Здесь стоит повторить, как важно подбирать правильные инструменты для решения конкретных задач. Мультиплатформа не может быть панацеей для всех проблем.

Полную версию статьи читайте тут.

А больше про технологии и разработку найдете в телеграм-канале Саши. Приходите, там интересно :)

Опросник SUS для измерения юзабилити

SUS (System Usability Scale) — это стандартизированный опросник для оценки общего юзабилити продукта.

Он состоит из 10 утверждений. Пользователи оценивают, насколько согласны с каждым из них. С SUS можно измерить, например, легкость использования, «понимаемость» и удовлетворенность продуктом.

Как это работает?

Например, наш продукт — это сайт. Предлагаем пользователям 10 утверждений о нем:

1. Я буду использовать этот сайт.

2. Сайт слишком сложный.

3. Сайтом легко пользоваться.

4. Мне понадобится помощь, чтобы научиться пользоваться сайтом.

5. Разные функции сайта правильно сгруппированы.

6. На сайте слишком много несоответствий.

7. Большая часть людей очень быстро поймет, как пользоваться сайтом.

8. Сайт очень трудно использовать.

9. Я уверенно себя чувствовал(а), используя этот сайт.

10. Мне пришлось многому научиться, прежде чем я смог(ла) работать с сайтом.

Просим оценить, насколько пользователи согласны с каждым из утверждений по шкале от 1 (совершенно не согласен) до 5 (полностью согласен).

SUS = (Σбаллов по всем вопросам - 10) ∗ 2,5

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

• Балл < 50: пользователи считают продукт неудовлетворительным.

• Балл от 50 до 70: пользователи считают продукт приемлемым, но есть место для улучшений.

• Балл > 70: пользователи считают продукт хорошим.

P. S. Больше о работе с диджитал-продуктами в нашем телеграм-канале. Приходите :)

Запуск нового проекта: когда Time and Materials дороже Fixed Price, и на что лучше потратить эту разницу

Недавно мы сравнили модели Fixed Price и Time and Materials на примере типичного среднего проекта: прошлись по всем этапам и проследили, как меняется бюджет от пресейла до релиза.

В нашем примере проект по T&M вышел примерно на 5 миллионов дороже, чем Fixed Price проект. При этом проект по T&M получился более продуманным. Но мы считаем, что это не стоит таких сверхвложений.

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

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

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

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

Полную версию этой статьи найдете тут. А об управлении проектами читайте в нашем телеграм-канале.

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

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

В AGIMA мы планируем на три месяца вперед: текущий месяц + 2 следующих. Именно на этот период все менеджеры должны четко понимать, чего ждать от своих проектов: какой бэклог у заказчика, будут ли перестановки в команде, когда согласуем финальный результат и получим акты?

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

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

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

Со временем такие вопросы превращаются в чек-лист для самоконфликта. Вопросы могут отличаться, но их объединяет сомнение «Уверен ли я, что…».

В полной версии статьи еще больше примеров — читайте ее здесь.

P. S. Мы много пишем об управлении проектами в нашем тг-канале. Так что приходите, если интересно)

Изучаем анимацию переходов во Flutter

Пересказ большой статьи в маленьком посте.

Существует много типов анимации для Flutter-приложений. Среди них — Rive-анимация, Hero animations, Progressindicator и т. д. С их помощью можно создавать кастомную анимацию для любого вида работ с системой. Но наиболее базовое решение — библиотека Animations.

Она предоставляет стандартные анимации Material Design. Система движений Material Design состоит из четырех паттернов для перехода между компонентами. Вот они:

• Container Transform. Он предназначен для переходов между элементами интерфейса, включающими контейнер. Паттерн создает видимую связь между этими элементами.

• Shared Axis. Его используют для переходов между элементами пользовательского интерфейса, имеющими пространственную или навигационную связь. Паттерн использует общую трансформацию по осям X, Y или Z для усиления взаимосвязи между элементами.

• Fade Through. Его используют для переходов между элементами интерфейса, не имеющими тесной связи друг с другом.

• Fade. Он для элементов интерфейса, которые входят или выходят за границы экрана. Например, диалог, который появляется и исчезает из центра экрана.

В шаблонах Shared Axis и Fade Through также нужно использовать библиотеки для навигации. В нашем случае это go_router. В Container Transform и Fade навигацию можно не использовать.

Посмотреть, как работают анимации, можно в репозитории, подробности и примеры кода — в нашей статье, а про Flutter — в телеграм-канале.

3 простых способа оценить свою стоимость на рынке труда

Способ №1. Провести исследование рынка

Для этого создано много инструментов. Например, Хабр Калькулятор покажет, какая зарплата у людей с таким же опытом, как у вас. Еще каждые полгода Хабр публикует анализ зарплат IT-специалистов. Собранная там статистика может помочь.

Чтобы посмотреть средние зарплаты по другим странам, можно воспользоваться сайтом Glassdoor. Свой калькулятор зарплат есть и у HeadHunter. Там же можно узнать средние зарплаты по рынку просто посмотрев релевантные объявления.

Плюсы: бесплатно, быстро, точно.
Минусы: без учета нюансов.

Способ №2. Развивать нетворкинг

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

Плюсы: бесплатно.

Минусы: неточно, ненадежно.

Способ №3. Поговорить с карьерным консультантом

Такие специалисты постоянно мониторят рынок и анализируют зарплату. К тому же они могут оценить ваш уровень компетенций и стоимость, а еще составить карьерную стратегию. Пройти консультацию можно, например, через Careerspace или «Эйч».

Плюсы: с учетом всех нюансов, надежно.

Минусы: дорого, иногда долго.

За вакансиями в AGIMA следите в нашем телеграм-канале.

Продакт-менеджмент: что такое PMF и как его измерять

Product-Market Fit (PMF) помогает определить, насколько продукт соответствует потребностям рынка и пользователей. Если PMF достигнут — продукт начинает приносить прибыль. Но важно помнить, что определение PMF — не финальный результат, а постоянный процесс.

Существует несколько подходов к PMF.

1. Опрос PMF — правило 40%

Эффективный способ замерить (но PMF — не метрика!) соответствие продукта рынку. Может содержать разные вопросы, но обязательным будет: «Как бы вы себя чувствовали, если бы больше не могли использовать продукт?»

Варианты ответов:

а) сильно расстроюсь;

б) немного расстроюсь;

в) не расстроюсь;

г) уже не пользуюсь.

≥40% пользователей дали ответ А — PMF достигнут.

25–40% — есть шансы достичь PMF, но нужно что-то поменять. 

<25% — скорее всего, требуется кардинальный пересмотр вижена.

2. Соотношение LTV/CAC

Другой подход к определению PMF — использовать данные аналитики. Концепция проста: PMF достигнут, когда клиенты платят больше, чем мы тратим на привлечение новых. То есть пожизненная ценность клиента (LTV) больше, чем стоимость привлечения клиента (CAC). Для достижения PMF это соотношение должно быть ≥3.

При обоих подходах нельзя упускать ключевые моменты:

• продукт должен удовлетворять потребности пользователей;

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

• продукт должен быть простым и удобным.

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