Завершился "Проектный практикум"

"Проектный практикум" - это курс, который я веду. Самое интересное в нем, что я работаю с группой студентов и реально работаю с коллективными комтепенциями. Про процесс преподавания я уже писал раньше. Сначала тут, потом тут и тут. 
Вкратце результаты.

• Конфликт все-таки состоялся - в той группе, где было четыре студентки и руководитель Сергей Л. Он такой парень своеобразный, хотя и после армии, отслужил сержантом. Вбил себе в голову, что не умеет работать в коллективе. В конце-концов группа отказалась работать по его плану и написала собственную концепцию проекта. Проблема была в том, что все собрались сдавать зачет раньше, и надо было пойти на встречу желанию группы. В результате группа послала руководителя и все сделал сама (да еще принесла мне скриншоты, где руководитель и меня посылает. "И лучшая из вас - змея" Шекспир о женщинах).
• Результат (продукт проекта) получился интересный, скорей по задумке, чем по исполнению. Обещали сделать интернет-сервис для ювелиров, который помогал бы создать свое собственное индивидуальное кольцо. (Вначале был замысел вообще сделать 3D руку, на которое кольцо надевать, но не получилось). В принципе этот проект можно было перевести в стартап, я их немного поуговаривал. Пытался объяснить, что проект хороший, но до конца его доведут, потому, что коллектив из одних женщин психологически не устойчив, и что Сергей им все-таки нужен... Получил следующий ответ: "Подумаешь, бутылочка новопассита на троих, и все в порядке..."
• Вторая группа, где были четыре студента и руководитель девушка Мария З. Конфликтов особых не было. Но у всех осталось разочарование. Сказали, что будут дальше продолжать эту разработку. 
• Результат вполне приличный (на мой взляд). Можно скачать. Реальный прототип игры. 

Помимо результатов, я всех заставлял заполнить такой отчет, который называется "Построектный анализ". Вот несколько штук.

Первая команда

---

Надежда К.

Что сделано

За время выполнения проекта мною было сделано: генерация идеи, обсуждение с участниками команды, создание концепции, утверждение и обсуждение с группой; поиск информации, поиск аналогов, поиск компонентов для сайта; генерация идей для логотипа, финальной страницы; прорисовка страниц сайта, создание сайта, добавления скриптов, стилей.

Осталось незавершенным

На момент написания отчета остались незавершенными следующие работы: Видео-реклама нашего продукта.

Качество управления проектами

Характеристика	Оценка	Влияние на ход выполнения проекта
Качество планирования	4	Среднее
Качество постановки задач	5	Высокое
Качество тестирования	5	Высокое
Управление рисками	3	Низкое
Управление общением	3	Низкое
Управление временем	5	Высокое

Извлеченные уроки

Приобретенные навыки

Создание сайта с полным функционалом, поиск и применение нужных скриптов, стилей, подключение сайта в интернет, работа внутри команды.

Приобретенный опыт

Опыт работы в коллективе, решение проблем.

Пригодится на будущее

Опыт создания сайта с нуля.

Нуждается в улучшении

Практика работы в коллективе, планирование сроков проекта

Следует избегать в будущем

Брать на себя абсолютно все организационные моменты, выбирать в будущем команду из заинтересованных людей.

---

Елена В. - новый урководитель

Что сделано

За время выполнения проекта мной был разработан дизайн колец, а также сделаны            3d-модели для будущего сайта, обработка полученных моделей

Осталось незавершенным

На данный момент  остались незавершенными следующие работы: Видео-реклама нашего продукта.

Качество управления проектами

Характеристика	Оценка	Влияние на ход выполнения проекта
Качество планирования	4	Среднее
Качество постановки задач	5	Высокое
Качество тестирования	5	Высокое
Управление рисками	3	Низкое
Управление общением	3	Низкое
Управление временем	5	Высокое

Извлеченные уроки

Приобретенные навыки

Создание и разработка 3d-моделей ювелирных колец.

Приобретенный опыт

Работа в коллективе, избежание конфликтов в ходе работы.

Пригодится на будущее

Освоение ювелирных программ и моделирование 3d моделей.

Нуждается в улучшении

Правильность расстановки целей и планирования выполнения проекта.

Следует избегать в будущем

Выбор в будущих проектах людей с общими интересами.

---

В общем женская команда страдает от отсутствия заинтересованности, читай - не хватает лидера.

Вторая команда

---

Иван С. - зам. руководителя, главный технический специалист

Что сделано

За время выполнения проекта мною были завершены следующие работы:

изучил Unity, разобрался в интерфейсе, научился переносить объекты из разных программ в unity, разобрался в создание скриптов(физики, управления и т.д), создание материалов для объектов  .

Осталось незавершенным

На момент написания отчета остались незавершенными следующие работы: не экспортировали игру на Android и IOS.

Качество управления проектами

Характеристика	Оценка	Влияние на ход выполнения проекта
Качество планирования	5	Высокое
Качество постановки задач	5	Высокое
Качество тестирования	5	Высокое
Управление рисками	5	Среднее
Управление общением	5	Низкое
Управление временем	5	Среднее

Извлеченные уроки

Приобретенные навыки

Навык разработки игры с помощью ПО, применение разработки 3D max

Приобретенный опыт

Планировать свою работу по времени

Пригодится на будущее

Знание  Unity 3D и программирования

Нуждается в улучшении

Рациональное использование времени и правильного коллектива

Следует избегать в будущем

брать на себя большой объем работы

---

Иван И. 

Что сделано

За время выполнения проекта мною были завершены следующие работы:

программирование игры с помощью поиска и применения нужных скриптов, разработка окружения.

Осталось незавершенным

На момент написания отчета остались незавершенными следующие работы: установка игры на мобильные операционные системы Android и IOS.

Качество управления проектами

Характеристика	Оценка	Влияние на ход выполнения проекта
Качество планирования	5	Высокое
Качество постановки задач	5	Высокое
Качество тестирования	5	Низкий
Управление рисками	5	Среднее
Управление общением	5	Низкое
Управление временем	5	Среднее

Извлеченные уроки

Приобретенные навыки

Навык разработки игры с помощью ПО, применение разработки 3D max

Приобретенный опыт

Опыт работы в коллективе

Пригодится на будущее

Знание программного обеспечения Unity 3D

Нуждается в улучшении

Рациональное использование времени

Следует избегать в будущем

Женского руководства - не понравилось ему, как Маша им руковдила

Не уйти мне от дистанционных курсов...

Поучаствовал в конкурсе, который объявляло издательство "Директ-Медиа" на разработку электронных курсов. В призеры не попал. Но неожиданно познакомился с хорошим человеком - Юрием Николаевичем Белоножкиным. Он записал меня на свой курс по дистанционному обучению. Выяснилось, что по ходу дела надо написать эссе. Вот и пишу. Будет эссе для курса и черновик для статьи. Называется.

К методологии проектирования дистанционных курсов или грабли, на которые предстоит наступить.

Было дело. И мы руковаживали.

Лев. Шебаршин. "КГБ шутит".

Учебный курс, разработанный в рамках программного продукта Мудл, несомненно является программным продуктом. Но у меня создается впечатление, что многочисленные за последнее время разработчики электронных курсов и их менеджеры никогда не занимались разработкой программных продуктов. . Доказательства? А вот...

Когда речь заходит о методиках проектирования электронных учебных курсов все толкуют про широко известную методологию ADDIE. Название происходит от первых букв: A (analyze), D (Design), Develop (develop), Implemen (применение), Evalute (оценка). Еще Кухаренко заставлял на ее учить - смутно помню, что сдавал по ней тест. Основная идея методики ADDIE в том, чтобы закончить каждый шаг, прежде чем приступить к следующему шагу. Таким образом, методология ADDIE с точки зрения управления представляет линейную (каскадную) модель разработки.

Засада первая.

Неопределенность в оценке трудозатрат. Это хорошо известный "конус возможностей". 

Что тут нарисовано? Коридор ошибок, который имеет место быть на разных стадиях разработки программного проекта. Т.е. на стадии обсуждения базовой концепции решения ошибка в оценке трудозатрат будет составлять +-400%, потом она постепенно снижается на стадиях разработки концепции, утверждения требований.

Хороший пример - прошедший конкурс. Кто-то спрашивал с авторов концепцию курса, не говоря уж про согласование требований. (Концепцию, конечно спрашивали, но исключительно в авторском видении, что имеет мало общего с формализованным процессом разработки концепции). Вообще, есть у издательства какая-то внятная методология работы: шаблоны документов и прочее? То-то ...

Засада вторая

Методология ADDIE - линейная модель разработки. Проблемы с линейными моделями известны. Как всякая линейная модель управления методология ADDIE имеет следующие достоинства:

• модель хорошо понимают все неспециалисты в предметной области,
• проста и удобна в применения за счет того, что все процессы выполняются поэтапно,
• облегает процедуры контроля качества, планирования проекта

и следующие недостатки:

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

В общем, если кто-то из разработчиков не поймет требований, то вернуться обратно будет трудно. Отсюда вытекает и засада третья


Засада третья

Управление требованиями - самая сложная область проектной деятельности. На самом деле мало кто вообще понимает, это про что. Особенно из всяких чтецов многочисленных курсов по управлению проектами, потому что даже профессиональные стандарты не сильно любят эту тему. Как-то это формализовано для ИТ. Дальше - все. Я даже разродился на эту тему статьей.
Но помимо требований, которые можно считать как чисто программные: требования к интерфейсу, к объему контента (количество видео, графики) есть еще педагогические требования. Возьмем для примера курс, где я записан. С интересом прочитал программу курса. Оказывается, что в результате освоения курса слушатель должен получить 11 обшекультурных компетенций и столько же профессиональных. Даже простой арифметический подсчет - 8 модулей против 22 компетенций, дает что в каждом модуле должно воспитаться 2,75 компетенции. Путем написания эссе по каждой теме и болтовни на форуме? Не смешите мои тапки. По идее, должна быть входная и выходная диагностика по каждой компетенции, должен быть ФОС - фонд оценочных средств, которые оценивают, насколько сформировалось компетенция. И вообще, почему я, когда пишу всякие учебные программы, потею над этими ФОСами, а Белоножкин - нет? Где социальная справедливость? В общем, все как обычно - бардак.   

Засада четвертая

Она же самая большая. Засада в том, что при линейной модели разработки 70% процентов трудозатрат падает на стадию сопровождения продукта. Примерно так.

Имеются ввиду многочисленные изменения, которые надо вносить по ходу эксплуатации. По жизни это означает, что издательство, которое заключило с авторами договор на разработку курса, через некоторое время может обнаружить (если доживет), что проблемы еще и не начинались, т.к. заплатить надо в три раза больше. Это вообще хроническая проблема разработки программных продуктов. Заказчик - издательство встанет перед дилеммой, в уже готовом курсе без конца нужны какие-то изменения, и тьюторы курса на это усиленно намекают, мол не соответствует курс теперешним задачам, мол поправить надо бы, мол прогресс же не стоит на месте и новые плагины появились и дизайн бы надо подправить... Если так пойдет, и клиентов можем потерять. Заказчик (издательство) им намекает в ответ: а где деньги на это взять? А то и тролить начнет бедных тьюторов, мол скажите у кого из вас из зар.плату уменьшить - тут же изменения внесем. 

По-моему, нет особого смысла рассуждать про экономику дистанционного обучения. Так, поумничать, если кто захочет.

Чем лечить?
Пилюля первая
Внедрение технологий проектного управления, переход на проектный офис. Результаты значительно улучшаются. Вот слайд из моей книжки по управлению проектами.

Вот мои личные данные по трудоемкости на различных стадиях выполнения проекта. После внедрения проектных методов.

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


Пилюля вторая.

Называется управленческий учет. нужен управленческий учет в разрезе каждого проекта - точнее каждого курса. Больше того, не только в разрезе курса, но и разрезе стадии: разработка, эксплуатация. Но на это мало у кого хватает мозгов (а может терпения). Это позволило бы создавать и отслеживать бюджет каждого проекта. Но есть один большущий минус: надо с бухгалтерией рулиться - вы ее явно не обрадуете своими завиральными идеями. 

Пилюля третья

Уход от линейной модели разработки курса к версионной, т.е модели при которой правка курса идет параллельно с его эксплуатацией. Плюс в том, что стадии эксплуатации и разработки идут параллельно и трудозатраты, как и деньги размазываются равномерно по производственному циклу. Компания Микрософт любит такие картинки, объясняя свой принцип работы.

В общем красиво. Но тоже не без проблем. Для версионной модели разработки продукта известны следующие достоинства:

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

и следующие недостатки:

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

Пилюля четвертая

Где-то читал цифры,что несмотря на все ухищрения, доля по миру(!) ИТ-проектов, которые заканчиваются укладываются в бюджет и в график составляет где-то 33%. И не надо строить себе иллюзий. Нужна грамотная работа с рисками. Это по-умному, а по-простому многократное резервирование денег.

И последнее, самое обнадеживающее - все равно все издержки ложатся в конечную стоимость обучения. 

PS

Недавно пообщались по скайпу С Юрием Николаевичем Белоножкиным. Поднятая тема оказалась актуальной. Но, увы, далеко не всегда понимаемой так, как я хотел сказать. Возможно тема даже поднята слишком рано. 

Поэтому несколько уточнений. 

1. По компетенциям. Оказалось, что в профессиональных стандартах компетенции тоже детально прописаны. Поэтому на вопрос о социальной справедливость "И вообще, почему я, когда пишу всякие учебные программы, потею над этими ФОСами, а Белоножкин - нет?" - ответ положительный. Социальная справедливость есть. Мы оба потеем )))

2. Про издательство. Издательство понимается исключительно как пример организации - заказчика. Без всяких претензий на то,что я не попал в число избранных на конкурсе. 

Разработка учебных курсов еще далека от той рыночной стадии, на которой давно уже находится рынок программных продуктов. Хотя пост как раз про грабли, на которые предстоит наступить. Но будем считать что неудачливых предсказателей пруд пруди, если автор этого поста пополнит из ряды - никто и не заметит.

Продолжу про проекты

Продолжу про проекты. Это я к тому что у меня есть дисциплина "Проектный практикум". Про особенности преподавания я уже писал. Самая главная особенность, что я работаю с группой, и даю группе самой возможность выбрать тему для своего проекта. Считаю, что это себя полностью оправдывает.

Вот доказательства. Каждая группа составила свой план выполнения проекта. Одна группа решила, будет делать компьютерную игру. Вот ее план исполнения проекта.

Вторая группа решила делать интернет-сервис для ювелирных магазинов, который предоставляет возможность виртуальной примерки изделия на виртуальную же руку за счет возможностей 3D визуализации. Вот ее план выполнения проекта.

В целом планы вполне грамотные. И тематика интересная. Причем я знаю, что часть работы они выполняют во время изучения других дисциплин. Но это ведь не плохо? Междисциплинарное взаимодействие, знаете ли )))