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

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

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

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

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

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

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

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

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

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

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

Техдолг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результаты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разбираемся с yield во Flutter

Начинающие Flutter-разработчики не всегда понимают, для чего нужно ключевое слово yield в Dart. Оно используется в генераторах Stream для пошаговой передачи данных. Это полезно в BLoC для управления состояниями и событиями. 

Примеры использования yield в Dart:

1. Простой генератор:

Stream<int> countStream(int to) async* {
  for (int i = 1; i <= to; i++) {
    yield i; // Постепенно выдаёт числа от 1 до to
  }
}

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

2. Использование в BLoC

class CounterBloc extends Bloc<CounterEvent, CounterState> {
  @override
  CounterState get initialState => CounterInitial();
  @override
  Stream<CounterState> mapEventToState(
    CounterEvent event,
  ) async* {
    if (event is Increment) {
      yield CounterLoading();
      // Представим, что здесь какая-то асинхронная логика
      yield CounterLoaded(newState);
    }
  }
}

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

yield во Flutter — это мощный инструмент для создания асинхронных потоков данных и управления состояниями в BLoC. Он делает код более чистым, понятным и поддерживаемым. А если говорить совсем просто, то yield добавляет значение к выходу потока функции async*. Это как return, но он не завершает функцию.

Подписывайтесь на телеграм-канал руководителя нашего направления Flutter/iOS Саши Ворожищева, чтобы узнать про Flutter больше.

Что добавить в CI при настройке GitLab CI/CD на Flutter-проекте?

Вот два примера команд для Static-проверок от нашего Flutter-разработчика Саши:

1. dart-metrics-analyze
   
   Поможет нам проанализировать код, выявить ошибки стиля и проблемы, которые могут повлиять на качество кода и сложность его поддержки.

dart-metrics-analyze:
  stage: static
  interruptible: true
  before_script:
    - flutter pub get
  script:
    - flutter pub run dart_code_metrics:metrics analyze --fatal-style --fatal-performance --no-fatal-warnings --reporter=console lib
  tags:
    - ci

2. dart-metrics-check-unused-files
   
   С помощью этой задачи можно проверить, все ли файлы в коде действительно использованы. Лишние файлы могут усложнять код и увеличивать время его компиляции.

dart-metrics-check-unused-files:
  stage: static
  interruptible: true
  before_script:
    - flutter pub get
  script:
    - flutter pub run dart_code_metrics:metrics check-unused-files --fatal-unused --exclude="{lib/application/core/bloc/void_action_bloc.dart,lib/util/log.dart}" lib
  tags:
    - ci

В обоих примерах используем проверки Dart Analyze. В результате мы получим чистый код, где нет лишних файлов. Еще можно добавить проверки на неиспользуемые переводы, на совместимость сгенерированных файлов локально и в репозитории.

Больше примеров и деталей найдете в нашей подробной инструкции по настройке GitLab CI/CD на Flutter-проекте.

P. S. А еще ждем вас в нашем телегам-канале про Flutter и не только.

Простая идея для канбан-доски, которая делает работу прозрачней

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

Недавно мы заметили, что некоторые задачи на наших канбан-досках застревают на приемке у заказчиков. Например, задачу с нуля мы делаем 10 дней, а потом в колонке Client Acceptance она может лежать еще 20–30. Ситуация повторялась на разных проектах и явно была общей.

Мы быстро поняли, в чем дело. На стадии Client Acceptance команда получала замечания от заказчики. И пока они вносились, задача оставалась в этом же столбце. По правилам Канбан, двигать ее назад нельзя. Хотя, по сути, всё это время она проходила тот же путь, что и до этого — через To do, In progress и Validation.

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

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

Благодаря этому решению мы:

• упростили и оптимизировали работу;

• начали лучше контролировать работу отделов;

• сделали работу прозрачной для заказчика.

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

Сложности работы с GraphQL, или Почему не стоит его использовать повсеместно

1. Внедрение GraphQL — это сложно. Поэтому перед практическим использованием выделите достаточно времени и ресурсов для изучения концепции и структуры.

2. Когда вы реализуете REST API, можете закэшировать ответ по каждому эндпоинту. В GraphQL запросы динамические, содержат разный набор полей и связей:

query {
  user(id: 1) {
    id
    name
    posts {
      id
      title
      comments {
        id
        text
      }
    }
  }
}

В этом запросе вы получаете данные из разных источников: пользователи, посты, комменты. Для оптимальной работы придётся продумывать более точечное кэширование.

3. А теперь представьте, что в запросе выше ещё больше вложенных запросов. По умолчанию GraphQL не ограничивает вас в глубине вложенности, что может вызвать шквал базовых запросов. Это сказывается на производительности сервера.

4. GraphQL не гарантирует атомарность выполнения нескольких мутаций:

mutation {
  createPost(title: "New Post", body: "Content") {
    id
    title
  }
  updateAuthor(id: 1, name: "New Name") {
    id
    name
  }
}

С одной стороны, это гибко и удобно, а с другой, — а что произойдет, если одна мутация пройдёт, а другая отвалится?

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

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

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. Принимать решения.

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

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