75 000 коров на ферме семьи Ферг рождаются и растут под присмотром трех серверов, 352 000 датчиков и пяти сотен роботизированных механизмов. Эту историю мне с гордостью рассказал мой однокурсник Слава, чья небольшая команда программистов написала и поддерживает непростой программный код “виртуального фермера”.
Уж лет двадцать IT-фундамент главнее, чем фундамент физический и любой иной. Программная эмуляция вытеснила натурные испытания бомб, программное обеспечение для осуществления интернет-звонков «убило» междугороднюю телефонную связь и вот-вот заменит вообще все виды голосовой связи. За 20 лет почти исчезли материальные носители у новостей, музыки и видео, похожая судьба ждет и большую часть книг.
Неудивительно, что такая же трансформация происходит и в управлении бизнесом. Не за горой тот момент, когда механика управления (согласование и передача распоряжений, контроль соответствия уставным документам и законодательству, принципам корпоративного управления) будут реализованы на базе блокчейн, полностью автоматически. В развитии принципов управления бизнесом главным направлением многие лидеры и эксперты считают перенос в деловую среду метода управления IT-проектами, называющегося Agile. Как пишут в Harvard Business Review Дарелл Ригби, Джефф Сазерленд и Хиротака Такеучи: «С помощью Agile удалось достичь радикальных улучшений в решении задач в IT. Возможности, которые несет внедрение этих методов в других корпоративных подразделениях, огромны”.
Метод Agile для ведения IT проектов возник не вчера. В конце 1980-х годов начала формироваться концепция гибкой разработки программного обеспечения, основанная на принципах постепенных, циклически повторяющихся улучшений, когда постоянная доработка, основанная на непрерывной обратной связи от клиента, заменила собой работу по подробно запротоколированным ТЗ. К 2001 году накопилась критическая масса знаний и подходов, закрепленных в Манифесте Agile, опубликованном группой 17 авторитетных разработчиков. Вот, что постулировал этот манифест:
o Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
o Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
o Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
o На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
o Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
o Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
o Работающий продукт — основной показатель прогресса.
o Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
o Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
o Простота — искусство минимизации лишней работы — крайне необходима.
o Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
o Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Важно понимать, что в разработке программного обеспечения метод Agile стал возможен не раньше, чем наступил момент, когда процессорная мощность стала избыточной и стало возможным написание кода, не оптимального по используемым ресурсам, но позволяющего легко заменять и подключать используемые программные модули. Безусловно важным было и то, что широкое распространение получили методы и инструменты программирования, поддерживающие компонентный, модульный принцип создания программного обеспечения.
В рамках постоянного совершенствования этих сервисов возможна как быстрая доработка и тестирование модулей программ, так и быстрый сбор и анализ обратной связи от пользователей системы. Немаловажную роль сыграло и то, что субкультура программистского сообщества в США – меритократическая до крайности, и профессиональная этика в ней доминирует при принятии любых решений.
Организации, внедрившие у себя Agile-метод в бизнесе (к их числу относятся, например, GE, Saab, John Deere), добиваются сверхбыстрого – в течение месяца – обновления или расширения услуги или продукта; дисциплинированной и систематизированной работы рабочих групп, занятых постоянным усовершенствованием услуги/продукта; тесной и продуктивной связи с конечными потребителями услуг/продуктов, выражающейся в постоянном тестировании предлагаемых изменений.
Но внедрение Agile – как в бизнесе, так и в разработке софта — требует одновременного исполнения трех условий:
Условие 1. По правилам Agile руководителем каждого проекта и всей работы в целом должен быть не старший по званию, а старший по умениям. Такой подход свойствен древним армиям, где военачальником становился самый сильный воин, и консалтинговым фирмам, которыми руководит наиболее опытный консультант. Однако, подавляющее число компаний устроено совсем не так.
Условие 2. Работа в командах/проектах, работающих по Agile-принципам, предъявляет высочайшие требования к качеству работы каждого участника. Это продиктовано необходимостью быстро встраивать разработанные участниками компоненты в интегральный продукт деятельности всей команды, минимизируя число и глубину проверок. Да и честность участников должна быть огромной, в первую очередь честность по отношению к самим себе, ведь именно на анализе ошибок и неудач основан ключевой для Agile-метода процесс инкрементальных улучшений. Немаловажным будет и энтузиазм команд, без которого невозможен постоянный поиск наилучших решений. Все перечисленные качества (профессионализм, требовательность к себе, честность, энтузиазм), сколь нередкие в IT-компаниях городов Пало-Альто, Менло-Парк и Маунтин-Вью, столь же нечасты вне IT-индустрии и вне Кремниевой долины.
Условие 3. Внедрение метода Agile в разработке программного обеспечения предполагает, что за быстрым внедрением нового модуля или модуля с изменениями идет контроль за результатом. Стало ли лучше от внесенного изменения? Что именно стало лучше и насколько? Хорошо таким компаниям, как Google, когда все отношения с клиентом имеют априори цифровую форму и реакция клиента тоже априори оцифрована (по какой ссылке перешел, сколько времени провел на странице и др.). А в традиционных бизнесах (банки, розница, услуги) сбор и, главное, анализ обратной связи от клиентов – задача непростая и почти всегда нерешенная.
Вот и получается, что всерьез говорить о внедрении Agile стоит только после того, как в организации сложилась меритократическая культура, когда все участники проектных команд профессиональны, честны и полны энтузиазма и когда существует эффективная обратная связь с клиентом и умение анализировать ее результаты.
Можно ли внедрять Agile параллельно (одновременно) с формированием в организации подобающей этому методу среды? Не более, чем жарить стейк, одновременно гоняясь за коровой по безлюдным лугам на ранчо семьи Ферг.