Каталог решений - Гибкий Стандартного разумеет?

Я занимаюсь автоматизацией предприятий на платформе 1С с использованием собственной технологии оказания внедренческих услуг, которую считаю гибкой по сути.

Что имеется в виду под понятием «гибкая технология»?

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

Основное отличие методики, которую мы используем – это работа в динамически формируемых командах, с заранее неизвестным количеством требований  — требования появляются, изменяются, или вообще отменяются.

Каждая итерация – это отдельный минипроект, выполняемый по каскадной модели:

• Анализ,
• Уточнение,
• Разработка,
• Тестирование,
• Передача.

Мы используем недельные итерации. Длительность итерации подобрана опытным путем. В рабочий месяц умещается 4 результативные итерации. 

Гибкие методики – упреки и заблуждения

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

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

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

Гибкие методики – преимущества

Пожалуйста, вот пример динамического формирования требований в процессе сотрудничества с одним из наших заказчиков. По горизонтали — количество месяцев сотрудничества, один столбик – это один месяц (всего 97 месяцев). По вертикали — значения выработки (часов в месяц).

Обратите внимание, когда нужно – выработка почти 700 часов в месяц. Когда не нужно – выработка почти 0 в месяц.

Нам удалось, например, работая по нашей технологии, разработать систему управления складом (WMS) за 90 дней и сэкономить заказчику 2000 долларов на каждом рабочем месте.

Измерение результатов использования гибких методик

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

Как все-таки увеличить степень доверия к нашей технологии для новых заказчиков? Так пришло решение о сертификации нашей системы управления качеством на соответствие международному стандарту ISO 9001-2008.

Я знаю, что есть проектные организации, у которых по ISO сертифицирована система управления качеством для "водопадного" процесса разработки. Нам сложнее. Как стандартизировать работу, которая во многом построена на субъективных критериях оценки качества, работа ведется по гибкой технологии, без технического задания, в частности?

Для нас, качество – это соответствие ожиданиям заказчика по функциональности, срокам и стоимости решения.

Отсюда родился слоган:

1. Требуемая функциональность
2. К ожидаемому сроку
3. За приемлемую плату.

Нижние два критерия сильно субъективны.

• Ожидаемый срок – субъективный критерий. Для одних недели мало, для других много.
• Приемлемая стоимость – тоже субъективное понятие. Для одного человека это решение может показаться приемлемым, а кто-то другой может субъективно посчитать, что это решение дороже, чем он ожидал.

Получается, что для конкретного проекта (с неизвестным результатом и неизвестным сроком) мы должны выполнить свою работу так, чтобы срок стал ожидаемым, а стоимость – приемлемой. Соответствие этим критериям мы каждую неделю, каждую итерацию проверяем на уровне заказчика. Смогли ли мы за неделю уложиться? Удалось ли реализовать требуемую функциональность? Насколько приемлема стоимость полученного за неделю прироста функциональности?

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

Область сертификации по ISO  

Структура деятельности нашей организации:

• 94% – основная деятельность — комплексное обслуживание 1С:Предприятие, включая программирование (разработка, проектирование, внедрение систем),
• 2% – это продажи программных продуктов,
• 4% – это информационно-технологическая сопровождение (ИТС).

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

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

Но в нашей деятельности эта область составляет 2% +4%=6%. Мы добавили в формулировку «проектирование, разработка и ввод в эксплуатацию», чтобы охватить областью сертифицации оставшиеся 94% нашей деятельности.

Сертифицируемый стандарт взаимодействия с заказчиком

Если раньше система управления качеством находилась в головах сотрудников, для сертификации СМК пришлось ее описать. Схема приведена в качестве примера.

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

• анализ достижения понимания требования,
• разработка,
• тестирование
• и внедрение.

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

Процесс сертификации  

49 с половиной недель — можно сказать, почти "эротическое путешествие" 🙂

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

Для сертификации нами пройдено:

• Подготовительный этап  – 8 недель.
• Анализ «Как есть» (анализ и описание нашей технологии) – 4 недели.
• Разработка документации для системы управления качеством – самый длительный этап, 20 недель.
• Само внедрение СМК – порядка 9 недель. На этом этапе все те документы, которые были разработаны для нашей системы управления качеством, надо было добавить в наш процесс, причем так, чтобы это не было навязыванием, чтобы люди согласились их использовать, чтобы это органически вплелось в нашу организацию. Это был достаточно сложный процесс.
• Внутренний аудит – мы уложились в 4 недели.
• 4 недели — внешний аудит.

В конечном итоге получилось 49 с половиной недель (чуть меньше года).

Комплект документов получился чуть-чуть меньше 22 см в толщину. Причем, как мы потом узнали на внешнем аудите, можно было сделать примерно в половину меньше.

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

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

• Наличие у нас системы управления качеством, эксплуатируемую нами с 2005 года;
• Наличие полностью документированных отношений со всеми заказчиками по всем проектам, по всем задачам от момента анализа до момента передачи через разработку и тестирование;
• Заинтересованность руководства во внедрении СМК – естественно, я был заинтересован в этом деле больше всего, как руководитель;
• Обеспечение СМК (системы менеджмента качества) необходимыми ресурсами – очень важный фактор. Если бы я не взял специального человека (специалиста по внедрению), вряд ли смог бы самостоятельно выделить время для того, чтобы все это провернуть в свободное от основной деятельности время. Если вы вдруг соберетесь сертифицироваться по ISO, важно понимать, что для этого нужен определенный ресурс, причем человек достаточной квалификации;
• Электронный документооборот;
• Система управления требованиями,
• И доступность документов СМК.

Заключение

Когда я только начинал заниматься сертификацией системы менеджмента качества, главное, чего хотелось – сохранить все достигнутые преимущества нашей технологии и избежать ее ужесточения. То есть, хотелось остаться гибким и одновременно устранить часть справедливых упреков. Достаточно высоки риски, сертифицироваться "через Ж", как на левой нижней картинке или загнать технологию в клетку, потеряв гибкость. Наш выбор — остаться гибкими и продолжать работать "точно в цель", как на правой верхней картинке следующего слайда.

 ******

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.