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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DevOps — A Business Perspective

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

Короткие тесты на профессиональную пригодность

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM