В том то и дело, что один преподаватель не может дать завершенную компетенцию. Для освоения компетенцией требуется комплекс дисциплин (причем перечень дисциплин этого комплекса не обязательно фиксированный), проверка результатов изучения которых объеденена в одном испытании.
Не увидел метрик по которым можно было бы оценить качество управления проектом. Когда Титаник столкнулся с айсбергом, все метрики говорили об отличной работе всех подсистем. Можете что-нибудь предложить для измерения качества работы руководителя проекта?
Полностью согласен. Просто в статье отражен личный опыт. Однако общение с коллегами, и не только в нашей стране, показало, что все эти проблемы возникают на крупных проектах с большим количеством стекхолдеров.
На облачной 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, если исполнитель покажет заказчику, что его желания могут быть реализованы путем выполнения определенного перечня работ, каждая из которых оценивается в нормо-часах специалиста, у заказчика появляется возможность выбора - какие работы он может выполнить за свои деньги, а какие оставить на потом. Это основание для начала нормального диалога. Когда Вы приходите к автомобильному дилеру с желанием отремонтировать свой автомобиль и он формирует перечень работ, общую цену и планируемые сроки, если у Вас не хватает денег или времени, Вы же не оспариваете стоимость отдельных работ - вы выбираете из списка наиболее приоритетные или уходите в другой сервис. Другое дело, если исполнитель любыми путями хочет получить контракт. Это распространенная ситуация - когда контракты заключают одни, а отвечают за их реализацию другие. Вот тогда мы сталкиваемся с ситуацией "впихнуть невпихуемое". И именно тогда нормо-часы превращаются в профанацию. Конечно, ключевой момент здесь в корректности оценки отдельных работ. Для снижения неопределенности при оценке трудоемкости я стараюсь конечную стоимость согласовывать с заказчиком после формирования проектных решений (подробно описал как их формируют на моих проектах здесь) и при создании WBS, по необходимости, использую калькуляторы оценки трудоемкости задач, которые в свою очередь являются площадкой для диалога между РП/аналитиком планирующим задачи и непосредственным исполнителем.
Конечно, я хотел бы чтобы мои сотрудники стремились к совершенству. Однако с моей точки зрения - это стремление должно быть подкреплено результатами, которые можно выразить количественно. Попробую пояснить на примере. С одной стороны, можно охарактеризовать школьника, что он очень талантлив, скажем, в математике, долго ходил на факультатив и несколько лет занимался с лучшими учителями. Но, с другой - на мой взгляд, гораздо представительней будет, если сказать, что он, например, самостоятельно решил XX задач из конкретного раздела конкретного учебника, занял Х в олимпиаде X уровня и т.п. Да действительно - все сотрудники разные. Однако, на мой взгляд, квалификация так или иначе всегда проявляется количественно. Один лучше подтягивается, другой быстрее бегает. То и другое можно измерить. Как сложить эти показатели - это отдельная тема для разговора. Как вариант. В отношении уникальности: на своих проектах я стремлюсь к снижению уникальности решений через унификацию и нормирование работ аналитика. Об этом я подробно рассказывал в одной из своих предыдущих статей. Обратите внимание на калькулятор для оценки трудоемкости этих работ при планировании. При этом унификация - это не ограничение для творчества. Это инструмент оценки и задания уровня. Квалификационные сетки в спорте не отменяют рекордов. Если на проекте рождается что-то эксклюзивное - это повод добавить этот эксклюзив в резюме отдельной строкой. В шаблонах резюме нельзя зафиксировать требование на озарения и инсайты, но это не отменяет их на проекте.
Спасибо за замечание в отношении подготовки бакалавров для ядерной промышленности. Уточнил текст статьи.
И где Вы в статье увидели такой тезис? Не стоит назначать автору статьи того, о чем в статье нет ни слова.
Проверке знаний-умений-навыков во время обучения.
Было бы здорово, если бы Вы поделились опытом о том каким образом организована проверка знаний студентов в Испании. Спасибо.
В том то и дело, что один преподаватель не может дать завершенную компетенцию. Для освоения компетенцией требуется комплекс дисциплин (причем перечень дисциплин этого комплекса не обязательно фиксированный), проверка результатов изучения которых объеденена в одном испытании.
Не увидел метрик по которым можно было бы оценить качество управления проектом. Когда Титаник столкнулся с айсбергом, все метрики говорили об отличной работе всех подсистем. Можете что-нибудь предложить для измерения качества работы руководителя проекта?
Полностью согласен. Просто в статье отражен личный опыт. Однако общение с коллегами, и не только в нашей стране, показало, что все эти проблемы возникают на крупных проектах с большим количеством стекхолдеров.
На облачной 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%. В случае возникновения конфликтов - в расстановку приоритетов включается РП.
Все стадии подробно описаны в статье https://habr.com/ru/company/lanit/blog/486754/ . Стадии анализа подробно детализированы в статье https://habr.com/ru/company/lanit/blog/515452/
Кодревью формируется как подзадача к задаче типа разработка и выполняется после того как аналитик примет доработанный функционал (перед заливкой ветки разработки в develop - https://habr.com/ru/company/lanit/blog/515452/ ). Если нужны дополнительные уточнения - пишите - попробую ответить.
Как правило, в кошельке заказчика ограниченный бюджет, а в голове - желание решить все проблемы за эти деньги. Однако, IMHO, если исполнитель покажет заказчику, что его желания могут быть реализованы путем выполнения определенного перечня работ, каждая из которых оценивается в нормо-часах специалиста, у заказчика появляется возможность выбора - какие работы он может выполнить за свои деньги, а какие оставить на потом. Это основание для начала нормального диалога.
Когда Вы приходите к автомобильному дилеру с желанием отремонтировать свой автомобиль и он формирует перечень работ, общую цену и планируемые сроки, если у Вас не хватает денег или времени, Вы же не оспариваете стоимость отдельных работ - вы выбираете из списка наиболее приоритетные или уходите в другой сервис.
Другое дело, если исполнитель любыми путями хочет получить контракт. Это распространенная ситуация - когда контракты заключают одни, а отвечают за их реализацию другие. Вот тогда мы сталкиваемся с ситуацией "впихнуть невпихуемое". И именно тогда нормо-часы превращаются в профанацию.
Конечно, ключевой момент здесь в корректности оценки отдельных работ. Для снижения неопределенности при оценке трудоемкости я стараюсь конечную стоимость согласовывать с заказчиком после формирования проектных решений (подробно описал как их формируют на моих проектах здесь) и при создании WBS, по необходимости, использую калькуляторы оценки трудоемкости задач, которые в свою очередь являются площадкой для диалога между РП/аналитиком планирующим задачи и непосредственным исполнителем.
Конечно, я хотел бы чтобы мои сотрудники стремились к совершенству. Однако с моей точки зрения - это стремление должно быть подкреплено результатами, которые можно выразить количественно. Попробую пояснить на примере. С одной стороны, можно охарактеризовать школьника, что он очень талантлив, скажем, в математике, долго ходил на факультатив и несколько лет занимался с лучшими учителями. Но, с другой - на мой взгляд, гораздо представительней будет, если сказать, что он, например, самостоятельно решил XX задач из конкретного раздела конкретного учебника, занял Х в олимпиаде X уровня и т.п. Да действительно - все сотрудники разные. Однако, на мой взгляд, квалификация так или иначе всегда проявляется количественно. Один лучше подтягивается, другой быстрее бегает. То и другое можно измерить. Как сложить эти показатели - это отдельная тема для разговора. Как вариант.
В отношении уникальности: на своих проектах я стремлюсь к снижению уникальности решений через унификацию и нормирование работ аналитика. Об этом я подробно рассказывал в одной из своих предыдущих статей. Обратите внимание на калькулятор для оценки трудоемкости этих работ при планировании. При этом унификация - это не ограничение для творчества. Это инструмент оценки и задания уровня. Квалификационные сетки в спорте не отменяют рекордов. Если на проекте рождается что-то эксклюзивное - это повод добавить этот эксклюзив в резюме отдельной строкой. В шаблонах резюме нельзя зафиксировать требование на озарения и инсайты, но это не отменяет их на проекте.