Каковы наихудшие ложные экономики в разработке программного обеспечения? [закрыто]

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

126 голосов | спросил 5 revs, 5 users 100%
Jon Hopkins
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

27 ответов


183

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

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

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
164

Наем 2 дешевых разработчиков вместо 1 действительно замечателен. (по той же цене)

ответил JeffO 8 J000000Friday11 2011, 04:17:48
85

Мой пример будет полной противоположностью пример НимКимпски , а именно:

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

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

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
73

Нет выделенных ресурсов для управления проектами

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

Плохое оборудование для новых программистов

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
71

Мы можем сэкономить деньги, если программисты удвоятся в качестве тестеров /технических авторов

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

BTW: разработчики ВСЕГДА работают в сжатые сроки.

ответил JeffO 8 J000000Friday11 2011, 04:17:48
63

Исследование /Чтение /Написание кода, не связанного с разработкой продукта, является пустой тратой ресурсов.

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

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
58

Во многих случаях офшоринг стоит больше денег. В моей компании очень сложно получить новые слоты для сотрудников, нас сильно перенаправляют на аутсорсинг. Его также трудно получить на месте подрядчиков; существует соотношение 3: 1 от берега до берега, которое они должны поддерживать. Следовательно, многие команды просто нанимают дюжину оффшорных компаний и почти не используют их вообще, поэтому они могут получить 4 подрядчика на месте.

ответил JeffO 8 J000000Friday11 2011, 04:17:48
50

Длинные петли обратной связи!

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

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

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

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
47

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

В значительной степени определение ложной экономики.

ответил JeffO 8 J000000Friday11 2011, 04:17:48
47

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

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

Настройка нескольких мониторов:

  • Уменьшение расходов на переключение окна
  • позволяют следить за работами в фоновом режиме (почта, компиляция и т. д.).
  • дает вам чувство свободы. Это похоже на то, чтобы быть в атриуме, а не находиться в шкафу для метлы.
  • и т.д ...
ответил JeffO 8 J000000Friday11 2011, 04:17:48
39

Самое дешевое оборудование , предоставленное консультанту , когда консультант стоит более 150 $ /час .

Полагая это в перспективе, лучшее оборудование может, по крайней мере, сделать работу 30мин более эффективной в день. Это даст 30мин * 20 дней работы в месяц = ​​600мин /месяц = ​​10 часов /месяц> более 1 день работы = 10 часов * 150 $ /час = 1500 $

Теперь, если бы у него /нее был 1500-долларовый компьютер, консультант не работал бы более эффективно? Может ли это сделать консультанта менее раздраженным?

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
38

Месяцы работы сохраняют дни планирования

(Не вкладывая достаточно времени в планирование)

ответил JeffO 8 J000000Friday11 2011, 04:17:48
27

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

В принципе, пункт 9 на Joel Test .

ответил JeffO 8 J000000Friday11 2011, 04:17:48
24

«Бросить (достаточно) тел на проблему» все еще можно использовать в некоторых местах, к сожалению , Закон Брук не противоречит этому из The Mythical Man-Month , хотя некоторые из них требуют опыта, чтобы выучить этот урок. Как правило, это не входит в мои полномочия, чтобы остановить, поскольку руководство может поверить в ложное заявление о добавлении людей и не платить за него цену.

ответил JeffO 8 J000000Friday11 2011, 04:17:48
21

Ежедневные встречи :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  
ответил JeffO 8 J000000Friday11 2011, 04:17:48
20

Покупка программного обеспечения на полке вместо его внутренней разработки.

У меня есть опыт систем управления масштабами антреприза, ориентированных как на HR, так и на биологические лаборатории.

Стоимость решения на полке составляет 50-100 тыс. фунтов стерлингов и необходима дальнейшая разработка и настройка для удовлетворения бизнес-требований.

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

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

(6 месяцев уже нанятого разработчика, работающего над другими проектами параллельно. Итак ~ 10k. И это не включает затраты на поддержку, связанные с решением для оффлайнов). Основной момент в том, что внутренне разработанная система использовалась на самом деле! Поэтому у вас есть добавленная стоимость, связанная с этим, которую я не могу рассчитать.

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
15

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

Сколько компаний использует git? Сколько компаний использует какой-то дерьмовый контроль версий предприятия?

ответил JeffO 8 J000000Friday11 2011, 04:17:48
14

Использование «простых» языков без большой выразительности

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
13

Плохие руководители проектов /руководитель команды.

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

Дозовите «Просто сделайте это быстро, мы реорганизуем позже» решает.

ответил JeffO 8 J000000Friday11 2011, 04:17:48
12

Отсутствующие требования пользователя

  

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

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
8

Производительность стоит больше, чем креативность

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

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
6

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

  • внешнее vs внутреннее программное обеспечение

  • Соответствие требованиям ISO 9001 (экономика - смягчение риска потери ПСС, если качество продукта падает)

  • разработка /аутсорсинг QA

  • процедуры разработки /сборки /выпуска /поддержки

ответил JeffO 8 J000000Friday11 2011, 04:17:48
4

Слишком много не подлежащих оплате менеджеров доставки.

Несколько лет назад в нашей компании у нас было несколько крупных бюджетных проектов, и набор был на пике. В то время наша компания нанимала слишком много менеджеров по доставке (многие из них были не ИТ!) И очень мало кодеров /тестеров. Отношение Менеджера к Программисту было буквально 1: 2. Позже, после завершения этих проектов, у нас была ситуация, когда у нас было много таких менеджеров (некоторые из них были настоящими бездельниками), сидя на скамейке, ничего не делая. У нас был один оценочный цикл, в котором все получили мало /не повышали (даже мы, трудолюбивые программисты, вздыхаем), чтобы компании не пришлось никого отнимать! К счастью, компания осознала эту ситуацию и сделала ПРАВОЗАЩИТУЮ в первом квартале этого года!

ответил JeffO 8 J000000Friday11 2011, 04:17:48
3

Оптимизация перед профилированием (например, преждевременная оптимизация).

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

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
3

Ограниченный доступ или доступ в Интернет без доступа

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

В действительности, конечно, интернет - это огромный прирост производительности, и, хотя может быть целесообразным использовать какой-то фильтр сайта для действительно изворотливых сайтов, есть что-то не так, если он блокирует файл readme visual studio или блокирует местное правительство telford страницы для разума «секс-туризм»

ответил JeffO 8 J000000Friday11 2011, 04:17:48
2

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

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

ответил JeffO 8 J000000Friday11 2011, 04:17:48
2

Слишком много бакалавров делового администрирования (или т.п.), иерархически организованных, которые пытаются применить то, о чем они думают, о современном управлении: беспокоить людей с «KPI», «SLA», а что нет, требуя «отчетов», (без, конечно, ухода за инфраструктурой для их создания), так что программисты тратят свои дни, заполняя причудливые листы EXCEL, отчеты Q4, а что нет и копируют из одного большого нового инструмента управления и вставляют в другой (кажется, правило, что эти инструменты никогда не делятся и не интегрируются друг с другом), и посещают собрания, на которых представлены отчеты и цифры (и все чувствуют себя виноватыми в том, что не смогли заполнить тот или иной KPI).

ответил JeffO 8 J000000Friday11 2011, 04:17:48

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132