All streams
Search
Write a publication
Pull to refresh
162
0
Александр Савин @aimfirst

Руководитель проекта + ведущий аналитик

Send message

Я бы не стал обобщать отсутствие связей с индустрией на все отрасли. Например, в части подготовки военных кадров такие связи пронизывают всю систему военного образования. Большая часть преподавателей проходила службу в строевых частях, многие имеют реальный боевой опыт. Сама система подготовки предполагает последовательное приобретение новых компетенций в ходе служебного пути. На вышестоящие должости нельзя быть назначенными не пройдя дополнительное очное обучение. Быть направленным на дополнительное обучение нельзя, если ты не докажешь в строевых частях, что ты его достоин. Исключения, конечно, есть везде, но в целом система работает.
Так же могу сказать, что познакомившись с тем, как отстаивали отдельные инженерные специальности в Московском авиационном институте - тоже можно с уверенностью констатировать, что в отдельных случаях образовательные учреждения очень плодотворно и опреративно взаимодействуют с промышленностью.

Вы неправильно перевели мой ник, хотя, как я заметил, именно так его переводят многие. Мне не платят за подготовку стажеров, как и за написание статей. И то и другое - личная инициатива. 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 всю цепочку задач по реализации требования, определяет плановую трудоемкость, затем согласовывает сроки в зависимости от загрузки привлекаемых исполнителей. После этого задачи передаются в работу. Последовательность выполнения задач определяет определяет ответственный исполнитель. Главное - успеть к сроку.

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity

Specialization

Project Manager, Systems Analyst
Lead
Project management
Development management
Organization of business processes
Negotiation
Development of tech specifications
Agile
Jira
Project planning
Building a team
Budgeting projects