Книга Софт за 30 дней. Как Scrum делает невозможное возможным, страница 30. Автор книги Кен Швабер, Джефф Сазерленд

Разделитель для чтения книг в онлайн библиотеке

Онлайн книга «Софт за 30 дней. Как Scrum делает невозможное возможным»

Cтраница 30

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

Развеять сомнения и сопротивление

Люди видели книги о Scrum на столах и слышали «внутреннюю информацию». Начинают ползти слухи. Проблема слухов в том, что они анонимны, люди вкладывают в них собственное мнение и худшие страхи. Слухи могут остановить каждого на его пути, потому они должны быть развеяны при любом значительном изменении.

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

Сопротивление принимает множество форм, и самая пагубная из них – пассивное сопротивление. Люди не протестуют, они не спорят и не возражают. Они не хотят быть отождествлены как помеха, но они не хотят меняться.

Жизненно важно усадить менеджеров и остальных сотрудников в одну лодку перед приближением перемен. Эти люди – основа организации. Они знают свое дело, потребителей, системы и продукты. Без них не будет изменений.

Создать и запустить методы коммуникации

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

Менеджеры и другие сотрудники должны провести небольшие собрания внутри отделов для ответов на вопросы. Следует подготовить проспекты, описывающие объявленные решения руководства. Покидая это собрание, сотрудники должны знать, с кем связаться внутри организации для получения ответов на возникшие вопросы.

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

Распространение по всей организации

Первые проекты по разработке программного обеспечения начинаются в действии 3 (табл. 9.4). Ваша организация уже имеет некоторый опыт работы со Scrum, из пилотного проекта (глава 3), разовых проектов (глава 4) или работы Scrum-студии (глава 5). Эти проекты – часть устойчивого внедрения и использования Scrum путем разработки продуктов организаций. Также они – причина изменений во всех смежных областях.


Таблица 9.4. Распространение по всей организации

Софт за 30 дней. Как Scrum делает невозможное возможным

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


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

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

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

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

Достичь воздействия

Каждый в организации должен видеть прогресс в достижении видения, как определено в действии 4 в табл. 9.5. Некоторые ранние успехи указывают путь и обеспечивают комфорт. Мы советуем команде трансформации выбрать два проекта по разработке программного обеспечения, которые сформируют базу для ранних успехов:


1) проект улучшения, встраивающий новые возможности в существующую систему, которой не больше пяти лет;

2) проект по созданию новой системы, использующей новые технологии.


Таблица 9.5. Достичь воздействия

Софт за 30 дней. Как Scrum делает невозможное возможным

Эти проекты должны быть продолжительностью от трех до шести месяцев каждый. Один из проектов, желательно новая разработка, должен состоять из 20–30 человек, организованных в три или четыре Scrum-команды. Другой проект должен состоять из одной Scrum-команды. В связи с тем что почти любой процесс работает с легким проектом, оба проекта должны включать трудные технологии и требования, в противном случае оценки будут иметь ограниченную ценность.

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

Вход
Поиск по сайту
Ищем:
Календарь
Навигация