внедрение Quality Management System в компании

Все, что касается управления качеством...

Модератор: YuriY

внедрение Quality Management System в компании

Сообщение МандарЫнка » 30 мар 2011, 15:50

Кто-нибудь сталкивался с подобной задачей? с чего начинали? как прошел переход на новые стандарты? какие артефакты создавались? Следовали ли вы каким-то конктерным стандартам или же изобретали велосипед?
МандарЫнка
Junior
 
Сообщений: 25
Зарегистрирован: 10 апр 2008, 11:49

Сообщение sae » 31 мар 2011, 14:59

у меня порядок примерно такой был:
1. Определение (создание) процессов (или четкое выявление) всех существующих и требуемых процессов на фирме
2. Четкое описание Typical Flow жизни проекта
3. Анализ применимости стандартных моделей к существующему с целью выявления возможности минимизировать изменения стандартных моделей. (Если необходимо, то подгонка)
4. Составление четких процессов работы QA на всех этапах жизни проекта (с составлением целей работы QA, последовательности действий, входных и выходных данных (документов), способов мониторинга, способов влияния на процессы и активности, методов оценки и т.д.)
5. Подборка средств мониторинга, документирования, баг-трэкинга, средств тестирования и завязывание всего этого в единую систему.
6. Включение задач QA на всех этапах разработки в план на проект
7. Мониторинг проекта и задач QA на всех этапах жизни проекта

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

Но главная последовательность внедрения у меня осталась неизменной:
1. Определиться с процессами в компании
2. Выявить, как можно с точки зрения QA внедриться в каждый процесс, мониторить его и влиять на него.
3. Максимально формализовать внедрение QA в каждый процесс (на уровне документов, планов, входных и выходных результатов работы QA, каких-либо активностей и т.д.)
4. Подобрать software средства для QA Management System
5. Обеспечить жесткую обратную связь на каждой активности QA
sae
Newcomer
 
Сообщений: 3
Зарегистрирован: 31 мар 2011, 12:29

Сообщение МандарЫнка » 01 апр 2011, 16:06

2. Четкое описание Typical Flow жизни проекта

хороший пункт, но как быть, если в компании проекты совершенно разных типов и направлений и каждый имеет свое флоу?


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

Подборка средств мониторинга
например? какие именно средства имеются ввиду?

Обеспечить жесткую обратную связь на каждой активности QA

обратная связь- это хорошо, если метрики можно снимать автоматически. но если у ПМа 50 проектов и все горят, и он не станет оформлять какой-либо фидбек..?
МандарЫнка
Junior
 
Сообщений: 25
Зарегистрирован: 10 апр 2008, 11:49

Сообщение sae » 01 апр 2011, 17:20

МандарЫнка писал(а):
2. Четкое описание Typical Flow жизни проекта
хороший пункт, но как быть, если в компании проекты совершенно разных типов и направлений и каждый имеет свое флоу?


Для каждого проекта --> свой флоу, в идеале, конечно, лучше унифицировать, но если эти флоу действительно оптимизированы и требуются проектам, то от этого никуда не уйти. Если же есть хоть малейшая возможность унификации этих флоу (или хотя бы отдельных процессов на этих проектах) -- то надо менять и униффицировать флоу.

МандарЫнка писал(а):
Анализ применимости стандартных моделей к существующему с целью выявления возможности минимизировать изменения стандартных моделей
Как можно разрешить ситуацию, когда теория остается теорией. например, стандарт предполагает управление рисками. но в реале на это просто нет времени. да, мы в QMS указываем что хотим управлять рисками, даже задаем какие-то шаблоны для управления, но реально эти артифакты рискуют так и остаться бумагами.


Наверное, вы все-таки управляете рисками, неосознанно и не формализовано :) Я думаю, что вы все равно как-то оцениваете хотя бы критичные риски, как-то пытаетесь их минимизировать, прогнозируете какие-то активности, их срыв и так далее. Просто чаще всего это делается ПМ-мом или на коротких митингах и какждый делает это в своей "песочнице" в отрыве от общего флоу. Вы попытайтесь делать каждый день утром и вечером короткие 5-минутки по текущим активностям с учетом рисков и вы увидите, что риски таки вы обсуждаете :). Когда речь идет о какихто глобальных рисках, то вы их наверняка тоже обсуждаете, просто управлять ими очень сложно, когда мало ресурсов и недостаточно информации о всем проекте. Поэтому самое важное в управлении рисками -- владеть ПОЛНОЙ информацией по проекту и иметь рычаги влияния на всех, кто хоть как-то влияет на проект. Ну а потом попытаться поработать с рисками. ТОлько не надо сильно их "формалить". Сильно "формалить" надо сами методики работы с рисками, а непосредственно риски надо быстро оценить и отрегаировать.

МандарЫнка писал(а):
Подборка средств мониторинга
например? какие именно средства имеются ввиду?


Я имею ввиду баг-трекинг систему, системe учета плана задач и активностей по ресурсам (ОБЯЗАТЕЛЬНО ежедневный трекинг выполнения активностей и задач) по всем ресурсам, систему работы с тест кейсами, систему учета документации, и т.д., то есть любые средства, которые могут дать хоть какую-то информацию о проекте. Но тут важно сделать так, чтобы они были завязаны друг на друга, а Вы, как "паук" должны сидеть в центре этой паутины и мониторить информацию. :) . Как только ниточки паутины становятся "красными" (цвет и скорость и интенсивность "краснения" ниточки надо подобрать), то сразу же звенит "звоночек" и надо бежать и лупить кого-то (того, кто завязан на эту ниточку), (хотя если система настроена правильно, то тот самый "виноватый" сам наченет копошиться раньше Вас.

МандарЫнка писал(а):
Обеспечить жесткую обратную связь на каждой активности QA

обратная связь- это хорошо, если метрики можно снимать автоматически. но если у ПМа 50 проектов и все горят, и он не станет оформлять какой-либо фидбек..?


А вот это просто кошмар, если у ПМ-а 50 проектов. Ситуация провальная в таком случае. Я, честно говоря, не могу поверить в такой расклад, когда у ПМ-а больше нескольких проектов. Если это так, то ПМ-м просто не занимается ПМ-ством (это уже не ПМ просто), а скидывает его на леад-девелопера или еще кого-то и занимается только попытками общей оценки этих 50-ти проектов, но наверное это уже не ПМ в чистом виде. В любом случае, пусть в Вашей ситуации это будет не ПМ, а кто-то (обозвать можно как-угодно), но должен быть кто-то, кто в состоянии в реальном времени отреагировать на реальные проблемы и обязательно иметь власть и ресурсы решать эти проблемы (иначе он будет просто "рупором" ПМ-а, у которого 50 проектов :) ).
sae
Newcomer
 
Сообщений: 3
Зарегистрирован: 31 мар 2011, 12:29

Сообщение МандарЫнка » 04 апр 2011, 11:28

sae писал(а):Если же есть хоть малейшая возможность унификации этих флоу (или хотя бы отдельных процессов на этих проектах) -- то надо менять и униффицировать флоу.
МандарЫнка писал(а):загвоздка в том, что кроме непосредственно тестирования все остальные фазы и активности очень разные, т.е то же планирование либо есть либо нет, документация, отчетность, подведение итогов, промежуточное тестирование-- слишком многие факторы могут розниться
и если написать идеальный воркфлоу то 1 из 10и проектов сможет ему следовать. остальное все так и будет на коленях.

Наверное, вы все-таки управляете рисками, неосознанно и не формализовано :)
безусловно. но вопрос формализации процессов отчести растет своими корнями из желания перенимать лучшие практики и наработки. Например ПМ Вася ведет 10 мелких проектов и 8 из них успешны. при этом на проекте нет совершенно никакой документации, требования не фиксированны, состояние проектов стрессовое. Успех достигается исключительно за счет личных качеств Васи и других разработчиков, привыкших к Васиным инструкциям. Если завтра Вася заболеет\уйдет в отпуск\уволится- ситуация будет критичной. т.к никто не сможет вести эти проекты не имея никакой информации\инструкций\шаблонов и тп. Кроме того, Вася испытывает колосальную нагрузку от того, что все 10 его проектов стрессовые. но перевести проекты на другого Пма мы не можем, так как они очень шаткие и кроме Васи никто не знает что с ними делать. Да, Вася управляет рисками на лету, прогнозирует их и успевает подстелить соломку. Но полная неформализация процесса разработки на этих проектах делает невозможным возможность существования без Васи
(как-то мутно получилось, но надеюсь, мысль понятна :) )


ОБЯЗАТЕЛЬНО ежедневный трекинг выполнения активностей и задач

Ну, этот пункт относится опять=таки не только к тестировщику, но и к проекту в целом. а заставить программистов, которые приходят на работу в 10 и уходят в 10, заносить все задачи в трекер и заставить их снова-таки следовать воркфлоу - задача не простая. Т.е все упирается в то, что концептуально все "ЗА" изменения, "ЗА" введение QMS и "ЗА" стандартизацию но у всех просто нет на это время, т.к в текущем бедламе все худо-бедно работает, а если начнем тратить время на занесение тасков и отслеживание воркфлоу - можем не успеть с релизом.


А вот это просто кошмар, если у ПМ-а 50 проектов. Ситуация провальная в таком случае.

ну, 50 - такого действительно не бывает. утрирую :)
но до 10и паралельных в принципе бывает.
но реалии таковы, что кроме как на Performance review узнать точный фидбек о всех задачах, выполненых Qa не представляется возможным
МандарЫнка
Junior
 
Сообщений: 25
Зарегистрирован: 10 апр 2008, 11:49

Сообщение sae » 08 апр 2011, 16:33

МандарЫнка писал(а):
sae писал(а):Если же есть хоть малейшая возможность унификации этих флоу (или хотя бы отдельных процессов на этих проектах) -- то надо менять и униффицировать флоу.
МандарЫнка писал(а):загвоздка в том, что кроме непосредственно тестирования все остальные фазы и активности очень разные, т.е то же планирование либо есть либо нет, документация, отчетность, подведение итогов, промежуточное тестирование-- слишком многие факторы могут розниться
и если написать идеальный воркфлоу то 1 из 10и проектов сможет ему следовать. остальное все так и будет на коленях.


Я могу только дать рекомендации, как бы я поступал в такой ситуации: есть полный общий набор активностей - его надо делать и унифицировать. И для каждого проекта пытаться проходить эти фазы. Да, чать активностей на начальном этапе будет фейковой - по разным причинам. Но сами фазы надо проходить и пытаться их хоть как-то отследить. Эти фазы должны быть формально отмечены, уних есть отвественные, есть планы, задачи и сроки. И в работе надо отмечать прохождение каждой фазы, даже если она не выполнена. После завершения фазы надо посмотреть, как она повлияла на проект. Если фаза фейковая и она не влияет вообще на проект -- я бы от нее избавлялся. Но по моему опыту -- у меня не нашлось ни одной фековой фазы или фазы, которая бы вообще не принесла пользы в проект. Как я определяю пользу -- если фаза повышает эффективность работы напроекте -- то ее надо внедрять. Как я считаю эффективность -- в ресурсах и качестве работы. Если активность дала прирост в этих параметрах и Вы смогли явно показать прирост эффективности -- то Вы сможете внедрить фазу. Если по каким-то причинам (даже если фаза эффектина), но Вы не смогли доказать эту эффектиность -- то Вас просто не поймут. Поэтому надо каждый раз доказывать эффективность :)

МандарЫнка писал(а):
sae писал(а):
Наверное, вы все-таки управляете рисками, неосознанно и не формализовано :)
безусловно. но вопрос формализации процессов отчести растет своими корнями из желания перенимать лучшие практики и наработки. Например ПМ Вася ведет 10 мелких проектов и 8 из них успешны. при этом на проекте нет совершенно никакой документации, требования не фиксированны, состояние проектов стрессовое. Успех достигается исключительно за счет личных качеств Васи и других разработчиков, привыкших к Васиным инструкциям. Если завтра Вася заболеет\уйдет в отпуск\уволится- ситуация будет критичной. т.к никто не сможет вести эти проекты не имея никакой информации\инструкций\шаблонов и тп. Кроме того, Вася испытывает колосальную нагрузку от того, что все 10 его проектов стрессовые. но перевести проекты на другого Пма мы не можем, так как они очень шаткие и кроме Васи никто не знает что с ними делать. Да, Вася управляет рисками на лету, прогнозирует их и успевает подстелить соломку. Но полная неформализация процесса разработки на этих проектах делает невозможным возможность существования без Васи
(как-то мутно получилось, но надеюсь, мысль понятна :) )



Насчет "Васи" -- есть такое выражение (я его полностью поддерживаю :)), что если я становлюсь незаменимым, то меня надо срочно увольнять. Пример "Васи" - это как раз такой пример. Как только "Вася" прекратит работу (по разными причинам -- заболел, уволился, устал и так далее), то все его проекты рухнут. Надо ЛЮБОЙ ценой избавляться от незаменимых людей. Не в том смысле, что их надо увольнять (а иногда и это приходится делать), а в том смысле -- что документация, процессы и требования для того и существуют, чтобы не зависеть от человеческого фактора а завязать работу и активности на формальный процесс. Случай с "Васей" -- это как раз анализ риска. Риск просто огромен. Я бы попытался выяснить -- по каким причинам "Вася" создал такую ситуацию. Эта ситуация не выгодна никому ("Васе" тоже, наверное, не сладко приходится, если он не мазохист), но "Вася" наверняка создал ее искуственно -- очень приятно, когда все тебя считают незаменимым. Надо рушить эту ситуацию. Как разрушить -- вариантов тоже достаточно. Но в Вашей ситуации -- я не знаю, в чем причина, и если "Вася" -- сам инициатор такой ситуации, то он будет сопротивляться нарушению его монополии. :)

МандарЫнка писал(а):
sae писал(а):ОБЯЗАТЕЛЬНО ежедневный трекинг выполнения активностей и задач

Ну, этот пункт относится опять=таки не только к тестировщику, но и к проекту в целом. а заставить программистов, которые приходят на работу в 10 и уходят в 10, заносить все задачи в трекер и заставить их снова-таки следовать воркфлоу - задача не простая. Т.е все упирается в то, что концептуально все "ЗА" изменения, "ЗА" введение QMS и "ЗА" стандартизацию но у всех просто нет на это время, т.к в текущем бедламе все худо-бедно работает, а если начнем тратить время на занесение тасков и отслеживание воркфлоу - можем не успеть с релизом.


Да, это не простая задача. Надо делать планы, надо трекать таски, это занимает время. Но опять же, по моему опыту, среднее время на занесение дневного "work log" не занимает более 5 - 10 минут (это если установлена система трекинга тасок и она завязана на план). А все разговоры о том, что за день не найдется 10 минут максимум на трекинг выполненной работы -- это просто отговорки. Просто так очень удобно, когда время (в пределах каких-то) безконтрольно и можно не отчитываться о времени. Насчет того, что время занесения тасок серьезно влияет на сроки релиза -- это (опять же по моему мнению) -- настоящее лукавство от лентяев. Просто девелоперы (в болшинстве своем) работают с группой своих задач и достаточно часто не отслеживают общие задачи и сроки их выполнения. Работа идет по принципу -- получил задачу и работай над ней, а что там дальше -- это уже забота ПМ-а. И тут инициатором должен быть ПМ и QA. Но тут много можно говорить о мотивации персонала работать "как правильно" - это отдельная тема. В Вашей ситуации Вам надо подтвердить реально, что выполнение этого даст прирост эффективности (подтвердить цифирьками желательно). Как только Вы это сделаете -- Вам останется только побороть лентяеев и все :).


МандарЫнка писал(а):
А вот это просто кошмар, если у ПМ-а 50 проектов. Ситуация провальная в таком случае.

ну, 50 - такого действительно не бывает. утрирую :)
но до 10и паралельных в принципе бывает.
но реалии таковы, что кроме как на Performance review узнать точный фидбек о всех задачах, выполненых Qa не представляется возможным


Тут опять же -- я просто не могу понять -- как у Вас там идет работа, что Вы не можете определить, что у вас там творится. Каждый сотрудник имеет пул задач. Каждый день он трекает выполненные задачи или отмечает статус по активным задачам. В конце дня (или в любой момент) -- Вы поднимаете систему учета активностей и смотрите два направления -- 1) Статусы ВСЕХ задач по проекту (или по выбранным проектам или по всем проектам) --> отсюда можно определить текущее состояние на проекте. 2) Смотрите сплошным порядком всех "своих" сотрудников (наприемр QA-шников) --> отсюда Вы вычисляете -- кто из своих чем занимался, что успел сделать, какие проблемы и где затыки. Но эта штука будет работать, если люди реально будут заносить текущие статусы своей работы и если сделан правильно план на проект.
sae
Newcomer
 
Сообщений: 3
Зарегистрирован: 31 мар 2011, 12:29


Вернуться в Управление качеством | Quality Management

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4

cron