При любом подходе придется потратить время на планирование, оценку трудозатрат, декомпозицию задач и прочее. В приведенном примере - эти затраты всего 15%, и кажется, что есть потенциал, улучшить этот показатель. Не так плохо. Если применяемый подход, по сравнению с остальными дает от 10% к приросту эффективности, тоже вроде здорово. Ответ на последний вопрос представляется очевидным: «да, стоило». А если «нет», то какая альтернатива?
Интересный взгляд. Никогда не смотрел на выученные уроки под таким углом. Как управлять выборами которые я делаю понятно. Как управлять выборами которая делает команда, кажется, что понятно. Но как управлять выборами которые делают стейкхолдеры и контрагенты?
Не смог припомнить ни одного примера когда одно и то же решение на схожих или типовых проектах приводило бы к противоположным результатам. Возможно я плохо старался. Кажется, что митапы, тренинги, база знаний и коллективный разбор кейсов - это более верхнеуровневый процесс, который направлен на то, чтобы привести уровень подготовки сотрудников с разной квалификацией, опытом и специализацией к единому стандарту компании. Если на типовых проектах один специалист выдает блестящий результат превосходящий все ожидания, а другой просто присутствует для фона - это может нанести компании некоторый репутационный ущерб.
Очень понравился пример про диагностику из пункта 6.
Если сбои происходят постоянно и непрерывно на всех проектах, то скорее всего не отлажены бизнес-процессы и нужно разбираться в причинах обуславливающих эти сбои. В случае если причиной сбоев являются систематические не верно принимаемые решения конкретного сотрудника, нужно, наверное, задуматься о целесообразности продолжения сотрудничества с ним. В документы я предлагаю вносить информацию согласно описанной в статье методике.
Не согласен с мнением, что формальное изменение бизнес-процессов это часть практики "выученные уроки". Это не входит в задачи для роли руководитель проектов. Внесение изменений в бизнес-процессы - это прерогатива владельца бизнес-процесса. Как, впрочем, и мониторинг результатов, которые приносят эти изменения.
Процесс документирования не приносит быстрого результата в краткосрочной перспективе, и по этому не хочется тратить на это время. Но когда начинаются разборы полетов, документы, метрики и конкретные цифры (в очках, голах, секундах) - это отличные козыри в диалоге. Время потраченное на документирование - это, как правило, долгосрочная инвестиция.
Первоначальный вариант статьи был регидрирован и сух. Прежде чем публиковать статью, я попросил ознакомиться с ней нескольких моих друзей. Среди негативных отзывов были строго противоположные тем, что озвучены выше в комментариях. В частности, недовольство вызвало: недостаточное раскрытие некоторых терминов, стиль изложения материала "как будто робот писал", наличие непонятных моментов, требующих пояснения и так далее. Пришел к выводу, что всем не угодишь. Опубликовал менее душный вариант.
При любом подходе придется потратить время на планирование, оценку трудозатрат, декомпозицию задач и прочее. В приведенном примере - эти затраты всего 15%, и кажется, что есть потенциал, улучшить этот показатель. Не так плохо. Если применяемый подход, по сравнению с остальными дает от 10% к приросту эффективности, тоже вроде здорово. Ответ на последний вопрос представляется очевидным: «да, стоило». А если «нет», то какая альтернатива?
Интересный взгляд. Никогда не смотрел на выученные уроки под таким углом. Как управлять выборами которые я делаю понятно. Как управлять выборами которая делает команда, кажется, что понятно. Но как управлять выборами которые делают стейкхолдеры и контрагенты?
Не смог припомнить ни одного примера когда одно и то же решение на схожих или типовых проектах приводило бы к противоположным результатам. Возможно я плохо старался. Кажется, что митапы, тренинги, база знаний и коллективный разбор кейсов - это более верхнеуровневый процесс, который направлен на то, чтобы привести уровень подготовки сотрудников с разной квалификацией, опытом и специализацией к единому стандарту компании. Если на типовых проектах один специалист выдает блестящий результат превосходящий все ожидания, а другой просто присутствует для фона - это может нанести компании некоторый репутационный ущерб.
Очень понравился пример про диагностику из пункта 6.
Если сбои происходят постоянно и непрерывно на всех проектах, то скорее всего не отлажены бизнес-процессы и нужно разбираться в причинах обуславливающих эти сбои. В случае если причиной сбоев являются систематические не верно принимаемые решения конкретного сотрудника, нужно, наверное, задуматься о целесообразности продолжения сотрудничества с ним. В документы я предлагаю вносить информацию согласно описанной в статье методике.
Не согласен с мнением, что формальное изменение бизнес-процессов это часть практики "выученные уроки". Это не входит в задачи для роли руководитель проектов. Внесение изменений в бизнес-процессы - это прерогатива владельца бизнес-процесса. Как, впрочем, и мониторинг результатов, которые приносят эти изменения.
Процесс документирования не приносит быстрого результата в краткосрочной перспективе, и по этому не хочется тратить на это время. Но когда начинаются разборы полетов, документы, метрики и конкретные цифры (в очках, голах, секундах) - это отличные козыри в диалоге. Время потраченное на документирование - это, как правило, долгосрочная инвестиция.
Первоначальный вариант статьи был регидрирован и сух. Прежде чем публиковать статью, я попросил ознакомиться с ней нескольких моих друзей. Среди негативных отзывов были строго противоположные тем, что озвучены выше в комментариях. В частности, недовольство вызвало: недостаточное раскрытие некоторых терминов, стиль изложения материала "как будто робот писал", наличие непонятных моментов, требующих пояснения и так далее. Пришел к выводу, что всем не угодишь. Опубликовал менее душный вариант.