Да, и много раз "да", руководитель должен быть готов слушать правду и не наказывать. И да, это тяжело. А ещё есть два вида неприятной правды: ошибка (не верно выбрал решения в неопределённости) и проступок (осознанное нарушение правила). Проступок всегда локально наказывается, но при добровольном признании и при разовости, сильно меньше наказывается.
Обязанности руководителя в самом начале статьи. Они заключаются в положительной оценке деятельности и предложении перспектив, если требования сотрудником соблюдаются.
До конкретных действий не детализировались, запроса ни разу не было.
А что кого-то другого, кроме автора, можно оценивать в контексте темы статьи? Упоминались какие-то примеры из чьей-тр ещё личной практики? Есть оговорки?
А вот это обидно. Мы с вами даже не знакомы, чтобы так меня оценивать.
Любой инструмент можно использовать по разному: топором можно дрова рубить, а можно головы. Сам инструмент за это не отвечает.
Контракт друхсторонний, руководитель тоже обещает определенные действия со своей стороны, и если он будет нарушать свои обещания, то и контракт не будет работать.
Любое управление или коммуникация по своей природе манипуляционны. Только есть манипуляции, в которых одна из сторон проигрывает (назовем их неэтичные), а есть в которых обе стороны выигрывают ("назовем "этичными"). От второй стороны нам нужно какие-то действия и мы предлагем ей в замен либо получение плюшек, либо избежать неприятного. В случае в контрактом явно проговаривается, что следование предлагаемым принципам позволит сотруднику гораздо проще закрывать свои потребности во взаимодействии со мной. Поэтому контракт - это манипуляция, но этичная.
Что касается вопросов. То речь идет о ситуациях, когда сотрудник отвечает на все, что угодно, но только не на заданный вопрос, т.к. банально боится рассказать. Меня такое поведение очень сильно раздражает, поэтому в интересах самого сотрудика так не делать :)
Да, Вы правы принципы банальны. Их цель создать и озвучить единую, прозрачную и понятную всем систему координат и убрать додумывания сторон. Именно фиксация на бумаге банальностей (того, что все вроде и так должны знать) часто дает удивительные результаты. Это именно такой случай.
Контракт не воспитывает, контракт задает границы. Кроме контракта дается время на подстроиться к среде, а получается не у всех.
Воспитать на примере коллектива без задания границ, на мой взгляд, не получится, сотрудники сами додумают все не сказанное, и версии этого могут сильно удивлять.
Если руководитель не будет сам выполнять контракт, который предлагает сотруднику, то конечно контракт не будет работать.
Хорошое замечание. Осознать не целесообразность продолжения и выйти из проекта/задачи, в моем понимании, это также доводить дело до конца. Спасибо, внесу коррекцию в текст. Принцип про исключение ситуаций, когда человек загорелся идей, а потом потух и задача мылится, как не интересная. Цель принципа стимулировать доделку, когда исполнителю уже не хочется.
Да, вы правы, такое может быть. Мне же чаще встречался паттерн поведения, когда выполнение задачи начинается, когда до дедлайна остается ровно столько времени, сколько, на взгляд исполнителя, нужно для выполнения задачи. А потом прилетает аврал по другой задче или выясняется ошибка при оценке этой задачи. В итоге имеем либо продолбанный дедлайн, либо упрощение результата, либо не запланированную трату доп. ресурсов.
И согласен, и не согласен. Согласен с размытостью использованного термина "правильные". Введение контракта и преследовало цель первести размытое "правильно/не правильно" в конкретные паттерны поведения через их описание. Не согласен, речь не столько о самих решениях, сколько о привычном поведении в повторяющихся ситуациях. Речь о том, какие действия желаемы, а какие не приемлемы.
Здорово, классная цель для дискуссии. А какие на Ваш взгляд могут быть цели на входе в ИТ? Для экономии времени ИТ упростим до отдела техподдержки и процесса решения обращений.
«риски или что денег не хватит» — для чего нужны?
«работа ИТ не соотвествует ожиданиям заказчиков» — для чего? В SLA это не прописано?
«процесс непрерывного улучшения» — зачем нужен? Если на него нет спрос
В игру «зачем?» можно до бесконечности играть. Я считаю, что уже достаточно пояснил мысль, заложенную в статье.
ITIL, COBIT, IT4IT — предполагают что IT это нечто обособленное.
Вы не правы, но обсуждение этих вопросов к статье не относится.
KPI — дословно «ключевые индикаторы результативности», они являются лишь «светофорами» или «градусниками» показывающими текущее состояние «здоровья» той или иной цели. Они не являются доказательством достижения или не достижения цели. поэтому:
«процент расходования годового бюджета ИТ» — о чем может сказать?
отклонение от ожидаемых показателей верхне уровнево показывает, что есть риски или что денег не хватит, и компании придется тратить резервы, или наоборот деньги останутся замороженными, а вообще нужно лезть в подробности и разбираться, что идет не так
рейтинг удовлетворенности по закрытым инцидентам» — где использовать,?
индикатор, что работа ИТ не соотвествует ожиданиям заказчиков, нужно встречаться и разговаривать для определения это ожидания завышены, или что-то изменилось в среде заказчика и старые SLA (не важно в виде документов или в виде устных договренностей) стали плохо описывать потребности.
«количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения» — как быть с неприемлемыми или отозванными предложениями?
как посчитаете правильным, так и cделайте. многие вообще живкт без оформленного процесса непрерывного улучшения (CSI), вполне обходясь локальными улучшениями без огласки и тушением пожаров.
вообще-то это заказчик выставляет вам цели и критерии оценки их достижения.
В случаях низкого доверия, да, жестко выставляет. Если доверия побольше, то идет обсуждение. Бывают случаи, когда заказчику все равно, единственное его требование: «чтобы все работало», и тогда приходится выпытывать его процессы и операции, которые поддерживаются ИТ-системами, и из этого получать требования к ИТ.
Не стоит бороться с «фатальным недостатком», лучше взять наработанные в других сферах методики. Тот-же кайдзэн полностью покрывает «эксплуатацию ИС». А проекты/микропроекты развития, даже в гибкой форме вполне самодостаточны в плане оценки результата.
Каждый решает для себя сам, чем ему пользоваться. Считаете, что для Вас более приемлем lean и готовы сделать его адаптацию под не производство, делайте. Другие выберут ITIL, а третьи поймут что им нужен только COBIT, т.к. внешние аудиты, четвертые выберут IT4IT, а пятые придумают свой уникальный фреймфорк, а еще кто-то скажет, что процессы — это бюрократия и они им не подходят.
Это же ничем не противречит статьям… В них идет рассказ об одном из вариантов (а именно вараинте рекомендуемом в ITIL) как имея цель, cформулированную в понятных для бизнеса категориях (сбалансированная система показателей), плучить ключевые показатели для оценки, которые также можно показывать заказчику, т.к. они сформулированы в его терминах.
Если нужны подробные примеры по показателям ITSM процеесом, можно посмотреть на COBIT.
Его позиционируют, как reference (образцовая, примерная) модель процессов, в отличие от ITIL, которую выпускают в мир, как best practics (только best трактуют, как хорошие, а не лучшие :) ).
Кстати, в COBIT для показателей используется сбалансиованная система…
серия про технологию формирования метрик через последовательное формулирование целей — критических факторов успешности — ключевые показатели — метрики.
цели выбираете сами, и в каждой заметке есть оговорка, что приводимые примеры не универсальные, не нужно их бездумно использовать. примеры лучше использовать, как вектор мысли.
данная стать про расширение это йтехнологии через добавление на каждом уровне четырех разрезов (проекций), чтобы связать процессы ITSM с целями, кто за них платит деньги, и быть им более понятными.
Попробуйте почитать еще одну статью Рейнса «Осторожно. Как использовать метрики процессов без вреда для здоровья процессов» habr.com/ru/post/359206, если она не ответит на Ваш вопрос, посмотрю, что еще можно найти.
PS Рейнс, как и многие, кто связан с любыми best practics, очень не любят давать рекомендации, что именно делать и измерять, предпочитая описывать подходы и в качестве примеров давать кусочки свой удачной практики.
Если это только не механизм с обратной связью. :)
Да, и много раз "да", руководитель должен быть готов слушать правду и не наказывать. И да, это тяжело. А ещё есть два вида неприятной правды: ошибка (не верно выбрал решения в неопределённости) и проступок (осознанное нарушение правила). Проступок всегда локально наказывается, но при добровольном признании и при разовости, сильно меньше наказывается.
Обязанности руководителя в самом начале статьи. Они заключаются в положительной оценке деятельности и предложении перспектив, если требования сотрудником соблюдаются.
До конкретных действий не детализировались, запроса ни разу не было.
А что кого-то другого, кроме автора, можно оценивать в контексте темы статьи? Упоминались какие-то примеры из чьей-тр ещё личной практики? Есть оговорки?
А вот это обидно. Мы с вами даже не знакомы, чтобы так меня оценивать.
Любой инструмент можно использовать по разному: топором можно дрова рубить, а можно головы. Сам инструмент за это не отвечает.
Контракт друхсторонний, руководитель тоже обещает определенные действия со своей стороны, и если он будет нарушать свои обещания, то и контракт не будет работать.
Да, только расписанные в деталях и настроенные на меня лично, чтобы упростить мне жизнь при объяснениях, как живем.
Оооооо, не многие узнают эту картнику.
Ни о чем, аналогия показалась занятной: продажа души и трудоустройство.
Согласен. При замене термина, на мой взгляд, возрастает риск, что сотрудник свалится в роль Жертвы. Я подумаю, спасибо, мысль ценная!
Любое управление или коммуникация по своей природе манипуляционны. Только есть манипуляции, в которых одна из сторон проигрывает (назовем их неэтичные), а есть в которых обе стороны выигрывают ("назовем "этичными"). От второй стороны нам нужно какие-то действия и мы предлагем ей в замен либо получение плюшек, либо избежать неприятного. В случае в контрактом явно проговаривается, что следование предлагаемым принципам позволит сотруднику гораздо проще закрывать свои потребности во взаимодействии со мной. Поэтому контракт - это манипуляция, но этичная.
Что касается вопросов. То речь идет о ситуациях, когда сотрудник отвечает на все, что угодно, но только не на заданный вопрос, т.к. банально боится рассказать. Меня такое поведение очень сильно раздражает, поэтому в интересах самого сотрудика так не делать :)
Да, Вы правы принципы банальны. Их цель создать и озвучить единую, прозрачную и понятную всем систему координат и убрать додумывания сторон. Именно фиксация на бумаге банальностей (того, что все вроде и так должны знать) часто дает удивительные результаты. Это именно такой случай.
Контракт не воспитывает, контракт задает границы. Кроме контракта дается время на подстроиться к среде, а получается не у всех.
Воспитать на примере коллектива без задания границ, на мой взгляд, не получится, сотрудники сами додумают все не сказанное, и версии этого могут сильно удивлять.
Если руководитель не будет сам выполнять контракт, который предлагает сотруднику, то конечно контракт не будет работать.
Хорошое замечание.
Осознать не целесообразность продолжения и выйти из проекта/задачи, в моем понимании, это также доводить дело до конца. Спасибо, внесу коррекцию в текст.
Принцип про исключение ситуаций, когда человек загорелся идей, а потом потух и задача мылится, как не интересная. Цель принципа стимулировать доделку, когда исполнителю уже не хочется.
Да, вы правы, такое может быть. Мне же чаще встречался паттерн поведения, когда выполнение задачи начинается, когда до дедлайна остается ровно столько времени, сколько, на взгляд исполнителя, нужно для выполнения задачи. А потом прилетает аврал по другой задче или выясняется ошибка при оценке этой задачи. В итоге имеем либо продолбанный дедлайн, либо упрощение результата, либо не запланированную трату доп. ресурсов.
И согласен, и не согласен.
Согласен с размытостью использованного термина "правильные". Введение контракта и преследовало цель первести размытое "правильно/не правильно" в конкретные паттерны поведения через их описание.
Не согласен, речь не столько о самих решениях, сколько о привычном поведении в повторяющихся ситуациях. Речь о том, какие действия желаемы, а какие не приемлемы.
В игру «зачем?» можно до бесконечности играть. Я считаю, что уже достаточно пояснил мысль, заложенную в статье.
Вы не правы, но обсуждение этих вопросов к статье не относится.
отклонение от ожидаемых показателей верхне уровнево показывает, что есть риски или что денег не хватит, и компании придется тратить резервы, или наоборот деньги останутся замороженными, а вообще нужно лезть в подробности и разбираться, что идет не так
индикатор, что работа ИТ не соотвествует ожиданиям заказчиков, нужно встречаться и разговаривать для определения это ожидания завышены, или что-то изменилось в среде заказчика и старые SLA (не важно в виде документов или в виде устных договренностей) стали плохо описывать потребности.
как посчитаете правильным, так и cделайте. многие вообще живкт без оформленного процесса непрерывного улучшения (CSI), вполне обходясь локальными улучшениями без огласки и тушением пожаров.
В случаях низкого доверия, да, жестко выставляет. Если доверия побольше, то идет обсуждение. Бывают случаи, когда заказчику все равно, единственное его требование: «чтобы все работало», и тогда приходится выпытывать его процессы и операции, которые поддерживаются ИТ-системами, и из этого получать требования к ИТ.
Каждый решает для себя сам, чем ему пользоваться. Считаете, что для Вас более приемлем lean и готовы сделать его адаптацию под не производство, делайте. Другие выберут ITIL, а третьи поймут что им нужен только COBIT, т.к. внешние аудиты, четвертые выберут IT4IT, а пятые придумают свой уникальный фреймфорк, а еще кто-то скажет, что процессы — это бюрократия и они им не подходят.
Его позиционируют, как reference (образцовая, примерная) модель процессов, в отличие от ITIL, которую выпускают в мир, как best practics (только best трактуют, как хорошие, а не лучшие :) ).
Кстати, в COBIT для показателей используется сбалансиованная система…
цели выбираете сами, и в каждой заметке есть оговорка, что приводимые примеры не универсальные, не нужно их бездумно использовать. примеры лучше использовать, как вектор мысли.
данная стать про расширение это йтехнологии через добавление на каждом уровне четырех разрезов (проекций), чтобы связать процессы ITSM с целями, кто за них платит деньги, и быть им более понятными.
Попробуйте почитать еще одну статью Рейнса «Осторожно. Как использовать метрики процессов без вреда для здоровья процессов» habr.com/ru/post/359206, если она не ответит на Ваш вопрос, посмотрю, что еще можно найти.
PS Рейнс, как и многие, кто связан с любыми best practics, очень не любят давать рекомендации, что именно делать и измерять, предпочитая описывать подходы и в качестве примеров давать кусочки свой удачной практики.