Comments 94
Риски ведения любого реального бизнеса, связанного с физическими объектами и живыми людьми несоизмеримо выше любой разработки, поэтому даже заикаться о рисках в ИТ, что чего‑то там «возможно не получится» — откровенно смешно.
Не смешно. Надо разделять вероятность риска и влияние плохого результата на дальнейшую деятельность. Риски в айти - непредсказуемые, огромные по вероятности и нарастающие вместе со сложностью проекта. Попробуйте найти большой проект без просранных сроков.
Влияние в деньгах на бизнес выше, это правда. Но это компенсируется прибыльностью бизнеса. Бизнес не будет делиться неожиданно высокой прибыльностью с линейным программером, он заберёт всё себе. Как следствие - он не в праве штрафовать программера, если у него появилась куча подводных камней. Да и вообще, программер обещал менять часы работы на деньги, а не впахивать на успех бизнеса.
Риски в айти - непредсказуемые, огромные по вероятности и нарастающие вместе со сложностью проекта. Попробуйте найти большой проект без просранных сроков.
Сейчас возможно будет очередной «срыв покровов»: не бывает сложных проектов без предистории и на пустом месте. А значит кто‑то этот сложный проект до вас много лет создавал и затем поддерживал — точно есть и компетенции и цифровой след и понимание что с этим делать.
А что вы будете делать например с ураганом или наводнением?
Про сроки в статье описано - срыв сроков и бюджета это и есть единственный возможный риск в ИТ.
значит кто‑то этот сложный проект до вас много лет создавал и затем поддерживал
Например я. Что это меняет в области рисков?
А что вы будете делать например с ураганом или наводнением?
То же, что и все остальные - страховать.
Про сроки в статье описано - срыв сроков и бюджета это и есть единственный возможный риск в ИТ.
А что, бывают другие риски, кроме сроков и бюджета?
Ну давайте, расскажите про риски бизнеса, которые не в бюджет и не в сроки упираются.
Ну давайте, расскажите про риски бизнеса, которые не в бюджет и не в сроки упираются.
Смерть одного из главных актеров, для примера. Потеря локации, потеря отснятого материала.
Понимаю что вы (как программист) сейчас сведете все к бюджету, но в реальности он не бывает резиновым даже у олигархов, плюс кино это химия, где смена ключевых персонажей = смене ингредиентов и итоговое варево может и не сработать.
Смерть одного из главных актеров, для примера.
Бюджет
Потеря локации, потеря отснятого материала.
Сроки, возможно бюджет
сейчас сведете все к бюджету
Это не я свёл к бюджету. Это вы. Это вы сказали, что в айти только к срокам и бюджетам риски сводятся. Они точно так же к рискам и бюджету сводятся, как и у бизнеса, даже просто потому, что айти - часть бизнеса.
Вопрос: а зачем все эти пафосные речи? Зачем пренебрежение к айтишным рискам, которые существуют и находятся с нами в одной комнате?
Зачем пренебрежение к айтишным рискам, которые существуют и находятся с нами в одной комнате?
В то лето, когда происходили описываемые съемки случилась трагедия - в Сочи при исполнении сложного трюка погиб один из знакомых каскадеров, ребята долго это обсуждали.
Миг и человека больше нет.
В ИТ даже близко сопоставимого риска нет и быть не может - люди все также хотят каждый день на работу в стеклянные офисы, временами меняя локации.
С внезапной смертью на работе вы врядли столкнетесь.
А, то есть лид проекта не может попасть под автобус, да?
Может, но на проект это никак драматически не повлияет.
Замена каскадёра тогда тоже не повлияет.
В чём разница?
Разница в шансах: для каскадера риск умереть на работе кратно выше.
Окей, верно. Но я не про это спрашивал. В чём разница для проекта?
Ну давайте поясню, видимо айтишники действительно настолько далеки от реальности.
Погиб человек, что само по себе ЧП и влечет за собой открытие уголовного дела.
Место происшествия оцепят, съемки остановят, всех присутствующих будут таскать по допросам.
Если был постановщик трюков (в том случае не было) - он точно будет крайним и рискует сесть в тюрьму.
Насколько серьезно это может повлиять на итоговый результат в виде кино или сериала - решайте сами.
Мне известны самые разнообразные варианты исхода, начиная от полной отмены съемок до глобальных переделок и задержек с выпуском.
Ага, только нового каскадёра обучать - это дни. А вот нового лида вкурить в курс дела - год. При большом проекте.
Вы там переживёте оцепление, надо будет - постановщика найдёте нового.
Я не понимаю вот чего: а зачем вы так пренебрежительно относитесь к рискам в айти?
видимо айтишники действительно настолько далеки от реальности
Зачем опять вы переходите на личности? В прошлый раз мы мне советовали обратиться к лечащему врачу. Зачем так?
Может быть это вы далеки от реальности айтишной и не понимаете, что тут риски не меньше по амплитуде?
Ага, только нового каскадёра обучать - это дни.
Только почему-то второго Джеки Чана нет до сих пор а трюки знаменитого Бастера Китона не смог повторить никто из современных каскадеров.
надо будет - постановщика найдёте нового.
А если я скажу что их просто нет?
Ну вот так просто: физически нет таких, совсем и вообще. Есть задача снять кино с трюками а постановщиков нет.
И что дальше?
И обучить с нуля нереально, поскольку учатся они только на реальных проектах и в большинстве своем это суровые дяди в возрасте.
А, вы Джеки Чана снимаете? Снимаю шляпу, молодцы!
Лида тоже может и не быть. Ну вот вообще. И никто не понимает, что с этим кодом делать. Ну вот физически нет.
Лид ушёл. Что вы будете делать?
Вы вообще осознаете что есть существенная разница между сидением попой на стуле в офисе и другими видами деятельности?
Лида тоже может и не быть. Ну вот вообще. И никто не понимает, что с этим кодом делать.
А если самого офиса больше нет — физически нет, тк снесло ураганом?
Ощущаете разницу в сложности?
Только почему-то второго Джеки Чана нет до сих пор
А кино с трюками все снимают и снимают. И не обязательно с Джеки Чаном.
Погиб каскадёр - это трагедия, кто спорит. Пока идут следственные действия - можно снимать другие сцены с другими актерами в другой локации, параллельно подбирая дублёра и/или меняя сценарий. Бюджет и сроки, как обещали.
У меня создается впечатление, что вы ПО воспринимаете как нечто автономное в вакууме. Программы пишутся для применения в бизнесе. Неужели за 25 лет стажа никогда не вникали в предметную область????
Не успеете написать прошивку марсианского зонда к моменту оптимальной траектории - придется отменять старт и ждать 26 месяцев. Ошибка в банковском приложении легко может стоить как сотни бюджетов фильмов Джеки Чана, баг в медицинском ПО может привести к ошибке в диагнозе и смерти пациента, проблема в ПО атомной электростанции, кажется, более рисковый момент, чем смерть даже всей съемочной группы фильма.
Ошибка в банковском приложении легко может стоить
Давайте обсуждать конкретику а не все эти больные фантазии.
Конкретика у вас есть? С фактами, персоналиями и цифрами, чтобы конкретный программист Вася ответил на «пицот мильонов» за вставший колом продакшн — есть такое?
Что-то мне подсказывает что нет.
Конкретика ущерба, например, вот, при помощи ПО от Яндекса легко находится: https://habr.com/ru/companies/quadcode/articles/730726/
Каковы были последствия для разработчиков, не знаю, но, когда я ходил по собеседованиям в 2010 году, были компании, где по договору ущерб для фирмы должен был быть возмещен (вычетами до 40% из каждой ЗП). Где-то за косяки лишают премий, где-то увольняют (возможно, с волчьим билетом). При работе на разовом проекте (что ближе всего к съемкам фильмов) затягивание сроков влечет штраф вплоть до обнуления оплаты программиста заказчиком и обрушение репутации подрядчика, что совершенно аналогично риску хренового актера после провала фильма.
Но все это не про риски, не нужно смешивать риск при создании ПО и последствия для накосячившего. Вы же приводите в пример риски стихийных бедствий. Какого Basil Navelson наказали за ущерб от тайфуна, уничтожившего декорации?
при помощи ПО от Яндекса легко
Я вроде ясно дал понять, что обсуждать похождения "программиста маминой подруги" из поисковой выдачи не имеет смысла.
У вас лично был означенный опыт? Когда вы лично, своими глазами видели ответственность разработчиков? Нет? Тогда обсуждать нечего, написать в интернете можно все что угодно.
где по договору ущерб для фирмы должен был быть возмещен
О как интересно и что вам трудовой договор показывали на собеседовании?
Но вообще вы несколько далеки от реалий, в российском ИТ существует всего один способ заставить сотрудника отвечать за причиненный ущерб — договор материальной ответственности. Чаще всего такой договор подписывают ИТ-директора (CTO).
Если он подписан, тогда человек отвечает за например потерянный сервер или ноутбук. Но и то все эти разборки происходят через суд.
возможно, с волчьим билетом)
Нет никакого «волчьего билета» и нет никаких страшных «черных списков» куда намеренно заносят кандидатов злобные рекрутеры. Все это не работает даже когда надо — когда человек был пойман на воровстве или уволен за пьянство.
и обрушение репутации подрядчика
Из отрасли выгонят? А в случае серии провалов именно это и происходит с карьерой актеров.
Но все это не про риски, не нужно смешивать риск при создании ПО и последствия для накосячившего.
А как вы представляете себе одно без другого?
Какого Basil Navelson наказали за ущерб от тайфуна, уничтожившего декорации?
Страховка покрыла ущерб, насколько мне известно. Что не отменяет сдвиг сроков и висевший риск отмены вообще - если бы не договорились.
А как вы представляете себе одно без другого?
Еще раз: давайте разделять риск разработки ПО и ответственность разработчика при косяках. Риски разработки ПО это риск не разработать продукт (малоопытный разработчик не потянул, деньги кончились), или получить продукт не выполняющий свои функции (ПО пафосно внедрили, а сотрудники через неделю взбунтовались, потому, что заказчик сэкономил на аналитике или дизайнере UI), или не получить продукт к нужному сроку (заложили слишком много фич и не осилили вовремя, конкуренты заняли рынок и пользователей уже не переманишь). Это риски заказчика, а ответственность разработчика прописывается в договоре. Собственно, косяки разработчика это только часть рисков разработки.
Риски разработки ПО это риск не разработать продукт
Нет таких рисков в природе.
малоопытный разработчик не потянул, деньги кончились
Разработка будет поставлена на паузу, пока не найдется новый бюджет и/или более грамотный исполнитель. Но даже незавершенный продукт никуда не денется.
ПО пафосно внедрили, а сотрудники через неделю взбунтовались, потому, что заказчик сэкономил на аналитике или дизайнере UI
Это не так происходит. Для начала делается "пилот" и с новым ПО допускают работать небольшое количество сотрудников и после специального обучения. По итогам "пилотного внедрения" составляется отчет и набор пожеланий, часть из которых возможно дойдут до разработки.
А вот бунтовать сотрудники не будут никогда, поскольку неработающее ПО для них является идеальной отговоркой для заваленной работы.
заложили слишком много фич и не осилили вовремя, конкуренты заняли рынок и пользователей уже не переманишь
Так не бывает поскольку захват рынка зависит не от набора фич а фактически только от заложенного бюджета на продвижение и жесткий демпинг.
Если вы сможете создать упрощенный аналог существующего ПО (любого) и скажем 10 лет продавать его за треть цены конкурентов — рынок ваш.
Я смотрю, вы всё про всё знаете, аргументы у вас железные (Нет таких рисков в природе) с такими не поспоришь. Пожалуй, пойду отдыхать в заслуженный отпуск.
Мне просто стыдно за коллег, поскольку такое раздувание «воображаемых рисков» приводит к тому, что люди трижды думают перед тем как запускать разработку, их приходится убеждать и тратить на все это существенное время.
Копеечные бюджеты в отрасли — тоже прямое следствие такого отношения к работе, бюджет выделяется по принципу «не сильно жалко потерять» а не исходя из реальной оценки.
рукалицожпг...
Риски разработки нужны не для запугивания заказчика, а для правильной оценки требующихся ресурсов.
а для правильной оценки требующихся ресурсов.
Ну попробуйте как-нибудь оценить проект в пару млн долларов, потом расскажете о реакции заказчика )
Вы предпочитаете сознательно занижать человеко-часы/финансы и работать в убыток или в авральном порядке на износ? Или заранее закладываете бОльшие сроки-суммы, но озвучиваете заказчику меньшие, в расчете на то, что вложившись он пожалеет бросать проект и продолжит финансирование?
Ну и потом, пара миллионов это смотря для каких заказчика и проекта. В десятые годы у больших контор было модно внедрять SAP R/3, там, пожалуй и поболее суммы фигурировали.
Вы предпочитаете
Неважно что я предпочитаю, когда есть правила отрасли и давно известная градация бюджетов.
Ну и потом, пара миллионов это смотря для каких заказчика и проекта
На данный момент — любого. Не будет больших бюджетов, пока не будет серьезного отношения, которого не будет из‑за отсутствия ответственности.
В десятые годы у больших контор было модно внедрять SAP R/3, там, пожалуй и поболее суммы фигурировали
Фигурировали, но только SAP - иностранная компания и иностранный же продукт, поэтому отношение и было несколько другим.
Неважно что я предпочитаю, когда есть правила отрасли и давно известная градация бюджетов.
Но для себя-то вы учитываете риски? Чтобы не переборщить с занижением или предложить дополнительное обследование-аналитику.
Например, риск того, что заказчик сам толком не знает свои бизнес-процессы и разрабатываемое ПО, после написания по ТЗ заказчика, придется долго и муторно дорабатывать напильником?
Чтобы не переборщить с занижением или предложить дополнительное обследование-аналитику.
При моем опыте сколь-нибудь серьезной ошибки в оценке быть уже не может )
риск того, что заказчик сам толком не знает свои бизнес-процессы
Сейчас снова сорву покровы: в подавляющем большинстве случаев заказчик не знает, не представляет и не догадывается.
Поэтому и нужны вы — профессионал, который подскажет, расскажет, объяснит и посчитает.
При моем опыте сколь-нибудь серьезной ошибки в оценке быть уже не может )
Т.е. вы риски явно не учитываете, включаете интуицию?
Сейчас снова сорву покровы: в подавляющем большинстве случаев заказчик не знает, не представляет и не догадывается.
Поэтому и нужны вы — профессионал, который подскажет, расскажет, объяснит и посчитает.
Помню, такой подход был в моде в начале нулевых. Как раз у SAP практически девизом шла мысль: мы уже автоматизировали туеву хучу фирм и лучше всех знаем, как должны строиться бизнес-процессы. Потом, правда, по доходившим до меня слухам, оказалось, что на нашей территории их немецкие бизнес-процессы не работают... И пришлось уже "почти внедренные" системы серьезно допиливать для совмещения с реальностью.
Но и "клиент всегда прав" не работает. Предпочитаю золотую середину - клиент, вероятно, знает свой бизнес (если сам построил или много лет в деле, конечно), но не знает в автоматизацию и, вероятно, не всегда строит процессы оптимально. Мое дело выяснить смысл бизнес-процессов и предложить оптимальную реализацию.
Т.е. вы риски явно не учитываете, включаете интуицию?
25 лет практики это очень много, поэтому нет уже никаких рисков при оценке. Нету. Кончилось детство.
такой подход был в моде в начале нулевых.
Так это не вопрос моды, оно по логике так происходит. Зачем нужна экспертиза и компетенции, если предполагается что на стороне заказчика все и так хорошо и понятно?
и лучше всех знаем, как должны строиться бизнес-процессы
А как иначе? Если вы целенаправленно автоматизируете предприятия по всему миру — действительно будете знать лучше и понимать больше, чем ИТ‑подразделение одного конкретного завода. Или с этим тоже будете спорить?
что на нашей территории их немецкие бизнес-процессы не работают
Несмотря на весь негатив вокруг продукции SAP и их практик, как только они вышли из РФ — внезапно оказалось что никаких аналогов внезапно нет и компетенций SAP сильно нехватает.
Вой стоит настолько громкий, что уже на уровне государства собрались финансировать разработку аналога.
Мое дело выяснить смысл бизнес-процессов и предложить оптимальную реализацию.
Оптимальную по сравнению с чем?
25 лет практики это очень много, поэтому нет уже никаких рисков при оценке.
Я про риски не в смысле дать неправильную оценку, а в смысле неопределенных факторов влияющих на реализацию, тех проблемах, которые могут случиться, а могут и нет, от которых в значительной степени зависит вилка по ресурсам.
Оптимальную по сравнению с чем?
С другими вариантами реализациями по совокупности факторов. Предложить где-то оптимизировать безнес-процессы, но учитывать, что заказчик, если это не новый владелец, в этом всем варится и может знать какие-то факторы, делающие наши оптимизации не работающими.
в смысле неопределенных факторов влияющих на реализацию, тех проблемах, которые могут случиться
Еще раз: 25 лет это много ) Нет никаких "неопределенных факторов", тем более влияющих на реализацию.
Все что могло случиться — уже случилось.
Предложить где-то оптимизировать безнес-процессы
Что вот так сразу и сходу? Вас точно об этом просили? Если скажу что смысл внедрения SAP как раз и заключался в том чтобы все местные оптимизаторы шли лесом - сильно удивитесь?
Что мешает неопределенным факторам повториться?
В процессе разработки заболевает/увольняется тим-лид
Аналитик не может найти общего языка с сотрудником, назначенным курировать проект со стороны заказчика, и ТЗ либо пишется очень медленно, либо с ошибками непонимания, которые потребуют переработки ПО на стадии тестирования с заказчиком
Обстановка на рынке меняется и оказывается очень важным добавить в приложение кнопку издавания трех зеленых свистков вверх, причем добавить так, что придется немного переработать все экраны приложения и половину DTO.
SAP, на сколько я помню (хотя сейчас могу уже соврать - лет двадцать прошло с тех пор как я интересовался мировым рынком MRP/ERP/CRM и прочих КИС), закупали во многом потому, что это авторитетно (лидер рынка, BAAN тогда уже сдал позиции, а Оракл был только СУБД), максимально функционально, есть у других крупных отечественных фирм и можно немалый бюджет освоить. Внедряли с большим скрипом, отставанием по срокам, и что принципиально - с большой кастомизацией под отечественные условия.
Слышал про случаи, когда SAP был явно избыточен, но его все равно, мучительно внедряли.
Кто помельче и хотел подешевле, брали Аксапту и тоже внедряли не без проблем.
А у отечественных производителей как не было в нулевых, так, похоже, и нет КИС для больших корпораций с сотнями тысяч сотрудников. Более того, с тех пор некоторые представители среднеразмерных систем вымерли, после того, как 1С научилась таки в нормальный клиент-сервер, а не так, что при работе пары десятков пользователей все тормозило нещадно.
Если на предприятии внедрен SAP сильно вряд ли меня подпустят к тем бизнес-процессам, но, если зовут автоматизировать другой участок, где еще нет автоматизации, то что мешает мне, посмотрев свежим взглядом и систематизировав предлагать бизнесу оптимизации? Не навязывать, как пытались в SAP в девяностые, а предлагать для дискуссии. Идея о том, что аналитик из какого-нибудь SAP/BAAN лучше основателя бизнеса знает, как у того должны работать процессы, кажется несколько устаревшей - сейчас заметная часть мира живет в постоянных изменениях чтобы не проиграть конкуренцию. И SAP это поняли, в рекламе новых продуктов упоминается гибкость и адаптируемость к индивидуальным особенностям конкретного бизнеса.
В процессе разработки заболевает/увольняется тим-лид
Временно достается другой — с соседнего проекта, с компании‑аутсорсера. Параллельно запускается поиск и найм нового — если лид ушел с концами.
Можно написать мне, благо есть такой опыт подхватывания проектов.
Короче это совсем не проблема, даже если внезапно ушел ваш директор (вместе с бухами), не то что какой-то тимлид.
Аналитик не может найти общего языка с сотрудником, назначенным курировать проект со стороны заказчика, и ТЗ либо пишется очень медленно, либо с ошибками непонимания, которые потребуют переработки ПО на стадии тестирования с заказчиком
Если работа оформлена как почасовая — радуетесь, если нет — в какой‑то момент переводите эту работу на почасовку и начинаете радоваться, организовыв встречу с руководством со стороны заказчика и объяснив ситуацию с конкретными фактами.
Обстановка на рынке меняется и оказывается очень важным добавить в приложение кнопку издавания трех зеленых свистков вверх, причем добавить так, что придется немного переработать все экраны приложения и половину DTO.
Вопрос практики проектирования, такого рода переделки «всех экранов» характерны для юных падаванов, пока еще остро желающих «переписать все».
Если дадите конкретику — расскажу как такие проблемы решаются без глобальных переделок.
Но вообще если вы выступаете как подрядчик, то такого рода изменения это просто дополнительная доработка, которая точно будет согласована и оплачена, поскольку остро нужна заказчику.
закупали во многом потому, что это авторитетно
Был период, когда использование решения SAP влияло на оценку всего бизнеса со стороны инвесторов, что позволяло получать более дешевые кредиты.
Как вы думаю догадываетесь, при таких смыслах никакие "сложности внедрения" никого не волновали.
сейчас заметная часть мира живет в постоянных изменениях чтобы не проиграть конкуренцию
До пандемии да, а теперь идет скорее откат к основам, поскольку вся эта "гибкость и клиенториентированность" сжирает ресурсы.
Вы перечислили варианты решения проблем с минимальным, но совсем не нулевым отклонением от графика. Замена тим-лида в процессе стартовавшей разработки это потеря не одного дня (найти замену, ввести в курс проекта, познакомить с командой и распределением задач). История с аналитиком может оказаться совсем не простой, если сотрудник подрядчика не открыто противостоит, а тихо саботирует (выдает не все данные), что может выясниться только на этапе пилотирования. Или на каком-то этапе аналитик с представителем заказчика (а то и с самим заказчиком) окончательно разругаются и придется заменять аналитика (это случай из реальной жизни).
Вопрос практики проектирования, такого рода переделки «всех экранов» характерны для юных падаванов, пока еще остро желающих «переписать все».
Согласен, не очень удачный пример. Шаблоны, разбиение экранов на блоки и виджеты решают вопрос. Хуже, если окажется, что на каждом экране функционал требует какие-то свои специфические данные, которые надо тащить из репозитория через все слои. Впрочем, забудем этот пример, я его из головы взял.
До пандемии да, а теперь идет скорее откат к основам, поскольку вся эта "гибкость и клиенториентированность" сжирает ресурсы.
Не могу судить о состоянии рынка заказной разработки ПО, но есть нейросети, которые жрут гораздо больше ресурсов. Тем не менее, все крупные игроки (включая SAP) в них вцепились, и, если реализуется хотя бы десятая часть задуманного, клиентоориентированность и гибкость возрастут на порядок.
но совсем не нулевым отклонением от графика.
А почему вас так сильно волнует этот вопрос? Сроки в разработке достаточно абстрактны сами по себе, поскольку не привязаны к физическим процессам. Ураган с пургой вам разработку не поломают, в худшем случае — отдалят релиз.
Во всех случаях кроме внешней заказной разработки, бюджет на разработку формируется на годы вперед, поскольку программисты нанимаются в штат и на оклад.
История с аналитиком может оказаться совсем не простой, если сотрудник подрядчика не открыто противостоит
Да пусть хоть в совместных оргиях участвуют — какая разница?
Я бы даже разбираться не стал — есть задача, есть ответственный за нее. Если ответственный человек по какой‑либо причине не выполняет обязательства — фиксируете и эскалируете наверх. Все.
Тут когда собственники бизнес делят — легко могут зайти с «группой поддержки» и физически выгнать всех с территории предприятия, еще и побив подвернувшихся под руку.
А вы говорите "тихо саботирует" ага )
клиентоориентированность и гибкость возрастут на порядок.
Как вы себе представляете возросшую "клиентоориентированность и гибкость" в B2B? Включение шалмана с эскортницами в план проекта?
Тут когда собственники бизнес делят — легко могут зайти с «группой поддержки» и физически выгнать всех с территории предприятия, еще и побив подвернувшихся под руку.
Вот! А говорите, никаких рисков в ИТ нет! Историю с группой поддержки я проходил на личном опыте (без побития). Везде есть риски, разные. Понимаю, новые впечатления в кино взорвали вам эмоциональную сферу. Да, безусловно, на съемках много сложнопредсказуемых факторов и часто факторы более "материальные" чем в ИТ, но зачем же сразу принижать свою профессиональную область? Если у вас в фирме процессы за годы так отлажены, что риски почти исключены, это ваша заслуга, а не жизнь в ИТ такая простая ).
Как вы себе представляете возросшую "клиентоориентированность и гибкость" в B2B?
Я? Я работаю в большой отечественной компании и автоматизирую процессы коллег инфраструктурщиков. Всегда стараюсь вникнуть в предметную область и понять потребность внутреннего заказчика. Не написать код строго по бизнес-требованиям и даже ТЗ, а решить проблему, с которой заказчик пришел. Заказчик (а иногда и наш собственный аналитик) может (имеет полное право) не знать всех возможностей и ограничений системы, придумывает решение по своему предыдущему опыту, что часто не оптимально. Иногда могу предложить использовать что-то из недавно освоенного отделом вместо того, что представлялось коллегам, иногда вижу и помогаю исправить логические нестыковки в бизнес-требованиях, иногда вынужден признавать, что какая-то идея заказчика на текущий момент слишком ресурсоемка, не окупит усилий, и либо конструктивно донести эту мысль до заказчика, с переносом задачи в бэклог на отдаленное будущее, когда появятся свободные ресурсы, либо предложить упрощенную альтернативу но сейчас. А иногда, если образовалось пол часа свободного времени, могу не заказанную небольшую фичу прикрутить, если вижу, что людям пригодится.
Но что я? Для меня общение с внутренним клиентом, приятный бонус (люблю ощущать, что моими продуктами пользуются, что они приносят людям пользу) или производственная необходимость (если штатный аналитик перегружен), не прописанные в должностных обязанностях.
Вот в интернете немало статей написано специалистами в этой области: https://yandex.ru/search/?clid=11450072&text=клиентоориентированность+в+B2B&l10n=ru&lr=213 )))
Нет таких рисков в природе
Ну да, конечно.
Просранные сроки - устройство не вышло в продажу как запланировано - в рождественский бум покупок не попало - доходы от продаж не те которые ожидались. Упсь.
Косячная прошивка - возвраты, обращения по гарантии, вместо доходов от продаж - расходы на гарантийное обслуживание. Упсь.
Просранные сроки - устройство не вышло в продажу как запланировано - в рождественский бум покупок не попало - доходы от продаж не те которые ожидались
И что вы с таким накалом отмечаете Рождество?
Вся эта возня с выпуском чего‑то под праздники была актуальна в 90е, сейчас другое время ПО даже на полках магазинов нет — лицензии покупают онлайн.
Что касается устройств, опять же на дворе давно не 90е - у вас телевизор с холодильником апдейты качают по сети, так что никакой привязки к праздничным датам давно уже нет.
И что вы с таким накалом отмечаете Рождество?
Традиции, сэр Многие люди под праздники делают друг другу подарки. Продажники это знают. То что не продано сразу - будет занимать место на складе и генерировать расходы.
телевизор с холодильником апдейты качают по сети,
Это совсем мимо. Апдейт - это гарантийное обслуживание. Сплошные расходы.
То что не продано сразу - будет занимать место на складе и генерировать расходы.
Апдейт - это гарантийное обслуживание
Вы всего этого в интернете начитались что-ли? Где такую фантастику рассказывают?
В РФ если что Рождество практически не отмечают, собственно даже Новый Год отмечают все меньше и меньше.
Также еще раз напоминаю, что на дворе не 90е — с логистикой все хорошо и проблем со складами нет, уж точно не для мелких подарков.
О как интересно и что вам трудовой договор показывали на собеседовании?
Проводивший собес начальник отдела был откровенен и поделился случаем, когда косякнувшему программисту за деятельное раскаяние скостили половину суммы ущерба. Фирма существует и поныне.
Но вообще вы несколько далеки от реалий, в российском ИТ существует всего один способ заставить сотрудника отвечать за причиненный ущерб — договор материальной ответственности. Чаще всего такой договор подписывают ИТ-директора (CTO).
Что вы рассказываете? Я сам лично, работая по договору подряда подписывал пункты об уменьшении гонорара в процентах за сутки на случай срыва сроков.
Проводивший собес начальник отдела был откровенен и поделился случаем
Ну верьте больше, что тут сказать. Интересная наверно компания )
сам лично, работая по договору подряда подписывал пункты об уменьшении гонорара в процентах за сутки на случай срыва сроков
Дело в том что подрядные работы не имеют ничего общего с работой в штате компании. Для подрядчиков в обязательном порядке подписываются пункты об ответственности, ваш можно сказать типовой для ГПХ.
косякнувшему программисту за деятельное раскаяние скостили половину суммы ущерба
Менеджера, не сообразившего организовать тестирование, наградили премией за экономию человеко-часов
баг в медицинском ПО может привести к ошибке в диагнозе и смерти пациента
И не одного... Therac-25
Каскадеру платят именно за риск, нам платят за работу головой, помощнику реквизитора платят за работу руками, порно актрисе... Кто-что умеет.
Фильмы бывают разные и программы бывают разные. Почему вы сравниваете высокобюджетный фильм для проката с офисным MVP? Сравните с управляющей программой ядерного реактора.
В кино, насколько мне известно, тоже есть масса народа, кроме съёмочной группы, работающая в офисе.
В разработке ПО куча рисков.
Ошибка в разработке ПО управления элеронами (например) в самолётостроение приводит к катастрофе. При разборе полетов посадят кого-то из команды разработки (по крайней мере в нашей стране)
Ошибка в разработке ПО для финансовой аналитики для типа крутых бизнесменов может привести к тому, что люди потерявшие деньги из-за вас просто вас пристрелят.
Ошибка в разработке в игре, когда один из игроков потеряет весь шмот, лут и прочие виртуальные прелести может привести к тому, что нестабильный психически игрок самовыпилится. А его родитель придет к вам с дробовиком и снесет вам голову.
И таких примеров куча. Примеры 2 и 3 из реальной жизни. Можете поискать в интернете. Человек каждый раз принимая любое решение подвергает себя риску.
И не нужно путать горячее со сладким...
Ну давайте разберем.
Ошибка в разработке ПО управления элеронами (например) в самолётостроение приводит к катастрофе.
Поэтому все рабочие системы в самолете дублируются, в случае самолетов гражданской авиации - неоднократно.
Каждая катастрофа внимательно изучается и расследуется и пока ни одного случая, когда разработчик ответил бы за падение самолета мне не известно.
В советсткие времена за такие инциденты всегда отвечало руководство и сажали именно его, но не рядовых инженеров.
Ошибка в разработке ПО для финансовой аналитики для типа крутых бизнесменов может привести к тому, что люди потерявшие деньги из-за вас просто вас пристрелят.
ПО реально отвечающее за чистую прибыль - невероятная для всей отрасли редкость, обычно софт выступает всего лишь приложением к работающему бизнесу.
Но даже в столь редком случае, если вдруг найдется недочет или даже серьезная ошибка в таком софте — карать разработчиков никто не будет, поскольку дураков, режущих
«кур несущих золотые яйца» среди «типа крутых бизнесменов» не бывает.
Третий пункт комментировать не буду — это не более чем ваше воображение.
Вы 25 лет кнопочки красили? Сюдя по Вашей статье - да. Я за свои 10 лет, загибайте пальцы: успел поучаствовать в разработке крупнейшей BI- системы которую использует гос сектор, цб, крупные банки и т.п.; разрабатывал софт для оборонки; разрабатывал оборудование для системы МДЛП (ведущий разработчик); реинжинирил систему учета операционных затрат для крупнейшей газово-нефтяной компании в роли тимлида)) а когда после 3 лет упорной работы над своим стартапом в области трейдинга, получив иностанные инвенстиции в десятки тысяч долларов, лишился их в 2022, вынужден был снова идти работать в найм, так как люблю свою Родину, без шуток (мог бы свалить за бугор), работу тогда, кстати, было не просто найти, а платить по финансовым обязательствам было нужно, как и семью кормить, была мысль на фронь идти, но работа меня нашла сама) Сейчас занимаюсь расчетом поглощенной дозы радиации для космических аппаратов, чтобы оборудование и космонавты себя хорошо чувствовали. Вот как то так. А вы лучше идите фильмы снимайте, там ответственность только перед инвесторами и своим кошельком. И да, сможите ли вы снять такой же фильм как раньше снимали? В начале века? Когда реальные люди ложились под реальные рельсы паравоза? Я очень сильно сомневаюсь, и не потому что не хотите, а потому что просто не дадут, а если снимите, то не монитезируете, еще и засудят
Вы 25 лет кнопочки красили?
Неужели так сложно посмотреть профиль? Если мало то вот еще. На сайте есть примеры проектов, на гитхабе - примеры кода, созданного лично мной.
То что вы описали ниже после "за свои 10 лет, загибайте пальцы: " на самом деле очень характерно для ИТ, включая итоговое печальное положение - оно у вас далеко не самое печальное но и не самое лучшее из виденных.
Но есть один важный нюанс: на вас все эти перипетии никаким образом не повлияли, верно?
Каким были таким и остались через все эти 10 лет, включая кругозор, интересы и даже уровень интеллекта. А все потому что рисков-то нет )
Ничего бы с вами инвесторы не сделали даже за просер нескольких миллионов, не то что тысяч.
Когда реальные люди ложились под реальные рельсы паравоза?
Это долгая история и уже не для формата Хабра, если кратко то нет.
Но причины тут не деньги а целый комплекс: от изменившейся физиологии до озверевшей страховой (как вы правильно заметили) и просто других ожиданий от кино.
Хмм, интересно, конечно, вы рассуждаете, то что предметные области вообще никак между собой не коррелируют вас не смущает - от BI аналитики до моделирования физических процессов? Мало того, я писал разные уровни софта, от микроконтроллеров до распределенных систем. "Ничего бы с вами инвесторы не сделали даже за просер нескольких миллионов, не то что тысяч." - я до таких факапов не опускался, ничего сказать не могу, возможно у вас есть такой опыт. В моем случае сумма факапа бы в экран калькулятора не влезла, не говоря о человеческих жизнях. По поводу кругозора - очень люблю физику (участвовал в областных олимпиадах), изобразительное искусство (10 лет художественной школы), книги, музыку(чисто для души - электрогитара), программирование мне в этом очень часто помогает, как ни странно). Что в вашем понимании развитие как личности? На мой взгляд, современный кинематограф не способствует ее развитию, ни создателей ни потребителей. Это уже давно конвейер, сюдя по количеству и качеству того, что выходит на экраны
что предметные области вообще никак между собой не коррелируют вас не смущает - от BI аналитики до моделирования физических процессов? Мало того, я писал разные уровни софта, от микроконтроллеров до распределенных систем.
А что в этом такого необычного? Ну помотало вас изрядно по разным проектам. И.. что?
Какие выводы вы вынесли из такого опыта?
Это уже давно конвейер, сюдя по количеству и качеству того, что выходит на экраны
Это расхожее мнение, на которое есть разные варианты ответов. Да, люди действительно тупеют повсеместно, но точно не из-за кино.
Риски провала при современных бюджетах блокбастеров настолько велики, что ничего кроме "сладкой газировки Marvel" снимать просто неразумно.
Так что все интересное и умное так и останется артхаусом, снятым за три копейки.
Меня не мотало, я просто успешно закрывал проект и переходил к следующему.
"Риски провала при современных бюджетах блокбастеров настолько велики, что ничего кроме "сладкой газировки Marvel" снимать просто неразумно.
Так что все интересное и умное так и останется артхаусом, снятым за три копейки"
То есть риски минимальны в обоих случаях?
Меня не мотало, я просто успешно закрывал проект и переходил к следующему.
Угу, вот только успешные проекты так просто не закрывают.
То есть риски минимальны в обоих случаях?
Конечно нет, "марвелизация" всего лишь способ (не всегда работающий) снизить риск отторжения основной аудиторией, но не более того.
По сравнению с кинопроизводством в разработке ПО никаких рисков нет вообще и совсем.
"Угу, вот только успешные проекты так просто не закрывают"
Согласен, приходилось не сладко...в каждом проекте частичка меня осталась.
"Конечно нет, "марвелизация" всего лишь способ (не всегда работающий) снизить риск отторжения основной аудиторией, но не более того."
Это работало в начале франшизы, сейчас уже все этим наелись, на первый план выходит политическая повесточка, а тут уже совсем другие бизнес модели работают, тоже кстати безрисковые, еще более безрисковые чем "марвел", и более прибыльные. Снимаем то, что заказывают. Какие тут риски? Одни оскары. Про отмывание бабла уже и говорить даже не хочется.
"По сравнению с кинопроизводством в разработке ПО никаких рисков нет вообще и совсем."
Не убедили.
Если не будет фильмов - IT останется, но если из-за сбоя IT инфраструктуры отключат свет хотя бы на пару дней, цветущая пустыня покажется раем, какие уж тут фильмы.
Если ваш фильм кассу не соберет, то этого даже никто не заметит, кроме вашего окружения и фанатов
Это работало в начале франшизы, сейчас уже все этим наелись, на первый план выходит политическая повесточка
Это честно говоря уже бессмысленно обсуждать сидя на техническом форуме в РФ, поскольку ни западные модели и бюджеты кинопроизводства ни сам Marvel к нам с вами никакого отношения не имеют.
Главная целевая аудитория кино это дети и подростки - не сильно умные и пресыщенные, зато больше всех тратящие. Marvel за много лет, путем проб и ошибок выстроил своеобразный "конвейер" для удовлетворения именно этой аудитории.
Но это не значит будто такой конвейер это что-то простое или стабильное.
Этот конвейер уже до них был) современный марвел, лукас, пиксар и т.п. заражены диснеем, дисней как форд в этом плане, только вместо машин - анимация. Откуда у детей деньги? Первые марвелы вывозили чисто на настальгии, их аудитория 30 - 40 лет у нас ( 91 год), на западе и того старше, а так же на прорыве визуальных технологий ( спасибо IT). Это хорошо заметно по звездным войнам - старшая аудитория не может уже этот сюр смореть, а новая не понимает зачем это смотреть, визуал уже не вывозит, кассы падают. Одни сиквелы, приквелы, спин-оффы ничего нового, риски никому не нужны. Этот конвейер не строили путем проб и ошибок, на нем поменяли выпускаемую продукцию в нужный момент ( появление и развитие визуальных эффектов) при этом им еще повезло с аудиторией ( те, кто были детьми в 70-90 годы). Это элементарная оценка рынка для снижения рисков и это работает. Сейчас рынок изменился и ничего из этого уже не работает, просто по инерции кидают бабки в надежде подоить еще немного, так как других вариантов у них нет
В статье почему-то не учитываются вероятности, а написана она так словно на съёмках каждый день цветет пустыня и гибнут каскадеры. Тогда как в разработке срыв сроков вполне рядовой случай.
Ну почему-же не учитываются?
Какова вероятность, что на локацию внезапно заедет караван рейверов?
50/50 - либо случится, либо нет.
Тогда как в разработке срыв сроков вполне рядовой случай
Который по большому счету ни на что не влияет и ни к чему серьезному не приводит.
Ну сорвали вы сроки — что дальше?
То, что вы не можете оценить вероятность появления рейверов на локации не говорит о том, что вероятность рейв-тусовок на закрытых пром-предприятиях равна 0.5. На самом деле, ваша команда плохо подготовилась. Кто-то не сделал запрос в том же Яндексе по новостям об интересующем объекте. Хорошо еще, что объект не сносили в этот день путем управляемого подрыва. А рейвы на заводах явление далеко не редкое: https://yandex.ru/search/?clid=11450072&text=рейв+на+заводе&l10n=ru&lr=213
То, что вы не можете оценить вероятность появления рейверов на локации не говорит о том, что вероятность рейв-тусовок на закрытых пром-предприятиях равна 0.5.
Ну вот — типичный пример мышления программиста, попытка все в мире свести к логике и правилам. Слово «подпольная» в описании вечеринки вы разумеется пропустили, ведь это не попадает в вашу картину мира, правда?
Про подпольную вечеринку люди узнали по стукам из под пола? Может быть, если поискать, то анонс какой-то был? Нет, естественно, существует вероятность того, что это была совсем закрытая и законспирированная вечеринка только для своих, но с таким же успехом в офис стартапа может нагрянуть маски-шоу и повязать всех разработчиков по подозрению в хакерстве. Или совладельцы фирмы разойдутся во мнениях и один из них захватит офис вместе с серверами проекта и они будут месяц бодаться, а потом делить активы и команду (это из моего личного опыта).
Про подпольную вечеринку люди узнали по стукам из под пола?
Про закрытую военным область и ПВО на второй день съемок полагаю надо было заранее уточнять у ФСБ следуя вашей логике?
А чтобы пройти по улице без риска быть сбитым самокатчиком, видимо надо заранее собрать досье и медкарты для каждого жителя района, вместе с маршрутами передвижения самых ярких шизов.
Подозреваю, что, если закрытие было плановым, его вполне могли анонсировать по общедоступным каналам. Еще подозреваю, что войсковые учения не проводят в случайном месте, для этого есть полигоны. Если съемки возле полигона, стоит закладывать риск того, что в день съемки там будут учения.
Конечно, если в экстренном порядке отбивались от налета беспилотников, такое предсказать сложно, но так же точно из-за беспилотников могут отключить интернет в офисе перед коммитом-деплоем в облако, не вижу, чем кино рискованее ИТ.
Спасибо! Статья получилась интересной, хотя и спорной. На мой взгляд, автор всё-таки перегибает как в плане переоценки рисков кинопроизводства (кино таки снимают и снимают очень много), так и в плане недооценки рисков разработки ПО (тут в комментах уже писали про ПО для критически важных областей).
Но у меня есть отдельный вопрос к автору, особенно к следующему пассажу:
провальный фильм может запросто загубить карьеру главных актеров, режиссера и сценариста.
Когда смотришь некоторые киноподелия, то удивляешься безмерно - неужели ни режиссёр, ни сценарист, ни актёры не видели сразу, что у них получается чудовищный говношлак? Ну ладно, бог с ними, с людьми творческими - они, бывает, немножко ослеплены отсветами собственного ЧСВ, но продюсеры? Это же люди, которые, грубо говоря, про деньги. Как они допускают выход полностью провальных фильмов?
так и в плане недооценки рисков разработки ПО
Наверное стоит пояснить как вообще появилась эта статья.
Дело в том что я много лет занимаюсь заказной разработкой и регулярно взаимодействую с людьми далекими от ИТ. и компьютеров .
И раз за разом слушаю истории реального превозмогания — как люди годами выстраивают работающие предприятия, с какими трудностями выбивают кредиты и платежи. Как их обманывают работники (например сливая бензин), как менеджеры пускают заказы налево, как лютует налоговая и надзорные органы.
А потом эти же люди спрашивают о возможных рисках при разработке или внедрении ИТ-проекта. И я каждый раз оказываюсь в ситуации, когда юнга должен осторожно пояснять морскому волку, прошедшему экватор, что в ИТ все несколько проще чем кажется.
неужели ни режиссёр, ни сценарист, ни актёры не видели сразу, что у них получается чудовищный говношлак?
Съемка растянута по времени и нет какого-то одного человека, который сразу в один момент времени видит всю картину и тем более может сказать шлак получится или нет.
Поэтому есть тестовые показы, до премьеры и бывает так что половину переснимают если тестовый показ провалился.
Еще есть вкусовщина и далеко не всегда то что нравится широкой аудитории понравится утонченным зрителям.
Много нюансов короче.
Приветствую. У мня после этой статьи так подгорел стул, что я зарегистрировался для написания комментария.
То есть, вы данной статьёй опустили всех IT специалистов, инженеров ниже уровня кинематографа?!!
Вы действительно считаете что человек кривляющийся на экране более велик чем инженер?
Все ваши доводы надуманы, в любом случае всё упирается в финансы и время, что в кино что в IT, ваши примеры не исключение я могу подобные примеры и из IT привести: как вам меняющееся ТЗ ближе к концу проекта, а изменение конфигурации датчиков на объекте хотя в ТЗ было по другому, а наладка без сна и отдыха 72ч. (я работаю в сфере АСУТП но думаю что любой IT инженер накидает вам проблем из своей сферы без особых размышлений)
Кстати просматривая современные фильмы приходит понимание, что инженеры там рядом не стояли.
И не надо говорить про творчество любой инженер по этому моменту весь кинематограф за пояс заткнёт: ему надо не только придумать решение проблемы но и оно должно работать а не просто быть!
Спасибо за внимание, извините за грубость.
Спасибо за внимание, извините за грубость.
Это можно сказать девиз ИТ-индустрии )
Все ваши доводы надуманы, в любом случае всё упирается в финансы и время, что в кино что в IT,
Я правильно понимаю, что нигде кроме ИТ вы не работали? И даже студенческой практики не было где-нибудь в Макдаке? Чтож, отсюда и столь специфический взгляд на мир.
И нет, далеко не все упирается в деньги и время, это сильно упрощенная картина мира.
Крайне рекомендую пообщаться поближе с обычными людьми, далекими от ИТ — для возвращения в реальность, внезапно окажется что жизнь несколько сложнее отладки за монитором.
Добавлю конкретики:
как вам меняющееся ТЗ ближе к концу проекта,
Вот допустим строят жилой дом, если стройка по какой‑то причине будет заморожена хотя‑бы на полгода‑год (в зависимости от локации) — с очень высокой вероятностью весь дом пойдет под снос. Если дом достроят, застеклят, подведут коммуникации но не примут в эксплуатацию — его все это время придется обслуживать за свой счет. Легко может пройти несколько лет такой псевдоэксплуатации за свой счет до тех пор пока не утрясут все нюансы.
Любое разбитое окно зимой может привести к сильным потерям тепла и лопнувшей трубе, замена которой мягко говоря недешевое удовольствие.
Теперь сравните такие риски с родным ИТ и какими-то там доработками в ТЗ )
немного не правильно, моя сфера АСУТП а пришёл я к асушке из КИПа а в КИП из токарки (немного странно но так и есть), так что ручками работать тоже умею =), а вот по поводу общения с обычными людьми тут проблема, мне трудно общается с людьми не понимающими логику.
Ок, отлично. Сколько стоит станок представляете? Каких усилий стоит развернуть и наладить производство: подготовить место, возвести конструкции, подключить электричество — на производстве а не дома?
Каких усилий стоит доставить сами станки и запустить производство?
Как интересно с таким опытом вы все еще можете заикаться о неких рисках в ИТ? Как?
в том то и дело что знаю, одна ошибка в программе управления станка и при запуске он просто самоуничтожится начав пилить сам себя.
как я уже ниже написал тяжесть ошибки зависит от последствий ITшник тоже может совершить ошибку на много миллионов зелёных рублей и такие прецеденты имеются
в том то и дело что знаю, одна ошибка в программе управления станка и при запуске он просто самоуничтожится начав пилить сам себя.
Если знаете о таком, тогда должны знать и про защитную автоматику и про пороговые значения, которые не позволят просто так уйти в опасный режим.
как я уже ниже написал тяжесть ошибки зависит от последствий ITшник тоже может совершить ошибку на много миллионов зелёных рублей и такие прецеденты имеются
А почему вы сводите все к деньгам? Человеческая жизнь для вас ничего не стоит?
Еще добавлю, что айтишник конечно может «совершить ошибку на много миллионов зелёных рублей», но только отвечать за нее в подавляющем количестве случаев — не будет.
Если вы например будучи главным технологом на пищевом производстве пропустите несвежий бутерброд и потребители отравятся — будет ваша персональная ответственность, вплоть до уголовки.
Точно также отвечают главврачи за каждого умершего пациента, главные инженеры — за сбой производства и так далее.
Вдумайтесь: в ИТ до сих пор не существует прецентов на запрет занятия профессиональной деятельностью, которые есть наверное уже во всех остальных областях человеческой деятельности.
Если знаете о таком, тогда должны знать и про защитную автоматику и про пороговые значения, которые не позволят просто так уйти в опасный режим.
как раз там и может быть ошибка, даже модули защиты например REER тоже требуют программы.
Если вы например будучи главным технологом на пищевом производстве пропустите несвежий бутерброд и потребители отравятся — будет ваша персональная ответственность, вплоть до уголовки.
Если во время наладки произойдёт ЧП то ответственным будет наладчик, по этому и приходится 72ч практически без сна от оборудования не отходить.
как раз там и может быть ошибка, даже модули защиты например REER тоже требуют программы.
Ну да да, давайте тогда сразу «ошибки при проектировании атомного реактора» обсуждать и чернобыльскую катастрофу.
Вы же прекрасно понимаете, что риск ошибки тут — на уровне погрешности, так зачем приводить это в пример?
Если во время наладки произойдёт ЧП то ответственным будет наладчик
но не разработчик, который писал прошивку в теплом офисе, верно ведь?
Ну да да, давайте тогда сразу «ошибки при проектировании атомного реактора» обсуждать и чернобыльскую катастрофу.
А это специально сделали?
Вы же прекрасно понимаете, что риск ошибки тут — на уровне погрешности, так зачем приводить это в пример?
любая ошибка это погрешность, но в зависимости от возможных последствий менеджер проекта должен контролировать возможность появления ошибок.
очень интерстно вы от кино к дому переешли
Ошибок с домом может быть много может менеджер не уследил за законами и актами(это не большая проблема решить), может инженеры допустили просчёт, а может и ITшники (безопасность не справилась и всю базу документов зашифровали вороги злые) данный пример как раз из сферы инженерной
А вообще степень тяжести ошибки всегда зависит от последствий и простой дворник может дом спалить.
очень интерстно вы от кино к дому переешли
Киноиндустрия просто небанальный пример, но конечно не единственный.
Ошибок с домом может быть много
Суть не в ошибках как таковых а в том что постройка дома это реальный процесс, ограниченный физическими законами, в отличие от разработки ПО, которая не ограничена ничем кроме фантазии автора.
Суть не в ошибках как таковых а в том что постройка дома это реальный процесс, ограниченный физическими законами, в отличие от разработки ПО, которая не ограничена ничем кроме фантазии автора.
разработка бывает разной, если это ПО для станка она ограничена физикой, ели для бухгалтерии то актами по налогам и математикой, и т.д. а ещё есть ПО для имитации физических процессов. В программировании много ограничений.
Что случится если разработку поставить на паузу и вернуться к ней через пару-тройку-десяток лет? Это как-то ухудшит ее качество?
А вы говорите "ограничена физикой".
с большой вероятностью проект устареет и его начнут заново писать.
Что устареет? Биты и байты?
Ладно еще когда речь идет про UI/UX и клиентский опыт (и то не всегда), но у вас же про АСУ и железо.
Что тут-то может устареть? Тем более за столь короткий срок.
Скорее всего, она не скомпилируется.
Сами байты не меняются, но программное и аппаратное окружение эволюционирует.
Про риски разработки ПО