❶ Про ошибку. Цитата: «Отслеживать физическую доступность мониторинга может другая…».
Первый абзац и сразу грубейшая ошибка — не физическая, а логическую доступность. Или у Вас РЛС определяющая азимут и дистанцию до объекта?
Проверка: задайте себе вопрос, каким методом и каким средством идентифицируется физическое местоположение системы мониторинга?
❷Про глупость. Цитата: «Клиент имеет доступ к метрикам по хостам…», «Беглый анализ показывает, что метрики собираются, а триггеров-то для них…».
→ Во первых, в системе мониторинга по определению не может быть метрик, поскольку метрика это «мера», «размер». Это базовые знания. В мониторинге датчики. В датчиках сенсоры, т.е. чувствительная часть датчика предназначенная для регистрации. Датчики могут быть физические или логические. Мониторинг может быть параметрический и состояния.
→ Во вторых, также как нет метрик, нет и триггеров для метрик. Триггер это устройство имеющее только 2 устойчивых состояния.
❸ Про мониторинг. Цитата: «Система мониторинга, а вы уверены, что она работает?».
А Вы уверены, что у Вас система мониторинга? Уверены, что это не система диагностики автоматизированная скриптами? Изучите назначение систем мониторинга. Структуру и состав функций таких АС, после чего сравните со своей системой. Впрочем, вряд ли это возможно, учитывая контекст статьи. У Вас, скорее всего, отсутствует документация и автоматизируете Вы скриптами, считая, что это программирование.
Стиль изложения понравился -позитивно. Методичность реализация не понравилась. Это на уровне ощущений. Теперь по порядку.
❶ Про мотивацию, цитата: «…медленно, но верно движемся к разработке системы поощрения и мотивации…»
Вы заблуждаетесь. Вы пытались реализовать не мотивацию, а стимуляцию, причём в большей степени материальную внешнюю, поскольку стимуляция входит в состав мотивации (партитивная связь).
→ Геройство одного работника, есть результат, как бы это выразиться полит корректно, промаха другого работника. Другими словами, если желаете создавать систему мотивации, то учитывайте каждую её составляющую: положительная/отрицательная, внешняя/внутренняя, материальная/духовная. Учитывая тот факт, что в статье не указано выполнение анализа предшествующего созданию системы – реализовывали субъективно, опираясь на мнения, а не знания. Аналитическую записку не писали? Так?
Выражаясь обывательски, стимулировать хорошо ослика, а человека нужно мотивировать…
❷ Про цель, цитата: «Цель системы мотивации для компании – повышение внутренней эффективности. Цель системы мотивации для каждого из вас – получить возможность объективной оценки своего вклада …»
У одной системы не может быть две цели, исходя их понятий «система» и «цель», тем более, разнонаправленные.
Заявленная Вами цель не соответствует подлинной цели системы мотивации, исходя её определения и назначения.
Оценка вклада выполняется в системе оценки персонала. В совокупности, это система оценки и мотивации персонала.
Кстати, исходя из контекста, объективной оценки у Вас не может быть, поскольку не формализовано описание должностей/ролей (зависит от реализуемых методов планирования и организации). Это как минимум. Ещё нужны модели мотивации. Мониторинг состояния. Формализованная постановка задач, а не по понятиям. => выдаёте желаемое за действительное.
Пример: работник занимал должность Х и развивался, в результате чего его компетентность начала превышать требования к должности. Премии за превышение? Логично? Работник переведён на более сложную, с т.з. сферы деятельности, должность Y – недостаток компетентности. Вполне возможно? При всех прочих равных условиях. Это интенсивный метод. Есть ещё экстенсивный…
❸ Про объективность, цитата: «технической поддержки с системой заявок меня устраивает и, что не менее важно, система мотивации по работе с системой заявок устраивает самих специалистов. Конечно, есть еще, что полировать и улучшать…»
Ещё одно подтверждение отсутствия у Вас объективной оценки. Вы создали себе иллюзию реализованной системы оценки и мотивации персонала, причина которой является опора на мнение, т.е. полноценный субъективизм выдаваемый за объективность. Осмыслите контекст Вашего предложения — «меня устраивает», «специалистов устраивает». И другой вариант – верифицируется соответствие знаний присущих работнику и требований предъявленных должности, с фактическим результатом работы. Различия осознаём? Где ощущения, а где обоснование?
И ещё: бизнес-инцидент и инфраструктурный-инцидент не одно и тоже (если с позиции ценностей ITIL). Это про, цитата: «Соответственно, заявка висит в ожидании удобного момента для проведения работ…». Другими словами, рассматривая связь система-подсистема.
█ На последок, цитата: «Правда, опыт показал, что с повышением качества работы информационных систем в компаниях, число обращений в техподдержку не меняется…». 1) ИС есть техническое обеспечение 2) Вы пишите про обращения пользователей => Качество тех.системы будет совокупность характеристик относящихся к способности удовлетворить установленные и предполагаемые потребности пользователей. Пользователь может обратиться в случае снижения качества услуги. А Вы не думали, что пользователь может обратиться из-за низкого уровня собственной готовности, а не снижения готовности ИС, т.е. рассматривать обращение с т.з. доступности объект-субъект? При прочих равных условиях, повышение качества работу ИС приведёт к снижению количества обращений в этой ИС. Кстати, методически верно рассматривать АС, а не ИС, поскольку АС включает и кадровое обеспечение, а Вы, исключая кадровое, делаете ошибочные умозаключения.
Деятельность работника может характеризоваться:
низкой результативностью, но высокой эффективностью – подметать пол зубной щёткой (что дали тем и работает, и это не вина работника).
высокой результативностью, но низкой эффективностью – (сами сформулируйте пример).
Формировать измерения деятельности следует исходя из minimum/optimum/maximum и соотносить к ним fact. Почему превышения максимума негативно, понятно? Как это связано с методами интенсивного и экстенсивного производства, понятно?
Информация должна быть представлена в виде формализованного (аналитик, руководитель) и обобщённого (упрощённого) контекста (рядовые работники).
Название статьи не соответствует контексту. См. хотя бы «как». Цитата «измерять различные метрики» => откройте определение термина «метрика». Сопоставьте с фразой. Что получается? Вам нужны показатели деятельности. Параметры, измерения, величины. Отчётность (первичная, сводная)… Не используйте словоблудие из маркетинговых статеек.
Осторожно: Выше описанное будет мешать продуцированию квази-деятельности.
PS: На надо уподобляться работникам вида «Моё мнение объективно, потому что верно, т.к. я руководитель».
❶ Про непонимание, цитата: «Здесь речь идет именно о календарном плане проекта, который можно использовать для 2 вещей…».
Диаграмма Гантта, используемая для визуализации плана управления проектом и плана проекта, использует привязки к датам в календаре – календарное планирование. Вы использовали термин «календарный план» для подмены понятий «план управления проектом» и «план проекта», с целью ухода о использования формализованных терминов.
Вы не смогли или не захотели осознать предоставленной информации.
❷ Про описание ролей, цитата: «По ролям — дано краткое описание, которое я встречал в компаниях…».
Ваш контекст описания ролей и использование описания увиденного в других компаниях, подтверждают, что описания нет.
На самом деле, описание делиться исходя из:
1. Функционального управление – должность.
2. Процессного управления – роль.
Состав характеристического описания идентичен и рассматривается с правовой т.з. Задайте себе вопрос, где у Вас описаны, хотя бы полномочия? А права? А ответственность? У Вас нет описания ролей и Вы находились в состоянии неосознанного незнания. Имеющиеся же описания – подделка.
❸ Типичная проблема псевдо-проекта. Интегратор делал то, что умеет, исходя из кадрового и технического обеспечения, а не то, что нужно заказчику. Проверить элементарно – ознакомьтесь с целью, задачами и рисками проекта – они тоже подделки. В тексте Вашей статьи так же упоминаются цель, задачи и риски, но контекста, соответствующего эти понятиям, нет.
Как проверить? Изучите состав и назначение цели, задачи, риска. Сравните с контекстом «Интеграторов».
Тоже и с «добровольностью ТЗ» — продуцирование квази-деятельности попутно убалтывая заказчика покупать уже имеющиеся тех.решения. ТЗ ведь обычно подрядчик пишет? Не так ли?
И в завершении, немного о демагогии, цитата: «Про РП — в корне не согласен, но спорить думаю тут бессмысленно — с тем же успехом можем спорить о том, какой из цветов лучше — красный или синий.»
Прямое и бездоказательное утверждение с апелляцией к ассоциативной связи в виде сравнения цветов, как контр-аргумент, но без указания объектов сравнения – классический приём демагогии.
Удачи.
PS: Смотреть текст не надо, текст надо читать и уметь осознавать.
❶ Про надёжность, цитата: «Что значит “надежный”? Когда дело доходит до управления сервисами, слово “надежный” не имеет смысла само по себе…».
С позиции автора, похоже, для АС не имеет смыла готовность, доступность, безотказность и т.д. Не имеет значения состав АС, т.е. техническое, организационное, кадровое обеспечение…
Типичная формулировка гуманитария относительно технического вопроса.
❷ Про понимание, цитата: «Каждый инфраструктурный проект (я надеюсь!) начинается с потребности бизнеса, и наша задача — улучшить надежность и безопасность существующей системы планирования…».
Явные проблемы применимостью терминологии. Что бы осознать этот «винегрет», следует изучить понятия инфраструктура, бизнес, задача, система, планирование. Для усиления стиля, могу рекомендовать применение таких маркетинговых формулировок, как:
«интерполяция меж-тектурного эко-ландшафта в архитектуре ИТ»
«имплементация теологических методов в продуцировании тасков ИТ»
«парадигма сентенций DevOps с т.з. Оруэлла» т.д.
К списку необходимости изучения, можно добавить термины: стратегический, тактический, оперативный. С ними у автора тоже проблемы (см, цитата: «Стратегия 0: Поговорить с другими компаниями…», «Стратегия 1: Прочитать код…» и т.д.) ⟾ в тексте статьи заменить «стратегия» на «операция».
❸ Тему DevOps даже не рассматриваю – и так понятно маркетинговое словоблудие про «вот эти ножницы DevOps», а «вот те ножницы Agile». Инженер с систематизированными знаниями сразу скажет: «назовите присущие характеристики различающие ножницы на Agile и DevOps». Маркетолог же, сразу начнёт генерировать поток словоблудия про философию ножниц и т.д., т.е. апеллировать к искусственно присвоенным характеристикам, имеющим место исключительно в мозгу маркетолога. Особо «одарённый», маркетолог, поставит соответствующую наклейку. На ножницы…
Ну что ж, эффективность и эффектность не одно и тоже…
По порядку.
❶ Про название статьи, цитата: «Планируем проект внедрения и доработки информационной системы в MS Project — быстро и красиво».
→ Планирование, есть намеченный порядок и последовательность действий по достижению поставленной цели. Это кратко, т.е. не вдаваясь в подробности.
Вот Вам примеры про порядок, по аналогии, чтобы ощутить различия:
Порядок (правильный):
Зайти в кабинку санузла.
Снять мешающую одежду.
Выполнить акт дефекации.
Оторвать нужное количество туалетной бумаги.
Использовать туалетную бумагу.
Одень снятую ранее одежду.
Выйти из кабинки санузла.
Порядок (ошибочный)
Зайти в кабинку санузла.
Выполнить акт дефекации.
Снять мешающую одежду.
Оторвать нужное количество туалетной бумаги.
Использовать туалетную бумагу.
Одень снятую ранее одежду.
Выйти из кабинки санузла.
Беспорядок:
Зайти в кабинку санузла. акт дефекации.
Выполнить снятую ранее одежду.
санузла. Снять Оторвать н
бумаги. мешающую одежду.
Использовать из кабинки туалетную бумагу.
Одень ужное кличество туалетной
Выйти
В описываемом проекте цель не поставлена, на задачи не декомпозирована, риски не идентифицированы, но успешно создаётся быстрый и красивый план в MS Project – классическое продуцирование квази-деятельности, т.е. «даёшь внедрёж».
❷ Про заблуждения, цитата: «Руководитель проекта — менеджер, с хорошей технической экспертизой и навыками бизнес- анализа…».
Менеджер с технической экспертизой, это оксюморон. Или в проекте участвовал такой уникум, как Королев С.П.?
Навыков бизнес-анализа не может быть по определению, поскольку навыки есть частный случай умений, в отличие от последних, характеризуемые неосознанностью исполнения. Например, навык вождения или навык устной речи.
Ещё раз:
1. Умение – характеризуется осознанностью исполнения.
2. Навык – характеризуется неосознанностью исполнения.
Проверка – попробуйте двигаться, смотря глазами через призмы переворачивающие изображение.
По ролям оценки дать не могу, т.к. в статье недостаточно их описания, но на основе имеющегося контекста, смею предположить, что определение и состав ролей автор не знает. Либо, что маловероятно, не успел описать, но это не подтверждается, поскольку отсутствует методическое описание – либо от общего к частному, либо от частного к общему.
Ну и далее, как обычно, устава проекта нет, отчётность отсутствует, роли не формализованы, да ещё и перепутаны как винегрет, управление по понятиям, кто громче орёт тот и прав и т.д…
❸ Про фантазии.
Состав протокола и правил его управления не знаете (очевидно из контекста). Рекомендую ознакомиться с формами краткого и полного протокола, а также методами оформления и ознакомления с ними.
Техническое задание не проектируется, поскольку предшествует ему, т.к. является выделенной стадией при создании системы.
У Вас априори не могло быть руководителя проекта, поскольку руководитель есть штатный работник назначенный на должность, на которого возложены функции управления коллективом… формально регламентированной компетенцией и т.д. Наиболее вероятно, у Вас было применено не функциональное, а процессное управление по матричному методу, т.е. выделение не формального лидера и т.д.
Документ ПМИ не может создаваться на основе тест-кейсов, это не логично, поскольку нарушается причинно-следственная связь, или, другими, словами, первичен ПМИ, а не тест-кейс. Про тест-кейс вообще отдельный разговор.
█ Вам следует формализовать деятельность, прежде чем приступить к реализации, т.е. планирование и организация деятельности и т.д…
Необходимо разделять планирование проекта от планирования управления проектом – есть назначение проекта, а есть назначение продукта проекта, что не одно и тоже.
Что же касается файла MS Project, то оформлен он красиво и может использоваться в качестве шаблона, но на этом всё.
По поводу колёс и палок. Контекст Вашего комментария соответствует принципу аналогии и ассоциативной связи, что снижает точность и достоверность оценки. Контекст моего комментария предельно ясен – ошибочность технических и организационных решений. Применение продуктов не в соответствие с их назначением. Если оценивать с позиции велосипеда, то последний предназначен для увеличения скорости перемещения человека. Используемая в ТУТУ.РУ АС управляет объектом типа электронный документ. Потребность состояла в увеличении скорости перемещения инцидентов? Это риторический вопрос. Переход от объективных оценок к субъективным приводит к искажению информации. Каждая последующая субъективная оценка вносит дополнительное искажение.
Про потребность. Предполагаю, что находясь на этапе неосознанного незнания, вполне себе можно мыслить, что потребность закрыта, но от мнения человека объективная реальность не зависит… Вспоминается рассказ про обезьян, банан и холодную воду…
Про покупку. Покупать? А обоснование есть? У работников есть аналитическая записка по выбору ПО для автоматизации? На основании моего опыта, сомневаюсь. Предполагаю, что выбор был по ощущениям «как уже те ребята сделали». Впрочем, проверить ведь не сложно. А нужно? Например, руководителю ИТ? И снова – каждое ошибочное решение вносить дополнительно искажение, усугубляя состояние…
Про статью. Что бы создать предметную статью, содержащую знания, нужна предметная постановка цели. Интересы (политические, экономические…). Далее, естественно, с декомпозицией на задачи и т.д. Входящие данные, типа «Сделать хорошо, чтобы все выбросили в окно» (утрирую), для анализа не подходят.
PS: Собаку есть не надо =), надо демонстрировать компетентность. Желательно на бумаге, поскольку на ней видна вся глупость человеческая. К тому же, человеку нельзя помочь, пока он этого сам не захочет, т.е. не перейдёт в состояние осознанного незнания и готовности к действиям.
❶ Про ложное направление эволюции, цитата: «От педагогики к андрагогике, от андрагогики к хьютагогике».
Не «андрагогика», а «педагогика для взрослых». Не «хьютагогике», а «самообучение».
→Эволюция (кратко) – необратимые процессы, протекающие в живой и неживой природе. Преимущественно необратимые.
→Слова заимствуются при условии, что отсутствует эквивалентное слово в заимствующем языке.
→Термин «хьютагогика» не более чем недомаркетинг, т.к. присутствует только в маркетинговых брошюрках и статейках.
Как очевидно из выше написанного, имеет место не эволюция «педагогика» -> «андрагогика» -> «хьютагогике», а банальная комбинация, т.е. «самообучение взрослого» и т.д.
⌂Вывод: глупость, т.е. либо нежелание либо неумение автора, осознать естественных процессов или явлений. Предполагаю, скорее нежелание, мотивом которой является маркетинг продвижения продукта или услуги, на что указывает контекст и принадлежность автора блогу компании.
❷ Про использование псевдо-научных терминов в обывательском контексте, цитата: «…В чем же отличие подхода к обучению в рамках андрагогики? Самое главное – у взрослых слушателей имеется накопленный багаж, опыт…».
У обучаемых людей по определению нет багажа, а есть знания и умения.
Выражаясь более точно: в педагогике учитываются интеллект, знания, умения и навыки обучаемых.
⌂Вывод: глупость.
❸ Про преподавателей. Цитата: «В наш учебный центр «Сетевая Академия ЛАНИТ» мы всегда с опаской берем на работу уже сложившихся учителей школ и преподавателей вузовов. Не каждому из них удается перебороть свои привычные взгляды на процесс обучения и перестроиться.»
Да, вполне очевидно, что не каждый преподаватель может побороть себя и заняться словоблудием вида:
1. Не самообучение взрослых, а хьютагогическая андрогеника.
2. Не присущие знания и умения, а имеющиеся багаж и опыт.
3. Не производитель, а вендор.
4. И что то там «фасилитатор» — простите, но точного и достоверного определения найти не удалось.
█ИТОГО: Если обращаться к современному жанру, то вспоминается реплика из фильма «О чём говорят мужчины», цитата: «А гренка в нашем ресторане называется croûton. Это точно такой же поджаренный кусочек хлеба, но гренка не может стоить 8 долларов, а croûton — может».
Самое время начать рекламу новых платных курсов, но не по системному администрированию методом самообучения, а DevOps блоттингом хьютагогической андрагогики.
%-)….
Хотелось бы выразиться экспрессивно, но, думаю, каждый осознавший глупость статьи, найдёт близкую себе по душе формулировку.
❶ Про название статьи, цитата: «Как найти хорошего маркетолога?».
→ Разница – «что» есть обобщённое описание исполнения, а «как», это разъяснение о методах и средствах выполнения.
В заголовке написано «как», что расходиться с контекстом статьи, суть которой «что».
Меняем название статьи с «Как найти хорошего маркетолога?».
На «Что делать для поиска хорошего маркетолога?».
❷ Про хорошего маркетолога.
В статье отсутствует формулировка, о назначении и составе «хороший маркетолог».
Есть только обобщённое описание не имеющее отношения к основной сути в деятельности маркетолога – продать товар применяя полуправду, лож и дезинформацию.
Описание сферы деятельности должности начинается с постановки цели, функций и задач.
→ Маркетолог, в первую очередь, должен владеть двусмысленностью, поскольку в ней заключена сила манипулирования потребителем.
Другими словами и более точно, владеть софистикой и демагогией, поскольку именно они позволяют убеждать оппонента, не преследуя своей целью объективность, истинность, точность, достоверность. Ведь нам нужно продать товар или услуг, а не предоставлять потребителю на анализ её присущие характеристики? Не так ли?
Основная функция хорошего маркетолога – умение убеждать потребителя приобретать продукт и услугу, выгодную для продавца, пусть даже невыгодную для потребителя.
Также следует описать функции опорные и качества.
Одной из опорных будет аналитическая, поскольку именно она обеспечивает маркетолога информацией. Кстати, аналитиком маркетологу быть не обязательно*, если не сказать нежелательно, поскольку маркетолог оперирует чувствами и эмоциями, тогда как аналитик объектами и действиями, анализируя и синтезируя их. Далее функции следует декомпозировать на задачи.
❸ Про описание вакансии.
Выбрасываем обывательские формулировки вида «типаж человека» и т.д. Воздерживаемся от словоблудия, поскольку это нужно в маркетинге, а не при решении конкретной прикладной задачи – формирование требований к вакансии.
Описания должно быть, как минимум два:
1. Академическое – требования к компетентности и компетенции.
2. Обывательская – обобщённые формулировки методом композиции из академического описания.
█ Учитывая вышеописанное, по отношению к статье, можно утверждать, что кандидатов Вы ищете по ощущениям, т.е. на основе мнения, нежели по осознаю, т.е. сформированному знанию. Это ни плохо, ни хорошо – это, скорее всего, факт. Главное, не заблуждаться относительно фактически используемых методов, т.е не выдавать желаемое за действительное.
А так, в целом, статья лёгкая в прочтении, но информативно мало значащая, хотя прочитал с интересом.
*Утверждение основывается на тезисе, что маркетинг есть совокупность действий для убеждения потребителя приобрести товар или услугу именно нашей фирмы.
Ваше предложение состоит исключительно из сущностных квантификаторов и относительных ссылок, но без указания точки отсчёта, т.е. не представляет информационной ценности — не информативно.
Пример: те или иные, всякие разные, довольно много, различные.
Обращение «месье» неуместно.
Желаете дискуссии, извольте обосновать (см.определение) позицию в явной форме. Я готов. Риторика и демагогия меня не интересует.
❶ Про эксплуатацию и support, цитата: «Разбором инцидентов в нашей компании занимается отдел эксплуатации (или, проще, support).».
→Эксплуатация, это практическое использование (по назначению) производственных ресурсов для получения выгоды. В эксплуатацию, в том числе, входит и поддержка, но не входит разработка.
→Support – это только поддержание технического обеспечения в исправном состоянии, т.е. часть, но никак не эксплуатация в целом.
Чтобы утверждать, что занимаетесь эксплуатацией, нужно непосредственно реализовывать коммерческую выгоду. Вы ведь коммерческая организация? В целом? А сами, как работник, входите в состав ИТ подразделения, как часть организации? Смею утверждать, что речь, скорее всего, идёт об опорном процессе, поддерживающем основные (с западной т.з. основные = бизнес-процессы). Всего различают процессы: основные, опорные, качества. Кстати, поддержка (по Вашему Support) может быть бизнес процессом, а может и не быть им.
❷ Про инциденты, ЧП и т.д., цитата: «Инцидент (или сбой, ЧП) — это некая критическая (обычно массовая) проблема, которая существенно снижает доступность, корректность, эффективность или надежность бизнес-функционала или инфраструктурных систем.».
→ Инцидент, не является проблемой по определению. Упрощённо, в обывательской формулировке, инцидент это «что то не работает как нужно», но можно исправить собственными ресурсами, а проблема, это «невозможность восстановить собственными ресурсами» — нет знаний, нет оборудования и т.д… И уж тем более инцидент не является ЧП. Под ЧП Вы подразумевали чрезвычайное происшествие? Тогда потрудитесь изучить определение термина ЧП – непредвиденное событие повлекшее гибель людей, порчу имущества…
Шедеврально, цитата: «надежность бизнес-функционала или инфраструктурных систем». Попробуйте изучить понятия «надёжность» (собирательный термин), «бизнес», «функция» (как полезная работа), «инфраструктура» (есть ещё 2 структуры). Вас ждёт большой сюрприз, при осознании Вашего контекста…
Простите, но, в данном случае, как нельзя кстати, подходит выражение «Всё смешалось в доме Облонских…».
❸Про цели, цитата: «В рамках процесса управления инцидентами мы ставим перед собой следующие основные цели: 1.Как можно быстрее восстановить работоспособность наших систем …».
Основные? Значит есть дополнительные? Прелестно (сарказм).
→ Заявленный Вами нумерованный список, не является целями по определению, поскольку ни один из пунктов нельзя ни измерить ни достичь. Изучите, хотя бы, такие модные в последние 15 лет западные принципы S.M.A.R.T.
У процесса должна быть одна цель (goal, а не target (мишень)), которую следует декомпозировать на низ лежащие уровни. Или у Вас функция в составе процесса? Это не одно и тоже.
Пример цели: модернизировать техническое обеспечение корпоративной сети между точками A и B в узлах 1,2,3,4 имеющимися ресурсами.
Дополните цель рамками и допущениями.
Декомпозируйте на функции, задачи.
❹ Про мониторинг, цитата: «У нас была самописная система мониторинга, которая подразумевала самостоятельную подписку сотрудников на сообщения о проблемах…»
→ Мониторинг. Наблюдение и регистрация данных с неразрывно примыкающими интервалами с незначительно меняющимися данными. Различают мониторинг параметрический и состояния. Важна визуализация и оповещение… Важна интерпретация показателей.
Учитывая контекст, смею предположить, что у Вас не было и нет системы мониторинга. Скорее всего, речь идёт о недо-системе диагностики и журналировании событий, успешно выдаваемой руководству, как система мониторинга (см. определения «система», «диагностика», «журналирование», «мониторинг»).
Учитывая в целом контекст «статьи» и самостоятельную подписку, у Вас отсутствует формальная структура как часть организационного обеспечения.
Мониторинг по определению не может сообщать о проблемах (см.определение).
❺ Про фазы инцидентов, цитата «Разделили работу с инцидентами на две фазы — активную и ретроспективную».
Ативная-Пассивная. Ретроспективная-Перспективная. Вы хоть понимаете назначение применяемых терминов? (это риторический вопрос).
Начните, хотя бы, с русского языка – прошлое, настоящее, будущее.
Воздержитесь от применения таких терминов, как «превентивный» и т.д., если не понимаете их назначения.
█ Вы не только не осознаёте используемые термины, но ещё применяете жаргонизмы и псевдо-терминологию.
Создаёте автоматизированные системы по заведомо ложным ценностям.
В общем, судя по Вашей статье, как пишите, так организуете и реализовываете – беспорядок, ошибки, подмена понятий, дезорганизация и т.д…
Прочитав, скорее всего подумаете – но ведь у нас всё работает. Да, скажу, машина на 3-х колёсах тоже работает… т.е. с т.з. она неисправна, но работоспособна… какое-то время… в какой-то мере…
Как то так.
PS: Каждый работник компании не в состоянии поставить задачу, тем более, техническому работнику, поскольку нужно обладать не только техническими знаниями, но и умением ставить задачи как таковые (см. состав задачи), что подтверждается, как правило, наличием у них только потребности.
PSS: JIRA есть СОО (BTS) – Система Отслеживания Ошибок (bug tracking system), а не система отслеживания инцидентов. BTS нужна для ЖЦ объекта во время «Разработка» (Development), а не «Сопровождение» (Maintenance). Тем более, BTS не является системой управления документооборотом, что подтверждается анализом ЖЦ и составом объектов управления. Или, по другому, применяется не по назначению. Характеризуется эта ситуация неумением или невозможностью субъекта осознать естественных явлений или объектов, что есть по определению глупость. Это с академической т.з.
С обывательской, это как забивать гвозди микроскопом, потому что он тяжёлый и, таки, забивает. Однако есть плюс – продуцирование квази-деятельности в которой все заняты…
Удачи.
Нашёл данную статью весьма интересной. Не могу не высказаться. По порядку.
❶ Про мнение, цитата: «Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. …».
→ Инцидент характеризуется временем, местом и сутью, т.е. другими словами когда, где и с чем произошло, о чём не пишет ITIL. На самом деле, изменение одной из 3-х составляющих приведёт к появлению нового инцидента, а не повторению предыдущего. Мера же воздействия инцидента на пользователей, является отдельным аспектом не оказывающим влияния на характеристики самого инцидента (метод обратной связи). Это надо уметь осознать.
→ Проблема. Характеризуется отсутствием алгоритма её устранения, основанной на недостатке имеющихся знаний и технического обеспечения. Это упрощённо.
Важно: Привлекая ресурсы извне, устраняя недостатки в ресурсах, т.е. нечто обладающее возможностью разрешить проблему, последняя преобразуется в задачу:
Известное начальное состояние (дано).
Известное конечное состояние (найти)
Алгоритм достижения от начального к конечному состоянию (решение).
Учитывая вышеописанное, лишний раз убеждаешься в том, что мнение присутствует каждый раз, когда отсутствует знание…
❷ Про признак проблемы, цитата: ”профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему»…”
→ Техника может быть:
Неисправна, но работоспособна (например, неисправность турбины в дизельном ДВС, что позволяет медленно, но ехать).
Неисправна и не работоспособна (например, заклинивший ДВС).
Исправна, но неработоспособна (например, нет топлива в автомобиле).
Рассмотрим на примере единственного неисправного и неработоспособного принтера в отделе продаж:
У компании №1 нет тех.персонала имеющего компетентность по ремонту оргтехники – проблема.
У компании №2 есть тех.персонал имеющий компетентность по ремонту оргтехники – инцидент.
Важно: проблема понятие относительное. Для пользователя, неисправность это проблема, а для техника — инцидент (см. определение п.1).
Первый признак проблемы это не «почему», а невозможность обеспечить работоспособность технического обеспечения собственными ресурсами (это есть критерий). И неважно, известно «почему», т.е. идентифицированное место и причина, или нет, поскольку причина выявляется только по результату диагностики (выявление места и причины неисправности). Данная ошибка основана на классическом обобщение, что приводит к снижению точности и достоверности информации. Чтобы возникло понимание, вольно приравняю «Почему» к декомпозированной формулировке «невозможность обеспечить работоспособность технического обеспечения собственными ресурсами».
Да, методическая формулировка сложнее для понимания, в отличие от обывательской формулировки выраженной в виде мнения, но зато позволяет идентифицировать наличие проблемы на основе критерия, а не ощущения. Выяснять же, к какой именно науке относиться звание профессора Росс Вайз, не имеет смысла, поскольку звание, само по себе, не является доказательством. Также может иметь место ошибка репортёра/редактора/ переводчика.
❸ Про примеры, цитата: «Вы едете на машине, и у неё лопнуло колесо…». Следствием выбранной автором ошибочной системы ценностей, является ложность приведённых им примеров.
Исправим заблуждения учитывая мои п.п.1-2.
Изначально у автора, цитата: «Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.»
Рассматривать следует как систему, надсистему, так и подсистему, причём в совокупности прошлое, настоящее и будущее.
Утверждение автора ложно, поскольку запасное колесо не является частью системы автомобиля до момента установки в него (интеграция), а также перестает быть частью системы после снятия (см. определение терминов). Не являясь частью системы «автомобиль», колесо перестаёт выполнять полезную работу, в результате чего к нему не применимо понятие инцидент или проблема, зато применимы понятия неисправна и работоспособна, что методически верно с тех. т.з…
Итого, на примерах:
В машине не оказалось запасного колеса – невозможно устранить собственными ресурсами => проблема, т.к. отсутствует тех.обеспечение.
В машине нет запасного колеса, но неисправное колесо RunFlat => инцидент, т.к. тех.система неисправна, но работоспособна.
3. В машине есть запасное колесо, но водитель девушка и не в состоянии его заменить => проблема в части анатомии (сила), компетентности (частный случай навык) и т.д..
В машине есть запасное колесо, домкрат и у водителя достаточно знаний и умений => инцидент, т.к. оперативно устраняется.
И т.д.
На основании вышеизложенного могу утверждать, что имеет место классический вариант подмены знания мнением, с последующим построением ложных умозаключений и приведением соответствующих примеров. Также следует учитывать, что ITIL описывает организационное обеспечение, причём частично, а применяется к техническому обеспечению, что заведомо ложно.
Если проще и по методу аналогии, то с таким же успехом можно утверждать, что бревно это карандаш, потому что оно деревянное, хотя это не так, поскольку назначение и функции карандаша и бревна отличаются, и это очевидно при первом же осмыслении.
█ Вместо заключения. Проблема (см.определение) таких документов как ITIL состоит в их гуманитарном контексте и позиционировании как методологии по техническим вопросам, хотя таковыми они не являются по своему содержанию. Проблема пользователей, использующих такие документы, заключается в невозможности осознания.
Количество не значит качество — массовый выброс подобных статей формирует ложную систему ценностей…
Из выше описанного следует делать вывод, что первичное значение имеет знание и осознание в совокупности с обоснованием (можно доказательством), а не вера в некое мнение. Следует не только выражаться в виде утверждений, но и трудится присовокуплять к ним подтверждения, что по своему составу уже будет уже обоснованием, хотя и не доказательством.
Что касается полезной работы Интеграторов, внедряющих автоматизацию по «таким» системам ценностей, в результате будем получать классический «даёшь внедрёж».
Желаю всем включать мозг и знания, а не «сердце» и мнение, поскольку этим широко пользуются маркетологи.
PS: Попугая можно научить говорить E=mc^2, однако для него это будет всего лишь совокупность звуков, а не знание как таковое.
PSS: Не всё заграничное хорошо. В России тоже достаточно накопленных знаний, надо лишь уметь их найти и осознать, а не гонятся за модными маркетинговыми выбросами типа DevOps и т.д…
❶ Про статью. Вместо того чтобы использовать аналитический метод и сделать сравнительную таблицу по структуре и функциям «разработка» и «программирование», автор предпочёл формировать своё мнение на основе домыслов.
❷ Про термины. Да, действительно, термины меняются со временем, например в результате глупости оратора/писателя или применения им демагогии.
❸ Про комментарии. Информационно-ценные:
1. geher 01.11.17 в 13:21.
2. fatronix 02.11.17 в 10:35.
3. lxsmkv 01.11.17 в 21:30.
Остальные либо содержат грубые аналогии и обывательские формулировки, либо, как точно выразился fatronix 02.11.17 в 10:35, словоблудие.
Первый абзац и сразу грубейшая ошибка — не физическая, а логическую доступность. Или у Вас РЛС определяющая азимут и дистанцию до объекта?
Проверка: задайте себе вопрос, каким методом и каким средством идентифицируется физическое местоположение системы мониторинга?
❷Про глупость. Цитата: «Клиент имеет доступ к метрикам по хостам…», «Беглый анализ показывает, что метрики собираются, а триггеров-то для них…».
→ Во первых, в системе мониторинга по определению не может быть метрик, поскольку метрика это «мера», «размер». Это базовые знания. В мониторинге датчики. В датчиках сенсоры, т.е. чувствительная часть датчика предназначенная для регистрации. Датчики могут быть физические или логические. Мониторинг может быть параметрический и состояния.
→ Во вторых, также как нет метрик, нет и триггеров для метрик. Триггер это устройство имеющее только 2 устойчивых состояния.
❸ Про мониторинг. Цитата: «Система мониторинга, а вы уверены, что она работает?».
А Вы уверены, что у Вас система мониторинга? Уверены, что это не система диагностики автоматизированная скриптами? Изучите назначение систем мониторинга. Структуру и состав функций таких АС, после чего сравните со своей системой. Впрочем, вряд ли это возможно, учитывая контекст статьи. У Вас, скорее всего, отсутствует документация и автоматизируете Вы скриптами, считая, что это программирование.
❶ Про мотивацию, цитата: «…медленно, но верно движемся к разработке системы поощрения и мотивации…»
Вы заблуждаетесь. Вы пытались реализовать не мотивацию, а стимуляцию, причём в большей степени материальную внешнюю, поскольку стимуляция входит в состав мотивации (партитивная связь).
→ Геройство одного работника, есть результат, как бы это выразиться полит корректно, промаха другого работника. Другими словами, если желаете создавать систему мотивации, то учитывайте каждую её составляющую: положительная/отрицательная, внешняя/внутренняя, материальная/духовная. Учитывая тот факт, что в статье не указано выполнение анализа предшествующего созданию системы – реализовывали субъективно, опираясь на мнения, а не знания. Аналитическую записку не писали? Так?
Выражаясь обывательски, стимулировать хорошо ослика, а человека нужно мотивировать…
❷ Про цель, цитата: «Цель системы мотивации для компании – повышение внутренней эффективности. Цель системы мотивации для каждого из вас – получить возможность объективной оценки своего вклада …»
У одной системы не может быть две цели, исходя их понятий «система» и «цель», тем более, разнонаправленные.
Заявленная Вами цель не соответствует подлинной цели системы мотивации, исходя её определения и назначения.
Оценка вклада выполняется в системе оценки персонала. В совокупности, это система оценки и мотивации персонала.
Кстати, исходя из контекста, объективной оценки у Вас не может быть, поскольку не формализовано описание должностей/ролей (зависит от реализуемых методов планирования и организации). Это как минимум. Ещё нужны модели мотивации. Мониторинг состояния. Формализованная постановка задач, а не по понятиям. => выдаёте желаемое за действительное.
Пример: работник занимал должность Х и развивался, в результате чего его компетентность начала превышать требования к должности. Премии за превышение? Логично? Работник переведён на более сложную, с т.з. сферы деятельности, должность Y – недостаток компетентности. Вполне возможно? При всех прочих равных условиях. Это интенсивный метод. Есть ещё экстенсивный…
❸ Про объективность, цитата: «технической поддержки с системой заявок меня устраивает и, что не менее важно, система мотивации по работе с системой заявок устраивает самих специалистов. Конечно, есть еще, что полировать и улучшать…»
Ещё одно подтверждение отсутствия у Вас объективной оценки. Вы создали себе иллюзию реализованной системы оценки и мотивации персонала, причина которой является опора на мнение, т.е. полноценный субъективизм выдаваемый за объективность. Осмыслите контекст Вашего предложения — «меня устраивает», «специалистов устраивает». И другой вариант – верифицируется соответствие знаний присущих работнику и требований предъявленных должности, с фактическим результатом работы. Различия осознаём? Где ощущения, а где обоснование?
И ещё: бизнес-инцидент и инфраструктурный-инцидент не одно и тоже (если с позиции ценностей ITIL). Это про, цитата: «Соответственно, заявка висит в ожидании удобного момента для проведения работ…». Другими словами, рассматривая связь система-подсистема.
█ На последок, цитата: «Правда, опыт показал, что с повышением качества работы информационных систем в компаниях, число обращений в техподдержку не меняется…». 1) ИС есть техническое обеспечение 2) Вы пишите про обращения пользователей => Качество тех.системы будет совокупность характеристик относящихся к способности удовлетворить установленные и предполагаемые потребности пользователей. Пользователь может обратиться в случае снижения качества услуги. А Вы не думали, что пользователь может обратиться из-за низкого уровня собственной готовности, а не снижения готовности ИС, т.е. рассматривать обращение с т.з. доступности объект-субъект? При прочих равных условиях, повышение качества работу ИС приведёт к снижению количества обращений в этой ИС. Кстати, методически верно рассматривать АС, а не ИС, поскольку АС включает и кадровое обеспечение, а Вы, исключая кадровое, делаете ошибочные умозаключения.
Деятельность работника может характеризоваться:
Формировать измерения деятельности следует исходя из minimum/optimum/maximum и соотносить к ним fact. Почему превышения максимума негативно, понятно? Как это связано с методами интенсивного и экстенсивного производства, понятно?
Информация должна быть представлена в виде формализованного (аналитик, руководитель) и обобщённого (упрощённого) контекста (рядовые работники).
Название статьи не соответствует контексту. См. хотя бы «как». Цитата «измерять различные метрики» => откройте определение термина «метрика». Сопоставьте с фразой. Что получается? Вам нужны показатели деятельности. Параметры, измерения, величины. Отчётность (первичная, сводная)… Не используйте словоблудие из маркетинговых статеек.
Осторожно: Выше описанное будет мешать продуцированию квази-деятельности.
PS: На надо уподобляться работникам вида «Моё мнение объективно, потому что верно, т.к. я руководитель».
Диаграмма Гантта, используемая для визуализации плана управления проектом и плана проекта, использует привязки к датам в календаре – календарное планирование. Вы использовали термин «календарный план» для подмены понятий «план управления проектом» и «план проекта», с целью ухода о использования формализованных терминов.
Вы не смогли или не захотели осознать предоставленной информации.
❷ Про описание ролей, цитата: «По ролям — дано краткое описание, которое я встречал в компаниях…».
Ваш контекст описания ролей и использование описания увиденного в других компаниях, подтверждают, что описания нет.
На самом деле, описание делиться исходя из:
1. Функционального управление – должность.
2. Процессного управления – роль.
Состав характеристического описания идентичен и рассматривается с правовой т.з. Задайте себе вопрос, где у Вас описаны, хотя бы полномочия? А права? А ответственность? У Вас нет описания ролей и Вы находились в состоянии неосознанного незнания. Имеющиеся же описания – подделка.
❸ Типичная проблема псевдо-проекта. Интегратор делал то, что умеет, исходя из кадрового и технического обеспечения, а не то, что нужно заказчику. Проверить элементарно – ознакомьтесь с целью, задачами и рисками проекта – они тоже подделки. В тексте Вашей статьи так же упоминаются цель, задачи и риски, но контекста, соответствующего эти понятиям, нет.
Как проверить? Изучите состав и назначение цели, задачи, риска. Сравните с контекстом «Интеграторов».
Тоже и с «добровольностью ТЗ» — продуцирование квази-деятельности попутно убалтывая заказчика покупать уже имеющиеся тех.решения. ТЗ ведь обычно подрядчик пишет? Не так ли?
И в завершении, немного о демагогии, цитата: «Про РП — в корне не согласен, но спорить думаю тут бессмысленно — с тем же успехом можем спорить о том, какой из цветов лучше — красный или синий.»
Прямое и бездоказательное утверждение с апелляцией к ассоциативной связи в виде сравнения цветов, как контр-аргумент, но без указания объектов сравнения – классический приём демагогии.
Удачи.
PS: Смотреть текст не надо, текст надо читать и уметь осознавать.
С позиции автора, похоже, для АС не имеет смыла готовность, доступность, безотказность и т.д. Не имеет значения состав АС, т.е. техническое, организационное, кадровое обеспечение…
Типичная формулировка гуманитария относительно технического вопроса.
❷ Про понимание, цитата: «Каждый инфраструктурный проект (я надеюсь!) начинается с потребности бизнеса, и наша задача — улучшить надежность и безопасность существующей системы планирования…».
Явные проблемы применимостью терминологии. Что бы осознать этот «винегрет», следует изучить понятия инфраструктура, бизнес, задача, система, планирование. Для усиления стиля, могу рекомендовать применение таких маркетинговых формулировок, как:
К списку необходимости изучения, можно добавить термины: стратегический, тактический, оперативный. С ними у автора тоже проблемы (см, цитата: «Стратегия 0: Поговорить с другими компаниями…», «Стратегия 1: Прочитать код…» и т.д.) ⟾ в тексте статьи заменить «стратегия» на «операция».
❸ Тему DevOps даже не рассматриваю – и так понятно маркетинговое словоблудие про «вот эти ножницы DevOps», а «вот те ножницы Agile». Инженер с систематизированными знаниями сразу скажет: «назовите присущие характеристики различающие ножницы на Agile и DevOps». Маркетолог же, сразу начнёт генерировать поток словоблудия про философию ножниц и т.д., т.е. апеллировать к искусственно присвоенным характеристикам, имеющим место исключительно в мозгу маркетолога. Особо «одарённый», маркетолог, поставит соответствующую наклейку. На ножницы…
Важно: самому продукту оценку не даю.
PS: Включайте оба полушария мозга.
По порядку.
❶ Про название статьи, цитата: «Планируем проект внедрения и доработки информационной системы в MS Project — быстро и красиво».
→ Планирование, есть намеченный порядок и последовательность действий по достижению поставленной цели. Это кратко, т.е. не вдаваясь в подробности.
Вот Вам примеры про порядок, по аналогии, чтобы ощутить различия:
Порядок (правильный):
Зайти в кабинку санузла.
Снять мешающую одежду.
Выполнить акт дефекации.
Оторвать нужное количество туалетной бумаги.
Использовать туалетную бумагу.
Одень снятую ранее одежду.
Выйти из кабинки санузла.
Порядок (ошибочный)
Зайти в кабинку санузла.
Выполнить акт дефекации.
Снять мешающую одежду.
Оторвать нужное количество туалетной бумаги.
Использовать туалетную бумагу.
Одень снятую ранее одежду.
Выйти из кабинки санузла.
Беспорядок:
Зайти в кабинку санузла. акт дефекации.
Выполнить снятую ранее одежду.
санузла. Снять Оторвать н
бумаги. мешающую одежду.
Использовать из кабинки туалетную бумагу.
Одень ужное кличество туалетной
Выйти
В описываемом проекте цель не поставлена, на задачи не декомпозирована, риски не идентифицированы, но успешно создаётся быстрый и красивый план в MS Project – классическое продуцирование квази-деятельности, т.е. «даёшь внедрёж».
❷ Про заблуждения, цитата: «Руководитель проекта — менеджер, с хорошей технической экспертизой и навыками бизнес- анализа…».
Менеджер с технической экспертизой, это оксюморон. Или в проекте участвовал такой уникум, как Королев С.П.?
Навыков бизнес-анализа не может быть по определению, поскольку навыки есть частный случай умений, в отличие от последних, характеризуемые неосознанностью исполнения. Например, навык вождения или навык устной речи.
Ещё раз:
1. Умение – характеризуется осознанностью исполнения.
2. Навык – характеризуется неосознанностью исполнения.
Проверка – попробуйте двигаться, смотря глазами через призмы переворачивающие изображение.
По ролям оценки дать не могу, т.к. в статье недостаточно их описания, но на основе имеющегося контекста, смею предположить, что определение и состав ролей автор не знает. Либо, что маловероятно, не успел описать, но это не подтверждается, поскольку отсутствует методическое описание – либо от общего к частному, либо от частного к общему.
Ну и далее, как обычно, устава проекта нет, отчётность отсутствует, роли не формализованы, да ещё и перепутаны как винегрет, управление по понятиям, кто громче орёт тот и прав и т.д…
❸ Про фантазии.
Состав протокола и правил его управления не знаете (очевидно из контекста). Рекомендую ознакомиться с формами краткого и полного протокола, а также методами оформления и ознакомления с ними.
Техническое задание не проектируется, поскольку предшествует ему, т.к. является выделенной стадией при создании системы.
У Вас априори не могло быть руководителя проекта, поскольку руководитель есть штатный работник назначенный на должность, на которого возложены функции управления коллективом… формально регламентированной компетенцией и т.д. Наиболее вероятно, у Вас было применено не функциональное, а процессное управление по матричному методу, т.е. выделение не формального лидера и т.д.
Документ ПМИ не может создаваться на основе тест-кейсов, это не логично, поскольку нарушается причинно-следственная связь, или, другими, словами, первичен ПМИ, а не тест-кейс. Про тест-кейс вообще отдельный разговор.
█ Вам следует формализовать деятельность, прежде чем приступить к реализации, т.е. планирование и организация деятельности и т.д…
Необходимо разделять планирование проекта от планирования управления проектом – есть назначение проекта, а есть назначение продукта проекта, что не одно и тоже.
Что же касается файла MS Project, то оформлен он красиво и может использоваться в качестве шаблона, но на этом всё.
Про потребность. Предполагаю, что находясь на этапе неосознанного незнания, вполне себе можно мыслить, что потребность закрыта, но от мнения человека объективная реальность не зависит… Вспоминается рассказ про обезьян, банан и холодную воду…
Про покупку. Покупать? А обоснование есть? У работников есть аналитическая записка по выбору ПО для автоматизации? На основании моего опыта, сомневаюсь. Предполагаю, что выбор был по ощущениям «как уже те ребята сделали». Впрочем, проверить ведь не сложно. А нужно? Например, руководителю ИТ? И снова – каждое ошибочное решение вносить дополнительно искажение, усугубляя состояние…
Про статью. Что бы создать предметную статью, содержащую знания, нужна предметная постановка цели. Интересы (политические, экономические…). Далее, естественно, с декомпозицией на задачи и т.д. Входящие данные, типа «Сделать хорошо, чтобы все выбросили в окно» (утрирую), для анализа не подходят.
PS: Собаку есть не надо =), надо демонстрировать компетентность. Желательно на бумаге, поскольку на ней видна вся глупость человеческая. К тому же, человеку нельзя помочь, пока он этого сам не захочет, т.е. не перейдёт в состояние осознанного незнания и готовности к действиям.
Не «андрагогика», а «педагогика для взрослых». Не «хьютагогике», а «самообучение».
→Эволюция (кратко) – необратимые процессы, протекающие в живой и неживой природе. Преимущественно необратимые.
→Слова заимствуются при условии, что отсутствует эквивалентное слово в заимствующем языке.
→Термин «хьютагогика» не более чем недомаркетинг, т.к. присутствует только в маркетинговых брошюрках и статейках.
Как очевидно из выше написанного, имеет место не эволюция «педагогика» -> «андрагогика» -> «хьютагогике», а банальная комбинация, т.е. «самообучение взрослого» и т.д.
⌂Вывод: глупость, т.е. либо нежелание либо неумение автора, осознать естественных процессов или явлений. Предполагаю, скорее нежелание, мотивом которой является маркетинг продвижения продукта или услуги, на что указывает контекст и принадлежность автора блогу компании.
❷ Про использование псевдо-научных терминов в обывательском контексте, цитата: «…В чем же отличие подхода к обучению в рамках андрагогики? Самое главное – у взрослых слушателей имеется накопленный багаж, опыт…».
У обучаемых людей по определению нет багажа, а есть знания и умения.
Выражаясь более точно: в педагогике учитываются интеллект, знания, умения и навыки обучаемых.
⌂Вывод: глупость.
❸ Про преподавателей. Цитата: «В наш учебный центр «Сетевая Академия ЛАНИТ» мы всегда с опаской берем на работу уже сложившихся учителей школ и преподавателей вузовов. Не каждому из них удается перебороть свои привычные взгляды на процесс обучения и перестроиться.»
Да, вполне очевидно, что не каждый преподаватель может побороть себя и заняться словоблудием вида:
1. Не самообучение взрослых, а хьютагогическая андрогеника.
2. Не присущие знания и умения, а имеющиеся багаж и опыт.
3. Не производитель, а вендор.
4. И что то там «фасилитатор» — простите, но точного и достоверного определения найти не удалось.
█ИТОГО: Если обращаться к современному жанру, то вспоминается реплика из фильма «О чём говорят мужчины», цитата: «А гренка в нашем ресторане называется croûton. Это точно такой же поджаренный кусочек хлеба, но гренка не может стоить 8 долларов, а croûton — может».
Самое время начать рекламу новых платных курсов, но не по системному администрированию методом самообучения, а DevOps блоттингом хьютагогической андрагогики.
%-)….
Хотелось бы выразиться экспрессивно, но, думаю, каждый осознавший глупость статьи, найдёт близкую себе по душе формулировку.
❶ Про название статьи, цитата: «Как найти хорошего маркетолога?».
→ Разница – «что» есть обобщённое описание исполнения, а «как», это разъяснение о методах и средствах выполнения.
В заголовке написано «как», что расходиться с контекстом статьи, суть которой «что».
Меняем название статьи с «Как найти хорошего маркетолога?».
На «Что делать для поиска хорошего маркетолога?».
❷ Про хорошего маркетолога.
В статье отсутствует формулировка, о назначении и составе «хороший маркетолог».
Есть только обобщённое описание не имеющее отношения к основной сути в деятельности маркетолога – продать товар применяя полуправду, лож и дезинформацию.
Описание сферы деятельности должности начинается с постановки цели, функций и задач.
→ Маркетолог, в первую очередь, должен владеть двусмысленностью, поскольку в ней заключена сила манипулирования потребителем.
Другими словами и более точно, владеть софистикой и демагогией, поскольку именно они позволяют убеждать оппонента, не преследуя своей целью объективность, истинность, точность, достоверность. Ведь нам нужно продать товар или услуг, а не предоставлять потребителю на анализ её присущие характеристики? Не так ли?
Основная функция хорошего маркетолога – умение убеждать потребителя приобретать продукт и услугу, выгодную для продавца, пусть даже невыгодную для потребителя.
Также следует описать функции опорные и качества.
Одной из опорных будет аналитическая, поскольку именно она обеспечивает маркетолога информацией. Кстати, аналитиком маркетологу быть не обязательно*, если не сказать нежелательно, поскольку маркетолог оперирует чувствами и эмоциями, тогда как аналитик объектами и действиями, анализируя и синтезируя их. Далее функции следует декомпозировать на задачи.
❸ Про описание вакансии.
Выбрасываем обывательские формулировки вида «типаж человека» и т.д. Воздерживаемся от словоблудия, поскольку это нужно в маркетинге, а не при решении конкретной прикладной задачи – формирование требований к вакансии.
Описания должно быть, как минимум два:
1. Академическое – требования к компетентности и компетенции.
2. Обывательская – обобщённые формулировки методом композиции из академического описания.
█ Учитывая вышеописанное, по отношению к статье, можно утверждать, что кандидатов Вы ищете по ощущениям, т.е. на основе мнения, нежели по осознаю, т.е. сформированному знанию. Это ни плохо, ни хорошо – это, скорее всего, факт. Главное, не заблуждаться относительно фактически используемых методов, т.е не выдавать желаемое за действительное.
А так, в целом, статья лёгкая в прочтении, но информативно мало значащая, хотя прочитал с интересом.
*Утверждение основывается на тезисе, что маркетинг есть совокупность действий для убеждения потребителя приобрести товар или услугу именно нашей фирмы.
Пример: те или иные, всякие разные, довольно много, различные.
Обращение «месье» неуместно.
Желаете дискуссии, извольте обосновать (см.определение) позицию в явной форме. Я готов. Риторика и демагогия меня не интересует.
→Эксплуатация, это практическое использование (по назначению) производственных ресурсов для получения выгоды. В эксплуатацию, в том числе, входит и поддержка, но не входит разработка.
→Support – это только поддержание технического обеспечения в исправном состоянии, т.е. часть, но никак не эксплуатация в целом.
Чтобы утверждать, что занимаетесь эксплуатацией, нужно непосредственно реализовывать коммерческую выгоду. Вы ведь коммерческая организация? В целом? А сами, как работник, входите в состав ИТ подразделения, как часть организации? Смею утверждать, что речь, скорее всего, идёт об опорном процессе, поддерживающем основные (с западной т.з. основные = бизнес-процессы). Всего различают процессы: основные, опорные, качества. Кстати, поддержка (по Вашему Support) может быть бизнес процессом, а может и не быть им.
❷ Про инциденты, ЧП и т.д., цитата: «Инцидент (или сбой, ЧП) — это некая критическая (обычно массовая) проблема, которая существенно снижает доступность, корректность, эффективность или надежность бизнес-функционала или инфраструктурных систем.».
→ Инцидент, не является проблемой по определению. Упрощённо, в обывательской формулировке, инцидент это «что то не работает как нужно», но можно исправить собственными ресурсами, а проблема, это «невозможность восстановить собственными ресурсами» — нет знаний, нет оборудования и т.д… И уж тем более инцидент не является ЧП. Под ЧП Вы подразумевали чрезвычайное происшествие? Тогда потрудитесь изучить определение термина ЧП – непредвиденное событие повлекшее гибель людей, порчу имущества…
Шедеврально, цитата: «надежность бизнес-функционала или инфраструктурных систем». Попробуйте изучить понятия «надёжность» (собирательный термин), «бизнес», «функция» (как полезная работа), «инфраструктура» (есть ещё 2 структуры). Вас ждёт большой сюрприз, при осознании Вашего контекста…
Простите, но, в данном случае, как нельзя кстати, подходит выражение «Всё смешалось в доме Облонских…».
❸Про цели, цитата: «В рамках процесса управления инцидентами мы ставим перед собой следующие основные цели: 1.Как можно быстрее восстановить работоспособность наших систем …».
Основные? Значит есть дополнительные? Прелестно (сарказм).
→ Заявленный Вами нумерованный список, не является целями по определению, поскольку ни один из пунктов нельзя ни измерить ни достичь. Изучите, хотя бы, такие модные в последние 15 лет западные принципы S.M.A.R.T.
У процесса должна быть одна цель (goal, а не target (мишень)), которую следует декомпозировать на низ лежащие уровни. Или у Вас функция в составе процесса? Это не одно и тоже.
Пример цели: модернизировать техническое обеспечение корпоративной сети между точками A и B в узлах 1,2,3,4 имеющимися ресурсами.
Дополните цель рамками и допущениями.
Декомпозируйте на функции, задачи.
❹ Про мониторинг, цитата: «У нас была самописная система мониторинга, которая подразумевала самостоятельную подписку сотрудников на сообщения о проблемах…»
→ Мониторинг. Наблюдение и регистрация данных с неразрывно примыкающими интервалами с незначительно меняющимися данными. Различают мониторинг параметрический и состояния. Важна визуализация и оповещение… Важна интерпретация показателей.
Учитывая контекст, смею предположить, что у Вас не было и нет системы мониторинга. Скорее всего, речь идёт о недо-системе диагностики и журналировании событий, успешно выдаваемой руководству, как система мониторинга (см. определения «система», «диагностика», «журналирование», «мониторинг»).
Учитывая в целом контекст «статьи» и самостоятельную подписку, у Вас отсутствует формальная структура как часть организационного обеспечения.
Мониторинг по определению не может сообщать о проблемах (см.определение).
❺ Про фазы инцидентов, цитата «Разделили работу с инцидентами на две фазы — активную и ретроспективную».
Ативная-Пассивная. Ретроспективная-Перспективная. Вы хоть понимаете назначение применяемых терминов? (это риторический вопрос).
Начните, хотя бы, с русского языка – прошлое, настоящее, будущее.
Воздержитесь от применения таких терминов, как «превентивный» и т.д., если не понимаете их назначения.
█ Вы не только не осознаёте используемые термины, но ещё применяете жаргонизмы и псевдо-терминологию.
Создаёте автоматизированные системы по заведомо ложным ценностям.
В общем, судя по Вашей статье, как пишите, так организуете и реализовываете – беспорядок, ошибки, подмена понятий, дезорганизация и т.д…
Прочитав, скорее всего подумаете – но ведь у нас всё работает. Да, скажу, машина на 3-х колёсах тоже работает… т.е. с т.з. она неисправна, но работоспособна… какое-то время… в какой-то мере…
Как то так.
PS: Каждый работник компании не в состоянии поставить задачу, тем более, техническому работнику, поскольку нужно обладать не только техническими знаниями, но и умением ставить задачи как таковые (см. состав задачи), что подтверждается, как правило, наличием у них только потребности.
PSS: JIRA есть СОО (BTS) – Система Отслеживания Ошибок (bug tracking system), а не система отслеживания инцидентов. BTS нужна для ЖЦ объекта во время «Разработка» (Development), а не «Сопровождение» (Maintenance). Тем более, BTS не является системой управления документооборотом, что подтверждается анализом ЖЦ и составом объектов управления. Или, по другому, применяется не по назначению. Характеризуется эта ситуация неумением или невозможностью субъекта осознать естественных явлений или объектов, что есть по определению глупость. Это с академической т.з.
С обывательской, это как забивать гвозди микроскопом, потому что он тяжёлый и, таки, забивает. Однако есть плюс – продуцирование квази-деятельности в которой все заняты…
Удачи.
По порядку.
❶ Про мнение, цитата: «Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. …».
→ Инцидент характеризуется временем, местом и сутью, т.е. другими словами когда, где и с чем произошло, о чём не пишет ITIL. На самом деле, изменение одной из 3-х составляющих приведёт к появлению нового инцидента, а не повторению предыдущего. Мера же воздействия инцидента на пользователей, является отдельным аспектом не оказывающим влияния на характеристики самого инцидента (метод обратной связи). Это надо уметь осознать.
→ Проблема. Характеризуется отсутствием алгоритма её устранения, основанной на недостатке имеющихся знаний и технического обеспечения. Это упрощённо.
Важно: Привлекая ресурсы извне, устраняя недостатки в ресурсах, т.е. нечто обладающее возможностью разрешить проблему, последняя преобразуется в задачу:
Учитывая вышеописанное, лишний раз убеждаешься в том, что мнение присутствует каждый раз, когда отсутствует знание…
❷ Про признак проблемы, цитата: ”профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему»…”
→ Техника может быть:
Рассмотрим на примере единственного неисправного и неработоспособного принтера в отделе продаж:
Важно: проблема понятие относительное. Для пользователя, неисправность это проблема, а для техника — инцидент (см. определение п.1).
Первый признак проблемы это не «почему», а невозможность обеспечить работоспособность технического обеспечения собственными ресурсами (это есть критерий). И неважно, известно «почему», т.е. идентифицированное место и причина, или нет, поскольку причина выявляется только по результату диагностики (выявление места и причины неисправности). Данная ошибка основана на классическом обобщение, что приводит к снижению точности и достоверности информации. Чтобы возникло понимание, вольно приравняю «Почему» к декомпозированной формулировке «невозможность обеспечить работоспособность технического обеспечения собственными ресурсами».
Да, методическая формулировка сложнее для понимания, в отличие от обывательской формулировки выраженной в виде мнения, но зато позволяет идентифицировать наличие проблемы на основе критерия, а не ощущения. Выяснять же, к какой именно науке относиться звание профессора Росс Вайз, не имеет смысла, поскольку звание, само по себе, не является доказательством. Также может иметь место ошибка репортёра/редактора/ переводчика.
❸ Про примеры, цитата: «Вы едете на машине, и у неё лопнуло колесо…». Следствием выбранной автором ошибочной системы ценностей, является ложность приведённых им примеров.
Исправим заблуждения учитывая мои п.п.1-2.
Изначально у автора, цитата: «Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.»
Рассматривать следует как систему, надсистему, так и подсистему, причём в совокупности прошлое, настоящее и будущее.
Утверждение автора ложно, поскольку запасное колесо не является частью системы автомобиля до момента установки в него (интеграция), а также перестает быть частью системы после снятия (см. определение терминов). Не являясь частью системы «автомобиль», колесо перестаёт выполнять полезную работу, в результате чего к нему не применимо понятие инцидент или проблема, зато применимы понятия неисправна и работоспособна, что методически верно с тех. т.з…
Итого, на примерах:
На основании вышеизложенного могу утверждать, что имеет место классический вариант подмены знания мнением, с последующим построением ложных умозаключений и приведением соответствующих примеров. Также следует учитывать, что ITIL описывает организационное обеспечение, причём частично, а применяется к техническому обеспечению, что заведомо ложно.
Если проще и по методу аналогии, то с таким же успехом можно утверждать, что бревно это карандаш, потому что оно деревянное, хотя это не так, поскольку назначение и функции карандаша и бревна отличаются, и это очевидно при первом же осмыслении.
█ Вместо заключения.
Проблема (см.определение) таких документов как ITIL состоит в их гуманитарном контексте и позиционировании как методологии по техническим вопросам, хотя таковыми они не являются по своему содержанию.
Проблема пользователей, использующих такие документы, заключается в невозможности осознания.
Количество не значит качество — массовый выброс подобных статей формирует ложную систему ценностей…
Из выше описанного следует делать вывод, что первичное значение имеет знание и осознание в совокупности с обоснованием (можно доказательством), а не вера в некое мнение. Следует не только выражаться в виде утверждений, но и трудится присовокуплять к ним подтверждения, что по своему составу уже будет уже обоснованием, хотя и не доказательством.
Что касается полезной работы Интеграторов, внедряющих автоматизацию по «таким» системам ценностей, в результате будем получать классический «даёшь внедрёж».
Желаю всем включать мозг и знания, а не «сердце» и мнение, поскольку этим широко пользуются маркетологи.
PS: Попугая можно научить говорить E=mc^2, однако для него это будет всего лишь совокупность звуков, а не знание как таковое.
PSS: Не всё заграничное хорошо. В России тоже достаточно накопленных знаний, надо лишь уметь их найти и осознать, а не гонятся за модными маркетинговыми выбросами типа DevOps и т.д…
❷ Про термины. Да, действительно, термины меняются со временем, например в результате глупости оратора/писателя или применения им демагогии.
❸ Про комментарии. Информационно-ценные:
1. geher 01.11.17 в 13:21.
2. fatronix 02.11.17 в 10:35.
3. lxsmkv 01.11.17 в 21:30.
Остальные либо содержат грубые аналогии и обывательские формулировки, либо, как точно выразился fatronix 02.11.17 в 10:35, словоблудие.