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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы справиться с этими вызовами, были созданы фреймворки масштабирования, такие как LeSS, SAFe и Nexus. В этой статье мы рассмотрим их основные принципы и рекомендации по применению.

С тех пор как я открыл для себя столь ценный инструмент выявления требований, как варианты использования (use case), я стал их ярым приверженцем. Варианты использования смещают фокус внимания с продукта и его возможностей на результат, который пользователи хотят получить от продукта. Акцент на использовании приводит к пониманию необходимых возможностей и характеристик решения.

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

Но несмотря на эффективность вариантов использования, они — не идеальный инструмент для любых ситуаций. Дополнительной стратегией выявления требований может быть изучение событий, происходящих в системе или продукте, и реакций системы на них. Реакция зависит от того, в каком состоянии находится система в момент события. Подход с анализом событий особенно хорошо подходит для связующего программного обеспечения (middleware) и систем реального времени, состоящих как из программных, так и аппаратных компонент.

В своей карьере я работала в таких компаниях, как Авито, Rutube, МТС, сейчас работаю в Банке [NDA] — и везде у меня была команда разработки самостоятельна. 

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

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

В этой статье представлено подробное руководство по инициализации проекта Spark с помощью Scala Build Tool (SBT). Это руководство охватывает все этапы процесса, включая создание проектов, управление зависимостями, локальное тестирование, компиляцию и развертывание проекта Spark на кластере.

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

Цель этой статьи — предоставить вам подробное руководство по инициализации проекта Spark, в котором будут подробно рассмотрены все ключевые идеи. В руководстве будет рассмотрен пошаговый процесс создания проектов с помощью Scala Build Tool (SBT), а также продемонстрировано управление зависимостями, локальное тестирование, компиляция и развертывание проекта Spark на кластере.

На протяжении всего моего времени работы с моделью и языком ArchiMate от The Open Group, внимательно наблюдая за практиками сообщества, я не переставал удивляться тому, насколько мало используются “точки зрения” (viewpoint’ы), предложенные в ArchiMate 2.1.

Я открыл их для себя благодаря отличному бесплатному опенсорсному решению Archi, разработанному Филлипом Бовуаром (Phillip Beauvoir), которое очень грамотно раскрывает потенциал представлений (view) в помощи заинтересованным сторонам, желающими создать всеобъемлющую модель архитектуры рассматриваемых ими организаций.

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

Я считаю, что понимать и уметь применять точки зрения так же важно, как и разбираться во всех остальных 60 (или около того) конструкциях языка ArchiMate.

В этом руководстве я покажу вам, как работать с моделью машинного обучения на сервере Vapor с помощью Swift.

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

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

Если вы, будучи разработчиком ASP.NET Web Forms, сомневаетесь в переносимости своих навыков на более современную платформу .NET (например, .NET Core или .NET 6), то спешу вас успокоить — все не так уж и плохо. Хоть Microsoft и не планирует переносить Web Forms, приобретенные вами навыки вполне применимы в аналогичном фреймворке под названием Razor Pages. Да, вам все равно придется адаптировать свое мышление к этой новой платформе, но если вы не пожалеете на это время, ты вы откроете для себя такой же мощный и простой в использовании инструмент для создания веб-приложений.

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

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

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

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

Рассмотрим подробнее, почему blockout столь важен и как он помогает улучшить игровой процесс.

Рад приветствовать вас во второй части! Если вы пропустили первую, то можете ознакомиться с ней, перейдя по этой ссылке. Цель этого руководства заключается в том, чтобы познакомить вас с полезными фичами редактора Unity и дать пару советов по улучшению рабочих процессов, которые помогут сделать работу над вашим следующим проектом более продуктивной и эффективной, чем над предыдущим.

Так, что это тут у нас? Очередная статья о генеративном ИИ? Скорее всего это первый вопрос, который придет вам в голову. Короткий ответ на него — да, но все не совсем так, как вам может показаться с первого взгляда.

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

Основатель и генеральный директор Half Moon Studios и бывший директор по маркетингу студии Miniclip Питер Койман (Pieter Kooyman) недавно поделился с Михаилом своей историей, которой я с удовольствием поделюсь с вами в этой статье. Опыт работы Коймана в игровой индустрии насчитывает 15 лет, из которых 13 Питер входил в руководящий состав студии Miniclip до того, как компания была приобретена Tencent. Сейчас он занимается развитием Half Moon Studios, которая начала с переосмысления жанра викторин (Picture Quiz).

Half Moon Studios использует особый метод управления своим бизнесом. Их акцент на тщательном подборе инвесторов и партнеров, а также использование искусственного интеллекта для оптимизации операций выделяют их на фоне других студий. Что еще примечательно, так это то, что они не планируют расширять команду дальше 10-12 человек. ИИ — ключевой ингредиент в достижении этого впечатляющего результата.

Давайте же узнаем, как им это удалось!

Я часто сталкиваюсь с необходимостью генерирования строк на лету. И не только для простого получения последовательности чисел или дат, но и, например, для наполнения базы данных тестовыми данными, создания сводных таблиц (pivot) с произвольным количеством столбцов, экстраполяции данных, заполнения пропусков в диапазонах дат или времени.