Які найгірші помилкові економії в розробці програмного забезпечення? [зачинено]

Які найгірші помилкові економії (тобто способи економії грошей, які в кінцевому рахунку коштують дорожче, ніж заощаджують), є поширеними в галузі програмного забезпечення та як боротися з ними?

Технічний борг

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

На жаль, багато хто досі вважає, що це економить цикли розробників, щоб змусити їх робити щось швидко. Я думаю, що це можливо, але я ще не бачив цього на практиці.

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

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

Намагаючись розробити в будинку щось, що можна купити поза доріжкою.

Зазвичай це відбувається через неможливість фактичної перевірки ринку, щоб перевірити, чи вже існує щось, що вирішить проблему. Це може ускладнитись розробниками, які люблять «зануритися в» кодування перед тим, як проводити будь-які дослідження, та керівниками проектів, які не встигають взяти до уваги той час = гроші.

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

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

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

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

Я колись переживав компанію, в якій політика полягала в тому, що "нові програмісти повинні працювати на справді старому ПК з невеликим екраном, поки вони не докажуть, що вони гідні". Не дивно, що така політика викликала негативний вибір, який відганяв добрих людей, які завжди мають вибір працювати в більш здорових умовах.

Ми можемо заощадити гроші, зробивши програмістів вдвічі більше, ніж тестерів / технічних авторів

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

BTW: Розробники ЗАВЖДИ наближені до граничного строку.

Дослідження / читання / Написання коду, не пов'язаного з розробкою продукту, є марною витратою ресурсів.

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

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

У багатьох випадках офшоринг коштує більше грошей. У моїй компанії дуже важко отримати нові слоти для співробітників, нас сильно підштовхують до аутсорсингу. Також важко потрапити на місце підрядників; існує співвідношення офшорних 3: 1 до суходольних, які вони повинні підтримувати. Отже, багато команд просто наймають дюжину офшорних і ледве їх не використовують взагалі, лише щоб вони могли отримати 4 підрядники на місці.

Довгі петлі зворотного зв'язку!

Це трапляється з усіма: ви будуєте щось, що, на вашу думку, є дивним, і виявляється, ви помилялися. Це не проблема. Проблема полягає в тому, як довго ви витрачаєте будівництво, перш ніж з’ясувати, що вам слід зупинитися.

На високому рівні ви бачите цю проблему з довгими циклами випуску. Якщо ви будуєте рік без зворотнього зв'язку, ви граєте цілий рік. Чим частіше ви звільняєтесь, тим менше азартних ігор, і тим краще ви отримуєте азартні ігри.

Але це також відбувається на найнижчих рівнях. Як розробник, мені дуже подобаються часті перегляди коду (або, ще краще, парне програмування), оскільки це обмежує кількість часу, коли я можу продовжувати робити щось глухо, перш ніж хтось скаже: "Ей, є простіший спосіб!" З цієї ж причини мені подобається, що мої тести на одиниці запускаються швидко і часто, тому я можу ловити і вбивати помилок, перш ніж вони виростають.

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

Не мій власний анекдот, але я одного разу почув про магазин, який перестав надавати безкоштовну каву своїм розробникам, сказавши їм, що щоразу, коли вони хочуть отримати каву, вони можуть піти до найближчої кав’ярні (щось на зразок десяти хвилин подорожувати кожним шляхом) та придбати якусь.

Досить велике значення помилкової економії.

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

Налаштування мультимонітора може зробити практично будь-яку задачу більш ефективною, не тільки завданнями розробки. Три монітора навіть краще, ніж два, але ефект стає менш вираженим з кожним додатковим екраном.

Налаштування кількох моніторів:

• зменшення перемикання вікон накладні
• дозволяють стежити за матеріалами, що працюють у фоновому режимі (пошта, компіляція тощо).
• дати вам відчуття свободи. Це як бути в атріумі проти перебування в шафі з мітлою.
• тощо ...

Найдешевше обладнання, що надається консультанту, коли консультант коштує більше 150 доларів / годину .

Якщо зробити це в перспективі, то краще обладнання може принаймні зробити роботу на 30 хвилин ефективнішою на день. Це дало б 30 хв * 20 днів роботи на місяць = 600 хв / місяць = 10 годин / місяць> більше, ніж робота на 1 день = 10 годин * 150 $ / година = 1500 $

Тепер чи не працював би консультант ефективніше, якби у нього був комп'ютер на 1500 доларів? Це зробило б консультанта менш роздратованим?

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

Місяці роботи економить дні планування

(Не вкладаючи достатньо часу для планування)

Я підозрюю, що менеджери просто не надають розробникам інструменти, необхідні для ефективної роботи.

В основному, пункт 9 про тест Джоеля .

На жаль, у деяких місцях все ще можна використовувати «кидання (достатньо) тіл при проблемі» . Закон Брука суперечить цьому "Міфічного чоловіка-місяця" , хоча для вивчення цього уроку для деяких потрібен досвід. Як правило, це не щось, на що я можу зупинитись, оскільки керівництво може вважати помилковим твердженням про додавання людей і не потрібно платити за це.

Щоденні зустрічі :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  

Купуйте програмне забезпечення на полиці, а не розробляйте його всередині країни.

Я маю досвід систем управління масштабами підприємств, орієнтованих як на HR, так і на біологічні лабораторії.

Рішення, що продається на полиці, коштувало 50-100 тис. Фунтів стерлінгів і потребувало подальшого розвитку та налаштування для задоволення бізнес-вимог.

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

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

(6 місяців вже найнятого розробника, який працює над іншими проектами паралельно. Отже, ~ 10 к. А це не включає витрати на підтримку, пов'язані з рішенням, що не входить в режим зберігання). Основний момент полягає в тому, що фактично використовується внутрішньо розроблена система! Тож у вас є додаткова вигода від вартості, пов'язана з цим, яку я не можу підрахувати.

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

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

Скільки компаній використовують git? Скільки компаній використовують якийсь хитрий контроль версій для підприємств?

Використання "простих" мов без особливої ​​виразності

Так, це полегшує пошук програмістів для підтримки коду, але ускладнює пошук хороших програмістів, які не просто вивчать найновіші модні слова, які дозволять їх найняти. Так, це полегшує розуміння окремих біт-кодів, але також робить його таким же жорстким, як 2x4 та збільшує обсяг коду, який потрібно зрозуміти. Так, це підтримується величезною корпорацією, але сказано, що величезна корпорація здійснює інновації повільно і бюрократично.

Погані керівники проектів / керівництво команди.

Оскільки одна некомпетентна особа має владу руйнувати роботу групи людей. Зрештою, проект був би набагато кращим без рішень вищого керівництва (проект / команда).

Дозує рішення "Просто зробіть це швидко, ми підемо рефактор згодом".

Відсутні вимоги користувача

Важливим і важким кроком проектування програмного продукту є визначення того, що клієнт насправді хоче цього зробити.

Вірите чи ні, інколи ця частина відсутня або застаріла. Що стосується вартості, це те, що створюється функціонал, про який кінцевий користувач ніколи не просив.

Продуктивність коштує більше, ніж творчість

Творчість важко виміряти загалом, і найчастіше неможливо навіть спостерігати, не зважаючи на те, що стосується розробки програмного забезпечення. З іншого боку, продуктивність може бути мірою (часто погано), і її можна спостерігати.

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

Все нижче може бути поганим при неправильному використанні або не використанні

• зовнішнє проти домашнього програмного забезпечення

• Відповідність ISO 9001 (економія - зменшення ризику втрати MSS, якщо якість продукції падає)

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

• процедури розробки / побудови / випуску / підтримки

Занадто багато менеджерів з доставки, які не підлягають оплаті.

Пару років тому в нашій компанії було кілька великих бюджетних проектів, і підбір персоналу був на піку. У той час наша компанія найняла занадто багато менеджерів з доставки (багато з них не були ІТ!) І дуже мало кодерів / тестерів. Співвідношення менеджер та програміст становило буквально 1: 2. Пізніше, після завершення цих проектів, у нас виникла ситуація, коли у нас багато з цих менеджерів (деякі з них були справжніми негідниками) сиділи на лавці, нічого не роблячи. У нас був один цикл оцінювання, коли кожен мало / не підвищував (навіть нас, працьовиті програмісти, зітхають), так що компанії не потрібно нікого звільняти! На щастя, компанія усвідомила таку ситуацію і зробила ПРАВИЛЬНИЙ В першому кварталі цього року!

Оптимізація перед профілюванням (також передчасна оптимізація).

Занадто багато разів я бачив, як хтось досягає розумного рішення, яке непотрібно ускладнює технічне обслуговування та читаність на тій підставі, що це швидше. Природно, що код не був позначений стендом (навіть не з мікро-орієнтирами), тому він швидко стає "швидшим на основі більш переконливого аргументу" для розділу коду, який, швидше за все, не вплинув на загальну продуктивність всього застосування багато.

Як така, це дуже хибна економіка і така помилкова економія, яка періодично заплутує навіть досвідчені профі.

Обмежений доступ до Інтернету або його відсутність

Тому що, очевидно, ваші співробітники використовуватимуть Інтернет, щоб грати у фейсбук ігри, а не надто дослідницькі відповіді на технічні питання Stackoverflow.

Насправді, звичайно, Інтернет є величезним підвищенням продуктивності праці, і хоча може бути доречним використовувати якийсь фільтр сайтів для справді химерних сайтів, щось не так, якщо він з причини блокує файл візуальної студії readme або блокує телфордські місцеві сторінки "сексуальний туризм"

Змусити розробників використовувати 15-дюймовий монітор та низькоспеціальний ПК, оскільки це корпоративний стандарт.

Монітори розумного розміру дешеві, швидкі в установці та роблять програмістів більш продуктивними, а також змушують ваших програмістів думати, що ви їх дбаєте.

Забагато бакалаврів ділового адміністрування (тощо), ієрархічно організованих, що намагаються застосувати те, що, на їхню думку, стосується сучасного менеджменту: турбуючи людей з "KPI", "SLA" і що ні, не вимагаючи "звітів" (без, звичайно, піклуючись про інфраструктуру для їх генерування), щоб програмісти витрачали свої дні на заповнення вигадливих аркушів EXCEL, звітів про Q4, а що ні, і копіюють з одного чудового нового інструмента управління та вставляють в інший (здається, правило, ці інструменти ніколи не інтегруються і не інтегруються між собою), і відвідуйте засідання, де представлені доповіді та цифри (і всі відчувають себе винуватими в тому, що не змогли повністю виконати той чи інший КПІ).