«Зачастую правообладатели или менеджеры утверждают, что автоматизацию тестирования следует полностью игнорировать, перенаправив 100% усилий по тестированию будущих спринтов на ручную регрессию»
У нас сейчас обратная проблема: правообладатель заявил, что раз каждый микросервис покрыт внутри юнит тестами, то ручное тестирование не нужно: ведь все покрыто же, зачем вам тестировщик?
У вас шикарная идея здесь о том что «Автоматизация проверяет то, что уже было протестировано. А ручное тестирование находит то, что не было вообще протестировано»
Если бы все играли по этим правилам — было бы всё понятно.
Но в реальности есть персонажи, которые играют по немного другим правилам.
Например, правило «сходить и отобрать бизнес у другого персонажа».
Или «найти доверчивого персонажа, обманным путём получить у него каких-нибудь ресурсов».
Или правило «психологической уловкой <истерика и слёзы> получить шубу» :))
Есть персонажи-манипуляторы, персонажи с большим количеством власти и с меньшим, с большим количеством информации и с меньшим. Персонажи-технари и персонажи-гуманитарии. Персонажи-совы и жаворонки. Интроверты и экстраверты. Есть вообще нелогичные персонажи, с которыми неизвестно как выстраивать взаимодействие.
Да, я тоже так подумала — вырванные отрывки не дают полного понимания, поэтому воспринимаются в штыки. Но я не знаю как детальнее описать. Детальнее — в книгах и выступлениях Dan Ariely )
5) Снижение ценности в отдаленной перспективе и страх риска
Вам выдать 10 долларов сейчас, или 20 в следующем году? Рациональное поведение — взять 20 в следующем году, т.к. 100% годовых это хорошее предложение, и люди понимающие в финансах взяли бы 20, 200, 2000 в следующем году, вместо 10, 100, 1000 в этом. Но среднестатистический человек больше ценит «сейчас» и ещё избегает риска — поэтому возьмёт сейчас. Среднестатистический человек всю жизнь ходит на работу, вместо того чтобы попробовать заняться бизнесом, и (возможно) в будущем зарабатывать больше (страх риска + сейчас лучше чем завтра)
3) О результатах труда
Чистый эксперимент — это когда все параметры, кроме исследуемых, зафиксированы. То есть, условия труда одни и те же, зарплата одна и та же, люди одни и те же — но в одном случае результаты труда разрушаются и человек об этом знает, во втором случае — не разрушаются. Первая группа людей раньше теряет мотивацию работать.
2) О том, во что мы вкладываем силы
Детальные исследования здесь en.wikipedia.org/wiki/IKEA_effect и этот эффект имеет ещё такой вариант: бывает, что менеджеры или предприниматели продолжают заниматься убыточным проектом, просто потому что жаль бросить то, во что вложены свои силы. Если вам кто-то предложит убыточный проект — вы откажетесь. Но если это убыточный проект в который вы вложили свои силы — вы отказываетесь не так легко… (проблема известна как Sunk Cost Dilemma)
Для 1) у меня нет данных об исследованиях, но у автора того курса — Dan Ariely — должны быть.
Я не могу в маленьком комментарии описать полностью функции и обязанности бизнес-аналитика, но я не далее как 2 месяца назад закончила вот этот курс ba-space.org/2013/11/15/kurs-osnovy-biznes-analiza-ot-kateriny-makarenko-nabor-3/ — посмотрите в таблицу «содержание курса» — в ней описано, чему учат бизнес-аналитиков. В посте я вижу, что от «проектировщика» хотят именно это — общаться с заказчиком, создавать структуру проекта, делать прототип в виде мокапов, обладать знаниями в бизнес-области заказчика, и знать суть процессов разработки.
Полноценный прототип аналитик не создаст, так как он не программист. Но делать мокапы входит в его обязанности — чтобы согласовывать их с заказчиком и добавлять их в документацию, чтобы по ним велась разработка.
Я в целом к тому, что в больших проектах для того, что вы хотите — есть отдельный человек, называется он бизнес-аналитик или системный аналитик, это совершенно отдельный человек, с отдельным набором знаний и умений — он не менеджер проектов и не программист. Это отдельная область знаний )
Курсы по этому есть, книги тоже. Просто, эта должность не очень распространена в маленьких ИТ компаниях, и функции бизнес-аналитика выполняют менеджеры проектов и программисты (у которых нет всех знаний и навыков нужных для BA). Вот например нашла описание на русском системного анализа — это часть бизнес-анализа — функции у системного (и бизнес) аналитика те, что вы описали.
То, что вы описали — это функции бизнес-аналитика (именно так называется эта должность, есть свод знаний по бизнес-анализу — BABOK).
Аналитик на проекте:
— хорошо общается с клиентом
— выясняет функциональные ( и нефункциональные) требования
— создаёт структуру разделов будущего проекта (и документацию вообще)
— разбирается в предметной области заказчика
— обладает набором знаний по психологии
— осведомлён об этапах разработки, способен оценивать их
— рисует мокапы, диаграммы последовательностей, прецедентов,
— анализирует требования на полноту, непротиворечивость и т.п.
— управляет требованиями и изменениями в них на протяжении всего проекта
— общается с ПМ, архитектором, тестировщиками, разработчиками
У нас сейчас обратная проблема: правообладатель заявил, что раз каждый микросервис покрыт внутри юнит тестами, то ручное тестирование не нужно: ведь все покрыто же, зачем вам тестировщик?
У вас шикарная идея здесь о том что «Автоматизация проверяет то, что уже было протестировано. А ручное тестирование находит то, что не было вообще протестировано»
Но в реальности есть персонажи, которые играют по немного другим правилам.
Например, правило «сходить и отобрать бизнес у другого персонажа».
Или «найти доверчивого персонажа, обманным путём получить у него каких-нибудь ресурсов».
Или правило «психологической уловкой <истерика и слёзы> получить шубу» :))
Есть персонажи-манипуляторы, персонажи с большим количеством власти и с меньшим, с большим количеством информации и с меньшим. Персонажи-технари и персонажи-гуманитарии. Персонажи-совы и жаворонки. Интроверты и экстраверты. Есть вообще нелогичные персонажи, с которыми неизвестно как выстраивать взаимодействие.
Вам выдать 10 долларов сейчас, или 20 в следующем году? Рациональное поведение — взять 20 в следующем году, т.к. 100% годовых это хорошее предложение, и люди понимающие в финансах взяли бы 20, 200, 2000 в следующем году, вместо 10, 100, 1000 в этом. Но среднестатистический человек больше ценит «сейчас» и ещё избегает риска — поэтому возьмёт сейчас. Среднестатистический человек всю жизнь ходит на работу, вместо того чтобы попробовать заняться бизнесом, и (возможно) в будущем зарабатывать больше (страх риска + сейчас лучше чем завтра)
3) О результатах труда
Чистый эксперимент — это когда все параметры, кроме исследуемых, зафиксированы. То есть, условия труда одни и те же, зарплата одна и та же, люди одни и те же — но в одном случае результаты труда разрушаются и человек об этом знает, во втором случае — не разрушаются. Первая группа людей раньше теряет мотивацию работать.
2) О том, во что мы вкладываем силы
Детальные исследования здесь en.wikipedia.org/wiki/IKEA_effect и этот эффект имеет ещё такой вариант: бывает, что менеджеры или предприниматели продолжают заниматься убыточным проектом, просто потому что жаль бросить то, во что вложены свои силы. Если вам кто-то предложит убыточный проект — вы откажетесь. Но если это убыточный проект в который вы вложили свои силы — вы отказываетесь не так легко… (проблема известна как Sunk Cost Dilemma)
Для 1) у меня нет данных об исследованиях, но у автора того курса — Dan Ariely — должны быть.
Я в целом к тому, что в больших проектах для того, что вы хотите — есть отдельный человек, называется он бизнес-аналитик или системный аналитик, это совершенно отдельный человек, с отдельным набором знаний и умений — он не менеджер проектов и не программист. Это отдельная область знаний )
Аналитик на проекте:
— хорошо общается с клиентом
— выясняет функциональные ( и нефункциональные) требования
— создаёт структуру разделов будущего проекта (и документацию вообще)
— разбирается в предметной области заказчика
— обладает набором знаний по психологии
— осведомлён об этапах разработки, способен оценивать их
— рисует мокапы, диаграммы последовательностей, прецедентов,
— анализирует требования на полноту, непротиворечивость и т.п.
— управляет требованиями и изменениями в них на протяжении всего проекта
— общается с ПМ, архитектором, тестировщиками, разработчиками