Необходимый и достаточный набор ролей в команде СДО

[Alexey Kalmykov]

Коллеги, по просьбе хозяйки данного форума инициирую тему (см. subj). Предлагаю подойти к этому вопросу как к кейсу и последовательно обсудить следующие вопросы:
1) Какие действия (групп действий), какие функции должны осуществляться командой по внедрению и поддержанию СДО?
2) Какие из этих действий целесообразно выполнять внутри компании, а что - внешними исполнителями (и в зависимости от каких факторов происходит такое распределение)
3) Как кризис влияет на ответы на вопросы 1 и 2?

Конечно, должна быть некоторая интрига - в данном случае она заключается в том, что для себя (и для конкретной ситуации) я ответ сформулировал, подойдя к данному вопросу через призму ролей в команде СДО (понимаемой широко, как всех активных участников процесса - но, пожалуй, не расширяя до всех stakeholder'ов). У меня получилось около 12 ролей, которые вообще говоря, хорошо коррелируются с набором компетенций. Понятно, что скорее всего эти роли будут исполняться гораздо меньшим количеством людей (в пределе - одним :)).
Я готов поделиться этими своими прикидками - но сначала очень хочется услышать мнение и других практиков, особенно "изнутри" компаний использующих СДО.

[Alexey Kalmykov]

Да, говоря о "кейсе", я имел в виду, что за отправную точку можно взять некую "типичную" компанию, использующую СДО, а разнообразные частности конкретных ситуаций рассматривать как факторы, изменяющие (возможно) набор и распределение ролей.
Типичной компанией, в которой применение СДО является не блажью, а объективной необходимостью бизнеса, в российских условиях, на мой взгляд, является:
- компания, успех бизнеса которой напрямую связан с операционной деятельностью сотрудников
- деятельность значительной части сотрудников, напрямую влияющих на доходы компании, достаточно унифицирована
- географический масштаб и количество сотрудников компании достаточно велико - как минимум филиалы в регионах, аудитория для обучения от 1000 человек

[Наумов Владимир]

Простите, нельзя ли уточнить, что разумеется под ролью в команде СДО?
Поскольку под нею отчего-то хочется понимать такой список позиций:
Инициатор
Скептик
Энтузиаст
Исполнитель
Эксперт и т.п
Вы подобные роли имели в виду?

Было бы интересно (если не прорывом) увязать подобные роли с компетенциями / функциями всех участинков команды СДО. Еще интереснее - совместить их в наименьшем количестве голов (людей) - вплоть до одной (одного).

[Alexey Kalmykov]

Владимир, несомненно, совместную деятельность группы людей (или команды - только давайте возможную дискуссию о разнице между группой и командой вынесем за рамки _данного_ обсуждения) можно рассмотреть с разных сторон и в свете разных теорий. Можно выделить роли в команде по Белбину, или по Хэнди (MTRi), или по Маргерисону и Маккэну, или по Томасу. Можно углубиться в типологии личности и то как это влияет на групповой процесс (Юнг, соционики, теория DISC и т.п.). Но все это - вопросы общего менеджмента.

Я предлагаю скорее исходить более сфокусированно - из практики управления проектами (и в необходимой мере - теорий из этой же области), а где-то - еще более узко - из управления IT проектами. Ни в PMBoKe, ни в RUP, ни в Microsoft Solution Framework (MSF) не даются абсолютно четкие определение термина "роли", они скорее качественные. Например, в RUP - "Роль – область функциональных обязанностей компетенции и ответственности, которые должен иметь человек или группа людей".
Например, по RUP типичные роли - менеджер проекта, аналитик, архитектор, разработчик, тестировщик (каждая из ролей может быть разложена еще на несколько). Это не должности, и не одна функция - но именно сгруппированные в одной роли задачи, компетенции, специфические инструменты и т.п.
В MSF - нечто весьма похожее.

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

[Alexey Kalmykov]

Кстати, как мне кажется, реализация довольно масштабных проектов корпоративных СДО силами 1-2-3 человек - обычная практика. Явно здесь есть функциональная и ролевая перегрузка. Составив матрицу "функция-роль", можно было бы эту перегрузку увидеть наглядно. А потом уже с учетом всех факторов, включая пресловутый кризис - говорить о количестве людей, о должностях, о структуре управления проектом СДО.

[Alexey Kalmykov]

С другой стороны, если есть успешные проекты, реализованные 1-2-3 людьми (и никто из них от истощения не умер) - то перегрузка приемлема?

[Наумов Владимир]

Алексей, на самом деле "мой" список "социопсихологических" ролей в одной голове - условие креатива. Этакая одна команда в одной голове. Иногда проектная :). Но это лирика.

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

[Alexey Kalmykov]

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

[Elena Lokteva]

Алексей, попробую представить свою картину мира. Не ту, которая есть на самом деле, а ту, которая должна быть, на мой взгляд, то есть помечтаю :) При этом сразу оговорюсь: буду мечтать с точки зрения руководителя корпоративного УЦ, и даже представляю, чем моя картина мира подойдет (и не подойдет) для академической среды. И еще одна оговорка: в попытке ответить на Ваши вопросы буду представлять себе не СДО, и не LMS, нечто более широкое, что назову учебным порталом (далее - УП).

1. На самом деле многое может зависеть от той концепции, которую для себя примет организация. Например, сейчас я вовсю сражаюсь против концепции ДО, при которой обучаемый получает один большой документ, после которого сдает один большой тест. Для такой концепции достаточно 2 сотрудников:
- того, кто собирает документы, оформляет в соответствии с неким принятым в организации стандартом (а то и просто проверяет, что сам автор это уже сделал), публикует и распределяет доступ (назовем его публикатор),
- и того, кто занимается техподдержкой (назовем его сисадмин).
Ни о каких особых компетенциях здесь речь не идет: знание Word и пары-тройки функций публикаций. Я даже думаю, что на самом деле команды из 1-2-3 потому и имеют место, что руководство свято верит, что внедрение СДО сводится к этому формату.
А вот если подходить к вопросу более вдумчиво, то мне кажется, что потребуются следующие специалисты:
а) сисадмин-технарь - отвечает за то, чтобы все работало :)
б) методист - тот, кто формирует учебные планы, учебные программы, учебные группы (не только группы ДО!), расписание занятий (не только дистанционных!), отслеживает преподавательскую нагрузку;
в) организатор - тот, кто контролирует состояние учебных ресурсов (ТСО, аудиторный фонд, библиотека и т.п.);
формирует команду преподавателей, контролирует их работу; организовывает информационную поддержку учебного процесса;
г) преподаватели - те, кто сопровожают учебный процесс, готовят материалы, консультируют, проводят занятия, проверяют работы, направляют слушателей и т. п.;
д) разработчики - те, кто разрабатывают/дорабатывают/перерабатывают электронные учебные материалы для публикации на УП; состав команды разработчиков может быть разным, но минимальное количество, на мой взгляд, таково: педдизайнер, графический дизайнер, программист и руководитель проекта разработки, итого 4 человека; если сюда добавлять видео и озвучку, а также серьезно относиться к стилистике и грамматике, то может понадобиться еще 2 человека;
е) контент-менеджер - тот, кто отвечает за информационное наполнение УП; УП - ресурс, который поддерживает обучение; следователь, за ним надо следить, его надо развивать, надо продумывать мероприятия, которые помогут сделать его популярным, востребованным, актуальным, живым; причем, замечу, это не означает, что этот человек сам пишет контент;
ж) руководитель проекта внедрения - собственно, тот человек, который управляет всем проектом и всеми, кто на нем работает.

Итого у меня получилась сборная от 10 до 14 человек. Которая на самом деле может разрастаться. Например, если через учебный портал реализуется несколько больших программ, то на каждой такой программе может быть свой методист и свой руководитель.

2. Какие из этих ролей могут быть внутренними и какие внешними, надо решать в каждой конкретной ситуации. Преподаватели и разработчики могут быть и внутренними, и внешними (от многих факторов зависит). Руководители программ - тоже могут быть и свои, и приглашенные. Но лучше, конечно, чтоб были свои. :)

3. Кризис, полагаю, тут ни при чем. Все зависит от руководителя проекта внедрения :) Если он сможет объяснить целесообразность наличия такой команды внедрения, то сможет ее собрать. Если нет, значит, еще не сам до конца понял, почему ему нужна именно такая команда. Это уже не мечты, а собственный опыт. Я вот не смогла объяснить, и пока работаю в 1,5 человека. :) Работаю над этим :)

[Наумов Владимир]

Елена, а фигура вроде педагогического дизайнера Вами не предксмотрена? Или я ее не сумел разглядеть?

[Elena Lokteva]

Не сумели :) Пункт 1д :)

[Alexey Kalmykov]

Елена, большое спасибо за обстоятельный ответ! Постараюсь на многие мысли из него дать свой отклик, но чуть позже (цейтнот :( )
По одной мысли устоять не могу - относительно того, что "идеальная команда" (а у нас с вами близкие параметры получились - 12-14 человек, причем я у Вас увидел то, о чем забыл, и с другой стороны - у меня есть некоторые другие роли) - не собирается исключительно из-за того, что руководитель внедрения не смог это "пробить".
Субъективный фактор, конечно, важен - но все же, может наше видение "идеала" слишком уж расходится с реальными возможностями или потребностями наших заказчиков?

[Elena Lokteva]

Алексей, буду с нетерпением ждать и Вашего отклика, и Вашей версии сборной внедренцев :)
Что касается возможностей и потребностей заказчика. Если заказчик только созрел до мысли, что ему нужен такой ресурс, как СДО/LMS/УП, то надо помочь ему понять, действительно ли он ему нужен и какой. На этом этапе должен появиться человек (или команда), который поможет правильно определить потребности и возможности и подобрать под них адекватное решение. И сразу сказать, что для реализации такого решения нужно будет столько-то времени/людей/денег. После чего официально принять решение, начать проект, под который выделить средства, найти людей и т.д.
Проблема в том, что у нас обычно так не делается. Несколько раз сталкивалась с примерами, когда ПО куплено по велению души (или потому что надо закрыть какие-то дырки и что-то подсунуть руководству), но нет четкого понимания, кто им будет заниматься, для чего оно куплено, что с ним надо делать, какой результат хотим получить и как можно понять, что мы его получили. В результате имеем дорогущий набор инструментов Bosch, из которого используем только молоток, и только для чесания спины, и даже иногда думаем, что на самом деле массажер и купили. :)