it-swarm-id.com

Apa ekonomi palsu terburuk dalam pengembangan perangkat lunak?

Apa ekonomi palsu terburuk (yaitu cara-cara menghemat uang yang akhirnya lebih mahal daripada yang mereka hemat) yang lazim di industri perangkat lunak dan bagaimana Anda memerangi mereka?

126
Jon Hopkins

Utang Teknis

yaitu "Lakukan saja dengan cepat, kami akan refactor nanti". Pertama karena saya belum melihat seseorang yang terlibat dalam perilaku ini sebenarnya refactor nanti. Kedua karena melakukan sesuatu dengan cara cepat, alih-alih dengan cara yang baik membuat lebih sulit untuk menambahkan fitur di masa depan atau menyelesaikan bug di masa depan sehingga Anda akhirnya kehilangan waktu dalam jangka panjang.

Sayangnya, banyak yang masih berpikir menghemat siklus pengembang agar mereka melakukan sesuatu dengan cepat. Saya kira itu mungkin, tetapi saya belum melihatnya dalam praktik.

182
Inaimathi

Mempekerjakan 2 pengembang murah alih-alih 1 benar-benar hebat. (dengan harga yang sama)

163
user2567

Contoh saya akan menjadi kebalikan dari contoh NimChimpsky , yaitu:

Mencoba mengembangkan sesuatu di rumah yang dapat dibeli di rak.

Biasanya ini terjadi karena kegagalan untuk benar-benar memeriksa pasar untuk melihat apakah ada sesuatu yang sudah ada yang akan menyelesaikan masalah. Ini dapat diperparah oleh pengembang yang suka "menyelam" pengkodean sebelum melakukan penelitian dan oleh manajer proyek yang gagal memperhitungkan waktu = uang.

Salah satu contoh paling umum yang pernah saya lihat di bidang saya, pengembangan web, adalah perusahaan yang mencoba mengembangkan dan sistem CMS internal. Ini selalu dimulai dari kecil, tetapi segera membengkak dan di luar kendali karena fitur melesat, sementara sepanjang waktu ada banyak produk gratis dan kerangka kerja di luar sana yang akan jauh lebih cocok.

85
Dan Diplo

Tidak ada sumber daya khusus untuk manajemen proyek

Saya telah mengalami beberapa kali ketika beberapa programmer dikontrak, dan seseorang yang sudah memiliki pekerjaan harian yang menuntut seharusnya mengelola proyek, tetapi sebenarnya terlalu sibuk dengan tugas-tugas lain sehingga proyek tidak pernah benar-benar mendapatkan momentum. Pemrogram membuat "prototipe" dan semacamnya, tetapi tanpa petunjuk, sebagian besar berjalan berputar-putar agar terlihat sibuk.

Peralatan buruk untuk programmer bar

Saya pernah mengalami sebuah perusahaan di mana kebijakan itu adalah "programmer baru harus bekerja pada PC yang benar-benar tua dengan layar kecil sampai mereka membuktikan bahwa mereka layak". Tidak mengherankan bahwa kebijakan semacam itu menyebabkan seleksi negatif yang mengusir orang-orang baik yang selalu memiliki pilihan untuk bekerja di lingkungan yang lebih waras.

73
user281377

Kita dapat menghemat uang dengan membuat programer berfungsi ganda sebagai penguji/penulis teknis

Jika Anda membayar gaji programmer untuk pekerjaan penguji/penulis teknis, maka Anda membuang-buang uang dan kemungkinan mendapatkan pekerjaan berkualitas lebih rendah daripada seseorang yang telah mendedikasikan karir mereka untuk tugas itu. Juga, ketika seorang programmer menghadapi ujian tenggat waktu yang ketat dan dokumentasi sangat mungkin untuk dijatuhkan atau dilakukan setengah-setengah untuk memenuhi itu.

BTW: Pengembang SELALU menghadapi tenggat waktu yang ketat.

71
JohnFx

Meneliti/Membaca/Menulis kode tidak terkait dengan pengembangan produk adalah pemborosan sumber daya.

Beberapa programmer dan bahkan manajer percaya akan hal itu. Biasanya, mereka hanya melakukan pemrograman berdasarkan pengetahuan di kepala mereka, dan melakukan riset dan mencari jawaban ketika mereka menghadapi masalah. Mereka tidak terus meningkatkan pengetahuan mereka secara proaktif. Pendapat saya, kita harus selalu memperbarui diri, dan pengetahuan yang kita kumpulkan akan berguna bagi kita dalam memecahkan masalah yang ada dan di masa depan. Tentu saja, Anda harus mengalokasikan waktu Anda dengan bijak untuk melakukannya.

Ini juga mirip dengan jawaban Dan . Beberapa manajer hanya ingin para pengembang dengan cepat menyelam dan mengembangkan produk sesuai dengan persyaratan tanpa meneliti produk yang ada di pasar.

63
Gan

Dalam banyak kasus offshoring membutuhkan lebih banyak uang. Di perusahaan saya sangat sulit untuk mendapatkan slot karyawan baru, kami sangat didorong untuk melakukan outsourcing. Juga sulit untuk mendapatkan kontraktor di tempat; ada rasio 3: 1 di lepas pantai dan di darat yang seharusnya mereka pertahankan. Akibatnya, banyak tim hanya menyewa selusin lepas pantai dan nyaris tidak menggunakannya sama sekali, hanya supaya mereka bisa mendapatkan 4 kontraktor di tempat.

58
Jeremy

Putaran umpan balik panjang!

Itu terjadi pada semua orang: Anda membangun sesuatu yang menurut Anda luar biasa, dan ternyata Anda salah. Bukan itu masalahnya. Masalahnya adalah berapa lama Anda habiskan membangun sebelum mengetahui bahwa Anda harus berhenti.

Pada level tinggi, Anda melihat masalah ini dengan siklus rilis panjang. Jika Anda membangun selama setahun tanpa umpan balik, Anda bertaruh sepanjang tahun. Semakin sering Anda melepaskan, semakin kecil judi Anda, dan semakin baik judi Anda.

Tetapi itu juga terjadi pada level terendah. Sebagai seorang pengembang, saya sangat suka tinjauan kode yang sering (atau, lebih baik, memasangkan pemrograman) karena membatasi jumlah waktu saya dapat terus melakukan sesuatu yang bodoh sebelum seseorang berkata, "Hei, ada cara yang lebih sederhana!" Untuk alasan yang sama, saya suka unit test saya berjalan cepat dan sering, jadi saya bisa menangkap dan membunuh bug sebelum mereka tumbuh.

Setelah Anda mulai memperhatikan pentingnya loop umpan balik pendek, Anda akan melihatnya di mana-mana. E.g., gagasan militer tentang OODA loop .

50
William Pietri

Menyediakan workstation satu layar karena monitor kedua terlalu mahal. Bahkan jika itu hanya menghemat satu jam kerja setiap tahun, layar kedua masih merupakan investasi yang bagus. Saya tahu pasti bahwa pekerjaan saya telah menyelamatkan saya, berjam-jam.

Pengaturan multi-monitor dapat membuat hampir semua tugas lebih efisien, tidak hanya tugas pengembangan. Tiga monitor bahkan lebih baik daripada dua, tetapi efeknya menjadi kurang jelas dengan setiap layar tambahan.

Pengaturan multi-monitor:

  • mengurangi overhead peralihan jendela
  • memungkinkan Anda untuk mengawasi hal-hal yang berjalan di latar belakang (mail, kompilasi, dll.).
  • memberi Anda perasaan kebebasan. Ini seperti berada di atrium vs. berada di lemari sapu.
  • dll ...
47
Joseph Tanenbaum

Bukan anekdot saya sendiri, tetapi saya pernah mendengar tentang sebuah toko yang berhenti memberikan kopi gratis kepada para pengembangnya, sebaliknya mengatakan kepada mereka bahwa setiap kali mereka ingin mendapatkan kopi, mereka bebas berjalan ke kedai kopi terdekat (sekitar sepuluh menit) perjalanan setiap jalan) dan beli beberapa.

Cukup banyak definisi ekonomi palsu.

47
EricBoersma

Perangkat keras termurah diberikan kepada konsultan ketika biaya konsultan lebih dari $ 150/jam.

Menempatkannya dalam perspektif perangkat keras yang lebih baik setidaknya dapat membuat pekerjaan 30 menit lebih efektif per hari. Itu akan memberi 30 menit * 20 hari kerja per bulan = 600 menit/bulan = 10 jam/bulan> lebih dari 1 hari kerja = 10 jam * 150 $/jam = 1500 $

Sekarang bukankah konsultan akan bekerja lebih efisien jika ia memiliki komputer $ 1500? Apakah itu akan membuat konsultan tidak terlalu kesal?

Sekarang masalahnya tampaknya ada dua anggaran, satu untuk konsultan dan satu untuk perangkat keras PC.

39
Amir Rezaei

Bulan kerja menghemat hari perencanaan

(Tidak menginvestasikan waktu yang cukup ke perencanaan)

38
serg

Saya kira yang paling lazim adalah manajer tidak menyediakan alat yang dibutuhkan pengembang untuk melakukan pekerjaannya secara efisien.

Pada dasarnya, titik 9 pada ji Joel .

27
richeym

"Lempar (cukup) tubuh ke masalah" masih dapat digunakan di beberapa tempat, sayangnya. Hukum Brook tidak melawan hal ini dari The Mythical Man-Month , meskipun beberapa membutuhkan pengalaman untuk belajar pelajaran ini. Secara umum, ini bukan sesuatu yang bisa saya hentikan karena manajemen mungkin mempercayai pernyataan salah tentang menambahkan orang dan tidak harus membayar harga untuk itu.

24
JB King

Rapat setiap hari:

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

Membeli perangkat lunak rak alih-alih mengembangkannya secara internal.

Saya memiliki pengalaman sistem manajemen skala entreprise, yang fokus pada HR dan Laboratorium Biologi.

Solusi yang tidak mahal harganya £ 50-100 ribu dan membutuhkan pengembangan dan penyesuaian lebih lanjut untuk memenuhi persyaratan bisnis.

Solusi yang dikembangkan secara internal membutuhkan waktu (<6) bulan untuk berkembang, dengan proyek lain sedang dikerjakan secara paralel, dan memanfaatkan pengembang yang sudah bekerja.

Saya beralih dari sektor publik tempat kami menjalankan LIMS (sistem manajemen informasi lab) internal dan menjalankannya, ke sebuah perusahaan farmasi internasional besar di mana penerapan solusi off the shelf memakan waktu lebih dari setahun dan tidak ada tempat yang lengkap.

(6 bulan pengembang sudah dipekerjakan bekerja pada proyek-proyek lain secara paralel. Jadi ~ 10k. Dan itu tidak termasuk biaya dukungan yang terkait dengan solusi off-rak). Poin utama adalah bahwa sistem yang dikembangkan secara internal sebenarnya sedang digunakan! Jadi Anda kemudian memiliki manfaat biaya tambahan yang terkait dengan itu, yang saya tidak dapat hitung.

Saya setuju untuk situs web dasar dll, mengapa repot mengembangkan situs Anda sendiri. Tetapi untuk sistem kompleks besar dan jika Anda sudah memiliki keterampilan di rumah, saya akan membangunnya sendiri.

20
NimChimpsky

Membeli produk off-the-shelf yang mahal ketika alternatif open source lebih baik dan gratis.

Berapa banyak perusahaan yang menggunakan git? Berapa banyak perusahaan yang menggunakan kontrol versi perusahaan yang jelek?

15
hasen

Menggunakan bahasa "sederhana" tanpa banyak ekspresi

Ya, ini membuatnya lebih mudah untuk menemukan programmer untuk mempertahankan kode, tetapi membuatnya lebih sulit untuk menemukan baik programmer yang tidak hanya mempelajari kata kunci terbaru yang akan membuat mereka dipekerjakan. Ya, itu membuat kode bit individu lebih mudah untuk dipahami, tetapi juga membuatnya sekaku 2x4 dan meningkatkan volume kode yang perlu dipahami. Ya, itu didukung oleh sebuah perusahaan besar, tetapi mengatakan perusahaan besar berinovasi dengan lambat dan birokratis.

14
dsimcha

Manajer proyek/pemimpin tim yang buruk.

Karena satu orang yang tidak kompeten memiliki kekuatan untuk merusak pekerjaan sekelompok orang. Pada akhirnya, proyek akan jauh lebih baik tanpa keputusan manajemen atas (pimpinan proyek/tim).

Dosis "Lakukan saja dengan cepat, kami akan refactor nanti" memutuskan.

13
Amir Rezaei

Persyaratan pengguna tidak ada

Langkah penting dan sulit dalam merancang produk perangkat lunak adalah menentukan apa yang sebenarnya diinginkan pelanggan untuk dilakukan.

Percaya atau tidak kadang-kadang bagian ini hilang atau ketinggalan jaman. Yang perlu diperhatikan adalah bahwa seseorang menciptakan fungsionalitas yang tidak pernah diminta oleh pengguna akhir.

12
Amir Rezaei

Produktivitas bernilai lebih dari kreativitas

Kreativitas sulit diukur secara umum, dan paling sering tidak mungkin untuk diamati, apalagi ukurannya, ketika menyangkut pengembangan perangkat lunak. Produktivitas, di sisi lain, dapat diukur (seringkali buruk), dan dapat diamati.

Akibatnya, pengembang yang dapat (menulis lebih banyak baris kode | menulis kode lebih cepat | membaca technobabble lebih cepat dalam menanggapi pertanyaan | lebih produktif) cenderung lebih dihargai daripada yang (menggunakan lebih sedikit baris kode untuk menyelesaikan masalah yang sama | membutuhkan waktu lebih lama untuk menulis kode, tetapi menghasilkan produk yang lebih dapat diandalkan | memahami materi pelajaran dengan cukup baik untuk menjawab pertanyaan dengan jelas, mudah dipahami, Bahasa Inggris | menyelesaikan masalah secara kreatif).

8
blueberryfields

Semua di bawah ini bisa buruk jika digunakan atau tidak digunakan dengan tidak tepat

  • perangkat lunak internal vs internal

  • Kepatuhan ISO 9001 (ekonomi - mitigasi risiko kerugian SPM jika kualitas produk turun)

  • pengembangan/outsourcing QA

  • prosedur pengembangan/pembangunan/pelepasan/dukungan

6
bobah

Memiliki terlalu banyak manajer pengiriman yang tidak dapat ditagih.

Beberapa tahun yang lalu, di perusahaan kami, kami memiliki beberapa proyek anggaran besar yang sedang berlangsung dan rekrutmen sedang memuncak. Pada waktu itu perusahaan kami mempekerjakan terlalu banyak manajer pengiriman (Banyak dari mereka bukan IT!) Dan sangat sedikit coders/penguji. Rasio Manajer terhadap Pemrogram adalah 1: 2. Kemudian, setelah menyelesaikan proyek-proyek itu, kami menghadapi situasi di mana kami memiliki banyak manajer ini (beberapa di antaranya adalah pemalas) yang duduk di bangku tanpa melakukan apa pun. Kami memiliki satu siklus penilaian di mana setiap orang mendapat sedikit/tidak ada kenaikan gaji (Bahkan kami programmer pekerja keras, desah) sehingga perusahaan tidak perlu memberhentikan siapa pun! Untungnya, perusahaan menyadari situasi ini dan melakukan RIGHTSIZING pada kuartal pertama tahun ini!

4
mananjani

Terbatas atau tidak ada akses internet

Karena jelas karyawan Anda akan menggunakan internet untuk bermain game facebook dan tidak terlalu mencari jawaban untuk pertanyaan teknis di Stackoverflow.

Pada kenyataannya tentu saja internet adalah dorongan produktivitas yang sangat besar, dan walaupun mungkin tepat untuk menggunakan semacam filter situs untuk situs yang benar-benar cerdik, ada sesuatu yang salah jika memblokir file readme studio visual atau memblokir halaman pemerintah daerah telford dengan alasan "pariwisata seks"

3
jk.

Pengoptimalan sebelum membuat profil (alias optimasi prematur).

Sudah terlalu sering saya melihat seseorang meraih solusi cerdas yang tidak perlu mempersulit pemeliharaan dan keterbacaan dengan alasan lebih cepat. Secara alami, kode tersebut belum ditandai (bahkan dengan micro-benchmark), sehingga dengan cepat menjadi "lebih cepat berdasarkan argumen yang lebih persuasif" pada bagian kode yang kemungkinan besar tidak mempengaruhi kinerja keseluruhan keseluruhan aplikasi oleh banyak.

Karena itu, ini adalah ekonomi yang sangat palsu, dan jenis ekonomi palsu yang kadang-kadang melibatkan bahkan para profesional yang berpengalaman sekalipun.

3
Edwin Buck

Membuat pengembang Anda menggunakan monitor 15 inci dan PC dengan spesifikasi rendah karena merupakan standar perusahaan.

Monitor berukuran wajar yang murah, cepat untuk menginstal dan membuat programmer lebih produktif serta membuat programmer Anda berpikir Anda peduli tentang mereka.

2
Ian

Terlalu banyak Sarjana Administrasi Bisnis (atau sejenisnya), yang diorganisasikan secara hierarki, yang mencoba menerapkan apa yang mereka pikirkan tentang manajemen modern: Mengganggu orang-orang dengan "KPI", "SLA" dan yang tidak, membutuhkan "laporan" (tanpa, tentu saja, peduli dengan infrastruktur untuk menghasilkan mereka), sehingga programmer menghabiskan hari-hari mereka dengan mengisi lembar Excel yang mewah, laporan Q4 dan apa yang tidak dan menyalin dari satu alat manajemen baru yang hebat dan menempel ke yang lain (tampaknya menjadi aturan bahwa alat-alat ini tidak pernah saling memadukan atau tidak bisa saling menyatu), dan menghadiri pertemuan di mana laporan dan angka disajikan (dan semua orang dibuat merasa bersalah karena gagal memenuhi KPI ini atau itu).

2
Ingo