Если вы работали в больших компаниях, то знаете, что это за ощущение: у вас вроде бы есть всё для реализации себя как профессионала, все условия для воплощения в жизнь любых идей и задач — однако что-то неосязаемое не даёт планам исполниться, а в голову лезут мысли, что инициатива наказуема и что хата твоя с краю. Когда я полтора года назад пришёл в ВТБ Лизинг, решил, что в моём департаменте всё будет по-другому.
Меня зовут Константин Морозов (morozovvtbl), и я руководитель управления развития информационных систем — то есть отвечаю за всю разработку в ВТБ Лизинге, а также лидирую Agile-трансформацию в компании. В этой статье я расскажу о том, как мы внедрили гибкую разработку в крупную компанию консервативного толка.
Весь последний год мы погружались в культуру Agile. Направление новое и прогрессивное по меркам финансового сектора, где консерватизм традиционно считают залогом надёжности. Потому Agile в связанной с финансами разработке часто воспринимают как игрушку для IT-стартапов.
К тому же ВТБ Лизинг — компания с устоявшимися технологическими и бизнес-процессами. Менять производственную культуру в таких организациях — задача особенно интересная и увлекательная.
Как было, когда я только пришёл
Большинство проектов, почти 80%, реализовывались с опозданием. Большинство заявок на автоматизацию (до 70%) исполнялись с задержкой. Структура компании вертикальная, с делением на департаменты по функциональности. Департамент IT работал на все подразделения и получал противоречивые требования от разных направлений. Продукт шёл через подразделения, преодолевая барьеры, вместо того чтобы готовиться одной командой.
Еженедельные «комитеты по изменениям» проходили с большим накалом. Все участники от IT воспринимали эти встречи как «экзекуцию» — показательную порку кого-нибудь из айтишников или даже всех сразу: человек 30 заказчиков отчитывало наших IT-тимлидов. В результате люди пачками увольнялись, не выдерживая стресса (в частности, именно это случилось с одним из ведущих разрабов). Всем всё важно, всем всё срочно. Годовое планирование представляло собой огромную массу задач от всех департаментов, необходимо было поставить сроки исполнения, а потом ещё и уложиться в них. Но на деле требования были нечёткие, а заказчик далеко не всегда понимал, чего хочет. От семи подразделений накопился список из 650 задач.
К началу 2020 года у нас оставалось 456 задач в плане релизов со сроками. При этом условия были ограниченные. Сколько потребуется времени? Какой нужен бюджет? До 40% заявок, созданных заказчиками в Jira, ими же и отменялись, а все камни летели в сторону IT-департамента как главного виновника всех бед («делают ерунду, не понимая, чего от них хотят»).
К примеру, «Электронный архив» мы реализовывали в два раза дольше, чем должны были: вместо шести месяцев у нас ушёл на него год, потому что в процессе вылезали уточнения.
В годовом плане менеджеры хотели от меня прибитых гвоздями обещаний. При том, что требования от департаментов были разрознены и сформулированы сумбурно, напоминая скорее гипотезы. Представьте, что у вас тысяча заявок, и одна из них сместилась. Теперь нужно на диаграмме Ганта смещать весь следующий за ней хвост из 500 других заявок. В декабре утвердили план, а уже в январе его пересматривали.
От IT требовали окончательных ответов и точных сроков при отсутствии какой бы то ни было ясности задач. Это вызывало постоянные конфликты: дать план на год вперёд и попасть в него невозможно. Слишком переменчивые условия. Было совершенно очевидно, что «проектная» тактика тут не сработает и нужно искать иной подход. Waterfall во всех направлениях деятельности привёл к появлению кучи регламентов, за которыми люди стали прятаться, и это явно не шло на пользу делу.
В итоге команда управления развитием информационных систем поняла, что нам нужна итеративная разработка с горизонтом планирования в один месяц (более длительные сроки относятся уже к категории ви́дения, а не строгого планирования), разделённый на спринты по две-четыре недели (их точное число каждая команда выбирает сама). А это, соответственно, уже Scrum. Мне очень сильно повезло прийти в компанию в тот момент, когда там появился новый генеральный директор, и он уже начал изменять ее. Хотя до IT еще не дотянулся. Все-таки важно, в какую почву падает посеянное тобой зерно, в каменистой земле шансов у нас было бы немного. И все равно на то, чтобы топы приняли идею Agile, ушло около четырёх месяцев: нужны были доказательства.
Доказательства
Компания в тот момент была еще очень консервативная, плюс коллеги не верили в возможность подобных изменений, а топы, как обычно это бывает, просили всё подтверждать на цифрах, которые без пилотного проекта взять было неоткуда. Раскручивать этот маховик пришлось долго.
Я использовал все инструменты, которые мог:
Выступал на всех доступных мне площадках (таун-холлы бизнес-подразделений).
При обсуждении каждой проблемной ситуации на совещаниях всех уровней подробно объяснял, как мы бы её решили при помощи Agile Scrum (а точнее, сделали бы так, чтобы проблема не возникла).
Узнал, что в нашей «маме» (ВТБ) использовались эджайлоподобные практики, и начал обращать на это внимание других: раз «мама» применяет — значит это работает!
Показывал на личном примере, как можно решать вопросы иначе, и стал собирать вокруг себя людей, которые действовали аналогично.
Мои усилия не пропали даром: лёд тронулся, и в итоге народ начал говорить про Agile. А когда идею обсуждают, её сложно игнорировать. В целом процесс переубеждения занял 3–4 месяца (с октября 2019 по январь 2020 гг.), а затем я получил благословение на запуск пилота, и оставалось только добыть цифры, доказывающие мою правоту.
С января по май 2020 года я собирал команды для пилота и неустанно пропагандировал им ценности Agile. Сам пилот продлился с мая по декабрь 2020 года.
Пилотный проект
Любой человек сопротивляется новому. И один менеджмент для эффективного запуска переубедить было недостаточно: загореться идеей должны были все. Чтобы достучаться до них, пришлось выступать с убеждающими презентациями на всевозможных мероприятиях. Я напрашивался на собрания подразделений, которые с IT даже не связаны (риски, поддержка бизнеса, продажи), и в свои выступления всегда вставлял пару слов про то, как бы то, о чём я рассказываю, «сработало по Agile». Было крайне важно, чтобы про Agile начали говорить все; чтобы слово «agile» стало ассоциироваться у коллег с выходом из сложной ситуации.
Поскольку у нас не было продуктов, на которых получилось бы доказать работоспособность идеи, в качестве пилотного проекта мы решили «локально оптимизировать» работу двух подразделений: департамента поддержки бизнеса и финансового департамента. Мы определили, что за сервисы/продукты есть в этих департаментах, определили бэклоги и на их основе сформировали StarMap для каждого из направлений. Это и был плацдарм для пилота.
Затем набирали людей в команду. Критериев отбора было всего два:
Должны гореть глаза.
Компетенции должны попадать в StarMap.
Мы сформировали кросс-функциональные команды под функциональные подразделения компании и организовали обучение заказчиков и айтишников гибким методам разработки. Все коммуникации и процессы пришлось выстраивать с нуля.
С самого начала мы пытались соответствовать ценностям Agile в работе и даже просто в общении. Снизили градус накала еженедельных встреч («комитетов по изменениям»), на которые собирались представители департаментов. На этих совещаниях мы действительно старались слушать друг друга. Вскоре решили попробовать Scrum: он хорошо подходит для тестирования гипотез и резкого изменения процессов, а ещё позволяет быстро выдавать результат и получать обратную связь. Последнее мы посчитали особенно важным: уж слишком много неопределённости было в пилотных целях и проектах.
Работали мы удалённо, используя Zoom, Miro и Jira; все команды запускались также в удалённом режиме. Честно говоря, тот ещё опыт: Agile — это ведь про людей и взаимодействие, а у нас эти люди раскиданы по всей стране.
В качестве метрик мы выбрали:
CSI (Customer satisfaction index; индекс удовлетворённости клиентов). Простыми словами: понравился ли вам продукт, воспользуетесь ли ещё?
Lead Time — среднее время выполнения задач пилотными командами (относительно первоначального показателя).
Количество ошибок в разработанном новом функционале продуктов (относительно первоначального показателя).
Оценка экономического эффекта в целом.
Количество зависших задач в очереди (бэклоге, долгом ящике).
Глобального методического плана действий изначально не было. Задача — показать результат изменений. Плана трансформации тоже не было — вместо него были вехи и верхнеуровневая путевая карта. Но я считаю, что способность гибко подстраиваться под реалии обратила эту нехватку в преимущество, несмотря на всплывающие, кхм, проблемы.
Да, в итоге именно отсутствие железобетонного плана помогло нам справиться. Мы быстро поняли, что, как и в любом другом проекте, эффективность нужно показывать на цифрах, и делали всё, чтобы понять, как наши действия влияют на ключевые метрики. После того как понимание пришло, мы действовали точечно, и результат не заставил себя долго ждать.
Раньше бизнес-процессы проходили через несколько систем, и каждое подразделение выпускалось порознь. Юзерам порой приходилось ждать месяцами (кусочек от CRM будет готов сегодня, 1С — через месяц, а Oracle — через два). Фактически, мы не могли поставить ценность, даже если все работали хорошо и быстро в рамках своих отделов.
В пилотном проекте мы несколько причесали процессы, добившись единого производственного цикла, когда все IT-системы обновляются синхронно. Это позволило добиться снижения сроков поставки интеграционных задач. Компетенции по IT-подразделениям постепенно начали выравниваться. Взаимодействие с заказчиками стало прозрачней и продуктивней для обеих сторон.
Велика земля наша, но порядка в ней нет: приходите и правьте нами
Ещё до старта пилота, на этапе формирования команд, я стал получать множество возражений в духе «Так не будет работать!». Я поймал себя на том, что постоянно рассказываю людям, как это работает, и безостановочно всех убеждаю. Когда этих людей двое-четверо, в этом нет ничего плохого, но их было за 30! И каждый из них готов был сделать всё, чтобы остаться в зоне комфорта. Стало понятно, что без профессионального тренера, который «укусит эджайлом», уже не обойтись.
Коуч был найден, и всё завертелось. Тренинг и последующее сопровождение команд длились два месяца, после чего команды стали потихоньку брать процессы в свои руки. Мы увидели, что культура Agile начинает приживаться. Более того, среди участников пилота появились убеждённые адепты этого подхода, которые стали проповедниками Agile-ценностей и активными участниками дальнейшей трансформации своих направлений. Пошла-поехала самоорганизация.
Скоро сказка сказывается, да не скоро дело делается
Убедить менеджмент дать добро на запуск пилота оказалось не самой сложной задачей (хоть и архиважной). А вот заразить всю остальную команду идеалами Agile, даже с помощью профессионального тренера оказалось не так-то просто.
Дело в том, что, как выяснилось, компания ещё не оправилась от неудачных попыток «внедрить Agile», предпринятых много лет назад.
Тогда, в доисторические времена, мой предшественник видимо совершил классическую ошибку - он нёс свет Agile в массы под видом упрощения процессов разработки.
В итоге инструменты Agile применялись бездумно, с единственной целью — не делать обязательных вещей вроде написания документации или регрессионного тестирования.
Ввиду искажённого восприятия культуры как чего-то механически «внедряемого» люди думали, что речь идёт о наборе ритуалов, которые должны сработать как панацея (в общем, что-то вроде карго-культа). Итог предсказуем: полное отсутствие документации, огромный bus-фактор в IT (ведь каждому проще заниматься тем, что он уже знает и умеет; зачем ему изучать что-то новое и распространять компетенции, правда?) и все вытекающие от этого проблемы:
негатив заказчиков;
низкое качество функционала;
непредсказуемая по объёму поставка;
сложность в поддержке.
Прежде чем запускать пилот, нам пришлось потратить около полугода (четвёртый квартал 2019 г. и первый квартал 2020 г.), чтобы «отмыть» Agile от прошлых неудач. К сожалению, некий негатив и неприязнь к нашим нововведениям сохранились у ряда сотрудников до сих пор. Есть и такие, кому Agile просто не зашёл по личным причинам. Например, после смены уклада жизни в компании некоторые лишились своего статуса незаменимых звёзд. И всё же с такими людьми, если они профессионалы своего дела, мы стараемся не расставаться, а совместно находить интересные области, где они могли бы продолжить расти.
Всплывало всякое:
разные KPI у смежных подразделений;
постоянные попытки «остальной компании» вернуть создаваемые Agile-команды в старые процессы (приходилось оберегать эти команды от уже сложившейся корпоративной культуры);
отсутствие в компании продуктовых и технических метрик (их пришлось создавать по ходу дела) и пр.
Итак, всего в пилотном проекте участвовали три команды на два направления бизнеса. От IT было около двадцати человек, от стейкхолдеров — примерно пять. Две команды из поддержки бизнеса запускались по Scrum. А вот в финансовом департаменте, как оказалось, лучше подошёл Kanban, потому что идея с быстрой поставкой там не сильно востребована. Там у них больше законодательства, внутренние и внешние аудиторы; да и вообще, финансовая область — это не про быструю поставку. Преимуществами Scrum они готовы пожертвовать в пользу визуализированного и предсказуемого результата. Поэтому мы решили не менять процессы резко, а идти к переменам последовательно. Благо Kanban позволяет отрисовать текущие положение и метрики, чтобы эффективно лечить там, где болит и где скапливаются заявки. Команды показывали планомерный рост и со временем самоорганизовались. В комфортный для себя момент они перешли к самостоятельному развитию от спринта к спринту. Теперь каждая команда чуть допиливает фреймворк под себя.
Отбираем продукты у подрядчиков
Хочу рассказать о кейсах, которые максимально наглядно показывают эффективность нашего подхода. Успех пилота дал нам повод забрать у не очень эффективных подрядчиков два продукта — «Автоматизированную систему службы сопровождения клиентов» и «CRM корпоративного блока» — и перенести их на внутреннюю разработку.
Сделать это было непросто ещё и потому, что в состав команд вошли сотрудники этих подрядчиков. Мы взяли их из-за нехватки ряда внутренних компетенций. Сотрудники подрядчика — это, по сути, работники с несколько иной мотивацией, нежели штатные сотрудники компании (и уж точно люди с другой культурой). Работа с ними просто не могла не давать сбоев. Например, вот что произошло с проектом «CRM корпоративного блока». Подрядчик неверно оценил сложность работы, а также не учёл систематически корректируемых ожиданий стейкхолдеров от системы и фактор изменчивости бизнес-среды. Чтобы исправить ситуацию, мы с нуля собрали команду из четырёх человек, запустили там итеративные процессы и начали прививать Agile-культуру. Сейчас эта команда разрабатывает новый лизинговый калькулятор для корпоративного блока, и мы ожидаем, что уже этой осенью до 80 % всех расчётов будет проходить на их продукте.
Есть мнение, что с подрядчиком реализовать успешную Agile-трансформацию нельзя в принципе, но мы вроде как справились — благодаря тому, что соблюдали баланс между штатными сотрудниками и работниками подрядчика в командах и старались, чтобы внутренние аналитики покрывали все компетенции с точки зрения понимания функционала, а программисты могли приходить извне. Правильная работа с людьми подрядчика и заключение договора T&M позволили создать одну команду, в которой подряд составлял целых 60 % от числа участников.
Перенос разработки внутрь и начало реализации по Scrum дали старт продуктовой разработке в компании; более того, на внутреннюю, домашнюю разработку мы теперь делаем ставку. Каждый год штат разработчиков растёт на 50 %. После ряда успешных кейсов в рамках Agile-пилота был выбран ещё один продукт, работу над которым мы начали строить по гибкой методологии: это конкурент каршеринга, который называется «Автомобиль по подписке». На рынке эта штука недавно, и сейчас её запускают в том числе и наши конкуренты. Было понятно, что столь сложную задачу, где нет времени на раскачку, нельзя запускать по классической модели Waterfall, и мы сделали ставку на Agile. Оперативно собрали команду из уже имеющихся заинтересованных сотрудников и начали работу. На разработку нам дали всего 5 месяцев!
Если MVP продукта получится вывести на рынок в ожидаемые сроки, мы плавно начнём перемещать подход компании с проектного в сторону продуктового.
Набитые шишки и наполеоновские планы
Результаты пилота порадовали как его прямых участников, так и вовлечённые стороны; опыт оказался позитивным и в качественном, и в количественном плане.
Самое главное — мы смогли сделать так, что многие стейкхолдеры из других направлений, не включённых в пилотный проект, стали приходить к нам с долгожданными словами: «Сделайте нам так же, как у вас в пилоте».
Количественные показатели:
Lead Time (средн.): −17 %.
CSI (средн.): +18 %.
Ошибки функционала: −40 %.
Прямой экономический эффект: +264.5 млн руб.
Очередь задач: −8 %.
Отзывы ключевых стейкхолдеров вполне благожелательны:
Владелец продукта в департаменте поддержки бизнеса:
«С появлением Agile-команды бизнес и IT начали говорить на одном, понятном друг другу языке, что способствует поступательному развитию операционной функции в компании. Команда разработки постепенно интегрируется с бизнес-средой, что позитивно сказывается на востребованности и качестве реализованного IT-продукта».
Scrum-мастер команды департамента поддержки бизнеса:
«Я была настроена скептически, так как у нас уже была неудачная попытка внедрения Agile. Мне не верилось, что эта методология сможет «лечь» на наши негибкие процессы. В итоге на обучении для меня стало неожиданностью, когда мы смогли решить неподъёмную на первый взгляд задачу всего за несколько итераций. Я осознала, что такое возможно. Мотивация выросла. Также очень большим сдвигом стало появление владельца продукта, который по максимуму освободил нас от решения несвязанных с работой нашей команды вопросов. Мне нравится приносить пользу, и сейчас эту пользу мы практически оцифровали, можем её измерить и почувствовать поддержку бизнеса!»
Положительный опыт даёт причины и мотивацию продолжать. В последнее время мы всё чаще слышим фразу: «Нужно масштабировать изменения».
В ходе прививания Agile в компании было создано нескольких кросс-функциональных команд для выпуска отдельных продуктов. Теперь мы стали всерьёз задумываться о глобальных изменениях:
Трансформация, уплощение оргструктуры компании в целом.
Применение «продуктового» подхода.
Больше in-house разработки; появление в командах выделенных Scrum-мастеров; развитие командных и продуктовых метрик.
Поднять уровень коллаборации между командами на новый уровень
Разработка собственной IT-платформы (окончательный переход на in-house).
Наша основная цель — осуществлять поставку ценности с гарантированным и предсказуемым качеством в рамках изначально согласованных сроков.
В 2020 г., благодаря гибкости в принятии решений, мой департамент смог реализовать идеи, эффект от которых составил почти на 3 млрд руб. больше, чем изначально планировалось. В 2021 г. мы хотим побить этот рекорд и дать нашей компании тот time to market, который ей необходим.
То, к чему мы теперь идём, получило в мировой практике название LeSS (Large-Scale Scrum), что означает «Scrum большого масштаба (масштаба крупной организации)».
При этом мы стараемся двигаться поступательно. После успешных «CRM корпоративного блока» и «Автоматизированной системы службы сопровождения клиентов» доводим до ума сервис «Автомобиль по подписке». Полная команда для работы над этим продуктом уже работает (аналитики, разработчики и др.). Дальше будем запускать новые продукты, последовательно переводя компанию на продуктовую разработку. Прямо сейчас формируются ещё три команды. У нас теперь есть свои Scrum-мастера, а также владельцы продукта, ответственные за видение и планы по развития своих продуктов на долгосрочную перспективу.
Послесловие
Убедить менеджмент принять Agile , безусловно, важно, но не слишком сложно при благоприятных обстоятельствах. Да, мне пришлось попотеть, но одобрение от руководства в итоге было получено (тут можно про них написать что-то хорошее типа «благодаря их дальновидности и вере в то, что это может сработать», но статья и так уже слишком длинная).
Гораздо труднее донести до всех остальных, что в Agile есть смысл, а потом суметь правильно привить им эту культуру.
Если воспринимать Agile как набор практик, которые просто нужно бездумно повторять, получится карго-культ. Когда я только пришёл в компанию, наблюдал последствия такого подхода. Восприятие Agile просто как методологи привело к тому, что люди натянули новые термины и определения на старый рабочий процесс (ведь бизнес у них никак не менялся) и перестали писать документацию, превратно истолковав одну из ценностей Agile-культуры. Потому-то мне и пришлось потрудиться, чтобы всех переубедить.
Но если всё с самого начала сделать правильно, жизнь всей компании кардинально улучшится. Опыт пилота помог мне понять, что вкладываться в людей и команду — это самая правильная инвестиция. Вот некоторые уроки, усвоенные за время пилота, которым я теперь следую:
Пилот должен длиться не менее шести месяцев. Это минимальный срок, при котором команды успеют перестроиться и реализовать хотя бы десятую часть своего потенциала.
Нужно проводить как можно больше агитационной и разъяснительной работы. Производственная культура живёт не столько в нормативных документах, сколько в головах и сердцах сотрудников.
Стоит доверять людям и не бояться давать им полномочия для решения задач и самоорганизации. Ведь грамотные специалисты в состоянии создать комфортную для себя рабочую среду. Да, звучит сентиментально, но так оно и есть — по-другому атмосферу не изменить.
Изменения в компании не возможны без полноценного вовлечения в них и всесторонней поддержки ее топ-менеджмента.
Давайте обсудим культуру Agile — особенно интересно было бы узнать о вашем опыте: удалось ли внедрить эти методы в вашей рабочей среде, как именно это получилось, или наоборот, почему Agile у вас так и не взлетел. Ну и, разумеется, если у вас есть вопросы, я могу подробнее рассказать о том, как сейчас устроена разработка в ВТБ Лизинге.
Комментарии (29)
Chelyuk
02.08.2021 20:37+1Молодцы конечно, но выглядит как микроскопом по гвоздями. Ключевая проблема - заказчик постоянно меняет требования. Я понимаю,когда речь в рынке и необхомисти перехода с ДВА на электромотор. Но когда так поступает внутренний заказчик, это прямой вопрос к его компетенции в коммуникации. Зачем терпеть кучу не компетентные людей в компании и исключительно в угоду им устраивать дорогую смену процессов? Смена 20 десятков людей на более компетентные и умеющих думать наперед даст ещё больший эффект,за гораздо более скромные вложения.
И ещё вопрос если нужен был Enterprise Agile + Scrum, почему не SAFE или Nexus SCRUM?
MorozovVTBL Автор
03.08.2021 00:32Интересный вопрос :) сейчас, скорее, мы проходим стадию "опрозрачнивания", т.е. за счет большого вовлечения стейкхолдеров в процессы: совместной с ИТ генерации идей, формулирования UserStory, регулярных демонстраций результатов работы спринта и т.д. мы показываем друг другу, что какие-то элементарные изменения могут влиять на результат. Это дает свои плоды, т.е. стейкхолдеры начали понимать, что каждое изменение должно приносить ценность, а не просто "хочу". Особенно дело сдвинулось, когда начали появляться "Владельцы продуктов". У нас они все от бизнеса, а не из ИТ. Вот эти ребята быстро смекнули, что ценные заявки должны быть в верхних строчках бэклогов, а то команда будет обходиться компании дороже чем эффект от ее работы :)
Да и вообще, Вы серьезно думаете, что так легко найти идеальных стейкхолдеров, которые к тому и не рядовые сотрудники (у нас и директора генерят идеи постоянно в погоне за изменениями рынка), да еще и они не должны хотеть всего и сразу? + предлагаете оценивать компетенции людей только по тому, сколько они генерят изменений? Мне за 20 лет работы в ИТ такие пока не попадались :) Думаю, что единственный способ победить "поток сознания" и отфильтровать ценные гипотезы - это оценивать эффект от каждой из них , приоритезировать и максимально быстро проверять идею. ВАЖНО потом проверять попадаем ли в ожидания, т.е. сколько в реале пришло денег от реализации.
По поводу SAFE или Nexus.
Это наше будущее. Вспомните свое первое знакомство со Scrum (например). Сама идея того, что можно делать продукты иначе была удивительна и чужда (ну, у меня так точно было :) ). Не думаю, что Вы сразу пошли сертифицироваться на PST (например). В школе мы тратим 11 лет для получения среднего образования, в институте 5 лет для высшего образования и т.д. Это я все к тому, что у всех разный уровень зрелости и трансформация начинается с разных уровней. У меня , на момент начала пилота, да и зарождения идеи трансформации, не было людей, которые понимали даже какие-то базовые вещи и могли отличить "Владельца продукта" от "Руководителя проекта", Scrum от Kanban и т.д. Масштабируемый Scrum (в тот момент) казался чем-то таким непостижимым и мы решили, что в пилоте это не нужно (не те масштабы). А вот сейчас..
У Вас есть практический опыт масштабирования Agile? Хорошо знакомы с SAFE? "тогда мы идем к Вам" за советами :)
achekalin
02.08.2021 22:23В начале Вы постулируете, что в крупных компаниях подход про «хату с краю» сам собой возникает. И далее говорите, что, когда пришли на это место, решили все изменить.
И вот тут связка лично мне непонятная: а откуда взялась эта уверенность, что получится, и откуда коллеги вдруг решили не в «хату с краю» поиграть? Размер компании, не говоря, что это ВТБ, как бы намекает на обратное.
MorozovVTBL Автор
03.08.2021 02:07Эх.. написал развернутый ответ , но не нажал "отправить" перед F5.. вечереет..
Попробую еще раз)
Вы верно подметили про "хату с краю", однако, я несколько о другом пишу. Думаю, что не будете спорить, большие компании дадут фору любому стартапу по части бюрократии. Иногда это все доходит до того, что внедрение элементарного улучшения/изменения процесса выглядит для сотрудника как прохождение миллиона итераций обсуждений, согласований, комитетов, собора подписей и т.д. Возникают "окольные тропы" в обход корпоративных процессов. Конечно, такое охладит пыл любого и потихоньку все приходит к той самой "хате".
Имея лидирующие места на рынке лизинга, разумеется, компания "ВТБ Лизинг" имеет возможность инвестировать в своих сотрудников большие ресурсы, при этом, странно помещать людей в условия, в которых они не смогут реализовать свой потенциал. Учитывая планы по предстоящим изменениям, мне хотелось создать такую среду, в которой было бы минимум преград на пути новых Agile-команд. Никаких "хат", только генерация идей и их реализация. Да, знаю, звучит пафосно, но идея была именно такая и таковой остается. Я уверен, что если люди занимаются любимым делом, человек не чувствует себя каким-то бесполезным винтиком в гигантской системе, у них есть реальная обратная связь от клиентов и возможность реализовывать свои идеи, то "хаты с краю" пропадают сами собой. Я искал людей, которые ГОРЯТ и на их примере старался показать остальным, что все возможно.
В том, что получится уверенности не может быть вообще. Была идея основанная на:
Личный опыт. Я уже проходил подобную историю в другой крупной финансовой компании (наверное, не этично писать в какой). Ситуация была аналогичной. Когда попадаешь в схожую среду, начинаешь видеть необходимость определенных изменений более четко.
Люди. Я начал с поиска сторонников и пытался вдохновить опытных сотрудников компании на изменения. Мы анализировали текущие процессы и продукты компании, попытались сформулировать видение развития продуктов вместе со стейкхолдерами, составляли звездные карты, собирали обратную связь от стейкхолдеров и ИТ-шников по части удобства текущих процессов и т.д. В итоге, коллективно сошлись во мнении, что все должно получиться.
Пилот. да, это более поздний этап, но любая гипотеза должна быть проверена. Пилот окончательно показал, что идея верная и при правильном масштабировании, мы получим отличный результат. После его успешного прохождения, на высшем уровне компании дали добро на масштабирование.
Еще немного про "хату с краю". Тут важно понять простую вещь. Вас окружают люди, а не какие-то злодеи, которые принципиально загоняют вас и себя в сложные условия. Я всегда придерживаюсь мнения, что если людям показать ситуацию, сделать предложение, которое подкрепляется реальным практическим результатом, то они будут меняться и менять окружение. Главное показать им их выгоду :) Когда у вас есть возможность напрямую влиять на тот продукт, который вы делаете, вы видите реальный результат своей работы в бою, благодарность пользователей и даже клиентов компании, вы точно не будете оставаться в стороне. Это не могло не сработать ;)
onets
02.08.2021 23:47С аджаилом есть одна проблема. Называется тяп-ляп и в продакшен. Так как никто не анализирует множество требований в совокупности и на противоречия до начала разработки - есть высокий риск на очередном требовании "добавьте кнопку" все переписать с нуля и не раз.
На легаси проектах, которые первично были реализованы по ватерфоллу - этой проблем никто не заметит, потому что на текущем проекте в основном текучка и устоявшиеся бизнес-процессы. А вот для стартапов, которые не знают, какой учет им потребуется партийный или серийный - аджаил вселенское зло. Даже если программист перепишет все за неделю, то наклейки придется печатать и переклеивать на коробках месяц-другой сутками на пролет и всей толпой.
MorozovVTBL Автор
03.08.2021 02:19+1Давайте разберем Ваши тезисы. У увидел:
Agile это тяп-ляп
Agile больше подходит для легси-проектов , в которых доработки - мелочь, а на стартапах Agile-зло, т.к. может быть много изменений.
Постараюсь ответить (соответственно):
Есть такой термин DoD (Definition of Done) , т.е. уровень вашего тяп-ляпа вы способны определить самостоятельно. Например, в последние 1,5 года мы очень активно развиваем автотесты. Не скажу, что достигли потрясающих успехов, но наш функционал покрыт автотестами > 70%. Учитывая, что 100% и не нужно, то ИМХО мы в состоянии проверять состояние регрессионного функционала. Так вот, прежде чем что-то выпустить, системы проходят полный цикл тестирования (скоро еще DevOps историей займемся и будет ваще здорово :) ). Таким образом, как написано в статье, с появлением Agile истории в командах, они даже снизили уровень багов и это тенденция сохраняется вот уже более года (с момента старта пилота).
Тут мне сложно комментировать, т.к. например, Scrum, лучше работает именно на стартапах, где надо быстро проверить идею и оперативно подстраиваться под изменения среды. Приведу Ваш пример чуть иначе чем Вы: "Для стартапов, которые не знают чего им надо, Waterfall настоящее зло, т.к. о том, что программисту надо все переписать, компания узнает не через неделю, а через месяцев 6 или даже больше, т.к. первым этапом пойдет аналитика, в результате которой будет БТ , слова в котором будут звучать правильно, а вот как их реализует программист.. уж все мы видели этот мем с качелями и деревом". Таким образом, я призываю не бояться необходимости переписывать, нужно бояться того, что об этом мы узнаем слишком поздно. Пользователю и клиенту важен продукт (даже если с ним что-то не так, то вы узнаете об этом раньше и сэкономите кучу денег).
onets
03.08.2021 09:32Если выделять тезисы, то он один - применять аджаил к месту.
Дело не в DoD и тем более не в тестах. Дело в отсутствии общей картины и достаточного анализа. Другими словами в отсутствии более-менее продуманного ТЗ на первое время. Что приводит к факапам, но не с точки зрения аджаила (у него как раз все хорошо), а с точки зрения бизнеса, людей, времени и денег. Область видимости аджаила ограничена, чтобы видеть всю картину и все проблемы, которые он создает.
Таким образом, я призываю не бояться необходимости переписывать, нужно бояться того, что об этом мы узнаем слишком поздно.
Например это. Изначально аджаил оперировал только таким артефактом как программное обеспечение. Если же заглянуть в ГОСТы 19/34, то там можно обнаружить другие виды обеспечения (организационное, методологическое и так далее). Переписывание программного обеспечения - это лишь малая часть.
Я в своем комментарии привел пример из своего опыта. Это обычный бизнес по продаже некоторого физического товара, который захотел новомодные ИТ-штучки и франшизу. Вместо аджаила лучше было бы сесть, подумать, описать бизнес-процессы и обкатать их хотя бы в голове, а лучше на складе, убрать противоречия, увидеть более полную картину. Другими словами составить ТЗ. А вот уже потом включать аджаил, заполнять бэклог, запускать спринты и болтать на митингах часами рабочего времени каждый день. В итоге это займет допустим неделю. А еще пойти на склад, расставить товар по полкам, наклеить свои штрихкоды и ценники, и это займет месяц-два.
Пользователю и клиенту важен продукт (даже если с ним что-то не так, то вы узнаете об этом раньше и сэкономите кучу денег).
Нет, клиенту на самом деле важно увеличение прибыли, уменьшение расходов, поток клиентов, благоприятная атмосфера в рабочем коллективе. И где-то потом уже продукт. Только аджаил этого не замечает.
MorozovVTBL Автор
03.08.2021 12:17Сложно конечно в комментариях дискутировать на такие глобальные темы. Попробую сформулировать свои мысли на этот счет:
Agile это культура. Культура не применяется. Судя по всему, вы говорите не про сам Agile (c его ценностями и принципами), а про Scrum, как фреймворк, который предписывает выполнять определенные мероприятия. Кто мешает не использовать Scrum, если он, по определенным причинам, не подходит?
"Agile" это адаптивная история. Зародилось это все в ИТ, но уже давно покинуло рамки лишь ИТ. Agile позволяет бизнесу максимально быстро получить MVP для проверки принятых решений и , вообще, тот продукт, который ему нужен, т.е. позволяет оперативно давать обратную связь разработчикам и корректировать свои потребности. Какая ее модель позволяет получать такую гибкость и за счет чего?
Про Ваш пример из личного опыта могу сказать, что тут вина не Agile. На начальной стадии не был сделан User Story Mapping, т.е. сразу ломанулись что-то делать не видя процесса (не отрисовав его). "Agile Scrum" не говорит , что надо так делать. Обычно это результат неграмотного трактования принципов Agile. Например, похожая история была в ВТБЛ до меня. От такого "внедрения" мне пришлось имя "Agile" еще отмывать несколько месяцев (на это слово было наложено проклятье :) ). Вы все верно говорите, но в том, что так не сделали, как Вы пишите, вина не подхода, а людей, которые сразу начали что-то делать без формирования видения продукта.
Последний тезис я не понял. Если мы говорим про внешнего клиента, то Ваш коллектив и атмосфера в нем его не сильно беспокоят. Ему надо то, чем он будет пользоваться. И чем лучший продукт предложит компания (соотношение цена /качество или уникальность, или еще по какому параметру), тем у нее , потенциально, будет больше выручка. По поводу уменьшения расходов (тут я понял, что Вы про внутреннего клиента, а не про того, о котором я) могу сказать, что по ТЗ может быть все здорово, только после реализации заказчик понимает, что написано "сделай экранную форму такую", а на деле какого-то функционала в ней нет и удивляется "ой, я думал, что он будет по умолчанию". все прописать в ТЗ просто нереально. Такой подход был развенчан самим Уинстон Ройс (считающимся создателем каскадной модели waterfall). В своей статье “Managing the Development of Large Software Systems” он утверждал, что только простые проекты можно делать таким образом и от итераций не уйти.
-
Вы говорите о каких-то маленьких масштабах (подумать неделю, например). Я же говорю о том, что утопия "сесть и обо всем подумать". Конечно, думать можно, но даже умы Гугла, Яндекса и т.д. постоянно развивают свои сервисы, а если бы можно было бы все сразу придумать, то они выпускали бы одну версию навсегда, где было бы все, но.. так не получается. В начале MVP, смотрим "оно/не оно", потом определяем дальнейший шаг и т.д. Часто бывает так, что мы создаем совсем не тот продукт, что хотели изначально и это нормально. Так происходит потому, что как раз НЕЛЬЗЯ все придумать изначально.
PS
Все, что я написал выше не относится к простым процессам типа игры в "крестики-нолики", где нового не придумаешь (хотя, и там выдумывают не 9 клеток, а больше). Там, действительно, можно все заранее продумать, а вот в чем-то более сложном.. я еще таких всесторонних "продумщиков" не встречал. Если Вы такой, то снимаю шляпу! мне бы такие сотрудники очень пригодились, правда.
onets
03.08.2021 14:24Аджаил, который я упоминаю - это совокупность всего, в том числе конкретных методик типа scrum/kanban/lean.
Вы по-прежнему остаетесь в рамках программного обеспечения. Абстрагируйтесь от него, ведь оно стало массовым только в последние лет 30-40, когда появились первые персональные компьютеры. Если подняться выше - увидите всю картину.
Элементы аджаила зародились не в ИТ, а как минимум в Японии после второй мировой войны в сфере производства. Просто бравые, по большей части, американские парни подумали "а чем мы хуже" и решили адаптировать это дело под производство программного обеспечения. Но я все же надеюсь они не забывали, что компьютер - это всего лишь инструмент, а программное обеспечение - всего лишь маленькая часть больших бизнес-процессов где бы то ни было (на складах, на заводах, в банках).
На начальной стадии не был сделан User Story Mapping, т.е. сразу ломанулись что-то делать не видя процесса
Погодите, откуда тут взялось описание процесса? По аджаилу к нам приходит заказчик и говорит "сделай то не знаю что", выдавая неопределенные требования на словах в час по чайной ложке. Если уж мы взялись за аналитику и описание бизнес-процессов - разве вся эта писанина не первый этап по ватерфоллу? И как же так вышло?
onets
03.08.2021 19:56Короче, суть в чем.
Чистый аджаил хорошо покрывает конкретно разработку программного обеспечения по требованиям, по которым уже была проведена глубокая аналитика. Т.е. управление требованиями остается на совести заказчика/владельца продукта. Но чаще всего заказчик не айтишник и не имеет опыта построения ИТ систем, даже если ему знакома предметная область.
Если каждый набросок в бэклог должен проходить еще и этап аналитики внутри команды разработки, то для начала придется добавить в спринт задачу "описать бизнес-процесс" (= написать ТЗ). А это по факту уже натягивание ватерфолла на спринты.
Мало того, если поторопиться, то придется все кардинально переписывать и не раз. Аджаил говорит "лучше об этом узнать раньше, чем поздно". В принципе логично и правильно. А что нам говорит бизнес? "Почему, чтобы добавить кнопку вам надо месяц и все переписать" или "Какого ... я должен оплачивать переработки складских работников, которые вынуждены по ночам переставлять товар и переклеивать штрихкоды. Вы что не можете сразу по-нормальному сделать???!!!".
Нет, не могут. Потому что по аджаилу в бэклог набрасывают заженные спички, а команда разработки занимается тушением пожаров.
Если вернутся к вашим банковским системам, то для дальнейшего развития и устранения багов аджаил подходит довольно хорошо, о чем вы и написали в своей статье. Почему? Потому что вы пришли на устоявшуюся систему, которая 146% была реализована по ватерфоллу 20 лет назад. А что будет если вам дадут задачу написать АБС с нуля по аджаилу? Не узнаешь пока не попробуешь. Но никто этого делать не будет.
При этом использование аджаила в гораздо более простых системах (как мой пример со складом) уже обнажает проблемы. Нельзя начинать писать код без предварительного анализа бизнес-процессов (=написание ТЗ =ватерфолл). Потому что по итогу приходится не только переписывать программное обеспечение, но и заново расставлять 20 тыс позиций на складе по новым правилам. В аджаиле об этом ни слова.
При этом можно поднятся выше программного обеспечения. И применить аджаил на всех этапах и начать с описания бизнес-процессов. Но хорошо бы выбрать какое-то иное средство прототипирования. Непосредственно кодинг конечно быстрее, чем строить дом, но порой не достаточно быстро. Например, как в фильме про братьев Макдональдс. Они на асфальте рисовали мелом расстановку кухонных блоков и тестировали процесс быстрого приготовления пищи. Т.е. спринт у них был ну 1 час. Тут кстати в целом интересный момент. Макдональдс существует со своими бизнес-процессами с 1940, а персональные компьютеры появились только спустя 40 лет. Что как раз и доказывает, что компьютеры это инструмент, а программное обеспечение - лишь малая часть бизнес-процесса.
Аналогичная проблема при использовании TDD. Нельзя сначала писать тесты, а потом реализацию. Потому что в процессе описания бизнес-процессов, уточнения требований, раз за разом придется с нуля переписывать все эти тесты. Тесты нужно писать на уже более-менее стабильный функционал.
MorozovVTBL Автор
04.08.2021 19:32Спасибо за развернутый комментарий. Теперь понял.
Все вот в этой Вашей фразе: "При этом можно поднятся выше программного обеспечения. И применить аджаил на всех этапах и начать с описания бизнес-процессов. "
КОНЕЧНО! Почему-то историю с Agile часто воспринимают лишь как игрушка ИТ-шников. У меня ушло не мало сил на объяснение внутри компании, что Agile это про всю компанию! Разумеется, Agile как культура и ценности не может существовать в отдельно взятом подразделении.
mvv-rus
03.08.2021 18:00Затем набирали людей в команду. Критериев отбора было всего два:
1. Должны гореть глаза.
...
Такие критерии настораживают. Мы ведь тут живем не в Самой Прекрасной Советской Стране, а вовсе в Царстве Бездушного Чистогана, то есть работаем не ради процветания Родно Страны и любимого предприятия, а чисто ради получаемых нами лично денег.
А потому требование видимого энтузиазма от работников выглядит подозрительным — как попытка владельцев бизнеса поиметь с них больше за те же деньги.
В связи с этим у меня к вам вопрос: не обнаружили ли вы в результате внедрения этих прогрессивных методик увеличение интенсивности труда программистов? Я понимаю, что нужные для ответа метрики, скорее всего, не собирались (ибо методикой гибкой разработки они не предусмотрены, сами по себе менеджерам они не нужны, а профсоюза у вас там нет), но, тем не менее, вопрос такой задам.
И совсем на всякий случай — еще вопрос: если увеличение интенсивности труда разработчиков имело место, то компенсировалось ли оно как-либо?MorozovVTBL Автор
05.08.2021 00:51Спасибо за интересный вопрос.
Начну с последнего вопроса. Мы ведь про ВТБ Лизинг говорим, а не ООО "Ромашка-22" (надеюсь, такого ООО в природе нет :) ). Разумеется мы достаточно серьезно вкладываемся в сотрудников. Один профессиональный Agile-тренинг и тренерское сопровождение команд чего стоили )) Если еще серьезнее, то Вы правы, Agile это про людей, про взаимодействие, про ценности. Люди, которые лишь пытаются выглядеть так, что они типа разделяют это все, они очень быстро "сдаются" (мимикрировать долго не получается). По факту, я не вижу смысла переделывать людей, я лишь показываю, что можно работать иначе, а дальше уже выбор человека. "В Agile" мы не загоняем. Очень многие компании несут Agile огнем и мечем, у нас же, те кто прям не могут работать кроме как "каскадно" и обладают иными ценностями, не могут поддерживать должный уровень коммуникаций и т.д. или уходят , или мы находим им место в других направлениях, в которых они могут развиваться дальше.
По поводу метрик производительности труда сложнее. Лично я уверен, что любую метрику можно "читить". Для того, чтобы метрика работала, ее надо реализовывать в компании, культура сотрудников которой позволяет честно показывать что происходит. Например: выработка времени. Списываем честно время и если списали больше, то что? поработали лучше и сделали больше? - нет. Идем дальше, "количество выполненных задач" , оно? тоже нет, т.к. как только люди узнают, что это критерий, то сразу задача начинает декомпозироваться на миллион подзадач и т.д. В статье написано какие метрики мы использовали и ключевыми были лишь 3:
-CSI (отношения с партнерами/клиентами, обратная связь стейкхолдеров)
-LeadTime (за ней смотрели на всех уровнях, т.к. ее можно очень успешно читить)
-Проверяемый экономический эффект (реализуемый эффект. Мы таки деньги зарабатываем)
А Вы о каких метриках говорите? Строчки кода? Переработки? или что? Поделитесь, пожалуйста, я с удовольствием почитаю. Всегда рад узнать что-то новое!
ps
... чуть не забыл. Я предлагаю использовать слово "прививали" (например). Agile это не методика, это культура. Внедрение культуры не работает, культуру прививают или , например, "выращивают" (да, странно звучит :) ). Если относиться как к ВНЕДРЕНИЮ, то это просто про процессы и карго-культ. Такого нам не надо. Agile только через ценности (понимаю, со стороны звучит как дикость и "радуга с единорогами")
mvv-rus
05.08.2021 14:47Спасибо за интересный вопрос.
Я вас понимаю.Я бы на вашем месте тоже обругал бы такого оппонента последними словами.Начну с последнего вопроса.
Зря. Он имеет смысл только в контексте положительного ответа на предпоследний вопрос — об интенсивности труда программистов.
А сам по себе ответ на последний вопрос заставляет предположить, что это увеличение интенсивности труда действительно имела место и ничем материальным скомпенсирована не было. Я правильно вас понял?
Потому что словаРазумеется мы достаточно серьезно вкладываемся в сотрудников...
по факту содержат неявное дополнение: "..., чтобы переделать их под свои нужды". Все эти Agile-тренинги — они ни материально сотрудникам ничего не приносят, ни ценность их на рынке труда не повышают. Эти вложения нужны исключительно вашей компании. Вы имеете полное право их делать, конечно, но неправильно представлять это как форму компенсации сотрудникам.Люди, которые лишь пытаются выглядеть так, что они типа разделяют это все, они очень быстро «сдаются» (мимикрировать долго не получается).
Немного в сторону. Вы просто плохо знаете людей. Я вот пожил и поработал в СССР — и знаю, что мимикрировать можно очень долго: приходилось, потому что там доступной альтернативы марсистко-ленинской идеологии с ее «трудовым энтузазизмом» не было. И, как мы знаем по опыту распада СССР, у многих мимикрировать получилось достаточно хорошо, чтобы занять весьма высокое положение в иерархии.По поводу метрик производительности труда сложнее.
Вы то ли меня действительно не поняли, то ли пытаетесь подменить понятия. Так вот, возвращаю контекст: я вел речь не о производительности труда — его результатах для фирмы, а о его интенсивности — то есть расходовании рабочей силы работниками, той самой, за продажу которой наемные работники поулчают зарплату. Отсутствие соответствующих метрик в вашем распоряжении — это для меня как раз ожидаемо (я сразу писал). Но, минимум, одна, хоть и приближенная, метрика есть: реальное суммарное время переработки за период. Вы можете сообщить как изменилось время переработки? И, если да — как в нем учтено было именно реальное время — в которое входят добровольные задержки, внеурочная работа из дома, состояние «на телефоне» и т.п.
С уважением.
PSAgile это не методика, это культура.
Когда я слышу слово «культура» мне чисто автоматически хочется продолжить фразу крылатыми словами, вложенными в уста отрицательного героя своей драмы «Шлагеттер» немецким драматургом Гансом Йостом ("… я взвожу свой браунинг"). Потому что 90+% случаев это слово сопровождает ту или иную разводку (на бабки, на поработать нахаляву и т.д.). И обсуждаемый вопрос, по моей оценке — он ничуть из этих 90+% не выбивается.понимаю, со стороны звучит как дикость и «радуга с единорогами»
Или как «классовое сотрудничество» — формой проявления которого по факту и является.MorozovVTBL Автор
05.08.2021 20:38Вы уверены, что у Вас нет личной обиды на что-то, что когда-то назвали для Вас "Эджайлом"? Через слово сквозит "разводка", "обман" и тд.
Судя по всему, предложенная метрика (измерять как долго сотрудники остаются на работе после официального рабочего времени, как я ее понял) и продиктована тем, что когда-то Вас так, выражаясь обычным языком, кинули.
У нас наоборот. Цель - создать среду для плодотворной работы. Какая еще среда, если люди будут обозлены, подавлены и работают 24/7 ? В этом и дело, что я верю в эффективную работу без переработок!
По метрике отвечаю:
В этом году глобальная цель - "снижать накопленный сотрудниками отпуск". Цифры я называть не могу, но по сравнению с 2019 годом, мы снизили накопленные отпуска процентов на 45 точно и этот тренд продолжается (люди должны отдыхать).
-
Саму эту метрику я не веду (цели ночевать на работе нет), т.к.
Все планы составляются без учета переработок и работы в выходные.
Если приходится выходить в выходной, то сотрудник получает ДВОЙНУЮ оплату (все по ТК) и , разумеется, мы кросс-функциональны теперь и если кто-то не может выйти, то найдется тот, кто сможет. Сами выходы теперь крайне редки.
У нас в договоре с сотрудниками предусмотрено "чуть больше отпускных дней" нежели стандартные 28 ;)
Ну и я просто вижу людей (кто и когда работает). В данном случае, живое общение и человеческое отношение к сотрудникам имхо заменяет любую метрику.
Думаю, что это вполне отвечает на Ваш вопрос про то как мы "истязаем сотрудников Эджайлом" :)
SashaKorolev
09.08.2021 18:44Костя, привет! )
Делаем аналогичное дело в «РБ ЛИЗИНГ». Нам, явно, проще. Видимо, возраст стейкхолдеров сказывается )
На связи.
MorozovVTBL Автор
10.08.2021 01:22О! привет!
Рад встрече!)) успехов в трансформации! Держитесь, будет увлекательно )) и чуток тяжело ))
ChePeter
Современные управляющие, менеджеры незаслуженно избегают применять такой испытанный и проверенный метод, как "демократический централизм".
Ракету построили, бомбу сделали, человека в космос, "кузькину мать", да Наполеона отбуцкали, Гитлера зарыли всё с помощью демократического централизма.
Вспомните "совет в Филях", когда младший штабной офицер первым излагает свою точку зрения и не боится никого. Это традиция русских штабов. Ну и после совета жесточайшая дисциплина со всеми прилагающимися.
Гораздо важнее достигнуть свободы обсуждения, вовлеченность и ответственность всех и плюшки, тем кто заслужил, а не выпросил.
Обсуждение считаю нужным начать с обоснованности выбора agile.
MorozovVTBL Автор
Согласен. Именно поэтому в статью я вставлял фразы типа "...а потом суметь правильно привить им эту культуру. "
Суть трансформации в том, что мы ее проводим не только и не столько как изменение процессов, а именно изменение культуры и ценностей в компании. Ценно партнерство на всех этапах (люди не винтики и не ресурсы, мнение каждого важно). Я стараюсь двигать Agile именно как ценности и мышление, а не карго-культ (бездумно делай так и будет успех). Уплощение структуры у нас тоже происходит (это помогает убирать "испорченный телефон" и вовлекать каждого в процесс "креатива", т.к. все участвуют в генерации идей, а не только начальники). Крайне важно слышать тех, кто непосредственно пишет код или работает с твоим продуктом в полях. Scrum с его Retro и Demo отлично помогают в этом. Сейчас мы растем (существенно), наше руководство поверило в in-house разработку и мне нужно больше людей, которым есть, что сказать ))
AnotherProgrammer
Полностью согласна с автором! Отличная статья! Спасибо дружище!!!
MorozovVTBL Автор
Спасибо! рад, что понравилось
KOnstaTEam
Так ведь в статье досствостаточно четко описываются предусловия. Диаграмма Ганта, в которой от базового плана двигались зависимые задачи. Изменен срок одной задачи, подвинулись еще 20 и более, выполняемые теми же ресурсами. Все просто waterfall стал сдишком планово незапланированно предсказуем. Иными словами, базовые сроки неисполнимы из-за зависимости ресурсов, человеков. А кроссфункциональные скрам команды пофиксили данный баг.
mvv-rus
Если вы думаете что в СССР, в КПСС (где он был записан в Уставе как основа функционирования партийной организции), то вы вы заблуждаетесь.
Потому что в СССР реальность и ее отражение в документах — это были две большие разницы.
В частности, «демократический централизм» в КПСС функционировал следующим образом: при рассмотрении вопроса на каком либо уровне на общем собрании или собрании партийного комитета представитель вышестоящего партийного комитета, или начальник организации сообщал, что «есть мнение», и все послушно за это мнение голосовали (послушание было выработано практикой 1921-1938 годов). И только если у вышестоящей организации и у партийного секретаря почему-либо мнения не было, начинался тот самый теоретический демократический централизм (для тех, кто от советских реалий в силу возраста далек, поясню: секретарь-официальное название должности партийного начальника, почему — так исторически сложилось).
ChePeter
Я успел пожить в СССР ( совет в Филях лично не застал ) и видел в действии при решении технических вопросов этот централизм. Очень он эффективно работал и я лично загубил парочку безумных проектов выступая на НТС первым, младшим.
Как Вы себе представляете "приходит секретарь партийный на заседание технического совета к Королеву и говорит, Вы, мол, тут не круглый иллюминатор делайте, а квадратный". Вы, @mvv-rus сами хоть верите в такой секретарский заход?
Решения совета главных конструкторов были обязательны для девятки министерств. Это в корне отличается от системы эффективного нынешнего менеджера.
mvv-rus
Я — про типичную для СССР партийную или комсомольскую организацию, с этим самым демократическим централизмом в уставе.
Которая с легкостью могла одобрить любую глупость, пришедшую сверху, типа «рязанского чуда» (показательный случай, кстати).
В СССР я тоже успел пожить и поработать (и даже из комсомольского возраста выйти), но — в обычных условиях, со всей полнотой проявления руководящей и направляющей роли партии. Плюс, родственники, в таких же условиях жившие и работавшие, кое что про жизнь рассказывали.
А вот про такие особенные, исключенные по факту из системы партийного руководства явления, как это ваше КБ Королева (или, там, НИИЧАВО) я сказать ничего не могу) — не встречался с ними по жизни.