Спасибо, исправил ошибку.
Любую компанию делают люди, если кто-то прочитав статью опробует при создании показателя любого процесса (даже не IT-шного), уже будет неплохо. Я чуть раньше этой статьи пробовал рассказать идею коллеге, когда он не мог сформулировать показатели, и она вполне зашла и ступор был убран.
Примеры, для внутреннего ИТ, хотя, на мой взгляд, вполне применимо и для оказания внешних услуг. А вот сама метология декомпозита: цели — показатели — метрики, универсальна.
Если интересно можем обсудить.
Так сами же призываете чтить оригинал. А там нет потребителя.
ITIL же, здесь при том, что статья опирается на понятийный аппарат данного фреймворка ITSM, ну и автор не чужой человек для этого свода практика.
Про риски, согласен, есть два предложения с упоминанием понятия.
Но в статье нет ни слова про потребителя. Есть Заказчик (customer), есть Пользователь (user), но Потребитель (consumer) не упоминается. Более того такого понятия, как потребитель в принципе нет в Глоссарий ITIL.
Спасибо за восторженный отзыв. А чем заказчик отличается от «консьюмера»? И разве обратная связь это не частный случай коммуникации? И нет в этой статье никакого Управления Рисками, только предостережение не брать на себя то, что не сможешь выполнить.
Не нравится мне слово «снабженские», душа протестует. Я бы заменил его на «поддерживающие» или на «эволюционные» процессы, когда задачи не захватить новые для себя позиции, а удержать.
Как основной идеей, да, вы почти правы (есть еще пара моментов, например, про формулировку целевого показателя в SLA), но статья для того и пишется, чтобы убедить читателя в этой идее.
Отлично, для себя Вы решили, что заморачиваться с оценкой рисков по озвученной мною технологии не стоит из-за высокой стоимости ресурсов на это для Вас, и похоже вы ее вынесли в зону «не интересно», план Б сформирован, и, скорее всего, находиться, частично в зоне влияния, а частично и в зоне контроля.
А по поводу наличия, степени продуманности плана Б, В, Г, Д и т.д. и выделения на них ресурсов, возможно, наглядным будет пример, запас прочности у самолетов истребителей не сильно больше 1, а вот в гражданской авиации используется двойное, а иногда и тройное резервирование. Вы в своих проектах летаете на боевом самолете :)
Вы правы. Но совсем отказываться от проактивного (превитивного) резервирования возможностей, думаю, не стоит. Всегда есть риски с серьезными последствиями и к их наступлению желательно быть готовым. Здесь меня нравится подход по работе с рисками из управления проектами, когда сначала составляется реестр рисков, затем оценивается потенциальные последствия и вероятности наступления, и на основе анализа выдается перечень ростков, к которым готовимся, резервируя ресурсы и покачивая возможности. Самое интересное каждые из нас подсознательно так и делает, только границы критериев, что разрешать в превитивного список подсознание может выбирать неадекватно задаче.
Не плохой вариант, спасибо, его гораздо проще объяснять, стоит задуматься.
Но все таки менять не буду, т.к. это не я придумал определение проактивности по Кови: «осознанная реакция на внешние события, исходя из личных ценностей, в противовес импульсивным реакциям на основе чувств, обстоятельств, условий, диктуемых окружающей средой». Мне кажется здесь основная идея заложена в «личностных ценностях», которые заранее определены и продуманы и именно в этом проактивность. Реакция же на основе условий диктуемых обществом тоже может быть рациональной.
Команде, да, говорить, и говорить на общем собрании. Но не озвучивать, что собираются разогнать именно пол команды, сказать, что команда будет распущена, а вот с переводом на другие проекты или с увольнением сейчас сказать сложно, но пока намерения выглядят серьезными.
Такой подход и покажет серьезность ситуации, и даст понимание, что все сейчас зависит от команды.
Если озвучить, что есть решение ополовинить команду, то начнутся перетягивания одеяла и подковерная возня, желательно, как можно дольше избегать этого.
Так же нужно показать команде свою заинтересованность в сохранении команды.
Часть 2 — так ли все безсистемно?
Если сбои ранее были безсистемные, то причина, скорее всего, в самой системе, т.е. в том, как построен процесс. Поэтому нужно искать в себе, а также попросить всех участников предыдущих сбоев еще раз вспомнить все обстоятельства приведшие к ним.
Также слегка повысить степень контроля промежуточных результатов, озвучив это людям, как свою попытку выяснить причину сбоев.
Также стоит еще раз поговорить с заказчиком, выяснив есть ли общие и частные претензии к работе команды, возможно всплывут те вещи, которые косвенно или явно вызывают сбои.
А может лучше один раз объяснить сотруднику, что именно будет пониматься под тем или иным термином, при его оценке. И не так уж важно будет каким словом зовется, главное, что под этим понимается?
Любую компанию делают люди, если кто-то прочитав статью опробует при создании показателя любого процесса (даже не IT-шного), уже будет неплохо. Я чуть раньше этой статьи пробовал рассказать идею коллеге, когда он не мог сформулировать показатели, и она вполне зашла и ступор был убран.
Если интересно можем обсудить.
Читал несколько раз. Судя по Вашей оценке, Гугл бы лучше справился :)
ITIL же, здесь при том, что статья опирается на понятийный аппарат данного фреймворка ITSM, ну и автор не чужой человек для этого свода практика.
Но в статье нет ни слова про потребителя. Есть Заказчик (customer), есть Пользователь (user), но Потребитель (consumer) не упоминается. Более того такого понятия, как потребитель в принципе нет в Глоссарий ITIL.
Они вне ограничений проектного треугольника (результат, ресурсы, срок) пна всю длину проекта.
А по поводу наличия, степени продуманности плана Б, В, Г, Д и т.д. и выделения на них ресурсов, возможно, наглядным будет пример, запас прочности у самолетов истребителей не сильно больше 1, а вот в гражданской авиации используется двойное, а иногда и тройное резервирование. Вы в своих проектах летаете на боевом самолете :)
Но все таки менять не буду, т.к. это не я придумал определение проактивности по Кови: «осознанная реакция на внешние события, исходя из личных ценностей, в противовес импульсивным реакциям на основе чувств, обстоятельств, условий, диктуемых окружающей средой». Мне кажется здесь основная идея заложена в «личностных ценностях», которые заранее определены и продуманы и именно в этом проактивность. Реакция же на основе условий диктуемых обществом тоже может быть рациональной.
Команде, да, говорить, и говорить на общем собрании. Но не озвучивать, что собираются разогнать именно пол команды, сказать, что команда будет распущена, а вот с переводом на другие проекты или с увольнением сейчас сказать сложно, но пока намерения выглядят серьезными.
Такой подход и покажет серьезность ситуации, и даст понимание, что все сейчас зависит от команды.
Если озвучить, что есть решение ополовинить команду, то начнутся перетягивания одеяла и подковерная возня, желательно, как можно дольше избегать этого.
Так же нужно показать команде свою заинтересованность в сохранении команды.
Часть 2 — так ли все безсистемно?
Если сбои ранее были безсистемные, то причина, скорее всего, в самой системе, т.е. в том, как построен процесс. Поэтому нужно искать в себе, а также попросить всех участников предыдущих сбоев еще раз вспомнить все обстоятельства приведшие к ним.
Также слегка повысить степень контроля промежуточных результатов, озвучив это людям, как свою попытку выяснить причину сбоев.
Также стоит еще раз поговорить с заказчиком, выяснив есть ли общие и частные претензии к работе команды, возможно всплывут те вещи, которые косвенно или явно вызывают сбои.