Сегодня хочу поделиться старой историей и поговорить об одном из принципов ITIL - collaborate and promote visibility. Вернувшись со встречи, на которой обсуждалась очередная инициатива, я негодовал. В бэклоге лежала куча критичных задач по развитию бизнеса, техдолгу и обновлениям, которые объективно были приоритетнее нового запроса "просто улучшающего пользовательский опыт". Мне было непонятно, как при такой очереди нам пытаются вставить новую задачу, да еще и просят об оперативности? Негодование довольно быстро сменилось пониманием - никто кроме нас о нашей нагрузке не знает. Естественно, коллеги будут приходить с запросами на изменения, если не видят очередь.
Когда мы проектируем интеграцию, легко попасть в ловушку: сделать АПИ "под конкретную систему", а не "про свои данные". Сегодня на другом конце провода одна CRM, завтра ее меняют, послезавтра BI переезжает на другую платформу - и каждый раз приходится переписывать контракт и пересобирать интеграцию. Хочу поделиться парой советов, которые упрощают жизнь архитекторам и ИТ-менеджерам.
Кажется, я нашел сборник вредных советов, которым пользуются все разработчики, аналитики и их менеджеры. Иначе сложно объяснить абсолютно шаблонное поведение вокруг сроков и результатов. Это даже не про людей - это про систему, которая поощряет тех, кто тянет до последнего.
В последние месяцы, а может и годы, я все чаще слышу упреки в сторону Agile. Перекраивание задач, перекладывание ответственности, отсутствие структуры - список претензий уже звучит как шаблон. Но Agile, как и любой инструмент, - это всего лишь инструмент. Результат всегда зависит от того, в чьих руках он оказался. В манифесте нигде не написано: "не работайте со стратегией", "устраивайте хаос", "не планируйте дальше двух недель". Суть Agile в другом - в фокусе на результате, а не на культуре процесса и придуманных нами же ограничениях в виде правил. Хочу поделиться двумя случаями из практики. Первый изменил мое отношение к правилам, второй - стал для меня примером настоящего Agile.
Мне приходится немало взаимодействовать с поставщиками ИТ-сервисов. И часто слышу одни и те же фразы: "мы не знали, как у вас все устроено", "мы только подключились, не знаем ваши процессы". Формально это звучит как оправдание. По факту - признание в том, что базовые принципы ИТ-управления игнорируются. Отрасль уже нашла ответы на большинство вопросов организации работы ИТ-сервиса. Эти подходы описаны, многократно проверены на практике и общедоступны.
Порой кажется, что мы живем в странном мире неестественного отбора: выживает не сильнейший, не умнейший и даже не хитрейший. Выживает слабейший - тот, кто лучше всех умеет притворяться беспомощным. Система защищает слабых. В такой реальности бесполезно что-то уметь, внедрять, оптимизировать. Побеждают те, кто мастерски находит оправдания, прикрывается годами "опыта" и бесконечно повторяет "мы всегда так делаем".
Когда баг попадает в руки разработчика, формируется тернистый путь к исправлению. Он может состоять из уверенных шагов, ведущих к быстрому исправлению, или виться бесконечной спиралью уточнений, проб и ошибок. Разница между этими сценариями часто кроется не в сложности самой ошибки, а в качестве информации.
Вспомнил давний эпизод, увидев ролик с Джеком Ма, главой Alibaba, о том, что его главная задача - находить нужных людей. На одном из проектов я запустил SonarQube и через какое-то время с одним из менеджеров обсуждал результаты анализа, сам инструмент и накопленный техдолг. Для меня Сонар был первой линией обороны в потоке бесконечных приемок и утомительных код-ревью. Коллеги, не погруженные в разработку, увидели в нем магического помощника, который находит и подсвечивает дефекты. Разговор о критериях приемки и требованиях к качеству естественно перетек в тему найма.
Ты замечал, как договор раздувается до ритуальной книги? В нем растут требования к отчетности - не к пониманию проблем и не к улучшению процессов, а к самому факту наличия форм. Появляются таблицы, которые никто не читает, графики, которые переделывают три раза ради соответствия шаблону, и тексты, предназначенные исключительно для аудита. В этот момент ценность перестает быть целью, а становится побочным эффектом между двумя подписями. Неделя уходит не на релиз, а на охоту за запятыми. ИТ рапортует о трансформации, а живет по тетрадке согласований.
Когда фреймворки управления ИТ начали входить в мою жизнь, ITIL стал фаворитом как понятный сборник практик. Однако меня интересовали и другие инструменты, в частности COBIT (Control Objectives for Information and Related Technology). Просматривая запись конференции о COBIT отметил для себя слова спикера, в которых он делился интересным случаем, с которым столкнулся занимаясь переводом фреймворка на русский язык. "Control" в COBIT, это контроль или управление? Ответ оказался простым - и то, и другое. Контроль и управление - две стороны одной медали. Без одного не бывает другого.
