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