Влад Долгов - Страсти по ISO 9000. Грустно-комическая повесть о получении сертификата на систему качества
Этот проект подразумевает изменение структуры, а у нас маловато опыта в этой области. К тому же у нас в компании не так много людей, которые специально обучались таким вещам. Если вас интересует мое мнение, мы бы смогли справиться с этим проектам, но на это у нас уйдет немного больше времени, чем обычно.
Менеджер среднего звена – менеджеру верхнего уровняЭтот проект подразумевает пересмотр структуры. У нас есть несколько специалистов, которые работали в этой области и еще несколько специалистов по языку реализации. Они могли бы организовать обучение персонала. Если вас интересует мое мнение, нам стоит взяться за этот проект, но действовать нужно осторожно.
Менеджер верхнего уровня – управляющемуЭтот проект даст нам возможность продемонстрировать нашу способность полного изменения структуры существующей системы. У нас есть все необходимые умения и ресурсы, чтобы успешно справиться с проектом. Некоторые сотрудники уже начали в неофициальном порядке обучать других необходимым навыкам. Если вас интересует мое мнение, мы ни в коем случае не должны упустить этот проект.
Управляющий – клиентуЭто как раз тот тип проектов, в которых наша компания специализируется. Мы уже завершили несколько проектов подобного типа для крупных заказчиков. Поверьте, что в этой области именно мы являемся наиболее компетентными. Если вас интересует мое мнение, мы можем выполнить этот проект успешно и в назначенные вами сроки.
Ты понял, Влад, куда уходит качество?
– Да уж, как не понять! ISO начинается только с момента подписания контракта, а качество проекта закладывается до этого – при анализе требований возможного клиента, и если вы «голодны» и ваш портфель проектов пуст, то вы и наобещаете сделать «из мухи слона».
Поэтому если нет нужной динамики продаж, то никакое ISO тут качество не обеспечит!
Вот откуда начинает расти качество проекта!
Мда…
И дым от пророка в своем отечестве нам сладок и приятен…
Глава одиннадцатая
Подводим итоги
Из измерений получается количество, из количества – цифры, из цифр – сравнение, а из сравнений – победа.
Сун Цу– Друзья!
Сегодня настало время поговорить о том, что уже сейчас нам дала система качества!
Основной тезис построенной нами системы, как я уже многократно говорил, гласит: «Нет процессов без сбора данных, нет сбора данных без их анализа, нет анализа без принятия решений и нет решений без планирования корректирующих и предупреждающих действий!»
И стандартный набор инструментов и процедур только помогает эффективному прогрессу. Однако почему-то еще не все менеджеры проектов хотят следовать стандартным процессам и методикам!
– Они боятся, что это будет ограничивать их креативность?
– Позвольте возразить. Именно в результате их отсутствия или их «незамечания» как раз очень часто и происходит так, что менеджер проекта в конце концов обнаруживает себя запутавшимся в жуткой помеси процедур, инструментов управления и техник, требующих значительных усилий для того, чтобы совместить их друг с другом. Это все только препятствует продвижению проекта и сопровождается однозначной потерей его качества!
Еще раз и еще раз повторяю, что стандарты – это регламенты действий только «по умолчанию». И если у вас появляется разумная им альтернатива, то это только приветствуется ISO, поскольку требует постоянного совершенствования! Поэтому не устану повторять, что наперекор устоявшемуся ошибочному мнению стандартные процедуры только способствуют креативности, а не затрудняют ее. Еще раз аргументирую. Стандартные процедуры дают четкое понимание задач данного проекта, а также конкретные инструменты и техники работы для завершения задач. Такой подход снижает количество информации, которое надо переварить, чтобы справиться с задачей. Стандартизация способствует, во-первых, эффективному логически последовательному выполнению проекта. Во-вторых, лучшей интеграции активности в связи с тем, что участники проекта видят взаимозависимость их работы с работой других участников проекта. Менеджеры смогут работать более автономно, понимая стандарты, которым надо следовать во время принятия решений. И наоборот, когда стандарты отсутствуют, сотрудники будут наталкиваться на разные препятствия, находя их просто на ровном месте. В-третьих, снижается коэффициент переделок в связи с тем, что стандартизация существенно облегчает возможность использования наработок предыдущих проектов, улучшает коммуникации, потому что все члены команды играют по общим правилам. И здесь мы плавно переходим к реальной возможности снижения рисков проекта при помощи хорошо известного способа – создания базы знаний по ранее выполненным проектам.
Креативность является важной и нужной, но, к сожалению, часто приводит к изобретению колеса. Проблемы с изобретениями связаны с тем, что отнимают много сил и времени, снижают общую скорость выполнения проекта. Кроме того, это еще означает и отсутствие грамотной работы с опытом предыдущих проектов, что, в конце концов, увеличивает сроки проекта.
Здесь еще раз напомню вам об основных наших показателях – это как раз отклонения от плана в себестоимости и длительности проекта!
Повторное использование наработок других проектов дает возможность сконцентрироваться именно на специфике проекта. Для управления проектами могут быть повторно использованы определенные расписания из похожих проектов, форматы отчетов и формы. Более того, c технической стороны могут быть повторно использованы коды, спецификации, шаблоны и так далее. Практику повторного использования необходимо сделать элементом культуры выполнения проектов. Руководителю проектов надо научиться определять, что может быть использовано повторно. Как правило, такое понимание приходит в результате изучения истории выполнения проектов и документации предыдущих проектов.
Вот почему мы в обязательном порядке требуем наличие отчета о выполненном проекте!
Многие ИТ-проекты, уверяю вас, так похожи, что создается впечатление, что вообще ничего не меняется.
Принципиально важно приобрести навык видеть новый проект в свете предыдущего опыта. Для этого необходимо проанализировать проблематику темы и определить, какие предыдущие методы работы можно использовать в данном проекте, а какие нет.
Это все много раз уже обсуждалось с вами на семинарах, но здесь специально повторил, чтобы подвести вас к абсолютной необходимости документирования всех проектных проблем и решений именно с целью создания такой практической базы знаний!
Да, чаще всего документирование связывают именно с понятием «бюрократии». Однако в управлении проектами достаточно разумная «бюрократия» просто необходима. В большинстве проектов члены команды выполняют колоссальное количество работы, к сожалению, часто усилия не успевают документироваться, и тогда и знания, и экспертные оценки могут постепенно растеряться.
Еще и еще раз повторяю, что отсутствие документирования – это большая потеря для компании именно качества. Документирование решений, оценок и прочей информации дает просто огромное преимущество.
Качество работы над проектом возрастает, если есть четкие записи, что было сделано, как и почему именно так.
Наличие такой документации позволяет в будущем сосредоточиться на специфике проектов, а не фокусироваться на решении стандартных, уже возникавших проблем.
Как показывают внутренние аудиты проектов-решения, на некоторых еще не полностью документируются, видимо, следуя довольно рисковой логике: раз решение дает немедленный результат, то и нет причин дополнительной административной нагрузки в виде его документирования. Но мало документировать процесс выполнения проекта, эта информация должна быть правильно структурирована, чтобы ее можно было быстро находить и извлекать!
Вот именно для этого мы и требуем теперь все проектные документы раскладывать по папкам в одной конфигурации. Но внутренние проверки показывают, что некоторые из вас опять «идут своим путем»!
Даже там, где это документирование ведется, важная информация часто опять теряется в общей массе документации. Вот поэтому мы теперь и требуем создать общий формат и конфигурацию папок именно до начала проекта.
– Да, вы правильно поняли, необходима просто исполнительская дисциплина, которой пока еще нет.
Ведь система качества – это только инструмент, а создают качество именно исполнители.
Вы все, конечно, много слышали про японские кружки качества. Этот процесс у них начался еще в 70-х годах, то есть уже более тридцати лет он в действии, и их же статистика упрямо говорит, что в среднем еще в 80-е годы каждый японский рабочий или служащий ежегодно вносил пять-шесть предложений по совершенствованию производственного процесса, из которых шестьдесят-восемьдесят процентов реализовывались на практике.
