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

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

• Конфликт все-таки состоялся - в той группе, где было четыре студентки и руководитель Сергей Л. Он такой парень своеобразный, хотя и после армии, отслужил сержантом. Вбил себе в голову, что не умеет работать в коллективе. В конце-концов группа отказалась работать по его плану и написала собственную концепцию проекта. Проблема была в том, что все собрались сдавать зачет раньше, и надо было пойти на встречу желанию группы. В результате группа послала руководителя и все сделал сама (да еще принесла мне скриншоты, где руководитель и меня посылает. "И лучшая из вас - змея" Шекспир о женщинах).
• Результат (продукт проекта) получился интересный, скорей по задумке, чем по исполнению. Обещали сделать интернет-сервис для ювелиров, который помогал бы создать свое собственное индивидуальное кольцо. (Вначале был замысел вообще сделать 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 визуализации. Вот ее план выполнения проекта.

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

Все плохо - 2015

Был на очередной конференции НОТВ-2015 (НОТВ - Новые Образовательные Технологии). Повестка конференции обусловлена тем, что бывший УПИ (Уральский Политехнический Институт), который путем слияния преобразовали в УрФУ (Уральский Федеральный Университет), решили сделать центром дистанционного обучения, Приезжал Соболев - выходец из УПИ, нынче глава департаменте образовательной политики в Минобре.

Рассказал, что решается задача по переходу на новые образовательные стандарты, В том числе путем развития дистанционного обучения. Попутно решается задача сокращения преподов, которые, как известно полное совковое говно (о чем сообщила представительница "вышки"). Соболев сообщил, что "аннушка разлила масло", решение принято. Расслабьтесь и постарайтесь получить удовольствие. 

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

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

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

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

UPD.
Люблю приводить цитату из книги святителя Феофана Затворника "Созерцание и размышление", из главы "Ум православный и ум немецкий".

Как у драчуна руки чешутся, а у говоруна язык, так у немца чешется мозг и не дает ему покоя. Дух новизны и непрестанного поновления составляет существо немецкого ума. 

Диалоги со студентами.

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

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

Начинаю трамбовать студентов на тему плана. Типичные диалоги.

- Поздравляю. Сегодня последняя неделя, когда группы должны мне сдать планы исполнения проектов. Группа, которая не сдаст до конца недели, не получит зачет.
- Почему я должен страдать из-за XXX?
- Потому, что ответственность за проект коллективная.
- А почему ответственность коллективная?
- Потому, что а) дисциплина называется "Проектный практикум", потому что б) в рамках дисциплины вы должны получить навыки коллективной работы, потому что в) в реальной жизни (в проектном бюро) ответственность тоже будет коллективная.

В одной  группе руководитель на лекцию не явился. (Там еще девица такая с гонором. Типа теневой лидер, но с отрицательным знаком. Такие бывают иногда). Диалог.

- Ну, это же не я не сделал план. Это же XXX. У нас с ним вообще в группе конфликт.
- Я вам уже рассказывал в лекциях про то, что конфликты - неизбежная часть проекта. Даже показывал слайды про интенсивность конфликтов на различных стадиях проекта. Даже показывал слайды, как надо сменить отношение к конфликтам.

На прощание говорю.

- Любой конфликт существует пока у него есть две стороны. Как только одна сторона прекращает конфликтовать, конфликт пропадает. Так что обращайтесь к своему руководителю. У него завтра есть последний день для сдачи плана. Лично я ХПП (хитрый план путина) на случай несдачи уже придумал.

Вечером приходит письмо от руководителя группы

Прошу прощения за опоздание. Необходимо время. Я исправлюсь. Высылаю документ.

PS
Еще вспомнил. На каком-то из прошлых занятий Маша - руководитель одной из групп спрашивает:

- Как сделать ... (не помню уже чего, но что-то по структур работ проекта),
Я по преподавательской привычке начинаю:
- Маша, я же давал пособие, там все написано ...
Маша, перебивая меня:
- Да я смотрела, Вы скажите, как сделать.

Продолжаю мучить студентов

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

Сегодня вы должны были сдать мне концепции и планы работ. Информирую:
если принесете на зачет планы и концепции, работа будет считаться НЕ СДЕЛАННОЙ.
Работа в группе должна вести по плану, который принят ДО сдачи готового продукта.