Operating through the “eyes” of development: Efficient communications

Доклад на тему: “Оперирование глазами

разработки: Эффективные коммуникации"

Руководитель проектаМясищев Александр

Оглавление:1. Стадия разработки и

оперирования2. Ключевые задачи3. Варианты решений4. Немного статистики

Стадия разработки+ Фокус на качестве контента+ Внесение изменений на любой стадии- Архитектурные решения только для сложных

систем- Монетизация вторична, геймплей первичен

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

Процесс создания+ Придумывание новой фичи- Монетизация фичи+ Дизайн фичи- Согласование настройки фичи с оператором + Разработка логики работы- Разработка обвязки инструментария+ Поддержка частных случаев+ Тестирование функционала- Тестирование дополнительных опций настройки+ Релиз

Составные части любого функционала- Основная логика поведения- Локализация- Контент- Данные- Статистика- Система изменения данных «на лету»- Система выдачи контента игрокам- Система добавления контента «на лету»- Монетизационные элементы- Инструментарий внешнего оперирования

Постулаты взаимодействия Разработки с Оператором

- Оператор лучше знает, как нужно продавать- Оператор лучше знает, что нужно продавать- Внутриигровые рекламные банеры – ответственность оператора- Оценка разработки пожеланий Оператора должна быть разбита на

сегменты- Лучший друг Оператора – статистика, худший враг – хардкод- Радость Оператора обратно пропорциональна времени между идеей и

возможности ее релиза- Каждый раз, когда в проекте требуются техработы, в компании грустит

один Оператор

КТО ВИНОВАТ И ЧТО ДЕЛАТЬ?

Вариант 1: Самый правильный

Нужен Product Manager!

- Главный по тарелочкам- Не имеет подчиненных и озабочен только

качеством проекта- Отвечает за деньги головой

Вариант 2: Правильный

Встроить Оператора в процесс разработки!

- Коллегиальные брейнштормы- Пришли к решению - задокументируй- Разделяй и неси ответственность!- В случае любых изменений в договоренностях

– оповещай сразу

Вариант 3: Плохой

Если Оператора нет … (или он внешний)

- Составьте чеклист без чего делать новый функционал нельзя- Закладывайте в код возможность быстрой доработкипо требованиям заказчика- Тренируйте в команде Product Manager

Такие доработки очень дороги!

Немного статистики:

Если функционал замкнут на себя:Среднее количество доработки функционала: 3Стоимость одной доработки: от 20 до 60% от базовой стоимостиКоличество работы в корзину: до 40%

Если функционал подготовлен к оперированию:Среднее количество доработок функционала: 1Стоимость доработки: не больше 15% от базовой стоимостиКоличество работы в корзину: до 5%

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

Готов ответить на ваши вопросы

www.nival.com

Мясищев АлександрКонтактыSkype: bespanikiiemail: alexander.myasischev@nivalnetwork.com