×

«Два года разработки» x «$1,7млн» = иск в суд на бесполезное ПО

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Lawsuit claims Epicor’s two-year effort delivered ’useless’ software.

Суть иска: ERP (enterprise resource planning) software vendor failed to deliver a satisfactory system after years of effort and significant cost overruns.
--------------------
В сентябре 2008 Major Brands начали подыскивать систему, которая заменила бы всё еще работающую, still «functioning in an acceptable fashion,» созданную около 20 лет назад. Через год, в сентябре 2009, Major Brands подписали контракт с компанией Epicor.

Разработка заняла два года и 1млн. 170тыс. долларов. При этом, вопреки заверениям Epicor, новая система V9 was «running so slowly that it was not going to be suitable for use». Major Brands проводит закупку нового оборудования примерно на 100тыс. долларов. После этого была еще одна попытка запустить новую систему, однако эта попытка «was a complete and absolute failure».

Те же самые функции, которые выполнялись за секунды на старой системе занимали минуты на новой V9.

В апреле 2011 Major Brands выплачивает разработчику еще $125,000.

После очередных неудачных попыток Epicor заявляет «new go-live date of mid-2015 and more than $1 million in additional costs on top of the original contracts». Major Brands делает случай публичным и подает в суд на Epicor.

Этот случай самый последний из подобных, «but there seems to be a key difference between it and others since it largely comes down to the software’s speed».

Чаще всего, говорит Michael Krigsman, управляющий IT-консалтинговой фирмой, иски подают аргументируя «mismatched expectations» в поставляемом ПО. Здесь же случай сильно отличается от других.

Источник: [ www.pcworld.com/...​red_useless_software.html ]

Что-то не так с программированием? Регресс или прогресс через 20 лет, если для той же задачи получился полный провал? Для неискушенной публики прогресс в программировании бодро отрапортовали. Но видно, что однозначный прогресс наблюдается только в суммах, запрашиваемых на разработку, и в широте расставляемых рук при описании чудесных характеристик нового ПО.
(см. также не менее известный и более дорогостоящий провал: Крах «Фобоса» был запрограммирован www.ria.ru/...​s/20120131/553200428.html)

Интересно было бы угадать, на каком языке и в какой парадигме написали V9. И также, что чувствуют при таком оглушительном провале разработчики?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Что-то я читаю этот материал, и мне совсем не жалко Major Brands. Проект внедрения завален, но проект внедрения ЕРП — это большой риск для той стороны, которая этот проект затеяла. Ну сыграл риск, стороны недооценили сложность или переоценили собственные силы. Заказчик хоть чуть денег пытается вернуть через суд.

Нормальное дело, имхо, ничего экстраординарного. Почему сразу вывод, что у подрядчика руки кривые? Я ни одного заваленного проекта не помню, где виноват на 100% был бы вендор, особенно если у него до этого было удачных 20 проектов, а этот — 21 — неудачный. Похоже, заказчики тоже хорошо руки приложили к провалу, поэтому-то их и не жалко совсем.

Я в подобном проекте участвовал на стороне заказчика. Длился он на пару лет дольше, а по деньгам где-то на порядок дороже.

У заказчика было:
1) нормально работающее, развивающееся с 99 года ПО;
2) мой отдел, в котором IT-специалисты совместно с предметными специалистами занимались глубоким изучением, анализом и обобщением предметной области;

3) возможность выдавать разработчику не только требования, но и рабочие макеты (прототипы) тех или иных подсистем программы (не более 2-3 дней на каждый прототип), разработку которых разработчик объявлял малореальной по времени/затратам.

Разработчик — одна из ведущих украинских компаний разработчиков ПО. Использовали .NET, интерфейс пользователя — WPF.

Необходимость разработки нового ПО новой компанией была чисто «политическая».

О стороне заказчика красноречиво говорит тот факт, что пока у руководителя проекта от разработчика не было политической установки руководства «свалить проблемы на заказчика», после очередного рабочего прототипа он сказал, что с таким уникальным (в хорошем смысле) заказчиком ему ещё не приходилось работать.

Через пару месяцев после начала проекта, оценив принятую разработчиками архитектуру, я пришел к выводу, что выбран неверный путь — система или вообще не получится, или будет ужасающе неповоротливой и дорогой.

По этому поводу мной был поднят шум, дошел до высшего руководства у нас и у разработчика. Шум привлек даже интерес владельцев компании-разработчика. Собрали совещание на высшем уровне по обсуждению вопроса. Поскольку система пока только на уровне архитектуры, то с моей стороны только эмпирические оценки, интуиция и опыт — померять и выдать в цифирном виде нечего...

У разработчика клоунада: директор поднимает поочередно специалиста по СУБД, архитектора, тимлида, руководителя проекта. Каждый торжественно клянется, что архитектура классная, через 2 года всё будет ок. По результатам совещания представитель владельца компании посмотрел на меня как на клоуна, поднявшего истерику на пустом месте...

Пришлось подчиниться коллегиальному решению и работать в имеющихся политических рамках.

В итоге в пилотную эксплуатацию внедрять начали систему, которая на момент начала внедрения не имела и 20% функционала старой, а требования к железу на порядок выше (для заказчика с десятками тыс. компов по всей Украине это весьма критично).

Тут тоже было много интересных событий, но опустим их, как лишние детали. В общем, загнулась система, не пошла.

Я уходил оттуда, когда еще трепыхались в попытках доделать и довести.

Директор компании-разработчика на прощанье заявил:
— Это ты виноват, что у нас не получилось.
— Ну нихера себе! Когда все еще начиналось, при всеобщем одобрямсе, я единственный здесь, кто бегал, уговаривал, кричал, орал, что делается херня. Меня же тогда выставили клоуном и не послушали. И это я виноват?!

— Да ты. Надо было громче кричать, чтобы мы услышали...

Занавес. После этого полгода я просто отдыхал и не имел желания искать новую работу.

от и еще один человек не читал работ паркинсона по бюрократии, в моем (подобном) случае я просто развернулся и ушел сразу, сэкономив нервы и время себе

еще один человек, который знает, что другой не знает :)

Представьте себе, читал, что подтверждается моей заметкой о маразматическом планировании.

понимаете, я не хотел вас обидеть, но судя по рассказанной «истории» вы нарушили почти все бюрократические законы , совершили акт карьерного самоубийства и расплатились своими нервами и временем.

Я — редкий случай работника, который в силу своей подготовки, опыта и знаний может занимать руководящие должности любого уровня, но не имеет никакого желания заниматься карьерой. По двум причинам: в качестве руководителя реализовал себя давно и достаточно успешно, и это уже не интересно; имею достаточно личных ресурсов, позволяющих в качестве наемного специалиста чувствовать себя абсолютно независимо от сиюминутных прихотей начальства.

Что это дает? Хоть кто-то в ответ на указание шефа должен иметь возможность вместо того, чтобы «работать работу» (выполнять бесполезную работу), обоснованно сказать «мы не будем это делать» или «мы это сделаем по-другому». Это иногда может быть много полезнее для результата, чем несколько десятков исполнителей, которые тупо роют тут, потому что сказали рыть тут.

Поэтому бюрократические законы и правила дрес-кода на меня не распространяются.

Поэтому бюрократические законы и правила дрес-кода на меня не распространяются.

Занавес. После этого полгода я просто отдыхал и не имел желания искать новую работу.

эти две цитаты противоречат друг другу , кроме того, бюрократические законы действуют везде, где взаимодействуют люди, только безлюдный остров может помочь их избежать :)
но неважно , я не психолог, а вы сам себе злобный буратина

извините, если шо

Я говорил о бюрократических законах в свете начатой Вами же темы Паркинсона. Или Вы сами не читали его книги или, может быть, не поняли?

А цитаты не противоречат друг-другу, т.к. не имеют никакой взаимосвязи.

Как по мне (с моей колокольни) ответственность всегда на руководстве компании, сейлзах, менеджере проекта. И в указанной очередности. Руководство всех подталкивает к заключению контракта и исполнению корпоративного стиля ведения проекта, оно всегда верит что «мы самые самые», и чем больше компания, тем больше самомнение. Сейлзам вообще все пофиг — продал, процент получил, побежал продавать дальше. Манагер проекта — много сложных задач по коммуникации с всеми и планировании, можно очень легко напортачить.

Что касается разработчиков и выбора языка — задача руководства подобрать команду, и найти людей способных принимать правильные решения

скорее всего, полное отсутствие контроля и отказ от ответственности со стороны заказчика, очковтирательство со стороны исполнителя. т.е. организационные проблемы. технические решения (платформа, язык, парадигма), наверное, не играли никакой роли

советы от системного интегратора «Как избежать потери денег и времени»
m.forbes.ru/...le.php?id=49040

советы не по случаю с Major Brands, поскольку в основе их претензий неприемлимое быстродействие ПО, но всё же.

Как сразу видно кто кого не любит. Информации ноль но каждый додумал причину провала и обвинил в ней своих личных «врагов». У кого-то это зависть и 23 летние, у кого-то менеджеры, у кого-то абстрактные фабрики, глупые архитекторы, жирные корпорации, новые языки программирования, портативные устройства.

Отличный психологический, кстати, ход. Сразу видно у кого что болит

функции, которые выполнялись за секунды

DCOM

занимали минуты на новой V9

Remoting (или веб-сервисы)

:)

Интересно, я что, один тут решил почитать источник (по ссылке выше)? В оригинальном тексте нигде не говорится о написании новой ERP:

Major Brands paid Epicor an initial fee of about US$500,000 for software license and support, and roughly $670,000 for implementation services.

Теперь ценник больше похож на правду и, в принципе, вопрос стоит немного по-другому: где был CIO Major Brands, когда выбирал вендора? Решил сэкономить на SAP R/3, теперь пусть возится с эпикоровским глюкалом (я их еще по Scala помню, судя по всему, ничего с тех пор не поменялось).

Короче, сенсации не получилось, расходимся.

Да и ценник то копеечный для таких проектов. Как тут не вспомнить Связьинвест

www.cnews.ru/...09/01/16/334604

Да я не спорю, что бюджет мелкий, но для аудита маленькой компании и внедрения типового решения без особой доработки — может быть. Меня изначальный месседж насчет «разработки ERP за $1M» очень смутил.

Читаю описание проекта для Связьинвеста и вздрагиваю

Пусть теперь запихнут свою ERP в облака. ;-)

В индустрии очень не хватает подобной информации.
Ашманов про нечто похожее с Рамблером писал.
История провалов и неудач (которых over9000) является в разы более ценной чем истории эпиквинов (которых сотни).
Если бы были технические подробности то было бы просто замечательно.

И наконец разрешились бы вопросы про десять слоёв абстрактных фабрик, agile, спагетти и 23 летних сеньёров.*

*Конечно, не разрешились бы.

И наконец разрешились бы вопросы про десять слоёв абстрактных фабрик, agile, спагетти и 23 летних сеньёров.*

Десять слоев абстрактных фабрик спагетти. Все четко, все аджайл.

Вы говорите так словно настоящих 23-трехлетних синьоров с опытом работы >= 4 года не бывает.

Канонически «Вы так говорите как будто это что-то плохое»

Я упомянул мем «23-х летние сенъёры» ка предмет диспута, без оценок с моей стороны, также как agile или «спагетти код который работает»

Да какая «подобная информация»? Клиент судится с вендором за неудавшееся внедрение? В айти фэйлятся проекты — омг, неужели? (trollface.jpg)

Информация о фейлах и конкретных причинах. Понимаю, что в айти такого не бывает на самом деле, но чисто гипотетически хотелось бы знать.

История провалов и неудач ...

Это будет похоже на рассказы, как внедряли невнедряемое и не внедрили. Железобетонная закономерность.

Интересно, только у меня одного складывается впечатление, что сижу зрителем спектакля перед сценой IT, где разыгрывается комедия? :) Надувается огромный пузырь, как когда-то с тюльпанами в Голландии. Ценности, достижения (особенно), цели, методы и парадигмы программирования — комичны.

Вот видео. То, что видите (покажите далеким от IT знакомым, спутают с Айфоном), работает на Atmel Atmega32. 8-битовый процессор, (прописью: 16 Мегагерц. М-Е-Г-А-Г-Е-Р-Ц), 2,5 KB ОЗУ, 32 KB ПЗУ, 1 KB (EEPROM). Это, еще раз АХТУНГ! килобайты и мегагерцы. Эй, Эплл, говорите, что тяжело и по передовому работали, создали чудо техники и никого ваш главный маркетолог не разводил? :)))

у Major Brands и Epicor должен быть приз за лучшее исполнение ролей в этом спектакле. Сценка исполнялась на устаревшем оборудовании и устаревшем ПО, а затем из-за кулис появился продавец с новым ПО, здесь-то и началось самое смешное...

Всё состояние IT скорее коматозное. Дот-комы в IT в анамнез можно не включать, это мелкие прыщики.

Не готов поддержать беседу.о частоте и битах.
А когда я не готов я апеллирую к рынку. И при отрицании мирового заговора можно предположить, что на видео показан трюк способный удивить обывателя, но не более, и который в реальной жизни «потребует» 1ГГц, и 2 ГБ ОЗУ и будет стоить как китайский айфон.

Не стоит забывать, что себестоимость, в современном мире, процессора гораздо ниже стоимости логистики и человеко-часа. Например у меня разбился экран на планшете — он стоит 6 долларов (около 50 грн), но дешевле 100 долларов (800 грн) в Украине я его поменять не могу. Я также не могу его купить за 50 грн. Причём стоит учитывать что 50 грн стоит экран у продавцов. Подозреваю заводская себестоимость ещё в два раза меньше. И тут барабанная дроб и фейерверк — Вы или кто-нибудь другой при всём желании не сможете осчастливить человечество экранами по 50 грн если конечно не будет доплачивать логистической цепочке, рекламщикам, таможенникам из своего кармана. Так устроен рынок и человеческое общество.

Это я говорю к тому, что разница в стоимости процессора на 16МГц и на 700Мгц скорее всего составляет 10 центов. Какой смысл ставить 16 когда конкуренты ставят 700 и пишут это крупными буквами.

Насколько я помню параметры своей первой 386 то там было около 40Мб ПЗУ и 33Мгц тактовой частоты. На нём летали форточки 3.1 игрался Warcraft и F16 Печатался Office и ещё куча софта в далёком 1995-ом

если бы вы сходили на rossum.posterous.com вы бы так не истерили.
на самом деле там показывается не текст, а скролинг raw bmp со ссылками как ofset
я представляю как будут истерить будущие «исследователи», когда увидят аналоговый телевизор (особенно в сравнении с iptv)

да ладно?
а в README на github.com/...umur/microtouch заявлено о поддержке ebook.

вы невнимательно читали:

The transcoding tool (epubgrider) reads standard epub format files and creates ’.epb’ files readable by the microtouch code. The transcoder has a rudimentary layout engine that formats and paginates the html content, mapping font sizes and styles to those appropriate for viewing on a 320×240 screen. <b>It records and stores hyperlinks within the html and resizes and transcodes images from jpg/png/gif etc to a raw 16bit RGB format</b>. The transcoder then packages text/images/links/fonts etc with a spatial index in a ’.epb’ file.

ну из описания вполне ясно что нет прямой поддержки epub а из него генерится некий байтовый поток для оптимизации рендеринга (т.е. фактически офлайновый рендеринг, а девайс только показывает его)

из спек видно что памяти все-таки 28 кб для прог, с возможностью paging и все такое (а данные читаются с microsd)

в общем, не вижу ничего сверх прям навороченного, синклер был похуже по качеству картинки и не risc и без поддержки microSD но при этом позволял вполне себе аналогичные вещи

тем не менее, это не «скроллинг raw bmp» все-таки. а конвертация нужна для раскладывания под экран 320×240. автор пишет, что мог бы сделать и прямую поддержку, но не уложился бы в 2,5кб ОЗУ (28 кб — это ПЗУ). это если мы о девайсе.

а если мы потроллить, то какой из подходов привлекает больше: «сперва добейся» или «ты просто завидуешь!!!!1111»?

вы можете поискать знакомых однокристальщиков, которым вы доверяете, и спросить у них.
в решении из экстроординарного, разве что использование тачскрина (обычно используют гуй попроще — можете посмотреть на него на стиралке или микроволновке) ну и применение :)

с точки зрения вычислительной мощности\фич ничего сверхсовершенного не видно — промышленный atmel используется для простых задач

синклер тоже был чуть сложнее калькулятора. если простые вещи способны дарить столько кайфа — я ЗА простые вещи!

Кого из современных молодых гиков этот девайс вообще заинтересует? Написано не на Джаве, всё, полный отстой... А уж отсутствие гигагерц и гигабайт это ж позор какой-то :)

Но суть примера с девайсом проста: для незаметного времени отклика на самом деле из ресурсов достаточно килобайт памяти, и энное количество тактов, ну и конечно, для распределения этих вычислительных ресурсов надо мозгов вместо соломы.

Epicor со своими минутными лагами на фоне этого девайса выглядят блондинками.

А вообще интересно взять их код и сделать по нему

find . -type f -name ’*.java’ -exec grep -inH ’sleep’ ’{}’ \;

И случай далеко не единичный, на польской ЖД их 20-летнюю систему, работавшую под DOS еще, заменили на нечто блестяще-свистяще-пердящее, заточенное под тачскрин (и вид кнопок как у Motif, я это видел и прослезился аж) во все поля, даже если на клавиатуре удобнее. Терминалы — как в «Пузатой хате» на кассе.

Так вот в 2010 году был просто шквал негодования в прессе по поводу жутчайших тормозов в сравнении со старым, теплым, ламповым, проверенным. Тем более, что в случае успеха результат не отличается.

find . -type f -name ’*.java’ -print0|xargs −0 -n6 -P6 sed -i ’s/\([^a-z]\)sleep\s*([^)]*)/\1/ig’

Что-то концы с концами не сходятся.

1) У Epicor есть своя ERP — iScala (раньше была Scala — тихий ужас вообще)

2) Бюджет вообще микроскопический для ERP, внедрения готовых систем обычно дороже обходятся (конкретно Epicor берет за консалтинг от 100 баксов в час, если память не изменяет)

Было бы интересно услышать от инсайдеров с любой из сторон детали проекта.

Непонятно нахрена при наличии кучи готовых ERP нужно было писать новую с нуля...

На осиливание существующих, их конфигурацию и допиливание под хотелки заказчика нужно время, усидчивость, желание ботанить скучнейшую хренотень и достаточно смирения, чтобы не надо было постоянно долбать себя на тему «успокойся, не спеши, не изобретай велосипед, наверняка ведь есть что-то на эту тему готовое, просто ты еще об этом не знаешь». Вы много видели эмоционально уравновешенных программистов, способных на такое?

Тот же фактор, из-за которого проекты переписывают с нуля вместо рефакторить.

Ну обычно такое решение принимается не программистами, и аргументы «да тут все херня, за месяц новую напишем» не канают.
Я просто представить не мог, что кому-то может придти в голову писать ERP под заказчика с нуля. ИМХО это сродни тому, чтобы писать под заказчика свою ОС или СУБД.
И если заказчик на это повелся, то сам виноват...
И кстати бюджет в 1.7 ляма и на внедрение готовой ERP — это не что-то огромное, а на написание новой так вообще...

Менеджеров тоже можно убедить, им, вопреки устоявшемуся мнению, с правильной подачей можно продать снизу что угодно, какой угодно шлак. Возможно, разработчики нашли ключик к его сердцу, и все заверте...

Ну если писалось действительно с нуля (до сих пор не верится), то идея была: «Ща мы за их деньги напишем, а потом сделаем из этого коробку и будем толкать»

Есть такое. Но, обычно, более успешные продукты тоже так делались: за чьи-то деньги и под чьи-то хотелки, а потом в коробку. В чем же разница? Может, кто-то колонку толкнет, а?

Я просто представить не мог, что кому-то может придти в голову писать ERP под заказчика с нуля.

А я представить не могу, чтобы разработчики нового автомобиля запихивали под капот устаревшие детали, сделанные в Индии, да еще допиленные по ходу напильником и с кучей переходников :)

Реюзабл относится в инженерной матриальной промышленности только к инструментарию. Даже поганенький насос будут делать из новых отливок и новых двигателей, ну разве что болты и гайки будут унифицированы (и то, не по длине общей, не по длине резьбовой части, и не по размерам шайб и головок, а только под... тадам-м-м.... ИНСТРУМЕНТ).

Epicor похоже, именно такую гаражную самоделку из скомпонованных запчастей и выкатило.

А я представить не могу, чтобы разработчики нового автомобиля запихивали под капот устаревшие детали, сделанные в Индии, да еще допиленные по ходу напильником и с кучей переходников :)

А вы под капотик БАЗа или ЛАЗа нового загляните при случае. :) Очень вероятно, что оно там так и есть. А если и нет, то не приведи Аллах какому-то гению от машиностроения прочитать этот комментарий, это же ж ИДЕЯ.

С другой стороны, когда делают новую модель автомобиля не изобретают заново колесо и двигатель внутреннего сгорания. Берут уже давно придуманные базовые вещи, допиливают под нужды, улучшают и собирают автомобиль.

А я представить не могу, чтобы разработчики нового автомобиля запихивали под капот устаревшие детали, сделанные в Индии, да еще допиленные по ходу напильником и с кучей переходников :)

Не сравнивайте Божий дар с яичницей. Разработка и выпуск на рынок нового серийного продукта — это одно. Но когда приходит заказчик и хочет купить самосвал, обычно ему не предлагают разработать абсолютно новый концепт, а просто продают самосвал.

Просто у компании-разработчика руки из *опы растут. Наверняка там всем заправляют сладкоречивые манагеры, которые умеют уболтать клиента, но ничего не понимают в разработке. А разработчиков небось меняют как перчатки.

Короче общая беда капитализма. Покупают у того, кто умеет убалтывать, рекламировать, убеждать, красиво врать а не у того, кто знает свое дело, но скромно молчит в сторонке.

У SAP таких исков каждый год по нескольку штук. С ERP системами очень много зависит от менеджмента. Если на начальном этапе провтыкали оговорить(прописать все моменты), то внедрение будет бесконечным. О проблемах внедрений можно целые книги писать. Очень часто проблема и не в исполнителе, а в головах ключевых юзеров заказчика.

ссылка на тупых юзеров некорректна, если претензии к скорости отклика.

А вообще, если юзер желает одну большую красную кнопку на весь экран, в которую он будет тыкать своими жирными пальцами (спасибо за эту восхитительную по эстетичности моду С.Джобсу) то так и нужно делать.

Но время отклика — максимально одна-две десятых секунды. Это значение абсолютно, и устанавливается психофизическими особенностями человека. Архитектор ПО обязан знать все интерфейсы, как у процессора, так и у человека.

Есть нюансы. Предположим изначально был оговорен один функционал, после его реализации юзвери почесали затылок и сказали «а, нет, давайте сделаем иначе». И начинается перепиливание кода. На какой-то из итераций большая часть изначальной архитектуры можно выбрасывать, но на это уже нет ни времени ни бюджета. И начинаются костыли.

В общем, не зная их ситуацию и причины, сложно судить почему так получилось.
З.Ы. Сужу по своему опыту внедрения.

Что-то не так с программированием?

Да все так с программированием. Это концепция ERP в корне кривая. За все время существования ERP, 70% внедрений готовых продуктов (!!!) окончились неудачей. Чего вы хотели от разработки новой? :)

Это концепция ERP в корне кривая

К случаю с Epicor оценка собственно задачи ERP — лишняя. Какая именно задача решалась поставщиком ПО, уже не так важно. Претензии выставлены по неприемлимой скорости работы ПО. Значит здесь обнажился чисто технический провал.

Разработка заняла два года и 1млн. 170тыс. долларов.

невеликий проект для 8 розробників і одного ПМа.

прошу озвучить калькуляцию!

Аренда помещения, техника, налоги, мед страховка..
кроме того для амеров это не такая «кошмарная» сумма как для нас

Осталось найти подтверждение, что проект писался в гамериках.

У них на сайте офисов по миру — вагон с тележкой.

вопрос не в «кошмарности». интересует почему именно 8 разработчиков и один ПМ. думается, что систему они писали не «с нуля». и предварительно кто-то должен был написать ТЗ «заточенное» под нужды «Major Brands», а в процессе разработки взаимодействовать с клиентом реагируя на любые изменения. не сваливать же эти задачи на ПМа? а кто разрабатывал рекомендации по приобретению нового оборудования? программисты? или «Major Brands» по своему разумению закупал «железо»? и если со всеми сопутствующими разработке задачами справилось 9 человек, то какие же у них были З/П?

Дело не в языке, и даже не в разработчиках..я думаю дело в менеджменте компании и технологии используемой для управления процессом разработки. Кстати, еще один возможный плюс для Scrum. Там такая ситуация, скорее всего, не возникла бы,- так как в процесс разработки, на всех промежуточных этапах, были бы вовлечены все, и заказчик в том числе.

Скорее всего, менеджмент виноват только в той части, в которой им принималось решение по выбору (некомпетентного?) архитектора ПО.

Не только. А как же сам процесс разработки? Что, выбрали архитектора и все?

Интересно было бы угадать, на каком языке и в какой парадигме написали V9. И также, что чувствуют при таком оглушительном провале разработчики?
Розробники мало що чувствують, як їм казали, так вони і кодили.
Може відчувати свою “геніальність” або “кривизну мозгів” спеціаліст, може бути так, що все замикається на інтуіції та рішеннях, прийнятих всього-навсього однією людиною, яка відчула/побачила в системі вузькі місця і заклала таке архітектурне рішення, коли ці вузькі місця відносно легко обходяться а система легко розширюється.
І справа не в мові і парадигмі, а в тому як архітектор бачить на етапі проектування.
А це все ж більше мистецтво, чим інженерія.
Скорее всего, менеджмент виноват только в той части, в которой им принималось решение по выбору (некомпетентного?) архитектора ПО.
Виходить що так.
Там такая ситуация, скорее всего, не возникла бы,- так как в процесс разработки, на всех промежуточных этапах, были бы вовлечены все, и заказчик в том числе.
І як замовник може вплинути на архітектуру, якщо його цікавить бюджет, сроки, якість?
Хіба що система робиться по його образу і подобію, на аутсосрс проекті працюють бібізянки, яким дяді із закордону тицяють пальцем, де, що і як писати.

У некоторых развивается "guilty programmer syndrom"/"синдром виноватого программиста" после таких проектов. Особенно когда на очередном интеревью: «а так это вы работали над ERP в Epicor?» =))

И правильно, что синдром развивается, это в человеческой природе.

Бюджет заказа распилило руководство, а позором накроет весь коллектив.

А це все ж більше мистецтво, чим інженерія.

:) а что с художников взять?

И да, заказчик не НАСА, где компетентные специалисты точно найдутся, а оптовый продавец спиртных напитков Major Brands. Повлиять на архитектурное решение ПО он может только из самодурства...

Инженер всегда отвечает на вопросы количественными оценками, показывая расчеты, и расчеты эти обосновывая. Художник будет давать оценки в терминах: модно, круто, последний писк...

Архитектор ПО это рокет сайенс, а не модный дизайнер. Разве нет?

Архитектор ПО это рокет сайенс, а не модный дизайнер. Разве нет?

Сайенс, це є теорія + експеремент.
Тому як економіка, так і математика як і програмування не є наукою.

Розробка ПО в одних випадках ремесло, в інших інженерія, іноді мистецтво.

а что с художников взять?

«Не бийте художника, він так бачить!»

Проблема не в том, что какой то функционал делается минуту, и не в архитектуре ПО, и не в квалификации исполнителей, а в эффективности (для заказчика) эксплуатации разрабатываемой системы управления. По своему опыту могу сказать что фейл в том, что дело это затянулось на 2 года. В итоге получается «бесполезное ПО» которое не нужно уже на дату внедрения т.к. бизнес процессы у компании уже поменялись. (А они меняются можно сказать, что очень часто и возможно что кусок который писали месяц больше вообще не нужен) И по факту получается заказчик платит кучу бабок, получает систему которая не покрывает всех текущих задач автоматизации. Претензию он предъявить не может так как все сделано по подписанным техническим требованиям.

Из выходов вижу внедрение по частям. Выделять логические неразделимые части и отдельно каждую внедрять. При таком развитии риск меньше, но проект уже будет затягиваться не на 2 а на 4 как минимум года. Если заказчик нормальный и «башляет» делаем именно так. (Это я про свой опыт)

Если есть хорошо работающая система-прототип, которую заменяют, очевидно, из-за ее морального устаревания, значит, бизнес процессы стабильные и волатильность требований исключается.

А вот еще похожие случаи, но с более приличными суммами:

Стартовый бюджет проекта тогда был $60 миллионов. За время «реализации проекта» траты разрослись до... $700 миллионов. В итоге — похоже, что ничего толком не работает

ko.com.ua/...ulice_erp_54172

ERP успело показать себя и на постсоветском пространстве:

www.erp-negative.ru/...ebnie-iski.html

В общем, тенденция уже очевидна. Случай с Epicor уникален тем, что что претензии основаны на неприемлимой скорости ПО и чрезмерным требованиям к аппаратным ресурсам. Выписка счета занимает минуты.

Предположу, что правильный технический вывод из этих случаев такой: борьба со сложностью с помощью современных парадигм программирования проиграна.

Предположу, что правильный технический вывод из этих случаев такой: борьба со сложностью с помощью современных парадигм программирования проиграна.
Не думаю, гогнокод можно писать с применением любой парадигмы, и быстрый удобочитаемый код тоже можно писать с применением любой парадигмы (ну кроме разви копипаста). Самая большая ошибка в попытках создать что-либо полностью дуракоустойчивое состоит в преуменьшении изобретательности полных дураков, как говаривал один покойник.

Цифры поражают. Американцы тоже умеют бюджет дерибанить!!! А подобные случаи это как ошибки внедренцев так и заказчика. Если заказчик не достаточно ответственно относится к процессу тут большая вероятность фейла на финише.

Так вот суть в том, что такие вещи творились и 20 и 30 лет назад, это не регрес — это топтание на месте некоторых компаний.Не потому что программирование плохое, а скорее проблема в архитектуре, просто обычно legacy software ставят на виртуалки, если оно работает. Есть системы написанные на Cobol. работающие до сих пор, непонятно как вообще выбили разработку, для западного бизеса нехарактерно тратить деньги куда попало

P.S: Не могу вспомнить книгу из классиков типа Листера, там описывалась такая ситуация, когда ребята делали ПО для нефтяной компании на Visual Basic, место действия Питтсбург, их гланый продакт менеджер все время отправлял байки и выбивал деньги, они работали 3 года, но так и несмогли написать систему и потом команду распустили, а главный герой остался в ИТ отделе это компании. Там еще про чувака, который делал личные ксероксы и все время заканчивалась бумага и чувака, который играл в рок группе и был типа кодеманки, а потом забил и начал концертами зарабатывать на жизнь.

Если кто вспомнит название книги, буду признателен

Может потому, что как обсудалось в одной ветке — выгоднее взять двух джунов, мидла и сеньора, чем двух сеньоров. Или даже трех :) Я вот в последнее время стал замечать, что кол-во глюкавого софта в мире прибавилось в разы, особенно, когда драйвера ставишь.

кол-во глюкавого софта в мире прибавилось в разы

И микроминиатюризация этому способствует.

Как только мощности процессоров и количество памяти стало достаточно, в крохотные устройства стали загружать готовые образы чуток подпиленных десктопных систем. В итоге полупустая коробочка роутера инициализируется больше минуты. Чем занимается процессор и что же там настраивает? Как что? Линукс в этой коробочке ищет шину PCI и определяет устройства на шине, OMG...

если отбросить попил или на порядки возросшую сложность (ведь зачем-то меняли уже работающее) то еще есть вариант нелинейности скалинга, т.е. условно говоря, система, которую откатали на 10 млн. транзакций в день, может более менее работать на 13-15-17. а на 18 происходит большой бадабум (даже если поставить в 2-3 раза больше серверов) , ибо статистика индексов изменилась да и относительно простые запросы начали вместо memory sorting запускать сортировку на диске, ну и база начала «черпать» диск (эт если для баз) , сети и гуи тоже начали петь свою песню, и тут надо рефакторить очень много и сложно (шардинг, денормализация и прочие танцы с бубном требуют много переделок )
обычно прогеры предупреждают об этом, но sales таких «тонкостей» не хочет слушать, вот и продают то, что не обкатано под требования.

а дальше менеджмент — нафига переписывать то, что уже работает, давайте побыстрому и вперде

ага, и при этом написанная 20 лет назад система прекрасно справляется с нагрузкой

скорее всего написанная 20 лет назад система имеет только 1% от функционала новой

Но в статье написано что этого функционала полностью хватает по сей день.

больше похоже на утрирование. если функционала хватает — нафига вообще что-то менять ? попил ? денег некуда девать ?

Причн может быть много, терминальный юай к мэйнфрейму выглядит несколько устаревшим, последний кобол програмист в компании уходит на пенсию, прекращена поддержка некоторых элементов инфраструктуры компаниями производителями.

И почему утрирование? Я так понимаю новую систему не выкатили и в строю вполне трудится старая?

так я собственно про тоже самое. то что для «менеджера» вы глядит как тот же самый функционал, реально является более навороченной системой, ui с плюшками, настроек больше, дополнительные феньки и плюшки внутри и снаружи. и архитектура заточенная не просто счета генерить, а более широкий охват бизнес процессов

при этом весь охват работает со скоростью самого медленного звена?

Со временем растет саппорт кост древней системы, потери от даунтаймов. Наступает точка, когда кажется, что дешевле заменить. Просто руки у подрядчиков кривые. При готовой системе в наличии остается ее только склонировать на новых технологиях. Ничего выдумывать же не надо.

Ну как бы бизнес-процессы тоже могли и поменяться за эти 20 лет. Даже и в полиции.

Не факт, что стоит копировать.

Ох да, и не факт, что кривые руки именно у подрядчиков. Заказчики всегда, ВСЕГДА вносят в этот беспредел свою лепту.

пришел эффективный менеджер, который во время фуршета у одного из ИТ монстров наслушался новых слов

пилили пилили распилили и в результате индусам зааутсорсили

Наверняка 23-летним сеньорам, обчитавшимся про правильные парадигмы, зааутсорсили. В результате — 10 уровней абстрактных фабрик, для того, чтобы класс «строчка в инвойсе» создать.

Підписатись на коментарі