Как стать автором
Обновить
114.22
AGIMA
Крупнейший интегратор digital-решений
Сначала показывать

О дуализме качественных и количественных исследований в UX

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

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

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

Об этом можно почитать у Джеффа Соро, известного аналитика: «Вам не нужно думать об этом как о ситуации или-или. Всегда можно использовать микс методов».

Он предлагает 3 различных дизайна исследований, при которых можно комбинировать методологии:

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

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

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

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

P. S. Это часть статьи Кати Патрикеевой о мифах в UX — полную версию читайте тут.

Теги:
Всего голосов 5: ↑5 и ↓0+6
Комментарии0

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

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

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

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

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

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

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

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

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

Результаты

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

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

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии2

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

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

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

Красные виды мотивации — неоптимальные, желтые оптимальные
Красные виды мотивации — неоптимальные, желтые оптимальные

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

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

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

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

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

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

Теги:
Всего голосов 5: ↑4 и ↓1+3
Комментарии1

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

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

Если нужной статьи нет, всегда можно попросить ассистента перевести вас на оператора
Если нужной статьи нет, всегда можно попросить ассистента перевести вас на оператора

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

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

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

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

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

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

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

Теги:
Всего голосов 10: ↑7 и ↓3+4
Комментарии1

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 9: ↑9 и ↓0+9
Комментарии0

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

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

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

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

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

Кнопка-иконка в коде непонятно названа, и скринридер ее пропустил/непонятно произнес — человек не понял, что сделать
Кнопка-иконка в коде непонятно названа, и скринридер ее пропустил/непонятно произнес — человек не понял, что сделать
  • Капча должна быть представлена в нескольких формах.

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

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

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

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

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

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

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

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

Теги:
Всего голосов 11: ↑9 и ↓2+7
Комментарии1

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 10: ↑9 и ↓1+8
Комментарии0

? Компания Apple сообщила об официальном возвращении в Россию

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

  1. Компания внедрит систему привязки продаваемых устройств к местным операторам связи, аналогично тому, как это происходит в США. Покупатели iPhone и других гаджетов Apple смогут приобрести их только в пакете с тарифным планом от определенных партнеров-операторов. Есть подозрение, что цена на устройства или не снизится, или снизится незначительно.

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

  3. Система Trade-In: Apple расширит свою программу обмена старых устройств на новые для российских клиентов.

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

  5. Ожидается, что в линейке появятся чехлы для iPhone, Apple Watch и AirPods только для России. Ждем коллаба со студией Лебедева.

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

Ссылочка: [тык]

UPD: Хотелось бы, чтобы всё так и было, но нет. Пока просто мечтаем об этом в формате первоапрельской шутки

Теги:
Всего голосов 14: ↑9 и ↓5+4
Комментарии0

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

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

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

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

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

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

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

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

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

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

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

Источник тут


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

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

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

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

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

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

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

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

Теги:
Всего голосов 14: ↑14 и ↓0+14
Комментарии0

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

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

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

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

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

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

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

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

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

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

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

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

4. Уважение

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

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

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

Теги:
Всего голосов 9: ↑9 и ↓0+9
Комментарии1

[Отладка] git bisect

Сегодня хочу рассказать об инструменте Git, который может очень помочь при отладке. Этот инструмент называется git bisect.

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

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

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

Ссылка на доку здесь.

А тут мой тг-канал со свежими новостями из мира мобильной разработки.

Теги:
Всего голосов 13: ↑10 и ↓3+7
Комментарии1

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

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

Источник изображения тут

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

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

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

Пример матрицы компетенций
Пример матрицы компетенций

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

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

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

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

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

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

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

Теги:
Всего голосов 6: ↑6 и ↓0+6
Комментарии1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 8: ↑8 и ↓0+8
Комментарии0

Ближайшие события

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

  1. Draw.io Integration

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

Создание диаграммы Draw.io с помощью расширения Draw.io Integration (иллюстрация: Rami Krispin)
Создание диаграммы Draw.io с помощью расширения Draw.io Integration (иллюстрация: Rami Krispin)
  1. Quarto

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

  2. Jupyter

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

  3. Markdown All in One

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

  4. Mermaid

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

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

Теги:
Всего голосов 15: ↑14 и ↓1+13
Комментарии2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 9: ↑9 и ↓0+9
Комментарии1

Удаленка: кому подходит, а кому нет

Лично я работаю из дома гораздо эффективнее, чем в офисе. Но я знаю тех, кто работает дома «на лайте» — например, совмещает работу с играми или фитнессом. Кому‑то не нравится сам процесс поездки в офис. Кому‑то (мне) сложно постоянно общаться в мите/зуме.

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

Мое краткое имхо:

  • Работать дома — неплохо.

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

По моим наблюдениям люди на удаленке делятся на два типа:

  1. Целеустремленные и самостоятельные. Чем меньше их трогаешь, тем эффективнее они работают.

  2. Ленивые гедонисты. Они — груз, который тащит команда. Если тебе кажется, что такой чувак сейчас играет, спит или гуляет, то, скорее всего, тебе не кажется.

Со стороны компаний тоже всё неоднозначно. Работники на удаленке обходятся дешевле. И есть возможность найма по всему миру.

Каким компаниям подходит (имхо):

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

  • Малым компаниям и стартапам, которые вышли «на плато», для экономии финансов

Каким не подходит (имхо):

  • Стартапы на ранней стадии. Здесь нужна интенсивная работа и быстрое принятие решений.

  • Компании‑лидеры, которым важна координация внутри и ОЧЕНЬ быстрое принятие решений.

По опыту и те и другие чаще используют гибрид.

Делитесь мнениями удаленка или офис? :) И подписывайтесь на авторский тг-канал про мобильную разработку.

Теги:
Всего голосов 9: ↑8 и ↓1+7
Комментарии1

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

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 9: ↑9 и ↓0+9
Комментарии0

Фишки Google Apps Script

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

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


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


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


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

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

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

Теги:
Всего голосов 9: ↑8 и ↓1+7
Комментарии0

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

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

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

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

Теги:
Всего голосов 11: ↑11 и ↓0+11
Комментарии0

Информация

Сайт
www.agima.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия
Представитель
Кристина Ляпцева