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