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

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

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

• «Наруто» учит преодолевать сложности, связанные с адаптацией специалиста в новой команде и с его онбордингом. Вспомните, как наставник Какаши объяснял Наруто правила команды 7.

• «Моя геройская академия» учит разрешать конфликты и строить доверительные отношения. Например, Аизава и Всемогущий проводят регулярные 1-to-1 с учениками.

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

• «Атака титанов» учит создать все условия для того, чтобы заказчик давал полную и своевременную обратную связь исполнителю. Так, например, поступают командиры, когда бывают недовольны отрядами.

• «Тетрадь смерти» учит минимизировать риски утечки данных и строго соблюдать юридические нормы. Помните, как Кира внушал союзникам, как важно следовать его инструкциям? 

• «Магическая битва» учит тщательно подбирать специалистов под запрос клиента. Например, учитель Годзё подбирает под каждую миссию тех учеников, чьи компетенции позволят решить задачу эффективнее всего.

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

• «Токийские мстители» учит выстраивать диалог со сложными ЛПРами. Такимичи вынужден то и дело договариваться с другими персонажами, чтобы изменить события будущего. И в этом ему помогает гибкость.

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

4 совета, как начать цифровую трансформацию бизнеса и не утонуть в ней

По статистике BCG, 70% проектов цифровой трансформации терпят неудачу. Чтобы попасть в успешные 30%, нужно продумать роадмап изменений до мелочей и учесть кучу факторов. Собрали четыре совета, как сделать этот путь проще и эффективней.

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

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

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

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

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

🌱Объясняем основы риск-менеджмента на репке

В известной русской сказке один дед посадил репку. Она выросла огромной, дед решил вытащить её, но не смог — в одиночку такой проект просто так не затащить. Тогда он собрал команду: позвал бабку, внучку, Жучку, кошку и мышку. Только благодаря командной работе дед справился с задачей.

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

🔮 Риск роста: будь готов к неожиданностям
Когда дед инициировал проект (сажал репку), он вряд ли предполагал, что она вырастет такой огромной. В реальной практике проект вида «репка-переросток» встречается не так уж и редко. Мог ли дед что-то с этим сделать? Конечно мог! 

Что можно сделать:

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

• На этапе планирования ответить на вопрос «а что нам будет нужно, если…?» и строить планы с учетом возможных рисковых событий. 

• Основываясь на риск-плане, сформировать резерв ресурсов — времени, денег и прочего. Например: «Сколько времени понадобится дополнительно, если репка будет зреть долго?», «Кто в итоге участвует в сборе урожая?» и так далее.

👥 Риск недооценки команды: отсутствие подготовки
Деду пришлось собирать команду по ходу дела. Если бы он сразу оценил возможные сложности, подготовил ресурсный план и заранее распределил роли, то, возможно, всё прошло бы быстрее.

Хорошо, что у нашего деда была добротная инхаус-команда дома. Но вот как бы выкрутился из этой ситуации его одинокий престарелый сосед? Брал бы аутстаф/аутсорс у нашего героя? Или так бы и бросил свой проект, не собрав урожай?

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

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

Что можно сделать:

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

• Убедитесь, что все участники понимают задачу и готовы приступить к работе.

🧩 Риск несогласованности: тянуть в разные стороны
В сказке все участники тянули за одну сторону репки, что обеспечило успех. А вот в IT-проектах часто возникает «перетягивание каната» — каждый тянет в свою сторону.

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

Что можно сделать:

• Заранее определить подход и технологии.

• Убедиться, что цели и задачи понятны всей команде.

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

⚠️ Риск упущенных возможностей: вовремя привлечь помощь
Мышку позвали в последнюю очередь, хотя ее вклад оказался решающим. А ведь иногда именно «незаметные», но важные участники команды (например, аналитик или DevOps) могут посоветовать лучшее решение.

Что можно сделать:

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

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

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

P. S. Первый пост из этой серии — про инфобез и семеро козлят.

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

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

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

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

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

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

• Вывод 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. В чем суть: теперь, когда на предприятие нашего заказчика привозят груз, его принимает не человек, а система на основе искусственного интеллекта.

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

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

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

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

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

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

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

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