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