Портал №1 по управлению цифровыми
и информационными технологиями

Что такое точка?

Вы когда-нибудь пробовали объяснить что-то простое, что, как Вам кажется, все и так знают? Например, дать определение точке или прямой?

На днях, выступая на одном публичном мероприятии, столкнулся с тем, что не вся аудитория знакома с понятием ITSM, и управлением ИТ как таковым. Я настолько привык к тому, что последнее время приходилось общаться с людьми, которые "в теме", что пришлось сделать над собой усилие и достать из недр памяти примеры и определения, которыми когда-то объяснял суть подхода.

К чему я это все? Всегда ли вы уверены, что основы того, на чем вы собираетесь строить решение (процесс, например), понятны участникам? Как это проверить? Не устраивать же тесты для проектной группы в начале проекта? Мы зачастую проект предваряем обучением проектной группы необходимым основам. Кажется, что этого достаточно, но практика показывает, что в идеале к общему языку лучше приходить раньше, еще на этапе постановки задачи. Т.е. когда проект еще не начался, а только планируется. Пару раз я, например, встречался с тем, что заказчик под словом "процесс" понимал некую последовательность технических операций, выполняемых специалистами для конкретной ситуации. Например, для заведения пользователя или при установке рабочего места.

PS: Почему-то, вспомнились определения из книги Евклида "Начала". Определения не прижились, но долгое время ими активно и успешно пользовались 🙂

  • Точка есть то, что не имеет частей. (Точка есть то, часть чего – ничто)
  • Линия — длина без ширины.
  • Поверхность есть то, что имеет только длину и ширину.

 

Комментариев: 11

  • Самое простое (ударение на "е") существо на сете – Бог

     

  • Главный постулат для построения и управления Архитектурой компании (EA) – Архитектура компании – это то, о чем договорились все заинтересованные стороны.

    Именно поэтому приглашение Консультантов для того чтобы они  сделали "ХОРОШО" – бессмысленно, если в компании не ядра которое точно знает что нужно сделать и как это делают

  • Grigory Kornilov

    Если вы выступаете в роли PM, то должны быть уверены, что требования собраны, они в том числе адекватны и однозначно воспринимаются соответствующими участниками проекта, а ресурсы соответствуют требованиям (доступны, компетентны).

    Так что без стеснения говорите, что проекту для успешной реализации требуется этап подготовки, включающий и повышение уровня знаний некоторых участников в определенных областях.

  • Alexey Popov

    Вводный семинар по “основам основ”, с плотной обратной связью и большим количеством примеров, забавных кейсов и открытых вопросов. А иначе никак. Особенно что касается “сервиса” и “процесс vs проект”.

    • Согласен, вводный семинар нужен обязательно. Но ведь не во всех случаях его можно провести. К примеру, в середине первой встречи с новым потенциальным клиентом очень забавно осознать, что под одними и теми же словами вы предыдущий час имели ввиду совершенно разные вещи 🙂

      • Alexey Popov

        В нашей практике есть некая «программа оценки зрелости» (по модели IOM), с которой должно начинаться, по идее, любое наше взаимодействие по операционной и не только тематике с Заказчиком. Это скорее диалог, во время которого можно понять, в том числе, настроения и терминологию Заказчика. 

        • Ух ты, интересно! А можно чуть подробнее?

          Что за модель? Как вы её используете?

          • Alexey Popov

            К сожалению, время, а так же скорость интернет в Вашем учебном классе, где я обитаю ближайшую неделю, не позволяют мне найти хорошее описание :), но по названию информация легко находится: infrastructure optimization model. По сути, это майкософтовская модель на основе хорошо себя зарекомендовавшей CMM(I), в разрезе по двум основным составляющим: Core Infrastructure и Business Productivity. Оценив текущий, а так же желаемый уровень зрелости Заказчика (инфрастуктуры, процессов) по этой модели, можно составить определённый роадмап наших с ним взаимоотношений, нашей помощи, как вендора, по тем продуктам и решениям, которые мы предлагаем и поддерживаем.
             

            Конечно, это не бест практис, потому что есть своя специфика – это те Заказчики, которые уже купили контракт премьер-поддержки и теперь исходя из его размера "набирают" себе в корзину те или иные наши услуги, скажем, на год. Ну и кроме того, мы мультинациональный вендор, поэтому мы не только можем, но и должны использовать подобные централизованные практики и подходы к планированию работ. 

            Это наш язык, который мы предлагаем своим Заказчикам для общения.

  • Евгений, отличная тема! Мир шире, чем привычные профессионалам рамки. В этом мире живут люди, которые, например, под словом "процесс" понимают не упорядоченный набор шагов, преобразующих входы в выходы, а всего лишь смену состояний. Например, процесс кипячения, воспалительный процесс и т.д. А ведь ещё есть и группа товарищей, которые занимаются гражданскими и уголовными процессами…

    Постоянно находясь в одной и той же профессиональной области мы по умолчанию подразумеваем определённый смысл за определёнными словами. И иногда ошибаемся, когда считаем, что все вокруг разделяют наше понимание.

  • Эля

    Ребята, вы ужасно нуууудные


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM