Мы с друзьями делаем игру для мобильного телефона. Целевой системой является "запущенная на телефоне игра" и в физическом мире это различные заряженные транзисторы в оперативной памяти телефона, какие-то разноцветные пиксели на его экране.
Надсистемой является "система досуга" того человека, который в нашу игру играет. "Запущенная на телефоне игра" очевидно в "досуг" вложена.
Системный эффект игры -- "в нее можно играть". Она обладает свойствами "затягивает" и "приносит удовольствие". Подсистемы -- телефон сам по себе (с установленной операционной системой), набор библиотек и ресурсов игры (в смысле графические и аудио-файлы) такими свойствами не обладают.
Проектированием этой целевой системы занимаемся мы (нас несколько человек, но каждый из нас играет множество ролей, причем некоторые роли мы играем все вместе). Проектируется "геймплей" в смысле "что будет видеть человек" и "какую реакцию это у него должно вызывать" (например радость, а не непонимание).
Производством целевой системы с одной стороны занимаемся мы (превращаем компоненты игры в некоторый готовый для загрузки пакет, который публикуется в Google Play), а с другой стороны потенциальный игрок должен установить его себе на телефон.
Эксплуатацией системы занимается игрок -- играет в игру и получает от этого удовольствие.
Система обеспечения это наша "команда по разработке", операционная система android, play market. Наверняка что-то еще.
Проектные роли
внутренние проектные роли
предприниматель
инженеры
инженер по требованиям
инженер по разработке механики
инженер по разработке ПО
менеджер
лидер
релиз-инженер
тестировщик
внешние проектные роли
игроки
Описание нашей системы существует, потому что существует сама система и вообще мы ей занимаемся. Документация системы существует в нескольких видах:
документ в google drive с описанием интерфейса и базовых механик
уточненные (более детальные) описания этого же в confluence нашего проекта
исходный код программы на C# для Unity
прототип на Python (его исходный код и исходные коды юнит-тестов)
Наиболее важные подсистемы
телефон на Android (в будущем планируется версия для iPhone)
интерфейс игры (то, с чем игрок взаимодействует) физически воплощается в виде программных библиотек, графических файлов и пр., которые "находятся" на накопителе телефона.
"механика игры" (то, с чем игрок напрямую не взаимодействует) другой набор библиотек/компонентов в коде
Проектные роли, которые я играю
предприниматель Каждый из нас играет роль предпринимателя, когда мы рассматриваем игру с точки зрения геймплея, геймдизайна, реиграбельности, удобства использования
инженер Каждый из нас играет роль "гейм-дизайнера" (фактически -- инженера по требованиям) -- рассматриваем особенности той или иной внутренней логики, "чтобы в это было интересно играть". С другой стороны я играю роль "инженера-программиста", -- прорабатываю определенные архитектурные элементы в реализации механики. Кроме того, я играю роль "тестировщика", поскольку разрабатываю систему автоматического тестирования корректности реализации.
менеджер Каждый из нас играет роль менеджера и лидера -- мы распределяем между собой задачи в соответствии с тем, кто с чем лучше справится, что по мнению каждого из нас является сейчас более срочным, а что может быть отложено на потом.
Спасибо за пост!
Отличное описание проекта, такой качественный рабочий продукт с первого раза далеко не всем удается составить)
Могу предложить только еще немного уточнить/улучшить его:
ЦС можно уточнить: у кого на телефоне запущена игра? У игрока или, может, у тестировщика в TestFlight? В текущем описании второе вполне подходит под определенную ЦС, но вряд ли вас в конечном счете интересует "запущенная на телефоне тестировщика игра".
можно подумать и об уточнении надсистемы. Она выделена правильно, но очень широко. Возможно, вас будет интересовать не весь отдых человека, а только какие-то конкретные ситуации, в которых он выбирает между "поиграть в игру" и каким-то другим досугом (вряд ли он будет выбирать между "отправиться в отпуск на Кубу" и "поиграть в игру", а между тем отпуск на Кубе вполне входит в систему досуга). Тут может быть уместно вспомнить о 4 уровнях внимания/сознания.
подсистема должна физически входить в ЦС целиком. Разве телефон игрока физически входит в ЦС, да еще и целиком?
проектирование, производство, эксплуатация – стадии ЖЦ системы обеспечения. Описание системы обеспечения начинается с того, что вы даете ей целиком название. "Команда" тут будет только одной из альф. Это все описывается в главе 10, думаю, как только вы до нее дойдете в изучении (я так понимаю, вы пока на главе 8?), думаю, тут распишете подробнее и выделите больше объектов внимания)
То же самое замечание в отношении предпринимательства. "Геймплей", "геймдизайн", "реиграбельность" и "удобство использования" – это инженерные интересы, описания предпринимательских интересов тут нет. В главе 9 предпринимательство расписано подробнее (как и менеджмент, оно более типовое, чем инженерия), когда изучите ее, тогда лучше удастся описать предпринимательскую область интересов.
В целом вам может быть интересно посмотреть доклад Ивана Падабеда "Платформа: от 7 альф к орг.инженерии" с конференции ШСМ-2020. Там он рассказывает об определении ЦС для игровой платформы Awem Games – возможно, что-то почерпнете для себя.
Действительно, речь идет об игре, запущенной на телефоне игрока.
Надсистема ... если уже, то речь идет о совокупности игр, в которые человек может играть на телефоне, а уже это в свою очередь является частью его досуга (может быть через несколько промежуточных уровней).
Телефон действительно не входит целиком, равно как и операционная система. Но выделять те части телефона (экран, память, возможно модуль беспроводной связи) мне показалось чем-то лишним.
.. на самом деле по домашним заданиям я отстаю от того, куда дошел в чтении, так что как раз главу 10 только что и закончил. Можно было бы перечислить и работы, и Way of Working, но наверно это было бы слишком сумбурно.
При описании предпринимательской области интересов я не мог выбрать между "зачем это нужно игроку" (играть) и "зачем это нужно нам" (чтобы игрок смотрел рекламу, а мы получали за это деньги). Во втором случае получается целая другая целевая система. Поэтому я решил сосредоточиться на процессе игры и тогда вопросы именно в том, чтобы игрок не удалил игру после запуска, чтобы вспомнил о ней через неделю, чтобы он не удалил ее после первого "прохождения". Эти требования фактически и переводятся в термины "геймплей" и "реиграбельность".
Доклад обязательно посмотрю, спасибо за рекомендацию.
Все-таки описания подсистем надо уточнять. С точки зрения преподаваемого в ШСМ системного подхода включение телефона в подсистему будет ошибкой, и защиту резюме проекта / эссе по проекту без исправления этой ошибки не пройдет.
“Геймплей” и “реиграбельность” относятся к описанию ЦС. Предпринимательская область интересов работает с описанием надсистемы, так что тут нужно будет тоже уточнять, такой вариант не подойдет. Вам нужно описывать игрока и что происходит с ним, когда он играет в вашу игру (а не какую-то другую). Когда мы говорим об описании игрока, то явно не будем использовать слова вроде “геймплей” и “реиграбельность”.
Надсистему надо уточнять обязательно, если она не будет уточнена, успех получить будет тяжело. Какие потребности игрока вы закрываете?
Получается, что есть подсистемы “аппаратная часть телефона, необходимая для работы игры (экран и графический процессор, оперативная память и накопитель, процессор, система сенсорного управления)” и “часть ПО телефон, необходимая для работы игры (графическая подсистема, подсистема обработки пользовательского ввода, файловая система, система управления потоками…)” (тут я могу долго перечислять).
Потребность игрока… Тут мы наверно совершаем основную ошибку, которую делают все начинающие разработчики игр. Мы в первую очередь делаем игру для себя. То есть то, во что нам самим было бы интересно играть. Мы видим другие существующие игры, но хочется чтобы “этот элемент оттуда, а этот отсюда”. Поэтому можно сказать, что мы удовлетворяем потребность в переживании определенных ощущений, которые складываются при наличии определенных игровых элементов.
Если надсистемой является вся совокупность игр, в которые игрок может играть на телефоне, то тогда нас интересует то, чем наша игра отличается от других, почему игрок будет играть именно в нее, а не во что-то другое. В этих случаях у нас начинаются дискуссии вида “мне кажется, надо добавить в игру Х” – “а я думаю не нужно, это лишнее, кому хочется Х, тот и так уже играет в игру Y”.
А получается, что мы думаем над тем, чтобы с одной стороны максимизировать показы рекламы пользователю, а с другой стороны не оттолкнуть его тем самым от игры. То есть какие игровые элементы мы можем “продать” игроку за просмотр рекламы, чтобы он счел этот обмен достойным.
И вот тут я наталкиваюсь на трудность в определении системных уровней. В ЦС не упоминается реклама, потому что пользователя это не интересует. Но это интересует нас. Получается, что ЦС это не просто “игра, запущенная на телефоне игрока”, но и “реклама, которую игрок иногда просматривает”, которая является подсистемой в ЦС. Появляются новые внешние проектные роли – рекламодатели и “мы, получающие доход за показ рекламы” (каким словом это назвать?). Среди требований со стороны игрока появляется условие “реклама не должна быть слишком много”, а со стороны “получаетелей дохода” требование “рекламы не должно быть слишком мало” и это те требования, с которыми мы как “инженеры геймплея” работаем.
Да, вот такое описание уже больше похоже на правду. Чтобы было легче думать о системном разбиении, могу сказать, что в ШСМ мы говорим о том, что при помощи курсов помогаем студенту изготовить функциональный кусочек мозга, обученный каким-то практикам (которые потом задействуются в проектах). Обычно этот кусочек мозга называем “мастерством”. Те мы не изготавливаем выпускника целиком, и даже обучаем его не всему, а только какому-то мастерству или даже только небольшой части мастерства.
По поводу потребностей: если хотите не просто сделать “игру для себя”, а получить еще какой-то коммерческий успех, то с областью интересов предпринимателя надо поработать обязательно. Причем помните, что вы не ваша ЦА (очень распространенное когнитивное искажение), а ЦА надо иссследовать постоянно и беседовать с ними постоянно. Подробнее об этом я писала в комментарии к посту Елены Унру, дала там ссылки на несколько полезных ресурсов.
Вы можете сделать несколько разных рассмотрений: ЦС с точки зрения игрока, ЦС с точки зрения рекламодателей и бенефициаров рекламы и тп, а потом подумать, как и где согласовать интересы из разных описаний.
СМ допускает и даже прямо прописывает а) субъективность выделения систем, б) множественность выделения систем в зависимости от интересов к системе (=ролей).
По названиям ролей – можно прогуглить соответствующие практики и узнать, какие там сейчас наименования ролей) ваша роль в зависимости от SOTA и проф сообщества может называться и “рекламщик”, и “вебмастер”, и еще как-нибудь.