Хотим еще больше работ на конкурс маскота для RUNIT

Полным ходом идет конкурс на создание маскота для фестиваля IT и спорта RUNIT, и нам уже прислали около 20 супермилых персонажей, которых мы с удовольствием разглядываем всей командой. Но нам этого мало. Уверены, тема раскрыта еще не полностью и впереди много классных идей и героев. Подать работу можно до 26 мая включительно — так что присоединяйтесь.

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

В конкурсе будет три призера: за третье место дарим 20 тысяч рублей, за второе — 30 тысяч, за первое — 50 тысяч. Но самое важное — что вашего перса увидят тысячи участников RUNIT.

Все условия конкурса подробно изложены на платформе Illustrators. Там же можно подать работу. Так что ничего не бойтесь, живите здесь и сейчас и присылайте свои варианты. Это будет классное приключение!

Три точки зрения на работу поисковиков

Ответ на вопрос о том, как работают поисковые системы, зависит от того, у кого вы спрашиваете. Рассмотрим верии основных носителей знаний.

🟢 Официальные представители поисковиков: поисковик — это библиотекарь

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

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

🟢 Инженеры: поисковик — интеллектуальный помощник

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

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

🟢 SEO-специалисты: поисковик — это сад

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

Мышление SEO — это постоянные эксперименты и адаптация к новым условиям, ведь «климат» в саду постоянно меняется.

А подробнее о том, как работают поисковики, рассказываем в нашем блоге. Там найдете ссылки на кейсы специалистов, разборы утечек Google и цитаты инженеров.

Что такое чистая архитектура: основные особенности

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

Какие еще свойства чистой архитектуры важны:

1. Тестируемость. Это значит, что бизнес-правила могут быть протестированы без UI, без баз данных, без веб-сервера и без любого другого внешнего компонента. Например, у нас может быть фронтенд на React и мобилка на Flutter — и мы при этом всё равно можем менять контракты, не меняя бизнес-правила.

2. Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится. 

3. Чистая архитектура — это независимость от внешнего сервиса. По факту слой use-кейсов изолирован от внешнего мира, ничего о нем не знает. А знает только о том, как работать в рамках бизнес-системы.

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

Чем полезна ротация разработчиков внутри компании

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

Разберем, как это работает:

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

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

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

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

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

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

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

Колобок как MVP: как запустить продукт и сделать так, чтобы тебя не съели на рынке

По сюжету сказки дед и бабка собрали остатки муки и испекли Колобка, но он сбежал в лес. Там ему встретились заяц, волк и медведь. Колобок пел песню, которая отвлекала зверей, и они его отпускали. А лиса не отпустила и съела.

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

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

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

Что важно помнить при разработке такого MVP, разберем на примере нашей сказки.

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

2. Работайте на репутацию. Во время тестирования Колобок никому не достался. Это частое переживание продуктологов: «Как быть, если продуктом заинтересуются, а его на самом деле пока нет». Звери остались в недоумении, но на реальных пользователей лучше произвести хорошее впечатление. Это будущая целевая аудитория — ею стоит дорожить, а не бежать от нее в лес.
   
   🔹 Совет: предлагайте пользователям любые плюшки, которые можете позволить. Это может быть промокод при условии предзаказа, благодарственное письмо или персонализированный сервис. Мелочь, а приятно.

3. Создавайте ценность для своей ЦА. Колобок румяный и привлекательный. Ни один зверь не прошел мимо него, потому что Колобок предлагал реальную ценность — как минимум, возможность утолить голод чем-то вкусным.
   
   🔹 Совет: ваш MVP должен решать конкретную проблему пользователя. Без реальной ценности он никому не нужен. Спросите себя: зачем клиентам ваш продукт? Если не можете ответить — дорабатывайте идею.

4. Запускайте быстрее — идеального старта не бывает. Над Колобком не сидели годами, шлифуя рецепт. Сделанный на скорую руку из остатков муки, он выкатился и сразу начал тестироваться.
   
   🔹 Совет: не тратьте месяцы на доводку продукта. Чем быстрее запуститесь, тем раньше узнаете, что нужно исправить. Первый блин комом? Отлично, зато теперь знаете, как делать лучше.

5. Работайте с обратной связью. Всем зверям Колобок явно пришелся по вкусу, и они хотели бы его съесть. Но готовы ли они за него платить и, если да, то сколько? Можно было бы установить цену и тестировать её от встречи к встрече. Лиса съела валявшегося в листьях Колобка, но купила бы его за деньги в следующий раз?
   
   🔹 Совет: Собирайте и анализируйте обратную связь от пользователей — они ваши тестировщики. Узнайте, что они думают о продукте, и спросите, сколько готовы платить.

6. Анализируйте неудачи — это тоже результат. Автономная доставка дала сбой — Колобка съели за бесплатно. Но в этом тоже есть урок: бабка и дед не учли риски и не подготовились к критическому сценарию.
   
   🔹 Совет: большинство MVP «съедают», но это не провал, а обучение. Разбирайте ошибки, улучшайте продукт, и следующий запуск будет сильнее. Может, Колобок 2.0 обзаведется броней от хищников или встроенным анти-лисиным радаром.

P. S. Мы увлеклись таким форматом и уже разобрали основы риск-менеджмента на «Репке» и дали советы по информационной безопасности в сказке «Волк и семеро козлят».

7 очень вредных советов для тимлида

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

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

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

3. Делайте всё сами, так легче и быстрее. Ну а кто, если не вы? На объяснение задания вы потратите больше сил и времени, а так всё сделаете самостоятельно — и дело в шляпе.

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

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

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

7. Пресекайте неформальное общение в команде — это мешает работе. Поболтать о всяком можно и в свободное время. А в рабочих чатах и тем более в офисе не кружок по интересам.

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

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

Управление проектами, особенно в аутстаффинге, это не то, чему учат в школе или универе. Об этом не пишут учебники, не снимают документалки на 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. Джуны лояльнее к компании. Если всё сделать правильно, то джуниор останется в компании надолго. Так вы экономите на найме и закрываете на будущее вопрос с высококвалифицированными кадрами.

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