Какие наихудшие ложные экономики (то есть способы экономии денег, которые в конечном итоге стоят больше, чем они экономят) преобладают в индустрии программного обеспечения и как с ними бороться?
programming-practices
project-management
Джон Хопкинс
источник
источник
Ответы:
Технический долг
т.е. "Просто сделай это быстро, мы рефакторинг позже". Во-первых, потому что я еще не видел, чтобы кто-то занимался этим поведением на самом деле рефакторинг позже. Во-вторых, потому что быстрые действия, а не хорошие, затрудняют добавление будущих функций или устранение будущих ошибок, так что в конечном итоге вы теряете время.
К сожалению, многие все еще думают, что это экономит циклы разработчиков, заставляя их делать что-то быстрое. Я предполагаю, что это возможно, но я еще не видел это на практике.
источник
Наем 2 дешевых разработчиков вместо 1 действительно здорово. (по той же цене)
источник
Мой пример будет полной противоположностью примеру НимЧимпски , а именно:
Попытка разработать что-то собственное, что можно купить в продаже.
Обычно это происходит из-за неспособности фактически проверить рынок, чтобы увидеть, существует ли уже что-то, что решит проблему. Это может быть усугублено разработчиками, которым нравится «погружаться» в кодирование, прежде чем проводить какие-либо исследования, и менеджерами проектов, которые не учитывают в это время = деньги.
Одним из наиболее распространенных примеров, которые я видел в своей области, веб-разработке, являются компании, пытающиеся разработать и внедрить систему CMS. Они неизменно начинаются с малого, но вскоре становятся раздутыми и выходящими из-под контроля по мере того, как появляются новые функции, хотя в то же время существует множество бесплатных продуктов и платформ, которые будут гораздо лучше подходить.
источник
Нет выделенных ресурсов для управления проектами
Я несколько раз сталкивался с контрактами нескольких программистов, и тот, у кого уже была тяжелая ежедневная работа, должен был управлять проектом, но на самом деле был слишком занят другими задачами, поэтому проект так и не набрал обороты. Программисты делали «прототипы» и прочее, но без всякой возможности многие из них бегали кругами, чтобы выглядеть занятыми.
Плохое оборудование для новых программистов
Однажды я испытал компанию, где политика гласила: «Новые программисты должны работать на действительно старом ПК с небольшим экраном, пока они не докажут, что они достойны». Не удивительно, что такая политика вызвала отрицательный отбор, который отбросил хороших людей, у которых всегда есть выбор, работать в более здоровой обстановке.
источник
Мы можем сэкономить деньги, если программисты выступают в роли тестировщиков / технических писателей.
Если вы платите зарплату программиста за работу тестировщика / технического писателя, то вы напрасно тратите деньги и, вероятно, получаете работу более низкого качества, чем тот, кто посвятил свою карьеру этой задаче. Кроме того, когда программист сталкивается с жесткими сроками тестирования, очень вероятно, что документация будет отброшена или сделана напрасно, чтобы ее выполнить.
Кстати: разработчики ВСЕГДА находятся в сжатые сроки.
источник
Исследование / Чтение / Написание кода, не связанного с разработкой продукта, является пустой тратой ресурсов.
Некоторые программисты и даже менеджеры верят в это. Обычно они просто занимаются программированием, основываясь на знаниях в своей голове, и проводят исследования и ищут ответы, когда сталкиваются с проблемами. Они не постоянно улучшают свои знания активно. Мое мнение, мы должны всегда держать себя в курсе, а полученные знания были бы полезны для нас при решении существующих и будущих проблем. Конечно, вы должны распределить свое время с умом.
Это также похоже на ответ Дэна . Некоторые менеджеры просто хотят, чтобы разработчики быстро погрузились и разработали продукт в соответствии с требованиями, не исследуя существующие продукты на рынке.
источник
Во многих случаях офшоринг стоит больше денег. В моей компании очень сложно получить новые слоты для сотрудников, нас сильно подталкивают к аутсорсингу. Также трудно найти подрядчиков на месте; есть соотношение 3: 1 на суше и на суше, которое они должны поддерживать. Следовательно, многие команды просто нанимают дюжину оффшоров и почти не используют их, просто чтобы получить 4 подрядчиков на месте.
источник
Длинные петли обратной связи!
Это случается со всеми: вы создаете что-то, что вы считаете удивительным, и получается, что вы ошиблись. Это не проблема. Проблема в том, как долго вы проводите строительство, прежде чем узнаете, что вам следует остановиться.
На высоком уровне вы видите эту проблему с длинными циклами выпуска. Если вы строите год без обратной связи, вы играете весь год. Чем чаще вы отпускаете, тем меньше ваши азартные игры и тем лучше вы играете.
Но это также происходит на самых низких уровнях. Как разработчик, мне действительно нравятся частые обзоры кода (или, лучше, парное программирование), потому что это ограничивает количество времени, которое я могу продолжать делать что-то глупое, прежде чем кто-то скажет: «Эй, есть более простой способ!» По той же причине мне нравится, что мои модульные тесты выполняются быстро и часто, поэтому я могу ловить и убивать ошибки до их появления.
Как только вы начнете замечать важность коротких петель обратной связи, вы увидите это повсюду. Например, военное понятие петли OODA .
источник
Не мой собственный анекдот, но однажды я услышал о магазине, который прекратил предоставлять бесплатный кофе своим разработчикам, вместо этого сказал им, что в любое время, когда они хотят получить кофе, они могут свободно ходить в ближайшую кофейню (что-то вроде десяти минут). поездка в каждую сторону) и покупка некоторых.
В значительной степени определение ложной экономики.
источник
Предоставление рабочих станций с одним экраном, потому что второй монитор слишком дорогой . Даже если это экономит вам час работы каждый год, второй экран все еще является хорошим вложением. Я точно знаю, что мой спас мне много-много часов работы.
Настройка нескольких мониторов может сделать практически любую задачу более эффективной, а не только задачи разработки. Три монитора даже лучше, чем два, но эффект становится менее выраженным с каждым дополнительным экраном.
Настройки нескольких мониторов:
источник
Самое дешевое оборудование предоставляется консультанту при стоимости консультанта более 150 $ / час .
Если рассматривать это в перспективе, то лучшее оборудование может повысить эффективность работы на 30 минут в день. Это дало бы 30 минут * 20 дней работы в месяц = 600 минут / месяц = 10 часов / месяц> больше, чем 1 день работы = 10 часов * 150 $ / час = 1500 $
Разве консультант не работал бы более эффективно, если бы у него был компьютер за 1500 $? Это сделает консультанта менее раздраженным?
Теперь проблема заключается в том, что существует два бюджета, один для консультанта и один для аппаратного обеспечения ПК.
источник
Месяцы работы экономят дни планирования
(Не вкладывая достаточно времени в планирование)
источник
Я подозреваю, что наиболее распространенными являются менеджеры, которые просто не предоставляют разработчикам инструменты, необходимые им для эффективной работы.
В основном, пункт 9 на тесте Джоэла .
источник
«Бросить (достаточно) тел в проблему» , к сожалению, все еще можно использовать в некоторых местах. Закон Брука противоречит этому из «Мифического человеко-месяца» , хотя некоторым требуется опыт, чтобы выучить этот урок. Как правило, это не то, что я могу остановить, поскольку руководство может поверить в ложное утверждение о добавлении людей и отсутствии необходимости платить за это цену.
источник
Ежедневные встречи :
источник
Покупка готового программного обеспечения вместо внутренней разработки.
У меня есть опыт систем управления масштабами предприятия, ориентированных как на HR, так и на биологические лаборатории.
Готовое решение стоило £ 50-100 тыс. И нуждалось в дальнейшей разработке и настройке в соответствии с требованиями бизнеса.
Для разработки внутреннего решения потребовалось (<6) месяцев, параллельно с другими проектами, и использовался уже нанятый разработчик.
Я перешел из государственного сектора, где у нас была запущена и запущена внутренняя система LIMS (лабораторная система управления информацией), в крупную международную фармацевтическую компанию, где внедрение готового решения заняло более года и не было завершено.
(6 месяцев уже нанятого разработчика, работающего над другими проектами параллельно. Так что ~ 10 тыс. И это не включает расходы на поддержку, связанные с готовым решением). Суть в том, что внутренне разработанная система фактически использовалась! Таким образом, у вас есть дополнительная экономическая выгода, связанная с этим, которую я не могу рассчитать.
Я согласен на базовые веб-сайты и т. Д., Зачем создавать свои собственные. Но для любых больших сложных систем, и если у вас уже есть домашние навыки, я бы сам их создал .
источник
Покупка дорогих готовых продуктов, когда альтернативы с открытым исходным кодом лучше и бесплатнее.
Сколько компаний используют git? Сколько компаний используют какой-то дерьмовый корпоративный контроль версий?
источник
Использование «простых» языков без особой выразительности
Да, это облегчает поиск программистов для поддержки кода, но затрудняет поиск хороших программистов, которые не просто изучают последнее модное слово, которое их наймет. Да, это облегчает понимание кода отдельных битов, но также делает его жестким, как 2x4, и увеличивает объем кода, который необходимо понять. Да, это поддержано огромной корпорацией, но сказал, что огромная корпорация вводит инновации медленно и бюрократически.
источник
Плохие руководители проектов / руководитель группы.
Так как один некомпетентный человек может разрушить работу группы людей. В конце концов, проект будет намного лучше без решений высшего руководства (руководитель проекта / команды).
Доза "Просто сделай это быстро, мы рефакторинг позже" решает.
источник
Отсутствующие требования пользователя
Хотите верьте, хотите нет, но иногда эта часть отсутствует или устарела. Что касается стоимости, так это то, что создается функциональность, о которой конечный пользователь никогда не просил.
источник
Производительность стоит больше, чем творчество
Творчество трудно измерить вообще, и чаще всего невозможно даже наблюдать, не говоря уже о измерении, когда дело доходит до разработки программного обеспечения. Производительность, с другой стороны, может быть измерена (часто плохо) и может наблюдаться.
В результате, разработчики, которые могут (писать больше строк кода | писать код быстрее | быстрее читать технические слова в ответ на вопросы | более заметны) имеют тенденцию цениться больше, чем те, которые (используют меньше строк кода для решения той же проблемы | требуется больше времени для написания кода, но для создания более надежного продукта | достаточно хорошо разбираюсь в предмете, чтобы отвечать на вопросы простым, понятным языком | творчески решать проблемы).
источник
Все ниже может быть плохо, если используется или не используется ненадлежащим образом
внешнее и внутреннее программное обеспечение
Соответствие ISO 9001 (экономия - снижение риска потери MSS, если качество продукта падает)
разработка / QA аутсорсинг
процедуры разработки / сборки / выпуска / поддержки
источник
Слишком много неоплачиваемых менеджеров по доставке.
Пару лет назад в нашей компании было несколько крупных бюджетных проектов, и набор был на пике. В то время наша компания наняла слишком много менеджеров по доставке (многие из них не были ИТ-специалистами!) И очень мало программистов / тестировщиков. Соотношение менеджера и программиста было буквально 1: 2. Позже, после завершения этих проектов, у нас была ситуация, когда многие из этих менеджеров (некоторые из них были настоящими бездельниками) сидели на скамейке и ничего не делали. У нас был один цикл оценки, когда у всех было мало / нет повышения (даже мы, трудолюбивые программисты, вздох), чтобы компании не пришлось никого увольнять! К счастью, компания осознала эту ситуацию и сделала RIGHTSIZING в первом квартале этого года!
источник
Оптимизация перед профилированием (преждевременная оптимизация).
Слишком много раз я видел, как кто-то пытался найти умное решение, которое без необходимости усложняло бы обслуживание и удобство чтения на том основании, что это быстрее. Естественно, код не был протестирован (даже с помощью микро-тестов), поэтому он быстро становится «быстрее на основе более убедительных аргументов» в части кода, что, скорее всего, не повлияло на общую производительность всего приложение по многим.
Таким образом, это очень ложная экономика, и такая ложная экономика иногда запутывает даже опытных профессионалов.
источник
Ограниченный или нет доступа в интернет
Потому что, очевидно, ваши сотрудники будут использовать Интернет, чтобы играть в игры на Facebook, а не изучать ответы на технические вопросы по Stackoverflow.
В действительности, конечно, Интернет является огромным приростом производительности, и, хотя может быть целесообразно использовать какой-то фильтр сайтов для действительно изворотливых сайтов, есть какая-то ошибка, если он блокирует файл readme для Visual Studio или блокирует страницы местного правительства Телфорда по причине "секс туризм"
источник
Заставить ваших разработчиков использовать 15-дюймовый монитор и ПК низкой спецификации, так как это корпоративный стандарт.
Мониторы разумного размера дешевы, быстры в установке и повышают производительность труда программистов, а также заставляют ваших программистов думать, что вы заботитесь о них.
источник
Слишком много бакалавров делового администрирования (или тому подобное), иерархически организованных, которые пытаются применить то, о чем они думают, о современном менеджменте: беспокоить людей с «KPI», «SLA» и тому подобное, требуя «отчетов» (без, конечно, заботясь об инфраструктуре для их генерации), так что программисты тратят свои дни, заполняя причудливые листы EXCEL, отчеты за 4 квартал, а что нет, копируют из одного замечательного нового инструмента управления и вставляют в другой (кажется, что это правило эти инструменты никогда не интегрируются и не интегрируются друг с другом) и посещают собрания, на которых представлены отчеты и цифры (и каждый чувствует себя виноватым из-за того, что не выполнил тот или иной KPI).
источник