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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Олег Скрынник

Управляющий партнёр Cleverics. Сертификация: IT Service Manager, IPSR (Certified ITIL Practitioner: Support & Restore), IPRC (Certified ITIL Practitioner: Release & Control), IPAD (Certified ITIL Practitioner: Agree & Define), ITIL Expert, EXIN DevOps Master, SAFe 4.0 Agilist, ITIL Managing Professional, ITIL Strategic Leader.

Лучше делать хоть что-то, чем не делать ничего

На конференциях по всяким Agile и DevOps мы часто слышим слово “unlearn” – забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено не так, как мы привыкли считать. Разучитесь, чтобы научиться. В очень многих случаях такие заявления – полная ерунда. Не нужно ничего забывать, нужно просто работать головой, опираться на старое и осваивать новое. Однако время от времени встречаются откровенно контринтуитивные тезисы, заставляющие и вправду задуматься. Для одного из клиентов, готовясь к семинару, я набросал список убеждений, на которые часто опираются менеджеры, при этом сами убеждения, скажем так, можно подвергнуть сомнению. Например, “простаивающий ресурс – это…

Воля и разум

Любое серьёзное преобразование в компании, от “внедрения” какого-либо нового ИТ-процесса до пресловутой цифровой трансформации, является организационным изменением: требуется изменить уже имеющиеся системы управления, чтобы они стали работать по-новому, или обрели новые свойства и способности. Приходится работать с формальной стороной (регламенты), культурной стороной (как у нас принято делать дела), технической составляющей, политической и так далее. Это – очень интересная работа, проводить организационные изменения в средних и крупных компаниях. К счастью, в области управления орг.изменениями накоплено достаточно знаний и опыта – есть замечательные публикации, методики, инструменты. Некоторые из них применяются уже десятки лет, другие являются относительно новыми. В частности, некоторые эксперты выделяют…

Шаг “Отложено” в потоке создания ценности

Рассмотрим простейший поток создания ценности: На ваш взгляд, что в этом потоке не так? Подумайте, и когда будете готовы – листайте ниже.                     Ответ бросается в глаза – один из шагов отличается от других. Опциональный шаг “Отложено” подразумевает, что задача, двигающаяся по потоку, может встать на паузу после этапа “В работе”, но до этапа “Проверка”. Причины этой паузы из схемы не ясны, но шаг “Отложено” даже визуально, из-за подписи “(опционально)”, уже выглядит инородным. Однако проблема не в инородности. Проблема в том, что на схеме изображён не поток создания ценности, а что-то…

DevOps Essentials: Business Perspective (Chinese Edition)

Когда дата публикации книги – первое апреля, всем совершенно очевидно, что это такая шутка, и нет никакой публикации. Ну как всем – любому нормальному человеку. К счастью, есть ещё и ненормальные, которые взяли и перевели одну из книг, выпущенных Cleverics, на китайский язык, и выпустили ровно первого апреля. Из всех слов приведённых на обложке, я могу разобрать только “DEVOPS”. Среди остальных загадочных символов наверняка где-то скрывается “business”, немного “perspective”, и, возможно, фамилия автора. Хотя нет, есть ещё в углу узнаваемый логотип EXIN – международного экзаменационного института. Потому что это не просто книжка, это пособие для подготовки к профессиональному экзамену “DevOps…

Метрика эффективности потока, похоже, совершенно бесполезна

Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику Flow Efficiency. Действительно, ещё со времён увлечения Lean нам известно, что далеко не всё время, которое заготовка проводит в нашей производственной системе, над ней кто-то работает. Существенную часть времени она находится в очередях, в ожидании, перемещаясь между участками работы и так далее. Потери, одним словом. Плохо. И Lean, и Канбан-метод, и даже ребята из DevOps советуют измерять эффективность потока путём деления времени, потраченного на собственно работу по созданию ценности, на общее время, которое задача провела в потоке. К примеру, вот что написано в словаре книжки “Essential Kanban Condensed”…

Две основные проблемы с CI/CD, конвейерами, GitOps и проч., и как с ними быть

Конвейер развёртывания (в народе именуемый CI/CD) – основной и необходимый компонент DevOps, даже если под DevOps понимаются сугубо технические практики. Понятно, что без конвейера никуда, никакого DevOps не будет. Предположим, некая продуктовая команда, пока не имеющая конвейера, всё же решила не оставаться в прошлом, а перейти в светлое настоящее. Предположим также, что это не решение одного какого-то безумца из команды, а идея, разделяемая большинством. Прекрасно. Такую команду на её пути подстерегают две большие проблемы. Проблемы Первая: даже в самых простых и тривиальных случаях (веб-приложение, виртуальная инфраструктура, современные языки, библиотеки и фреймворки) построить конвейер бывает не так просто. Дело в том,…

Диагностика продуктовых команд как поток

Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали – не суть. Предположим, что с этой командой мы какое-то время поработали: разобрались в её рабочем процессе, особенностях, составе, области ответственности… Реализовали набор практик, помогающих работу/результаты структурировать, визуализировать, организовывать, измерять и улучшать. Всё на основе важных принципов и исходя из определённого, нового продуктово-гибкого mindset’а (это слово я на русский перевести затрудняюсь). Итого: первоначальные инвестиции сделаны, далее ожидается более самостоятельное движение этой команды вперёд. Возникают важные управленческие вопросы: как убедиться, что команду можно “отпускать в более свободное…

Кто тут крайний?

Забудем на минуту про единорогов, бирюзовые компании, холакратию и прочие мифические концепции. Они, конечно, где-то есть, но не очень рядом. Представим себе традиционную организацию, имеющую ИТ-департамент, устроенный, как водится, в виде иерархии. Ничего необычного. Часть этой иерархии – подразделение, где трудятся аналитики. Поймаем одного из них в коридоре и спросим: “Подскажи, дружище, на твой взгляд, чтобы всё в разработке ПО стало быстрее и качественнее, что нужно сделать?”. Во многих знакомых мне компаниях ответ будет примерно таким: “Известно что – разработчиков заменить на нормальных. Наши-то и бизнес не понимают, и код пишут так себе, а учиться и слушать никого не хотят…”….

Незаметный прогресс (глобальный и локальный)

Многие привычные сегодня вещи и явления ещё вчера отсутствовали. Яндекс.Такси и Убер вместо дикого рынка частного извоза, YouTube вместо телевизора, Spotify вместо компакт-дисков, оплата телефоном вместо наличных, онлайн-банк вместо похода в отделение с паспортом: список бесконечен. Любопытно, что сегодня всё это воспринимается как данность. У многих есть ощущение, что так было всегда, а если не всегда – то уж точно возникло очень давно. Строго говоря, возраст многих перечисленных сервисов действительно приличный: YouTube стартовал в 2005, Spotify в 2006, Uber в 2009… Даже прогрессивный Тинькофф Банк начал свою историю в далёком 2006. Однако есть нюанс: первые много лет своего развития проникновение,…

Побыть в шкуре бизнеса

В некоторых компаниях есть замечательная практика. Почти любой новый сотрудник в первые же недели своей работы, в какое бы подразделение компании он не устроился, обязан некоторое время поработать “в бизнесе”. Насколько я помню, эту затею придумали японцы, затем распространили её по миру в составе бережливого производства (Lean). Мне известно минимум три примера такой практики в России: одна производственная компания отправляет многих новых сотрудников (включая ребят из ИТ) на сборочный конвейер, другая – на упаковку готовой продукции, третья – в свои розничные магазины. Эта действительно замечательная процедура даёт очень наглядное понимание – что есть бизнес конкретной компании и в чём он…

Требования к системе управления ИТ с точки зрения персонала

Какая бы ни была система управления в ИТ-департаменте, командно-административная или гибко-самоорганизованная, она опирается на персонал. Да, тезис избит до неузнаваемости, начиная с “Кадры решают всё!”, вплоть до “Сотрудники – наш самый ценный ресурс”. Тем не менее, следует признать, что результаты работы ИТ-служб напрямую создаются ИТ-персоналом, и больше никем. При этом многие ИТ-руководители склонны переоценивать компетенции и интеллектуальные способности собственных подчинённых. Считается, что корпоративные механизмы поиска и найма могут обеспечить поступление требуемого качества персонала в требуемом количестве, а традиционные механизмы развития и карьерного роста закроют все потребности в ценных кадрах. Это, разумеется, заблуждение, которое особенно больно бьёт по компаниям среднего и…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;