Як слід впроваджувати стандарти та удосконалення процесів в організації без них?

Мені було доручено вдосконалити процес розробки програмного забезпечення шляхом впровадження удосконалень процесів, серед яких ми, швидше за все, будемо використовувати CMMI для розробки версії 1.3 як настанову та прийняти кращі практики повністю або частково. Який найкращий спосіб запровадити стандарти та удосконалення процесів, щоб ступінь відштовхування та опір розробників було мінімізовано?

1. Почніть проект з удосконалення програмного забезпечення (SPI) . Визначте його обсяг та цілі. Це безумовно допоможе, якщо стандартизація має свої цілі та міри, застосовні до вашої організації.
2. Призначте особу, відповідальну за прийняття стандартів . У випадку великої організації може бути декілька людей або навіть відділ. Важливим є те, що всі, хто відповідає за стандартизацію, будуть:
   • досить професійний, щоб побачити всю картину
   • достатньо впливовий для того, щоб мати справу з командами та допомагати їм приймати / домовлятися про зміни
3. Розробіть тренінги, що охоплюють як стандарт, який ви хочете прийняти, так і його специфіку, застосовану до вашої організації. І це дійсно важливо, доки всі люди, які не пройшли навчання, потенційно стійкі до змін. Наприклад, коли я працював у великій компанії, я інструктував усіх нових працівників про процеси забезпечення якості, CMMI, ISO та систему управління якістю. Таке навчання було обов’язковим. Це допомогло вдосконалити знання про процеси управління якістю та підвищити обізнаність працівників щодо важливого питання якості програмного забезпечення.
4. Домовляйтеся про зміни та адаптуйте загальноприйняті практики для ваших конкретних потреб. Це допоможе уникнути бюрократії та впровадження важких процесів, які нікому не потрібні.
5. Встановіть моніторинг того, як підтримуються покращені процеси, що підтримуються, та чи достатньо вони ефективні у вашій організації.

Це також допоможе, якщо ви знайдете всіх людей у ​​вашій організації, які справді переймаються якістю. Найімовірніше, це були б найважливішим ресурсом, який допоможе вам сприяти змінам та встановлювати зрілі практики.

Пара думок зі школи важких стукачів:

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

2) Визначте чіткі причини, чому ви просите людей змінити спосіб їх роботи. Що стосується бізнесу? В ідеалі це виграє кожній команді індивідуально. Іноді це просто системне вдосконалення. У будь-якому випадку зробіть вигляд видимим.

3) Спростіть, а потім стандартизуйте, а не навпаки.

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

5) Знайдіть доброзичливих ранніх усиновлювачів. Люди будуть скаржитися на те, скільки часу це займає. Вам потрібен хтось, на кого можна вказати і сказати, "це зайняло лише 15 хвилин"

6) Для метрики наполегливо натисніть на кількісне, а над якісне. Інакше у вас є зелені проекти до дня, перш ніж перейти в прямому ефірі, коли все проскочить на місяць.

7) Підкресліть техніку над інструментами. Гарне планування важливіше, ніж проект MS.

8) Поставити рівень процесу щодо потреб. Кожен ресторан потребує процесу, але Нобу та французька пральня потребують іншого виду, ніж Макдональдс. Те саме з програмними фірмами.

Удачі!

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

Я рекомендую глибоко дивитися на постійний підхід до впровадження CMMI, а не на поетапний підхід. Мені здається, що це набагато ефективніший спосіб визначити, де саме зараз стоїть ваша організація, та покращити сфери, що додають найбільшу цінність бізнесу. Це дозволить вам не тільки узгодити свої зусилля щодо вдосконалення з цілями бізнесу, але швидко досягти важливих етапів прогресу та продемонструвати ефекти вдосконалення, збільшуючи викуп з усіх рівнів.

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

Деякий тип інженерних процесів може також бути корисним. Зберіть разом представників різних організаційних компонентів та команд, які зазнали впливу покращення, щоб чути голос кожного. Сюди входять не просто представники кожної ролі, а, можливо, різні команди з розробки продуктів. Не знаючи, як структурована ваша організація, я не можу точно сказати, кого ви хочете подивитися, але включайте до групи людей усіх рівнів організації. Крім того, зробіть обговорення та рішення, прийняті цією групою, доступними для організації для коментарів та підняття будь-яких проблем.

Для кожної зміни:

• Викличте зміну 1 і як це покращить розвиток.
• Внесіть зміни.
• Продемонструйте вдосконалення
• Видаліть зміни, які не продемонстрували покращення

Очевидно, що аналіз повинен відбуватися з часом, але жодних змін не слід приймати, поки не буде показано, що він є ефективним. Ось чому я міг би впроваджувати не більше 2-3 змін за цикл, інакше ви часто не можете виміряти, було покращення чи ні.

Ніщо не дратує мене, ніж сліпо слідувати кращим практикам, не роблячи аналіз, щоб показати, що насправді є найкращою практикою для вашого оточення. Краща практика , яка не демонструє поліпшення в кращому випадку марнотратно і в гіршому випадку пошкодження.

Усі кроки у вашому процесі та всі методологічні практики повинні бути проаналізовані та доведені до користі. Якщо це не так, його слід видалити. Цей аналіз слід проводити на постійній основі незалежно від додавання чи усунення кроків чи практик.