Технологии Agile

Страница: 1

Сообщений 1 страница 4 из 4

Поделиться12016-04-11 17:09:25

Автор: snezhinka
Администратор
Зарегистрирован: 2008-06-30
Приглашений: 0
Сообщений: 58685
Уважение: [+410/-21]
Позитив: [+458/-283]
Провел на форуме:
1 год 0 месяцев
Последний визит:
2020-03-18 05:07:47

Эпоха бета-версий: почему предприниматели-перфекционисты проигрывают

Сергей Рыжиков,
Основатель и генеральный директор «1С-Битрикс»

Многие предприниматели тратят время и деньги на то, чтобы создать идеальную компанию, лучший продукт. На самом деле любой бизнес лучше запускать как можно раньше, даже если он далек от совершенства

Греф и лузеры

В начале 2016 года на Гайдаровском форуме Герман Греф буквально парализовал внимание огромного числа политиков и экономистов. Он вынес на массовое обсуждение термин Agile. «Те, кто не освоят Agile сегодня, в текущих бизнес-процессах, будут лузерами завтра», — невозмутимо заявил Греф собравшимся в зале, как следует не пояснив, что же это, собственно, такое.

Программисты знают: Agile — это гибкая методика разработки программных продуктов небольшими командами. Она ориентирована на разделение большой задачи на мелкие и быстрое их выполнение с помощью коротких итераций. При этом Греф в своем докладе утверждал, что тот же принцип нужно применять не только в IT, но и в организации любых процессов — как в бизнесе, так и в общественной жизни.

Главной причиной стала скорость развития технологий, которая не дает довести до идеала ни один проект. Как только вы заканчиваете работу над каким-нибудь продуктом, он тут же начинает устаревать, если еще не устарел, пока вы над ним работали. Оставаться конкурентоспособным можно только в ритме постоянных изменений, и производить их нужно с невиданной раньше скоростью, к которой общество уже привыкает, хотя и не успело как следует адаптироваться.

Тема Agile всплыла, когда Сбербанк создал централизованную платформу для всех своих отделений на основе решений Oracle, Microsoft и других IT-гигантов, но к моменту запуска эта система уже устарела. Греф это признал, и систему пришлось совершенствовать. В 2015 году «Сбербанк-Технологии» провели 27 тыс. изменений IT-платформы, а в 2016 году собираются сделать 41 тыс. изменений. Пять лет назад программисты Сбербанка проводили 500–600 изменений системы в год, и налицо огромный прогресс, но с передовыми компаниями IT-отрасли им не сравниться — Amazon, например, делает 10 тыс. изменений своей платформы в день.

Греф справедливо рассудил, что не только программисты, но вообще весь Сбербанк должен работать по тем же принципам, без этого быстрые перемены невозможны. «Вот руководитель крупной хедхантинговой компании сидит на ступеньках, ноги поджал, — сказал Греф посетителям форума. — Примерно то же самое мне нужно делать в своей компании, чтобы все менять». Что имел в виду Греф? Прежде всего, нужно отказаться от привычки долго готовиться, прежде чем что-то сделать, и решать задачи пусть не идеально, но сразу как только возможно. Если долго искать место — прослушаешь выступление, но можно просто войти в зал, быстро сесть на ступеньки и выслушать все, за чем пришел.

Малый и быстрый

Случается, что мелкие предприниматели, далекие от IT и интернета, интуитивно применяют технологии Agile. Владелец маленького бюджетного кафе открывает заведение сразу же, с недоработанным ассортиментом и наспех оформленным интерьером, а потом потихоньку улучшает. Конечно, он поступает так от недостатка средств, но его подход, как ни странно, очень современный. Он стал обязательным условием для успешного ведения дел в любой другой сфере бизнеса.

Долго работать над запуском и выдавать законченный продукт — самая большая ошибка предпринимателя. Я знаю одну строительную компанию, лидирующую на своем рынке, которая уже около двух лет работает над своим интернет-магазином. Они быстро сделали сайт-визитку и с тех пор «вычищают» каталог. Я говорю им: начните торговать с тем, что есть. Они отвечают: не можем, у нас же сотни тысяч позиций. На самом же деле запустить магазин нужно было сразу, и потом каждую неделю пополнять ассортимент. Пытаясь за год или два создать идеальный продукт, вы получите «дрова», которые можно выкинуть сразу, потому что вы слишком затянули время.

Работая над системой управления сайтами, мы хорошо знаем ожидания пользователей интернет-магазинов, и про принципы Agile мне проще всего рассуждать на примере е-commerce. Так вот, запуская интернет-магазин еще в 2014 году, вы могли не делать адаптивную версию сайта и ограничиться обычной. Год спустя, в 2015 году, у вас уже не получилось бы игнорировать тот факт, что мобильные пользователи интернета скоро составят большинство, и адаптивная версия сайта уже стала хорошим тоном. Теперь, в 2016 году, именно с нее и надо начинать, а десктоп-версию создавать, только если успеваешь. За два года привычки и потребности клиентов изменились полностью, и даже за год работы над сайтом вы бы не попали в их ожидания. Вывод: запускайтесь как можно раньше, а все доработки сделаете потом, в формате коротких итераций, с оглядкой на реакцию клиентов.

Приведу пример, ставший хрестоматийным: когда в компании «Эльдорадо» решили сделать интернет-магазин, топовые руководители, включая генерального директора, совещались несколько часов — спорили, ругались, смотрели сайты похожих компаний на западе. И все это еще на этапе утверждения дизайна. В конце концов, как вспоминает один из участников встречи, гендиректору все это надоело. Он попросил вывести на экран скриншот интернет-магазина Best buy и сказал все точно скопировать и через три месяца запустить, а если не получится — готовиться к увольнению. Все вопросы к дизайну сразу рассосались, интернет-магазин открылся 1 сентября 2006 года с кучей «глюков», но к концу года уже торговал без проблем и на новогодних продажах окупил затраты на разработку. Уже через полгода после запуска вышла новая версия дизайна, потом еще одна и так далее — сайт все время дорабатывался и дорабатывается до сих пор.

Толкай и властвуй

Все это похоже на биологию: есть гены, но этапы развития организма и индивидуальности сильно зависят от внешних условий. Когда мы запускали «Битрикс24» термин Agile еще не был настолько известен, как сейчас, и мы пользовались собственным названием для этой технологии — «метод кратковременных направленных толчков». Но суть его была такой же: первый релиз «Битрикс24» мы выкатили быстро, он был сырым и недоделанным, а потом — раз в полгода — мы выпускали новый релиз с дополнениями и доработками.

Когда вы открываете интернет-магазин, то через четыре, а максимум через шесть месяцев начинайте продавать, даже если вам не нравится дизайн и есть ошибки. Выдерживать итерации раз в четыре месяца в нашей стране получается наиболее органично (что первое время и делал интернет-магазин «Эльдорадо»). Первый такой период — с января по апрель: в начале января работать не получится, но можно строить планы, а со второй половины января по апрель — работать. Второй период — с мая по август: в первой половине мая также можно только планировать, но потом работаешь до августа, когда снова наступает спад деловой активности. Наконец, третий период — с сентября по конец декабря.

Разрабатывайте интернет-магазин за один такой период и открывайтесь сразу, как только сможете, с табличной бета-версией на главной странице. Не стесняйтесь: мы вступили в эпоху бета-версий, и законченных продуктов больше нет. Недавно я заказывал кофе в офис, и в заказе было вложено письмо, где были фотографии сотрудников и короткие истории к ним — кто из сотрудников и как улучшил работу кофейни за последнюю неделю. Показывать клиентам, что вы постоянно меняетесь и развиваетесь, гораздо важнее долгой работы над «идеальным» продуктом. В любом случае в моем опыте еще ни разу не было такого, чтобы компания, открыв проект, ничего не переделала в первые три-четыре месяца его работы.

С масштабами бизнеса, как у «Эльдорадо», повезло не всем, а Сбербанк — и вовсе уникальная организация, так что месяцы работы могут показаться слишком долгим сроком. Тогда достаточно наметить большую цель и двигаться к ней итерациями, которые измеряются неделями или вообще днями — тут главное сохранить принцип. Например, маленький интернет-магазин за одну итерацию может решать одну проблему и запускать одну новинку, оценить работу по двум противоположным показателям — конверсии и удовлетворенности клиентов, и если оба показателя растут, значит, вы двигаетесь правильно. Начинайте следующую итерацию и двигайтесь к большой цели, после которой, конечно же, будет новая.

Точка зрения авторов, статьи которых публикуются в разделе «Мнения», может не совпадать с мнением редакции.

http://www.rbc.ru/opinions/business/11/04/2016/570b66ff9a7947cefc664df0?from=typeindex/opinion

Поделиться22017-04-14 22:56:38

Автор: snezhinka
Администратор
Зарегистрирован: 2008-06-30
Приглашений: 0
Сообщений: 58685
Уважение: [+410/-21]
Позитив: [+458/-283]
Провел на форуме:
1 год 0 месяцев
Последний визит:
2020-03-18 05:07:47

Бизнес по Грефу: как российские компании становятся гибкими

21:09

Илья Носырев

В офисе компании МТС
Фото: Владислав Шатило / РБК

Модная бизнес-методика Agile по замыслу позволяет компаниям быстрее создавать новые продукты на основе обратной связи с клиентом. На практике нередко получается «как всегда» — ведет к бессмысленным баснословным расходам

«Те, кто не освоит Agile сегодня в куче бизнес-процессов, будут лузерами завтра» — такое грозное предупреждение сделал глава крупнейшего российского банка Герман Греф на Гайдаровском форуме в январе 2016 года. Почему президент и председатель правления Сбербанка стал горячим приверженцем и главным российским идеологом новой методики управления бизнес-процессами?

Agile в переводе с английского означает «проворный», «гибкий». В бизнес-обиход это слово вошло в феврале 2001 года, когда на лыжном курорте в штате Юта 17 корифеев в области программирования и управления из ведущих IT-компаний подписали «Манифест Agile».

Суть этой методики, ориентированной на гибкость в разработке новых продуктов, такова: в отличие от привычных моделей управления, которые называют «водопадным» или «каскадным», потому что все решения как бы текут сверху вниз, Agile предполагает эффективное и тесное взаимодействие сотрудников разных уровней. Они сами определяют, над какими продуктами и как надо работать. Вместо строгой иерархии и профильных отделов — временные межфункциональные команды (объединяющие, например, программиста, дизайнера и маркетолога), где все равны и ориентированы на конечный результат. Вместо планерок и цепочек согласований — быстрое решение проблем в ходе назначаемых по необходимости встреч. Вместо долгосрочной стратегии и детального календарного плана — постоянная трансформация продукта под меняющиеся нужды потребителя.

Идеология Agile увлекла многих, среди компаний, которые ее применяют, — Google, PayPal, Acrolinx, Moody’s, Facebook и другие мировые гиганты. В России после выступления Грефа тоже, кажется, только ленивый не говорит о переходе на гибкие бизнес-технологии. «Agile — это не мода, это борьба за здравый смысл, стремление сделать хороший продукт, а не выполнить формальный план», — говорит Agile-коуч компании OnAgile Дмитрий Лобасев.

Но как эта модель работает в российской реальности?

«Туту.ру»: естественная эволюция

Гибкая разработка пришла из IT, и опрошенные РБК эксперты сходятся во мнении, что именно для компаний этой отрасли внедрение Agile более чем логично. «IT не та сфера, где допустимы тонны бумажек и бесконечные согласования, — считает Алексей Спасский, гендиректор IT-компаний Phobos и Deimos. — Рынок технологий — самый конкурентный и динамичный, он не растет простым масштабированием. У небольших и быстрых команд здесь все преимущества. Android, например, разработали восемь человек».

Софтверные компании часто сами приходят к Agile. Так получилось у российского туристического онлайн-сервиса «Туту.ру». С управленческими проблемами компания столкнулась, когда переживала бурный рост, в 2013 году штат отделов разработки и тестирования достиг 40 человек, рабочие процессы стали запутанными, менеджеры, ответственные за разработку разных продуктов, вели постоянную битву за опытных специалистов, нагружая их одновременно десятками задач. А разработчики софта жаловались, что ничего не успевают довести до ума. Решение созрело само. «Мы разделили людей на небольшие команды по семь—девять человек и сосредоточились на том, чтобы делать полезные для клиента функции сайта, а не просто выполнять задачи в рамках своей роли, — вспоминает технический директор «Туту.ру» Вадим Мельников. — Уже через месяц полноценно заработали пять команд».

Менеджеры, которые сами не программировали, а контролировали решение задач, смогли сосредоточиться на изучении потребностей аудитории и отслеживать большее количество проектов. И хотя число команд разработчиков удвоилось, это не потребовало увеличения штата менеджеров.

Использование практик Agile на всех уровнях позволило «Туту.ру» всего за три месяца разработать новый продукт «Автобусы», позволяющий покупать в онлайне билеты на междугородные автобусные рейсы, быстрее конкурентов среагировать на появление новой линейки тарифов у авиакомпаний (билеты по сниженным ценам для пассажиров без багажа) и добавить опцию поиска таких билетов.

Мельников убежден, что полноценно внедрить Agile в компании удалось именно потому, что общий стиль управления в компании всегда был неформальным и гибким: «Наш Agile — это в первую очередь мировоззрение руководителей и владельцев компании, признающих лучшим способом решения конфликтов на стыке компетенций коммуникацию, а не иерархию». Впрочем, он подчеркивает, что никакого революционного ускорения процессов внедрение Agile не дало: «Не было такого, чтобы было плохо — и вдруг стало хорошо, хотя в среднем все улучшилось».

Для небольшой компании, разрабатывающей онлайн-приложения, Agile — естественное решение. Куда труднее отказываются от иерархии в пользу скорости в крупных корпорациях.

Владимир Хренков
Фото: Владислав Шатило / РБК

МТС: без фанатизма

В МТС об Agile задумались, когда компания стала выходить на новый для себя рынок — стала предлагать решения на стыке IT и телекоммуникаций. «Здесь очень важны сроки разработки продуктов: если будешь долго делать, то либо конкуренты опередят, либо спрос может пропасть, — рассказывает директор центра инноваций МТС Владимир Хренков. — Поменялся подход к производству: оказалось выгоднее не сосредоточиваться на долгой разработке больших и сложных продуктов, а в сжатые сроки выпускать так называемый минимально жизнеспособный продукт (MVP) и тут же начинать улучшать его, получая обратную связь от клиентов».

Agile-методики внедрялись в компании постепенно. В конце 2015 года директор департамента развития МТС Галина Ильчук пригласила консультанта по Agile Дмитрия Лобасева помочь улучшить работу одного из IT-направлений. Компанию не устраивала скорость, с которой разрабатывались новые программные продукты (в среднем 1,5–2 года), а также постоянные срывы календарных сроков. Проведенный Лобасевым аудит выявил несколько проблем, типичных для крупных компаний. Менеджеры не заботились об удовлетворенности клиентов, считая, что главное — подписать акты, и совсем не стремились иметь обратную связь по уже сделанным приложениям. Начальство приняло — и хорошо. Все решения по разработке новых программ требовали согласования 15–20 менеджеров, которые вместо того, чтобы встретиться и договориться по спорным моментам, вступали в затяжную переписку.

Организовав работу многофункциональными командами, в которых бок о бок работали сотрудники разных направлений, руководство компании добилось сокращения числа согласований в несколько раз. Также оказалось, что некоторые приложения и функции, которые давно и упорно разрабатывали программисты, уже не нужны пользователям.

В результате стало меняться отношение к подготовке проектов. «Например, компания отводила на разработку корпоративного портала более года, — рассказывает Дмитрий Лобасев. — В итоге мы провели тендер и сделали его всего за три недели. Запустили, протестировали. Обратная связь позволила улучшать портал уже в процессе работы».

Успешно опробованный на IT-направлении подход стал постепенно внедряться во всей компании. Созданный в октябре прошлого года инновационный центр МТС, подчиняющийся напрямую президенту компании, имеет простую структуру: это три команды по десять человек, в аппарате — всего три человека, которые занимаются координацией команд с другими направлениями.

У каждого сотрудника центра только один ключевой показатель успешности — выполнение задачи, над которой сейчас работает его команда. Члены команды сидят в одной комнате, чтобы общаться на короткой ноге и избегать ненужных совещаний. «Теперь мы выпускаем MVP за три месяца и сразу начинаем общаться с клиентом, — говорит Хренков. — Например, в прошлом году решили запустить услугу облачных вычислений и хранения данных для крупных корпоративных клиентов. Быстро запустили ее в самом простом варианте, и первый же клиент сказал: у вас только один центр обработки данных — ЦОД, что будет, если с ним что-то произойдет? Мы создали еще два в Петербурге и Новосибирске, и услуга сразу стала более востребованной». По такой же модели было создано приложение «Телемедицина», позволяющее консультироваться онлайн с врачами разного профиля. Сейчас инновационный центр МТС выпускает приложения по четырем направлениям: облачные технологии, цифровое здоровье, образование, киберспорт.

Существенно упростилась в компании и процедура финансирования проектов: раньше процесс мог тянуться месяцами, теперь вопрос о выделении относительно небольших для компании денег — до 100 млн руб. — может решаться в течение одного дня.

Хренков считает, что причина, по которой у МТC получается извлекать пользу из Agile, заключается в отсутствии фанатизма: «Мы не стали переводить на Agile все 75 тыс. сотрудников: тиражируем успешные подходы очень постепенно, адаптируя под каждое направление. Работа над некоторыми проектами, требующими крупных вложений средств и времени, связанных с большими рисками, останется каскадной».

NPM: «железо» со скоростью Facebook

Новосибирская компания NPM, один из крупнейших в России производителей оборудования для индустрии напитков, несколько лет назад начала поставлять свои аппараты за рубеж и столкнулась с жесткой конкуренцией. «И наши, и зарубежные производители оборудования для розлива пива в среднем готовят новый аппарат около двух лет, но по качеству и дизайну изделий они ушли на десятилетия вперед. Догнать их при равной скорости разработки невозможно», — говорит Agile-директор NPM Сергей Чирва.

В компании Сергей работает почти 20 лет — занимался маркетингом, поднимал продажи. Новую должность придумал себе два года назад, когда увлекся гибкой методологией разработки и, вдохновившись примерами Facebook и Amazon, задумался, можно ли производить новые аппараты путем итераций, то есть выпуская сначала базовую версию, а затем ее обновления. «Продукты в реальном производственном секторе создаются и меняются годами, — говорит Чирва. — Может ли заимствованный из IT подход увеличить скорость и качество в производстве «железа»? Наш опыт доказал, что может».

В качестве пробного камня была выбрана задуманная конструкторами компании интеллектуальная система Craftap Smart, которая могла бы в автоматическом режиме разливать пиво в тару любого объема, подавляя при этом образование пены.

Традиционная схема разработки — маркетологи создают концепт устройства, конструкторское бюро делает прототип, потом другие отделы готовят документацию, тестируют и, наконец, передают в производство. Руководство NPM решило рискнуть и делать новый аппарат так, как делаются программные продукты: поскорее выпустить первый вариант, а потом его дорабатывать.

Руководство компании выделило для работы над устройством специалистов из разных служб. Конструкторы работали в связке с маркетологами и специалистами по производству. «По самым смелым планам мы хотели разработать продукт в два раза быстрее обычного — за 12 месяцев, — говорит Чирва. — В результате сделали за шесть и продали целую партию, в основном за рубеж. Если бы мы разрабатывали Craftap Smart по обычной схеме, то до сих пор были бы далеки от первых поставок, а возможно, не создали бы его никогда».

Разработка и производство первой партии обошлись в 7 млн руб., уже на седьмой месяц с начала разработки было продано устройств на общую сумму 3 млн руб. (один аппарат стоит $3 тыс., или около 180 тыс. руб.), а к концу 2017 года компания планирует продавать Craftap Smart на 10 млн руб. в месяц.

Этот пример не уникален. Сейчас консультант по Agile Лобасев сотрудничает с одной из крупнейших сетей АЗС: помогает оптимизировать строительство новых заправок. «Здесь мы столкнулись с классической проблемой «колодцев». Речь о том, что в компании несколько подразделений, которые сосредоточены на исполнении процессов и выполнении своих KPI: это разведка подходящих площадок, юристы, безопасность, строители, розница, — говорит Лобасев. — С другими направлениями каждый «колодец» общается, переправляя тонны документов по почте. Мы объединили представителей этих «колодцев» в единую Agile-команду и предложили им встречаться несколько раз в неделю по утрам, чтобы совместно обсуждать вопросы по всем объектам».

Когда люди стали общаться на регулярной основе, выяснилось, что отдельные направления могут не ждать друг друга — например, юристы с удивлением узнавали, что могут начать оформлять документы еще до окончания основных работ по проекту, а не через месяц, как планировалось изначально. А главное — быстрее стали выявляться проблемы (со сроками, новыми требованиями от дорожных служб и т.п.), а значит, и быстрее стали обсуждаться пути их решения.

Беспощадный Agile

Если послушать пропагандистов Agile, то можно подумать, что эта методика — панацея, но это далеко не так, уверяет Алексей Спасский. Как правило, адепты этой методики умалчивают о провалах, ссылаясь на неэтичность упоминания компаний, где дело не пошло на лад. Но таких примеров немало.

Когда Сбербанк в 2012 году пригласил Дмитрия Лобасева внедрять Agile, из пяти созданных им команд фактически заработала лишь одна. Методики гибкого проектирования вступили в конфликт с 14-уровневой иерархией банка. «Это то, что принято называть наследием — корпоративная культура, которая сопротивляется изменениям», — говорит Дмитрий. Насколько продвинулось внедрение гибкой методологии разработки, можно судить лишь косвенно. Например, больше недели Сбербанк готовил комментарий к этому материалу РБК, но так и не смог его согласовать.

Если компания следует моде, не слишком хорошо понимая, чего она хочет в итоге достигнуть, внедрение Agile обернется пустой тратой денег, говорят все опрошенные РБК эксперты. И это недешевая ошибка. «Специалисты по Agile в банках и крупных компаниях получают от 100 тыс. до 600 тыс. руб. в день, — говорит Лобасев. — В среднем на начальный этап трансформации компании тратят около 10 млн руб.».

Многие признаются, что на протяжении первых месяцев Agile-трансформации в компаниях царит неразбериха. «Сотрудникам, которые так не работали раньше, это непривычно и дискомфортно, — рассказывает руководитель российской компании — разработчика игр RPF Анти Данилевский. — Кто-то считает, что это трата ценного рабочего времени, и воспринимает негативно». По наблюдениям Хренкова, рядовые сотрудники принимают перемены легче, а вот менеджеры, как правило, недовольны — ведь они теряют возможность использовать сотрудников для решения своих задач. В практике Лобасева были примеры, когда сопротивление менеджеров было столь сильным, что компаниям приходилось выбирать: либо сворачивать реформы, либо увольнять сопротивляющихся.

Гендиректор IT-компании Accera Анатолий Шеин отмечает следующий парадокс: Agile в большинстве компаний внедряется по каскадной методологии. То есть руководитель приказал, отделы потратили деньги и отчитались об успешно проведенной Agile-трансформации. И это показывает, насколько практика все еще далека от теории.

http://www.rbc.ru/own_business/14/04/20 … m=detailed

Поделиться32018-02-16 05:30:30

Автор: snezhinka
Администратор
Зарегистрирован: 2008-06-30
Приглашений: 0
Сообщений: 58685
Уважение: [+410/-21]
Позитив: [+458/-283]
Провел на форуме:
1 год 0 месяцев
Последний визит:
2020-03-18 05:07:47

Гибкая разработка меняет бизнес: как Agile помогает увеличить прибыль

Бизнес все активнее внедряет Agile-методологию. Гибкое управление проектами дает возможность оперативнее достигать результата: поэтапный ввод в строй отдельных законченных элементов проекта и начало работы с ними увеличивают шансы в борьбе с конкурентами. Адаптивная структура уже проникла в банки, промышленность и ритейл. Отходить от классических «водопадных» моделей помогает профильное ПО, без которого Agile уже сложно представить.

28.12.2017

Чем выгодно планирование в облаках

Почему мир стремится к Agile

Сегодня бизнес уже отчетливо осознает необходимость тотальной цифровой трансформации для выживания на рынке. Многие из тех, кто не позаботился о преобразовании ИТ-инфраструктуры под современные вызовы, уже проиграли более расторопным противникам. Agile — история как раз об этом: уже не модная или инновационная методология, но прочно вошедшая в инструментарий бизнеса, который не хочет остановиться в развитии.

«Agile-подход уже перешел в разряд базовых техник работы с проектами, стал частью стандартного рабочего процесса, — считает Алексей Явкин, генеральный директор компании «Бастион Интегратор». — В каждом отдельном случае необходимо правильно определить стратегию управления проектами, будь то Agile, гибридное решение или классический «водопад». Если говорить о небольших компаниях и стартапах, то в них можно обойтись без водопадной структуры — практически все процессы могут исполняться по Agile».

В своих исследованиях аналитики Gartner неоднократно подчеркивали, что трендом в современном бизнесе стал переход от классических «водопадов» к философии Agile при управлении проектами. Достижение цели — через короткие итерации, важная составляющая успеха — вовлеченность в работу всех заинтересованных подразделений компании.

Важное правило гибкой разработки — внесение изменений на ходу. Зачастую проектируемая система или приложение имеют лишь общий вид, а детали добавляются уже в процессе. Это обстоятельство еще и психологически раскрепощает сотрудников — на них не давит некий жесткий заранее одобренный и обязательный к исполнению «План», предписывающий каждый следующий шаг. Но, конечно, Agile — это не тотальная свобода, это еще и результат: перед каждым участником команды стоят определенные задачи, которые должны быть выполнены в определенное время.

Поэтапное исполнение общего проекта и такой же поэтапный ввод в строй определенных элементов конечного продукта олицетворяют постоянно прибывающую новую пользу. Не всегда она востребована «здесь и сейчас», бывает, что она еще и легко встраивается потом, спустя месяцы после ввода решения в эксплуатацию. Все это позволяет оперативно менять стратегии коммуникаций с клиентами и те сервисы, которые может предложить им компания. В Альфа-Банке, например, реализуется инициатива «Единый фронт»: этот проект постепенно заменит все существующие разрозненные системы взаимодействия банка с клиентом, включая каналы самообслуживания.

«В новом подходе модули разрабатываются параллельно небольшими agile-командами, количество которых не ограничено. Что, кстати, также является одним из важных аспектов культуры цифрового бизнеса. Модули дополняют друг друга, как кусочки паззла, при этом переключение между ними происходит совершенно незаметно для клиента или сотрудника, что создает единое гармоничное восприятие. Клиент и не подозревает, что работает на разных серверах и инфраструктуре. Более того, общаясь с банком через разные каналы — отделение, колл-центр, систему самообслуживания — клиент или сотрудник использует ровно одно и то же приложение», — рассказывает директор по архитектуре и стратегии блока ИТ Альфа-Банка Сергей Радул.

Гибкость формируют машины

По мере эволюции методик управления проектами, развивается и предназначенное для этого программное обеспечение.

«По опыту, который мы можем видеть на примере наших компаний-заказчиков, есть достаточно ощутимый эффект от использования Microsoft Project. Например, с точки зрения упрощения работы, сокращения времени на выполнение рутинных операций в рамках управления проектов. Также идет улучшение контроля и прозрачности самой компании внутри. Все это приводит к снижению рисков срыва сроков сдачи проекта. Это положительно влияет на финальный результат проектной деятельности», — перечисляет Алексей Явкин выгоды от использования профильного ПО.
Даже после перехода к гибкой разработке придется определяться, каким из нескольких способов ее вести. Сам Agile — действительно философия, но не готовая методология. Разработать на ее основе конкретную последовательность шагов — времязатратная задача для действительно вдумчивого менеджера. Но в реальной жизни у руководителя проекта нет времени на изобретение велосипеда. К счастью, со временем появились готовые шаблоны, наиболее действенными из которых оказались Scrum и Kanban. Они также добавились к традиционной «водопадной» структуре, которую раньше можно было использовать во вспомогательном ПО.

Scrum фактически разбивает проекты на отдельные части. Он состоит из спринтов и бэклогов (в оригинале — «product backlog» — «задел продукта»). Первое — это отдельно взятая итерация, которая обычно длится не больше месяца, но речь может идти и о часах, если сам проект относительно небольшой. Второе — некие ключевые задачи, которые выполняются в «спринте». Каждая из выполненных задач, как правило, уже несет в себе определенную функциональность. Оправдывая тем самым еще один из ключевых принципов гибкой разработки: поставки функциональности должны происходить еще до завершения проекта. Само собой, после каждого спринта происходит разбор ошибок предыдущего этапа и оценка достигнутого результата. Содержание будущего спринта обсуждается перед его началом. Но определенные коррективы могут происходить и по ходу дела. Например, по итогам постоянно происходящего обсуждения, которое используется как рабочий инструмент.

«Одним из самых показательных проектов этого года мы можем назвать проект по внедрению решения Microsoft Project для ИТ-дирекции в крупнейшей трубопроводной монополии, — рассказывает Алексей Семидетнов, генеральный директор компании «Контек». — В соответствии с конкурсной документацией, нами были определены этапы, сроки и стоимость. Но функциональному заказчику требовались видимые промежуточные результаты, при которых погружение в проект с его стороны не потребует высоких временных затрат, а для нас — выхода за рамки проекта. Решением в данной ситуации послужило применение Scrum и использование Project для управления задачами между спринтами. Таким образом, мы остались в рамках договорных этапов, и смогли продемонстрировать требуемые промежуточные результаты, необходимые для нашего клиента».

Kanban — история даже более старая, чем Scrum. Впервые эту методологию начали применять еще в 50-х, и представляет она собой визуализированное представление Agile. Она и не такая строгая, поэтому время спринтов достаточно гибко меняется под изменяющиеся условия. Один сотрудник может выполнять сразу несколько задач, что в Scrum нежелательно.

Когда это были физические доски, на смену которым пришли маркерные. Весь процесс достижения цели разделяется на столбцы. А задачи, выполнение которых поможет этой цели достичь, принято прописывать на карточках или стикерах. Они перемещаются в столбцах по мере своего развития. Но количество задач на каждом этапе ограничено. И это при том, что некоторые из целей можно оставлять на полпути, если меняется их приоритет или необходимость в них вовсе отпадает. Именно приоритет определяет порядок попадания задач из бэклога в работу.

Примером перехода на к гибкому управлению может служить история внедрения корпоративной системы управления проектами, осуществленного компанией K2IT. Заказчиком выступила компания с широкой сетью медицинских представителей во многих регионах России, одновременно осуществляющая большое количество проектов в различных областях: строительство нового производства, вывод новых лекарственных препаратов на рынок, оптимизация бизнес-процессов, развитие персонала. Перед компанией встала задача повышения эффективности исполнения разноплановых проектов.

«Было принято решение о создании и внедрении на базе программного обеспечения Microsoft Project корпоративной информационной системы управления проектами, позволяющей осуществлять централизованное планирование и контроль как набора взаимосвязанных проектов (программ и портфеля проектов), так и отдельных проектов, с целью принятия необходимых управленческих решений», — рассказывает вице-президент московского отделения PMI Александр Зубрицкий.
Ключевыми принципами внедренной системы стали календарно-сетевое планирование проектов, ресурсное управление проектами, управление проектными рисками, мониторинг и контроль исполнения самих проектов, контроль за коммуникациями между участниками рабочего процесса, максимальное ведение проектной отчетности с оценками выполнения задач, соответствия сроков, нагрузки персонала.

Выгоды для заказчика выразились в сокращении сроков реализации проектов за счет совершенствования и автоматизации процедур планирования и контроля выполнения работ, повышении качества мониторинга проектов и принятых решений, а также эффективном управлении трудовыми ресурсами.

«Преимущества внедренной системы следующие: настраиваемый набор проектной отчетности; возможность мониторинга портфеля проектов на основе усовершенствованной системы отображения информации; настройка критериев автоматического определения критичности отклонений по срокам для задач и для проектов, — перечисляет Александр Зубрицкий. — Также настроены оповещения сотрудников о событиях системы при помощи почтовой рассылки, а интеграция с 1С упростила формирование проектной отчетности. За дистанционное обучение сотрудников работе в корпоративной системе управления проектами отвечает специальный онлайн-модуль».

Когда нельзя выбрать между Agile и «водопадом»

История «Agile против «водопадов» еще недавно была одним из ключевых противостояний как среди теоретиков, так и среди практиков. Сторонники жестких структур доказывали, что Agile не позволяет четко зафиксировать итоговую стоимость проекта и не дает гарантий по срокам завершения проекта, ведь на любом из этапов могут возникнуть сложности. В ответ они слышали, что главное — не потраченные деньги, а результат, да и не всегда у бизнеса есть достаточно четкая концепция проекта, чтобы представлять с точностью до секунды сроки завершения работы над ним. На это адепты «водопадов» говорили, что и сроки, и бюджеты могут строго ограничены по независящим от исполнителя причинам. Но приверженцы Agile резонно отмечали, что заказчик должен быть не только инвестором, но и партнером, а сам конечный продукт вообще может стартапом в подверженной постоянным изменениям сфере бизнеса.
Конец этой войне положило создание гибридных форм управления, которые позволяют в рамках одного проекта использовать преимущества и «водопадов», и Agile, практически сводя к нулю их слабые стороны за счет, например, распараллеливания процессов по ходу решения действительно больших задач.

«Что касается, последней редакции Microsoft Project, то там становится возможным объединение нескольких техник управления в рамках одного проекта, а также использование преимущества каждого из них для достижения наибольшего эффекта результативности и управляемости проекта. Кроме этого, появляется возможность использования в рамках одного инструмента нескольких методологий: водопад, Scrum и Kanban, что дает значимые преимущества руководителю проекта», — отмечает Алексей Семидетнов.

«Microsoft Project, который теперь поддерживает методологию Agile, открывает широкие возможности по внедрению гибридных решений. Ранее приходилось внедрять и связывать несколько решений, что конечно же по определению сложнее. Теперь проектное управление как по методологии «водопад», так и по Agile-философии, реализовано в одном продукте, соответственно, внедрение, настройка и управление становится значительно проще», — соглашается Алексей Явкин.

После обновления функционала Microsoft Project (в потребляемой из облака десктопной версии) отпала необходимость вести тонкую настройку. Теперь существует готовый набор новых шаблонов, представлений и столбцов, которые вместе делают управление проектами более гибким. Вместе с тем, появились инструменты, которые наглядно визуализируют трудозатраты, статусы, спринты и прочую аналитику по проекту.

Для частичного перевода проекта в Agile в представлении задач проекта достаточно добавить столбец «Гибкое планирование». Управлять гибкими задачами можно вручную, но лучше доверить это облачному приложению Planner. Для обеих методологий доступны широкие функции управления. При использовании Scrum, например, можно создавать и переименовывать спринты, а также настраивать их длительность, дату начала и окончания.

Широки и варианты представления. В Kanban это могут быть листы или доски, а в Scrum — это и доска, и лист бэклога, и лист текущего спринта. Формат досок удобнее для перемещения задач между этапами. Добавление в бэклог задач и их исполнителей производится через удобное меню. User story, как и в обычном «водопаде», моделируются через суммарные задачи.

Чем выгодно планирование в облаках

Немалое влияние на развитие способов проектного управления оказали облачные технологии. И, пожалуй, нет ничего более логичного. Agile-команды — гибкие, геораспределенные, мобильные — отчаянно нуждаются в инструментах для продуктивной совместной работы. Им нужно быть на связи, работать в едином пространстве, максимально полноценно переносить в онлайн-совещания эффект физического присутствия.

Исследование, проведенное экспертами Evans Data Corporation, свидетельствует о том, что облачная платформа, совмещенная с принципами гибкой разработки, сокращает время создания конечного продукта на 20% в сравнении с использованием одного только облака. При этом из-за этапности осуществления проекта появляются новые возможности, которые приводят к ускорению получения реальных бизнес-результатов.

«Microsoft Project — это уже привычная для заказчиков среда. К тому же, обучение достаточно простое. Существенным преимуществом также является возможность построения кастомизированных отчетов. За счет простых и понятных инструментов очень просто выстраивать системную аналитику под конкретные цели и задачи компании. У Microsoft Project, как в серверной, так и в облачной версии, есть простая интеграция с инструментами бизнес-аналитики, построения отчетности и визуализации: PowerBI, Power View и другие. У Microsoft есть множество решений как для клиентов, так и для разработчиков, с простой и бесшовной интеграцией. Безусловно, это положительно воспринимается заказчиками», — резюмирует Алексей Явкин.

«Экономия средств — прямое следствие применения гибкой разработки. Когда ты правильно планируешь может сложиться ощущение, что ты начинаешь делать что-то медленнее. Ты всегда ждешь каких-то циклов, пытаешься работать системно. Но, когда ты оцениваешь на каком-то длинном горизонте, ты понимаешь, сколько денег ты сэкономил, потому что ничего не переделывал, — уверен Егор Ланько, директор по omnichannel «Азбуки вкуса». — Важно перестроить сознание команды и планирование, понять, что нужно двигаться системно. И на долгосрочном горизонте это действительно эффективно с точки зрения экономии и времени, и средств. И делаешь ты в итоге больше, потому что ты ничего не переделываешь».

В конечном счете настолько широкий и вариативный набор методологий при максимальной поддержке со стороны технологий и программного обеспечения серьезно развязывает руки современному бизнесу. Это позволяет ему концентрироваться именно на бизнесе как таковом: извлечении прибыли через оказание услуг или продажу необходимых товаров.

http://www.cnews.ru/special_project/2017/microsoft/