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

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

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

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

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

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

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

Сопротивление измерению

Известная фраза «Нельзя управлять тем, что не измеряешь» приписывается разным уважаемым управленцам: Джеку Уэлчу из GE, Эдварду Демингу, отцу QA, возможно ещё кому-то. Некоторые считают, что это народная пословица — общеизвестная истина, сформулированная кратко и ёмко. Действительно, выстраивая систему управления неплохо бы сделать так, чтобы принимаемые решения опирались на объективные данные, а не мнение отдельных участников о состоянии дел. В этом случае решения могут быть более взвешенными, а потому — более результативными. Занимаясь организацией процессов управления, скажем, в ITSM, современный консультант не забудет про KPI и метрики. Разрабатывая для заказчика регламент какого-либо процесса, управления инцидентами, проблемами, конфигурациями, изменениями, уровнем услуг... — любого процесса,...

Под кого подстраивать систему управления?

Минута философии на портале. Не пугайтесь, и простите за циничное изложение. Вступление, часть первая. Известно, что иерархические структуры управления обладают существенным недостатком. ИТ-подразделения крупных компаний, в которых (подразделениях) трудятся 800-1000 человек, в управленческой иерархии опираются на 50+ менеджеров разного уровня. Эта опора во многих случаях достаточно хлипкая ввиду низкой компетенции означенных менеджеров — где же взять столько высококвалифицированных управленцев? Традиционный способ «вырастим из айтишников» имеет известные недостатки, а мотивация двигать вверенное направление вперёд у многих руководителей со временем сходит на нет из-за политических вопросов и желания удержаться и расти вверх, а не организовывать работу подчинённых. Итого, менеджеров в ИТ много, а...

Кто отвечает за конвейер развёртывания?

Нужно очень сильно отстать от жизни (примерно лет на 5-7, что по нынешним временам приравнивается к вечности), либо иметь крайне веские аргументы, чтобы не использовать для доставки готового кода до среды эксплуатации конвейер развёртывания (в народе часто именуемый конвейером CI/CD, что в данном случае непринципиально). Техническая сторона вопроса — как построить конвейер — в большинстве случаев понятна, если не очевидна. Инструментов море, идеология ясна, собрать конвейер можно в простых случаях за час, в сложных — за пару недель. Организационная же сторона вопроса не так проста, как кажется. Кто должен/может его создать? Кто обеспечит функционирование? Кто починит, когда сломается? Кто будет его постоянно улучшать,...

Существует ли эффект Даннинга-Крюгера?

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

Повышение приоритета как (неработающий) способ ускорения работ

Мы это видим довольно регулярно. Не только видим, но и принимаем участие в обсуждении или принятии решения: «смотрите, задача АВС уже очень долго находится в работе, давайте повысим её приоритет, чтобы, наконец-то, устранить проблему». Согласитесь, это вполне привычный способ управления. Беда в том, что он очень деструктивен и зачастую приносит больше вреда, чем пользы. Для дальнейших рассуждений необходимо сделать два предположения: Задача, приоритет которой повышается, не единственная в очереди. Работы много; точно больше, чем ресурсов в данный момент. В большинстве случаев оба предположения верны и дела обстоят именно так. Эти два пункта позволяют нам смотреть на ситуацию как на систему,...

Кейс: увеличение частоты релизов в продуктовой команде

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

ITIL и новые модные штуки

В самом начале 2000-х мне, как и многим другим ребятам, было очень важно узнать: как организовать современный (на тот момент) ИТ-департамент коммерческой компании среднего размера. Скажем, на 50-200 «айтишников». То был не праздный интерес, а вполне реальная задача — столкнувшись с управленческим аспектом организации труда стало понятно следующее: Работа персонала может и должна быть организована (в противовес простому устройству мира «все люди изначально хорошие, и они просто ходят на работу, и там работают изо всех сил»). Работа может быть организована сильно по-разному. Способ организации работы существенным образом влияет на получаемые результаты. Мне и моим коллегам в то время очень сильно помогла...

DevOps — A Business Perspective

Наверное, это реклама, но не могу не поделиться. Простите. Недавно, с год назад, я написал книжку про DevOps. Нужно было разобраться в теме, структурировать мысли, да и объяснять кому-то намного лучше, если есть источник знаний — вот и получилась целая книга. Мне, конечно, было очень важно узнать мнение экспертов по поводу этого монументального (для меня) труда. Раньше я книжек не писал, вдруг там внутри глупости или банальности? Поэтому я передал рукопись нескольким уважаемым мной ребятам и, в целом, получил хороший отклик. Но русскоязычные товарищи, мнением которых я дорожил, очень быстро закончились. Что делать? Пришлось книжку перевести на английский. Это было, разумеется,...

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM