По мере того так я читал пост, мое раздражение переходило в истинное негодование. В посте (он небольшого объема и хорошо написан, стоит того, чтобы прочесть) Купач утверждает, что баги и долгие сроки – это, на самом деле, нормально. По ее опыту, большинство компаний могут себе позволить выдавать продукт с недочетами и в неспешном темпе. Влияние багов на бизнес не слишком велико, и скорость, с которой они исправляются, большого значения не имеет. Да и то, что разработчикам портит жизнь непрерывный поток срочных багфиксов – не беда.
Несложно догадаться, почему идеи Купач вызвали у меня, поддерживающего благородные принципы вроде разработки через тестирование и магистральной разработки, такое возмущение. Они ведь напрямую противоречат всем моим убеждения!
Но больше всего в ее посте меня разозлило вот что: она была права.
Купач говорит, что пришла к своим выводам, основываясь на личном опыте. Это подтолкнуло меня к размышлениям над собственным опытом, который сложился за пятнадцать лет работы в сфере разработки ПО.
Мне доводилось видеть (и писать) код ужасного качества – так чтобы всё прямо совсем плохо, и с тестами по большей части по нулям. Такое случалось почти на каждом месте работы. Я видел, как на дописывание тестов или исправление багов затрачивалась целая куча времени. Но знаете, чего я не видел ни разу за эти пятнадцать лет? Чтобы компания разорилась.
Затратное и бесполезное переписывание кода, после того как неизбежно объявлялось техническое банкротство – это да. Выгорание разработчиков, которых регулярно принуждают день и ночь работать над устранением багов – тоже было. Суетливые утешения, объяснения и, да, временами откровенное вранье клиентам от коллег из продуктовых команд, когда обновление функциональности запаздывает – и это видел. Но ничего из этого не привело к тому, чтобы компания ушла с рынка.
А всё почему? Думаю, ответ кроется в неприятной истине.
Программное обеспечение не решает судьбу организации.
Даже если это техническая организация.
У программных продуктов есть разные пути к выживанию, и многие из них никак не завязаны на качество:
- Некоторые продукты создаются для внутренних потребителей, которые оказываются в положении клиентов-заложников. Они вынуждены проглатывать любую лажу, какую мы, разработчики, им предложим.
- Бывает, что внешние потребители так привязаны к определенному поставщику, что тоже недалеко ушли от положения заложников. Причиной тому могут быть условия контрактов, или глубокая интеграция продукта в клиентскую систему, или откровенная коррупция.
- Конкуренты могут быть ничем не лучше и страдать от тех же самых багов и проблем со скоростью.
- Сильные команды на продажах и обслуживании клиентов могут компенсировать недочеты в функциональности.
Плюс множество других факторов, никак не связанных с разработкой.
Когда я осознал правдивость аргументов Купач, то понял, что стал жертвой догматического мышления. Я был так убежден, что «высокое качество» (что бы это ни значило) – путь к успеху, что закрывал глаза на стоящие передо мной факты. Подобно овце из романа Оруэлла, я знай себе блеял: «Высокое качество – хорошо! Низкое качество – плохо!», не подвергая эти постулаты сомнению.
Это я не к тому, что теперь переключился на «Высокое качество – хорошо! Низкое качество – еще лучше!» Как отметили многие комментаторы под постом Купач, высокое качество пусть и не является обязательным условием успеха, но повышает шансы его достигнуть. Даже если мы считаем баги и сильные задержки приемлемыми, отсутствие багов и быстрые релизы составляют конкурентное преимущество.
Теперь у меня сложилось более тонкое понимание роли качества в технической компании. Хорошо, если вы поддерживаете его на высоком уровне, но свет на нем клином не сошелся. Иногда решение той или иной организации не вкладываться в качество бывает оправданным. Это не делает людей по умолчанию неправыми.
До сих пор я всегда исходил из того, что любая организация должна стремиться выдавать продукт на высоком уровне. А если пока не получается, то сам собой разумеется, что они идут к этой цели. Такой взгляд на вещи часто приводил к разочарованиям, когда я осознавал, что та или компания не разделяет моего убеждения.
Новый угол зрения в корне изменит моё восприятие технических компаний и, в первую очередь, поможет оценивать, какие из них хорошо вписываются в мои предпочтения касательно качества продукта (а это именно предпочтения, а не закон), а какие – хуже. Так что спасибо Валентине за пост, который заставляет задуматься. Он приятно меня выбесил.
Комментарии (19)
vagon333
13.07.2023 12:18-2Не берусь судить баги и релизы, но хотел был обратить внимание на уровень нетерпимости.
На Хабре норм делиться IT опытом и мнениями.
"Разозлил, раздражение, выбесил", эти конфликтные слова сразу обращают внимание при беглом просмотре, и путь просветления автора (статья переводная) уже кажется не таким важным и позитивным.
Tiriet
13.07.2023 12:18+6А меня вот раздражает и подбешивает апелляция к "конфликтным словам"- я считаю такие апелляции гнусными и подлыми- автор- живой человек, и он испытывает эмоции (как и я), как нормальный человек- он испытывает разные эмоции, и гнев и раздражение- тоже. А как взрослый человек он учитывает влияние своих эмоций на свои выводы и объясняет читателю- что выводы его имеют не только логическую подоплеку, но и эмоциональную. И я его вполне понимаю. Но тут вдруг появляется снежинка, и начинает ставить акценты- а вот автор заюзал хейтспичь, а вот автор использовал токсичные выражения, а вот он тут "конфликтные слова" написал. Дружище, это не у автора "нетерпимость", это у тебя ЧСВ завышенное и нестабильная психика, раз тебе вместо обсуждения идей с учетом эмоций хочется обсуждать эмоции без учета идей. И что характерно- именно люди, трепетно относящиеся к "конфликтным словам" демонстрируют наиболее высокий уровень деятельной нетерпимости :-).
vagon333
13.07.2023 12:18-5Но тут вдруг появляется снежинка ...
Не зная человека осторожнее с выражениями. В личке можно огрести.
Кто меня знают - подтвердят.Дружище, это не у автора "нетерпимость", это у тебя ЧСВ завышенное и нестабильная психика ...
Оставьте панибратство. Мы не друзья.
Держите уважительную дистанцию, пока взаимно не решили перейти на 'ты', в чем я сомневаюсь.... именно люди, трепетно относящиеся к "конфликтным словам" демонстрируют наиболее высокий уровень деятельной нетерпимости :-).
За всех не скажу, но на Хабре никому никогда ни одного минуса, и считаю это правильным для себя.
А слова, да, конфликтные.Tiriet
13.07.2023 12:18+5В личке можно огрести.
В личке можно сделать, простите, что? Огрести? Василий, Вы серьезно? Вы воспользуетесь такими непечатными словами, от которых я расстроюсь и растаю?
Оставьте панибратство
это не панибратство, это пренебрежение. Понимаете, Вы предлагаете мне держать с Вами уважительную дистанцию после того, как продемонстрировали мне недостойность Вашей точки зрения. Я понимаю, что это мое личное восприятие, но я Выше изложил Вам причины такого моего восприятия- Вы обсуждение нормальной статьи со вполне себе понятной идей и с вполне себе эмоционально взрослым анализом материала предложили перевести в русло анализа степени конфликтности использованных слов. это -2 к харизме.
CrazyOpossum
13.07.2023 12:18+8За всех не скажу, но на Хабре никому никогда ни одного минуса, и считаю это правильным для себя.
Задумался, почему я тоже никому минусы не ставлю. А потом догадался - так это потому что кармы не хватает!
Ivan22
13.07.2023 12:18+1Если заменить слова "ПО" - на "дороги", а "баги" на "ямы" в принципе все становится понятно....
Revertis
13.07.2023 12:18+1Если посмотреть на качество ПО вокруг, то похоже, что все это уже осознали, и клепают бажное ПО постоянно.
hoack
13.07.2023 12:18+3Ох уж мне эти эксперты... Прочитал статью, на которую автор ссылается, посмотрел немного про автора... Мне любопытно, откуда она взяла эти самые мистические числа "95%" и "5%"? В статье написано, что она взяла их из "личного опыта". Учитывая, что личного опыта у нее не так уж и много - менее десяти лет разработки в пяти компаниях - я бы не придавал этим обобщениям так уж много значения. Спектр типов компаний, в которых так или иначе идет разработка софта, невероятно широк, и у них ну очень разные требования как к качеству, так и к скорости разработки (кстати, мне совершенно не ясно, почему она валит в одну кучу большое количество багов и медленные релизы?).
CrazyOpossum
13.07.2023 12:18Цифры надуманные, но факт остаётся. Да, допустим, я тоже недостаточно повидал в четырёх компаниях, но субъективно, положа руку на сердце, вы можете сказать что среднее качество (стабильность, производительность) приложений, игр, сайтов, каких-то бизнес вещей выросло за последние 10-20 лет? Я не говорю про фундаментальные вещи типа баз данных или операционных систем, я говорю именно про массовые продукты.
ginkage
13.07.2023 12:18+1Дык, согласно статистике, 73.6% всех статистических фактов являются вымышленными.
Ndochp
13.07.2023 12:18Не, на самом деле конечно не 5%, а меньше. Просто вместо "абсолютное большинство" написала 95%.
domix32
13.07.2023 12:18Циферка обычно обозначает, что это статистически достоверное утверждение. Строится естественно на эмпирически. Находится рядом с законом Мёрфи и Парето.
Arhammon
13.07.2023 12:18Тут вообще в экономику надо копать. Хорошей иллюстрацией будет древнее исследование - рынок «лимонов». В оригинале исследование про БУ авто - где основная идея, что у покупателя нет возможности гарантировано купить машину без дефектов, и продавцу получить за идеальный товар адекватную цену сложно и в итоге рыночная цена падает до той цены, где покупатель готов мириться с возможными дефектами.
dlc
13.07.2023 12:18Выводы какие-то однобокие. Высокое качество всё так же хорошо, а низкое качество - всё так же плохо, ничего не изменилось.
Просто ТС внезапно узнал, что понятие "качество" разнится как между профессиями внутри организации (разработчики, менеджмент, С-level), так и между работниками организации в целом и их клиентами.
Клиенту может быть абсолютно начхать, обрабатывается запрос на поиск в 50мс или в 1 секунду, а вот разработчики могут из кожи вон вылезти ради оптимизации этого места. А надоумить на это их может менеджер продукта, который посмотрел вчера на конкурента "а у него там всё быстро, вжух!".
С точки зрения организации, команда предоставила функционал высокого качества. С точки зрения клиента ничего не изменилось. И вообще ему цвет кнопки поиска не нравится, поэтому он уход теперь к конкуренту.
P.S. Все примеры утрированы.
SpiderEkb
Везде ли это так?
Где-то - да. Ну клепаешь ты сайт для ООО "Сукин и Сын", ну получился он кривой-косой, с багами. Ну и что? Мир не рухнет.
А теперь представим что продукт твой ПО для управления АЭС. Кривое-косое? С багами? Возможные последствия себе представляете?
Даже попроще пример - банк. Платежи пошли не туда. Или регулярно пропускаются платежи туда, куда они не должны пропускаться. Тут тоже можно привлечь к себе внимание регулятора с весьма неприятными для банка последствиями.
Если баг пролез на пром и там "выстрелил" так, что возникли последствия в виде недоступности каких-то систем - тут уже не просто "дефект промсреды" заведут. Тут уже будет "комиссия по инцидентам" которая будет и ущерб оценивать и выяснять как оно так получилось и кто руку приложил. Расстрелять не расстреляют, но неприятности могут быть.
Посему, тезис достаточно неоднозначный. Где-то не решает, а где и решает. И там где решает, подход "херак-херак и в продакшен" не проходит. Там и кодревью будет и тестирование многоуровневое и план отката обязательный и все вот это вот. И вопрос о выборе (как спрашивал портной Фима с Молдаванки)
тут просто не ставится. Потому что баги тут имеют вполне реальную и очень таки осязаемую цену.
Возможно поэтому в такие области разработки не очень-то рвется молодежь - там легаси (сиречь только проверенные всесторонне временем решения и очень консервативный подход в плане всяких новшеств) и кровавый энтерпрайз (сиречь жесткая дисциплина разработки и требования к коду). Естественно, это касается прежде всего mission critical систем.
Kanut
Ну если вы откроете оригинальную статью на которую ссылается автор, то там в самом начале написано что это применимо примерно к 95% компаний. А где-то 5% компаний как раз таки не могут себе такое позволить .
SpiderEkb
В такой постановке - да. Но в целом сие печально.
domix32
Так там и цикл релиза будет невроятно длительный потому что помимо кода туда столько аудита добавляют, что мама не горюй. Да и ПО в общем-то не слишком связано именно с бизнесом.
Хотя с другой стороны помнится как разрабы ПО для всякой авиации седели, увидев на каком коде и честном слове летают самолёты. Но в случае с самолётами по крайней мере относительно понятен бизнес цикл. В любом случае речь по большей части не касается настолько критически важного софта т.к. там в любом случае цикл выпуска будет длинным из-за огромного количества испытательных этапов.
Прямые потери денег банком напрямую влиет на бизнес банка, поэтому такого рода баги банк будет решать за считанные часы. Ну а баблишко понятное дело компенсируют. Все эти истории когда с начала СВО половина банков России полегла под DDoS тому неплохой пример. Опять же этапы тестирования и развертывания в такого размера энтерпрайзах довольно массивные, поэтому за такой софт тоже особо беспокоиться нет смысла. А баги в приложениях для клиентов банка таки судьбу организации не решают.