В этой статье в коротком формате ознакомимся с инструментом, который может изменить командную динамику и повысить эффективность принятия решений.

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

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

В этой статье я хочу рассказать вам о том, как мы писали с нуля полнофункциональный Gaussian Splatting вьюер для Unreal Engine 5.

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

Управление разработкой продуктов требует точного мониторинга процессов и результатов. Команды, которые отслеживают только конечные результаты, могут упустить важные сигналы на ранних этапах работы. Здесь на помощь приходят leading и lagging индикаторы. Эти метрики помогают контролировать как текущее состояние процесса, так и итоговые результаты, что позволяет принимать своевременные решения, корректировать стратегию и предотвращать потенциальные проблемы.

Leading индикаторы измеряют действия, которые происходят до достижения результата, и позволяют предсказывать успех или проблемы. Lagging индикаторы фиксируют результаты этих действий, которые можно измерить только после завершения работы. Оба типа метрик важны и взаимосвязаны: изменения в leading индикаторах могут повлиять на результаты, которые отражают lagging индикаторы.

Периодически при работе на стороне заказчика (in‑house) встречаются «сложные» для запуска проекты, которые вы, как исполнитель (аналитик, архитектор, ИТ‑директор), не можете продать руководству или, находясь на стороне интегратора, вы сталкиваетесь с приостановкой или отменой перспективного проекта заказчика. Еще несколько лет назад компании в России запускали проекты на базе «лучших мировых практик» и стремились не отстать от соседей, что на 2024 год стало недоступным из‑за «деглобализации» большинства российских компаний.

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

Попробуем провести разбор кейса и способов выхода из подобных ситуаций, предлагаемых опытными коллегами.

Привет, Хабр. В этой статье мы продолжим разбираться с автоматизацией воронки продаж. Как писал в прошлой статье, за 7 лет работы с продажами я выделил топ-3 инструмента автоматизации: реактивация отказов, реактивация клиентов и контрольные точки на этапах продаж.

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

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

В этой статье я рассмотрю 7 наиболее распространенных ошибок с примерами и способами их предотвращения. Чтобы выводы ваших А/В были точны и надежны.

В этой статье я поделюсь с вами своим опытом использования Golang, Kafka и Clickhouse на примере простого ETL-конвейера для параллельной передачи JSON-данных в базу данных с последующим прогнозированием температуры на основе машинного обучения.

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

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

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

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

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

Теория ограничений (ТОС) — это управленческая методология, предложенная Элияху Голдраттом в 1984 году в его книге «Цель». Она базируется на простом, но мощном принципе: любая система, будь то производство, бизнес‑процесс или команда разработки, всегда ограничена одним или несколькими узкими местами. Эти ограничения или «бутылочные горлышки» сдерживают общую эффективность системы и являются теми ключевыми элементами, которые необходимо обнаружить и устранить для значительных улучшений.

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

Меня пригласили как эксперта по внедрению гибких подходов управления в одну IT-компанию, занимающуюся разработкой решений в сфере B2B. Основная задача заключалась в том, чтобы настроить процессы управления проектами, сделать их предсказуемыми и управляемыми. До начала сотрудничества компания сталкивалась с множеством проблем: сроки регулярно срывались, клиенты были недовольны, проекты могли «висеть» в работе до 8 месяцев без завершения, а команда испытывала серьезные перегрузки из‑за параллельной работы над несколькими задачами.

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

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

В этой статье я расскажу, как ведущие компании, на российском и международном рынке, такие как Яндекс, Авито, Booking и Google, используют продуктовую аналитику для масштабирования своих продуктов.

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

Современные компании стремятся повысить оперативность и гибкость в управлении ИТ‑услугами, чтобы быстрее реагировать на запросы бизнеса и улучшать клиентский опыт. Традиционные подходы ITSM (управление ИТ‑услугами) с их жесткими процессами и бюрократическими барьерами часто не справляются с этими задачами. Работа по Agile позволяет трансформировать управление ИТ‑услугами, делая его более эффективным и адаптивным.

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

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

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

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

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

Часто, стремясь угодить всем и сразу, команды теряют фокус на долгосрочных целях, что в конечном итоге снижает эффективность продукта и его способность удовлетворять стратегические бизнес-цели. В статье мы рассмотрим важность удержания фокуса на ключевых приоритетах и разберем, как не отвлекаться на ежедневные мелкие и “влетные” задачи и обсудим методы работы с дорожными картами и стратегическим видением продукта.