Mengapa proyek-proyek TI besar cenderung gagal atau memiliki kelebihan biaya / jadwal besar? [Tutup]

Saya selalu membaca tentang transformasi skala besar atau proyek integrasi yang total atau hampir total bencana. Bahkan jika mereka entah bagaimana berhasil, biaya dan jadwal yang dikeluarkan sangat besar. Apa alasan sebenarnya di balik proyek besar lebih rentan terhadap kegagalan. Dapatkah tangkas digunakan dalam proyek semacam ini atau pendekatan tradisional masih yang terbaik.

Salah satu contoh dari Australia adalah proyek Payroll Queensland di mana mereka mengubah kriteria keberhasilan tes untuk memberikan proyek.
Lihat beberapa proyek lain yang gagal dalam pertanyaan SO ini ( di Wayback Machine )

Apakah Anda punya pengalaman pribadi untuk dibagikan?

Alasan utamanya adalah peningkatan cakupan , yang digambarkan oleh buku "The Pragmatic Programmer" sebagai:

• fitur bloat
• featureism merayap
• persyaratan creep

Ini adalah aspek dari sindrom boiled-frog.

Gagasan dari berbagai metode "gesit" adalah untuk mempercepat umpan balik dan - semoga - memperbaiki evolusi proyek pada waktunya.

Tetapi alasan lainnya adalah manajemen rilis : jika Anda tidak diarahkan untuk merilis proyek (betapapun tidak sempurna), kemungkinan itu akan gagal (karena dirilis terlalu terlambat, dengan fitur kereta terlalu banyak, dan lebih sulit untuk memperbaiki / memperbarui / meningkatkan).

Itu tidak berarti Anda harus memiliki tanggal rilis yang tetap, tetapi itu berarti Anda harus dapat setiap saat membangun versi yang sedang berjalan dari program Anda, untuk menguji / mengevaluasi / merilisnya.

Posting blog " Proyek terlambat terlambat satu hari pada suatu waktu " berisi lebih banyak contoh:

Saya tahu hal 'Getting Real' yang harus dilakukan adalah Flex cakupan dan menjaga tanggal peluncuran tetap, tetapi itu tidak berfungsi jika ada fungsi yang disepakati yang tidak dapat diselesaikan pada waktunya.

Itu sebabnya kami tidak menganjurkan spesifikasi atau "fungsionalitas yang disepakati." Itulah akar masalahnya - mengatakan Anda tahu segalanya tentang apa yang Anda butuhkan dan bagaimana itu akan diterapkan bahkan sebelum piksel pertama dicat atau garis kode ditulis .

Ketika Anda meramalkan masa depan yang kaku dengan hadiah fleksibel, Anda dalam kesulitan. Masa depan yang kaku adalah hal yang paling berbahaya. Mereka tidak meninggalkan ruang untuk penemuan, kemunculan, dan kesalahan yang membuka pintu baru.

Biasanya kerumitan proyek diremehkan .

Steve McConnell (dari ketenaran "Kode Lengkap") memiliki daftar kesalahan klasik .

Beberapa praktik pembangunan yang tidak efektif telah dipilih begitu sering, oleh begitu banyak orang, dengan hasil buruk yang dapat diprediksi sehingga mereka pantas disebut "kesalahan klasik" ...

Bagian ini menyebutkan tiga lusin kesalahan klasik. Saya pribadi telah melihat masing-masing kesalahan ini setidaknya satu kali, dan saya telah membuat banyak dari mereka sendiri ...

Penyebut umum dalam daftar ini adalah bahwa Anda tidak perlu mendapatkan perkembangan yang cepat jika Anda menghindari kesalahan, tetapi Anda pasti akan mendapatkan perkembangan yang lambat jika Anda tidak menghindarinya ...

Untuk kemudahan referensi, daftar ini telah dibagi sepanjang dimensi kecepatan pengembangan orang, proses, produk, dan teknologi.

Orang-orang

# 1: Motivasi yang rusak ...

# 2: Personil yang lemah ...

# 3: Karyawan bermasalah yang tidak terkontrol ...

# 4: Pahlawan ...

# 5: Menambahkan orang ke proyek yang terlambat ...

# 6: Kantor berisik, ramai ...

# 7: Gesekan antara pengembang dan pelanggan ...

# 8: Harapan yang tidak realistis ...

# 9: Kurangnya sponsor proyek yang efektif ...

# 10: Kurangnya dukungan pemangku kepentingan ...

# 11: Kurangnya input pengguna ...

# 12: Politik ditempatkan di atas substansi ...

# 13: Pemikiran angan-angan ...

Proses

# 14: Jadwal yang terlalu optimis ...

# 15: Manajemen risiko yang tidak memadai ...

# 16: Kegagalan kontraktor ...

# 17: Perencanaan yang tidak memadai ...

# 18: Pengabaian perencanaan di bawah tekanan ...

# 19: Waktu terbuang selama front end fuzzy. The "fuzzy front end" adalah waktu sebelum proyek dimulai, waktu yang biasanya dihabiskan dalam proses persetujuan dan penganggaran ...

# 20: Aktivitas hulu yang diperpendek ... Juga dikenal sebagai "melompat ke pengkodean" ...

# 21: Desain tidak memadai ...

# 22: Jaminan kualitas yang diperpendek ...

# 23: Kontrol manajemen tidak mencukupi ...

# 24: Konvergensi prematur atau terlalu sering. Sesaat sebelum suatu produk dijadwalkan untuk dirilis ada dorongan untuk mempersiapkan produk untuk dirilis - meningkatkan kinerja produk, mencetak dokumentasi akhir, memasukkan kait sistem bantuan akhir, memoles program instalasi, mematikan fungsi yang tidak akan menjadi siap tepat waktu, dan seterusnya ...

# 25: Menghilangkan tugas-tugas yang diperlukan dari perkiraan ...

# 26: Berencana untuk mengejar ketinggalan nanti ...

# 27: Pemrograman kode-seperti-neraka Beberapa organisasi berpikir bahwa pengodean yang cepat, longgar, serba bisa adalah rute menuju pengembangan cepat ...

Produk

# 28: Persyaratan pelapisan emas. Beberapa proyek memiliki persyaratan lebih dari yang mereka butuhkan sejak awal ...

# 29: Creep fitur ...

# 30: Pelapisan emas pengembang. Pengembang terpesona oleh teknologi baru dan kadang-kadang ingin mencoba fitur baru ... - apakah itu diperlukan dalam produk mereka ...

# 31: Dorong aku, tarik aku negosiasi ...

# 32: Pengembangan berorientasi penelitian. Seymour Cray, perancang superkomputer Cray, mengatakan bahwa ia tidak berusaha melampaui batas teknik di lebih dari dua area sekaligus karena risiko kegagalan terlalu tinggi (Gilb 1988). Banyak proyek perangkat lunak dapat belajar pelajaran dari ...

Teknologi

# 33: Sindrom perak-peluru ...

# 34: Penghematan estimasi berlebihan dari alat atau metode baru ... Kasus khusus penghematan estimasi berlebihan muncul ketika proyek menggunakan kembali kode dari proyek sebelumnya ...

# 35: Berpindah alat di tengah proyek ...

# 36: Kurangnya kontrol kode sumber otomatis ...

Proyek Lebih Besar = Lebih Kompleksitas
Lebih Kompleksitas = Lebih Banyak Ketidakpastian
Lebih Banyak Ketidakpastian = Lebih Keras untuk Diperkirakan
Lebih Keras untuk Diperkirakan = Perkiraan
Buruk Perkiraan Buruk = Biaya Overruns

Saya menyalahkan proses penawaran. Ini penghargaan kelompok yang dapat membuat transaksi terlihat termurah / tercepat di atas kertas.

Orang-orang yang menyusun penawaran tidak ingin membuang waktu mereka jika mereka tidak memiliki kesempatan untuk menang, sehingga estimasi normal mereka ditunda. Saya tahu orang-orang yang telah menetapkan sakelar normal, bukan sakelar POE untuk menghemat $ 80. Tetapi proyek tersebut membutuhkan POE karena memiliki kamera IP. $ 80 itu harus dikeluarkan, tapi sekarang di luar spesifikasi.

Saya memiliki keyakinan kuat bahwa proyek 2 bulan $ 2.000.000 masih akan memakan waktu 2 bulan $ 2.000.000 tidak peduli berapa banyak tawaran yang Anda dapatkan. Jika menurut Anda melakukannya dengan benar itu mahal, tunggu dan lihat seberapa mahal melakukan itu dengan salah.

Salah satu alasan yang mungkin adalah bahwa estimasi didasarkan pada proyek yang lebih kecil, dengan asumsi pertumbuhan linear dalam biaya dengan ukuran proyek, ketika sebenarnya pertumbuhan biaya adalah kuadratik karena meningkatnya kompleksitas, durasi proyek yang lebih lama (lebih banyak waktu untuk perubahan kebutuhan) dll. Estimasi adalah keras, dan semakin besar proyek, semakin sulit untuk memperkirakan dengan benar.

Alasan lain adalah estimasi bias yang optimis: Untuk memenangkan penawaran, estimasi kasus terbaik digunakan untuk menghitung harga. Semakin besar proyek, semakin kecil kemungkinan skenario terbaik. Aturan penawaran memungkinkan penawar yang paling optimis menerima penerimaan, sehingga meskipun 5 vendor membuat perkiraan realistis dan keenam terlalu optimis, yang optimis memenangkan penawaran dan gagal kemudian. Jadi ini semacam seleksi negatif.

Biaya tidak menghalangi jadwal di mata 'manajemen' yang merupakan perbedaan penting untuk dibuat. Seperti yang kita ketahui, "sembilan wanita tidak bisa menghasilkan bayi dalam satu bulan" , namun Anda akan terkejut melihat betapa banyak orang berpikir bahwa masalah menurun secara mendalam sehubungan dengan jumlah uang yang diberikan kepada mereka. Manajemen proyek yang buruk, sering memanifestasikan dirinya dalam bentuk manajemen mikro adalah penyebab utama sebagian besar proyek tangki (dalam pengalaman saya). Manajemen mikro menendang ketika 'manajemen' menyadari bahwa ada sesuatu yang keluar dari kendali dan mereka tidak mengerti mengapa.

Ketika itu bukan penyebabnya, hasil yang diharapkan dari proyek itu mungkin tidak dapat dipertahankan untuk memulai. Dalam pengalaman saya, jika kerangka waktu proyek terlalu pendek, orang akan sangat takut membuat kesalahan yang menghasilkan 'pekerjaan ganda' sehingga mereka tidak mendapatkan banyak hal yang dilakukan sama sekali.

Inilah sebabnya mengapa manajemen harus diisi dengan programmer berpengalaman yang memiliki sejarah tim terkemuka yang menghasilkan proyek yang sukses. Orang seperti itu mungkin berkata "Tidak mungkin kita bisa melakukan itu secara bertanggung jawab" terlepas dari kemungkinan pendapatan, dan tidak akan berada dalam manajemen lama, itulah sebabnya banyak dari kita (akhirnya) menjawab MBA bukan PHD.

Saya kehilangan hitungan jumlah perusahaan tempat saya bekerja ketika seorang non-programmer bertugas merekrut programmer. Saya pernah wawancara di mana manajer perekrutan ingin melakukan apa-apa selain membahas acara olahraga baru-baru ini (saya pikir itu adalah pertandingan sepak bola). Jika orang yang Anda pimpin memiliki lebih banyak inspirasi dari pelatih NFL daripada Knuth, proyek ini akan gagal.

Sesekali, Anda mengalami sesuatu yang terencana dengan baik, dipahami dengan baik, realistis dan tampaknya lurus ke depan. Untuk alasan apa pun, enam bulan menuju pengembangan, semuanya berbalik sendiri. Itu terjadi. Namun, jarang ada penyebab mendasar dari suatu proyek menjadi tong daging babi yang dimuliakan.

Namun, saya harus mengakui .. jika Anda menonton berita, Anda mungkin melihat kecelakaan sepeda motor sesekali atau kecelakaan kereta api. Anda tidak pernah mendengar tentang jutaan sepeda motor atau kereta yang tiba tepat waktu setiap hari tanpa insiden. Hal yang sama berlaku untuk proyek. Tentu, menarik melihat otopsi publik tentang sesuatu yang berjalan sangat, sangat buruk, tetapi Anda hampir tidak pernah mendengar tentang hal-hal yang berjalan sangat, sangat baik. Saya pikir proyek yang dikerjakan masih pengecualian, bukan norma.

Sebagian besar waktu kombinasi dari dua atau lebih dari yang berikut:

• masalah kolaborasi antar departemen
• politik ... terlalu banyak politik ...
• tim yang salah
• penjadwalan yang tidak realistis
• mengubah ruang lingkup tanpa metodologi yang tepat
• informasi yang hilang

Buku yang bagus tentang masalah ini: Death March .

Orang-orang cenderung berpikir bahwa pengembangan perangkat lunak adalah proses prediksi, mencoba mengukur dan memperkirakan hal-hal satu tahun ke depan. Ini tidak mungkin! Membangun perangkat lunak bukanlah pembuatan baut.

Mengikuti "tren" yang sama, mereka mencoba melakukan analisis besar (sekali lagi satu tahun ke depan) dengan berpikir bahwa mereka akan mencakup semua kemungkinan, dan kemudian, mengubah programmer menjadi juru ketik belaka. Bagaimana mungkin orang berpikir bahwa ini bisa berhasil? Perilaku semacam ini hanya mengarah pada perkiraan buruk dan banyak birokrasi.

Semakin besar proyek, semakin besar kemungkinan Anda bekerja untuk organisasi besar. Semakin besar organisasi, semakin banyak lapisan manajemen. Semakin banyak lapisan manajemen, semakin sulit untuk berita buruk ("kita tidak dapat memiliki apa yang kita inginkan untuk apa yang kita mampu") untuk menjadikannya rantai komando. Semakin sedikit berita buruk yang dapat menjadikannya rantai komando, semakin besar kemungkinan rencana fantasi akan diterima dan kemudian ditahan lama setelah diketahui bahwa hal itu tidak dapat dipertahankan.

Proyek perangkat lunak dari semua ukuran "cenderung gagal" atau "memiliki kelebihan biaya". Anda tidak mendengar tentang biaya overrun di bisnis sekitar sudut, tetapi Anda lakukan mendengar tentang hal-hal seperti FBI sistem Virtual Case, atau Denver Bandara sistem penanganan bagasi. Jadi saya akan membuat klaim bahwa tidak semua sistem besar gagal, juga tidak semua sistem besar mengalami kelebihan biaya / jadwal.

Saya telah menemukan sistem besar yang datang tepat waktu (jadwal bergerak sekali dan hanya sekali selama proyek) dan pada spec (saya tidak punya akses ke informasi anggaran karena kami hanya 1 dari banyak pemasok). Salah satu yang masih membuat saya terkesan (dan saya telah menulis sedikit tentang hal itu di situs ini) adalah sistem manajemen pelanggan terpadu yang besar untuk klien finansial besar (dalam 100 pertama dari kekayaan 500). Saya memperkirakan bahwa mereka meniup sekitar $ 100rb / hari (lebih dari setahun) pada gaji orang selama panggilan konferensi.

Dalam kasus sistem penanganan bagasi, manajer perangkat lunak mengatakan "berdasarkan proyek dengan ukuran dan kompleksitas ini, akan dibutuhkan 4 tahun untuk membangun dan men-debug sistem ini." Manajer penjualan dan eksekutif mengatakan "bandara dibuka dalam 2 tahun, kami mengatakan kepada klien itu akan memakan waktu 2 tahun, sehingga Anda memiliki 2 tahun untuk melakukannya." Tes untuk mengetahui apakah Anda seorang programmer atau salah urus adalah jawaban sederhana untuk pertanyaan berikut: "apakah sistem penanganan bagasi terlambat atau tepat waktu?"

Jika pelanggan tahu persis apa yang mereka inginkan (dan sangat sedikit yang dilakukan), mereka akan sangat jauh di jalan untuk menjaga biaya dan waktu di bawah kendali (dan ini adalah orang-orang yang cenderung melakukan offshoring dengan cukup baik). Jika proyek Anda harus memenuhi setiap fitur yang mungkin pelanggan Anda mungkin impikan, dan setiap departemen memiliki hak veto ketika batu bata emas peliharaan mereka ditambahkan ke proyek, maka Anda ditakdirkan untuk menolak kegagalan sejak awal (seperti FBI's Proyek VCF).

Persepsi Realitas

Berikut adalah deskripsi terbaik dari masalah ini yang pernah saya temukan. Ayunan Pohon Dari businessballs.com

Saya diperkenalkan dengan konsep "Persepsi Realitas" sejak awal di program saya. Untuk ini saya benar-benar berterima kasih. Saya percaya bahwa ini adalah alasan terbesar mengapa setiap proyek gagal, bukan hanya proyek TI .

Salah satu alasan kegagalan adalah bahwa proyek besar biasanya merupakan proyek penting yang penting bagi bisnis. Ketika proyek dan tugas menonjol, itu mendorong orang untuk berbohong.

Bos Anda ingin Anda memperkirakan status penyelesaian Anda di sisi atas. Dia ingin memperkirakan kelebihan dan penundaan di sisi rendah. Ketika Anda menghadapi masalah, dia tidak ingin mendengar bahwa itu akan menambah tiga minggu untuk tugas; dia ingin mendengar Anda bisa mengerjakannya dalam beberapa jam malam ini.

Dan seterusnya dan seterusnya.

Saya mengerjakan satu proyek beberapa tahun yang lalu, untuk seorang klien. Saya dibawa masuk setelah penawaran dan rencana proyek selesai. Ada tekanan terus-menerus untuk pergi lebih cepat, lebih cepat, dan keputusan pemotongan biaya yang konyol, terlalu banyak staf, tidak ada sumber daya untuk mereka; tidak ada meja, komputer, apa pun.

Akhirnya, saya menemukan bahwa proyek itu menawar 7 bulan dan 16 juta dolar. Saya memperkirakan di bagian belakang sebuah amplop seharusnya 24 bulan dan 50 hingga 100 juta. Saya mengatur pertemuan dengan manajer saya dan manajernya, dan mempresentasikan kasus saya, dan bagaimana kami TIDAK mendekati pengiriman tepat waktu atau anggaran; mereka meremehkan semua masalah. Di akhir pertemuan, CIO menelepon dan memberi tahu kedua manajer ini pada dasarnya apa yang saya katakan, dengan pengecualian dari cacat dalam penawaran asli.

Saya memiliki kesempatan untuk memulai proyek ketika mereka mengubah teknologi menjadi sesuatu yang tidak saya kuasai. Saya berbicara dengan seseorang jauh kemudian. Proyek itu akhirnya dibatalkan ketika sekitar setengahnya selesai ... pada 12 bulan dan 35 juta dolar.

Proyek besar profil tinggi membuat orang enggan berkata, "ini kesalahan". Kesalahan tidak ditoleransi.

Menguraikan sedikit tentang jawaban VonC:

Proyek-proyek besar ini cenderung memiliki mentalitas "semua atau tidak sama sekali". Proyek sebagaimana didefinisikan harus dirilis dalam sekali jalan - sering karena itu adalah perubahan dari sistem yang ada.

Ini berarti bahwa masalah creep fitur / persyaratan lebih sulit untuk diatasi sehingga ketika proyek mulai membuahkan hasil, sering dianggap tidak lagi memenuhi persyaratan. Ini dapat diperburuk jika sistem yang ada telah diperbarui atau teknologi telah pindah sementara itu.

Apa solusinya?

Saya tidak benar-benar tahu karena tidak ada yang ingin memiliki dua sistem berjalan secara paralel dengan sekumpulan fungsi yang berubah yang memisahkan keduanya.

Kompleksitas proyek besar dapat diperburuk oleh tekanan politik eksternal. Satu departemen mungkin memiliki gagasan yang sangat jelas dan terfokus tentang apa yang mereka inginkan dalam sistem baru, tetapi kemudian departemen terkait melompat dengan lusinan permintaan di sepanjang baris "Ya, selama Anda melakukan itu, mengapa Anda tidak melakukannya? melakukan tugas sampingan kecil ini untuk kita juga? " Anda mungkin mulai dengan mengatakan "Tidak, itu di luar jangkauan.", Tetapi kemudian pertarungan politik di antara deaprtments dimulai, dan anggaran untuk proyek terancam kecuali semua orang mendapatkan bagian dari kue mereka.

Selama bertahun-tahun, polisi setempat kami tidak dapat mencari pelat parsial melalui sistem kendaraan bermotor, suatu fitur yang tampaknya sangat tidak masuk akal. Saya bertanya kepada seorang teman, apa yang sangat sulit untuk menambahkan fitur ini, dan mereka mengatakan bahwa setiap kali mereka mengusulkan untuk beralih ke basis data modern, setiap departemen lain di negara bagian yang berinteraksi dengan sistem kendaraan bermotor ingin mendapatkan bagian dari sistem diperbaiki juga. Hasilnya adalah kunci lengkap dalam modernisasi TI. Akhirnya negara mengumpulkan modal yang cukup untuk melakukan upaya modernisasi sistem yang luas, yang kemudian menggelepar karena sangat rumit.

Faktor yang telah disentuh tetapi belum ditangani:

Hampir semua kegagalan dramatis adalah kontrak yang ditawar. Apa yang terjadi pada perusahaan yang kompeten dalam situasi seperti itu? Mereka membuat estimasi realistis dan karenanya hampir pasti underbid oleh seseorang yang membuat estimasi buruk.

Jika perusahaan tidak dapat memperkirakan dengan benar, apakah mengejutkan mereka tidak dapat membangun sistem dengan benar juga?

Michael Krigsman di ZDNet memiliki blog yang ditujukan untuk " Kegagalan Proyek TI ", yang mungkin menarik di sini.

Poin lain adalah bahwa dengan proyek-proyek panjang yang berlangsung selama bertahun-tahun, umumnya akan ada peningkatan untuk mempertimbangkan atau solusi alternatif, misalnya, apakah proyek sekarang dapat dilakukan di cloud dibandingkan di tempat untuk sesuatu yang mulai muncul lebih dan lebih, yang dalam mempertimbangkan ini tidak diberikan ketika proyek dimulai. Sebagai contoh, ketika seseorang bisa mulai ketika ada sesuatu di 6.0, pada saat fase pertama dilakukan mungkin ada 6,3 atau 6,4 dan pertanyaan tentang kapan upgrade akan ditanyakan. Perubahan dalam ruang lingkup dan fungsionalitas yang diinginkan, baik karena persyaratan tidak dikumpulkan dengan benar atau seseorang berubah pikiran, adalah beberapa poin lain yang telah dibahas cukup sedikit.

Dapatkah tangkas digunakan dalam proyek semacam ini atau pendekatan tradisional masih yang terbaik.

Alasan mengapa proses tangkas yang diterapkan dengan baik tampaknya tidak terlalu menderita dari masalah ini adalah karena alasan sederhana. Anda tidak dapat memulai proyek besar dengan gesit. Anda dapat memilih satu atau yang lain.

Dengan proses yang gesit, Anda tidak pernah benar-benar melihat melewati satu atau dua iterasi ke masa depan proyek. tidak ada 'rencana' untuk 2 tahun ke depan, hanya dua minggu ke depan. Ketika pandangan Anda sesingkat itu, Anda harus membuat beberapa kompromi. Anda tidak pernah dapat memulai dengan rencana untuk membuat "Kata terakhir dalam widget", untuk widget apa pun yang Anda rancang. Paling-paling, Anda bisa mulai dengan "Sebuah widget yang dapat menipu", karena itulah pekerjaan terbanyak yang dapat Anda lakukan dalam satu atau dua iterasi.

Hal yang baik tentang ini, adalah setelah beberapa kali pengulangan, Anda sudah memiliki produk yang lengkap dan berfungsi yang dapat bermanfaat bagi seseorang, terutama bahwa seorang pelanggan yang sangat membutuhkan widget yang dapat menipu dan menyortir.

Pada dasarnya, proyek besar bisa gagal karena mereka bertujuan untuk menyelesaikan semua masalah dari semua pelanggan potensial. Proyek lincah tidak pernah memiliki tujuan ini, alih-alih menangani di setiap versi hanya satu masalah kritis yang mungkin dimiliki satu pelanggan. Namun, setelah beberapa lama, sebuah proyek yang gesit mungkin menyelesaikan banyak masalah penting bagi banyak pelanggan.

• Gagal mengirim ke pengguna yang sebenarnya

Proyek-proyek besar memiliki kecenderungan buruk untuk masuk ke mode "infrastruktur" selama bertahun-tahun, dan lupakan tentang membangun fitur pengguna akhir yang nyata dan mengirimkannya. Pada saat dikirimkan, sangat mahal untuk berubah, dan biasanya perubahan konseptual terbesar akhirnya ditanyakan setelah pengujian beta nyata pertama terjadi.

• Gagal memperkirakan biaya secara akurat

Jika proyek tampak seperti mereka akan melebihi laba atas investasi mereka, mereka dibatalkan.

• Gagal mengontrol kualitas

Dengan cacat yang cukup dimungkinkan momentum ke depan jatuh ke nol, atau di bawah. Tanpa kemajuan sama sekali, sulit untuk memperdebatkan keberadaan yang berkelanjutan.

Mereka lupa Hukum Hofstadter: Itu selalu memakan waktu lebih lama dari yang Anda harapkan, bahkan ketika Anda memperhitungkan Hukum Hofstadter.

Hal yang Saya Lihat Dalam Pengembangan Web:

• Terlalu banyak koki - Pengecer B&M Utama tempat penekanannya tiba-tiba bergeser ke web. Tiba-tiba 20 kepala departemen mengikuti setiap inisiatif untuk mengesankan keju kepala baru. Saya pernah harus menerapkan ikon baru karena legal tidak suka tampilan yang lama.

• Kelebihan fokus pada pencocokan spesifikasi dalam mencapai sasaran - "Ikon IE6 sedikit memudar dibandingkan dengan IE7. Tolong lepaskan pekerjaan penting tanggal-peluncuran yang Anda lakukan dan hadiri. 0,05% dari basis pelanggan kami untuk melakukan hal-hal buruk yang akan memakan waktu berhari-hari untuk mengimplementasikan dan memperlambat pengalaman IE lebih banyak lagi. "

• Bad Tools dipilih oleh non-devs yang bahkan tidak bisa diganggu untuk meminta saran para devs mereka sendiri.

• Pengembang buruk yang dipilih oleh alat - "Mengapa membayar 20 pengembang Java yang kompeten gaji yang layak ketika kita bisa memasang iklan 200 orang yang hampir tidak bisa membaca kode yang tahu terlalu sedikit untuk menggunakan kontrol versi?" karena mereka secara bersamaan dan dengan orang-orang di berbagai negara, bekerja di back-end terutama untuk 3 aplikasi besar.

• Arsitektur Buruk / Rusak - Layers demi lapis kode panik, menyelesaikannya kemarin, oleh orang-orang yang dipecat atau sekarang menjadi manajer.