Та ну, зная совок ... все записано, в архив сложено. Просто это тебе не в строке поиска запрос писать, а вручню перебирать, заказывать следующие документыи работать-работать :)
Я сам первую дипломную на бакалавра писал в библиотеке. Современным детям даже не пояснить, как оно. Но в реале - довольно таки быстро.
Ну так тут не промышленные масштабы, а как раз штучный проект
Ты думаешь, если поставить задачу, не поднимут один условный паровоз с колен? Да изи при таком бюджете. Вот условно перевезти одну железку на паровозную тягу нереально, а штучно - там по винтигу разобрать/собрать. Бюджет то ого-го :)
Все ж есть кстати, и ретро машинки, и паровозы, и парусники. Но 7 миллиардов людей можно найти любое извращение ;)
Я думаю, более рабочей выглядит связка дизайнера и бизнес-аналитика со знанием домена, который не стесняются спросить мнение лида/архитекта
И единорогов на рынке искать не надо
А дизайнер с опытом и так знает достаточно, как работает в целом приложение технически, либо хотя бы может сказать "а в моем прошлом проекте оно так работало"
Согласен. Но ведь носителями инженерной культуры инженеры и являются :)
Культура это всего то, что поддерживается основными людьми в организации. И трудно себе предствить организацию, при которой культура сама по себе, а главный конструктор сам по себе
Плюс, никто ведь не запрещает конкретному спецу не делать фигню. Корпоративная культура - это сильно, но своя всегда сильнее для себя лично.
Понятно есть те, кто свою часть сделал хорошо. Но я лично могу этим в своей работе удовлетворитьмя, если точно уверен что "красавчик"
По примерам ... корабли, кареты ... все есть, просто нишевое. Банально для массмаркета никому не надо, но сомневаться в том, что под заказ любвя страна первого эшелона может построить паровоз несколько странно. Лошади как тяговое средство еще используются, достаточно к примеру покататься по Румынии. И опять же - все навыки есть. У меня дочка конным спортом занимается к примеру. С парусниками еще проще, дойти до любой марины и все ;) Парусников сколько угодно
Момент два. Дока на все точно сохранилась и явно не на мертвом языке. Т.е. для спецов там ничего потайного нет.
Большая часть вообще тупо не уникальна, тот же носитель с Земли до околоземной орбиты. Это вообще рутина
В целом "управляемые" полеты на орбите тоже рутина, вон сколько вокруг земли летает всего.
Связь ... ну тоже смешно. Советские люди смогли передать точка-тире на той элементной базе, не смочь сейчас ... да и явно эти блоки можно заменить на современные.
Как по мне, банальный кризис менеджмента. Прлсто для многих ИТ-шников ПМ это бесполезная тушка, которая ходит и "водит руками", но в реальности это основа всего на сложном проекте. Тут скорее всего полная .опа.
В теории да, разгрузим дороги, улучшим жизнь ... как выглядит,можно посмотреть в фильме "5 элемент" например
Но в реале мне кажется проблема в том, что авто поток массовый, а леталки штучный. Ну реально, сколько в реале их надо, чтобы снять нагрузку с 2-3 полоски? Десятки тысяч? Многовато
Получается для них просто нет масслвой ниши, точнее они бесконечно далеки от массовости. А для избранных и сейчас есть куча вариантов. Частные вертолеты - без проблем. Лакшери авто и наемный водитель, чтобы паботать в пробках - изи.
В целом, разкм подсказывает при взгляде на проблему смотреть на техническое задание, и от него уже смотреть на то, что есть. Иначе не имеет смысла
Человек берется в команду в идеале после собеседования, на котором проверяется наличие hard/soft скилов, а также обычно кандидата знакомят с проектом и задачами
Также очевидно, что если есть конкретные ожидания, например к решению есть требования по производительности, которые надо будет проверит, то они озвучиваются.
Но в рамках экспертизы QA ПМ не должет ставить детальные задачи. Как и другим ролям. Но может контролировать. К примеру, начинается большой проект. Есть до головы QA лида не дошла светлая мысль, которая заключаеться в необходимости начать работу над тестовой стратегией, то ПМ вполне может спросить, а почему лид все еще занимает положение "сижу на жопке" ровно? Ну и походу стоит попросить другого спеца посмотреть, чего лид туда написал и не написал. И найти экспертов которые помогут туда вписать все что нужно. Это нормально, еж птица гордая и инфантильная.
Но в целом, мне не очень понятно в чем суть. Человек с опытом ЗНАЕТ, что надо делать. Ему нужны детали/нюансы конкретного проекта, либо бебиситер в виде лида. Еслм лиду нужен бебиситер - то лиду точно пора на выход. Тут все просто.
Про то, что делает ПМ - да очень много чего, не только управленческие решения. Как минимум очевидно, что чтобы чего то принимать, надо убедится, что есть достаточно вводных.
А для этого, как раз нужна ориентация QA на фичи, а не на баги
Пример. Утренний ответ на стандартные вопрос от QA.
Закончил покрытие тестов к фиче 111, возьму покрытие фича 222 и протестирую фичу 333. Планирую сделать за день. Отлично
Написал 20 тест кейсов к фиче XYZ, нашел 5 багов в фиче ABC. Очень плохо :)
Задача ПМ в таком случае трансформировать инфу и фокус QA с нижнего варианта ответа на верхний :)
А чем в целом изначально я и талдычу :) Как и о практической бесполезности измерения работы, качественно и количественно багами
Я обычно работал в организациях, где либо есть стандартны качества, либо люди и так понимают зачем. Вариаент без QA - только когда есть маленькая команда и можно просто кросс чекать друг друга
Про поставить задачу. Взгляд с другой стороны :) Я ПМ, или частично вывполняю его функции. У меня есть QA, или даже команда. Я нанимаю кого-то с опытом 15 лет. Блин, какая постановка задачи ожидается?
Во-первых. На большом проекте может быть 5+ команд разработчиков, разномастный заказчик с 7 говорящими головами, 2+ спонсора, куча мерзких запрещалок, контракты с тремя поставщиками, 2 из которых из-за бугра. Куча доки, которую надо вести. 10 встреч каждый день, 100+ писем, и много-много другого. ПМ нанял в команду QA команду с лидом, чтобы тратить время на постановку задачи?
Реально на это физически нет времени. Для этого и берется лид, который не просит поставить задачу, а организует процесс тестирования. Да, именно так. Ожидается, что человек с опытом знает как построить свой процесс и ему нужен ПМ для решения орг. вопросов. Конечно, я лично еще не встречал QA, которые бы не просили помощи в технических вопросах, так где сложно, но это нормально. Точнее они есть, те кто могут сами, но стоят дорого, и сразу фиг дадут.
Поэтому, подытоживая. Да, спец с опытом знает, зачем он в проекте и ему надо только уточнить детали, как именно в будет тут. Бэби ситтингом никому заниматься не интересно, кроме удовлетворения преподавательского зуда.
По контроль - да, это пичалька. Если первый вопрос тестировщику на совеседовании "какой ваш added value", то вот ПМа стоит спросить в целом по каждой роли и "что вы выносите с утренних стенд-апов". Ответ на последний часто удручает :(
Но тогда есть надежда на то, что в команде будет сильный аналитик/архитектор/тимлид, которые тут подстрахуют
> все ПМ, которых я опрашивал, уверены, что тестировщик отвечает за качество продукта.
Ну, не совсем. QA подтверждает, что разработанный продукт соответствует требованиям к нему в рамках своих компетенций. QA не может сделать продукт качественнее. Он только указывает на дефекты. Поэтому формально формулировка неверна. Что при этом вкладывают эти ПМ в эти слоаа я догадаться не могу, сорян
А что до ситуации ... ну так если ПМ ни черта не делает, чуда тоже не произойдет. Да длинном проекте можно увидеть достаточно признаков заоанее, что есть проблемы и заняться их исправлением до того, как подкрадется песец.
Но основная мысль в том, что если QA ищет баги, это уже проблема :) QA, как и DEV - закрывает фичи, только по своему
Дело в том, что избранная мера в виде количества багов глубоко вторична по отношению к мере готовности приложения к проду в виде списка фич/требований.
Как следствие, ориентированность команды QA на поиск багов, а девов на их фикс в реальности приводит к расфокусировке от важных вещей
Команда должна быть сфокусирована на фичах и их готовности к проду. Тогда релизы будут иметь смысл, так как будут состоять из протестированных фич, которые наиболее важны.
Это как 10 стаканов. Я не успеваю наполнить все 10 объективно? ОК, я наполню 7 самых важных, а на 3 забью. Если я фокусируюсь на багах, я могу получить 3 полных, и 7 почти полных. И даже в первом случае может быть условно 5 критикалов и 25 медиум, а во втором 2 критикала, и 12 медиумов. Но первый релиз выглядит намного лучше второго
Поэтому QA НЕ ИЩЕТ БАГИ. Он проверяет ГОТОВНОСТЬ ФИЧ, начиная с самых важных. А если продолжает искать баги и не исправляется, значит идет за борт :)
Даже сейчас ты пишешь про задачу, которая не имеет смысла. В проде не выходит отсутствие багов. В прод выходят одобренные фичи. И именно количество фич - мерило успеха команды.
Отдельный вопрос, если фича задекларирована как готовая, а в пподе вылез баг. Это повод для ретроспективного анализа и работы над техниками, взаимодействием и т.д. Но если команда изначально ориентирована не туда - она уже неэффективна
Ну или еще. QA находит баги. Много, мало ... это хорошо или плохо? ХЗ. Ну реально. Может багов и правда мало, а может и много. Это не важно. Важно мерять работу QA по количеству фич, которые он либо одобрил к выходу в прод, либо протестил и выкатил список багов. Тогда легко понять продуктивность команды и все остальное. И легко проверить качество работы тестировщика. Если окажется, что в готовой фиче есть баги (которые нашел клиент) или в "протестированной" фиче нашлись новые баги без изменения кода - это повод устроить QA команде разбор полетов
Ну, я работал и чистым ПМом, но объективно это не моя основная специальность
Вообще, выше я написал. QA команда работает, покрывая тестами и собственно тестируя требования/фичи, в зависимости от релизной политики. На коротких релизах это фичи, на длинных - требования. Так они имеют цель и смвсл жизни в команде.
Периодически QA готовят отчет, где мы в части готовности к проду. Т.е. что и скоупа готово, а что нет. Что не готово, обязательно классифицируется по тяжести багов. Так все знают текущий статус, включая заказчика.
Оперативно, часто с помощью жопомера и иных потусторонних сил, оценивается, насколько много шансов успеть к дедлайну и пора ли "паниковать" (резать скоуп, добавлять ресурсы, менять приоритеты). Также, если идентифицированы проблемы (тикеты не закрываются, появляются новые, переоткрываются старые), надо собраться и устранить корень возникновения проблемы.
Иногда надо QA помочь, так как уровень их технических знаний обычно невелик и багальное "я сейчас расскажу, как можно автоматизировать это штуку" может сильно ускорить процесс
В целом ничего уникального. В проекте должна быть цель, путь и движение к цели по этому пути, которое измеримо. И ежедневное вджобывание :)
Про БОЛЬШОЙ проект ... хз, кому что большое. У меня самый большой это Интернет банкинг, где одновременно трудилось до 10 команд в разных точках решения. Но он принципиально не отличается. Подходы те же. Просто надо ж понимать, что если условно он еще больше, то на проекте желательно иметь больше одного ПМа. Т.е. ничего страшного нет в том, что на большом проекте и лбдей больше, в том числе "с погонами".
В статье основная проблема и возможно, корень ее в том, что тестирование идет от требований, а не от багов.
Из опыта кстати, именно командам QA приходится чаще всего вставлять пистоны и проводить лекции на тему, как стать лучше. Некоторые воспринимают и дело идет на лад, с некоторыми приходится расставаться, иногда после жесткой беседы, так как иные методы не сработали :(
Дополнительно. Про большой проект. Да по фиг. В роли ПМа я ожидаю получить от QA ответ по списку:
Это протестировано и готово
Это в работе, вот список багов
Это покрывается тестами
Это вообще ХЗ что, будем покрывать
Где взять этот список - это мой вопрос. Возьму аналитика за жабры и заставлю написать. Не важно. Список будет. Иначе НИКТО НЕ БУДЕТ ЗНАТЬ ГДЕ МЫ И ЧТО МЫ ДЕЛАЕМ.
Потому что любой проект/релиз - это конечная и описанная активность. Либо в виде требований, либо в виде бэклога. Не важно.
Еслм что-то не описано, как например "ковыряние овна мамонта", значит оно есть на столе именно в таком виде. Но тогда QA туда соваться еще рано
Но вот что точно будет, так это пендаль QA, который на проекте занимается "сврбодным" поиском багов.
Не нужно описывать требования. Нужно для начала иметь из список. Это есть всегда, сорян. Даже в виде сторек из Jira.
Дальше QA команда:
Пишет стратегию, как они это будут тестить. Виды тестирования, как именно тестить, тулы и т.д
Каждое требование покрывается тест кейсами, которые собираются в сценарии. Как именно - это вопрос QA команды
И идет работа
Главное, работа идет по списку требований. Они могут быть связаны, собраны в группы, релизы. Это уже детали. Но ... всем начиная с ПМа интересно статус работ по тестированию в разрезе требований. Если QA этого не может дать - он идет далеко и прямо.
А аот по этому списку уже можно работать. Например:
Срезать скоуп релиза, оставив только то, что ПРОТЕСТИРОВАНО
Обратить внимание на проблемнве требования
Увидеть влияние багов на другие требовантя по связке требований
Планировать работы, так как прогрес измерим и явно видет
Та ну, зная совок ... все записано, в архив сложено. Просто это тебе не в строке поиска запрос писать, а вручню перебирать, заказывать следующие документыи работать-работать :)
Я сам первую дипломную на бакалавра писал в библиотеке. Современным детям даже не пояснить, как оно. Но в реале - довольно таки быстро.
Вджобывать просто надо :)
Ну так тут не промышленные масштабы, а как раз штучный проект
Ты думаешь, если поставить задачу, не поднимут один условный паровоз с колен? Да изи при таком бюджете. Вот условно перевезти одну железку на паровозную тягу нереально, а штучно - там по винтигу разобрать/собрать. Бюджет то ого-го :)
Все ж есть кстати, и ретро машинки, и паровозы, и парусники. Но 7 миллиардов людей можно найти любое извращение ;)
Боюсь Ауди и БМВ находятся за пределами зоны дейсьвия этого документа. Максимум импортера можно :)
А попытки идти дальше натолкнуться на претензии куда большего размера
Я думаю, более рабочей выглядит связка дизайнера и бизнес-аналитика со знанием домена, который не стесняются спросить мнение лида/архитекта
И единорогов на рынке искать не надо
А дизайнер с опытом и так знает достаточно, как работает в целом приложение технически, либо хотя бы может сказать "а в моем прошлом проекте оно так работало"
Согласен. Но ведь носителями инженерной культуры инженеры и являются :)
Культура это всего то, что поддерживается основными людьми в организации. И трудно себе предствить организацию, при которой культура сама по себе, а главный конструктор сам по себе
Плюс, никто ведь не запрещает конкретному спецу не делать фигню. Корпоративная культура - это сильно, но своя всегда сильнее для себя лично.
Понятно есть те, кто свою часть сделал хорошо. Но я лично могу этим в своей работе удовлетворитьмя, если точно уверен что "красавчик"
Тщательнее не значит дольше :(
Тут мозги и организацию труда в команде интенсивностью не заменишь
Поэтому инженеров и не жалко.
Ну, наверное что-то в этом есть, но
По примерам ... корабли, кареты ... все есть, просто нишевое. Банально для массмаркета никому не надо, но сомневаться в том, что под заказ любвя страна первого эшелона может построить паровоз несколько странно. Лошади как тяговое средство еще используются, достаточно к примеру покататься по Румынии. И опять же - все навыки есть. У меня дочка конным спортом занимается к примеру. С парусниками еще проще, дойти до любой марины и все ;) Парусников сколько угодно
Момент два. Дока на все точно сохранилась и явно не на мертвом языке. Т.е. для спецов там ничего потайного нет.
Большая часть вообще тупо не уникальна, тот же носитель с Земли до околоземной орбиты. Это вообще рутина
В целом "управляемые" полеты на орбите тоже рутина, вон сколько вокруг земли летает всего.
Связь ... ну тоже смешно. Советские люди смогли передать точка-тире на той элементной базе, не смочь сейчас ... да и явно эти блоки можно заменить на современные.
Как по мне, банальный кризис менеджмента. Прлсто для многих ИТ-шников ПМ это бесполезная тушка, которая ходит и "водит руками", но в реальности это основа всего на сложном проекте. Тут скорее всего полная .опа.
Основная проблема - это их ненужность.
В теории да, разгрузим дороги, улучшим жизнь ... как выглядит,можно посмотреть в фильме "5 элемент" например
Но в реале мне кажется проблема в том, что авто поток массовый, а леталки штучный. Ну реально, сколько в реале их надо, чтобы снять нагрузку с 2-3 полоски? Десятки тысяч? Многовато
Получается для них просто нет масслвой ниши, точнее они бесконечно далеки от массовости. А для избранных и сейчас есть куча вариантов. Частные вертолеты - без проблем. Лакшери авто и наемный водитель, чтобы паботать в пробках - изи.
В целом, разкм подсказывает при взгляде на проблему смотреть на техническое задание, и от него уже смотреть на то, что есть. Иначе не имеет смысла
Та ну, не смочь повторить достижения 50ти летней давности ... это клиника
Тем более, а что утеряно то?
А им то чего? Типа как проигравшим?
Работать нужно тшательнее :)
Общая компоновка может отличаться из-за других материалов в пользу увеличения чего-то полезного к примеру.
Скорее всего чуда нет, взяли что есть
Я дуолингво прохожу 2 по 15 в день и стараюсь смотреть интересующме меня темы на утубе на английском
Прогресс чувствую, на совещаниях лучше понимаю найтив спикеров
Блин, честно говоря, все уже придумано и расписано
К чему эти синтетические примеры - неясно
Человек берется в команду в идеале после собеседования, на котором проверяется наличие hard/soft скилов, а также обычно кандидата знакомят с проектом и задачами
Также очевидно, что если есть конкретные ожидания, например к решению есть требования по производительности, которые надо будет проверит, то они озвучиваются.
Но в рамках экспертизы QA ПМ не должет ставить детальные задачи. Как и другим ролям. Но может контролировать. К примеру, начинается большой проект. Есть до головы QA лида не дошла светлая мысль, которая заключаеться в необходимости начать работу над тестовой стратегией, то ПМ вполне может спросить, а почему лид все еще занимает положение "сижу на жопке" ровно? Ну и походу стоит попросить другого спеца посмотреть, чего лид туда написал и не написал. И найти экспертов которые помогут туда вписать все что нужно. Это нормально, еж птица гордая и инфантильная.
Но в целом, мне не очень понятно в чем суть. Человек с опытом ЗНАЕТ, что надо делать. Ему нужны детали/нюансы конкретного проекта, либо бебиситер в виде лида. Еслм лиду нужен бебиситер - то лиду точно пора на выход. Тут все просто.
Про то, что делает ПМ - да очень много чего, не только управленческие решения. Как минимум очевидно, что чтобы чего то принимать, надо убедится, что есть достаточно вводных.
А для этого, как раз нужна ориентация QA на фичи, а не на баги
Пример. Утренний ответ на стандартные вопрос от QA.
Закончил покрытие тестов к фиче 111, возьму покрытие фича 222 и протестирую фичу 333. Планирую сделать за день. Отлично
Написал 20 тест кейсов к фиче XYZ, нашел 5 багов в фиче ABC. Очень плохо :)
Задача ПМ в таком случае трансформировать инфу и фокус QA с нижнего варианта ответа на верхний :)
А чем в целом изначально я и талдычу :) Как и о практической бесполезности измерения работы, качественно и количественно багами
Я обычно работал в организациях, где либо есть стандартны качества, либо люди и так понимают зачем. Вариаент без QA - только когда есть маленькая команда и можно просто кросс чекать друг друга
Про поставить задачу. Взгляд с другой стороны :) Я ПМ, или частично вывполняю его функции. У меня есть QA, или даже команда. Я нанимаю кого-то с опытом 15 лет. Блин, какая постановка задачи ожидается?
Во-первых. На большом проекте может быть 5+ команд разработчиков, разномастный заказчик с 7 говорящими головами, 2+ спонсора, куча мерзких запрещалок, контракты с тремя поставщиками, 2 из которых из-за бугра. Куча доки, которую надо вести. 10 встреч каждый день, 100+ писем, и много-много другого. ПМ нанял в команду QA команду с лидом, чтобы тратить время на постановку задачи?
Реально на это физически нет времени. Для этого и берется лид, который не просит поставить задачу, а организует процесс тестирования. Да, именно так. Ожидается, что человек с опытом знает как построить свой процесс и ему нужен ПМ для решения орг. вопросов. Конечно, я лично еще не встречал QA, которые бы не просили помощи в технических вопросах, так где сложно, но это нормально. Точнее они есть, те кто могут сами, но стоят дорого, и сразу фиг дадут.
Поэтому, подытоживая. Да, спец с опытом знает, зачем он в проекте и ему надо только уточнить детали, как именно в будет тут. Бэби ситтингом никому заниматься не интересно, кроме удовлетворения преподавательского зуда.
По контроль - да, это пичалька. Если первый вопрос тестировщику на совеседовании "какой ваш added value", то вот ПМа стоит спросить в целом по каждой роли и "что вы выносите с утренних стенд-апов". Ответ на последний часто удручает :(
Но тогда есть надежда на то, что в команде будет сильный аналитик/архитектор/тимлид, которые тут подстрахуют
> все ПМ, которых я опрашивал, уверены, что тестировщик отвечает за качество продукта.
Ну, не совсем. QA подтверждает, что разработанный продукт соответствует требованиям к нему в рамках своих компетенций. QA не может сделать продукт качественнее. Он только указывает на дефекты. Поэтому формально формулировка неверна. Что при этом вкладывают эти ПМ в эти слоаа я догадаться не могу, сорян
А что до ситуации ... ну так если ПМ ни черта не делает, чуда тоже не произойдет. Да длинном проекте можно увидеть достаточно признаков заоанее, что есть проблемы и заняться их исправлением до того, как подкрадется песец.
Но основная мысль в том, что если QA ищет баги, это уже проблема :) QA, как и DEV - закрывает фичи, только по своему
Дело в том, что избранная мера в виде количества багов глубоко вторична по отношению к мере готовности приложения к проду в виде списка фич/требований.
Как следствие, ориентированность команды QA на поиск багов, а девов на их фикс в реальности приводит к расфокусировке от важных вещей
Команда должна быть сфокусирована на фичах и их готовности к проду. Тогда релизы будут иметь смысл, так как будут состоять из протестированных фич, которые наиболее важны.
Это как 10 стаканов. Я не успеваю наполнить все 10 объективно? ОК, я наполню 7 самых важных, а на 3 забью. Если я фокусируюсь на багах, я могу получить 3 полных, и 7 почти полных. И даже в первом случае может быть условно 5 критикалов и 25 медиум, а во втором 2 критикала, и 12 медиумов. Но первый релиз выглядит намного лучше второго
Поэтому QA НЕ ИЩЕТ БАГИ. Он проверяет ГОТОВНОСТЬ ФИЧ, начиная с самых важных. А если продолжает искать баги и не исправляется, значит идет за борт :)
Даже сейчас ты пишешь про задачу, которая не имеет смысла. В проде не выходит отсутствие багов. В прод выходят одобренные фичи. И именно количество фич - мерило успеха команды.
Отдельный вопрос, если фича задекларирована как готовая, а в пподе вылез баг. Это повод для ретроспективного анализа и работы над техниками, взаимодействием и т.д. Но если команда изначально ориентирована не туда - она уже неэффективна
Ну или еще. QA находит баги. Много, мало ... это хорошо или плохо? ХЗ. Ну реально. Может багов и правда мало, а может и много. Это не важно. Важно мерять работу QA по количеству фич, которые он либо одобрил к выходу в прод, либо протестил и выкатил список багов. Тогда легко понять продуктивность команды и все остальное. И легко проверить качество работы тестировщика. Если окажется, что в готовой фиче есть баги (которые нашел клиент) или в "протестированной" фиче нашлись новые баги без изменения кода - это повод устроить QA команде разбор полетов
Ну, я работал и чистым ПМом, но объективно это не моя основная специальность
Вообще, выше я написал. QA команда работает, покрывая тестами и собственно тестируя требования/фичи, в зависимости от релизной политики. На коротких релизах это фичи, на длинных - требования. Так они имеют цель и смвсл жизни в команде.
Периодически QA готовят отчет, где мы в части готовности к проду. Т.е. что и скоупа готово, а что нет. Что не готово, обязательно классифицируется по тяжести багов. Так все знают текущий статус, включая заказчика.
Оперативно, часто с помощью жопомера и иных потусторонних сил, оценивается, насколько много шансов успеть к дедлайну и пора ли "паниковать" (резать скоуп, добавлять ресурсы, менять приоритеты). Также, если идентифицированы проблемы (тикеты не закрываются, появляются новые, переоткрываются старые), надо собраться и устранить корень возникновения проблемы.
Иногда надо QA помочь, так как уровень их технических знаний обычно невелик и багальное "я сейчас расскажу, как можно автоматизировать это штуку" может сильно ускорить процесс
В целом ничего уникального. В проекте должна быть цель, путь и движение к цели по этому пути, которое измеримо. И ежедневное вджобывание :)
Про БОЛЬШОЙ проект ... хз, кому что большое. У меня самый большой это Интернет банкинг, где одновременно трудилось до 10 команд в разных точках решения. Но он принципиально не отличается. Подходы те же. Просто надо ж понимать, что если условно он еще больше, то на проекте желательно иметь больше одного ПМа. Т.е. ничего страшного нет в том, что на большом проекте и лбдей больше, в том числе "с погонами".
В статье основная проблема и возможно, корень ее в том, что тестирование идет от требований, а не от багов.
Из опыта кстати, именно командам QA приходится чаще всего вставлять пистоны и проводить лекции на тему, как стать лучше. Некоторые воспринимают и дело идет на лад, с некоторыми приходится расставаться, иногда после жесткой беседы, так как иные методы не сработали :(
Дополнительно. Про большой проект. Да по фиг. В роли ПМа я ожидаю получить от QA ответ по списку:
Это протестировано и готово
Это в работе, вот список багов
Это покрывается тестами
Это вообще ХЗ что, будем покрывать
Где взять этот список - это мой вопрос. Возьму аналитика за жабры и заставлю написать. Не важно. Список будет. Иначе НИКТО НЕ БУДЕТ ЗНАТЬ ГДЕ МЫ И ЧТО МЫ ДЕЛАЕМ.
Потому что любой проект/релиз - это конечная и описанная активность. Либо в виде требований, либо в виде бэклога. Не важно.
Еслм что-то не описано, как например "ковыряние овна мамонта", значит оно есть на столе именно в таком виде. Но тогда QA туда соваться еще рано
Но вот что точно будет, так это пендаль QA, который на проекте занимается "сврбодным" поиском багов.
Не нужно описывать требования. Нужно для начала иметь из список. Это есть всегда, сорян. Даже в виде сторек из Jira.
Дальше QA команда:
Пишет стратегию, как они это будут тестить. Виды тестирования, как именно тестить, тулы и т.д
Каждое требование покрывается тест кейсами, которые собираются в сценарии. Как именно - это вопрос QA команды
И идет работа
Главное, работа идет по списку требований. Они могут быть связаны, собраны в группы, релизы. Это уже детали. Но ... всем начиная с ПМа интересно статус работ по тестированию в разрезе требований. Если QA этого не может дать - он идет далеко и прямо.
А аот по этому списку уже можно работать. Например:
Срезать скоуп релиза, оставив только то, что ПРОТЕСТИРОВАНО
Обратить внимание на проблемнве требования
Увидеть влияние багов на другие требовантя по связке требований
Планировать работы, так как прогрес измерим и явно видет