Re[25]: Про мягкие навыки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 14.11.20 10:43
Оценка:
Здравствуйте, SkyDance, Вы писали:

I>>Что бы дать гарантию, что сервис ничего нигде не теряет, замерить ресурсы, посмотреть насколько он хлопотен в обслуживании и сопровождении — для этого нужен четко выстроеный процесс. Гарантия сама себя не даст


SD>А вот это, кстати, распространенное заблуждение. Прошлое не определяет будущее.


Давай проверим твою формулу. Ленин умер в прошлом. Следовательно, ни в каком будущем него не будет существовать и новых революций он больше не сорганизует. Очевидно, противоречие с твоим заявлением.

>И если в прошлом сервис доставлял проблемы, это не значит, что он будет доставлять их в будущем.


Наоборот, именно это и значит. Если ты не устранил проблем, они будут воспроизводиться снова и снова.

>И, напротив, сервис, который "просто работал" несколько лет, может "просто перестать работать" завтра, и починить его будет невозможно.


Похоже, система контроля качества для тебя какое то чудо
Никто, ни в одной области, не может гарантировать ни отсутствие новых проблем, ни, тем более, отсутствие любых проблем. Вся система контроля качества совсем про другое — про степень соответствия требованиям.
Вместо 1 "нет проблем" имеем 2 "не более X сбоев при нагрузе уровня Y за время Z"
Очевидно, что первое проверить невозможно, и дать геранти тоже невозможно, а вот проверить второе очень даже возможно и это делается испытаниями по конкретной методологии, а следовательно гарантии вполне себе возможны.

Процесс строится таким образом, что бы
1 выявлять как можно больше проблем на ранних этапах
2 устранять проблемы
3 иметь подход, которых позволять экономически выгодное устранение новых проблем в ходе эксплуатации.

Как следствие, ты уверен в качестве своего продукта и заявляешь, вещи вида "устраним новые проблемы за время Х или вернем деньги(заплатим пенальти и тд)"
Соответсвенно, если твой процесс хилый, у тебя издержки превысят заработок. А если всё хорошо, ты сможешь получать прибыль.

А все это на основании того, что
1 у тебя годные испытания и ты видишь, что проблемы случаются раз в год.
2 архитектура, качество реализации адекватные
3 команда адекватная
4 итд, уже описывал в другом сообщении в этом треде

Тем не менее, гипотетически может случиться неизвестная проблема которую не удастся решить экономически выгодными методами
тогда
1. есть страхование рисков
2. ограничивается сфера применения, например — железо, конфигурация и тд и тд, жостко описываются граничные случаи
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.