Комментарии 28
Простите, а Вы уже ведете разработку по этим книжкам или пока только послушали великолепные курсы? Просто в организации техподдержки (на что эти рекомендации изначально и были направлены) слово «айтил» обычно встречается в составе выражения «на### айтил!». В чистом виде это отличный способ парализовать работу предприятия в стиле итальянской забастовки. Может использоваться, когда с процессами полнейший швах и никто на предприятии не знает, что делать и куда бежать.
Ровно так-же можно сказать:
Version Control? — на### version control!
Continuos Integration? — на### continuos integration!
Continuos Delivery? на### continuos delivery
не говоря уже о более простых «на### объекты», или «на### функциональщину», «на### реляционные базы данных», «на### всякий noSQL» и так далее.
Организация тех.поддержки, как замечено в статье — это ITSM.
О каком «в чистом виде» идет речь, если это по сути «сборник рецептов»?
Всякие научные методики применяют не «когда никто не знает куда бежать», как раз наоборот, когда вроде бы все знают, все бегают и делают, но результат как был полный швах, так и остается. Или человеческого ресурса не хватает, или времени, или одновременно, и как вылезать на следующий уровень — непонятно.
Именно в этот момент нужно знакомиться с результатами исследований и начинать применять к своим процессам.
Если же у кого «процессы известны, все бегают в правильную сторону и результат устраивает», то конечно чего дергаться-то?
Version Control? — на### version control!
Continuos Integration? — на### continuos integration!
Continuos Delivery? на### continuos delivery
не говоря уже о более простых «на### объекты», или «на### функциональщину», «на### реляционные базы данных», «на### всякий noSQL» и так далее.
Организация тех.поддержки, как замечено в статье — это ITSM.
О каком «в чистом виде» идет речь, если это по сути «сборник рецептов»?
Всякие научные методики применяют не «когда никто не знает куда бежать», как раз наоборот, когда вроде бы все знают, все бегают и делают, но результат как был полный швах, так и остается. Или человеческого ресурса не хватает, или времени, или одновременно, и как вылезать на следующий уровень — непонятно.
Именно в этот момент нужно знакомиться с результатами исследований и начинать применять к своим процессам.
Если же у кого «процессы известны, все бегают в правильную сторону и результат устраивает», то конечно чего дергаться-то?
>О каком «в чистом виде» идет речь, если это по сути «сборник рецептов»?
Открываем книгу, видим «для внесения изменений их должен утвердить консультационный комитет, который собирается раз в месяц». Говорим, что 10 начальников будут теперь CAB`ом, собираться они будут 4го числа и утверждать список изменений. Работы можно проводить только после утверждения.
Это не утрированный пример из головы, это реальный пример. Что интересно — в применение к одной системе на предприятии оно работает отлично, в применении к другой ломает работу полностью.
>Если же у кого «процессы известны, все бегают в правильную сторону и результат устраивает», то конечно чего дергаться-то?
Потому что «у нас не по айтилу!!!!1111одинодин Надо переделывать!!!!111одинодин». Приходилось слышать на совещаниях предложения сломать рабочую схему и сделать «как в книжке» или как «нам на курсах говорили». Оно бы привело к увеличению времени решения инцидента часов на 10.
Открываем книгу, видим «для внесения изменений их должен утвердить консультационный комитет, который собирается раз в месяц». Говорим, что 10 начальников будут теперь CAB`ом, собираться они будут 4го числа и утверждать список изменений. Работы можно проводить только после утверждения.
Это не утрированный пример из головы, это реальный пример. Что интересно — в применение к одной системе на предприятии оно работает отлично, в применении к другой ломает работу полностью.
>Если же у кого «процессы известны, все бегают в правильную сторону и результат устраивает», то конечно чего дергаться-то?
Потому что «у нас не по айтилу!!!!1111одинодин Надо переделывать!!!!111одинодин». Приходилось слышать на совещаниях предложения сломать рабочую схему и сделать «как в книжке» или как «нам на курсах говорили». Оно бы привело к увеличению времени решения инцидента часов на 10.
Для продолжения рассмотрения примера, нужно больше деталей. Интересно, например, как определяется «консультационный комитет» — сколько человек туда должны входить, какие у них роли. Что значит «собирается» — обязательно встречаться лично или устроит скайп, e-mail, еще как-то?
Приведу наш реальный пример (у нас ни разу не ITIL, кстати):
— есть «менеджер продаж» — люди, которые общаются с заказчиками и отвечают «за деньги» в рамках проекта.
— есть технолог — человек, который очень хорошо знает прикладную область, и отвечает за перевод «с языка заказчиков на простой язык, и на язык программистов». Обычно этих людей называют «аналитик», но у нас вот как-то прижилось «технолог».
— есть руководитель проекта — в классическом понимании.
сюрприз: какие из пожеланий заказчиков и в каком виде войдут в следующую версию, решают (по сути) эти трое.
Они собираются, или «примитивно» в e-mail, или «продвинуто», в task-трекере, и решают, или «срочно» — по телефону.
Раз в месяц — это бы мы умерли давно, реже чем раз в неделю физически не получается, иногда по несколько раз в день приходится «собираться» — заказчиков много, все разные, хотят порой кардинально противоположных вещей.
Истерики «у нас не по ZZZZ» — я воспринимаю нормально. Мой личный опыт показывает, что люди кричащие «у нас не по ZZZZ, нужно переделать», скорее всего не понимают ту самую фразу про «добавление ценности».
Разве что за исключением реплик «горизонт завален» — это чаще таки говорят по приколу :)))
Вот со слов «оно бы привело к увеличению времени решения» можно дальше развить. И, взять да применить ITIL ко внедрению ITIL'я, элементарно проверить добавляет ли его внедрение ценность? Снижает риски? И так далее.
Приведу наш реальный пример (у нас ни разу не ITIL, кстати):
— есть «менеджер продаж» — люди, которые общаются с заказчиками и отвечают «за деньги» в рамках проекта.
— есть технолог — человек, который очень хорошо знает прикладную область, и отвечает за перевод «с языка заказчиков на простой язык, и на язык программистов». Обычно этих людей называют «аналитик», но у нас вот как-то прижилось «технолог».
— есть руководитель проекта — в классическом понимании.
сюрприз: какие из пожеланий заказчиков и в каком виде войдут в следующую версию, решают (по сути) эти трое.
Они собираются, или «примитивно» в e-mail, или «продвинуто», в task-трекере, и решают, или «срочно» — по телефону.
Раз в месяц — это бы мы умерли давно, реже чем раз в неделю физически не получается, иногда по несколько раз в день приходится «собираться» — заказчиков много, все разные, хотят порой кардинально противоположных вещей.
Истерики «у нас не по ZZZZ» — я воспринимаю нормально. Мой личный опыт показывает, что люди кричащие «у нас не по ZZZZ, нужно переделать», скорее всего не понимают ту самую фразу про «добавление ценности».
Разве что за исключением реплик «горизонт завален» — это чаще таки говорят по приколу :)))
Вот со слов «оно бы привело к увеличению времени решения» можно дальше развить. И, взять да применить ITIL ко внедрению ITIL'я, элементарно проверить добавляет ли его внедрение ценность? Снижает риски? И так далее.
>Приведу наш реальный пример (у нас ни разу не ITIL, кстати):
Вот! На чём я настаиваю — так это на том, что нельзя брать ITIL как религиозную догму. Можно брать какие-то идеи и адаптировать их к имеющейся реальности. Вы так и сделали, как я понимаю.
>Истерики «у нас не по ZZZZ» — я воспринимаю нормально.
Да я уже тоже нормально. Просто объясняю, почему в данной ситуации ITIL «на### идет».
>Мой личный опыт показывает, что люди кричащие «у нас не по ZZZZ, нужно переделать», скорее всего не понимают ту самую фразу про «добавление ценности»
А мой показывает, что это люди, которые не знают, что сказать, но что-то умное сказать надо обязательно. А «айтил» солидно звучит, внушительно. Можно еще сертификат трехдневных курсов показать :)
Вот! На чём я настаиваю — так это на том, что нельзя брать ITIL как религиозную догму. Можно брать какие-то идеи и адаптировать их к имеющейся реальности. Вы так и сделали, как я понимаю.
>Истерики «у нас не по ZZZZ» — я воспринимаю нормально.
Да я уже тоже нормально. Просто объясняю, почему в данной ситуации ITIL «на### идет».
>Мой личный опыт показывает, что люди кричащие «у нас не по ZZZZ, нужно переделать», скорее всего не понимают ту самую фразу про «добавление ценности»
А мой показывает, что это люди, которые не знают, что сказать, но что-то умное сказать надо обязательно. А «айтил» солидно звучит, внушительно. Можно еще сертификат трехдневных курсов показать :)
Работать по ITIL можно, но она часто упирается в бюрократию. А Бюрократия очень изменчива.
у вас спрошу иначе:
1. Source Version Control — это бюрократия? Это же как же можно заставлять программиста, регулярно фиксировать результат своего труда, сопровождая комментарием? От этой бюрократии программа лучше не становится.
2. task tracking — это бюрократия? Это же как же можно, заставлять писать задачи, работать по задачам, при коммите ставить ссылку на задачу? От этой бюрократии тоже программа ну улучшается.
1. Source Version Control — это бюрократия? Это же как же можно заставлять программиста, регулярно фиксировать результат своего труда, сопровождая комментарием? От этой бюрократии программа лучше не становится.
2. task tracking — это бюрократия? Это же как же можно, заставлять писать задачи, работать по задачам, при коммите ставить ссылку на задачу? От этой бюрократии тоже программа ну улучшается.
1. Осознанная необходимость. Если еще не осознана — то либо везунчик, либо пофигист.
2. Аналогично п.1, как я полагаю.
2. Аналогично п.1, как я полагаю.
Ну так и лучшие практики из ITIL — тоже осознанная (теми, кто их применял) необходимость. А если ещё не осознана — то либо везунчик, либо «IT-ники ни хрена не делают, гнать их всех в шею» :)
Регулярно записывать для отчёта для меня и есть бюрократия. По сути врач записывающий карты пациента на отлично лучше лечить не станет. И не понимаю зачем мне этот вопрос.
Врач, читающий карты пациента, станет лечить лучше. Узнает, что у него аллергия на одну групп антибиотиков и что другой группой его уже кормили месяц назад.
если врач не будет регулярно вести историю болезни, пациента мало кто эффективно вылечить сможет. елси мы, конечно, не говорим о простуде, которая или за неделю сама проходит, или за семь дней её можно вылечить.
Вопрос к вам потому, что слово «бюрократия» обросло очень разными смыслами.
Заметьте, я ни разу не сказал «для отчета». Комментарии при коммите нужны
— коллеге, который делает Code Review
— руководителю (team lead), который следит за ходом решения задачи
— PM'у, который следит за развитием проекта в целом, если вдруг какая-то задача по срокам начинает пролетать.
— разработчику, который через пару лет в этом коде будет править ошибку
Я слабо представляю, кому в современном мире нужно что-то «для отчета», как и отчеты сами по себе.
Вопрос к вам потому, что слово «бюрократия» обросло очень разными смыслами.
Заметьте, я ни разу не сказал «для отчета». Комментарии при коммите нужны
— коллеге, который делает Code Review
— руководителю (team lead), который следит за ходом решения задачи
— PM'у, который следит за развитием проекта в целом, если вдруг какая-то задача по срокам начинает пролетать.
— разработчику, который через пару лет в этом коде будет править ошибку
Я слабо представляю, кому в современном мире нужно что-то «для отчета», как и отчеты сами по себе.
>Я слабо представляю, кому в современном мире нужно что-то «для отчета», как и отчеты сами по себе.
Вас познакомить?
У меня в служебный обязанности входила подготовка отчета. Раз в неделю. В силу ряда причин на это уходило полдня. И у нас была возможность проверить, открывал ли кто-нибудь файл с отчетом. За полгода — никто. За вопрос «а может, ну его?» получили ответ «это очень нужный отчет!!!!». Чуть не бизнес без него встанет.
С другим еженедельным отчетом (тоже очень важном) бывали косяки. Каждую неделю новый отчет с одними и теми же данными — свежие не поступали. Получатель отчета заметил это через 2 месяца. Даже не бизнес-получатель, а «промежуточное звено» в длинной цепи передачи отчета.
Вас познакомить?
У меня в служебный обязанности входила подготовка отчета. Раз в неделю. В силу ряда причин на это уходило полдня. И у нас была возможность проверить, открывал ли кто-нибудь файл с отчетом. За полгода — никто. За вопрос «а может, ну его?» получили ответ «это очень нужный отчет!!!!». Чуть не бизнес без него встанет.
С другим еженедельным отчетом (тоже очень важном) бывали косяки. Каждую неделю новый отчет с одними и теми же данными — свежие не поступали. Получатель отчета заметил это через 2 месяца. Даже не бизнес-получатель, а «промежуточное звено» в длинной цепи передачи отчета.
спасибо, специально знакомить не нужно :)
На самом деле, я сам большой сторонник разных «отчетов», но в моём понимании, отчет — это консолидация и обработка информации которая уже фиксируется по ходу процесса.
Момент «фиксации информации», должен быть частью процесса, должен «естественно проистекать» из самого процесса, и самое главное (и сложное) — человеку должно быть понятно с какой целью его заставляют «заниматься фигнёй».
На самом деле, я сам большой сторонник разных «отчетов», но в моём понимании, отчет — это консолидация и обработка информации которая уже фиксируется по ходу процесса.
Момент «фиксации информации», должен быть частью процесса, должен «естественно проистекать» из самого процесса, и самое главное (и сложное) — человеку должно быть понятно с какой целью его заставляют «заниматься фигнёй».
Мой первый комментарий:
Работать по ITIL можно, но она часто упирается в бюрократию. А Бюрократия очень изменчива.
Вот это и имелось ввиду. К примеру у меня сломался принтер. Исправил, записал. Ещё раз, исправил, записал. Написал что ресурс изношен. Заключение. Техника на списание. Руководство говорит принтер списать, но нового не будет. Смысл записей? Если принтер изначально было известно что выработал ресурс.
Врач, пишет одну карту для больницы, потом карту для страховой, потом для статистов края\области. Данный процесс не вписан в рабочий график, в результате на него просто нет времени. Падает качество заполнения? При этом почему бы нельзя сделать всё в одной базе. Кстати карта из одной больницы в другую отправляется по запросу, и того может быть потеряна.
Задумка хорошая, реализация хромает.
Но есть и хорошие примеры. к примеру появляется инцидент, в базе знаний уже можно найти решения по тем или иным продуктам и оборудованию.
Работать по ITIL можно, но она часто упирается в бюрократию. А Бюрократия очень изменчива.
Вот это и имелось ввиду. К примеру у меня сломался принтер. Исправил, записал. Ещё раз, исправил, записал. Написал что ресурс изношен. Заключение. Техника на списание. Руководство говорит принтер списать, но нового не будет. Смысл записей? Если принтер изначально было известно что выработал ресурс.
Врач, пишет одну карту для больницы, потом карту для страховой, потом для статистов края\области. Данный процесс не вписан в рабочий график, в результате на него просто нет времени. Падает качество заполнения? При этом почему бы нельзя сделать всё в одной базе. Кстати карта из одной больницы в другую отправляется по запросу, и того может быть потеряна.
Задумка хорошая, реализация хромает.
Но есть и хорошие примеры. к примеру появляется инцидент, в базе знаний уже можно найти решения по тем или иным продуктам и оборудованию.
вот вы сами говорите, что проблема не в требованиях записывать, а в том, что происходит дальше, и как эти требований встроены в процесс.
Если зафиксировали два раза поломку принтера, и записали что ресурс закончился — отлично. На этом этапе (в этой части) работы выполнены правильно и хорошо. А то, что нового не будет — это проблема уже дальше по цепочке управления.
Сравнивать эту ситуацию нужно не с «пофиг, пиши не пиши — как работает полу-мертвый принтер пока не развалится так и будет», а с ситуацией, когда есть деньги на новый принтер, а люди мучаются с развалюхой, носят его в ремонт, теряя время, нервы и так далее. Просто потому, что никто не записал, что принтер давно пора менять.
Про врачей, так получилось, я знаю чуть больше. И там, куда приходим мы, врачи работу два раза не делают. А многие «записи» вообще сразу получаются, автоматически. Именно потому, что реально можно всё сделать «в одной базе», и так далее.
И вопрос с автоматизацией в медицине, как и с внедрением ITIL — в целях руководства. Если нужно, что бы врачи занимались лечением — ищут способы, как снять с них не профильную рутину. Если нужно тупо бумажки заполнять — заставляют заполнять бумажки.
Если зафиксировали два раза поломку принтера, и записали что ресурс закончился — отлично. На этом этапе (в этой части) работы выполнены правильно и хорошо. А то, что нового не будет — это проблема уже дальше по цепочке управления.
Сравнивать эту ситуацию нужно не с «пофиг, пиши не пиши — как работает полу-мертвый принтер пока не развалится так и будет», а с ситуацией, когда есть деньги на новый принтер, а люди мучаются с развалюхой, носят его в ремонт, теряя время, нервы и так далее. Просто потому, что никто не записал, что принтер давно пора менять.
Про врачей, так получилось, я знаю чуть больше. И там, куда приходим мы, врачи работу два раза не делают. А многие «записи» вообще сразу получаются, автоматически. Именно потому, что реально можно всё сделать «в одной базе», и так далее.
И вопрос с автоматизацией в медицине, как и с внедрением ITIL — в целях руководства. Если нужно, что бы врачи занимались лечением — ищут способы, как снять с них не профильную рутину. Если нужно тупо бумажки заполнять — заставляют заполнять бумажки.
вот вы сами говорите, что проблема не в требованиях записывать, а в том, что происходит дальше, и как эти требований встроены в процесс.
Вот я и сказал в первом сообщении, что упирается. Ведь как не печатал принтер он так и не будет печатать, проблема останется.
Про врачей всё зависит от региона, и это у вас может полуавтоматически у меня в глубинке всё по старинке. И вот так получилось, что я отработал в медицине с информационными системами и знаю как работает. Но движется, надеюсь со временем всё наладится.
В ITIL одних ролей 26 штук, это больше чем людей в некоторых организациях =)
Всякие change manager, risk manager, facility manager, security manager, deployment manager, service desk manager, finance manager, incident manager, relationships manager, их там целая толпа.
Хотя может быть для организаций уровня газпрома можно просто взять и внедрить.
Всякие change manager, risk manager, facility manager, security manager, deployment manager, service desk manager, finance manager, incident manager, relationships manager, их там целая толпа.
Хотя может быть для организаций уровня газпрома можно просто взять и внедрить.
ITIL часто используют аутсорсинговые компании.
В организациях уровня Газпрома никогда и ничего нельзя
Что касается ITIL/ITSM — подход к внедрению этих практик всегда определяется исходя из специфики конкретной организации. Нельзя просто взять и внедрить все рекомендации ITIL и сделать все по Cobit. Всегда должна быть взаимная адаптация рекомендаций (ITIL) или стандартов (Cobit) и текущей деятельности компании.
просто взять и внедрить!!!
Что касается ITIL/ITSM — подход к внедрению этих практик всегда определяется исходя из специфики конкретной организации. Нельзя просто взять и внедрить все рекомендации ITIL и сделать все по Cobit. Всегда должна быть взаимная адаптация рекомендаций (ITIL) или стандартов (Cobit) и текущей деятельности компании.
Роли могут сочетаться, но сути это не меняет, — ITIL это методология прогона умняка при собеседовании на должность CIO.
Звучит как реклама новой модной религии.
Если «сервисы» заменить на «услуги», а «доставляет ценности» — на «приносит пользу», то становится намного понятнее, имхо.
И на картинке книг пять, а написали вы про четыре, забыв про самую главную — Service Strategy.
И на картинке книг пять, а написали вы про четыре, забыв про самую главную — Service Strategy.
В статье рассказано какой классный ITIL и что он умеет, но не написано ничего о том что это такое. Да же определния нет, расшифровки абревиатуры, краткой аннотации. Одна вода какая то, извините. Я толком ничего не понял что это и зачем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ITIL для разработчиков