Алексей Корольков в блоге "Websoft"-а опубликовал историю, которая наводит на определенные мысли. Цитирую:
В компании делали серию из нескольких курсов. Почти все курсы из них делали "как положено" - сначала писали и согласовывали сценарий, оформляли в PowerPoint, импортировали в авторское средство (Courselab) и затем доделывали (добавляли кое-где интерактивности, вставляли упражнения и вопросы и т.п.). Один из курсов преподаватель делал без всякого сценария и подготовки в PowerPoint прямо сразу в Courselab - придумывал и материал и способы его оформления и представления.
Так вот, по отзывам обучаемых, именно этот курс понравился им больше всего.
В чем причина? Ничто не сдерживало фантазии или сначала "набили руку" на сценариях и научились делать?
Такая постановка вопроса ставит меня в тупик: создается впечатление, что автор считает, будто бы стандарт, или даже так - СТАНДАРТ, может гарантировать качество продукции. Стандарт может, на самом-то деле, если это стандарт на саму продукцию - тогда некачественная продукция просто не уйдет в реализацию. Однако СТАНДАРТ на процесс производства этой же продукции совершенно ничего не гарантирует.
Я давно размышлял над стандартами и, вообще, над пользой всевозможных инструкций, рекомендаций, предписаний и так далее.
- За свою жизнь я сам написал пару дюжин тысяч служебных инструкций, а такого рода опыт не способствует готовности их выполнять. - М.Фрай. Простые волшебные вещи.
Ранее я уже делился соображениями, но там речь шла, в основном, о стандартах на интерфейсы, а тут размышления коснулись стандартов на процессы.
Для примера возьмем знаменитый стандарт ISO 9001 "Quality Management Systems - Requirements" ("Системы управления качеством - Требования", текущая его версия ISO 9001:2008, российский аналог - ГОСТ Р ИСО 9001-2008). Этот стандарт единственный из группы ISO 9000, применяемых при организации системы управления качеством, по которому допустима сертификация организаций. В последние годы организации ну очень любят по нему сертифицироваться, о чем с удовольствием пишут на своих сайтах и в своих проспектах. Это хорошо, даже очень, но хотелось бы сделать ряд замечаний:
- Соответствие данному стандарту, установленное в ходе сертификации, никоим образом не гарантирует качество продукции этой организации, поскольку в самом стандарте сказано, что (русский перевод):
Требования к системе управления качеством, указанные в этом Международном Стандарте, являются дополнением к требованиям к продуктам.
- Опять-таки в самом стандарте сказано, что помимо применения с целью увеличения удовлетворенности потребителей, он может применяться, когда
организация нуждается в демонстрации своей способности постоянно выпускать продукт, соответствующий требованиям потребителя.
Обращаю внимание на тот факт, что "СПОСОБНОСТЬ постоянно ВЫПУСКАТЬ качественный продукт" и "ВЫПУСК ИСКЛЮЧИТЕЛЬНО качественного продукта" - формулировки по смыслу очень разные. - Стандарт слишком общий. Весь его смысл заключается в рекомендации следующей поведенческой цепочки:
1. Подумай, прежде чем что-то делать. ->
2. Когда делаешь, документируй. ->
3. После того, как сделал, проверь, насколько оно работает. ->
4. После того, как проверил, сделай выводы. ->
5. Перейди к шагу 1.
Это не мои фантазии - в самом стандарте имеется указание на методологию PDCA:
1. Plan. ->
2. Do. ->
3. Check. ->
4. Act.
- НЕ гарантирует качество ее продукции ни в какой степени;
- в определенной степени свидетельствует о том, что организация МОЖЕТ работать эффективно и производить качественную продукцию, но ни в коей мере НЕ гарантирует, что ее сотрудники будут прилагать все или хоть какие-нибудь усилия для этого;
- говорит о том, что для организации важна ее репутация;
- свидетельствует в пользу того, что в организации работают сотрудники, обладающие разумом.
Человек разумный - это не всегда разумный человек... хомо сапиенс - это возможность думать, но не всегда способность... - А. и Б. Стругацкие "Отягощенные злом, или сорок лет спустя".
ISO 9001 - это, как ни странно, стандарт на процессы, хотя в названии и значатся "требования" к системе управления качеством (что намекает на требования к интерфейсу). У меня к стандартам на процессы специфическое отношение. Я считаю, что они уместны там, где:
("Велика вероятность ошибки при выполнении какой-либо операции в составе процесса"
ИЛИ
"Имеет значение последовательность операций в ходе процесса")
И
"Ошибка при выполнении операции или в последовательности операций имеет значительные последствия".
В остальных случаях стандарты бессмысленны, а иногда вредны. Определение того, что для конкретной организационной единицы является "значительными последствиями", а что не является - это сложная задача. Проблема в том, что организации часто идут по пути "лучше перебдеть, чем недобдеть", пытаясь стандартизировать все, или даже так - ВСЁ! Стандарт или инструкция позволяют превратить любое "дело" в последовательность четких "операций", но в тех случаях, когда первоначальное "дело" было в значительной степени связано с творчеством, переход к операциям (особенно, если их много) часто заставляет человека забыть вообще о том, чего ради он все это начал (забыть об "идее"). Я называю это "Эффектом шелухи".
Представьте себе, что повар в столовой готовит яичницу из двух яиц. Через некоторое время он решает добавить в нее лук, затем фасоль, затем еще что-нибудь невообразимое. Его яичница становится популярным блюдом в меню, и директор столовой решает, что ее должны готовить и другие повара. Тут на арене появляется "рецепт", то есть - "стандарт на процесс приготовления яичницы". Другие повара готовят, следуя этому рецепту. Если они неопытные или не сильно увлечены своим делом, они так и будут ему следовать. Если они хотят творить новое, то могут втихую опробовать на посетителях другой набор ингредиентов либо обратиться к руководству. Если все пойдет удачно, новая яичница может быть опробована на нем, затем на посетителях (уже не втихую), а затем станет новым рецептом/стандартом. Цикл замкнулся. Все бы ничего, но обратите внимание:
- Первый повар изготовил свой шедевр в отсутствие стандарта.
- Другие повара-энтузиасты имеют два варианта действий: либо нарушить стандарт, либо предложить изменения/дополнения в него.
Таким образом, наличие, сам факт существования стандарта на тот или иной процесс в определенной степени идет вразрез с потребностями творческих натур, которым хочется попробовать добавить в блюдо перец хабанера вместо халапеньо и посмотреть, что будет, вместо того, чтобы тупо разбивать скорлупу. Я уж не говорю о том, что стандарт на процесс, где задействованы люди, или даже так ЛЮДИ, - эти непредсказуемые существа с чувствами, эмоциями и никому неизвестными болезнями и тараканами в голове - по определению не будет всегда точно выполняться.
Интересно, что определение того, что нужно стандартизировать, а что - нет; выделение чего-то общего, что можно записать в стандарт, с определенной точки зрения похоже на задачу проектировщика/программиста, который должен решить, насколько универсальным будет тот или иной модуль/метод/класс. И, зная, насколько сложна ЭТА задача, я могу предположить, насколько сложна первая. Кстати, что касается "сильно творческих" проектов в области разработки программного обеспечения, то "просветленные" авторитеты практически рекламируют уход от корпоративных стандартов и правил (Э.Йордон. Путь камикадзе. Второе издание. - М.: "Лори", 2008. ISBN 5-85582-227-3). Это, действительно, большая проблема - грамотно выбрать жертвенный процесс для стандарта, и над ней, на мой взгляд, маловато задумываются. Что до стандартов на интерфейсы, то тут, как ни крути, проще - исчезни они, и батарейки просто перестанут влезать в пульты.
Как бы то ни было, иногда, чтобы создать что-то по настоящему новое и качественное, имеет смысл ободрать всю шелуху и просто сделать ХОРОШО!
Комментариев нет:
Отправить комментарий