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

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

Рассмотрим поток создания ценности. Для измерения его эффективности настоятельно рекомендуется применять метрику 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, и он у нас есть, вон, работает. Великолепно...

Продуктовым командам метрики не нужны

Модное течение последних лет заключается в отказе от управления проектами в пользу управления продуктами. Долгое время мы пытались получать ценность от информационных технологий (и, соответственно, от ИТ-специалистов и ИТ-руководителей) с помощью проектного подхода: назовём важное изменение проектом, запланируем, выделим ресурс, постараемся уложиться в ограничения. В некоторых случаях срабатывало хорошо, в последнее время — не очень. Теперь ставку делают на управление продуктами как интересную и перспективную альтернативу. Где продукты — там и команда. Необходимо сильно ограничить область ответственности, выделить и закрепить ресурс на 100% времени, посадить всех рядом, объявить единую цель, начать работать по новым принципам организации труда. Без этого всего управление продуктом...

Лекарство от всех болезней

Современные организации — сложные организмы. В них одновременно протекает множество процессов, взаимодействует бесчисленное число субъектов. Как и в любом сложном организме, в них возникают сбои — что-то идёт не так, как положено, или не идёт вовсе. Какой-то участок работ или некоторая зона ответственности, как теперь часто говорят, «подвисает». Когда затевается действительно большая перестройка, очень часто возникает соблазн явно или не очень, но расширить область охвата проводимых изменений. Явно — когда руководители пытаются воспользоваться случаем. Неявно — когда при проработке управленческих решений участники затрудняются пояснить, почему то или иное решение именно таково. После погружения в детали выясняется, что решалась-то уже совершенно иная задача, нежели чем...

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM