В России понятие 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 смотрится искусственной между прочим - а должна создавать ощущение раскованности и непосредственности. А представьте себя на месте человека прочитавшего ваши прошлогодние отчеты - разве он подпишет единолично расходы на что-то подобное? (нет, в комиссии, в комитете можно...) И проблема именно в качестве отчета, но не в успехе или неудаче продукта
Только вот что толку от перечисления причин? Если Agile команда полностью зависима от тех, кто в-целом, не нуждается в переменах, то в результате ... вас погладят по головке, но это будет единственным позитивным результатом.
Я думаю все подобные методики (Agile и другие) можно определить в одно семейство методик - Гы-гылити
Поколение G
G - gamers (геймеры, игроки комп игр)
Мы живем в обществе, в котором присутствует множество игроков компьютерных игр. Ими зачастую оценка окружающего мира осуществляется по знакомым играм. Зачастую ими используются методы и навыки, приобретенные при участии в компьютерной игре. Их же можно и нужно выделить в семейство G.
Таким образом, необходимым является классификация представителей семейства G.
В компьютерных играх возможно поведение двух основных видов: дрочеры и жорики. При этом обычно целью приобретения игровых достижений является получения хайпа (иначе говоря "гы-гы", затмевающее "гы-гы" других игроков - типа: сделал "пиу-пиу" и получил в награду "гы-гы").
Дрочеры выполняют все задания и таким способом приобретают игровые достижения.
Жорики покупают за реальные деньги ценности, способствующие им приобретать игровые достижения.
Задроченные жорики применяют оба пути для приобретения игровых достижений.
В современном обществе, чтобы Agile и подобные технологии стали ценностью, они должны быть доступны, как "гы-гы".
Как говорил Франсуа де Ларошфуко, «Все жалуются на свою память, но никто не жалуется на свой ум».
При этом, на место памяти в статье можно вписать (и вписано!) всё, что угодно — отсутствие инфраструктуры, мышление годовыми бюджетами… вплоть до «не тех» HR-процессов. Но не упомянуто главное — архаичные технологии принятия решений и генерации идей, в частности — примитивный «мозговой штурм» (детище Алекса Осборна без малого столетней давности — образца 1930-х годов).
Между тем, никакие технологии вторичной, инженерной разработки — ни гибкие, ни классические не заменят компании отсутствия инновационности и технологии правильной генерации инновационных идей. Точно также, как не заменят они культуры инноваций в целом.
Какая разница, какими методами внедрять СЛАБЫЕ решения? Бедным производителям полуфабрикатов новый сорт пельменей внедрить быстро не дают? А что реально нового в этих пельменях? Больше перца, меньше лука? На какой процент этот новый сорт увеличит прибыль? На пару процентов? Где реальная инновационность и внеконкурентность?
Попробуйте GB как методику и получите наконец-то культуру инновационных разработок, где не придётся жаловаться на сотни лишних безмозглых причин.
Или не пробуйте и оставайтесь бесконечно пережёвывать тему «Работает или не работает Agile». Что ещё вам остаётся?
Зачем мне танки, их кавалерия шашками порубает (c) Один эффективный менеджер
Ум это одно, а память это другое. Вы смешиваете не смешиваемое :-)
Типа: центральный процессор и жесткий диск представляете единым целым.
Александр, Вы читать умеете? Претензии — не ко мне, а к Франсуа де Ларошфуко, пожалуйста. Это цитата, между прочим. Закавыченная. С отмеченным авторством.
А во времена Ларошфуко компьютеров не было (сверьтесь по датам хотя бы с Википедией). Я же как системный администратор с 15-летним стажем в прошлом процессоры с памятью (ни с постоянной, ни с оперативной) на уровне архитектуры не смешиваю. Предполагать такое по меньшей мере странно.
Но, во-первых, никакого «смешения» в данном случае и нет. Системные сбои могут возникать как «в памяти», так и «в процессоре» (если вам такая метафора человеческих памяти и сознания ближе). Как, впрочем, и в любых других частях вычислительной системы. И даже на стыке систем. Например, нельзя исключать ошибки ввода. (Те же когнитивные искажения в случае человека.)
Ларошфуко лишь отметил, что все жалуются на сбои памяти, но не на недостаток ума. Впрочем, это естественно. Поскольку в силу следствий теоремы о неполноте Гёделя заметить недостатки «главного процессора» можно лишь из надсистемы, с уровня супервизора. Поэтому, определить недостаток интеллекта может лишь более развитый сторонний (!) интеллект.
Так что саможалобы на дурость, практически, исключены. Саморефлексия — вообще крайне затратна и слишком редка, особенно нынче. ;)
А во-вторых, ни процессор, ни память в отдельности функционального смысла не имеют. Рассматривать их функционирование имеет смысл лишь в рамках единой системы (компьютера). Она-то действительно с точки зрения главной полезной функции (вычисления) является единым целым. Как является единым целым и человек. («Медицинское» дробление на органы — лишь для упрощения анализа в частных случаях. Здоровье же, в том числе, интеллектуальное, комплексно.)
Учите матчасть, юноша.
Так же и с умом. Ум это одно, а память это другое. Память это типа примочка к уму при измерении интеллекта, так как кроме возмжностей запоминания информации имеет значение возможности манипуляций и вычислительных действий с имеющейся информацией, а это информации может извлекаться не только из памяти, но и других источников.
А относительно обеспечения безопасности (безопасного обращения с объектом), то принято составлять модель угроз и оценивать угрозы и риски, а также защиту от них, в связи с пораженной частью (модулем). Естесственно при обследовании пораженного модуля это модуль исследуется до атома, если такое возможно.
Если ближе к теме дискуссии - почему команды Agile такие ... потому, что из тех людей, кто организует, тренирует и внедряет модный сейчас Scrum, никто не знает или все молчат, что главное в в Agile - это не гибкость, а Дисциплина в работе и разработке. И все методологии Agile в первую очередь направлены на это - кроме Scrum ...
Вот Роберт Мартин - один из тех, кто написал Манифест - приводит такой пример: "Сколько из вас видели как СEO североамериканской Volkswagen давал показания перед конгрессом, обвиняя пару разработчиков программного обеспечения в том, что они подделали результаты тестов? "Ооо, это была пара программистов, которые с чего-то накосячили".
А знаете в чем дело? Это действительно была пара программистов. Может быть даже больше. Это они написали тот код, обманывающий тесты. Некоторые программисты так делают :
Если РежимТестирования Тогда
Сообщить("Все хорошо");
Возврат;
КонецЕсли;
Я даже думаю, что они осознавали, что делают. И в этом проблема. И будет день, когда кто-то из нас напишет программу, которая приведет к интересным газетным заголовкам. Что это может быть за программа? Да что угодно, от софта управляющего самолетом, до софта управляющего футбольным стадионом. Это просто вопрос времени".
Александр, не обобщайте так вольно компьютерную архитектуру на устройство человеческого интеллекта. Слишком уж они разные, а аналогии — грубые.
В курсе ли Вы, например, что обработка и запоминание информации в мозге, в отличие от компьютеров, тесно взаимосвязаны, осуществляются общими «узлами»? Или что механизм памяти и фантазии — общий, отличается лишь мелочами? (Например, дети их в принципе не различают.) И что поэтому каждое обращение к человеческой памяти творчески её перезаписывает — вплоть до полной противоположности?
Ну, а так называемые «тесты интеллекта» тестируют что угодно, кроме того самого интеллекта. Например, тот же объём памяти.
Так что, нельзя просто самоуверенно сказать, что «память — это типа примочка». Человеческий интеллект — СИСТЕМА. Включающая, в том числе и память.