«Гибкое» предприятие требует не только внедрения гибких методологий разработки (Agile) внутри ИТ-службы. Опытные руководители знают, что наиболее успешная agile-среда формируется там, где бизнес-подразделения предприятия следуют точно таким же принципам. А наилучший способ добиться этого — поручить ИТ-директору возглавить процесс.
Как и многие другие современные ИТ-директора, Эд Тонер, возглавляющий ИТ-службу штата Небраска, привносит в ИТ гибкость мышления, которая должна стать гарантией того, что внедрение и поддержка программного обеспечения будут отвечать потребностям организации наилучшим образом.
Тонер ожидает от сотрудников своей ИТ-службы соблюдения принципов Agile, но при этом хочет, чтобы точно так же поступали и его коллеги из бизнес-подразделений. А потому в договорах, заключаемых с различными департаментами штата, ИТ-служба прописывает принципы методологии Agile (обусловливая необходимостью их соблюдения продолжение своего участия в разработке и развертывании программного обеспечения).
«Сейчас большинство глав департаментов понимают, что либо они становятся нашими партнерами в этом процессе, либо шансы на успешное завершение проекта заметно снижаются», — подчеркнул Тонер.
С представителями бизнеса на борту
Методологией Agile Тонер увлекся, когда возглавил ИТ-службу штата. От привычной концепции водопада он пришел к совершенно иным принципам гибкого проектирования. Тонер начал с того, что пригласил специалистов с опытом использования ориентированных на гибкое проектирование языков программирования — .Net и Java. А эти люди уже в свою очередь обучили языкам и принципам гибкого проектирования 400 сотрудников ИТ-службы.
Необходимость соблюдения принципов Agile другими департаментами для обеспечения общего успеха закрепляется в договорах. «Мы начинаем с обсуждения общей вовлеченности бизнес-подразделений в процесс, — пояснил Тонер. — С директором каждого департамента заключается контракт, в котором прописываются обязательства сторон в части разработки».
«Чтобы вовлечь бизнес-подразделения в процесс agile-разработки, я должен был привести убедительные доказательства целесообразности такого перехода, — указал он. — Все хотели реальных подтверждений. Примерно через год после начала подобных проектов поползли слухи о том, что мы предоставляем продукт за несколько недель, а не за несколько месяцев. И с этого момента начался органический рост проектирования по методологии Agile».
Проблемы формирования культуры agile
У ИТ-директора есть веские причины внедрять agile-методологию в рамках всего предприятия, а не только ИТ-службы.
«Если бизнес-подразделения вовлечены в процессы agile-разработки, то ИТ-службе легче получить более полное представление о потребностях бизнеса, а значит, она может лучше согласовывать свои действия с целями бизнеса, — рассказал генеральный директор Scrum.org Дэйв Уэст. — И тогда отдача от инвестиций в ИТ возрастает в масштабе всей организации. Предприятие оказывается в более выгодной позиции при проведении необходимых преобразований благодаря использованию передовых технологий. Применяя методологию Agile, вы быстро предлагаете рынку то, что его интересует».
Но вовлечение бизнес-подразделений в процесс agile-разработки сопряжено и с определенными трудностями.
Во-первых, по-разному понимается сам термин «agile». ИТ-директор и ИТ-специалисты подразумевают под ним методологию, тогда как бизнес в соответствии с традиционным определением словарей — ускорение внесения изменений и продвижения вперед.
ИТ-директор должен помочь другим руководителям понять, что agile-подход к доставке приложений требует от бизнес-подразделений и ИТ-службы иных партнерских взаимоотношений. ИТ-директор должен убедить своих коллег в необходимости такого партнерства. И они должны иметь возможность ощутить открывающиеся перед ними преимущества, не заблудившись в дебрях Agile Manifesto и технического жаргона.
Между тем ИТ-директора и сотрудники ИТ-служб продолжают бороться за соблюдение принципов agile-методологии и полноценное претворение в жизнь методов Agile и поддерживающих технологий внутри самой ИТ -службы. По оценкам Уэста, большинство (от 70 до 80%) корпоративных ИТ-служб при реализации программных проектов в той или иной степени используют принципы agile-методологии. В качестве сдерживающих факторов выступают унаследованные технологии и привычка считать ИТ-службу центром затрат, предоставляющим стандартные услуги.
Все это затрудняет ИТ-службе переход к agile-методологии, ее сотрудники встречают сопротивление со стороны бизнес-подразделений.
ИТ-директорам, продвигающим концепцию «гибкого» предприятия, приходится бороться с укоренившимся изолированным мышлением, когда каждое подразделение озабочено лишь тем, что лучше для него, а не общими приоритетами организации.
Продвижение концепции agile. Преимущества и ограничения
Дэнис Гуле, использующий полученный ранее при разработке коммерческого ПО опыт проектирования по agile-методологии на своей нынешней позиции руководителя ИТ-службы штата Нью-Гэмпшир, при выстраивании «гибкого» предприятия вынужден преодолевать самые разные трудности. (Под «гибким предприятием» он понимает организацию, придерживающуюся итерационного ввода систем в эксплуатацию и культуры взаимной подотчетности.)
По его словам, руководители бизнес-подразделений весьма неохотно берут на себя роль владельца продукта и с трудом выделяют время для взаимодействия с ИТ-службой в ходе реализации спринтов.
«Мы задаем все больше и больше вопросов, людей это раздражает и вызывает у них сомнения в том, что задачи решаются наилучшим способом, — указал Гуле. — Им кажется, что вы пытаетесь выведать у них слишком много. Но это не так. Просто весь процесс меняется. И такой неизбежный переходный этап становится одним из самых трудных».
Следуя agile-методологии, Гуле придерживается поэтапных и устойчивых изменений. Совместные группы, сформированные из представителей ИТ-службы и бизнес-подразделений, решают возникающие вопросы общими усилиями. Уровень их полномочий, равно как и ответственность, растет. Люди понимают, что от них ждут максимально быстрой диагностики и устранения проблем. Поэтапная доставка становится нормой. А затем внимание акцентируется на внесенных изменениях и достигнутых успехах.
«Я не использую терминологию Agile, — признался Гуле. — Я просто говорю, что надо сделать конкретно то-то и то-то, и объясняю, какие выгоды это принесет».
С тем что ИТ-директорам следует придерживаться такого подхода, согласны и другие. Необходимо внедрять agile-методологии и добиваться успеха, после чего делиться историями его достижения с высшими руководителями, вызывая у них желание опробовать новые методы работы.
Для этого нужен ИТ-директор, выступающий скорее в роли продавца, предпринимателя, предлагающего новый способ мышления. О ценностях, результатах и вызовах надо говорить на языке бизнеса, уходя как можно дальше от методологий и технологий. Попытки объять сразу всё не дадут эффекта. Как правило, успешный ИТ-директор обучает пять-шесть человек, после чего берет пару небольших проектов и добивается их действительно хорошей реализации. Таким образом, создается достаточный импульс, для того чтобы охватить всю организацию.
Конечная цель заключается в формировании организации, которая вбирает в себя принципы agile-проектирования и превращается в предприятие, где говорят не о старых системах или проектах, а о закладывании нового фундамента в соответствии с имеющимися приоритетами.
Баланс между ИТ-службой и бизнес-подразделениями
Но ИТ-директора предостерегают от перегибов, утверждая, что уделять чрезмерное внимание agile-подходам в организации все же не стоит.
Да, ИТ-директору нужно, чтобы в бизнес-подразделениях понимали ценность принципов Agile, а их руководители становились владельцами продуктов.
ИТ-директор, приняв на себя ответственность владельца продукта, должен заручиться поддержкой своих коллег, которые помогли бы сформировать правильный менталитет и отношения в возглавляемых ими подразделениях. От руководителей бизнес-подразделений необходимо добиться поддержки agile-разработки.
Нужно сформулировать приоритеты и определить, что понимается под минимально жизнеспособным продуктом. Это потребует тесного взаимодействия между теми, кто лучше понимает предлагаемые ценности (является владельцем продукта), и технологической командой.
И Тонер понимает, насколько важно достичь нужного баланса. Он не намерен пускаться в пространные объяснения идей Agile, но пытается убедить своих коллег из бизнес-подразделений в том, что, работая по-другому, они извлекут немалую выгоду. Традиционному подходу, подразумевающему меньшую вовлеченность и долгое время ожидания, противопоставляется новый тип партнерства, при котором очередные функции внедряются за недели, а затраты оказываются ниже, но требуется более активное участие.
И такой новый подход способен привлечь даже скептически настроенных руководителей.
— Mary K. Pratt. Moving agile beyond IT: The secret to successful software delivery. CIO. AUG 21, 2018