TARMOLOV_WORK Telegram 217
На вопрос "А у вас сервис — качественный?" можно получить совершенно разные ответы:
- от разработчиков можно услышать: "ничего критичного нет, остались минорчики";
- тестировщик возразит, что "у нас куча багов, которые не пофикшены с прошлого релиза";
- менеджер пожмет плечами: "основное работает, нам нужно новые фичи зарелизить".

Налицо "конфликт" субъективных мнений. Нетривиально понять, сколько времени нужно тратить на фиксы багов, а сколько — на дальнейшее развитие сервисов.

На помощь приходит метрика Zero Bug Policy (ZBP) с очень простой идеей:
1. Каждому открытому багу выставляется вес согласно критериям.
2. Подсчитывается сумма всех весов.
3. Каждый день значение пересчитывается, и рисуется график суммы багов сервиса.
4. На графике проводится горизонтальная линия "максимальной забагованности", которую нельзя пересекать.

Если график ZBP превысил допустимый уровень забагованности, то выделяется больше времени на фикс багов. Если график ZBP в пределах нормы, то можно спокойно пилить фичи.

В простейшем случае в качестве критериев для выставления весов может использоваться приоритет багов:
- низкий — 1
- средний — 10
- критичный — 100
- блокер — 1000

Но лучше для разметки весов использовать более бизнес-ориентированные компоненты: важность юзкейса, процент затрагиваемых пользователей, "дыры" в безопасности, влияние на деньги и т.д.

А приоритет бага выставлять уже в зависимости от накопленного веса. Тогда будет меньше споров, почему один баг — минорный, а другой — критичный.

Невозможно найти все баги, и часть из них проскакивает наружу. Поэтому мы дополнительно считаем процент багов, найденных коллегами. Стремимся, чтобы этот процент был минимален :)

И отдельно, конечно, читаем фидбек и жалобы наших пользователей. У нашей команды саппорта также есть ряд метрик по скорости первого ответа, скорости решения проблем пользователей и т.д.

DORA советует:
- внимательно относиться к фидбеку пользователей
- подключать службу безопасности на ранних этапах

#разработка
🔥23👍6❤‍🔥1👏1



tgoop.com/tarmolov_work/217
Create:
Last Update:

На вопрос "А у вас сервис — качественный?" можно получить совершенно разные ответы:
- от разработчиков можно услышать: "ничего критичного нет, остались минорчики";
- тестировщик возразит, что "у нас куча багов, которые не пофикшены с прошлого релиза";
- менеджер пожмет плечами: "основное работает, нам нужно новые фичи зарелизить".

Налицо "конфликт" субъективных мнений. Нетривиально понять, сколько времени нужно тратить на фиксы багов, а сколько — на дальнейшее развитие сервисов.

На помощь приходит метрика Zero Bug Policy (ZBP) с очень простой идеей:
1. Каждому открытому багу выставляется вес согласно критериям.
2. Подсчитывается сумма всех весов.
3. Каждый день значение пересчитывается, и рисуется график суммы багов сервиса.
4. На графике проводится горизонтальная линия "максимальной забагованности", которую нельзя пересекать.

Если график ZBP превысил допустимый уровень забагованности, то выделяется больше времени на фикс багов. Если график ZBP в пределах нормы, то можно спокойно пилить фичи.

В простейшем случае в качестве критериев для выставления весов может использоваться приоритет багов:
- низкий — 1
- средний — 10
- критичный — 100
- блокер — 1000

Но лучше для разметки весов использовать более бизнес-ориентированные компоненты: важность юзкейса, процент затрагиваемых пользователей, "дыры" в безопасности, влияние на деньги и т.д.

А приоритет бага выставлять уже в зависимости от накопленного веса. Тогда будет меньше споров, почему один баг — минорный, а другой — критичный.

Невозможно найти все баги, и часть из них проскакивает наружу. Поэтому мы дополнительно считаем процент багов, найденных коллегами. Стремимся, чтобы этот процент был минимален :)

И отдельно, конечно, читаем фидбек и жалобы наших пользователей. У нашей команды саппорта также есть ряд метрик по скорости первого ответа, скорости решения проблем пользователей и т.д.

DORA советует:
- внимательно относиться к фидбеку пользователей
- подключать службу безопасности на ранних этапах

#разработка

BY Тармолов про работу


Share with your friend now:
tgoop.com/tarmolov_work/217

View MORE
Open in Telegram


Telegram News

Date: |

Commenting about the court's concerns about the spread of false information related to the elections, Minister Fachin noted Brazil is "facing circumstances that could put Brazil's democracy at risk." During the meeting, the information technology secretary at the TSE, Julio Valente, put forward a list of requests the court believes will disinformation. Activate up to 20 bots How to create a business channel on Telegram? (Tutorial) So far, more than a dozen different members have contributed to the group, posting voice notes of themselves screaming, yelling, groaning, and wailing in various pitches and rhythms. Hui said the messages, which included urging the disruption of airport operations, were attempts to incite followers to make use of poisonous, corrosive or flammable substances to vandalize police vehicles, and also called on others to make weapons to harm police.
from us


Telegram Тармолов про работу
FROM American