Apa yang harus dilakukan ketika klien memiliki harapan yang tidak realistis? [Tutup]


23

Saya telah mengerjakan proyek selama enam bulan terakhir di situs klien, karena mereka membutuhkan kerahasiaan data dan tidak ingin kami bekerja di kantor kami sendiri.

Ketika saya muncul sendirian di situs klien ini, saya diberitahu bahwa saya perlu menyelesaikan proyek dalam dua bulan.

Karena klien bukan perusahaan perangkat lunak, dan karena berbagai kebijakan, butuh sekitar 20-25 hari hanya untuk memberi saya hak pada mesin saya untuk menginstal hal-hal seperti Eclipse, Tomcat, dll. Bahkan setelah keterlambatan dalam mendapatkan pengaturan lingkungan, mereka masih mengharapkan saya untuk menyelesaikan proyek dalam periode dua bulan yang sama.

Mereka tidak memberi saya dokumen persyaratan, tetapi karena saya bekerja di situs klien, kami biasa mengadakan pertemuan untuk membahas persyaratan.

Setelah enam bulan aplikasi masih belum selesai, dan semua orang menyalahkan saya, tetapi mereka gagal menyadari bahwa kami telah menambahkan lebih banyak fitur daripada yang dibahas dalam beberapa pertemuan pertama.

Saya harus mengulang banyak hal selama periode ini, misalnya memisahkan formulir menjadi dua bagian; beberapa minggu kemudian, mereka meminta saya untuk menggabungkan kedua formulir lagi karena membingungkan, dan sebagainya.

Cakupan aplikasi meningkat setiap hari tetapi mereka masih berpikir itu adalah proyek dua bulan yang tertunda. Ketika saya memberi tahu mereka bahwa ruang lingkup telah meningkat, mereka bertanya mengapa saya tidak meminta persyaratan pada awalnya.

Saya sudah bekerja 11-12 jam setiap hari dan bepergian 3-4 jam, dan sekarang mereka mengharapkan saya datang pada hari Sabtu juga.

Saya harus melakukan semuanya di sini: menerima persyaratan, desain, kode, dan tes.

Tolong beri tahu saya apa yang harus dilakukan dalam kasus seperti itu?

Rincian tambahan: Kami memang memiliki daftar kiriman, tetapi kemudian mereka menambahkan beberapa hal lagi dengan mengatakan ini juga penting. Mereka juga mengubah beberapa hasil. Mereka bahkan tidak memiliki server UAT mereka, mereka menguji pada mesin pengembangan saya sendiri melalui alamat IP-nya.


11
Anda benar-benar akan menyelesaikannya lebih cepat jika Anda hanya bekerja 8 jam sehari dan tidak ada akhir pekan. Keletihan melemahkan produktivitas Anda. alternet.org/visions/154518/…
HLGEM

10
Sepertinya Anda menjadi kambing hitam orang lain

Bisakah Anda menambahkan suntingan yang menjelaskan bagaimana situasi ini diselesaikan? Ini dapat membantu pembaca di masa depan jika mereka menemukan diri mereka dalam situasi yang sama.
Radu Murzea

Di mana Anda menemukan pekerjaan baru Anda?
Mawg

Jawaban:


65

Ini adalah kegagalan manajer Anda . Anda, sebagai kontraktor, seharusnya tidak ditempatkan dalam situasi dengan tenggat waktu yang ketat oleh perusahaan Anda tanpa harus ada persyaratan tertulis di muka, secara tertulis. Tak satu pun dari ini 'mereka menambahkan fitur' setelah itu omong kosong - setiap kali itu terjadi, mereka harus menandatangani jadwal yang diperbarui yang Anda berikan kepada mereka .

Manajer Anda, karena mereka berencana untuk bertemu dengannya, perlu mendapatkan dari pelanggan satu set persyaratan khusus - proyek harus melakukan A, B, C, D, dan E. Dan setelah itu, itu selesai. Tanda tangan pelanggan harus ada pada dokumen yang menyetujui daftar itu. Anda harus memiliki itu sejak awal.

Jika manajer Anda tidak mendukung Anda dan mendukung Anda dalam hal ini - dan saya jarang mengatakan ini - mulailah mencari pekerjaan lain. Karena Anda mungkin akan menjadi kambing hitam untuk seluruh kekacauan. Dan jika Anda bersedia bekerja 11 jam sehari & 3 jam perjalanan, jelas Anda adalah individu yang sangat berdedikasi dan layak mendapatkan yang lebih baik.


Ketika saya berbicara dengan manajer saya tentang ini, dia mendukung. Tapi itu semua tergantung pada apa yang terjadi dalam pertemuan sekarang :(
ashishjmeshram

1
Dalam pengalaman saya, Programmer sangat cepat untuk menyalahkan manajemen untuk segala sesuatu yang salah ... Bagian pertama yang berani hampir membuat saya membaca jawaban yang sangat baik. Jika manajer tidak menyadari masalah ini, sulit untuk sepenuhnya menyalahkannya (Meskipun manajer yang baik "hanya tahu" apa yang terjadi, apa pun yang ia sampaikan). Terserah pengembang untuk membawa masalah seperti ini ke perhatian manajer lebih cepat daripada nanti.
mattnz

1
Saya pikir dalam kasus ini ia ditempatkan dalam situasi tanpa persyaratan yang diperlukan pada tingkat detail yang cukup disepakati, atau paling tidak, tanpa indikasi yang jelas tentang otoritas apa yang harus ia hadapi dengan perubahan pelanggan pada ruang lingkup proyek . Keduanya adalah masalah manajemen. Dalam kasus yang terakhir, jika maksudnya adalah bahwa ia akan menangani pelanggan, seharusnya sudah jelas baginya bahwa itu adalah masalahnya dan sejauh mana ia dapat menyesuaikan penawaran harga dan tanggal pengiriman untuk pelanggan.
GrandmasterB

1
@GrandmasterB. Hampir seminggu setelah pertemuan, banyak yang dikatakan tentang melakukan sesuatu dengan lebih terorganisir tetapi tidak ada yang berubah. Saya mencoba mendaftar semua hal yang kami diskusikan dalam pertemuan persyaratan dan mengirim email kepada klien. Tidak ada yang mau repot-repot membacanya dan malah saya dapat ini dari klien "Anda pasti sudah membuang waktu satu jam untuk menulis email ini". :(
ashishjmeshram

1
Saya ingin tahu bagaimana ini berakhir. Klien Anda bodoh dan egois. Mereka tidak mendengarkan Anda karena mereka tidak perlu. Anda harus membuat pernyataan tegas bahwa Anda tidak bisa lagi bekerja dengan cara ini. Jadi, apakah Anda berjalan pergi? Atau apakah Anda menyelesaikan pekerjaan itu?
Forza

21

Yang penting dalam situasi seperti itu adalah membangun jejak kertas CYA. Tidak ada yang harus dilakukan tanpa harus ditulis, terutama dalam hubungan bisnis yang rumit. Menempel jadwal awal meskipun mereka membutuhkan 20 hari untuk membiarkan Anda bekerja adalah sebuah bendera merah besar yang akan menjadi rumit.

Anda mengadakan rapat di mana fitur tambahan diperlukan? Tuliskan setelah itu, beri tag "+ X hari ke jadwal saat ini" pada setiap item dan kirimkan ke semua orang yang terlibat. Jika Anda hanya menggunakan sistem surat internal pelanggan, cetaklah juga, termasuk ke:, cc: dan bcc: daftar penerima dan simpan dengan hati-hati. Selain itu, seperti yang dikatakan GrandmasterB, pelanggan harus menandatangani perubahan tersebut terhadap persyaratan awal.

Jika jadwal yang diperlukan tidak dapat ditahan, tuliskan kepada mereka. Jika ada perubahan, tuliskan kepada mereka, termasuk konsekuensinya. Dan seterusnya.

Ini bukan untuk "Aku sudah bilang begitu." ketika kekacauan akhirnya menabrak tembok - mereka tidak akan mendengarkannya. Ini adalah asuransi Anda ketika pelanggan menggugat Anda karena dia berpikir bahwa Anda tidak memenuhi kontrak, atau ketika perusahaan Anda menggugat pelanggan karena ia menolak pembayaran.


16

Dari apa yang Anda jelaskan, tampaknya Anda berpartisipasi dalam proyek Death March klasik :

Dalam manajemen proyek , mars kematian adalah salah satu dari beberapa jenis proyek patologis yang melibatkan analogi disfemistik, humor gelap dengan mars kematian nyata, seperti terlalu banyak bekerja, dan (sering dan terutama terutama) terlalu banyak bekerja karena alasan yang tidak jelas pada proyek yang jelas berisiko tinggi terhadap hasil yang buruk (yaitu, kegagalan proyek, dan kemungkinan ancaman kerusakan reputasi pribadi dan kelompok) . Dengan demikian nama "pawai maut" dapat diterapkan pada proyek yang pada akhirnya berhasil tetapi melibatkan serangkaian pekerjaan rumah yang tidak berkelanjutan, atau (mungkin lebih sering) pada proyek yang dapat dilihat oleh anggota yang cerdas dan berpengetahuan, ditakdirkan untuk gagal (atau dengan risiko kegagalan yang sangat tinggi) tetapi para anggota tetap dipaksa untuk bertindak oleh atasan mereka ...

Fenomena terkenal dan ada banyak literatur tentang bagaimana untuk melanjutkan - termasuk tentu saja buku Edward Yourdon seminalis Death March: Panduan Lengkap Pengembang Perangkat Lunak untuk Selamat Proyek 'Mission Impossible' .

Artikel Wikipedia yang dikutip di atas merupakan titik awal yang baik untuk mencari lebih banyak informasi, penelitian, dan rekomendasi bagi mereka yang terlibat / tertarik pada proyek-proyek pawai kematian .


Berjalan dengan sepatu Anda, hal pertama yang saya pertimbangkan adalah memberikan referensi ke artikel di atas kepada manajer saya.

Dengan cara itu, mereka akan tahu bahwa saya tahu apa yang sedang terjadi, dan mungkin bahkan membantu mereka membimbing saya dalam kerangka yang disediakan untuk gagasan ini, seperti "Lihat, keadaan kita saat ini dekat dengan yang dijelaskan dalam bab Xdi Yourdon. Periksa keluar, bersama dengan bab terkait erat Ydll ... "

Dalam kasus (kemungkinan besar) manajer tidak mengetahui tentang bidang studi ini, merujuk dapat memberi mereka banyak makanan untuk dipikirkan membantu mengidentifikasi situasi dan memutuskan bagaimana cara menanganinya.


11

Jujur saja, jika memungkinkan bagi Anda untuk melakukan ini, solusi terbaik adalah berhenti. Situasi seperti ini beracun bagi Anda dan jarang membaik seiring waktu, tidak peduli seberapa keras Anda berusaha.

Terbaik untuk memotong kerugian Anda dan menemukan pertunjukan yang berbeda. Tetapi, renungkan pengalaman Anda dan ikuti saran dari jawaban lain di utas ini.


2
Ini bukan jawaban yang buruk, tolong jangan downvote tanpa penjelasan. Ya, itu seperti memotong simpul Gordian, tetapi menilai dari situasi yang dijelaskan OP (dan keputusasaannya) ini mungkin hal terbaik yang bisa dia lakukan. Bekerja + bepergian 14 jam plus bekerja pada hari Sabtu? Kedengarannya seperti kesehatan fisik dan mental Anda berada pada risiko serius.
Tamás Szelei

1
Berdasarkan pengalaman, jenis situasi ini memang disebabkan oleh budaya perusahaan, dan akan membutuhkan individu yang saat ini tidak mengalami situasi tersebut. Akan hampir mustahil untuk mengubah budaya semacam itu.
deadalnix

Mengapa ini bukan jawaban yang paling populer dan diterima? quit++;
Mawg

11

Ini serius issue in project management . Sepertinya Anda Project Managerharus bekerja pada daftar yang dapat dikirim dan memprioritaskannya dengan klien.

Yang terpenting , PM Anda should discussdan setuju dengan Klien kerangka waktu (termasuk desain dan analisis masalah / solusi) dalam estimasi Anda.

Memiliki clear estimation of your work loaddan mengirimkan barang-barang proyek akan membebaskan Anda dari stres, Serta menambah ketenangan pikiran dan kepercayaan diri dalam pekerjaan Anda.

Cobalah untuk menggunakan pendekatan Agile dengan mengirimkan barang Anda dalam sprint (2-3 minggu) dan membuat UAT (tes penerimaan pengguna) dengan klien. Ingat, selalu lakukan perencanaan sprint Anda sebelum memulai sprint.

masukkan deskripsi gambar di sini

Sunting: Dari komentar jelas bahwa ini memang kegagalan manajer proyek Anda . Tidak memiliki pengujian yang tepat dan / atau lingkungan pengembangan yang ditetapkan untuk proyek serius seperti milik Anda adalah lubang besar untuk projectdan untuk proses SDLC.


2
Kami memang memiliki daftar pengiriman. Tetapi kemudian mereka menambahkan beberapa hal lagi dengan mengatakan ini juga penting. Mereka juga mengubah beberapa hal dalam daftar yang dapat dikirim. Mereka bahkan tidak memiliki server UAT mereka, mereka menguji pada mesin pengembangan saya sendiri melalui alamat IP.
ashishjmeshram

Ini adalah orang-orang bisnis. Mereka tidak mengerti hal-hal desain dll. Awalnya saya mencoba menjelaskan ini kepada mereka tetapi semua yang mereka katakan kami tidak peduli bagaimana Anda melakukannya tetapi kami melakukannya seperti yang kami inginkan.
ashishjmeshram

2
+1 untuk pendekatan Agile. Lakukan, dan patuhi itu, dengan segala cara.
Bruno Schäpper

1
@Vain Felloman - "+1" berarti Anda menjawab secara terbalik.
mouviciel

@mouviciel Yap. bukan? Sejauh yang saya bisa lihat saya lakukan ..
Bruno Schäpper

10

Meskipun saya setuju bahwa ini adalah kegagalan manajemen, itu juga merupakan kegagalan Anda. Pada tahap ini akan sangat sulit untuk diperbaiki, jadi beberapa yang Anda butuhkan untuk keluar dari ini adalah bagaimana menangani proyek masa depan.

Pertama, Anda perlu menekankan pada dokumen rona awal persyaratan di awal proyek. Tidak harus mewah atau formal, tetapi Anda tidak dapat berhasil membangun apa pun sampai klien menentukan apa yang diharapkan. Jika Anda tidak memiliki ini secara tertulis, peluang pelanggan puas dengan hasil akhirnya sekitar 0%. Jadi ini sangat penting. Adalah juga tugas Anda untuk mencari ambiguitas dalam dokumen ini dan menyelesaikannya sesegera mungkin. Ketika Anda menemukan salah satu dari ini dan Anda tidak yakin bagaimana menafsirkannya, jangan menebak apa yang Anda pikirkan artinya, pastikan Anda dan klien berada di halaman yang sama tentang apa artinya. Ya ini berarti lebih banyak berbicara dengan orang dan lebih banyak rapat dan lebih sedikit pengkodean. Tetapi butuh waktu lebih sedikit untuk membersihkan persyaratan yang tidak jelas daripada kode salah dan kemudian harus mengode ulang. Selanjutnya, Anda sering harus memberi mereka pengkodean ulang secara gratis dan itu tidak baik untuk perusahaan tempat Anda bekerja.

Selanjutnya, Anda memberi tahu mereka berapa lama untuk melakukan pekerjaan itu dan itu menentukan batas waktu. Anda tidak pernah menerima tenggat waktu yang didasarkan pada apa pun selain jumlah jam yang dibutuhkan untuk melakukan pekerjaan untuk memenuhi persyaratan. Jika Anda melakukannya, Anda akan berada dalam mars kematian lagi. Tunjukkan pada mereka bagaimana tenggat waktu tidak mungkin dipenuhi dengan memiliki penjelajahan terperinci untuk waktu yang dibutuhkan. Anda tidak dapat memasukkan 200 jam waktu pengembangan dalam satu minggu dengan hanya 1 pengembang tidak peduli berapa banyak yang diinginkan klien. Pada saat batas waktu tidak bisa digerakkan, Anda bertanya barang apa yang harus dipindahkan ke iterasi berikutnya.

Jangan lupa bahwa waktu devlopment hanya sebagian kecil dari waktu proyek ketika melakukan perkiraan waktu proyek. Anda juga harus memperhitungkan rapat dan komunikasi email / telepon, pengujian, penyebaran, dokumentasi, pengaturan fisik server, workstation, perangkat lunak. Lebih jauh, dalam merencanakan tenggat waktu, Anda hanya dapat berasumsi bahwa Anda memiliki 6 jam sehari tidak tersedia 8. Ini untuk menghitung cuti, berkabung, waktu sakit, keterlambatan yang tidak dapat dihindari (seperti ketika Anda harus menunggu mereka mendapatkan izin untuk Anda) pada jaringan dll.), pelatihan, pekerjaan yang tidak berhubungan dengan proyek (lembar waktu, pertemuan SDM, dll.). Salah satu alasan terbesar mengapa orang tidak memenuhi tenggat waktu mereka adalah bahwa mereka membuat asumsi bahwa mereka hanya akan melakukan pengembangan dan bekerja 8 jam setiap hari. Ini sama sekali bukan asumsi yang realistis.

Dan setiap kali mereka menambahkan bagian lain, Anda memberi tahu mereka berapa lama lagi dan berapa banyak pekerjaan tambahan akan memindahkan tenggat waktu. Anda tidak meminta untuk memindahkan tenggat waktu, Anda memberi tahu mereka bahwa itu bergerak karena persyaratan baru. Sekarang Anda harus melalui manajer Anda untuk hal ini, tetapi pertama-tama Anda bertanggung jawab untuk memastikan manajer Anda tahu setiap kali persyaratan diubah dan berapa banyak yang akan ditambahkan ke proyek. Pastikan semua ini dalam bentuk tertulis, sehingga Anda dapat membela diri jika perlu.

Selanjutnya, jangan biarkan diri Anda disalahgunakan untuk bekerja 11 jam sehari dan akhir pekan. Ini OK dalam semburan singkat (Kurang dari 1 minggu setiap enam bulan atau lebih), tetapi untuk jangka panjang ini sama sekali tidak dapat diterima. Kode orang yang lelah lebih lambat dan mereka membuat lebih banyak kesalahan. Anda dapat menyelesaikan lebih banyak pekerjaan dengan kualitas lebih tinggi secara teratur 8 jam daripada secara teratur 11 jam. dan akhir pekan.


1
Terima kasih balasannya. Poin yang sangat bagus untuk saya perhatikan.
ashishjmeshram

+1 untuk "Anda tidak meminta untuk memindahkan tenggat waktu, Anda memberi tahu mereka bahwa mereka pindah karena persyaratan baru." Ini menunjukkan bahwa tenggat waktu bukanlah sesuatu yang Anda buat, tetapi properti intrinsik dari proyek tersebut.
sleske

1
you need to insist ona a requirements baseline document at the start of the project, Next, you tell them how long it takes to do the work and that sets the deadline., And every time they add another piece on, you tell them how much longer it will take and how much the additional work will move the deadline. Saran besar tetapi berada di situasi seperti itu setelah saya dipecat dalam waktu kurang dari satu karena tidak mungkin untuk bekerja dengan rupanya. Situasi sebenarnya adalah bagaimana orang lain mengatakannya, perusahaan seperti ini ingin kambing hitam dan alasan, bukan pengembang perangkat lunak realistis yang produktif.
maple_shaft

4

Saya telah menemukan Gantt Charts bisa sangat baik dalam situasi seperti ini. Mereka dapat mengilustrasikan kepada klien jadwal saat ini dan dapat berguna dalam menggambarkan efek penambahan dalam setiap fitur / perubahan baru. Kadang-kadang memberi tahu klien bahwa fitur x akan memengaruhi pengiriman pada y hari tidak mendaftar. Dengan memilikinya dengan jelas pada grafik, mereka dapat menangkapnya dengan lebih baik.

Idealnya ini harus dilakukan sejak awal proyek. Mungkin tidak berguna untuk menjelaskan " keterlambatan " sampai saat ini, tetapi mungkin membantu dengan proyek ke depan.

Dari Wiki :

Grafik Gantt menggambarkan tanggal mulai dan selesai dari elemen terminal dan elemen ringkasan dari suatu proyek.


Jika jawaban ini tidak dipilih, beri tahu saya alasannya. Terima kasih.
AidanO

1
+1 - Gantt chart mungkin sudah tua tetapi sepertinya klien tidak membeli ke dalam proyek sehingga sesuatu yang sederhana seperti Gantt chart dapat menunjukkan kepada mereka efek dari persyaratan tambahan mereka.
dave
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.