Вы неправильно перевели мой ник, хотя, как я заметил, именно так его переводят многие. Мне не платят за подготовку стажеров, как и за написание статей. И то и другое - личная инициатива. IMHO - зачастую неправильные исходные допущения ведут к неправильным выводам.
Не обязательно один курс. Если у посещаемость группы у конкретного преподавателя стабильно на 20% ниже, чем на других предметах этой же группы, Вам не кажется что это повод задуматься о причинах такой посещаемости? Что касается дистанционки - я не предлагал универсальные решения для всех случаев жизни. Я просто поделился несколькими возможными подходами. При этом надо помнить о том, что отлично зарекомендовало себя в условиях Сахары может быть абсолютно неприемлемым в условиях Антарктики. Так что у Вы ничем не ограничены для модификации и дополнения этих подходов в интересах улучшения качества образования в различных условиях.
Смотря как сформулировны KPI. У нас в проектной группе как то раз разгорелся спор о применимости KPI. Критика заметно поутихла, когда я предложил "запросто" улучшить такой показатель как среднее время устранения инцидентов (время ожидания ответов от заказчиков не учитывалось). Некоторые апробировнные варианты, которые положительно себя зарекомендовали для формальной оценки качества работы преподавателя:
статистический анализ результатов проверки заданий (ссылка в статье);
анализ плотности опроса студентов на занятиях;
анализ закономерностей распределения выставляемых оценок;
анализ посещаемости студентами занятий конкретных преподавателей;
сбор и взвешенный анализ отзывов от студентов о качестве проведения занятий, в т.ч. оценка доли выбора студентами занятий конкретного преподавателя (любовь студентов завоевать не так просто как кажется - не путать с лояльностью);
и главное - статистика успешности прохождения испытаний, которые отвечают описанным в статье требованиям.
В том то и дело, что один преподаватель не может дать завершенную компетенцию. Для освоения компетенцией требуется комплекс дисциплин (причем перечень дисциплин этого комплекса не обязательно фиксированный), проверка результатов изучения которых объеденена в одном испытании.
Не увидел метрик по которым можно было бы оценить качество управления проектом. Когда Титаник столкнулся с айсбергом, все метрики говорили об отличной работе всех подсистем. Можете что-нибудь предложить для измерения качества работы руководителя проекта?
Полностью согласен. Просто в статье отражен личный опыт. Однако общение с коллегами, и не только в нашей стране, показало, что все эти проблемы возникают на крупных проектах с большим количеством стекхолдеров.
На облачной JIRA можно делать свои плагины. Как это делать описано на сайте Atlasian. Другое дело, для того чтобы такой плагин выставить на маркетплейс для всеобщего использования, надо вложить в 10 раз больше усилий, чем чтобы этот плагин написать. Мы пользуемся серверной JIRA в базовой версии и я не пишу плагины. Я просто пишу свои нехитрые инструменты для оперативного управления проектом, которые подключаются напрямую к БД JIRA. Описание БД JIRA тоже можно найти на сайте Atlasian.
Два года назад, когда я писал эту статью по этой схеме перешла работать одна проектная группа. Сегодня по этой схеме работает уже шесть проектных групп. За это время в рамках этого подхода родилось еще несколько дополнительных дашбордов позволяющих: - оценить текущую степень выполнения пула задач по реализации выбранного пула требований (с учетом неопределенности их выполнения); - планировать работы с учетом привлечения сотрудников на нескольких проектах с превентивным отображением рисков срыва задач по 5 различным критериям; - формировать план работ по выбранному пулу требований с расчетом трудоемкости и стоимости этих работ (с учетом тарифных ставок); - формировать аналитический отчет по выполненным работам по отдельному сотруднику с учетом финансовой эффективности (в т.ч. позволяющий оценить насколько сотрудник соответствует занимаемой должности). Надеюсь найти время, чтобы рассказать об этих наработках в ближайших статьях.
Как спасли - читайте первоисточник. Ссылку я дал в комментарии. Подробности - в следующей статье (это была выдержка из нее, можете расценивать как анонс).
Прошу прощения, видимо я неправильно интерпретировал Ваш комментарий в части "национальных особенностей" менеджмента. Но, замечу, здесь не о критике той или иной методологии. Я пытался обсудить вопрос применимости методологий в зависимости от условий.
Не соглашусь в части "национальных особенностей". Джефф Сазерленд в своей знаменитой книге связывает рождение методологии Scrum с проектом по разработке аналитической системы «Страж» (Sentinel), выполняемым компанией Lockheed Martin по заказу ФБР. Джефф пришел на проект, когда дата завершения была просрочена на 1 год. Из выделенных из бюджета США 451 000 000$ было потрачено почти 90% . Было реализовано только около половины требований. По оценке тамошних экспертов на завершение проекта требовалось еще 350 000 000$ и десять лет работы. При этом, необходимость разработки системы «Страж» было продиктовано провалом проектов ФБР по созданию систем «Автоматизированная поддержка следственных дел» (Automated Case Support, ACS) и «Виртуальные следственные дела» (Virtual Case File, VCF) работа над которыми, стоимостью 170 000 000$, длилась без малого тринадцать лет. Вам эта ситуация ничего не напоминает? Конечно, даже ребенку понятно, что поскольку это случилось в США, а не в России, эти неприятности были вызваны тем, что люди просто не знали как правильно работать. Так в книжке и написано. Ни о какой махровой коррупции речь не идет (чур меня, чур). Джефф всех научил. Scrum всех спас.
Свои гипотезы в отношении данного вопроса я отразил в разделе "Предпосылки к депрессии". Если в отношении Вас эти гипотезы не подтверждаются - я за вас рад - не будите лихо. Если у Вас другие причины или Вы не согласны - пишите в комментариях или в опросе.
Когда - решает исполнитель. А вот к какому сроку - аналитик (при необходимости согласовывает с РП). Аналитик планирует и регистрирует в JIRA всю цепочку задач по реализации требования, определяет плановую трудоемкость, затем согласовывает сроки в зависимости от загрузки привлекаемых исполнителей. После этого задачи передаются в работу. Последовательность выполнения задач определяет определяет ответственный исполнитель. Главное - успеть к сроку.
Именно так - первичную проверку реализованного нового функционала осуществляет аналитик, который отвечает за реализацию требования. Тестировщики отвечают за реализацию регрессионного тестирования (проверку ранее реализованного и принятого функционала). Код-ревью идет после проверки реализации, поскольку, как правило, новый функционал всегда допиливается после проверки аналитиком (не только потому, что ошибки, а и потому, что могут быть незначительно уточнены требования). Повторное тестирование проводится всегда - при выпуске версии для заказчика (тут могут быть привлечены и тестировщики).
Все идет от требований. Вся система разбита на подсистемы, на каждую подсистему назначен ответственный аналитик. В зависимости от того к какой подсистеме относится входящее требование, ответственный аналитик берет на себя руководство реализацией требования и отвечает за его реализацию вплоть до сдачи заказчику. Аналитик в числе прочего отвечает за своевременное назначение задач на разработчика и контроль своевременности выполнения. В случае назначения нескольких задач на разработчика он сам определяет какую задачу он будет делать сегодня. Последовательность выполнения выбирает сам исполнитель. Однако, на проекте согласованы наиболее общие правила определения приоритета задач. Каждый сотрудник знает что инциденты надо решать в первую очередь, но при наличии других задач нельзя тратить на них более 50% рабочего времени (если не было других указаний). Задача которая выполняется в интересах нескольких требований имеет приоритет над задачей в интересах меньшего числа требований. Кроме того, сделан еще один дашборд который позволяет осуществлять балансировку задач сотрудника в зависимости от требуемых сроков, изменения приоритетов задач и привлечения разработчиков для выполнения задач в интересах разных аналитиков/проектов (планирую подробно описать этот дашборд в одной из следующих статей - честно говоря хочется попробовать сделать плагин для JIRA, а потом писать статью). С помощью этого дашборда так же осуществляется контроль того, чтобы сотрудник не был загружен задачами более чем на 80%. В случае возникновения конфликтов - в расстановку приоритетов включается РП.
Вы неправильно перевели мой ник, хотя, как я заметил, именно так его переводят многие. Мне не платят за подготовку стажеров, как и за написание статей. И то и другое - личная инициатива. IMHO - зачастую неправильные исходные допущения ведут к неправильным выводам.
Не обязательно один курс. Если у посещаемость группы у конкретного преподавателя стабильно на 20% ниже, чем на других предметах этой же группы, Вам не кажется что это повод задуматься о причинах такой посещаемости? Что касается дистанционки - я не предлагал универсальные решения для всех случаев жизни. Я просто поделился несколькими возможными подходами. При этом надо помнить о том, что отлично зарекомендовало себя в условиях Сахары может быть абсолютно неприемлемым в условиях Антарктики. Так что у Вы ничем не ограничены для модификации и дополнения этих подходов в интересах улучшения качества образования в различных условиях.
Смотря как сформулировны KPI. У нас в проектной группе как то раз разгорелся спор о применимости KPI. Критика заметно поутихла, когда я предложил "запросто" улучшить такой показатель как среднее время устранения инцидентов (время ожидания ответов от заказчиков не учитывалось).
Некоторые апробировнные варианты, которые положительно себя зарекомендовали для формальной оценки качества работы преподавателя:
статистический анализ результатов проверки заданий (ссылка в статье);
анализ плотности опроса студентов на занятиях;
анализ закономерностей распределения выставляемых оценок;
анализ посещаемости студентами занятий конкретных преподавателей;
сбор и взвешенный анализ отзывов от студентов о качестве проведения занятий, в т.ч. оценка доли выбора студентами занятий конкретного преподавателя (любовь студентов завоевать не так просто как кажется - не путать с лояльностью);
и главное - статистика успешности прохождения испытаний, которые отвечают описанным в статье требованиям.
Спасибо за замечание в отношении подготовки бакалавров для ядерной промышленности. Уточнил текст статьи.
И где Вы в статье увидели такой тезис? Не стоит назначать автору статьи того, о чем в статье нет ни слова.
Проверке знаний-умений-навыков во время обучения.
Было бы здорово, если бы Вы поделились опытом о том каким образом организована проверка знаний студентов в Испании. Спасибо.
В том то и дело, что один преподаватель не может дать завершенную компетенцию. Для освоения компетенцией требуется комплекс дисциплин (причем перечень дисциплин этого комплекса не обязательно фиксированный), проверка результатов изучения которых объеденена в одном испытании.
Не увидел метрик по которым можно было бы оценить качество управления проектом. Когда Титаник столкнулся с айсбергом, все метрики говорили об отличной работе всех подсистем. Можете что-нибудь предложить для измерения качества работы руководителя проекта?
Полностью согласен. Просто в статье отражен личный опыт. Однако общение с коллегами, и не только в нашей стране, показало, что все эти проблемы возникают на крупных проектах с большим количеством стекхолдеров.
На облачной JIRA можно делать свои плагины. Как это делать описано на сайте Atlasian. Другое дело, для того чтобы такой плагин выставить на маркетплейс для всеобщего использования, надо вложить в 10 раз больше усилий, чем чтобы этот плагин написать. Мы пользуемся серверной JIRA в базовой версии и я не пишу плагины. Я просто пишу свои нехитрые инструменты для оперативного управления проектом, которые подключаются напрямую к БД JIRA. Описание БД JIRA тоже можно найти на сайте Atlasian.
Два года назад, когда я писал эту статью по этой схеме перешла работать одна проектная группа. Сегодня по этой схеме работает уже шесть проектных групп. За это время в рамках этого подхода родилось еще несколько дополнительных дашбордов позволяющих:
- оценить текущую степень выполнения пула задач по реализации выбранного пула требований (с учетом неопределенности их выполнения);
- планировать работы с учетом привлечения сотрудников на нескольких проектах с превентивным отображением рисков срыва задач по 5 различным критериям;
- формировать план работ по выбранному пулу требований с расчетом трудоемкости и стоимости этих работ (с учетом тарифных ставок);
- формировать аналитический отчет по выполненным работам по отдельному сотруднику с учетом финансовой эффективности (в т.ч. позволяющий оценить насколько сотрудник соответствует занимаемой должности).
Надеюсь найти время, чтобы рассказать об этих наработках в ближайших статьях.
Как спасли - читайте первоисточник. Ссылку я дал в комментарии. Подробности - в следующей статье (это была выдержка из нее, можете расценивать как анонс).
Прошу прощения, видимо я неправильно интерпретировал Ваш комментарий в части "национальных особенностей" менеджмента. Но, замечу, здесь не о критике той или иной методологии. Я пытался обсудить вопрос применимости методологий в зависимости от условий.
Не соглашусь в части "национальных особенностей". Джефф Сазерленд в своей знаменитой книге связывает рождение методологии Scrum с проектом по разработке аналитической системы «Страж» (Sentinel), выполняемым компанией Lockheed Martin по заказу ФБР. Джефф пришел на проект, когда дата завершения была просрочена на 1 год. Из выделенных из бюджета США 451 000 000$ было потрачено почти 90% . Было реализовано только около половины требований. По оценке тамошних экспертов на завершение проекта требовалось еще 350 000 000$ и десять лет работы. При этом, необходимость разработки системы «Страж» было продиктовано провалом проектов ФБР по созданию систем «Автоматизированная поддержка следственных дел» (Automated Case Support, ACS) и «Виртуальные следственные дела» (Virtual Case File, VCF) работа над которыми, стоимостью 170 000 000$, длилась без малого тринадцать лет. Вам эта ситуация ничего не напоминает? Конечно, даже ребенку понятно, что поскольку это случилось в США, а не в России, эти неприятности были вызваны тем, что люди просто не знали как правильно работать. Так в книжке и написано. Ни о какой махровой коррупции речь не идет (чур меня, чур). Джефф всех научил. Scrum всех спас.
Альтернативный вариант на русском языке: профессиональный стандарт "Системный администратор информационно-коммуникационных систем". Вариант апробирован как неплохое обоснование должностных обязанностей для вышестоящих менеджеров.
Свои гипотезы в отношении данного вопроса я отразил в разделе "Предпосылки к депрессии". Если в отношении Вас эти гипотезы не подтверждаются - я за вас рад - не будите лихо. Если у Вас другие причины или Вы не согласны - пишите в комментариях или в опросе.
Когда - решает исполнитель. А вот к какому сроку - аналитик (при необходимости согласовывает с РП). Аналитик планирует и регистрирует в JIRA всю цепочку задач по реализации требования, определяет плановую трудоемкость, затем согласовывает сроки в зависимости от загрузки привлекаемых исполнителей. После этого задачи передаются в работу. Последовательность выполнения задач определяет определяет ответственный исполнитель. Главное - успеть к сроку.
Именно так - первичную проверку реализованного нового функционала осуществляет аналитик, который отвечает за реализацию требования. Тестировщики отвечают за реализацию регрессионного тестирования (проверку ранее реализованного и принятого функционала). Код-ревью идет после проверки реализации, поскольку, как правило, новый функционал всегда допиливается после проверки аналитиком (не только потому, что ошибки, а и потому, что могут быть незначительно уточнены требования). Повторное тестирование проводится всегда - при выпуске версии для заказчика (тут могут быть привлечены и тестировщики).
Все идет от требований. Вся система разбита на подсистемы, на каждую подсистему назначен ответственный аналитик. В зависимости от того к какой подсистеме относится входящее требование, ответственный аналитик берет на себя руководство реализацией требования и отвечает за его реализацию вплоть до сдачи заказчику. Аналитик в числе прочего отвечает за своевременное назначение задач на разработчика и контроль своевременности выполнения. В случае назначения нескольких задач на разработчика он сам определяет какую задачу он будет делать сегодня. Последовательность выполнения выбирает сам исполнитель. Однако, на проекте согласованы наиболее общие правила определения приоритета задач. Каждый сотрудник знает что инциденты надо решать в первую очередь, но при наличии других задач нельзя тратить на них более 50% рабочего времени (если не было других указаний). Задача которая выполняется в интересах нескольких требований имеет приоритет над задачей в интересах меньшего числа требований. Кроме того, сделан еще один дашборд который позволяет осуществлять балансировку задач сотрудника в зависимости от требуемых сроков, изменения приоритетов задач и привлечения разработчиков для выполнения задач в интересах разных аналитиков/проектов (планирую подробно описать этот дашборд в одной из следующих статей - честно говоря хочется попробовать сделать плагин для JIRA, а потом писать статью). С помощью этого дашборда так же осуществляется контроль того, чтобы сотрудник не был загружен задачами более чем на 80%. В случае возникновения конфликтов - в расстановку приоритетов включается РП.