В России понятие Business agility (бизнес-гибкость) довольно прочно ассоциируется с командами. Считается, что достаточно собрать в одну или несколько Agile-команд людей из разных отделов – и они тут же начнут быстро выдавать продукт, который порадует клиентов. Почему же этого часто не происходит?
Нет инфраструктуры для быстрых экспериментов
Agile-команда – это группа, объединяющая от 5 до 10 человек разных специальностей, компетенций которых хватает для самодостаточного создания ценного продукта. Команда выдвигает гипотезу, проверяет ее на пользователях и по результатам улучшает продукт. Работает такая команда короткими спринтами. Соответственно, чтобы работа была эффективной, Agile-команде нужны полномочия, возможности и инфраструктура для быстрых, недорогих и безопасных экспериментов и проверки гипотез. Нет инфраструктуры – не будет и скорости.
К примеру, в одной компании, производящей пельмени, блины и полуфабрикаты, решили ввести Agile-подход: руководство не устраивало, что вывод нового продукта на рынок занимал 4-8 месяцев. Запустили Agile-команды, технологи и дизайнеры приступили к работе, но оказалось, что для выпуска нового продукта все равно приходится ждать несколько месяцев. Почему так? Потому что выпуск зависит от основного цеха и основной производственной линии. А там уже существуют собственные планы по выпуску продукции, и команду просто не пускают в цех на пару дней для пробного производства 100 кг новых пельменей.
Вывод прост: даже введя стендапы и спринты, отсутствие инфраструктуры не поможет увеличить скорость работы, и Agile-подход становится бессмысленным.
В компании приняты годовые бюджеты
Что такое годовой бюджет? Как правило, еще летом руководство начинает обсуждать бюджет на следующий год, а осенью проходят жаркие дебаты. И каждый проект, который команда планирует запустить в следующем году, нужно обосновать с финансовой точки зрения: сколько денег потратится, сколько будет командировок и так далее. Финансовому департаменту без разницы, как именно вы работаете, ему нужно сверстать и проконтролировать годовой бюджет.
Но с Agile-подходом это невозможно. Agile – это высокая степень неопределенности, фактически, туман вокруг задач. При этом подходе невозможно дать точные оценки, потому что команда не знает на 100%, чем будет заниматься в следующем году. Сегодня вы думаете, что нужно сделать сайт, но после проверки гипотез станет ясно, что нужен чат-бот, а это совершенно разные бюджеты.
То есть, сначала команде нужно тыкать пальцем в небо и придумывать оценки, а потом в условиях жесткого финансового контроля работать в рамках своей сметы, которую она писала в прошлом году. Это очень серьезное ограничение гибкости.
Если при этом у компании есть стратегия повышать свою капитализацию, то от команд требуют заранее показать план с расчетом капитальных и операционных расходов. Но Agile-команда не может заранее знать, сколько функций будет добавлено в продукт (капитальные затраты), а сколько времени уйдет на исследования или исправления дефектов (операционные). При этом финансовый отдел продолжает требовать план, а потом не разрешает за него выходить. И это – прямое противоречие с Agile-подходом.
Решения об инвестициях принимают пару раз в год
В большинстве компаний решения о более-менее серьезных инвестициях принимают на самом верху, и для получения или увеличения бюджета команде приходится согласовывать каждый шаг на собрании, которое собирается, например, раз в квартал. Это тоже серьезно влияет на гибкость и скорость работы.
Представим ситуацию: команда видит, что в продукт необходимо внедрить искусственный интеллект. Своих компетенций нет, значит, нужен подрядчик. Но вместо того, чтобы начать поиски и работу, приходится считать и обосновывать бюджет, а потом отчитываться. Почему это столько стоит? Вы провели анализ рынка? А теперь напишите нам экономическое обоснование. Отлично, приходите в большой комитет, который все посмотрит и, возможно, одобрит такие расходы. Следующее собрание через три месяца.
И команде приходится на это время брать паузу, хотя рынок и клиенты не ждут. Пока мы ходим по кругам и сидим без дела, конкуренты могут все сделать и внедрить. Момент будет упущен.
Долгие тендерные процедуры
Когда у команды есть потребность в подрядчике, это уже не чисто финансы, а еще и закупочная процедура. Если в компании тендеры устроены бюрократически сложно – а это обычная ситуация в крупных российских компаниях – закупка занимает несколько месяцев. Сначала нужно оформить закупочную документацию, провести тендер, выбрать победителя, заключить с ним контракт и только после этого он начнет работать.
Естественно, такая длительная процедура снижает скорость работы. Кроме того, подрядчиков часто выбирают по бумажкам, критерии оценки – цена, подтверждение былых заслуг, квалификация персонала (всех, а не только команды на проект). Также нужно учитывать – если в компании подрядчика работает огромная иерархическая бюрократическая машина, вероятно, он не сможет полноценно работать с вами в Agile-подходе. Не сможет выделить людей, которые будут ежедневно работать с вашей командой, станет затягивать сроки, подключать бюрократию и согласования. Работы в нужном темпе просто не получится.
Так что при переходе в Agile нужно менять процесс и критерии выбора подрядчиков, уходить от традиционной тендерной системы, создавать подходящие контракты и процедуры.
Устаревший подход к составлению контрактов
Здесь проблема в структуре контракта с подрядчиками. В России существует две крайности. Первая – контракт фикспрайс. Вы даете исчерпывающее техзадание, а подрядчик оценивает, сколько будет стоить его реализация. Любые изменения вносятся через дополнительные согласования, а это длительная непростая процедура.
Вторая крайность – Time And Materials (Т&M). В этом случае вы даете часовую ставку и каждую неделю подписываете с подрядчиком time sheet, в котором отражаете, сколько часов мы отработали, сколько отработал дорогой специалист, сколько недорогой. Проблема здесь в том, что подрядчик не несет ответственности за результат, он просто предоставляет людей, которые что-то делают, а мы оплачиваем их время. Если подрядчик хороший, ответственный, то он работает на результат, но если подрядчик хитрый и непорядочный, то он может специально затягивать сроки и проект, чтобы побольше получить денег.
Соответственно, с текущими контрактами на заказчике остается много рисков. Выход – искать более сбалансированные модели для контрактования, в которых у вас с подрядчиком будет общая ответственность за результат, и чтобы не снижать гибкость.
Работая по agile, нужно уходить от подробных техзаданий, которые снижают гибкость. Можно фиксировать цели на уровне бизнес-результатов. К примеру, если вы делаете мобильное приложение, опишите, какие у него цели, но не добавляйте нюансов вроде того, какие кнопки и где будут, и сколько именно требуется функций.
HR-процессы тормозят бизнес
К примеру, Agile-команда понимает, что ей не хватает нужного специалиста, допустим, дизайнера. Обращается в HR-отдел и сталкивается с типичными ограничениями крупной компании. Система найма включает в себя 15 раундов собеседований, каждого претендента нужно показать ряду топ-менеджеров (у которых плотный график). Потом нужно проверить всех в службе безопасности чуть ли не на полиграфе.
В итоге хорошие сотрудники могут вообще отказаться идти в такую компанию, им неинтересна подобная бюрократия. И даже те, кто готовы это терпеть, вынуждены долго проходить все круги собеседований и согласований. О какой скорости может идти речь, если несколько месяцев ждать нужного сотрудника? Безусловно, подбор кандидатов для Agile-команды должен быть совершенно иным. Возможно, стоит доверить команде право самостоятельного квалификационного отбора кандидатов и только проверять их соответствие общим требованиям компании.
Еще один нюанс, который может развалить даже успешную команду – принятая в компании система мотивации. Часто принято разделять ответственность: если что-то пошло не так, ищут виноватого, и депремируют его одного, а остальные участники команды по-прежнему получают премию. Такой подход разобщает. При работе в стиле Agile – да и вообще при любой работе – стоит стремиться к групповой ответственности за результат. Либо все молодцы и получают премии, либо вся команда совершила ошибку, и не выигрывает никто. От персональных премий лучше отказаться.
В общем, если ваша цель – реальное повышение скорости и гибкости компании за счет перехода к Agile-принципам, настраивайтесь на большую и серьезную работу по изменению текущего уклада. Без Agile-команд не обойтись, но много вопросов лежит вне их компетенций.
Очень хорошо
Agile это панацея. Каждый проект это уникальный предмет, который находится под влиянием имеющихся обстоятельств среды, в которой он будет реализоваться, если вообще среда подходит. Каждый проект это уникальный предмет, который находится под влиянием действующего законодательства и не урегулированных пробелов (пробелы это риски понести в будущем расходы или даже уголовную ответственность (пример: разбирательство ФСБ РФ с операторами ПДн, осуществляющих обращение с применением средств шифрования)).
По моему мнению при кодировании самое главное не допустить в коде ошибку, которую может злоумышленник эксплуатировать. Именно на этом необходимо в первую очередь сосредоточиться, иначе репутационные расходы могут быть настолько высоки, что "не отмыться" до конца жизни.
Скептицизм порождает предвзятость. Предвзятость допустима, но ограничена нормами законодательства. В частности п.2 ст. 401 ГК РФ - Отсутствие вины доказывается лицом, нарушившим обязательство. Таким образом, если лицо подозревается в нарушении обязательства, то ему необходимо доказать отсутствие своей вины. Типа: Взялся за гуж не говори, что не дюжь! (даже, если не гуж, а куш взял :-)
" Команда выдвигает гипотезу, проверяет ее на пользователях и по результатам улучшает продукт. " - Мне кажется, это он сам придумал. Что значит, когда экспертом себя называет человек, который сам никогда не сделал ни одного продукта.
Не работаю уже несколько лет, но когда работал (а работал среди обычных пользователей без спец ИТ образования) находился под впечатлением, что разработчики ПО производят по гипотезам. :-)
Но по гипотезам может прокатить, когда ПО пользуется множество лиц в разных частях России или мира. Можно вообще впарить о "моде" или о "тренде". Быть по моде и в тренде это же круто :-)
Пролог: Agile, Scrum, Lean ... сколько новомодных "новых" технологий морочат голову прежде всего руководителям, а потом и всем остальным. Если "оглянуться" на 20-30 лет назад - всё это уже было, просто называлось иначе.
А теперь конкретно по статье: как написал предыдущий комментатор (наверное, пытался написать) "Agile не панацея" автор пытается оправдать новомодное слово, что оно как раз не панацея. И что? В чём уникальность статьи? Да и ежу понятно, что не дав любому проекту/инициативе ресурсов и возможностей - ничего не заработает и не взлетит! Тогда уж, Вы уважаемые "суперспециалисты новых технологий" должны были на старте проекта обозначить требования. И, в случае, не выполнения этих требований даже и не начинать этот проект. Вот именно в этом и заключается профессиональность, а не в том, чтобы ввязавшись в проект, "наломать дров", а потом обвинять Заказчика, что он чего-то не предоставил или не знает ...
Это все очень правильно. Только вот вызывает удивление (не только здесь) ссылка на "Agile" - команды и на Agile Manifesto (не дай Бог) как на что-то сакральное. Ничего нового: какую команду не набери, как ее не назови, как ни заставь работать, но если ВСЯ система управления вокруг команды не будет целостной и/или Agile, т.е. гибкой, то люди ничего не смогут вынести во вне своей команды. Оно там попросту не нужно, а иногда даже раздражает. Вот тут-то и начинается самое интересное. Нигде этому не учат, мало кто сам старается этому научиться. А если и старается, то обычно на себе, любимом, на своих "кошечках" методом проб и ошибок. Чему "этому"? Так управлению как комплексу прикладных наук. Там много всего, надо все это уметь интегрировать, применять избирательно "под среду" и даже, не поверите, под конкретных людей. Не всем нужно гибкое управления. Как правило, в крупных компаниях есть участки, где оно нужно, но есть и такие, где оно противопоказано. Ну кто станет на это заморачиваться? Ведь управление в лучшем случае - вспомогательная деятельность. В худшем - каждый может это делать после назначения на соответствующую позицию. Помните про знаменитую "доярку - кухарку"? Чего удивляться-то?
И давно уже исполнители работ устанавливают требования к заказчику в отношении исполняемых работ? Ну на этапе консультаций конечно заказчик может получить сведения об исполнимости своих фантазий, которые он считае существенными. Я к тому, что заказчику (особенно из гос сектора) необходимо знать хотя бы о ФЗ "О стандартизации в РФ" (для каких лиц он обязателен, а для каких и Agile прокатит).
Ну хорошо. Могу признать в реалиях России "Agile может быть не панацея".
ФЗ "О стандартизации в РФ" обязателен для применения каждым лицом органов власти и органов местного самоуправления, а по факту далеко не везде он известен.
Кроме того, в РФ более 1500 ФЗ и 22 Кодекса. А приказов и даже писем вообще не счесть, и задолбишься объснять служащему органов (даже являющемуся руководителем юр лица), что письмо вышестоящего начальства имеет меньшую силу ФЗ и Кодексов.
Вот я в такой России живу :-) от Agile практической пользы не вижу.
Но правда я и не разработчик, хоть и с программированием знаком не по-наслышке :-)
Может мне кто-нибудь объяснить, как можно получить расположение заказчика, если заказчик двух слов связать не может? (запад прошу не предлагать, потому что насколько мне известно они не "своих" не признают)
Все верно и принято считать сферу ИТ адвенчурным рынком. Причем приключения присутствуют у каждого участника ИТ рынка :-)
Но отвращает не это, а зажратость юзверей. Случай из моей практики: вызывает бухгалтер и обращается с просьбой сделать, чтобы принтер включался вместе с компом, а принтер при этом стоит рядом с монитором. В сосднем кабинете менеджеры жалуются, что у них МФУ не печатает, прихожу и нажимаю кнопку ВКЛ - МФУ включился и начал печать.
Вообще по моему мнению с имеющимся количеством ПО и популярностью комп игр, нужно упор делать на графический интерфейс юзера. Например: для силовиков можно сделать внизу экрана пистолет и изображение прицела, который перемещается с помощью мыши, а при наведении на "цель" по щелчку мыши производиться вызов функции для этого события. Я думаю силовики в очередь выстрояться за таким ПО :-)
Это системная ошибка, которая заложена в Руководстве по scrum, она находится в противоречии с ценностями и принципами Agile.
Сегодня команды-scrum занимаются в основном продукто-ориентированным подходом. Само Руководство очень четко и детально описывает деятельность команды, в результате которой можно сформировать её самоуправляемость.
Если улучшать бизнес-процессы, описанные в Руководстве клиенто-ориентированностью Agile, то гибкость, быстродействие и результативность могут зачительно улучшаться.
По-моему речь шла о внутренней agile-команде. Хотя это и не важно. Могу ответить - давно. Не важно, внешняя вы команда или внутрення, agile или просто подряд на выполнение задачи - вы выставляете требования к ресурсам компании, которые вам необходимы для реализации задачи. И как внешняя компания, вы закрепляете это в договоре.
Могу объяснить. Если вы имеете большой опыт реализации проектов в интересуемом бизнес-процессе заказчика, то вы начинаете говорить с заказчиком его языком. Тогда и заказчик может больше 2х слов связать и вы можете дать свои рекомендации по опыту уже реализованных проектов.