Можно ли небольшим усилием над собой самим, например, перестав сорить на улице, сделать страну, в которой ты живешь, лучше? Как навести порядок в городе и снизить уровень преступности, только борясь с граффити? Опыт нью-йоркского шефа полиции метрополитена заставил меня задуматься о применении подобных принципов по отношению к инжиниринговому процессу. Если перевести на язык бизнеса, вопрос формулировался бы так: возможно ли малыми усилиями достичь большого результата?
Принято считать, что значительный результат – следствие фундаментальных изменений в работе компании. Очень часто (гораздо чаще, чем может показаться) лучше начать с небольших косметических нововведений. Они, казалось бы, не могут серьезно влиять на результат – но, как по волшебству, влекут за собой изменения глобальные. Когда в вашей комнате выбиты все окна, никакая уборка вам не поможет, до тех пор, пока вы не вставите стекла в рамы.
В софтверных компаниях эффективность R&D-процесса (Research & Development – английский аналог русского термина НИОКР) – во многом определяется изначально хорошо написанным исходным кодом – архитектурой продукта, библиотеками, которые используются и т.п. А есть мелкие вещи вроде билд-систем, инсталляторов, единственная задача которых, по большому счету, – собирать несколько продуктов в один автоматизированным способом. Подобного рода несущественные моменты, которые помогают в общем деле выпуска программного обеспечения, но сами по себе не являются ключевой функцией, я называю House Keeping.
Так вот, когда в процессе споров инженеры пытаются доказать, что запуску нашего продукта в срок мешает лежащее в основе несовершенное технологическое решение или бизнес-процесс, и предлагают выделить наиболее сильно влияющие на этот процесс факторы и начать устранять их, я предпочитаю «убираться по дому, начиная с мелких вещей» (Do house keeping!). На справедливые возражения коллег «у нас гангрена ноги, а ты предлагаешь заниматься царапиной на ухе», я часто провожу аналогию с действиями тех самых шефов полиции метро Нью-Йорка 80-х и 90-х. Борьба с бушевавшей со страшной силой преступностью в метрополитене началась через… избавление от граффити и ловлю безбилетников. Казалось бы, деньги налогоплательщиков шли не на прямые действия по борьбе с нарушителями правопорядка, а на несущественные и мало коррелирующие с основной задачей кампании. Но это помогло. Известный пример решения проблемы, который позже применялся не только для метрополитена, но и всего Нью-Йорка.
Я уверен, что «теорию разбитых окон» стоит применять в интересах бизнеса. Наш случай: что может быть проще, чем правильно наладить автоматизированную работу билд-систем? Если для одного нашего продукта для B2C билд собирается 4 раза в сутки, то для другого, более сложного решения для сервис-провайдеров, этот процесс может растягиваться до 5 дней. В результате снижается скорость сборки компонентов кода продукта, влияющая в свою очередь на скорость тестирования, далее на скорость девелопмента и т.д.
Парадоксальная вещь: порой правильно организованный технический процесс существенно важнее с точки зрения перспектив для бизнеса, чем лежащее в его основе гениальное технологическое решение, до которого никому и никогда не будет дела. Потому что оно не смогло быть «доведено» до стадии продукта и найти потребителя.
