Заказать звонок
Мы перезвоним и подробно расскажем о наших продуктах
Нажимая на кнопку «Отправить», я даю свое согласие на обработку персональных данных
Проект
"Машина времени"
Инструкция для участников деловой игры
Обсудите в группе и выберите ответ
А, В или С в каждом из кейсов
Учтите, что общая сумма ресурсов, которые вы можете потратить на 5 кейсов -12 ресурсов или меньше. На следующий раунд ресурсы не переносятся. Каждое решение оказывает определенное влияние (от -4 до +4) на заинтересованные стороны проекта
Кейс 11. Неразбериха.
Пользовательское соглашение. В процессе работы мы будем распоряжаться массивом данных клиента. На этом этапе мы можем решить, где будут храниться сведения, которые он нам доверит? Сведения напрямую касаются безопасности конечного клиента. Часть инвесторов и команды хочет, чтобы сведения хранились на наших серверах - так будет надежнее. Другая группа считает что нужно дать клиентам решать, где будут храниться их данные - у нас, у них или на сторонних серверах. От решения сейчас зависит архитектура продукта на всех последующих стадиях разработки. Что мы предпримем?
А. Серверное решение. Мы будем использовать наши сервера — только так мы сможем гарантировать сохранность данных клиента. Также, это решение позволит нам без промедлений оказывать клиенту необходимую техническую поддержку (4 ресурса).

В. Облачное решение. Мы считаем, что хранение данных на сторонних серверах — прекрасное решение. Нам не нужно будет тратить лишних ресурсов на ИТ безопасность, уровень которой на сторонних серверах может быть ничуть не ниже (2 ресурса).

С. Совместная ответственность. Мы должны предоставить пользователям обе опции. Они должны иметь возможность хранить информацию и на наших серверах, и в облачных хранилищах, да и где угодно по своему желанию (2 ресурса).
Кейс 12. Увеличение вовлеченности сотрудников.
В команде - производственный бум! Продукт уверенно движется к сдаче, и многие члены команды предлагают внедрять туда все новые и новые опции, которые расширят рынок сбыта продукта и сделают его доступным и для небольших компаний. Однако, эти опции будут не соответствовать утвержденным требованиям управляющего комитета и конечных пользователей. Что делаем?
А. Принять все. Любая идея команды имеет свой потенциал. Мы будем стараться внедрить каждое решение команды в программу. Уверены, так продукт станет только лучше (5 ресурсов).

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

С. Информировать. Еще раз обсудить с командой требования управляющего комитета и клиентов. Принимать все предложения и не спешить с их внедрением (2 ресурса).
Кейс 13. Достаточно ли гибкая архитектура?
Кастомизация. Инвесторы интересуются, возможно ли сделать архитектуру продукта более гибкой? Это позволит кастомизировать продукт под конкретного конечного пользователя. Они настоятельно рекомендовали нам подумать над этим вопросом и предложить свои варианты решения.
А. Максимальная гибкость архитектуры. Мы готовы работать на благо клиента. Команде будет поручено пересмотреть архитектуру проекта, и если это необходимо, со сверхурочными, приступить к разработке (4 ресурса).

В. Соблюдение баланса. Мы дорожим силами команды и не можем бросить их в сверхурочные на этом этапе. Но и игнорировать просьбу инвестора будет недальновидным шагом. Мы проработаем это предложение и внесем в архитектуру проекта только самые необходимые изменения (2 ресурса).

С. Неопределенное обещание. Команде вообще необязательно знать про это желание инвестора. Пусть сохраняют рабочий ритм, а инвесторам мы пообещаем, что возможно, если это будет необходимо, сделаем продукт более гибким (1 ресурс).
Кейс 14. Насколько важно техническое задание?
Перестановки в управляющем комитете. Новые члены комитета проанализировали проект. В процессе выяснилось, что наш продукт не соответствует изначальному техническому заданию. Для того, чтобы привести все в соответствие с ТЗ, потребуется потратить дополнительные усилия всей команды. Что будем делать?
А. Вернемся к основам. Мы организуем встречу, на которой еще раз обсудим техническое задание и разработаем план возвращения к его изначальным требованиям. Необходимые для этого ресурсы выделит управляющий комитет (4 ресурса).

В. Обновление. Мы знаем, что подобные ситуации — не редкость. Давайте пересмотрим наше ТЗ и попробуем понять, получается ли у нас продукт, который отвечает в первую очередь не ТЗ, а потребностям конечного пользователя? Если да — изменяем ТЗ (4 ресурса).

С. Обзор. Наша задача на данный момент — заниматься дизайном продукта, а не бюрократией. Продолжаем работать в утвержденном графике и с реальными задачами. Обещаем комитету вернуться к этому позже (2 ресурс).
Кейс 15. Степень доступности управляющего комитета уменьшается.
Похоже, члены комитета теряют к нам интерес. Они часто не отвечают на письма, и все реже появляются на наших плановых совещаниях. Но инвестирование проекта идет по графику. Как мы отреагируем?
А. Общая проверка. Мы пригласим всех инвесторов на большую встречу с командой, на которой воодушевленные разработчики и административный персонал расскажут, какие надежды и цели мы связываем с этоим проектам. Пусть эта встреча займет целый рабочий день — нам нужно заново разжечь интерес инвесторов к проекту! (4 ресурса).

В. Проверка с несколькими людьми. Мы выборочно пригласим членов комитета на деловой обед с тимлидами. Они познакомятся с ответственными лицами и воодушевятся (3 ресурса).

С. Информирование. Мы не против того, чтобы инвесторы не принимали активного участия в проекте на данном этапе. В конце концов, чем отчеты, отправленные по почте, хуже, чем личные встречи каждые две недели? (1 ресурс).