Apa saja tanda-tanda peringatan akan datangnya malapetaka yang harus diwaspadai pada suatu proyek? [Tutup]


66

Setelah mengerjakan proyek yang gagal adalah salah satu dari beberapa hal yang dimiliki oleh sebagian besar programmer, terlepas dari bahasa yang digunakan, industri atau pengalaman.

Proyek-proyek ini dapat menjadi pengalaman belajar yang hebat, bencana yang menghancurkan jiwa (atau keduanya!), Dan dapat terjadi karena banyak alasan:

  • perubahan manajemen atas hati
  • tim yang kurang terampil / kekurangan sumber daya
  • Munculnya pesaing unggul selama siklus dev
  • manajemen over / under

Setelah Anda mengerjakan beberapa proyek seperti itu, apakah mungkin untuk mengenali pada tahap awal tepat ketika sebuah proyek pasti gagal?

Bagi saya, tanda besar adalah memiliki tenggat waktu eksternal yang keras & cepat yang dikombinasikan dengan fitur creep . Saya telah melihat proyek-proyek yang direncanakan dengan baik dan berjalan sesuai jadwal berjalan dengan sangat buruk begitu permintaan fitur yang terlambat mulai bergulir dan ditambahkan ke "pengiriman akhir". Pengusul permintaan ini mendapat julukan Columbo , karena jarang meninggalkan ruangan tanpa meminta "hanya satu hal lagi".

Apa saja tanda-tanda peringatan yang Anda waspadai yang memicu lonceng alarm akan terjadinya malapetaka di kepala Anda?


Robert Glass menulis "Elixir Universal dan Proyek Komputasi Lain yang Gagal". Diterbitkan pada tahun 1977, buku itu adalah kumpulan kolom yang dia tulis sebelumnya, masing-masing mencari proyek yang gagal, mencari alasan di balik kegagalan tersebut. Buku ini membuat daftar tanda-tanda peringatan yang SANGAT BAIK.
John R. Strohm

Dua artikel - Patologi proyek dan Laporan Kekacauan (over the hyped) . Berikan Death March bacaan yang bagus jika Anda mencari buku.

Jawaban:


70

Pengodean Heroik

Pengodean sampai larut malam, bekerja berjam-jam, dan mencatat banyak waktu lembur adalah pertanda pasti bahwa ada yang salah. Lebih jauh, pengalaman saya adalah bahwa jika Anda melihat seseorang bekerja lembur pada suatu titik dalam proyek, itu hanya akan semakin buruk. Dia mungkin melakukannya hanya untuk mendapatkan satu fitur kembali sesuai jadwal, dan dia mungkin berhasil; Namun, pengkodean koboi seperti itu hampir selalu merupakan hasil dari kegagalan perencanaan yang pasti akan menyebabkan lebih dari itu dalam waktu dekat. Jadi, lebih awal dalam proyek yang Anda lihat, semakin buruk nantinya.


12
Satu-satunya alasan untuk menarik semua-malam adalah untuk mengatasi masalah SPESIFIKASI untuk tenggat waktu SPESIFIK yang tidak fleksibel. Mungkin hanya aku, tapi kode yang kutulis pada jam tiga pagi ketika aku merengek dan kurang tidur cenderung terlihat sangat mengerikan dilihat dalam cahaya yang kejam.
BlairHippo

5
Nah, alasan lainnya adalah menjadi mahasiswa. Perencanaan proyek yang buruk setara dengan kursus saat itu. :)
Fishtoaster

20
Ya Tuhan. Perguruan tinggi. Saya ingat duduk di depan terminal saya ketika matahari terbit, mendorong *dan &lebih atau kurang secara acak di depan variabel dalam kode C ++ saya dengan harapan bahwa benda sialan itu akan mulai bekerja. Aku bukan bagian dari perguruan tinggi.
BlairHippo

2
Awal tahun ini kami memiliki proyek seperti itu - seorang pria secara teratur bekerja sampai jam 2 pagi dan saya mulai jam 4 pagi. Namun, kami menyelesaikan pekerjaan itu, meskipun ada skala waktu konyol yang dipaksakan kepada kami (kami berkomitmen untuk menyelesaikannya dengan tenggat waktu legislatif). Kami masih merapikan dan refactoring sekarang!
Chris Buckett

3
Saya akan menempatkan karma saya dalam bahaya di sini dan menunjukkan bahwa "pengkodean heroik" adalah indikator yang terlambat. Proyek mendapat masalah jauh sebelum mereka sampai ke fase di mana "pengkodean heroik" mulai terjadi. Biasanya ada banyak indikator masalah awal, yang muncul jauh sebelum pengkodean berlangsung dengan sungguh-sungguh. Sayangnya, mereka terlalu sering diabaikan. Robert Glass telah banyak menulis tentang hal ini, dalam "The Universal Elixir", dan dalam buku-buku lain. Abaikan dia atas risiko Anda.
John R. Strohm

44

Ketika programmer mulai memenangkan argumen "Kode ini mengerikan, kita harus memulai dari awal." pada aplikasi dewasa.

Anda mungkin berpikir Anda bisa membangunnya lebih baik, atau memahami masalahnya lebih lengkap, tetapi Anda benar-benar tidak. Oh, dan semua tambalan jelek itu? Mereka adalah perbaikan untuk masalah dunia nyata yang akan Anda perkenalkan kembali dalam penulisan ulang.

Plus, suatu hari Anda harus menjelaskan kepada manajer proyek mengapa setelah 6 bulan bekerja Anda hampir mencapai 85% dari kemampuan dan 150% dari bug yang dimiliki aplikasi ketika Anda mulai.


9
Bukankah ini hanya ringkasan dari penulisan ulang Netscape yang terkenal?
Jasarien


4
Saya tidak setuju. Ada bahaya tertentu untuk penulisan ulang (misalnya sindrom sistem kedua), tetapi jika Anda mengetahuinya, penulisan ulang tidak lebih berbahaya daripada proyek lapangan hijau lainnya.
nikie

4
Terkadang Anda perlu mengamputasi dan mengganti dengan sesuatu yang akan membuat aplikasi lebih kuat, lebih baik, lebih pintar. Tetapi kata kuncinya ada diamputasi, tidak membunuh dan membangkitkan.
Erik Reppen

2
Ini mungkin sebagian besar benar, tetapi tidak sepenuhnya benar. Saya menjalani proyek semacam itu sekitar 9 bulan yang lalu, dan itu sukses. Menghabiskan lebih dari separuh waktu untuk menyusun tes untuk membuktikan itu benar dan bahwa bug lama / baru tidak diperkenalkan ke versi baru, dan menemukan banyak bug baru di yang sudah ada sementara itu. (Padahal, saya kira, ini membuat jawaban ini benar sebagai tanda peringatan )
Izkata

41

Alat baru sebagai pemecah masalah.

Ketika orang-orang mulai berencana untuk menggunakan alat-alat yang tidak dikenal, saya tidak keberatan, tetapi saya tetap memperhatikannya. Ketika mereka mulai merencanakan semua manfaat yang diiklankan dari alat-alat itu ke dalam jadwal, saya merasa khawatir. Contoh menyenangkan:

  • Kita dapat mencukur satu bulan dari jadwal karena kita akan mencoba menggunakan bahasa berorientasi objek (meskipun yang kita miliki adalah c developer).
  • Kami akan mencoba scrum baru ini - yang akan memperbaiki semua masalah proses kami!
  • Saya tahu ini setengah jalan dari proyek, tetapi bagaimana jika kita mengubah ORM menjadi sesuatu yang baru?

Teknologi dan praktik baru sangat bagus, tetapi Anda hampir tidak pernah mendapatkan semua manfaat dari gerbang.


3
Saya pernah di proyek yang memiliki dua garpu karena dua antarmuka - desktop dan gadget genggam. Perkiraan waktu didasarkan pada gagasan bahwa kita dapat menggunakan hal-hal "EJB" baru yang mengkilap ini untuk menggunakan kembali kode model-layer di antara keduanya. Sayangnya, basis data adalah sarang tikus yang mengerikan sehingga semua data yang diambil darinya harus berasal dari pertanyaan SQL khusus yang dibuat dengan cermat; mengisi penuh kacang akan terlalu brutal hit kinerja. Ketika ternyata (kejutan!) Versi desktop membutuhkan lebih banyak data daripada versi genggam, timeline menjadi LURUS ke neraka.
BlairHippo

2
"Hebat! Sekarang setelah kita menyelamatkan kerangka kerja unit testing, kita bisa mulai memotong waktu dari fase QA yang panjang itu!"
Arkaaito

ha ha ha. Luar biasa. +1 untuk alat baru akan menyelesaikan semua masalah saya.
cepat_now

40

Bagi saya satu-satunya masalah terbesar, dan yang dapat Anda temui segera, adalah ketika bisnis menganggap persyaratan tertulis sebagai pemborosan waktu.

Jadi pada dasarnya; Tidak Ada Persyaratan Tertulis

Itu ciuman kematian.


3
Atau lebih buruk, persyaratan tertulis yang tidak dibaca oleh siapa pun. Bahkan, saya pernah mengerjakan proyek-proyek di mana persyaratan yang luas ditulis dan tidak pernah ditunjukkan kepada para programmer.
JohnFx

1
@Adolf Garlic - Persyaratan tertulis tidak akan memastikan Anda tepat waktu atau sesuai anggaran, tetapi Anda tidak akan pernah memenuhi harapan jika harapan tidak dikomunikasikan, tidak memiliki semua area abu-abu dipaku, dan terus berubah (ide-ide mental Anda akan berubah ).
John MacIntyre

5
Saya pernah memiliki seorang Analis Bisnis yang mengatakan kepada saya bahwa persyaratan tidak diperlukan. Apa pekerjaan seorang analis bisnis lagi? Oh ya untuk menulis persyaratan! Kami akan mendapatkan persyaratan seperti membuat ini berfungsi seperti yang dilakukan hkjk.com.
HLGEM

1
Jika Anda mengembangkan untuk produk khusus untuk satu klien, tentu saja. Tetapi jika Anda sedang menulis Powerpoint versi berikutnya atau versi berikutnya dari sistem perangkat lunak in-house, saya tidak mengerti intinya. Anda akan selalu belajar lebih banyak tentang persyaratan selama pengembangan (mis. Bahwa beberapa persyaratan tidak berguna dan yang lainnya tidak layak). Saya lebih suka menggunakan pengetahuan itu dan mengubah persyaratan selama pengembangan daripada merilis produk yang lebih rendah.
nikie

1
@nikie - Saya tidak mengatakan persyaratan harus statis, dan tidak pernah berubah. Saya mengatakan Anda harus menuliskannya untuk mencegah salah komunikasi dan mencegah ide berubah di kepala orang dari waktu ke waktu. Jika persyaratan harus berubah, maka ubahlah, tetapi simpan persyaratan saat ini ditulis. Apakah itu masuk akal?
John MacIntyre

33

Putus Manajemen

Ketika mereka yang bertanggung jawab atas tenggat waktu, fitur, kepegawaian, dll terputus dari orang yang bertanggung jawab untuk mengirimkan proyek. Ini dapat menyebabkan:

  • Fitur merayap ketika pelanggan berbicara dengan seseorang yang tidak mengerti biaya fitur
  • Man-month syndrome, di mana pengembang baru dilemparkan ke dalam proyek cukup terlambat untuk menjadi lebih dari penghalang daripada bantuan
  • Tenggat waktu yang tidak realistis, dibuat oleh orang-orang yang harus berurusan dengan konsekuensi bisnis dari keputusan tenggat waktu tetapi bukan konsekuensi implementasi.
  • Produk yang tidak menyelesaikan masalah, ketika komunikasi customer-dev terhambat oleh manajemen di tengah.
  • Manajemen risiko yang buruk, di mana potensi masalah tidak dikomunikasikan cukup awal antara pengembang dan manajemen.

Jadi, ketika tampaknya manajemen tidak tertarik pada proyek, berkomunikasi dengan buruk, tidak mendengarkan pelanggan, atau tidak mendengarkan tim pengembang, lari ke perbukitan.


+1 untuk item pertama Anda. Saya telah menjadi pelanggan dalam skenario yang Anda sebutkan dan itu buruk untuk semua orang (tidak ada yang menginginkan tagihan yang tidak terduga, dan tidak ada yang menginginkan argumen tentang pembayarannya).
fearoffours

+1 amin. Pernah ke sana, melakukan itu, tidak peduli berada di posisi itu lagi.
Evan Plaice

+1 untuk fakta saya hidup dengan semua peluru ini (kecuali mungkin yang ke-4).
AShelly

Jawaban yang bagus Bahkan jika Anda tidak repot-repot menjelaskan, dan Anda cukup memasukkan 'Putus Manajemen', jawaban Anda akan bernilai +10.
Jim G.

25
  1. Ketika pengembang utama pergi dan manajemen tidak peduli

  2. Ketika pengembang utama pergi dan tidak ada pengembang lain yang peduli

Nomor satu biasanya menunjukkan manajer yang sangat tidak berhubungan dengan dinamika tim (yang merupakan "bintang super 10x", yang merupakan programmer yang baik, dan bagaimana mereka berinteraksi satu sama lain, dll.).

Nomor dua biasanya menunjukkan kurangnya minat pada pengembang yang tersisa.


24

Pertama kali seseorang, biasanya manajemen mengatakan "kita tidak punya waktu untuk .."

Biasanya mendahului sesuatu yang kita tidak punya waktu untuk tidak melakukannya, seperti dokumentasi atau ulasan kode (yang secara statistik menemukan dan memperbaiki lebih banyak bug dari yang lainnya, termasuk semua bentuk pengujian)


8
punya referensi untuk itu? itu akan menjadi amunisi yang bagus untuk digunakan ...
Alex Feinman

1
Sebut saja "Hukum pertama manajemen perangkat lunak
Mawg

1
@Alex Feinman: Kode IIRC Lengkap berisi banyak referensi untuk statistik seperti ini.
nikie

21

Biarkan pelanggan, pemasaran atau manajemen memilih tanggal dan kemudian mencoba bekerja mundur ke jadwal imajiner


Terima kasih. Selalu ingat, Anda dapat memilikinya cepat, murah atau bekerja ... pilih dua
Mawg

21

Ketika manajemen terlalu lemah untuk mengatakan "Tidak" pada bisnis.

Ini mengarah ke tenggat waktu yang tidak akan pernah terpenuhi, yang mengarah ke kurangnya kepercayaan pada departemen TI yang menyebabkan pengembang membuat peretasan (yaitu akses db yang berjalan pada mesin seseorang ... di suatu tempat) yang mengarah ke mimpi buruk bagi TI ketika ' sistem kritis 'harus dimigrasi yang mengarah ke ...


Tidak ada yang membuat ruang lingkup merayap lebih buruk daripada 'fitur konsesi' karena PM kacau ketika dia mengatur tanggal tonggak.
Evan Plaice

21

Tanda buruk pertama yang bisa saya pikirkan adalah ketika manajemen tidak mau menyampaikan berita buruk ke rantai atau ke klien dengan harapan bahwa itu akan hilang - yaitu manajemen dengan angan-angan. Saya tidak dapat memikirkan berapa kali, pengembang telah membuktikan bahwa mereka tidak dapat memenuhi tenggat waktu minggu atau bahkan berbulan-bulan sebelumnya, namun tidak ada yang mau memberi tahu klien. Saya jarang melihat seorang klien yang tidak akan memaksakan tenggat waktu ketika ada alasan tulus ketika kebutuhan itu dijelaskan sebelumnya; Saya sering melihat klien yang kesal ketika diberi tahu pada hari batas waktu bahwa itu tidak akan dipenuhi dan bahwa itu tidak akan dipenuhi pada hari berikutnya juga, tetapi dua bulan kemudian. Pada titik ini mereka, mungkin saya tambahkan, mempertanyakan proses Anda - bagaimana Anda tidak tahu ini sebelumnya.

Tanda pasti lain bahwa kegagalan akan datang adalah untuk menetapkan pengembang baru ke bagian yang paling sulit, paling kritis dari proses daripada orang-orang yang sudah memahami sistem saat ini. Maka jangan perhatikan mereka dengan seksama untuk melihat apakah mereka benar-benar menyelesaikan pekerjaan dengan benar atau memiliki pertanyaan (BENDERA BESAR BESAR MERAH jika tidak ada pertanyaan). Karyawan baru perlu dimonitor sampai Anda tahu mereka benar-benar memiliki keterampilan yang mereka miliki. Saya masih ingat menghabiskan satu musim panas yang menyakitkan mengulangi pekerjaan (sudah melewati batas waktu ketika saya mendapatkannya) dari seorang karyawan baru yang mendapat bagian penting dari sebuah proyek dan mengatakan kepada semua orang semuanya baik-baik saja selama berbulan-bulan dan kemudian berhenti tanpa pemberitahuan satu minggu dari tenggat waktu. dan tidak ada yang dia lakukan yang bisa digunakan.

Tanda kegagalan yang pasti adalah ketika pengembang mengerjakan bagian yang bergantung pada hal-hal lain yang dilakukan terlebih dahulu dan hal-hal itu tidak dilakukan atau bahkan dimulai. Jika manajemen tidak bisa mendapatkan pekerjaan yang ditugaskan dalam urutan yang benar, Anda akan turun tabung.

Tentu saja fitur merayap tanpa mendorong batas waktu kembali setiap kali adalah salah satu tanda paling umum hal-hal akan menjadi buruk. Anda menambahkan 20 jam kerja ke piringan saya, batas waktu akan dipindahkan oleh 20 jam. Jika tidak maka proyek akan gagal, dijamin.


Yap, berita menjadi lebih baik saat perjalanan naik :)
Hans Westerbeek

18

Satu tanda pasti yang saya lihat dalam karier saya adalah ketika manajemen mulai berbicara tentang membawa lebih banyak orang untuk memperbaiki waktu dalam jadwal. Saya tidak pernah benar-benar melihat lebih banyak orang dalam suatu bantuan proyek.


6
Saya pernah memiliki seorang manajer yang ingin membawa seorang web coder front end ke sebuah proyek (keputusan yang tepat) tetapi karena orang lain dalam proyek itu sudah sakit jangka panjang, ia ingin terkena kontrak tertulis orang baru itu sehingga ia tidak diizinkan untuk melakukannya. sakit.
Jon Hopkins

1
@ Jon - Itu menyedihkan ... lucu, tapi sangat sedih!
Walter

16

Ketika manajer non-teknis mulai bersikeras untuk membuat keputusan teknis bahwa mereka sama sekali tidak memenuhi syarat untuk membuat. Besar, bendera merah besar!


16

Tanda yang paling jelas adalah pergantian staf yang tinggi. Ketika semua orang mencari pekerjaan baru, Anda mungkin juga harus melakukannya.

Tanda lain yang sangat jelas adalah kurangnya kemajuan. Jika satu tahun telah berlalu, dan sepertinya Anda tidak mendekati target, Anda akan menemui ajal. Ini terjadi terutama ketika persyaratan berubah lebih cepat daripada yang dapat Anda terapkan.


1
Tingkat turnover tertinggi yang saya lihat ada di dua proyek. Salah satunya adalah proyek stabil yang terus berjalan, dan satu adalah proyek malapetaka yang dikenal di bank. Saya tidak pernah senang menganggur seperti keduanya.
David Thornley


11

Anda sudah "90% selesai", pengirimannya minggu depan, tetapi tidak apa-apa karena yang tersisa adalah "pengujian".


2
Tampaknya sangat lucu sekarang karena Anda mengatakannya. Akan tetapi terjadi pada saya. Tidak lucu waktu itu.

+1000 terjadi di mana saya bekerja sepanjang waktu T_T
Songo

1
Lucu sekali setiap jadwal memiliki pengujian sebagai langkah terakhir seolah-olah pengujian tidak akan menemukan bug. Jika tidak, mengapa repot-repot dengan pengujian?
JohnFx

Jangan khawatir, "pelanggan akan mengujinya untuk kami" :-(
Mawg

10
  • Setiap orang kelelahan secara fisik dan mental
  • Pelanggan / pengguna jelas tidak senang tentang rentang waktu atau apa yang mereka lihat
  • Desain aslinya yang indah sekarang terasa terganggu
  • Anda mengundurkan diri untuk pengiriman dengan beberapa bug yang relatif signifikan yang sebenarnya ingin Anda perbaiki tetapi tidak dapat melakukannya
  • Kebanggaan Anda yang tersisa ada pada tindakan pengiriman daripada apa yang Anda kirim - lebih dekat dengan mental orang yang selamat daripada kebanggaan profesional
  • Tim takut ada hal-hal tertentu yang tidak berfungsi dan mengabaikan bagian-bagian itu dan berharap yang terbaik karena mereka takut dengan apa yang mungkin ada di sana.
  • Semua orang yakin bahwa mereka telah melampaui dan melampaui (dan mereka benar)
  • Orang-orang menunjukkan tanda-tanda kelelahan (pesimisme umum, ketidaktertarikan, kemarahan)

(Disarikan dari Jim McCarthy's Dynamics of Development Software ).


+1 untuk "Anda merasa bangga berada dalam tindakan pengiriman daripada apa yang Anda kirim". Itu sangat benar (walaupun saya hanya melihat itu di manajer saya. Kami pengembang tahu apa yang keluar dari pintu ... kaki dulu)


9

Jika rencana proyek membutuhkan satu iterasi desain, pengembangan, pengujian dan penyebaran - air terjun klasik - untuk proyek lebih dari 1 bulan, saya akan berlari satu mil.

Anda tidak perlu gesit sepenuhnya, tetapi memiliki siklus pengembangan yang singkat memungkinkan Anda untuk menunjukkan kemajuan kepada semua orang (pelanggan, manajemen, dan pengembang sendiri) dan mengatasi persyaratan yang berubah ketika hal yang tak terhindarkan terjadi.


6
Tidak ada yang salah dengan air terjun bila digunakan dengan benar. Sayangnya itu tidak pernah digunakan dengan benar :)
adolf bawang putih

@ Adolf - Saya sedang memikirkan satu melewati air terjun. Beberapa air terjun mini mungkin baik-baik saja.
ChrisF

imo, Agile hanyalah serangkaian air terjun. Sangat sedikit yang dapat melakukan air terjun dengan benar, ergo ..
Mawg

@ mawg - poin saya adalah tentang iterasi panjang tunggal menjadi buruk sedangkan serangkaian iterasi pendek (namun mereka dikelola) lebih baik.
ChrisF

1
Mengingatkan saya pada sebuah proyek yang mengembangkan hal-hal elektronik di mana tidak ada prototipe di mana dijadwalkan di ... Tanda pasti akan terjadi bencana.
cepat

9

Pengembang Berlari Liar di Kisaran

Ini terjadi ketika Anda menyadari bahwa pengembang lain (atau, sayangnya, Anda) telah mengembangkan komponen yang sangat berbeda dari desain, dan bahwa ini tidak diambil sampai masuk ke pengujian sistem / UAT. Saya tidak berbicara bug; Saya berbicara tentang komponen sistem yang signifikan adalah fitur yang hilang atau belum digunakan untuk fungsi dan tidak akan pernah lulus UAT tanpa pengerjaan ulang yang signifikan. Masalah ini menunjukkan bahwa:

  • Sistem kualitas Anda rusak; mengapa pengembang tidak memperhatikan masalah pada tahap desain / implementasi. Bukankah kode per ditinjau / diperiksa? Mengapa unit dan tes integrasi tidak memahami hal ini? Jika Anda tidak memiliki semacam pengujian unit / integrasi yang konsisten, Anda kacau.
  • Manajer proyek / pimpinan teknis Anda tidak mengendalikan tim pengembangan mereka. Jika mereka tidak bisa membuat pengembang memberikan apa yang diperlukan, mereka tidak akan pernah bisa memberikan solusi lengkap.

8

Ketika pengembang utama pada suatu proyek belum memeriksa kode apa pun selama berminggu-minggu dan tonggak yang serius akan datang.

Itu adalah pekerjaan kontrak dan pengembang yang lebih senior dan PM di pekerjaan memutuskan mereka ingin bekerja sama untuk mencoba mendapatkan potongan yang lebih besar sehingga pengembang lain menahan sandera kode kritis selama 3 minggu. Pada akhirnya, kami memecat PM yang tidak kompeten (yang telah menghabiskan 6 bulan menempatkan proyek pada kehancuran) dan membicarakan hal-hal dengan pengembang.

Cukuplah untuk mengatakan, sisa dari proyek itu adalah mars kematian masokis, pembekuan spesifikasi tertunda, pelanggan diberi banyak fitur konsesi untuk menebus penjadwalan mengerikan yang ditinggalkan PM meninggalkan proyek, dan kualitas proyek menderita semua karena itu.

PM bahkan memiliki keberanian untuk terbang ke CDR (Critical Design Review) hanya untuk menutup pertemuan dengan klien dan melempar bunyi desis. Ketika dia menuntut agar biaya perjalanannya dibayar berdasarkan proyek, dia dengan sopan disuruh pergi beramal dengan dirinya sendiri.

Saya dapat dengan mudah mengidentifikasi dengan setidaknya 5 jawaban lain yang ditemukan di sini yang mempengaruhi proyek itu. Singkatnya, saya belajar banyak pelajaran sulit tentang proyek pengkodean serius pertama saya.


8

Tanda pertama saya pada salah satunya adalah ketika mereka bertanya berapa jam lembur yang kita masing-masing akan berkomitmen untuk sepuluh minggu ke depan dan menawarkan bonus kepada pekerja yang digaji untuk bekerja mengatakan lembur berdasarkan keberhasilan proyek dan memenuhi tenggat waktu.

Tanda-tanda utama lain yang pernah saya lihat: Persyaratan definisi lebih dari jadwal dan tanggal akhir tidak dipindahkan. Kami berada di belakang bahkan sebelum kami bisa mulai. Mereka mengambil waktu dari desain, jadi kami mulai tanpa desain database dan desain situs tetapi diharapkan tepat waktu, antara lain, melakukan impor ke tabel yang belum dirancang dan dibuat.

Ketika item di jalur kritis dilakukan secara bersamaan alih-alih berurutan. (Jika saya diharuskan menggunakan alat X dan programmer A baru mulai membangunnya, itu akan menunda tugas saya.)

Ketika manajer melakukan kode pada Thanksgiving.

Ketika Anda mulai mendapatkan email yang memiliki stempel waktu lebih dari 11 malam dan lebih awal dari pukul 6 pagi.

Ketika setiap pertanyaan tentang bagaimana menangani beberapa kompleksitas bertemu dengan jawaban yang sama, "Jangan khawatir tentang itu."

Ketika mereka masih membuat perubahan persyaratan pada hari pertama Anda pergi ke QA atau ditayangkan.

Ketika Anda mulai mengadakan pertemuan harian yang membutuhkan waktu beberapa jam untuk membahas kurangnya kemajuan Anda. Oh, itu karena aku ada rapat sepanjang hari. Rapat harian 5 menit, rapat harian lebih dari satu jam, tidak baik.

Ketika tim basis data dan tim aplikasi tidak saling berbicara.

Ketika klien tidak dapat memberikan informasi yang dijanjikan tepat waktu. Terutama ketika itu adalah file impor data dan Anda memerlukan data dalam database untuk memeriksa untuk melihat bagaimana kode bekerja.

Ketika Anda mempertimbangkan untuk memasang lampu berhenti di luar kantor manajer untuk memberi tahu Anda apakah aman untuk mendekatinya hari itu.


2
Kicker pada paragraf pertama Anda adalah bahwa, jika manajemen melakukan itu, tenggat waktu mungkin sudah hancur dan bonus tidak mungkin tercapai.
David Thornley

1
@ David Thornley, ya itu persis seperti itu.
HLGEM

6

Saya pikir itu umumnya mudah untuk menemukan proyek gagal ketika tenggat waktu mendekat. Seperti yang Anda katakan, fitur creep dikombinasikan dengan tenggat waktu set-in-stone adalah cara yang pasti untuk membunuh suatu proyek.

Namun kuncinya adalah menemukan cara proyek yang gagal di muka. Saya pikir satu-satunya 'tanda azab' yang nyata dalam kasus ini adalah ketiadaan definisi tentang 'kapan kita selesai'. Kecuali kita tahu ini di offset kita ditakdirkan untuk kegagalan IMO.


1
alias "definisi selesai", seperti yang disepakati oleh TI dan Bisnis
adolf bawang putih

6

Saya telah berada di tiga pawai kematian dalam lima tahun terakhir. Berikut adalah beberapa hal yang berkontribusi pada firasat saya akan azab yang akan datang.

  • Perusahaan memutuskan untuk membuat pengembang junior mendesain dan mengembangkan fitur baru, dan menugaskan pengembang senior yang lebih mahal untuk memperbaiki bug mereka.
  • Perusahaan melakukan outsourcing komponen perangkat lunak penting ke perusahaan dunia ketiga yang tidak memiliki keahlian domain yang diperlukan.
  • Siklus waktu krisis datang begitu dekat sehingga kesehatan orang-orang rusak.
  • Pil-pil yang dibutuhkan tim Anda untuk membuat obat tidur setiap malam berhenti bekerja.
  • Klien mengirim pesanan perubahan lebih cepat dari yang Anda bisa menganalisisnya.
  • Anda seharusnya mengirimkan pekerjaan beberapa tahun dalam beberapa minggu, tetapi manajemen menolak untuk melakukan pembekuan fitur.
  • Pemasok perangkat keras Anda jelas mengalami kesulitan dalam mengirimkan produk yang bisa diterapkan sesuai jadwal, dan pembuat keputusan di perusahaan Anda tidak akan mempertimbangkan alternatif lain.
  • Perangkat prototipe yang dibutuhkan pengembang sehingga mereka memiliki hantu kesempatan untuk memenuhi jadwal yang mungkin tidak realistis diambil dan diberikan kepada eksekutif puncak untuk membuat mereka merasa baik.
  • Minggu pertama: "Oh, sial, kodenya buggy. Semua orang berhenti melakukan fitur baru dan memperbaiki bug." Minggu kedua: "Oh, sial, kita tidak akan memenuhi jadwal fitur. Semua orang berhenti memperbaiki bug dan menulis fitur baru." Ulangi tanpa batas.
  • Pengembangan dilakukan di satu negara, dan QA semua dilakukan di negara lain setengah jalan di seluruh dunia, jadi komunikasi bolak-balik tentang bug selalu membutuhkan 24 jam, dan setidaknya satu dari orang yang terlibat mendiskusikan masalah teknis yang rumit dalam bahasa yang mereka tidak mahir.

Saya akan memberi Anda satu juta untuk poin terakhir itu.
HLGEM

5

Bagi saya, itu adalah ketika orang-orang yang bertanggung jawab untuk set fitur (alias manajer, pemilik produk, pelanggan ...) berhenti peduli atau tampaknya tidak punya harapan tentang jawaban mereka. Pertanyaan tentang fitur bertemu dengan apatis dan keputusasaan. Jelas bahwa mereka telah kehilangan investasi atau kepercayaan pada proyek.

Ini terjadi pada saya ketika sebuah proyek saya berada di "hit hati manajemen atas" memukulnya. Saya mengajukan pertanyaan tentang bagaimana itu seharusnya bekerja dan tiba-tiba tidak ada yang memiliki pendapat yang sebenarnya.

Beberapa saat kemudian proyek dibatalkan dan semua kode indah yang saya tulis dihapus.


5

Paul Vick menulis posting yang sangat baik beberapa tahun yang lalu tentang proyek lubang hitam . Saya pikir semua saran itu relevan. (Saya sudah mengedit panjang item dan ringkasan.)

  • Tujuan muluk yang luar biasa . Seperti "secara mendasar menata kembali cara orang bekerja dengan komputer."
  • Tenggat waktu yang sama sekali tidak realistis . Biasanya ini karena mereka percaya bahwa mereka dapat menulis ulang basis kode yang asli dalam waktu yang jauh lebih singkat daripada waktu yang dibutuhkan.
  • Keyakinan yang tidak realistis tentang kompatibilitas . Seperti percaya Anda bisa menulis ulang dan melestarikan semua kebiasaan kecil tanpa usaha ekstra.
  • Selalu "enam bulan" dari batas waktu utama yang sepertinya tidak pernah tiba . Atau, jika itu tiba, tonggak sejarah lain ditambahkan ke akhir proyek untuk mengkompensasi.
  • Harus mengkonsumsi sumber daya dalam jumlah besar . Biasanya dengan menghisap darah kehidupan dari satu atau lebih produk yang sudah mapan.
  • Libatkan menggunakan teknologi baru yang belum terbukti . Dengan demikian, mereka bisa menghilangkan semua masalah skalabilitas dengan teknologi baru.

4

Saya menerjemahkan secara mental, "Semuanya baik-baik saja. Kami tidak perlu khawatir." untuk "Kita semua kacau" setiap kali saya mendengarnya manajemen mengatakannya. Anda biasanya mendengar manajer melemparkannya secara tidak sengaja dalam pertemuan yang tidak terkait ("Oh dan omong-omong, semuanya baik-baik saja. Tidak ada alasan untuk khawatir!"), Tetapi itu merupakan bendera merah yang lebih besar untuk mengadakan rapat yang secara khusus dipanggil untuk mengatakan itu.

Saya belum pernah mendengar seorang manajer mengatakan sesuatu seperti itu dan membuatnya tidak bohong.


Lolx! Benar sekali; pertemuan "Anda mungkin pernah mendengar rumo (u) rs ...".
Mawg

4

beberapa poin dari proyek mati saya adalah bagian dari:

  • Manajemen menggandakan tim untuk menyelesaikan lebih cepat.
  • pengembang mulai "mengubur" bug untuk memenuhi tenggat waktu, dan meskipun jelas, bug ini diabaikan selama peninjauan kode.

3

Ketika manajemen menarik proyek ke arah yang berbeda secara bersamaan dan kereta tetap diam.

Saya pernah terlibat dalam proyek yang dikelola oleh dua orang. Entah mereka tidak berbicara satu sama lain atau masing-masing memiliki ego untuk diselesaikan, tetapi mereka memerintahkan pekerjaan kami ke arah yang berlawanan tentang setiap minggu atau lebih. Tidak butuh waktu lama untuk menyadari bahwa tidak akan ada hasil apa pun. Dengan senang hati partisipasi saya hanya berlangsung beberapa bulan.


LOL, saya mengerjakan studi ketenagakerjaan seperti itu walaupun lebih buruk karena kedua pemimpin itu berusaha berselingkuh dengan wanita yang sama. Jika Bill mengatakan ya, maka Bob mengatakan tidak dan sebaliknya, proyek terburuk yang pernah saya kerjakan. Saya memohon untuk dipindahkan.
HLGEM

3

Lihat artikel ringkas ini: Saat Proyek TI Berlangsung Benar .

Tidak adanya elemen yang disebutkan dalam artikel harus membuat bel alarm berbunyi:

Jadi pastikan proyek Anda memiliki semua hal berikut, jika tidak maka Anda harus khawatir:

(Mengutip artikel di atas :)

  1. "Yang pertama adalah bahwa mereka didasarkan pada visi yang jelas tentang apa yang harus dicapai."

  2. "Karakteristik kedua menyangkut dukungan dan komitmen dari berbagai pihak yang terlibat di seluruh bisnis, terutama manajemen senior."

  3. "Ketiga adalah pemahaman tentang masalah yang harus ditangani."

  4. "Karakteristik umum terakhir adalah sumber daya dan keterampilan yang memadai telah tersedia."


Artikel bagus! Saya suka pendekatan "ketika segalanya berjalan dengan benar".
user8865

3

Secara statistik awal proyek perangkat lunak adalah tanda yang adil bahwa itu akan gagal, karena mayoritas dari mereka melakukannya ...


1
Saya pikir itu adalah statistik start-up, belum tentu statistik proyek perangkat lunak umum.
Erik Reppen

2
Berikut adalah satu referensi yang di-Google- googled yang tampaknya menyarankan itu tidak terbatas pada pemula. Juga lihat Rapid Development luar biasa dari Mr. McConnel untuk permata lebih lanjut tentang topik ini.
Nitsan Wakart
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.