 | Создала Елена Локтева 6 февраля 2011 г. в 01:06
в категории «Управление проектами e-learning» |
Коллеги, завожу эту ветку форума вот с какой целью.
Каждый, кому приходилось участвовать во внедрении e-learning, наверняка сталкивался с какими-то неожиданными ситуациями, которые влияли на ход проекта — замедляли его или ускоряли, расширяли или сужали задачи и т.п.
Поделитесь коротко этими ситуациями:
1) где внедрялся e-learning (можно без названий, важно — в вузе ли, в компании или еще где);
2) какая неожиданность случилась в ходе проекта;
3) как она повлияла на ход проекта.
Заранее спасибо всем за ответы, которые я уже жду с большим нетерпением!
| Теги: | опрос, неожиданность, непредвиденные обстоятельства, проект, e-learning | |
|---|
|
Рейтинг 227 | Скажу несколько в общем, не особо конкретизируя.
Частые неожиданности такие:
1. Понимание, что некоторая задача была изначально поставлена не очень корректно. Что была ошибка в мышлении, которая, тем не менее, хорошо закрепилась в голове. Например, поставлена задача — разработать некоторый курс. Создана проектная группа, налажено взаимодействие между ее членами, собраны материалы, уже разработана структура курса и вовсю идет оформление. Но только на этом этапе становится понятно, что курс вообще не поможет решить имеющиеся проблемы в бизнесе. Что нужно, по-хорошему, провести ряд организационных изменений, а курс если и делать — то совсем на другую тему.
Избежать такой ошибки можно было бы, уделив больше внимания анализу ситуации на раннем этапе проекта.
2. Отсутствие согласованности в ожиданиях заказчика и исполнителя. Когда исполнитель делает одно, а закачик от него ждет другого, и это выясняется только на стадии приемки результатов работы.
Чтобы избежать этого, на мой взгляд, нужен целый комплекс мер.
1) Нужно хорошо понимать бизнес-задачи и цели заказчика. Не только те, которые включаются в данный проект, но и вышестоящие, и смежные.
2) Понимать бизнес-задачи и цели других заинтересованных сторон.
3) Нужно аккуратно согласовывать ожидания и выявлять скрытые требования, даже если заказчик сам о них не говорит явно.
4) Желательно, сдавать работу поэтапно, а также использовать пилоты.
В целом все это, на мой взгляд, относится не столько к e-learning, сколько к управлению проектами
|
|---|
Рейтинг 569 | Спасибо, Михаил!
Оба пункта — очень в точку, и действительно очень распространены. И действительно, не только в проектах eLearning.
А могли бы Вы несколько конкретных примеров привести? Более кейсово?
|
|---|
Рейтинг 227 | Елена, мне как раз не хотелось бы очень конкретизировать.
Парочку примеров могу описать чуть конкретнее
1. Был курс, положенный на полку сразу после завершения. На стадии согласования с заказчиком выявился ряд проблем. Проработав эти проблемы, обнаружили, что неправильно определен набор заинтересованных сторон. Были влиятельные люди, которые гораздо лучше понимали специфику предметной области, чем наш заказчик. Эти люди вполне обоснованно показали, что курс нужно делать совершенно по-другому. А именно
а) неправильно определена цель курса и целевая аудитория
б) неправильно определен круг вопросов, рассматривавшихся в курсе. Нужно было сосредоточиться на гораздо более узкой предметной области
в) в курсе не учитывались многие существенные запланированные в предметной области организационные изменения
2. По второй ситуации у меня был случай, когда из-за того, что не были должным образом продуманы организационные моменты, связанные с курсом, запуск курса пришлось отложить на несколько месяцев. В то же время, ничто не мешало прорабатывать эти организационные вопросы параллельно с разработкой курса. Но фактически, о них задумались только после окончания разработки.
Ну и еще был неприятный случай, когда я был на стороне заказчика, а не исполнителя. Мы делали один проект, связанный с eL, с рядом ИТ-специалистов. ИТшники требовали технических заданий, в которых подробно должны были описываться различные технические моменты, которые я не слишком хорошо понимал. Потом оказалось, что некоторые вещи я в техническом задании не описал (подумал, что они сами собой подразумевается, даже не пришло в голову, что это нужно оговаривать). А также некоторые проблемы выявились только в процессе работы. В начале, из-за того, что я плохо представлял себе технические особенности работы, я не подумал о том, что встанут эти проблемы.
При этом ИТ-специалисты очень негативно относились к любым изменениям в изначальное техническое задание, из-за этого время проекта существенно увеличилось.
Думаю, нужно было в первых этапах проекта сделать больший акцент не на техническое задание, а в целом на бизнес-задачи проекта. И заинтересовать коллег именно в выполнении бизнес-задач, а не только в работе четко по техническому заданию.
|
|---|
Рейтинг 131 | В первом абзаце описана Главная Неожиданность: «задача была изначально поставлена не очень корректно». И ее причина «ошибка в мышлении, которая, тем не менее, хорошо закрепилась в голове». Ошибку можно назвать «прошлый опыт», «шаблоны», «стереотипы мышления».
За ней противоречие: Надо использовать прошлый опыт — куда же без него? — но прошлый опыт мешает находить Новые Нестандартные Решения, диктует привычные решения. Противоречия разрешать = устранять без ТРИЗ в короткие сроки затруднительно. Вот и громоздятся одна Большая Неожиданность на другую :-) ) . Плывут сроки, стоимости, множатся бюджеты и т.п.
Михаил предлагает «больше внимания Анализу Ситуации на раннем этапе». Здесь опять противоречие: Если больше внимания — больше затраты времени! Меньше внимания — меньше затраты! надо бы ОПтимизировать, но кто его знает где он «оптимум».
Решение видится в использовании Алгоритма, позволяющего Быстро, Качественно и Согласованно проводить Анализ Ситуации отдельному руководителю или группе.
В условиях ужесточающейся конкуренции продвигаться будут те разработчики, организации, что сумеют приблизить свою деятельность к логике, диктуемой Алгоритмом.
Простенький вариант Алгоритма выглядит так:
Объект — Предмет — Проблема — (Причина) — Цель — Задачи — Тема,
где Цель и Задачи составляют Систему, позволяющую ГАРАНТИРОВАТЬ РЕЗУЛЬТАТ работы.
Здесь «тема» возникает как обоснованное следствие Анализа Ситуации, а не берется с потолка.
|
|---|
Рейтинг 227 | Валерий, Ваш Алгоритм я не очень понял. Можете привести пример?
|
|---|
Рейтинг 901 | Елена, спасибо за тему форума.
Михаил, спасибо за примеры неожиданностей. Постараюсь пополнить Ваш список вплоть до совсем уж «детских» неожиданностей, однако не только это.
В ходе внедрения чего бы то ни было (от системы обучения до отдельного курса) в компаниях довольно скоро обнаружил то, что в работе с ними (даже если ты внутренний разработчик) необходимо пользоваться принципом знания о незнании.
Как бы крут ни был заказчик, исполнитель всегда должен понимать, что:
1. заказчик знает больше, чем может проговорить. Многое кажется ему само собой разумеющимся (отчасти это похоже на Ваш, Михаил, пример с ТЗ и айтишниками), что в голову не придет проговаривать, а тем более — формализовать.
Был у меня заказчик, у которого я, грешным делом поинтересовался, что должно измениться в работе у его сотрудников после освоения курса N. Заказчик (в лице более чем очаровательного лица) сильно обиделся, возмутившись: «Он (исполнитель) что, меня за идиотку держит?» С тех пор стал деликатнее интересоваться потребностями в обучении:)
2. Заказчик не хочет выносить сора из избы (особенно перед внешним исполнителем). Когда у него спрашиваешь, чем вызвана необходимость учить тому-то, он стыдливо что-то буркнет что-то неопределенное (в лучшем случае), а то и соврет, например, вместо того, чтоб признаться что текучка кадров более 30%, начнет врать, что заказывает курс по новому продукту (которому уже более 3-х лет в реале). Вот и реши в таких условиях проблему учебной мотивации.
3. заказчик думает что он заказывает А, в то время, как вслух он заказывает В. Так, обсуждал не так давно некий продукт, который виделся заказчику в духе activ learning, но под этим термином он разумел то, что именуется action learning (или наоборот, что тоже бывало)
При этом и мы, разработчики, не должны упускать, что этот принцип и на нас в той же мере распространяется и на нас самих. Об этом можно также кучу примеров привести
|
|---|
Рейтинг 468 | Коллеги, для меня сначала было неожиданностью, что заказчик Департамент поддержки малого предпринимательства Москвы, через год-полтора после запуска проекта бесплатного образования Система Дистанционного Бизнес Образования изъял из проекта раздел конференция (или форум), где обсуждались достоинства и недостатки размещённых учебных материалов.
После до меня дошло. Если бы мэру Москвы пришла блажь посмотреть, что там происходит, то он тут же прикрыл бы проект, прочитав отзывы о деятельности Правительства. Куратор пректа из Депортамента проявил «государственную мудрость». И спасибо ему за это.!
|
|---|
Рейтинг 468 | Коллеги, ещё одна «неожиданность», связанная с образовательной деятельностью, не только через e-learning. Руководитель одного из гос. предприятий заказал повышение управленческой грамотности работников, включённых в список «резерва на повышение» по программе переподготовки. Две группы: «высшие» и «средние» руководители. После окончания программы более трёх четвертей «выдвиженцев» уволились с предприятия. До них дошло, что они теперь живут «на рынке».
|
|---|
Рейтинг 901 | +1
|
|---|
Рейтинг 201 | Вячеслав, а до меня что-то не дошло, про какой «рынок» Вы говорите... :(
|
|---|
Рейтинг 468 | Максим, про российский «рынок». «Продать себя» дороже им «не светит» на родном предприятии. А на открытом рынке «рабочей силы» у них появилось конкурентное преимущество — «второй диплом» об экономическом образовании. «... Так мне кажется?»
|
|---|
Рейтинг 227 | Владимир, на мой взгляд, главное противоречие в следующем. Заказчик и исполнитель никогда не смогут мыслить полностью одинаково и добиться полного взаимопонимания. Однако работа над проектом, как правило, строится таким образом, как будто они друг друга понимают идеально. Заказчик ждет от исполнителя идеального соответствия своим целям и требованиям, явным и неявным. Исполнитель уверен, что его трактовка требований заказчика совпадает с истинными требованиями заказчика.
Улучшить ситуацию можно следующим образом:
1. Признать наличие противоречия.
2. Признать невозможность достижения полного взаимопонимания, особенного, простыми способами
3. Тем не менее, тратить больше усилий на достижение более глубокого взаимопонимания. Заказчику следует активно вовлекаться в работу над проектом, желательно принимать его блоками, регулярно согласовывать текущую работу. Очень желательно постараться самому достичь некоторого уровня экспертизы в том, чем занимается исполнитель. Исполнителю следует выявлять неявные требования заказчика. Быть готовым к внесению изменений в требования.
4. Без достаточного уровня проактивности с обеих сторон проблемы будут возникать постоянно в любом случае.
|
|---|
Рейтинг 901 | Михаил,
согласен с Вашей «программой действий». И дело тут не только в абсолютном единомыслии Заказчика — Исполнителя. Это и прочих людей, видно, касается.
В любом случае, Вы правы, нужна обоюдная проактивность, особая культура взаимодействия, которую нужно взращивать при сотрудничестве заинтересованных в еL сторон.
И еще, в Вашу программу как-то, ИМХО, нужно включить и потенциальных обучаемых, как минимум, изучение их потребностей, интересов, создания для них более или менее комфортных условий обучения (= организацию учебного процесса как такового).
|
|---|
Рейтинг 227 | Насчет обучаемых (обучающихся) согласен. Но тут есть пара моментов:
1. Я говорю про любые проекты, связанные с eL (да и не только с eL), не только разработку курсов и построение интерфейса, с которыми будут работать обучающиеся. А еще про многочисленные ИТ-вопросы, системы отчетности и т.д.
2. Во взаимодействии с обучающимися главное противоречие в несколько другом. В очень большом количестве систем обучения их мнение не исследуется совершенно. К ним относятся как к безответственным и пассивным, не видящим смысла в обучении и развитии. Отсутствует доверие между ними и учебным центром. Обучение навязывается, людей заставляют учиться. В таких условиях невозможно говорить о полноценном изучении потребностей, да и вообще многим вещам научить в таких условиях невозможно. С другой стороны, если учиться всех заставляют, то явно суммарный объем обучения будет больше, что используется как основной способ обоснования значимости учебного центра для компании. Кроме того, в этих условиях легко дать «гарантию» топ-менеджменту, что целевая аудитория (хотя и ее иногда не могут правильно определить) знает материал необходимого курса (она же сдала тест). А топ-менеджмент обычно очень высоко ценит эту гарантию.
Это и есть главное противоречие взаимодействия с обучающимися. Оно затмевает собой почти все остальные, и оно мало где решено (и у нас в компании в том числе, хотя, на мой взгляд, у нас ситуация гораздо лучше, чем у многих других).
И еще: «взрастить» проактивность обучающихся просто посредством обучения, на мой взгляд, нереально. Ну, может быть, только в отношении отдельных выдающихся личностей. Проактивность может появиться только если среда проактивна, если люди, с которыми общаешься каждый день, проактивны. Ну, может быть, еще тренинги личностного роста могут помочь, хотя я к ним в целом плохо отношусь.
Для создания проактивной среды, наверное, нужна работа над ценностями компании, корпоративной культурой, с привлечением компетентных в этой области экспертов. Ну и соответствующие акценты при рекрутинге персонала.
|
|---|
Рейтинг 901 | Добрый вечер, Михаил.
Позволю себе очередную грубость (в смысле — грубое обобщение):
- все аспекты. которые Вы зафиксировали, мне кажется, растут из одного места: стиля менеджмента, точнее — стиля руководства. Практически все остальное — прилагается и/или вытекает из него.
Наш еL (и не только он) — это процесс, который имеет свое собственное течение. а процессы компании либо способствуют ему, либо тормозят, если не уродуют. Взгляните, в деле управления знаниями, талантами, мотивационного и кадрового менеджмента и т.п. — везде можно зафиксировать аналогичные противоречия. И не факт, что это еL противоречит менеджменту, корпоративным культуре или кадровой политике. Очень часто менеджмент, кадровая политика и корпоративная культура противоречат обучению персонала, самой природе обучения как такового.
Не рассматривайте, пжл, мою позицию, как критиканство. Это только констатация реальной проблемы, которую шапками не закидать и над решением которой предстоит кропотливо, планомерно и долго работать всем сторонам, ее касающимся, если мы не хотим оказаться еще на более дальних задворках, нежели сейчас находимся.
Если в США сейчас главный тренд в корпоративном обучении... управление талантами, то у нас... вообще нет внятного тренда, ИМХО.
|
|---|
Рейтинг 227 | Владимир, так может быть, нам нужно задумываться о развитии и обучении менеджмента? Или это не наша задача?
|
|---|
Рейтинг 901 | Михаил, и это, ИМХО, наша задача. Отнюдь не простая.
В больший компаниях менеджмент не сильно любит учиться, ибо «всегда прав», а если ошибается, то имеет на то право. Он сейчас типа коучируются, а под этим соусом высоким менеджерам легко вдувается в виде «обучения» то, что менеджмент прав по определению (худший вариант), либо то, до чего менеджмент и сам почти дозрел, а завтра — наверняка дозреет.
В нашем же случае, думаю, менеджмент нужно учить пониманию того, что может, в чем компетентно, на что способно обучение персонала компании. Тогда будет минимизировано возникновение ситуаций, о которых мы с Вами любим рассуждать:
- в ситуации N не обучение нужно, а орг.решения,
- учить этому (например, управлению талантами или командообразованию) для вашей компании — неактуально, т.к. компания от этого ничего не выиграет,или т.п.
Ну, а по большому счету, учить менеджмент нужно тому, что обучение есть часть процессов управления знаниями, корпоративной культуры, развития организации и т.п., и тогда только оно станет инструментом роста прибыли. Само по себе обучение прибыли не прибавит.
|
|---|
Рейтинг 131 | Все сказанное уважаемыми коллегами подтверждает необходимость использования Технологии Эффективной Коллективной Деятельности как в работе Исполнителей, так и в работе Исполнителей с Заказчиком.
ТЭКД создана и развивалась Талгатом Акбашевым с 1988 года. Апробирована на проектах от группы детского сада до Выборгского района Ленинграда «Проект Микрорайон как пространство образования детей» и Наб Челнов проект «Технологический университет».
К сожалению, в текстах ТЭКД не зафиксирована и передается как know-how в практической работе поскольку весьма проста.
|
|---|
Рейтинг 901 | Уважаемый Валерий, вместо слова необходимость в вашем тексте: «подтверждает необходимость использования» я предпочел бы несколько иное: возможность.
|
|---|
Рейтинг 131 | Уважаемый Владимир! Не возражаю — предпочитайте ;-) и читайте текст в Вашей редакции.
|
|---|
Рейтинг 201 | Валерий, а Вы можете зафиксировать ТЭКД в тексте? :)
|
|---|
Рейтинг 131 | Максим! Без проблем ;-) !.
Когда собралась группа, то Ведущий (координатор — не путать с фасилитатором и модератором), предлагает провести Анализ Ситуации (и не вносит отсебятины при классическом исполнении, лишь следит за процессом) и согласует с участниками Время Работы Группы.
В классике по окончании работы проводят Анализ Деятельности группы.
Затем 2 этап: Целеполагание. Давайте поставим нашу Цель (на основе АнСит) и Задачи.
И здесь происходит СОГЛАСОВАННОЕ согласование Разных Целей в Систему Целей и ЗАдач.
В классике по окончании также АД группы.
Затем 3 этап: Планирование. Давайте выработаем План (планы) и согласуем их. И снова Согласованное Согласование. По окончании АД группы.
По окончании 3 этапа — получается Программа развития, Бизнес-План, Проект, Стратегия Развития — то, что заказал Заказчик.
А дальше этап 4 — Реализация планов. Мы разошлись и каждый реализует свой план, как часть
Общего Плана. Регулярно проводится АД отдельного участника, подгрупп и группы в целом.
По окончании реализации Плана этап 5: Анализ Деятельности, где мы выясняем наши промахи и — что особенно важно! — Наши Достижения.
Кроме Продуктов Результатом получается еще Взаимопонимание и Сплочение группы, без специальных тренингов. Если точно организован процесс, то он безконфликтный и автоматически сплачивающий даже разных людей..
А по ходу, когда выясняется отсутствие знаний и умений, могут проводиться обучение, семинары, тренинги, и прочее.
Вот примерно так можно описать стержень ТЭКД.
|
|---|
Рейтинг 201 | Валерий, спасибо. Однако у меня возник резонный вопрос: в чем принципиальное отличие ТЭКД от стандарта PMBOK от PMI, которому обучают наших проектных менеджеров на американский манер?
|
|---|
Рейтинг 227 | Максим, мы с Вами прямо одновременно об этом упомянули :) Я Ваше сообщение не видел, когда свое писал.
|
|---|
Рейтинг 201 | Просто аналогии такие. :) Но все же ТЭКД кое-чем отличается. Прежде чем это комментировать, хотелось бы услышать ответ Валерия на мой вопрос.
|
|---|
Рейтинг 131 | М-да! Как объяснить вам разницу между Технологией, укладывающейся в полстраницы текста, осваиваемой «на ходу» и стандартом, который...
Вот что пишет В.Дункан, разработчик стандарта PMBOK:
«Организация должна понять, какого рода стандарт она хочет иметь. Например, люди инженерного склада склонны воспринимать стандарт, как нечто предписывающее. Поэтому, если вы хотите дать им описательный стандарт, сохраняющий значительную степень свободы, лучше назовите как-нибудь иначе -- руководство или общие принципы».
Если сложно ПОНЯТЬ КАКОЙ стандарт нужен, еще сложнее НАУЧИТЬ.
Сошлюсь на формулу: СЛОЖНОЕ СДЕЛАТЬ ПРОСТО, ПРОСТОЕ СДЕЛАТЬ СЛОЖНО.
Авторы PMBOK делают СЛОЖНЫЕ стандарты, как в понимании, так и исполнении. Делают за неимением иного. Почему делают сложно? Не опираются на Законы Природы, не учитывают ВЕСЬ опыт человечества. Делают «от головы».
ТЭКД сделана путем упрощения методологии Г.П.Щедровицкого: выброшено все лишнее и достроено закономерное, но отсутствующее в ней. То есть сделан «следующий шаг» в развитии.
Уважаемым авторам PMBOK еще предстоит сделать такой шаг в будущем. Но пока у них идет этап Усложнения системы.
Итак, принципиальные отличия ТЭКД от РМВОК в следующем:
- ТЭКД есть следующий в развитии этап СМД Щедровицкого, этап упрощения и обогащения;
- ТЭКД опирается на Законы (повышения идеальности, согласованности, динамичности), закон Кооперации Т.Акбашева;
- в ТЭКД «склеены» процесс производства продуктов и процесс освоения технологии, потому она осваивается легче и не требует документального сопровождения;
- эффективность ТЭКД проверена от дошкольников в ДОУ, до Творческого съезда Союза Учителей (1992), от ученых-снобов до заводчан и предпринимателей.
А если необходимо, то документы = стандарты могут быть разработаны на основе использования ТЭКД в практике. Таким образом с помощью ТЭКД соединяются жесткость технологического подхода и свобода и уникальность организации (и человека).
|
|---|
Рейтинг 227 | Описанная Вами ТЭКД во многом пересекается с современными технологиями управления проектами. Вот описание весьма интересного источника в этой области: http://ru.wikipedia.org/wiki/PMBOK
|
|---|
Рейтинг 790 | Коллеги!
Раз заговориле о коллективной работе, то вот эта заметка будет интересной, а особенно комментарии к ней
Заметка
Комментарий
---
Остаюсь при своих — любые стандарты только для любых стандартных процессов и взаимодействующих в них стандартных сущностей, можно сказать «роботов».
Это только мое субъективное мнение. Другого (т.е. объективного) и быть не может.
Есть ли стандарт для перевода субъектиного в объективное?
Дайте почитать
:-)
|
|---|
Рейтинг 901 | Олег,
погуглите и почитайте:
- лингвистика текста
- когнитивная лингвистика
- трансформационная грамматика + завязанные на них лингвистические философии (Лакан, Хабермас, Витгенштейн, а также аналитическая философия)
|
|---|
|
Всего 2 цитаты из темы форума и её обсуждения;
2 цитаты отмечены метками: Михаил Протасов
06.02.2011, 11:18
Частые неожиданности такие:
1. Понимание, что некоторая задача была изначально поставлена не очень корректно. Что была ошибка в мышлении, которая, тем не менее, хорошо закрепилась в голове. Например, поставлена задача — разработать некоторый курс. Создана проектная группа, налажено взаимодействие между ее членами, собраны материалы, уже разработана структура курса и вовсю идет оформление. Но только на этом этапе становится понятно, что курс вообще не поможет решить имеющиеся проблемы в бизнесе. Что нужно, по-хорошему, провести ряд организационных изменений, а курс если и делать — то совсем на другую тему.  | Михаил Протасов
06.02.2011, 11:18 Михаил Протасов, 6 февраля 2011 г. в 11:18
Скажу несколько в общем, не особо конкретизируя.
Частые неожиданности такие:
1. Понимание, что некоторая задача была изначально поставлена не очень корректно. Что была ошибка в мышлении, которая, тем не менее, хорошо закрепилась в голове. Например, поставлена задача — разработать некоторый курс. Создана проектная группа, налажено взаимодействие между ее членами, собраны материалы, уже разработана структура курса и вовсю идет оформление. Но только на этом этапе становится понятно, что курс вообще не поможет решить имеющиеся проблемы в бизнесе. Что нужно, по-хорошему, провести ряд организационных изменений, а курс если и делать — то совсем на другую тему.
Избежать такой ошибки можно было бы, уделив больше внимания анализу ситуации на раннем этапе проекта.
2. Отсутствие согласованности в ожиданиях заказчика и исполнителя. Когда исполнитель делает одно, а закачик от него ждет другого, и это выясняется только на стадии приемки результатов работы.
Чтобы избежать этого, на мой взгляд, нужен целый комплекс мер.
1) Нужно хорошо понимать бизнес-задачи и цели заказчика. Не только те, которые включаются в данный проект, но и вышестоящие, и смежные.
2) Понимать бизнес-задачи и цели других заинтересованных сторон.
3) Нужно аккуратно согласовывать ожидания и выявлять скрытые требования, даже если заказчик сам о них не говорит явно.
4) Желательно, сдавать работу поэтапно, а также использовать пилоты.
В целом все это, на мой взгляд, относится не столько к e-learning, сколько к управлению проектами |
|
: el-info (at) e-learning by