Какую самую вопиющую трату денег вы видели, и что вы с этим сделали?[закрыто]

https://softwareengineering.stackexchange.com/questions/18585

22-10-2019
|

Вопрос

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

Итак, мой вопрос заключается в следующем.После того, как вы столкнулись с вопиющей тратой денег на какое-то программное обеспечение и / или аппаратное обеспечение, которые действительно достали вас, что вы сделали с этим, чтобы все исправить или вы были обречены стиснуть зубы и вечно бормотать что-то себе под нос?Мне интересно услышать ваш общий опыт и особенно какие уроки вы извлекли о том, как справляться с подобными вещами в будущем.Давайте не будем называть имен, опыт решения проблемы важнее, чем сам продукт-нарушитель.

Решение

Оплата за большие, громоздкие коммерческие продукты, в диапазоне:

Серверы приложений;
Инструменты тестирования;
Среда разработки.

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

Мои шаги обычно:

Установить альтернативу в качестве ссылки - например, «Я буду экспериментировать с App Server X вместо сервера приложений Y. У меня был хороший опыт с ним, потому что (...).»;
Продайте это предложение своим коллегам - «Я сейчас развиваю быстрее, так как сервер X перезапускается намного быстрее, и я не трачу все это время»;
Продайте это непосредственному менеджеру - «Наша команда теперь развивается быстрее, так как мы используем сервер X. Все это началось как небольшой эксперимент, но всем нравится».

Другие советы

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

Тщеслаковые сайты. Анкет Это веб-сайты, которые не служат никакой полезной цели для любого за пределами небольшой организации, которая комиссии по ним и построена вокруг навязчивого принуждения с логотипами, фотографиями себя и самодовольной вафлей. Хуже всего это то, что они обычно финансируются и заказаны в эксплуатации людей, которые не имеют ни малейшего понятия о Интернете. (Например, однажды имел траст больниц NHS, который хотел разработать мини-версию Facebook для интрасети собственной персонала).
Заплатить за лучшее. Анкет Мышление, которое настаивает на том, что платное программное обеспечение должно быть лучше, чем открытый источник. В конце концов, это оплачивается, верно? Я видел, как так много клиентов настаивают на том, чтобы сделать глупый выбор просто потому, что они работают в культуре, которая автоматически скизывает все, что является открытым исходным кодом в вопросе политики.
Дизайн комитетом. Здесь у огромной группы людей есть «мозговой штурм», а затем попытайтесь включить каждую идею клолока, в которой есть дизайн, неизбежно приводя к плохому беспорядку, который ставит под угрозу все в пользу попытки угодить всем ( и всеми они имеют в виду, что комитет принимает решения, а не людей, которые должны использовать заявку).
Консультанты. Здесь вы платите среднему человеку (который не знает ни деловых практик, ни разработки программного обеспечения), чтобы мешать и кремовать деньги, затягивая процесс разработки с запутанными техно-блюдами и выступлением на бизнес.

Я не вижу, чтобы кто -то уже упоминал об этом.

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

Вариации этой схемы:

Даже не рассматривая компромисс Buy-Vs.-Build
Значительный ползучий охват внутреннего раствора
ограниченная область, но также ограниченная полезность внутреннего решения

Мои два фаворита:

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

Ограничение долгосрочных повышений и бонусов

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

В конечном итоге сотрудники поймут, что их масштаб оплаты не является линейной с их отраслью (или результатом). Люди, у которых есть резюме и навыки, в конечном итоге уйдут, и возьмут с собой все свои знания и, вероятно, некоторые из своих друзей. Оставшиеся люди (которые являются нижними исполнителями), должны будут забрать слабину, а затем потратить больше времени на найм нового человека (по рыночной ставке). Таким образом, компания только что обменяла звездного сотрудника на первый уровень JR и просто потеряла все «сбережения» поддержания низкой зарплаты.

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

Этот ответ несколько отличается от большинства: не увольняет сотрудника достаточно скоро, или заявлено по -другому, чрезмерно терпимо к работнику ~~ошибки~~ привычки. Анкет Это были вещи, которые я наблюдал, и не мог многое сделать как консультант.

Разработчик, который плохо управлял дизайнерскими решениями проекта, который привел к его возможному переписыванию (это был полный беспорядок).
Разработчик, который отправил конфиденциальные незашифрованные данные в диаграммы Google, потому что они думали, что было бы здорово показать круговую диаграмму (была ли это круговой диаграммой требованием? Нет!).
Разработчик, который консультировался с компанией в прошлом и занял с ними должность напрямую. Он сделал это лицо и превратился в Prima Donna, которая искала техническую позицию и пошел так далеко, как поговорить с менеджером лидера, заявив, что они думали, что ему будет хорошо взять на себя в качестве ведущего. Поговорим об смелости! Многие разработчики больше не похожи на парня, и он сжигал много мостов в течение первых 2 недель в качестве сотрудника. В довершение всего он очень зеленый разработчик, который закончил только 2 года назад, но думает, что он потрясающий.

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

Несколько раз я был свидетелем управления, привлекая консультантов для Единственная цель тратить деньги. Анкет Большую часть времени это происходило в конце года, когда они были недостаточно отчаянно пытались потратить деньги. Обычно этим консультантам платят сотни долларов в час, и они тратят недели на презентацию PowerPoint, которая никогда не будет использоваться.

Здесь гораздо большая проблема.

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

Итак - иди на работу или запустить компанию, которая приносит пользу обществу / планете.

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

Я работал в правительственном агентстве для команды, которая была глубоко в постели с Oracle. В течение многих лет им платили баджиллионы долларов за свое программное обеспечение. Исходя из фона запуска, это не имело для меня смысла - «Почему бы не использовать MySQL или Postgres?» Мне сказали, что это было в основном из -за поддержки, которую предоставляет Oracle, если что -то пойдет не так, они помогут вам быстро найти решение.

Поддержка была абсолютной шуткой. Была проблема, когда одно веб -приложение продолжало сбивать всю систему. Похоже, это результат медленного запроса базы данных с комбинацией ужасно написанного кода (который был написан командой консультантов, что должно быть совершенно другим ответом). «Целевая группа» (стон) была собрана, чтобы определить проблему и исправить ее. В целевую группу был включен участник поддержки Oracle. Каждый день в EOB была бы конференц -телефон, где члены целевой группы обновляют остальную часть команды с результатами. Это был достаточно длинный звонок, что никто не хотел быть на B/C, он начался в 5, и человек Oracle просто усугублялся. Почему? Ну, говоря «человек» даже не верно. Это было несколько человек. Казалось, что каждые два или три конференции конференции, представитель Oracle был бы кем -то новым, который объяснил, что их предшественник был теперь на другом проекте или уехал в отпуск. Новые люди никогда не были проинформированы никому в Oracle, поэтому каждый раз, когда кто -то появился, нам приходилось тратить десять минут на конференции, объясняя проблему снова. Их вклад Затем будет запрашивать файлы журналов J2EE, которые не только могут прочитать любую обезьян, но и бесполезны, потому что ужасно написанный код делал такие вещи, как бросание исключений IndexoutOfBounds, когда программист обнаружил ошибки при анализе XML.

Наличие программистов в поддержку телефона 1 -й строки.

Наличие программистов выполняют тестирование.

Я знаю, что это старый вопрос, и мне повезет, если 3 человека прочтут этот ответ, но это забавная история, так что, черт возьми.

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

Я написал очень длинную электронную почту своей первой недели там (как консультант). Это было рискованно, потому что я в основном говорил, что это было неправильно, разработчики находились над своими головами, никакого процесса не следовали и т. Д. мне. Он не был полностью защищен от этого, на самом деле он признал многие недостатки и сказал мне, что я не первым указал на них (не шучу, верно?)

Чтобы ответить на суть исходного вопроса: я предложил потратить не более 1 человека в неделю, получая статический инструмент анализа Gimpel (PC-Lint / FlexElint), настроенный на их платформу и запустить полный отчет обо всем, что было найдено Анкет Я сказал им, что был абсолютно уверен, что в результате мы найдем несколько скрытых «времени».

Они рассчитали мою почасовую скорость, умножили ее на 40 и определили, что это «слишком дорого, чтобы сделать это». Короче говоря, я ушел там в течение 60 дней. Примерно через 3 года я узнал о отзыве продукта, стоимость приблизилась к 9 цифрам (100 миллионов долларов), не говоря уже о повреждении репутации компании.

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

Таким образом, они сэкономили 295 долларов, не купив PC -Lint (хорошо, они также сэкономили неделю платить мне, больше всего) - но я нигде не достаточно хорош, чтобы взимать 100 миллионов долларов за неделю.

Это то, что я называю чертовски большой тратой денег.

Напоминает мне о шутке, которую многие из вас уже слышали:

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

Двое владельцев корабля были там, наблюдая за этим человеком, надеясь, что он узнает, что делать. Посмотрев все, старик протянул в сумку и вытащил маленький молоток. Он осторожно что -то постучал. Мгновенно двигатель встал на жизнь. Он осторожно убрал молоток. Двигатель был исправлен! Через неделю владельцы получили счет от старика за 10 000 долларов.

"Какая?!" Владельцы воскликнули. "Он почти ничего не сделал!"

Поэтому они написали старику записку с надписью: «Пожалуйста, пришлите нам подробный счет».

Человек послал счет, который прочитал:

  Tapping with a hammer ........ $ 2.00

  Knowing where to tap ......... $ 9998.00

Усилия важны, но знание того, что вы делаете, имеет все значение.

Раздутые команды разработчиков и ужасная производительность в компаниях -разработчиках программного обеспечения.

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

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

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

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

Есть два, которые я испытал.

Отмена проекта, у которого был огромный рентабельность инвестиций для бизнеса, который был завершен на 80%, а затем раздавал 100 гравированных и золотых iPod для старших руководителей.
Уложить несколько сотен человек, а затем на следующий день, объявляя о значительных повышениях заработной платы и бонусах для старших руководителей.

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

Меня не уволили, но я также не получил повышение или iPod.

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

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

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

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

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

Технический долг

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

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

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

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

Я работаю с несколькими Государственные учреждения И они потрясающие, тратя деньги на это. От покупки раздутого промежуточного программного обеспечения до решения чрезвычайно простых проблем до оплаты тысяч и тысяч долларов поставщику, чтобы они создали CSV. Без внутренних людей с достаточным опытом, кажется, они либо уходят из-за первоначальной стоимости, либо на техническом обслуживании.

В компании, не связанных с программами (банки, страхование) с внутренними ИТ, деньги поступают от различных бизнес-групп. Бизнес -группы напрямую получают продажи от поставщиков и будут перенести его к ИТ. Они платят за программное обеспечение/аппаратное обеспечение и вашу зарплату, чтобы ваши протесты никуда не пойдут.

Оплата за раздутые приложения и промежуточное программное обеспечение, которое стоит пять цифр в середине высоты и даже не вписывается в существующую архитектуру системы
Использование дорогостоящего программного обеспечения, такого как HP QualityCenter, BMC Remedy, HP LoadRunner и т. Д., где доступны лучшие и более дешевые варианты
С многоуровневыми командами большие расходы на поездки, иногда всего за несколько часов после встречи
Оплата лицензии Windows 7, которая Some с новыми машинами, а затем снова заплатит на понижение до Windows XP, поскольку новый SOE (разработан в 2010 году) по -прежнему XP
Из -за емкости в оборудовании

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

Найм аутсорсис -аутсорсера, основанный только на цене, а не на квалификационных навыках и не регулярно аудит навыков тестеров производительности. Наем любительского тестера производительности очень похож на найм сантехника или любительского электрика, им потребуется гораздо больше времени, чтобы выполнить основные задачи, много проверок и балансов в процессе потеряны, и когда вы узнаете, как просто как это Плохо, что они были ужасно дорогими, чтобы исправить (в производстве). Будучи модератором для полдюжины форумов в этой области, я регулярно наблюдаю за появлением людей, которые не имеют фундаментальных навыков в тестировании, коммуникации, управлении проектами, разработке, системным анализом и т. Д., И они просто были брошены на инструмент. Человеку, который отметил LoadRunner как трату денег раньше, если вы бросаете дурака за инструмент, есть только один результат, который вы должны ожидать. Ирония заключается в том, что инструменты с открытым исходным кодом требуют еще более зрелого набора навыков, чтобы добиться успеха с ними.
Не собирая требования к производительности. Это влияет на всю организацию, потому что у вас будет другой взгляд на производительность в области архитектуры, инженерии платформы, инженерии приложений, функционального QA и QA производительности, ни один из которых на самом деле не может соответствовать заинтересованным сторонам бизнеса (и часто нет). Это проблема процесса для многих организаций, команду тестирования производительности просят как собрать требования к производительности, так и проверить на них. Для надлежащих проверок и балансов вы должны делать одно, а не другое. Связанные с 1 выше с незрелым персоналом, у вас будут люди, которые даже не могут распознать надлежащее требование о производительности, у вас нет точки измерения для проверки с профилем нагрузки, и все же они все еще строят «сценарии для работы». Это потраченная трата времени и усилий, и это мало что делает для улучшения качества. Производительность нуждается в общей перспективе по всей организации, и это не то, что можно просто прикрепить в конце, если она не была разработана с самого начала.
Управление средой тестирования производительности. Я не могу сказать вам, сколько организаций откладывается на тестирование среды, не готовые к запуску в то время, когда тестовая организация готова к продолжению. Только у одного клиента я вижу это как многомиллионную проблему с точки зрения часов, потерянных во время ожидания
Менеджеры проектов, которые не понимают, что такое тестирование производительности, какие задачи вовлечены или каким уровнем усилий, но которые определяют, как долго должны происходить действия. Это приводит к отклонениям в графике проектов, которые полностью связаны с тем, как были запланированы предметы (и в результате перерасход). Это непосредственно связано с 1 выше, а незрелые тестеры не могут точно проецировать ни число, ни типы задач, ни на то, как долго должны выполняться задачи. Это аксиома, что если вы позволите кому -то, кто не понимает, что вы делаете и почему вы делаете это, чтобы определить, как вы работаете и сколько времени вы будете проходить, тогда этот путь приведет к неудаче. Это происходит слишком часто при тестировании производительности.

Собственные системы управления версиями. Учитывая состояние GIT и Mercurial, я не понимаю, почему люди пойдут на что -то с хранителем ворот.

Вам нужно не только платить за VCS, но и заплатить за пользователя. Кроме того, ваша гибкость выстрела в ногу. С таким же успехом вы могли бы носить футболку с надписью «Я ♥ продавца блокирует !!!»

Я чувствую, что в наши дни это просто чокнутый - не использовать бесплатные (D) VCS. Если вы хотите, чтобы с ним было много дополнительных льгот, доступны такие вещи, как Kiln.

Я не думаю, что пойду на работу на кого -то, кто настаивал на Bitkeeper или подобном.

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

Статусные встречи и еженедельные отчеты

Организация, в которой я работал, была все о еженедельных отчетах о статусе - расстроена на 3 разных уровнях. DEV ведет и тестирует лидеры для каждого из 4-6 проектов в полете сообщать о своих прогрессах в длительном электронном письме, которое затем подталкивается следующим менеджером, что, в свою очередь, произвольно обобщено следующим.

В следующий рабочий день все руководители проекта собираются в течение 1 часа встречи, чтобы пройти отчет.

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

Я работаю в государственном учреждении.На самом деле нет никакого способа адекватно объяснить уровень расточительства, который может иметь место, когда рабочее место настолько жестко регламентировано законодательством и профсоюзами, что уволить кого-либо практически невозможно.

Менеджеры разыгрывают партию с плохими сотрудниками и надеются убрать их всех сразу под предлогом реструктуризации.Некоторых плохих сотрудников повышают в должности только для того, чтобы вывести их из области, которая нуждается в улучшении.Любой хороший сотрудник в конечном итоге постоянно борется только за то, чтобы компенсировать работу плохого сотрудника.Сотрудники, которых вы не удержали бы в течение 3 месяцев, создают 40-летнюю карьеру.Количество денег, которые они тратят на такую карьеру, просто астрономическое.

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

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

Один проект, над которым я работал с крупным финансовым учреждением. Ежедневно было огромное количество конференц -звонок, и я подсчитал, что они сжигали около 100 тысяч долларов в день только на конференц -звонках. Проект длился около 2 лет. У них было множество устаревших систем, и когда были внесены изменения в дневной сбережения пару лет назад, они заплатили Microsoft около полумиллиона долларов, чтобы придумать патч DST за 3,51 NT.

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

Решите дефицит бюджета, увеличивая расходы ... неудача.

С другой стороны - эксперт по эффективности предоставил совет по сухой стиле, где мы отслеживали наши оплачиваемые часы и оплачиваемые часы ... Угадайте, у кого было наименьшее количество оплачиваемых часов.

Давайте посмотрим, мы однажды потратили более полумиллиона долларов, выполняя работу, чтобы выиграть контракт на миллион долларов. Так много за прибыль от этого. Некоторые из нас в команде разработчиков предложений по проекту пытались указать на это, но для нашей маленькой компании это стало гордостью завоевать компании Fortune 500, с которыми мы конкурировали. Мы выиграли и потеряли деньги из -за контракта с кулаком Onteh по этим и другим причинам, но у нас были права хвастаться.

Когда -то как государственный подрядчик, я был вынужден работать невыплаченным сверхурочным, потому что контракт разрешил это, и подрядчику заплатили за мое сверхурочное время. Мало того, что я был увлечен своей работой и провел 4 часа каждые воскресенье, занимаясь серфингом в Интернете без работы. Само собой разумеется, я очень быстро переехал после того, как они начали эту ерунду.

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

Чистые отходы. ИТ -трата, которая должна была быть сокращена многими миллионами. Таким образом, способ сделать это заключалась в том, чтобы вылететь на людей ИТ со всего мира. Поместите их в Flash Hotel на неделю. Затем в здании, где проводились встречи, положите новый пол. Мрамор, конечно. И в одночасье между встречами каждый день здание было отремонтировано. Это каждый вечер на неделю.

Эээ ... приоритеты кто -нибудь?

Земля фантазии.

Компания, на которую я работаю, заплатила 800 долларов за лицензию в диаграмме FX - это даже не мои деньги, но я чувствую себя ограбленным.

http://www.softwarefx.com/sfxnetproducts/chartfx/

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с softwareengineering.stackexchange