E-learning-проекта компании competentum
Объект исследования: процесс реализации международного eLearning-проекта.
Результаты, полученные лично автором: получены рекомендации по улучшению методологии оценки и управления рисками при реализации eLearning-проекта.
E-Learning означает electronic learning – электронное обучение, то есть, использование электронных информационных устройств в образовательных целях. В настоящее время e-Learning является одним из трендов современных ИТ. Компания Компетентум занимается разработкой e-Learning-проектов, заказчиками являются в основном государственные и частные образовательные учреждения в США и Европе.
В Компетентуме я являюсь frontend-разработчиком. Что же побудило меня подготовить этот доклад? Некоторое время назад на выполнение был отправлен небольшой проект, являющийся, по сути, продолжением того проекта, что был сдан ещё раньше. По стечению обстоятельств и согласно планированию ресурсов, над этим проектом сначала работало трое разработчиков, затем нас осталось двое, и, в итоге, остался лишь один – я. Благодаря этому у меня появилась возможность увидеть несколько больше в организации проекта. То есть, стало трое действующих лиц с нашей стороны – менеджер, разработчик и тестировщик. Так как настоящий анализ проводится уже постфактум, он отличается от того, который бывает на стадии предпроекта. Будут даны ответы на следующие вопросы «Какие риски сыграли?» и «Как этого, на мой взгляд, можно было избежать?»
Технологически (как и большая часть нашей продукции) проект, о котором идёт речь – это SPA (single page application) на JavaScript+HTML5. Суть проекта – пособие по физике, содержащее видео с преподавателем, вопросы с выбором ответа и опыты-интерактивы. Всё это вписано в поделённые на части – квадранты – страницы приложения. Всего в проекте шесть подобных SPA – аналогов уроков. На старте уже даже была основа – так называемая оболочка (shell) – движок на языке JavaScript, который осуществляет размещение контента на экране и логику работы интерактивов и навигации по слайдам.
Что может пойти не так? Ниже в формате «причина-следствие» приведён список рисков, которые могли появиться на проекте.
· Недостаточная оценка трудозатрат – срыв сроков.
· Неопытность исполнителей – ухудшение качества.
· Отсутствие материалов от заказчика – позднее согласование реализации.
· Отсутствие общего видения деталей проекта – позднее согласование реализации.
Технически, проект весьма простой, и на его реализацию – добавление контента (видео, картинок, вопросов) – должно было уйти минимум времени. Это и был самый главный риск, который сыграл – недооценка.
Есть конкретный случай: одним из интерактивов в проекте является рисование графиков: ученик должен нарисовать графики положения и скорости материальной точки, а приложение должно проверить, верно ли он это сделал. Этот функционал является дополнительным для существующей оболочки. Возможно, и я уверен, что при оценке было учтено, что предстоит дописывать функционал интерактивов. Но как учтено? На разработку урока, содержащего этот интерактив, было выделено три человеко-дня. Фактически на это ушло примерно человеко-месяц. Как можно было избежать этого? Потратить чуть больше времени на оценку. Даже не самому опытному разработчику не составило бы особого труда выяснить, чего не хватает в текущей оболочке или же чего не хватает из материалов.
Менеджером этого проекта был назначен человек, проходивший (и не прошедший) испытательный срок на должности проектного менеджера. Это сыграло свою отрицательную роль. Менеджер, как известно, является передатчиком информации от заказчика к разработчикам. Задержка в передаче информации иногда составляла неделю. И для этого случая, допустив, что менеджер некомпетентен, можно дать рекомендацию разработчикам: постоянно следует напоминать менеджеру о том, что нужна быстрая обратная связь от заказчиков по тому или иному вопросу.
Материалы от заказчика поступали в виде .pdf-файлов на каждый урок, в которых было описано, что хочет видеть заказчик. До позднего времени (того времени, когда разработчик брался за наполнение урока контентом), в требованиях можно было видеть графики, которые необходимо было вставить в электронный урок, в очень низком качестве – было невозможно различить значения на шкалах. Это, конечно, поспособствовало срыву сроков.
Кроме того, в материалах можно было встретить такое: (показываю на экран). Здесь, однако, удалось получить приличные графики быстро – менеджер сменился. Что можно было сделать? Сразу после того как были получены исходные файлы, просмотреть их и сообщить заказчику о том, что в их материалах не хватает необходимых элементов.
Как избежать? Разработчику – быть более внимательным, менеджеру – быть максимально заинтересованным в том, что делается на проекте.
Таким образом, уделяя больше времени оценке, и в целом тому, что происходит на проекте, можно, если не целиком, но на какую-то часть избежать срабатывания рисков.
Материал поступил в редколлегию 20.04.2017
УДК 004.4
С.И. Родькин
Научный руководитель: ассистент кафедры «Информатика и программное обеспечение», Е.В. Коптенок