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: |

Among the requests, the Brazilian electoral Court wanted to know if they could obtain data on the origins of malicious content posted on the platform. According to the TSE, this would enable the authorities to track false content and identify the user responsible for publishing it in the first place. Hui said the time period and nature of some offences “overlapped” and thus their prison terms could be served concurrently. The judge ordered Ng to be jailed for a total of six years and six months. Deputy District Judge Peter Hui sentenced computer technician Ng Man-ho on Thursday, a month after the 27-year-old, who ran a Telegram group called SUCK Channel, was found guilty of seven charges of conspiring to incite others to commit illegal acts during the 2019 extradition bill protests and subsequent months. The initiatives announced by Perekopsky include monitoring the content in groups. According to the executive, posts identified as lacking context or as containing false information will be flagged as a potential source of disinformation. The content is then forwarded to Telegram's fact-checking channels for analysis and subsequent publication of verified information. Telegram is a leading cloud-based instant messages platform. It became popular in recent years for its privacy, speed, voice and video quality, and other unmatched features over its main competitor Whatsapp.
from us


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