Как внедрить стандарты и усовершенствования процессов в организацию без них?

Передо мной была поставлена ​​задача улучшить процесс разработки программного обеспечения путем внедрения улучшений процесса, из которых мы, скорее всего, будем использовать CMMI для разработки версии 1.3 в качестве руководства и применять лучшие практики полностью или частично. Как лучше всего внедрить стандарты и усовершенствования процессов, чтобы минимизировать степень отталкивания и сопротивления со стороны разработчиков?

1. Начать проект улучшения программного обеспечения (SPI) . Определите его объем и цели. Это определенно поможет, если у стандартизации есть свои цели и показатели, применимые к вашей организации.
2. Назначить ответственного за принятие стандартов . Это также может быть несколько человек или даже отдел в случае большой организации. Важно то, что все, кто отвечает за стандартизацию, будут:
   • достаточно профессионально, чтобы увидеть всю картину
   • достаточно влиятельны, чтобы иметь дело с командами и помочь им принять / обсудить изменения
3. Разработайте тренинги, охватывающие как стандарт, который вы хотите принять, так и его особенности, применимые к вашей организации. И это действительно важно, поскольку все люди, которые не были обучены, потенциально устойчивы к изменениям. Например, когда я работал в крупной компании, я инструктировал всех новых сотрудников о процессах обеспечения качества, CMMI, ISO и системе управления качеством. Такое обучение было обязательным. Это помогло улучшить знания о процессах управления качеством и повысить осведомленность сотрудников о важной проблеме качества программного обеспечения.
4. Обсудить изменения и адаптировать общепринятые методы для ваших конкретных потребностей. Это поможет избежать бюрократии и реализации тяжеловесных процессов, которые никому не нужны.
5. Установите мониторинг того, как внедряются улучшения процесса, поддерживаются ли они и являются ли они достаточно эффективными в вашей организации.

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

Пара мыслей из школы тяжелых ударов:

1) Большинство инициатив по улучшению процессов тратят 80% своего времени на разработку процессов и 20% на образование и социализацию. Отразить эти проценты. Посредственный стандарт, который следует, превосходит идеальный, который не соответствует.

2) Определите четкие причины, по которым вы просите людей изменить свою работу. Какой бизнес-кейс? В идеале это приносит пользу каждой команде индивидуально. Иногда это просто системное улучшение. В любом случае, сделайте случай видимым.

3) Упростите, затем стандартизируйте, а не наоборот.

4) Вы не можете полностью делегировать это PMO. Прямые менеджеры должны быть куплены, и руководитель бизнес-единицы должен будет разорвать связи, когда поступают жалобы.

5) Найдите дружелюбных ранних последователей. Люди будут жаловаться на то, сколько времени это займет. Вам нужен кто-то, на кого вы можете указать и сказать: «Это заняло у них всего 15 минут»

6) Для метрик, настаивайте на количественном, а не на качественном. В противном случае у вас есть проекты, которые являются зелеными до дня, предшествующего Go Live, когда все падает на месяц.

7) Подчеркните методы над инструментами. Хорошее планирование важнее, чем MS Project.

8) Поставьте уровень процесса относительно потребностей. Каждый ресторан нуждается в обработке, но Nobu и французская прачечная нуждаются в другом виде, чем McDonalds. То же самое с фирмами-разработчиками программного обеспечения.

Удачи!

Скорее всего, хорошая идея сосредоточить свои усилия на CMMI, даже если вы не проходите аттестацию и не проходите официальную проверку и оценку. Доступно много литературы о CMMI , CMMI и других методах улучшения процессов, таких как Lean и Six Sigma , а также CMMI и гибкой разработке программного обеспечения . SEI имеет целый набор ресурсов , некоторые доступны бесплатно, о различных аспектах CMMI и руководства для различных типов организаций.

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

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

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

Для каждого изменения:

• Назовите 1 изменение и как это улучшит развитие.
• Реализуйте изменения.
• Продемонстрировать улучшение
• Удалить изменения, которые не продемонстрировали улучшения

Очевидно, что анализ должен проводиться с течением времени, но никакие изменения не должны приниматься, пока он не продемонстрирует свою эффективность. По этой же причине я бы реализовал не более 2-3 изменений за цикл, иначе вы часто не сможете измерить, было ли улучшение или нет.

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

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