решение проблем пользователя требует какого-то качества, вот это «минимальное качество» и есть то, что нужно от продукта в разном случае – разное требуемое качество и тестировщики отсюда следуют

качество обеспечивают тестировщики, в т. ч

всмысле можно создать какого то монстра которым будет адски неудобно пользоваться но все тест кейсы оно проходит

К сожалению, Тестировщики только проверяют Качество (QC) но не обеспечивают. Чтобы обеспечивать им нужно быть инженерами по Обеспечению Качества (QA) и влиять на сам процесс разработки продукта а не только контролировать результат.

К сожалению, Тестировщики только проверяют Качество (QC) но не обеспечивают. Чтобы обеспечивать им нужно быть инженерами по Обеспечению Качества (QA) и влиять на сам процесс разработки продукта а не только контролировать результат.

value - ценность для Клиента

нет, пожалуй я погорячился. хреновое определение

я не уверен, про QC или QA говорилось в том контексте. Но QC в масштабе -- это продолжение QA, нет?

что лучше -- идеальное решение проблемы близкой пользователю, но не совсем его, или сносное решение проблемы пользователя как есть?

Давайте ваше

если я дам то я спалюсь по полной

Если вы продукт делаете и хотите заработать на этом - то вам решать

Курите там чтоли?

от ответа на мой вопрос будет зависеть то, чем у вас будут заниматься QA

но мне лень поэтому я хотел бы заставить кого то из вас под него косить

только то что тот кто её отрицает должен обьяснить что имеется ввиду когда разработчик его вносит

про какой ?

так не моя же

Вы чё-то в какую-то фигню скатываетесь

У меня? С моими разрабами я и сам знаю что делать. Давайте лучше про ваших. Вы же с вопросом пришли

а если речь про субьективное велью для клиента то это может быть что угодно и зависит от умения продавать

У вас продуктовая или сервисная компания? Тот доклад был от C-level из продуктовой компании (средне-крупный финтех).

ну если ставить критерий что веью субьективно то разраб не может быть разрабом если он не продажник

C-level executive, а не компания

Взгляд руководителя разработки вполне закономерно будет отличаться от взгляда руководителя верхнего уровня.

Это все разрабы

Есть хорошее слово, которое начали забывать: Инженер. И команда строится из инженеров. Инженера придумывают изделия из типовых приемов. Иногда, конечно, нужна наука, но в основном это типовые приемы, нужно толко правильно соединить. Задача правильного процесса сделать так чтобы был заводик, который трансформирует Мысль (Идею) в Программу которой не требуется обслуживание, например как чайник. А важно чтобы этот заводик штамповал изделия (Продукты) с постоянной скоростью и не ломался. Если какого-то инженера собъет автобус, то заводик не должен останавливаться. Нужно просто заменить сбитого, на новую деталь , подожать пока шестеренки притрутся и прододжить штамповать Продукты. Поэтому "Люди конечно выше процессов", но на самом деле правильный процесс делает из людей заменяемые винтики. Pair Programming - чтобы быстрее притерлись и новый винтик (инженер) вышел на расчетную можщность быстрее Wiki it - hot plug для инженеров, чтобы винтики заменить можно было в любой момент. QA/QC - это техники наладчики и служба контроля, из задача чтобы на выходе заводика не выходил брак, а то снижается производительность. На Если что-то поймал контроль значит пора выходить и смазывать шестеренки и калибровать процессы на нашем заводике. Аналитики - это заводик по предобработке сырья, чтобы основной заводик производил без остановки. он создает буфер беред основным ограничением. (см ТОС) Спринты, летучки - это РИТМ - это ритуал обслуживания и синхронизация нашего завода по производству продукта. Он должен быть регулярный иначе сломается и не будет ничего производить. Нет синхро-импульса - ничего не работает. и продукт начинает выходить бракованным. ...А то Agile это круто, Agile это свобода! Agile это самомотивация!..

Есть хорошее слово, которое начали забывать: Инженер. И команда строится из инженеров. Инженера придумывают изделия из типовых приемов. Иногда, конечно, нужна наука, но в основном это типовые приемы, нужно толко правильно соединить. Задача правильного процесса сделать так чтобы был заводик, который трансформирует Мысль (Идею) в Программу которой не требуется обслуживание, например как чайник. А важно чтобы этот заводик штамповал изделия (Продукты) с постоянной скоростью и не ломался. Если какого-то инженера собъет автобус, то заводик не должен останавливаться. Нужно просто заменить сбитого, на новую деталь , подожать пока шестеренки притрутся и прододжить штамповать Продукты. Поэтому "Люди конечно выше процессов", но на самом деле правильный процесс делает из людей заменяемые винтики. Pair Programming - чтобы быстрее притерлись и новый винтик (инженер) вышел на расчетную можщность быстрее Wiki it - hot plug для инженеров, чтобы винтики заменить можно было в любой момент. QA/QC - это техники наладчики и служба контроля, из задача чтобы на выходе заводика не выходил брак, а то снижается производительность. На Если что-то поймал контроль значит пора выходить и смазывать шестеренки и калибровать процессы на нашем заводике. Аналитики - это заводик по предобработке сырья, чтобы основной заводик производил без остановки. он создает буфер беред основным ограничением. (см ТОС) Спринты, летучки - это РИТМ - это ритуал обслуживания и синхронизация нашего завода по производству продукта. Он должен быть регулярный иначе сломается и не будет ничего производить. Нет синхро-импульса - ничего не работает. и продукт начинает выходить бракованным. ...А то Agile это круто, Agile это свобода! Agile это самомотивация!..

Алексей, зачем аналитики, если своими словами?

> Аналитики - это заводик по предобработке сырья, чтобы основной заводик производил без остановки. он создает буфер беред основным ограничением. (см ТОС) В том случае ограничением, по их словам, были именно аналитики :-) Не знаю, наложило ли это отпечаток на их идеи

Ограничением может быть любой участок нашего заводика по производству Продукта, а разный момент времени разный, важно его зафиксирвоать, и регулировать пропускную способность. (принципы Lean)

Да, видимо им было удобнее зафиксировать пропускную способность аналитиков. Возможно, потому что ее (как и пропускную способность QA) сложнее сделать эластичной?

И конвейер у вас странный какой то