82
4. /{taskId}/assign – PATCH, изменение ответственного по задаче
5. /{taskId}/status – PATCH, изменение статуса задачи. Если статус
задачи становится ‘done’, то пользователю, ответственному за
выполнение задачи, начисляется количество валюты, равное
значению user points задачи. Помимо этого, в объект пользователя
в БД вносится информация о выполненной задаче: существует
свойство doneTasks, имеющее три показателя: day, week, month –
и оно отображает, сколько пользователь выполнил задач в
определенный период времени.
Бейджи, url ‘/badges’
Бейджи делятся на два типа: лидерства и достижений. Первый тип
может принадлежать только одному участнику команды, второй – любому
участнику команды. Все типы бейджей хранятся в БД в документе badges,
и их присвоение пользователям происходит простым добавлением в
массив бейджей пользователя id соответствующего бейджа. При каждом
запросе пользователя со стороны клиента сервер дополняет ответ именем,
описанием и ссылкой на картинку каждого бейджа, найденного для
каждого пользователя, при этом для работы с БД используется метод find()
с передачей в него объекта со свойствами, которые мы хотим найти в
бейджах
Отдельного инструментария по добавлению бейджей пользователю
нет, так как каждый случай присвоения работает отдельно и независимо от
других, и они описаны выше, в методах других роутов. Однако есть
независимые от действий пользователя процессы начисления бейджей, а
именно подсчёт количества выполненных задач.
Для этого создан скрипт, который раз в сутки проверяет количество
задач, выполненных пользователем (doneTasks), причем если конец деня
также является и концом недели или месяца, происходит считывание
83
информации по выполненным задачам по этому периоду. Кроме
считывания, происходит автоматическое затирание значения до нуля,
например: db.users.update({id: {userId}}, {$set: doneTasks.day: 0}). Тот из
пользователей каждой команды, кто выполнил наибольшее или
наименьшее количество задач, получает соответствующий бейдж.
На этом участке наблюдается большая загруженность системы в
момент смены даты, поэтому при увеличении количества пользователей,
использующих систему, имеет смысл масштабировать её следующим
образом: сохранять для каждой команды время её создания и производить
подсчёт статистики ежедневно в это время. Так мы распределим нагрузку
на мощности серверной стороны работы приложения по времени и
улучшим качество его работы при взаимодействии с запросами
пользователей.
Валюта, url ‘/finances’
Так как большая часть финансовых начислений происходит без
специальной отправки запросов, например, при закрытии задач, в этом
роуте имеется всего два адреса:
1. /purchase – POST, покупка бонуса. Осуществляет вычет
соответствующей стоимости покупки суммы со счёта
пользователя путём обновления соответствующей строки
пользователя через db.users.update, добавляет запись в историю
покупок и добавляет в БД уведомление для менеджера проекта.
Если при этом на счету пользователя остаётся ровно 0,
происходит присвоение пользователю бейджа «Один раз живём!».
2. /send – POST, передача средств от одного пользователя другому.
Производит вычет и начисление переводимой суммы со счета
адресанта и на счёт адресата соответственно. Также добавляет
записи истории и пересчет финансовой статистики.
84
3.5. Выводы по третьей главе
В процессе разработки было реализовано полноценное fullstack-
приложение, позволяющее использовать одну из лучших систем
управления разработкой, так и современные тренды к геймификации.
Во время работы не было обнаружено никаких несовместимостей
требований к системе и тех технологий, которые мы определили для
реализации: ECMAscript 6 на фреймворке Vue.js для стороны клиента и
Node.js на фреймворке Express для серверной стороны. Можно утверждать,
что эти технологии более чем подходят для реализации приложений
малого и среднего размера и могут конкурировать в IT-среде в том числе и
для крупных бизнес-разработок.
85
ЗАКЛЮЧЕНИЕ
В процессе написания магистерской работы мы выполнили ряд
поставленных задач:
1. Исследовали современные методы управления разработкой ПО,
определили сильные и слабые стороны каждого из методов.
2. Изучили предпосылки и психологические особенности явления
геймификации, нашли и изучили примеры внедрения геймификации
в бизнес-структурах.
3. Определили основные потребности участников всех сторон
разработки ПО, а также методы управления и виды геймификации,
которые способны удовлетворить эти потребности.
4. Создали новую систему управления разработкой ПО и подготовили
её к внедрению на практике в компании или IT-подразделении,
осуществляющем разработку программного обеспечения.
Созданная система позволяет решить большую часть проблем,
связанных с разработкой программного обеспечения, обозначенных в
начале нашей работы:
1. Проблема слабой интеграции разработчиков с общими идеями и
интересами компании решается созданием корпоративной валюты,
оформлением процессов геймификации в стиле компании, а также
участием разработчиков в одной общей со всеми игре.
2. Проблему слабой прогнозируемости сложности и длительности
процессов разработки решают инструменты начального этапа
спринта: презентация проекта команде разработки и этап «дебатов»
разработчиков с заказчиком.
86
3. Проблема сложности оценки качества работы разработчиков решена
нами частично, с помощью получения игровой валюты за
выполнение задач, поставленных разработчиком перед самим собой,
а также через «монетизированный» процесс Code Review.
4. Проблема низкого уровеня проработки модели конечного результата
на начальной стадии разработки ПО решается вовлечением
заказчика в работу на начальных этапах проекта: презентация и
дебаты с командой.
В целом, результат нашей работы является объединением двух
эффективных и работающих инструментариев: системой управления
разработкой программного обеспечения Agile, с одной стороны, и
геймификацией, способной замотивировать работников к более
оперативной и качественной работе, с другой. И то и другое хорошо
показывают себя по отдельности, однако взяв их лучшие стороны, можно
предложить компаниям мощный продукт повышения производительности
в IT-подразделениях.
Тот факт, что на сегодняшний день в обществе происходит смещение
представлений о статусе и удовлетворение иерархического инстинкта
происходит даже в социальных сетях и Online-играх, обязывает нас
использовать особенности нашего времени. Вопросы, к примеру, о
заработной плате сотрудников часто являются личными, и этот показатель
не может помочь людям сформировать внутривидовую иерархию, тогда
как система виртуальных баллов, наград, бейджей отлично справляется с
этой задачей. Участники игры всегда видят, кто находится впереди, и
стараются не отставать от лидера.
Мы нашли рабочие примеры интегрирования геймификации в работу
коммерческих компаний, которые оказывают существенное влияние на
успешность каждого отдельного сотрудника и, как следствие, на успехи
87
компании в целом. Таким образом, можно утверждать, что даже один из
элементов, использованных нами в работе, может улучшить ситуацию в
компании, а объединение их в стройную систему поддерживающих друг
друга возможностей для достижения лидерства должно привести к
мощному рывку для каждого разработчика, и для результатов всей
команды.
Хотя мы объединили множество возможностей различных систем,
система не выглядит чересчур сложной. Простая доска Kanban способна
удовлетворить большинству требований небольшого или среднего размера
IT-подразделения. Дополняя её системой спринтов с историями и
задачами, которые могут иметь разные типы и приоритет выполнения, мы
закрываем практически все потребности хорошего менеджмента. Наконец,
интегрируя в эту систему правила геймификации, а их не так много:
виртуальная валюта и два вида бейджей – мы завершаем создание нашего
приложения. Такого рода система не должна быть сложной ни для того,
чтобы работать с ней командам любого размера, ни для того, чтобы
реализовать её небольшой группой разработчиков.
При том, что система не является сложной, в ней, тем не менее,
имеется большое количество функционала, с которым пользователь может
работать. Вполне ожидаемой может оказаться ситуация, в которой
разработчик не сможет быстро разобраться со всей системой и, если он не
поймёт, как использовать весь имеющийся функционал, то будет
испытывать отторжение и неприятие этой системы. Однако, эта проблема
должна решиться сама собой. Чтобы работать с системой, пользователю
необязательно пользоваться сразу всеми функциями: его погружение будет
происходить совершенно органично, в процессе работы с доской Kanban.
Просто входя в систему и перенося карточки своих задач из колонки
одного статуса в колонку другого, пользователь уже будет совершать
88
действия-триггеры, которые будут приводить либо к получению им
некоторого количества виртуальной валюты, либо к получению бейджей
того или иного типа. Всплывающие окна, поздравляющие его с тем или
иным достижением в системе, будут мотивировать его изучать систему и
открывать для себя новый функционал. Так, в сжатые сроки, но без
особого напряжения и раздражения, каждый пользователь системы сможет
погрузиться в процесс геймификации, и это начнёт стимулировать его к
более эффективной работе.
Что же касается сложности внедрения этой системы, мы полагаем,
что достаточно, чтобы в команде был один человек, решивший
использовать её у себя, как правило, менеджер, и он сможет использовать
руководство по использованию системы, чтобы самостоятельно
разобраться с ней и впоследствии помочь сделать это всем членам своей
команды.
89
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1. Стюарт Браун. Игра. Как она влияет на наше воображение, мозг и
здоровье –– М.: Литагент «МИФ без БК», 2015
2. Кавтарадзе Д.Н. Обучение и игра: введение в интерактивные методы
обучения / Д.Н. Кавтарадзе. – 2-е изд. –– М.: Просвещение, 2009
3. Эльконин Д.Б. Психология игры –– М.: Владос, 1999.
4. Ворошилов В.Я. Феномен игры –– М.: Советская Россия, 1982.
5. Сотская М.Н. Зоопсихология и сравнительная психология. Учебник,
–– М.: МГУ - 2007.
6. Фабри К. Игра у животных. –– М.: Знание, 1985
7. Фабри К. Основы зоопсихологии. –– М.: МГУ, 1976.
8. Зорина З.А., Полетаева И.И., Резникова Ж.И. Основы этологии и
генетики поведения. –– М.: Изд-во МГУ, 1999.
9. Вагнер В.А. Сравнительная психология. –– М.: Изд-во Института
практической психологии, 1998.
10. Курпатов А.В. Иерархическая катастрофа. Журнал «Сноб» –– М.:
№01 (92) Весна 2017.
11. Локк Д. - Основы Управления Проектами. –– М.: HIPPO, 2004.
12. Арчибальд Р. Управление высокотехнологичными программами и
проектами –– М.: ДМК Пресс, 2010.
13. Милошевич Д. Набор инструментов для управления проектами —
М.: ДМК Пресс, 2008.
14. Кеннет C. Рубин. Основы Scrum: Практическое руководство по
гибкой разработке ПО, М.: ВИЛЬЯМС, 2016.
15. Адкинс Л. Коучинг agile-команд. Руководство для scrum-мастеров,
agile-коучей и руководителей проектов в переходный период — М.:
Манн, Иванов и Фербер, 2010.
16. Шохова З. Путь скрам-мастера — М.: Манн, Иванов и Фербер, 2017.