PI-планирование, или Почему нам стало легче дышать

Один из наших заказчиков — известный бренд, который развивают Ecom-направление. Мы работаем с ними уже пять лет, но начиналось всё так себе. Первое время мы не могли найти общий язык, спорили из-за мелочей. Всё как в басне «Лебедь, рак и щука».

Но затем нашли лекарство — PI-планирование. Рассказываем, как его проводим мы.

PI-планирование — это регулярная встреча всех команд проекта и его стейкхолдеров. Она помогает держать фокус на общей цели и синхронизировать действия нескольких команд сразу.

PI-планирование идет от бэклога. То есть на встрече мы не пополняем доску задачами, а все вместе распределяем их по двухнедельным таймбоксам. У нас встречи проходят онлайн.

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

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

1. Мы обеспечиваем команде равномерную нагрузку.

2. Мы делим ответственность за проект с заказчиком.

3. Мы лучше распределяем ресурсы.

PI-планирование точно стоит внедрить тем,

✔️ кто строит команду на аутсорсе;

✔️ у кого над продуктом работает несколько команд.

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

Что мы делаем, когда задача приходит на разработку без планирования

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

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

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

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

Если коротко, то выбираем решение с еmail-рассылкой, потому что многие пользуются VPN и по IP мы ничего выяснить не можем. Бэк генерирует уникальную ссылку и промокод, получить его можно кликнув по своему городу в письме.

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

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

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

Чек-лист: как понять, что компании нужен карьерный сайт

Пересказываем большую статью в маленьком посте.

Ребята из нашего PHP-направления разработали универсальный бэкенд для карьерных сайтов на Laravel. Наша «коробка» — это пять ключевых фич, они покрывают 90% потребностей рекрутеров. Остальное — кастомные решения. Вот эти фичи:

• интеграция с Хантфлоу;

• админка с функционалом под создание лендингов;

• интеграция с поисковой системой Elasticsearch с синонимичным поиском;

• факультативный блок с новостями;

• рендеринг картинок для шеринга.

Но как понять, что компании нужен карьерный сайт? Мы составили простой чек-лист на основе нашего опыта. В этом году мы уже сделали шесть подобных проектов, в работе еще два. У большинства заказчиков одни и те же особенности:

✔️ вы много и интенсивно нанимаете, в постоянной работе у вас от 100–150 вакансий;

✔️ вам не хватает возможностей HH и подобных площадок, чтобы показать преимущества компании;

✔️ вам нужна подробная аналитика по каждой позиции.

В статьях по теме иногда предлагают еще два пункта, но они факультативные:

✔️ вам сложно закрывать отдельные позиции, их нужно активнее продвигать;

✔️ у вас сложные тестовые задания, их условия нужно подробно описывать.

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

Больше о «коробке», карьерных сайтах и подборе IT-специалистов — в нашем блоге.

Как работать со старожилами компании, которые стали неэффективными. Инструкция для тимлидов

Если компания на рынке хотя бы 10–15 лет, в ней точно есть сотрудники-старожилы. Когда-то они решали нерешаемые задачи и были незаменимы. Но технологии и процессы шагнули вперед, а они нет. Ниже советы, как вернуть их в строй.

1. Разговаривать.

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

2. Учить новому.

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

3. Строить план развития.

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

4. Мотивировать.

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

5. Следить и поддерживать.

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

6. Принимать решения.

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

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

Как заказчик пришел к нам за новой фичей, а мы его отговорили

Это пересказ статьи из нашего блога.

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

Чтобы разобраться, мы предложили провести UX-аудит.

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

Для UX-аудита мы совместили два метода:

1. Эвристический анализ — это метод, при котором UX-эксперт ходит по сайту и анализирует каждый шаг и сценарий.

2. Когнитивное прохождение — это метод, при котором исследователь прописывает все возможные сценарии и анализирует их.

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

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

Все иллюстрации и подробности — в нашей статье. А больше про аналитику — у нас в телеграме.

Rive для Flutter-приложений: что нужно знать

Привет! Я Никита Грибков, Flutter-разработчик в AGIMA. Сегодня расскажу вам про возможности Rive. Это фреймворк, который использует векторную графику для создания анимации во Flutter-приложениях. Я использовал его, чтобы сделать кнопки для Bottom Bar в своем пет-проекте. 

Элементы для анимации можно создавать в программных продуктах типа SVG или Adobe Illustrator. У меня не было опыта работы с векторной графикой, поэтому я использовал встроенный в Rive UI-интерфейс. Еще в Rive есть раздел Community. Там авторы выкладывают бесплатные анимации.

Вообще в Rive несколько слоев:

• статический слой — это слой, который отображает элемент в неподвижном состоянии;

• анимационный слой — это временная линия, на которой можно задавать ключевые кадры для изменения формы, цвета и размера элементов;

• State Machine — это часть фреймворка Rive, которая позволяет создавать сложные анимации. Он использует конечный автомат (FSM) для определения состояний и переходов между ними.

Чтобы внедрить Rive в приложение, нужно всего 2–3 строки кода. Хотя это может зависеть от сложности анимации. Но на первый взгляд, код здесь компактный и легко поддерживаемый.

Вот что получилось в итоге:

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

P. S. А еще у моего коллеги Саши Ворожищева есть канал про Flutter. Приходите читать.

Мы внедрили OKR. Как? Зачем? Что теперь?

Пересказываем большую статью в маленьком посте.

В прошлом году мы внедрили новую систему целеполагания — OKR. Ее используют гиганты вроде Google и Uber. И мы тоже решили попробовать. Главная причина: компания выросла, и нам нужно было подключить больше людей к стратегическим задачам.

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

OKR — это не KPI. Главные отличия:

• OKR трудно достижимы, они амбициознее и больше;

• OKR на влияют на финансовую мотивацию;

• OKR — это коллективная ответственность.

Новую систему мы внедряли методом проб и ошибок. Но начали с пирамиды метрик. В качестве North Star Metric взяли оборот, декомпозировали его и получили набор метрик низкого уровня.

Затем мы провели ретроспективу по итогам 2022 года, составили список побед и поражений. Обращали внимание на те, которые больше влияли на доход. Так мы нашли идеи, как сделать, чтобы этот год был лучше прошлого. Они-то и стали нашими OKR.

Чтобы их контролировать, мы:

• Внедрили регулярные встречи раз в неделю.

• После каждой встречи делаем мини-отчёт для сотрудников.

• Назначили ментора по каждому OKR.

Что в итоге? Эксперимент продолжается. Мы пару раз профакапились, но смогли привлечь больше людей к стратегическим задачам. Достижимость OKR пока составляет 62%.

Все подробности о наших ошибках и открытиях здесь.