Модератор: YuriY
2. Четкое описание Typical Flow жизни проекта
Как можно разрешить ситуацию, когда теория остается теорией. например, стандарт предполагает управление рисками. но в реале на это просто нет времени. да, мы в QMS указываем что хотим управлять рисками, даже задаем какие-то шаблоны для управления, но реально эти артифакты рискуют так и остаться бумагами.Анализ применимости стандартных моделей к существующему с целью выявления возможности минимизировать изменения стандартных моделей
например? какие именно средства имеются ввиду?Подборка средств мониторинга
Обеспечить жесткую обратную связь на каждой активности QA
МандарЫнка писал(а):2. Четкое описание Typical Flow жизни проектахороший пункт, но как быть, если в компании проекты совершенно разных типов и направлений и каждый имеет свое флоу?
Для каждого проекта --> свой флоу, в идеале, конечно, лучше унифицировать, но если эти флоу действительно оптимизированы и требуются проектам, то от этого никуда не уйти. Если же есть хоть малейшая возможность унификации этих флоу (или хотя бы отдельных процессов на этих проектах) -- то надо менять и униффицировать флоу.МандарЫнка писал(а):Как можно разрешить ситуацию, когда теория остается теорией. например, стандарт предполагает управление рисками. но в реале на это просто нет времени. да, мы в QMS указываем что хотим управлять рисками, даже задаем какие-то шаблоны для управления, но реально эти артифакты рискуют так и остаться бумагами.Анализ применимости стандартных моделей к существующему с целью выявления возможности минимизировать изменения стандартных моделей
Наверное, вы все-таки управляете рисками, неосознанно и не формализовано Я думаю, что вы все равно как-то оцениваете хотя бы критичные риски, как-то пытаетесь их минимизировать, прогнозируете какие-то активности, их срыв и так далее. Просто чаще всего это делается ПМ-мом или на коротких митингах и какждый делает это в своей "песочнице" в отрыве от общего флоу. Вы попытайтесь делать каждый день утром и вечером короткие 5-минутки по текущим активностям с учетом рисков и вы увидите, что риски таки вы обсуждаете . Когда речь идет о какихто глобальных рисках, то вы их наверняка тоже обсуждаете, просто управлять ими очень сложно, когда мало ресурсов и недостаточно информации о всем проекте. Поэтому самое важное в управлении рисками -- владеть ПОЛНОЙ информацией по проекту и иметь рычаги влияния на всех, кто хоть как-то влияет на проект. Ну а потом попытаться поработать с рисками. ТОлько не надо сильно их "формалить". Сильно "формалить" надо сами методики работы с рисками, а непосредственно риски надо быстро оценить и отрегаировать.МандарЫнка писал(а):например? какие именно средства имеются ввиду?Подборка средств мониторинга
Я имею ввиду баг-трекинг систему, системe учета плана задач и активностей по ресурсам (ОБЯЗАТЕЛЬНО ежедневный трекинг выполнения активностей и задач) по всем ресурсам, систему работы с тест кейсами, систему учета документации, и т.д., то есть любые средства, которые могут дать хоть какую-то информацию о проекте. Но тут важно сделать так, чтобы они были завязаны друг на друга, а Вы, как "паук" должны сидеть в центре этой паутины и мониторить информацию. . Как только ниточки паутины становятся "красными" (цвет и скорость и интенсивность "краснения" ниточки надо подобрать), то сразу же звенит "звоночек" и надо бежать и лупить кого-то (того, кто завязан на эту ниточку), (хотя если система настроена правильно, то тот самый "виноватый" сам наченет копошиться раньше Вас.МандарЫнка писал(а):Обеспечить жесткую обратную связь на каждой активности QA
обратная связь- это хорошо, если метрики можно снимать автоматически. но если у ПМа 50 проектов и все горят, и он не станет оформлять какой-либо фидбек..?
sae писал(а):Если же есть хоть малейшая возможность унификации этих флоу (или хотя бы отдельных процессов на этих проектах) -- то надо менять и униффицировать флоу.ОБЯЗАТЕЛЬНО ежедневный трекинг выполнения активностей и задачМандарЫнка писал(а):загвоздка в том, что кроме непосредственно тестирования все остальные фазы и активности очень разные, т.е то же планирование либо есть либо нет, документация, отчетность, подведение итогов, промежуточное тестирование-- слишком многие факторы могут розниться
и если написать идеальный воркфлоу то 1 из 10и проектов сможет ему следовать. остальное все так и будет на коленях.безусловно. но вопрос формализации процессов отчести растет своими корнями из желания перенимать лучшие практики и наработки. Например ПМ Вася ведет 10 мелких проектов и 8 из них успешны. при этом на проекте нет совершенно никакой документации, требования не фиксированны, состояние проектов стрессовое. Успех достигается исключительно за счет личных качеств Васи и других разработчиков, привыкших к Васиным инструкциям. Если завтра Вася заболеет\уйдет в отпуск\уволится- ситуация будет критичной. т.к никто не сможет вести эти проекты не имея никакой информации\инструкций\шаблонов и тп. Кроме того, Вася испытывает колосальную нагрузку от того, что все 10 его проектов стрессовые. но перевести проекты на другого Пма мы не можем, так как они очень шаткие и кроме Васи никто не знает что с ними делать. Да, Вася управляет рисками на лету, прогнозирует их и успевает подстелить соломку. Но полная неформализация процесса разработки на этих проектах делает невозможным возможность существования без ВасиНаверное, вы все-таки управляете рисками, неосознанно и не формализовано
(как-то мутно получилось, но надеюсь, мысль понятна )
А вот это просто кошмар, если у ПМ-а 50 проектов. Ситуация провальная в таком случае.
МандарЫнка писал(а):sae писал(а):Если же есть хоть малейшая возможность унификации этих флоу (или хотя бы отдельных процессов на этих проектах) -- то надо менять и униффицировать флоу.МандарЫнка писал(а):загвоздка в том, что кроме непосредственно тестирования все остальные фазы и активности очень разные, т.е то же планирование либо есть либо нет, документация, отчетность, подведение итогов, промежуточное тестирование-- слишком многие факторы могут розниться
и если написать идеальный воркфлоу то 1 из 10и проектов сможет ему следовать. остальное все так и будет на коленях.
МандарЫнка писал(а):sae писал(а):безусловно. но вопрос формализации процессов отчести растет своими корнями из желания перенимать лучшие практики и наработки. Например ПМ Вася ведет 10 мелких проектов и 8 из них успешны. при этом на проекте нет совершенно никакой документации, требования не фиксированны, состояние проектов стрессовое. Успех достигается исключительно за счет личных качеств Васи и других разработчиков, привыкших к Васиным инструкциям. Если завтра Вася заболеет\уйдет в отпуск\уволится- ситуация будет критичной. т.к никто не сможет вести эти проекты не имея никакой информации\инструкций\шаблонов и тп. Кроме того, Вася испытывает колосальную нагрузку от того, что все 10 его проектов стрессовые. но перевести проекты на другого Пма мы не можем, так как они очень шаткие и кроме Васи никто не знает что с ними делать. Да, Вася управляет рисками на лету, прогнозирует их и успевает подстелить соломку. Но полная неформализация процесса разработки на этих проектах делает невозможным возможность существования без ВасиНаверное, вы все-таки управляете рисками, неосознанно и не формализовано
(как-то мутно получилось, но надеюсь, мысль понятна )
МандарЫнка писал(а):sae писал(а):ОБЯЗАТЕЛЬНО ежедневный трекинг выполнения активностей и задач
Ну, этот пункт относится опять=таки не только к тестировщику, но и к проекту в целом. а заставить программистов, которые приходят на работу в 10 и уходят в 10, заносить все задачи в трекер и заставить их снова-таки следовать воркфлоу - задача не простая. Т.е все упирается в то, что концептуально все "ЗА" изменения, "ЗА" введение QMS и "ЗА" стандартизацию но у всех просто нет на это время, т.к в текущем бедламе все худо-бедно работает, а если начнем тратить время на занесение тасков и отслеживание воркфлоу - можем не успеть с релизом.
МандарЫнка писал(а):А вот это просто кошмар, если у ПМ-а 50 проектов. Ситуация провальная в таком случае.
ну, 50 - такого действительно не бывает. утрирую
но до 10и паралельных в принципе бывает.
но реалии таковы, что кроме как на Performance review узнать точный фидбек о всех задачах, выполненых Qa не представляется возможным
Вернуться в Управление качеством | Quality Management
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6