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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

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

Управляющий партнёр 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.

Сказки про кратное сокращение Time to Market

Разговоры про ускорение разработки программного обеспечения ведутся уже много лет. Насколько ожидания оправданы? Можно ли ускориться, и как сильно? И главное — что для этого нужно?

Action Bias — известная ловушка, в которую мы всё равно постоянно попадаем

Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.

Стоит ли использовать продуктовый подход, если нет продукта?

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

Источники, которым можно верить

Предположим, вам нужно разобраться в какой-то новой для вас предметной области. Также предположим, что эта область знаний относительно новая, относительно модная, да ещё и динамично развивается. Например, Agile, Kanban, ITSM, ITIL, что-то такое. Вроде бы существует уже десятки лет, но вы пока не очень знакомы, вам было не надо. А теперь — надо. Какими источниками знаний воспользоваться? Кажется, что вопрос тривиален — вот же Гугл, или Википедия, берём, читаем. Однако всё не так просто. В Cleverics многие годы была хорошая традиция, мы каждый год выпускали книжку. Иногда это были книги, написанные нами, но чаще — книги других авторов, которые мы переводили с их...

Метрики потока создания ценности

Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки, сколько заявок приходит от какого филиала, сколько распределяется на какого специалиста поддержки, что чаще всего ломается и требует внимания. Понять объективно, а не в ощущениях. И понимать регулярно. Нет, я не помешан на метриках и отчётах. Знаю много случаев, когда управленческие решения принимаются вовсе без данных, и оно срабатывает. Что уж там говорить, с 2009 года, когда появился Cleverics, мы в нашей компании принимаем сотни решений каждый год,...

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

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

Воля и разум

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

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

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

DevOps Essentials: Business Perspective (Chinese Edition)

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

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM