МандарЫнка писал(а):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-шников) --> отсюда Вы вычисляете -- кто из своих чем занимался, что успел сделать, какие проблемы и где затыки. Но эта штука будет работать, если люди реально будут заносить текущие статусы своей работы и если сделан правильно план на проект.