Здравствуйте, VladCore, Вы писали:

VC>Здравствуйте, playnext, Вы писали:


P>>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос.

VC>Я сейчас крамолу напишу. На эффективность разработки бизнесу насрать. Безнес хочет рост продаж, отсутствие возвратов и положительные отзывы.
Продукт продается и дает больше всего прибыли по сравнению с остальными продуктами разрабатываемыми в компании. По отзывам я детали не знаю этим поддержка занимается но положительных больше.
Бизнесу в нашем случае интересно сократить кое где бюджет и иметь при этом качество не хуже текущего а в идеале лучше, это естественное желание. Продукт на рынке с 2002 года.
Исходя из пожеланий бизнеса вышестоящий менеджмент пытается улучшить качество и таким образом сократить циклы тестрирования. Это по их мнению позволить сэкономить бюджет.
QA работает исходя из критичности багов и их количества (но не в кеом случает не сложнности и скорости исправления их разработчиком). Чем больше заведено багов тем больше работы у тестеров тем больше ресурсов требуется. Отсюда требования снизить количество багов.
Но по ресурсам и квалификации у разработчиков ничего не меняется. Здесь бюджет остается тот же.
Поэтому предлагается по большей мере изменением процесса и давлением на разработчиков улучшить качество продукта. На рефакторинг времени отдельно не дается. Изменений в коде очень много на релиз и затрагивает почти все области.

VC>Вы вкурсе, что ненужный софт, который не продается, довольно часто может быть очень качественным?

P>>У нас например при количестве разработчиков 8, багов бывает от 100 до 400
У нас примерно также 10 разработчиков багов от 50 до 450 в среднем

VC>Я нехочу никого обидеть, но у вас либо мало опыта, либо бесполезная мотивация.
На счет опыта не знаю. Мотивация не меняется. Есть требование от менеджеров сделать качество продукта лучше. Бюджет как они говорят не позволяет добавлять ресурсы. Они в основном указывают на недостаки процесса в частности.
VC>Количество багов не зависит от кол-ва разработчиков. Количество багов зависит от:
VC>- Количества продаж/клиентов
VC>- Количества людей что отвечают клиентам на письма "йо совтфаре дазнт ворк проперли"
Это как я писал выше не знаю но знаю что количество клиентов растет.

Здравствуйте, playnext,

P> Есть требование от менеджеров сделать качество продукта лучше. Бюджет как они говорят не позволяет добавлять ресурсы.

Менеджеры могут выдать тебе некий цифровой критерий измерения этого самого качества, чтобы ты мог обоснованно утверждать, что "качество стало лучше" или "качество стало хуже"? Нет? Тогда прежде всего договорись с ними о таком измеримом критерии. Обоснуй тем, что "я не могу управлять тем, что я не могу измерить". И зафиксируй этот критерий письменно, в какой-нибудь там внутренней инструкции или регламенте. (А то, знаешь ли, менеджеры любят говорить сегодня одно, а завтра совсем другое. Типа "ты меня не так понял, я имел в виду другое" — в зависимости от того, чего просит очередной жирный клиент.)
Ну и имей в виду, что "качество" не может измениться одномгновенно, по приказу, — сегодня было плохо, а завтра все уже хорошо. Управление качеством — достаточно протяженный во времени процесс. Я бы считал целесообразным трекать изменения "качества" где-то за полгода-год.

Здравствуйте, Вячеслав Бенедичук, Вы писали:

ВБ>Здравствуйте, playnext, Вы писали:

P>>Хотелось бы оценить качество и эффективность разработки в связи с чем возник вопрос.
P>>Какое количество багов в среднем бывает (допустимо) на проекте?

ВБ>Качество это соответствие продукта потребностям клиента и оценивать качество нужно именно с этой точки зрения.
ВБ>Нет абсолютных величин количества дефектов определяющих качественный продукт или нет, так как вы как менеджер не можете менять качество продукта не повлияв на стоимость и сроки.
Тут предлагается прежде всего улучшить процесс. Есть также претензии что разработчики работают плохо, но я так не думаю. Ни стоимость ни сроки менять нет желания.
ВБ>Если ваш клиент считает, что то количество дефектов, которое он видит его устраивает, за ту цену, которую он тратит на разработку и продукт он получает вовремя, значит продукт качественный. Если не устраивает, значит у вас есть в этой области проблемы.
Хотят сделать получше, в целом устраивает.
ВБ>Если нужны абсолютные цифры — обсудите с клиентом, какие последствия для его бизнеса несут разные классы дефектов в различных частях функционала и зафиксируйте это в SLA.
Мы обсуждаем с вышестоящим менеджементом а они уже по Бизнесом.
ВБ>При фиксации оцените, сколько будет стоить достижение требуемого качества и включите это в стоимость разработки.
У нас бюджет плохо изменяется в строну увеличения. Сроки немного могут но тоже сложно просить.
Анализ у нас есть на кждый релиз.

Здравствуйте, playnext, Вы писали:

P>Исходя из пожеланий бизнеса вышестоящий менеджмент пытается улучшить качество и таким образом сократить циклы тестрирования. Это по их мнению позволить сэкономить бюджет.
P>QA работает исходя из критичности багов и их количества (но не в кеом случает не сложнности и скорости исправления их разработчиком). Чем больше заведено багов тем больше работы у тестеров тем больше ресурсов требуется. Отсюда требования снизить количество багов.

Т.е. основная проблема, которая у вас есть это "высокие" трудозатраты или стоимость тестирования?
Если я правильно понял, тогда подумайте над организацией этого процесса. Возможно вам поможет внедрение автоматических тестов например с помощью silenium. Ну и в целом стоит посмотреть на эту часть процесса.
Так же введите разбор дефектов. Дефекты должны классифицироваться, на каком этапе они возникли, что явилось корневой причиной. дальше смотрите, по каким причинам у вас возникло наибольшее число дефектов и работаете с их устранением.