Портал №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.

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

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

DevOps Essentials: Business Perspective (Chinese Edition)

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

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

Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику 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). Мне известно минимум три примера такой практики в России: одна производственная компания отправляет многих новых сотрудников (включая ребят из ИТ) на сборочный конвейер, другая — на упаковку готовой продукции, третья — в свои розничные магазины. Эта действительно замечательная процедура даёт очень наглядное понимание — что есть бизнес конкретной компании и в чём он заключается. Однако этого...

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

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

Вакансии направления Digital

Есть две интересные вакансии — консультанта по Agile и методолога продуктовых команд. Консультант по Agile Cleverics расширяет спектр предоставляемых услуг — уже несколько лет мы помогаем клиентам выстраивать работу продуктовых команд и трансформироваться в сторону современных подходов управления ИТ. У нас есть опыт точечного привлечения для отдельных команд, а есть и участие в масштабных трансформациях крупных компаний. Всё это невозможно без квалифицированных консультантов. Мы рассматриваем кандидатов с совершенно различным опытом. В любом случае мы обеспечиваем обучение и выравнивание понимания. Развитие навыков и накопление знаний начинаются с первого дня, потому что задачи клиентов не ждут — работы больше, чем мы успеваем делать. Консультант этого...

Искажение восприятия из-за изоляции

Совсем недавно, летом, писал про эффект Даннинга-Крюгера. Рассуждал — существует ли он, или только кажется? Пришёл к неоднозначным выводам. И вот снова наблюдаю его в реальности. Поразительно, насколько искажается восприятие границы нормального в разных компаниях, подразделениях и командах. То, что для одних привычно, для других находится далеко за гранью допустимого. Искажение наблюдается и в разработке, и в эксплуатации. Пример из разработки ПО, который встречается наиболее часто, таков. Собираешься с командой, спрашиваешь: — Знаете ли вы, что такое конвейер развёртывания? — Конечно, — отвечают, — знаем, только у нас он называется конвейер CI/CD, и он у нас есть, вон, работает. Великолепно...

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM