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