YB
Так-то в IT сажают пачками, но формально - не за говнокод (нет такой статьи)
Ну я знаю только случай сговора в Сбербанке, когда про ошибку с курсом Йены знали в одном отделении и подготовились.
Size: a a a
2020 March 05
PD
О, а что за история?
YB
Но это опять же не за говнокод, а за сговор с целью мошенничества.
AP
Таких историй каждый региональный операционист из регионов в другом часовом поясе рассказать может, особенно 10-20 лет назад происходивших. Но это не совсем про ИТ, точно не про код и абсолютно не про архитектуру
AP
Или как там они называются - кассир-операционист?
YB
О, а что за история?
В отличие от прочих валют у Йены нет «копеек», просто она очень дешёвая, поэтому цену дают не за 1 йену, а за 1000. И вышло ПО с багой с неправильным расчётом обмена по курсу. Кто-то попытался на этом заработать.
PD
А, э, там было ПО с курсами без учёта делителя? Тут даже без сговора можно всех выгонять от аналитика до разработчика.
RT
Stack Overflow Driven, Component Driven, Data Driven, Support Driven, Event Driven, Parent Driven...
YOBA-driven development
https://www.urbandictionary.com/define.php?term=YOBA
https://www.urbandictionary.com/define.php?term=YOBA
YB
А, э, там было ПО с курсами без учёта делителя? Тут даже без сговора можно всех выгонять от аналитика до разработчика.
Там не выгнали, а посадили за мошенничество
PD
Ну, тоже хорошо
YB
Я так понял, там не на сеть разлили, а закладку сделали. Но было больше года назад, точности могут быть не точными.
YB
Но там прям доказали, что это было специально по сговору с сотрудниками какого-то отделения.
DK
Если у вас длительный ремонт в квартире, полагаю, вы будете считать неглупой идею периодически навещать бригаду работников.
И прогресс будете оценивать примерно так: в прошлый раз в этой комнате обоев не было, а в этот раз есть.
Если поклеено ровно и без щелей - то качество удовлетворяет, переделывать не нужно.
И прогресс будете оценивать примерно так: в прошлый раз в этой комнате обоев не было, а в этот раз есть.
Если поклеено ровно и без щелей - то качество удовлетворяет, переделывать не нужно.
Но это же очень ограниченная возможность проверки. Да и она не показывает объем работ и внутренние изменения. Сколько там слоев штукатурки? Хорошо ли проложены провода? Там же куча работы внутри.
DK
Иначе получаются все те минусы, описанные сегодня.
RT
Вся разработка ведётся от обсуждений интерфейса, при этом теряются сутевые вещи.
Наблюдаю этот эффект в реальности. ТЗ ставится как эскиз пользовательского интерфейса, а что там внутри бизнес-процесса как раз теряется.
Продакт это про картинки и эскизы, как там оно будет выглядеть для пользователя.
Но, например вопрос о финансовой схеме сервиса вызывает зависание мозга и искреннее непонимание чего тут хотят.
Это очень печально: команды с успехом делают красивые интерфейсы, но вообще не понимают как работает базовый сервис
Продакт это про картинки и эскизы, как там оно будет выглядеть для пользователя.
Но, например вопрос о финансовой схеме сервиса вызывает зависание мозга и искреннее непонимание чего тут хотят.
Это очень печально: команды с успехом делают красивые интерфейсы, но вообще не понимают как работает базовый сервис
YB
А в случае с Боингом история прекрасна. Пока Боинг не ткнули, что сэмики как-то уж очень одинаково воткнулись, Боинг вовсю говорил что-то про «бывает». И только когда посадили весь авиапарк, они признали, что налажали в ПО, и вроде до сих пор исправляют.
YB
Но это же очень ограниченная возможность проверки. Да и она не показывает объем работ и внутренние изменения. Сколько там слоев штукатурки? Хорошо ли проложены провода? Там же куча работы внутри.
Сколько раз делал ремонт: обязательно расштрабили — позвали. Пересчитал розетки, обратил внимание, что две забыли. Доштробили — позвали, получили добро на штукатурку. Доштукатурили — позвали, получили добро на обои. Поклеили — позвали...
GK
Наблюдаю этот эффект в реальности. ТЗ ставится как эскиз пользовательского интерфейса, а что там внутри бизнес-процесса как раз теряется.
Продакт это про картинки и эскизы, как там оно будет выглядеть для пользователя.
Но, например вопрос о финансовой схеме сервиса вызывает зависание мозга и искреннее непонимание чего тут хотят.
Это очень печально: команды с успехом делают красивые интерфейсы, но вообще не понимают как работает базовый сервис
Продакт это про картинки и эскизы, как там оно будет выглядеть для пользователя.
Но, например вопрос о финансовой схеме сервиса вызывает зависание мозга и искреннее непонимание чего тут хотят.
Это очень печально: команды с успехом делают красивые интерфейсы, но вообще не понимают как работает базовый сервис
Именно. Иногда случаются парадоксальные вещи. Команда/группа людей работающая над проектом, забывает даже цель решения. На встречах львиная доля времени уделяется обсуждению "кнопочек", а в центре этой истории - UI дизайнер, герой нашего времени.
PD
А все равно качество звукоизоляции выясняются после окончания работ (
RT
Я не зря тут ною про некомптетентность “команд” в прикладном домене, сейчас это прямо проблема. Учить команды понимать бизнес-прцоессы системы.