Доклад на тему: “Оперирование глазами
разработки: Эффективные коммуникации"
Руководитель проектаМясищев Александр
Оглавление:1. Стадия разработки и
оперирования2. Ключевые задачи3. Варианты решений4. Немного статистики
Стадия разработки+ Фокус на качестве контента+ Внесение изменений на любой стадии- Архитектурные решения только для сложных
систем- Монетизация вторична, геймплей первичен
Стадия Оперирования+ Оперативный фидбек от игроков+ Большая статистика- Очень ограниченные ресурсы - Очень дорого менять основные концепции
Процесс создания+ Придумывание новой фичи- Монетизация фичи+ Дизайн фичи- Согласование настройки фичи с оператором + Разработка логики работы- Разработка обвязки инструментария+ Поддержка частных случаев+ Тестирование функционала- Тестирование дополнительных опций настройки+ Релиз
Составные части любого функционала- Основная логика поведения- Локализация- Контент- Данные- Статистика- Система изменения данных «на лету»- Система выдачи контента игрокам- Система добавления контента «на лету»- Монетизационные элементы- Инструментарий внешнего оперирования
Постулаты взаимодействия Разработки с Оператором
- Оператор лучше знает, как нужно продавать- Оператор лучше знает, что нужно продавать- Внутриигровые рекламные банеры – ответственность оператора- Оценка разработки пожеланий Оператора должна быть разбита на
сегменты- Лучший друг Оператора – статистика, худший враг – хардкод- Радость Оператора обратно пропорциональна времени между идеей и
возможности ее релиза- Каждый раз, когда в проекте требуются техработы, в компании грустит
один Оператор
КТО ВИНОВАТ И ЧТО ДЕЛАТЬ?
Вариант 1: Самый правильный
Нужен Product Manager!
- Главный по тарелочкам- Не имеет подчиненных и озабочен только
качеством проекта- Отвечает за деньги головой
Вариант 2: Правильный
Встроить Оператора в процесс разработки!
- Коллегиальные брейнштормы- Пришли к решению - задокументируй- Разделяй и неси ответственность!- В случае любых изменений в договоренностях
– оповещай сразу
Вариант 3: Плохой
Если Оператора нет … (или он внешний)
- Составьте чеклист без чего делать новый функционал нельзя- Закладывайте в код возможность быстрой доработкипо требованиям заказчика- Тренируйте в команде Product Manager
Такие доработки очень дороги!
Немного статистики:
Если функционал замкнут на себя:Среднее количество доработки функционала: 3Стоимость одной доработки: от 20 до 60% от базовой стоимостиКоличество работы в корзину: до 40%
Если функционал подготовлен к оперированию:Среднее количество доработок функционала: 1Стоимость доработки: не больше 15% от базовой стоимостиКоличество работы в корзину: до 5%
Главные и очевидные плюсыВозможность :- использовать функционал многократно - использовать функционал без участия разработки- расширять функционал с минимальными трудозатратами- сократить технические издержки
Готов ответить на ваши вопросы
www.nival.com
Мясищев АлександрКонтактыSkype: bespanikiiemail: [email protected]