Комментарии 39
С ребёнком то все нормально ?
Можно, я на английский переведу? (Если разберусь, как на Хабре делать английскую статью). Надо начальнику показать.
А при чем тут код и ит-компании? Нет — я сам, как ИТ-шник, бы очень хотел, что бы к моей работе относились как к работе врача: что бы претензии заказчика и его недовольство — побоку. В какой-то мере моя репутация на текущем месте работы позволяет это до определенного предела… но все-таки ит для бизнеса, а не наоборот. Берега надо знать.
Они (врачи интенсивки) именно поэтому и могут себе позволить так выстраивать работу, что работа такая.
ИТ и рядом не стояли в плане сложности и ответственности. Ответственности особенно.
Вы о том, какая должна быть ответственность.
Я о том, на каком уровне она в средней ИТ-компании.
Просто сначала надо повысить уровень ответственности, а потом претендовать на процессы вида «никогда не оценивают время ее решения сверху. Только снизу», «Никто не пытается быть «customer obsessed», всем плевать на глупые неквалифицированные запросы кастомера» и «Претензии клиентов к работе сотрудников игнорируются»…
В реальной жизни часто встречаются ИТ-сервисы (чаще всего в тех областях, где они смогли получить какой-то вариант монополии), которые ведут себя по отношению клиенту именно так, как описано, при этом никакой особенной «ответственностью» не отличаясь… За примерами ходить далеко не надо — это и большая тройка GSM, некоторые банковские сервисы, некоторые провайдеры…
А когда самолеты падают и гибнут 300+ человек из за ошибок в ПО
А когда такое было? Только не про MCAS, там не ошибка в ПО.
Там, как и во многих ситуациях, был комплекс ошибок, который привёл к аварии. Убери из этого комплекса любую единичную ошибку и мы бы получили очередной некритичный баг.
Во-первых, проблема развесовки самого планера, из-за которой и пришлось реализовывать такой механизм
Во-вторых, насколько я слышал, оно работало от одного датчика вместо двух (но, возможно, я ошибаюсь)
В третьих, софт не учёл "странное" поведение планера — выполняем триммирование, а показания датчика не меняются.
В четвёртых, логика работы системы не была описана, пилоты просто не понимали, что происходит.
В пятых, не было тренеровеи пилотов на отработку данного отказа.
Ведь пост-фактум уже выяснилось, что эта проблема в полёте решалась элементарно, как минимум одним из двух способов:
- каждые 5 секунд нажимать на кнопку триммирование на штурвале, тогда MCAS не будет успевать включаться
- начать переводить самолёт в посадочное положение, снизив скорость и выпустив закрылки, в таком режиме MCAS отключается
Если бы пилотов заранее обучили отрабатывать такой отказ, то вместо двух разбитых самолётов и кучи жертв мы бы получили "два авиапроисшествия без пострадавших". Допускаю, что даже Боинг бы вместо полного запрета на полёты max'ов отделался бы намного легче.
Там, как и во многих ситуациях, был комплекс ошибок, который привёл к аварии
Это называется "синергия" — без него не было бы ни двух "Боингов", ни Чернобыля (если бы кнопка аварийного глушения реактора не вводила в него — на несколько секунд — положительную реактивность...), ни "Аполлона-13" (если бы датчики температуры показывали, что в баке при выпаривании кислорода было не 27 градусов, а over900), и прочаго, и прочаго, и прочаго — но большей частью виновны всё же люди, благодаря неполному пониманию происходящих процессов (знали бы про реактивность — не жали бы кнопку; знали бы про датчики — следили бы вручную за температурой, не полагаясь на термопары автоматических размыкателей, и т.п.), знали бы про логику работы MCAS — выпустили бы закрылки...
Убери из этого комплекса любую единичную ошибку.
И я даже знаю имя этой ошибки — жажда наживы и гонка за прибыльностью любой ценой. Особенно грустно что никто из руководства Boeing не сел с конфискацией всех активов, а тем более не помазал лоб зеленкой (а надо бы).
- если мы говорим о вероятности сделать ошибку и необходимости делать то, что никогда до этого не делал, то медицина и рядом не стояла
- а вот если мы смотрим на масштаб последствий возможной ошибки, то никакой неожиданно покрасневший юнит-тест рядом не стоял с потенциальным трупом
Да, я
[действия из статьи] действительно минимально необходимые в любой компании, которая производит что-то помимо отходов и макулатурыя бы ожидал чуть более обстоятельное сравнение, чем «мы тут людей лечим, а вы какую-то фигню делаете».
На всякий случай, с
С должна быть в комменте ниже — та же проблема. Повышение ответственности — штука дорогая. Ещё и заметно замедляет скорость разработки. Должна кому? Далеко не везде клиенты готовы платить втридорога за чуть меньшее количество багов (привет, большая тройка GSM)
И таких примеров может быть много на самом деле, информационные системы уже плотно вошли в нашу жизнь и требования к ним должны быть на высоком уровне.
что доктор сделает/сделал все, что мог.
… чтобы написать свой диссер или(и) пополнить свое личное маленькое кладбище. А что — обстоятельства непреодолимой силы; если хорошие отношения с начмедом и главнюком — так и от погон прикрыть может.
Скорость вывода инноваций в ИТ несоизмеримо больше, чем в медицине, цена риска (в целом, не берем узкие ниши типа самолетостроения) ниже. Каждый подход имеет свои ограничений и хорош для своей области.
Но в медицине ситуация другая. Если не брать коммерческую медицину, а ту, которую описал автор — там целью является обеспечение качества жизни пациента на максимальном возможном уровне, стремящемся к качеству жизни здорового пациента.
Поэтому медицина, обеспечивающая выживание пациента, и ИТ лежат в разных плоскостях.
И расходы в такой медицине намного больше того, что может позволить себе заказчик. Как раз за счет страхования.
Еще в медицине другие подходы к образованию. Несколько лет учебы, теория, практика, специализация, ординатура, интернатура, повышение квалификации, сертификация. Врача без действующего сертификата не допустят к работе в учреждении.
Если сравнить с ИТ — то это «высокий входной порог».
В силу описанных ранее причин — целей и образования — то есть уровня подготовки специалистов, и разные методы работы.
Хотя есть книжка «Чек-лист» — там очень хорошо расписано, как применение методов из авиации по чек-листам в хирургии снизили количество послеоперационных осложнений. И автор советует этот же метод применять в ИТ и в жизни.
Я одновременно согласен с вами — у вас весьма аккуратные формулировки "невероятная сложность изменений и вывода новых методов лечения и препаратов", "Скорость вывода инноваций в ИТ несоизмеримо больше, чем в медицине, цена риска (...) ниже" и "Каждый подход имеет свои ограничений и хорош для своей области". Это всё так. Но есть момент, в котором хочу возразить.
Медицина очень консервативна. Это в определённой мере так. От идеи до врача проходит немало времени, особенно в методах лечения и выводе новых препаратов. Но на самом деле медицина быстро меняется. Не в смысле, что меняется скорость внедрения, а в том смысле, что диагностика, методы лечения и препараты очень быстро меняются. На уровне условного "участкового терапевта" это не так заметно, но все специализированные и технологичные направления меняются очень быстро. В диагностике МРТ, анализ ДНК ещё лет 10 назад были в целом экзотикой. Сейчас это мейнстрим. Стали применяться технологии ИТ для обработки данных в несравнимом объёме. Офтальмологическая хирургия, ЭКО, лечение опухолей, протезирование конечностей, нейрохирургия — всё это тоже за 10-15 лет тоже изменилось очень существенно. Да, в диагностике изменения быстрее, чем лечении — для диагностики обычно проще убедиться, что она безопасна. В программировании, за исключением нескольких областей (типа веб-фреймворки, облачные технологии, да всякие "блокчейны"), скорость прогресса сопоставима, если не меньше. А в проектировании реляционных БД вообще можно смело брать книгу Дейта 20-летней давности.
Да, у нас, в ИТ есть возможность попробовать новые технологии хоть вчера придуманные в прямо проме (только чувакам из core banking processing этот секрет не говорите :) ) — это так. Не везде, но можно. У медиков так не получится. Но это latency. А вот throughput изменений в целом вполне сопоставим. И устаревают у них, у медиков, знания — только в путь (регуляторно обязательные обучения не на пустом месте возникли).
Как мне кажется, одна из причин такой разницы и, вероятно, это очень значимая причина — тот факт, что медицина в нашей стране не до конца коммерционализирована (пока еще). Ведь что заставляет нас в ИТ устанавливать, например, крайние сроки? Требование бизнеса. А их что заставляет? Страх потерять деньги или возможность заработать.
Увы, причём рассмотренный в статье случай очень похож на учреждение подпадающее под финансирование без участия фмс( в котором, но может и ошибаюсь)
Это когда две сантиарки везут детские трупики и хохочут над анекдотом.
Иначе сбрасывать стресс лучше учить тех, кто в конце дня или недели заливается алкоголем, чтобы «мозг перезагрузить».
Лично, когда лежал в 1998м месяц в терапии с ЖКТ в городской больнице, три раза в выходные помогал дежурным медсестрам перевозить из реанимации в морг тела пенсионеров весом более 100 км. Я и еще двое парней из терапии, кто от военкомата лежал. Нужно было помочь каталку докатить и в морге переложить с каталки на стол — это было самое тяжелое. Первый раз когда везли — еще было какое-то ощущение, что вот, человек был и не стало. На третий раз уже главным было — выполнить без инцидентов то, о чем попросили, и вернуться к своим делам в палату. И я не медик.
Это просто нейропластичность. После того, как санитарки отвезли первые 100 трупиков, приходит понимание, что:
1) Этот трупик не последний и даже не предпоследний.
2) Для кого-то жизнь, может, и кончилась, но для тебя-то продолжается.
3) Дедушка старый, ему трупику (уже) всё равно.
4) Ощущения от перевозки что трупика, что 20 кг кирпичей — практически одинаковые (а если абстрагироваться от характера груза — то совсем одинаковые). Как говорится, "Что Вы чувствуете, стреляя в человека? — Отдачу."
— ежедневный контроль изменений в требованиях со стороны заказчика, митинги и корректировка планов;
— о специализации: дежурит всегда минимум один «сеньор», который может переставить катетеры, переподключить аппарат ИВЛ и т.п., в общем, оперативно решить проблему; если есть нестабильно тяжелые — выходит дежурить доп. «сеньор»;
— из личного опыта, а у нас долго не было опорного диагноза — постоянная проработка новых тестов, перераспределение ролей, перекрёстный контроль — перепроверяли «логи» (историю болезни) и переделывали анализы в других лабораториях, тестировали инфраструктуру на стороне заказчика (проверяли родителей и всю родословную), меняли лекарства, меняли производителей лекарств (!);
— меняли тимлида (лечащего врача), если долго (неделю) не было положительной динамики. И это не от недовольства его работой, просто искали свежие идеи, пытались определить конкретную точку приложения усилий.
И в общем под этим углом, лично мне, кажется, что работа интенсивной терапии(сужу по ОРИТНН) очень напоминает работу над проектом, который скинули команде сеньоров, когда перед самой сдачей (или на ней) что-то пошло кардинально не так. Только уровень ответственности несравнимо выше… И следующий проект — такой же…
Принципы работы детского отделении интенсивной терапии в виде ответа на «Программист, стая и Джон Стейнбек» или