EL
вот потому я и не люблю споры по поводу теории.
Size: a a a
2019 February 22
MS
вот потому я и не люблю споры по поводу теории.
а по мне это вполне уместные приседания. практикой мы и без этого сполна занимаемся. а тут - рефлексируем. что потом, порой, пригождается на практике.
EL
а по мне это вполне уместные приседания. практикой мы и без этого сполна занимаемся. а тут - рефлексируем. что потом, порой, пригождается на практике.
:) Я обычно сюда как раз за разбором кейсов прихожу и за публикуемыми материалами.
2019 February 23
Е
Gretchen
Конечно. С названиями всегда зыбко) Но все-таки склоняюсь к разграничению сервис-менеджера и продакта по признаку дополнительности "сервиса". Не могу вспомнить ни одного "сервис-менеджера", ответственного за основную услугу компании.
Сейчас работаю в компании, где есть и продакты и пиэмы и сервис-менеджеры. И знаю ещё одну такую же как минимум. Деятельность во многом схожая, но как всегда, разделяет их нюансы.
Е
Вот если сказать, что:
- владелец процесса отвечает за установление целевых параметров процесса и за их соответствие целям компании. Иными словами проектирует процесс .
- сервис -менеджер отвечает за повседневное функционирование процесса в соответчтвии с задвнныси парвметрами.
Иными словами эксплуатирует этот процесс.
- владелец процесса отвечает за установление целевых параметров процесса и за их соответствие целям компании. Иными словами проектирует процесс .
- сервис -менеджер отвечает за повседневное функционирование процесса в соответчтвии с задвнныси парвметрами.
Иными словами эксплуатирует этот процесс.
Почти так, но не совсем. В ITIL все распределяется по ролям. Владелец и менеджер это роли. Владелец процесса отвечает за общее управление и помогает корректировать достижение и закрепление показателей SLA по сервису, но не проектирует. В ITIL вообще разрешать проектировать процесс владельцу это преступление (на мой взгляд). Это делают консультанты. Если, конечно, владелец не сертифицирован по ITIL не ниже practicioner. Менеджер процесса отвечает за реализацию процесса, т.е. принимает участие в проектировании на правах полноценного участника вместе с консультантами и по сути обеспечивает через ролевые инструкции участников процесса достижение тех самых показателей качества сервиса и качества процесса. Если совсем просто, то владелец процесса это человек, на должности примерно директор департамента (эксплуатации, развития, архитектуры), менеджер процесса - руководитель группы, начальник профильного отдела, бывают ведущие специалисты. Я допускаю, что эволюция 10 последних лет сильно поменяло значение моих слов, но на правах преподавателя ITIL v.2 в анамнезе и практика по внедрению процессов до 2011 года было всегда так. Чем старше становлюсь, тем больше сомневаюсь).
YR
Тьма - отсуствие света, а свет отсуствие тьмы. Таким образом и то и другое является лишь частным случаем тени :) не помю откуда..
Не, тьма это состояние по умолчанию.
YR
Почти так, но не совсем. В ITIL все распределяется по ролям. Владелец и менеджер это роли. Владелец процесса отвечает за общее управление и помогает корректировать достижение и закрепление показателей SLA по сервису, но не проектирует. В ITIL вообще разрешать проектировать процесс владельцу это преступление (на мой взгляд). Это делают консультанты. Если, конечно, владелец не сертифицирован по ITIL не ниже practicioner. Менеджер процесса отвечает за реализацию процесса, т.е. принимает участие в проектировании на правах полноценного участника вместе с консультантами и по сути обеспечивает через ролевые инструкции участников процесса достижение тех самых показателей качества сервиса и качества процесса. Если совсем просто, то владелец процесса это человек, на должности примерно директор департамента (эксплуатации, развития, архитектуры), менеджер процесса - руководитель группы, начальник профильного отдела, бывают ведущие специалисты. Я допускаю, что эволюция 10 последних лет сильно поменяло значение моих слов, но на правах преподавателя ITIL v.2 в анамнезе и практика по внедрению процессов до 2011 года было всегда так. Чем старше становлюсь, тем больше сомневаюсь).
Вот все по полочкам и разложили
AO
Почти так, но не совсем. В ITIL все распределяется по ролям. Владелец и менеджер это роли. Владелец процесса отвечает за общее управление и помогает корректировать достижение и закрепление показателей SLA по сервису, но не проектирует. В ITIL вообще разрешать проектировать процесс владельцу это преступление (на мой взгляд). Это делают консультанты. Если, конечно, владелец не сертифицирован по ITIL не ниже practicioner. Менеджер процесса отвечает за реализацию процесса, т.е. принимает участие в проектировании на правах полноценного участника вместе с консультантами и по сути обеспечивает через ролевые инструкции участников процесса достижение тех самых показателей качества сервиса и качества процесса. Если совсем просто, то владелец процесса это человек, на должности примерно директор департамента (эксплуатации, развития, архитектуры), менеджер процесса - руководитель группы, начальник профильного отдела, бывают ведущие специалисты. Я допускаю, что эволюция 10 последних лет сильно поменяло значение моих слов, но на правах преподавателя ITIL v.2 в анамнезе и практика по внедрению процессов до 2011 года было всегда так. Чем старше становлюсь, тем больше сомневаюсь).
👍 Отличный разбор.
Но это «классика» так сказать.
А есть уже подходы, что нарезать RUN-деятельность на процессы - уже не модно. Ибо слишком много процессов получается.
Но это «классика» так сказать.
А есть уже подходы, что нарезать RUN-деятельность на процессы - уже не модно. Ибо слишком много процессов получается.
NS
Коллеги, а кто из вас на практике использует трёхточечный метод оценки сроков? Есть ли практическая польза на ваш взгляд?
DD
Коллеги, а кто из вас на практике использует трёхточечный метод оценки сроков? Есть ли практическая польза на ваш взгляд?
Для очень предварительных грубых оценок, и чтобы проверить, не слишком ли кто-то оптимист/пессимист/перезакладчик
AO
Коллеги, а кто из вас на практике использует трёхточечный метод оценки сроков? Есть ли практическая польза на ваш взгляд?
Мне больше нравиться planning poker
YR
Коллеги, а кто из вас на практике использует трёхточечный метод оценки сроков? Есть ли практическая польза на ваш взгляд?
Пол полец потолок ?
NS
Alexander Ozharovskiy
Мне больше нравиться planning poker
Хороший метод для внутренней разработки. На аутсорсе пошлют с таким)
С
Хороший метод для внутренней разработки. На аутсорсе пошлют с таким)
Чтоб вопросов не было, дробим тдз на аналитику, разработку и тестирование ( если вопрос именно к разработке/доработке ПО)
С
Ну и при планировании участвует вся команда для более точной оценки, но в тоже время быстрой
С
А при реализации таймшитинг от команды в Jira и на ретроспективе спринта соотносим реальностью с экспресс-оценкой, ну и делаем выводы)
2019 February 24
НК
Внутренняя разработка или на заказ?
С
Внутренняя разработка или на заказ?
Внутренняя, но организация крупная и бизнес взаимодействует с ИТ по аналогии со сторонней организацией
2019 February 25
MS
Кричать на работе будете? А планировать все заранее? Проверьте, в какой стране управляют так же, как вы — Meduza
https://meduza.io/games/krichat-na-rabote-budete-a-planirovat-vse-zaranee-proverte-v-kakoy-strane-upravlyayut-tak-zhe-kak-vy
https://meduza.io/games/krichat-na-rabote-budete-a-planirovat-vse-zaranee-proverte-v-kakoy-strane-upravlyayut-tak-zhe-kak-vy
MS
Начитался, вот, американских книжек по менеджменту )