Manajer Proyek yang ingin mengunci perkiraan waktu dengan kontrak yang ditandatangani

Pada pekerjaan sebelumnya, manajer proyek (PM) tidak puas dengan waktu pengiriman kode pada proyek yang saya ikuti. Saya diberitahu oleh pimpinan proyek bahwa PM sedang mempertimbangkan untuk menandatangani kontrak untuk mengunci perkiraan waktu yang saya berikan untuk tugas dan tanggal pengiriman.

Situasi pada proyek ini adalah kami bekerja dengan teknologi baru, basis kode, standar pengkodean, dan persyaratan yang sangat rentan terhadap perubahan. Saya belajar hal-hal baru dan menerapkannya sebaik mungkin pada persyaratan yang terus berubah. Persyaratan di seluruh iterasi tumbuh 2-3 kali, dengan perkiraan saya untuk menyelesaikan tumbuh sekitar 5-8 kali. Satu-satunya hal yang tidak berubah adalah perkiraan dan tanggal pengiriman.

Ya, saya akhirnya melewatkan sebagian besar tenggat waktu. Dan saya sedang mengerjakan beberapa teknologi yang sangat baru sehingga tidak ada orang lain di seluruh tim pengembangan yang bisa membantu karena mereka tidak akan terbiasa dengannya. Setidaknya tidak mudah.

Bagi saya, pada saat itu, sang PM ingin angka-angkanya bertambah - dan dengan demikian ingin saya menandatangani kontrak untuk "memastikan" bahwa saya akan selalu memberikan kode kerja tepat waktu. Saya kira dengan kontrak yang ditandatangani, PM dapat menggunakannya terhadap saya jika saya tidak dapat memenuhi tepat waktu.

Saya percaya apa yang terjadi selanjutnya adalah bahwa manajer proyek dan / atau pimpinan proyek lainnya membela saya, dan tidak membiarkan ini terjadi.

Pertanyaan saya adalah, haruskah ini menaikkan bendera merah tentang manajer? Apakah praktik umum bagi manajer untuk mengunci waktu perkiraan pengembang perangkat lunak dengan kontrak yang ditandatangani? Atau dalam hal ini, cobalah.

Harap dicatat, saya adalah karyawan penuh waktu, bukan konsultan independen.

Pembaruan : Saya ingin menambahkan bahwa saya memang memberikan perkiraan baru setiap minggu, tetapi tampaknya perkiraan asli dan tanggal pengiriman adalah apa yang ditetapkan PM.

Pertanyaan saya adalah, haruskah ini menaikkan bendera merah tentang manajer?

Ya . Ini berarti sudah saatnya bagi Anda untuk mendapatkan resume / CV Anda yang terbaru dan mulai mencari pekerjaan baru. Atau itu artinya manajer Anda akan mulai memainkan beberapa permainan yang sangat jahat dengan Anda.

Apakah praktik umum bagi manajer untuk mengunci waktu perkiraan pengembang perangkat lunak dengan kontrak yang ditandatangani?

Saya tidak pernah mendengar ini diterapkan pada karyawan.

Estimasi waktu dan upaya selalu sulit. Terutama karena profesi kita penuh dengan optimisme berlebihan. Ada beberapa sistem estimasi yang dapat membantu dengan estimasi di masa depan, tetapi mereka perlu mengumpulkan statistik historis dari Anda sendiri. Salah satunya adalah PSP . Lainnya adalah Function Points . Banyak pengembang yang tidak menyukai keduanya, dan Anda akan menemukan pendapat yang sangat kuat terhadap keduanya.

Kesulitan utama dalam memperkirakan waktu dan usaha adalah kurangnya umpan balik dalam heuristik estimasi kami. Salah satu kuncinya adalah menuliskan perkiraan perkiraan Anda, dan parameter apa yang Anda gunakan untuk memperkirakannya. Kemudian, berdasarkan apa yang sebenarnya Anda lakukan, bandingkan dengan apa yang Anda pikir akan Anda lakukan. Dan gunakan itu untuk mengubah parameter estimasi Anda. Dalam rekayasa, kami menyebutnya " umpan balik ."

Ya, itu seharusnya benar-benar berbunyi lonceng alarm.

Jika saya berada di posisi itu, untuk hiburan pribadi saya, saya akan meminta manajer untuk menandatangani kontrak yang membekukan semua persyaratan. Saya membayangkan manajer kemungkinan akan menebus. Lalu aku akan pergi.

Yah, itu sederhana. Katakan saja kepada manajer Anda bahwa Anda akan masuk untuk mengunci perkiraan waktu Anda ketika dia akan masuk untuk mengunci spesifikasi. Karena Anda tidak bisa, tentu saja berikan perkiraan untuk sesuatu yang tidak dikenal. Spesifikasi proyek lengkap sebelum Anda mulai, tidak ada perubahan - dan Anda dapat menyelesaikannya tepat waktu :)

Satu perubahan ke kontrak spec => tidak berlaku. Mungkin masalahnya akan batal setelah 10 menit di hari pertama Anda :)

Ya, ini adalah bendera merah. Apa yang diberitahukan kepada Anda adalah bahwa manajer tidak mengerti bagaimana mengelola risiko dalam proyek perangkat lunak. Apa yang harus dia lakukan adalah mencari tahu apa yang sebenarnya menyebabkan keterlambatan di tempat pertama dan kemudian mulai instrumen proses untuk secara efektif mengelola risiko jadwal yang tidak dapat dihindari terjadi selama proyek perangkat lunak.

TIDAK PERNAH dalam keadaan apa pun saya akan menandatangani kontrak dengan manajer saya menjamin jadwal. Yang lain mengatakan dia menandatangani kunci pada spesifikasi. Ini menurut saya tidak cukup. Ini tidak menjelaskan kesulitan yang tidak terduga dengan alat atau teknologi, desain yang tidak lengkap atau buruk, kinerja anggota tim lain, dll.

Ini bukan bendera merah, ini adalah kebodohan tingkat senjata.

Jika perkiraan dan tenggat waktu ditiup secara konsisten, hal yang rasional untuk dilakukan adalah mengidentifikasi penyebab dan meningkatkan proses.

Jika Anda menyalahkan dan menendang kuda karena Anda tidak tahu ke mana Anda akan pergi, jangan heran jika kuda itu menggigit Anda dan melarikan diri!

Sementara manajer itu tidak sesuai dengan permintaannya. Dia tidak sepenuhnya bisa disalahkan. Jika Anda bekerja di wilayah yang sepenuhnya asing, tidak ada yang salah dengan mengatakan "Saya tidak tahu." Perlu beberapa saat bagi saya untuk menyadari bahwa "Saya tidak tahu" adalah jawaban yang sangat bisa diterima, jadi saya tahu betapa sakit rasanya mengucapkan kata-kata itu. Tetapi jika Anda benar-benar tidak tahu maka itulah jawabannya. Dan jika mereka menolak pada saat itu meminta mereka untuk memberi Anda perkiraan berapa banyak uang yang diperlukan untuk membuat tumpukan setinggi Menara Sears (membuatnya Willis). Dan apakah mereka bersedia menandatangani kontrak untuk membayar Anda setiap sen yang mereka hilangkan?

Manajer Proyek mana pun yang layak gajinya harus tahu bahwa beberapa hal tidak cocok dengan bagus dan cantik dalam spreadsheet. Kadang-kadang hal-hal dilakukan ketika mereka selesai. Saya pikir Anda baik-baik saja dengan memberikan kemajuan pada berapa banyak yang telah Anda lakukan. Berhentilah memberikan nomor pembaruan.

Latihan lain adalah memecah tugas besar menjadi unit-unit yang lebih kecil yang lebih dapat diperkirakan. Latihan ini akan membantu Anda memahami dengan lebih baik apa yang perlu Anda lakukan juga. Lihatlah Estimasi Perangkat Lunak Steve McConnell dan Pola Persyaratan Perangkat Lunak Stephen Withall untuk kiat-kiat mogok tugas dan masing-masing menemukan persyaratan tersembunyi.

Jangan menembak dari pinggul berdasarkan perkiraan. Luangkan waktu untuk memecahnya. Memperkirakan sejumlah besar tugas kecil akan memberi Anda perkiraan keseluruhan yang lebih baik (karena hukum rata-rata beberapa estimasi Anda akan di bawah tetapi beberapa akan berakhir dan mereka akan cenderung saling menimbang) dari tugas besar.

Tanyakan "manajer proyek" Anda: Apakah kami menjual perangkat lunak atau tenggat waktu?

Saya seorang manajer proyek dan seorang programmer :-) Saya bisa terus berseru tentang bagaimana kebanyakan PM dari luar industri dan tidak dapat menangani apa pun yang tidak cocok dengan baik ke dalam model lini produksi ... tapi saya tidak akan, tidak di sini. Alih-alih, inilah polemik panjang tentang apa yang harus dilakukan (Tn. Mod, jika terlalu lama lakukan apa yang Anda inginkan dengannya). Saya setuju dengan komentar yang sudah dibuat di sini, beberapa harus Anda lakukan sebelum yang lain, tapi inilah yang saya pikir akan menjadi langkah pertama Anda . Oh, dan jawaban yang jelas untuk pertanyaan Anda adalah ya, tapi itu dijabarkan dalam bahasa yang penuh warna & terperinci di bawah ini.

Sebelum saya mulai, perhatikan bahwa PM kemungkinan besar memberi Anda kesedihan, karena orang lain yang lebih jauh dalam rantai makanan memberi mereka kesedihan. Mereka (kami) adalah makhluk sederhana ... Ada beberapa cara untuk menghindari situasi yang Anda gambarkan - Mike Brown memberikan perlindungan yang cukup baik. Tidak ada yang salah dengan melakukan workshopping selama 3/4/5 .. jam langsung sebelum memulai (sebenarnya semua jenis alarm harus dimatikan jika ini tidak terjadi). Dan jika Anda pergi ke wilayah yang tidak dikenal, dorong kembali dan minta seminggu untuk meneliti area & teknologi untuk dapat membuat perkiraan yang masuk akal (Anda akan ingin melakukan ini dengan benar karena Anda ingin teknologi baru untuk belajar & bermain dengan don kan?). Jika PM Anda dan manajemen di tempat Anda berada tidak memahami ini ... perbarui resume Anda dan cari jalan keluar terdekat, meninggalkan mereka pada nasib yang pantas mereka terima. Bahwa PM bahkan akan berpikir untuk mendapatkan karyawan penuh waktu untuk menandatangani kontrak seperti itu adalah pertanda buruk ... satu-satunya cara saya bisa melihat bahwa merekamungkin tidak benar-benar tidak kompeten adalah bahwa mereka benar-benar hanya bermain permainan pikiran dengan pimpinan proyek Anda dan Anda (dari apa yang saya baca mereka tidak menempatkan ini langsung kepada Anda, dan pada akhirnya tidak menindaklanjuti ancaman). Bagaimanapun, PMing adalah surga bagi psikopat korporat standar Anda. Itu baik bahwa orang lain pergi ke kelelawar untuk Anda dari apa yang Anda katakan, jadi saran di bawah ini mungkin akan menjadi positif bagi Anda pada akhirnya. Saya membayangkan mereka akan memiliki revolusi di tangan mereka jika ternyata lebih dari sekadar bicara.

Jadi untuk situasi aktual / lubang yang Anda gambarkan , karena itu akan terjadi lagi pada seseorang, di suatu tempat (seperti sekitar 5 menit yang lalu, dan lagi di 5 lainnya, scheduleRepeat ()). Mungkin tanpa kebodohan kontrak, tetapi alur cerita dasarnya selalu sama. Mengorganisir rapat (!), Mereka suka rapat ;-) setiap orang dapat menepuk punggung mereka sendiri pada akhirnya seperti sesuatu yang sebenarnya dilakukan. PENTING:Pastikan Anda menyertakan pimpinan proyek / pemimpin tim / arsitek / manajer proyek teknis Anda dalam undangan rapat setelah membahas masalah tersebut dengan mereka dan menyelesaikannya. Semakin tinggi hierarki yang bisa Anda pilih untuk seseorang di 'sisi' Anda, semakin baik. Karena PM Anda akan melihatnya dan mencoba mencocokkan manajer desain Anda dengan yang setara. Jika tidak, mereka bodoh dan Anda sudah menang. Itu sendiri biasanya akan menarik mereka kembali ke barisan, karena sekarang mereka dapat dilihat oleh seseorang yang mungkin dapat memecat mereka di tempat. Jika mereka bermain game dengan Anda, Anda diizinkan untuk membalas budi.

Dalam pertemuan tersebut, pelajari rincian teknis tentang apa yang Anda hadapi dan mengapa dibutuhkan waktu. Mereka seharusnya ingin mengetahui hal ini (dan bagaimana mereka dapat membantu Anda menyelesaikannya), tetapi fakta yang menyedihkan umumnya ini tidak terjadi ... Anda mungkin akan mendapatkan 10 menit sebelum mata mereka kembali ke kepala mereka. Sekarang apa yang ingin saya lakukan di sini mungkin tidak legal ... ya, saya sudah memeriksa, sebenarnya sangat ilegal dan Anda tidak ingin masuk penjara selama itu. Intinya adalah Anda telah berupaya sebaik-baiknya untuk menjadi proaktif dan jika Anda memiliki beberapa atasan hadir, rasa sakit Anda sekarang adalah milik mereka ... sebagaimana mestinya. Anda harus menggunakan penilaian Anda tentang bagaimana hal-hal cenderung terjadi, karena 'eskalasi' adalah apa yang akan terjadi. Jika kepemimpinan di tempat Anda berada setengah layak, mereka akan melakukan hal yang benar, dan lakukan hal yang benar oleh Anda juga. Jika tidak, maka Anda akan memiliki resume Anda di pasar sebelumnya ... Anda akan pergi pada kesempatan pertama (dan sepertinya Anda akhirnya). Kepemimpinan akan jatuh ke dalam dua kelompok - baik mereka secara teknis cerdas dan mereka akan langsung melihat sudut pandang Anda; atau tidak dan apa yang akan mereka lakukan selain tersenyum dan menahannya? Jika mereka bisa melakukan apa yang Anda lakukan, maka mereka sudah melakukannya. t dan apa yang akan mereka lakukan selain tersenyum dan menahannya? Jika mereka bisa melakukan apa yang Anda lakukan, maka mereka sudah melakukannya. t dan apa yang akan mereka lakukan selain tersenyum dan menahannya? Jika mereka bisa melakukan apa yang Anda lakukan, maka mereka sudah melakukannya.

Simpan masalah perubahan persyaratan sebagai kartu truf Anda untuk digunakan di akhir ... itu akan berfungsi sebagai jalan keluar bagi semua orang. Proyek itu sendiri dan klien / stakeholder sial akan diambil namanya sia-sia. Cara paling maju tanpa rasa sakit adalah untuk jenis reset terjadi pada proyek, dan mungkin bahwa PM akan diam-diam dipindahkan ke area yang berbeda. Mukjizat bisa terjadi sesekali. Jika masalah kontrak diangkat dalam pertemuan oleh PM, maka balas dengan persyaratan membekukan permintaan kontrak-kontra - sejauh yang saya ketahui mereka sudah membakar jembatan mereka dengan Anda, dan untuk seluruh tim pengembangan, ketika mereka mulai memainkan permainan pikiran semacam itu.

Sebelum saya sign-off: Mengubah ruang lingkup / persyaratan - salah satu alasan terbaik untuk mengadopsi metodologi Agile, sehingga klien / pemangku kepentingan bertanggung jawab untuk mengubah pikiran mereka tentang apa yang mereka inginkan ...

Oh, satu hal lagi: pada pernyataan "Saya tidak tahu", selalu menjadi tolok ukur pribadi saya tentang bagaimana mengukur nilai sesama teknolog atau anggota dalam salah satu tim proyek saya. Saya menemukan satu-satunya orang yang dapat mengatakan bahwa langsung ke wajah Anda adalah yang terbaik yang ada, terutama karena seseorang yang tahu bahwa mereka berada di luar kemampuan mereka tidak akan pernah mengatakan itu - membuka mereka untuk secara jelas diekspos oleh seseorang dengan kemampuan aktual dalam detak jantung. Di sisi lain seseorang yang akan menghadap ke depan dan mengatakannya, juga akan memiliki rencana dasar (bahkan jika belum dipikirkan melalui) tentang bagaimana mengatasi hal yang tidak diketahui sehingga dalam 24 jam akan ada jawaban yang lebih berguna, dan dalam waktu seminggu bahkan lebih baik. Ketika Apollo 13 terbang di sekitar sisi gelap Bulan, ada sejumlah besar "Aku tidak tahu" terjadi.

Ya, ini seharusnya menaikkan bendera merah, terutama jika Anda adalah karyawan penuh waktu. Bagaimana kondisi kontraknya? Apakah Anda benar-benar akan dipecat jika Anda telah melewati tenggat waktu? Atau apakah Anda hanya melewatkan bonus? Apa yang akan mereka lakukan?

Bendera yang ditimbulkannya adalah bahwa manajer tidak tahu cara mengelola proyek yang berurusan dengan teknologi baru / asing dan persyaratan pergeseran yang secara langsung memengaruhi upaya yang diperkirakan. Sementara tenggat waktu yang keras kadang-kadang terjadi, seorang manajer yang tahu situasinya tidak boleh mencoba membuat karyawan menandatangani kontrak untuk menegakkannya. Larut malam dan waktu krisis akan buruk tetapi itu mungkin setara untuk kursus. Dan kadang-kadang masih batas waktu akan tergelincir. Itu terjadi, dan seperti orang lain diposting, satu-satunya cara untuk tetap pada jadwal adalah untuk membekukan persyaratan AWAL sehingga masih ada cukup ruang untuk menjaga timeline.

Dari apa yang Anda katakan, bel alarm terlambat beberapa bulan. Biasanya berisiko untuk mendasarkan proyek yang sensitif terhadap waktu pada teknologi yang belum dikenal oleh staf. Sangat sulit untuk melakukannya jika Anda tidak memahami pengumpulan persyaratan dan manajemen ruang lingkup.

Yang mengatakan, saya setuju dengan jawaban lain. Juga, Anda mungkin ingin memperbarui resume Anda jika Anda belum melakukannya.

Sama seperti semua responden lain, saya sangat setuju bahwa ini harus menaikkan bendera merah.

Sepertinya PM tidak ingin terlibat dalam proses pengembangan.

Dalam praktik pribadi saya, saya sudah lama beralih dari berurusan dengan spesifikasi di muka rinci, sign-off, perkiraan proyek penuh, atau harga penawaran tetap (dari perspektif konsultasi).

Alasan untuk ini adalah realisasi, yang dibicarakan oleh banyak pakar Agile dan Lean Software, bahwa perangkat lunak bukanlah entitas manufaktur tetap, tetapi sebagian besar merupakan proses penemuan.

Banyak orang masih mengalami masalah dengan gagasan ini, dan sepertinya PM Anda juga. Itu datang ke pemahaman sederhana tentang pertukaran.

Spesifikasi awal yang kaku dan perkiraan tetap berfungsi untuk sistem di mana biaya perubahan tinggi. Seperti membangun gedung tinggi. Jika Anda lupa menentukan poros elevator di bagian depan, maka akan sangat sulit untuk memperbaiki bangunan begitu telah didirikan. Biaya perubahan yang tinggi membutuhkan banyak perencanaan di muka, mempelajari komponen dan teknologi yang tidak diketahui, dan eksperimen di muka. Hanya setelah Anda menyelesaikan semua pekerjaan rumah ini, Anda dapat memperkirakan anggaran dan biaya.

Dalam perangkat lunak, orang-orang semakin terbiasa dengan gagasan bahwa biaya perubahan rendah, sehingga mereka suka mengambil keuntungan karena dapat mengubah hal-hal begitu mereka melihat rilis, memasukkan pemahaman baru tentang aplikasi, bisnis, pelanggan pada dasar yang sedang berlangsung. Semua ini bagus dan peluang besar jika dimanfaatkan dengan benar. Kebanyakan orang yang saya temui dan bekerja dengan perangkat lunak sebenarnya tidak menikmati menghabiskan banyak waktu merencanakan atau menyelidiki; kebanyakan dari kita (termasuk PM) ingin melihat traksi yang sedang berlangsung. Di sinilah pengembangan berulang berasal dari rilis fungsionalitasnya yang kecil dan bertahap. Ada praktik lain yang dapat digunakan, seperti pengembangan berbasis tes untuk memastikan bahwa biaya perubahan tetap rendah dan utang teknis terkandung.

Membuat pekerjaan ini melibatkan "kontrak" antara kedua belah pihak, pemilik produk (Agile berbicara untuk PM Anda atau pelanggan atau tim QA) dan pengembang. Pengembang setuju untuk hanya mengerjakan hal-hal yang telah diprioritaskan sebagai yang paling penting untuk iterasi yang diberikan dan untuk tidak mengambil selamanya dengan itu, tetapi berusaha untuk merilis potongan fungsionalitas terintegrasi penuh sering (misalnya mingguan atau bulanan). Pemilik produk, sebaliknya, setuju untuk terus-menerus meninjau rilis tambahan dan memberikan umpan balik segera. Mereka juga setuju untuk menetapkan prioritas untuk iterasi berikutnya dan sekali ditetapkan untuk tidak berubah pikiran selama durasi iterasi.

Bagian terakhir dari perjanjian ini adalah sesuatu yang kemungkinan besar tidak dimengerti oleh PM Anda. Banyak PM tradisional sebenarnya tidak. Beberapa dari mereka berpikir pekerjaan mereka selesai ketika mereka menurunkan spec; mereka tidak ingin mendengar tentang masalah, alternatif, cara yang lebih baik, dll. Kelemahannya adalah ini tidak hanya melawan arus pengembangan perangkat lunak tetapi juga merugikan organisasi dengan meninggalkan banyak peluang di atas meja.

Lihatlah Agile Manifesto: http://agilemanifesto.org/ Mungkin beresonansi dengan Anda. Buku yang bagus untuk dibaca juga "Pengembangan Perangkat Lunak Ramping" karya Mary Poppendieck

Semoga berhasil.

Sepertinya manajer mencari seseorang untuk disalahkan ketika dia melapor kepada atasannya.

Saya menemukan jika Anda memiliki manajer yang tidak masuk akal yang berpikir 'perkiraan' sama dengan 'periode tetap', hal terbaik yang harus dilakukan adalah memikirkan periode perkiraan yang sangat murah hati dan kemudian menggandakannya!

Selain itu, paksakan manajer untuk memastikan persyaratan sepenuhnya terperinci dan diperbaiki. Setiap perubahan sejak saat itu tidak akan ditangani tanpa 'negosiasi ulang resmi' dengan manajer proyek pada waktu penyelesaian yang baru.

Akhirnya manajer proyek mendapatkan ide dan rencana yang sesuai.

Pengalaman pribadi saya dengan hal-hal semacam ini adalah bahwa manajer proyek berusaha untuk membuat jejak kertas untuk membuang Anda sambil membuat pemutusan Anda kesalahan Anda sendiri. Itu akan membuatnya menjadi bendera yang sangat merah. Jarak tempuh Anda mungkin, tentu saja, agak berbeda.

Jawaban yang bagus ada di sekitar, tetapi izinkan saya menambahkan 2 sen saya.

Jika Anda pernah mempelajari probabilitas, ada yang namanya "variabel acak". Itu adalah angka yang nilainya tidak Anda ketahui, tetapi Anda dapat menggambarkan ketidaktahuan Anda dengan distribusi, seperti distribusi normal (kurva lonceng) atau lainnya.

Intinya adalah, pekerjaan itu akan memakan waktu, tetapi perkiraan sebelumnya akan salah, sedikit atau banyak, di sisi negatif atau positif, sehingga ada risiko, dan seseorang harus mengambil risiko. Umumnya, jika orang mengambil risiko, mereka dibayar untuk itu. Biaya asuransi uang.

Ketika saya menjadi seorang konsultan, saya biasanya memiliki pilihan untuk menandatangani kontrak waktu dan bahan dibandingkan dengan kontrak harga tetap. Dengan waktu dan bahan, klien menanggung risiko. Dengan harga tetap, saya menanggung risikonya. Dengan harga tetap, saya membangun margin keselamatan, karena jika saya gagal memenuhi target, tidak ada yang menang.

Meminta Anda untuk berkomitmen pada tanggal pengiriman tetap, terutama tanpa persyaratan tetap, kedengarannya seperti mencoba mentransfer risiko kepada Anda, meskipun tidak jelas apa yang sebenarnya Anda riskan. Dalam kasus apa pun, satu respons adalah menempatkan margin keselamatan yang sangat murah hati.

PS Anda selalu melihat ini dengan kontrak pemerintah. Ada permintaan awal untuk proposal, tawaran dibuat, tawaran rendah diterima, dan kemudian permintaan perubahan mulai masuk, sehingga balon biaya, dan kontraktor akan disalahkan. Hal-hal bekerja jauh lebih baik jika ada hubungan kerja tim antara klien dan kontraktor, daripada hubungan yang bermusuhan.

Ya, tentu saja ini mengibarkan bendera tentang pengalaman dan kompetensi mantan bos Anda. Ya, seperti yang disarankan kebanyakan orang, ini saat yang tepat untuk memperbarui CV Anda.

Ya, seperti yang dinyatakan oleh jawaban lainnya, dalam sebagian besar situasi Anda tidak ingin menandatangani perjanjian itu. Namun, saya ingin menyarankan bahwa mungkin ada beberapa situasi di mana Anda dapat mempertimbangkan untuk menandatanganinya.

Sebagian besar pengembang dan manajer menyadari adanya gesekan yang konstan antara fungsi, tenggat waktu, dan anggaran. Banyak juga yang akan menominasikan kualitas sebagai dimensi keempat ("Saya dapat memberikan serangkaian persyaratan yang Anda sukai, besok dengan anggaran rendah, selama Anda bersedia menerima bahwa itu tidak akan berhasil!")

Tetapi ada dimensi lain: risiko. Jika saya hanya perlu berhasil mengirimkan 50% dari waktu, saya dapat menurunkan perkiraan saya sangat; mereka empuk untuk menangani tingkat pengiriman yang jauh lebih tinggi.

Kami dapat mengatasi risiko dalam beberapa cara (dan perkiraan padding adalah salah satunya). Manajer tidak mau menerima risiko apa pun, dan ingin menempatkan risiko di pundak Anda. Biasanya, Anda harus menolak langkah seperti itu ... kecuali jika Anda mendapat kompensasi yang baik.

Jika Anda dapat mencalonkan tenggat waktu Anda, dengan jumlah padding yang dapat diterima bersama untuk mengatasi penundaan yang tidak terduga, dan dapat menegosiasikan bonus (sangat besar) jika Anda menekannya, dan berada dalam posisi keuangan untuk dapat menangani penalti (misalnya dipecat) jika Anda tidak bisa, Anda mungkin menemukan bahwa itu adalah "pertaruhan" yang berharga untuk menerima risiko itu sendiri dan menandatangani kontrak - dengan klausul yang sesuai untuk menangani perubahan persyaratan.

Ini adalah kebodohan langsung. Saya tidak tahu apa tujuan akhirnya, tetapi setiap manajer proyek yang bertanggung jawab untuk produk perangkat lunak setengah sadar harus menyadari bahwa perkiraan adalah apa yang mereka sebut: perkiraan. Mereka bukan janji dan mereka tidak dapat dibuat seperti itu tanpa menguras pengembang perangkat lunak dari semua energi mereka atau memaksa mereka untuk melanggar "janji" mereka.

Jika Anda ingin menunjukkan betapa konyolnya kontrak semacam itu, berikut ini ada dua saran:

a) Sangat melebih-lebihkan ke titik di mana proyek membutuhkan waktu lima atau sepuluh kali selama Anda memperkirakan tanpa kontrak. Jika manajer proyek bertanya mengapa perkiraannya sangat tinggi, cukup katakan bahwa Anda hanya memastikan bahwa Anda dapat memenuhi kontrak Anda.

b) Ini telah disarankan: Minta kontrak yang memastikan tidak ada satu pun persyaratan yang berubah dan pastikan ini termasuk memperbaiki kesalahan pengejaan. Dalam pengalaman saya, tidak ada proyek perangkat lunak tunggal di mana persyaratan tidak berubah di beberapa titik selama pengembangan. Manajer proyek lebih cenderung harus melanggar kontrak mereka daripada Anda.

Jika manajer proyek akan menyetujui salah satu dari dua saran ini, Anda akan tahu pasti bahwa mereka tidak waras.

Ngomong-ngomong, bagaimana kontrak untuk karyawan penuh waktu bisa bekerja? Saya tidak tahu tentang peraturan kerja di negara lain, tetapi sebagai karyawan penuh waktu di perusahaan saya tidak berpikir bahwa ada orang yang bisa memaksa Anda untuk menandatangani kontrak yang mengikat untuk memenuhi tenggat waktu dan memiliki kasus yang valid. Tentu, mereka bisa memberi Anda neraka jika Anda tidak memenuhi tenggat waktu, tetapi mereka tidak perlu kontrak untuk itu. Tidak ada yang bisa memecat Anda atau memberi Anda lebih sedikit uang. Mereka dapat memotong bonus yang Anda sepakati paling buruk. Jadi, kecuali ini berbeda di negara lain, ini tampaknya lebih seperti ancaman kosong daripada apa pun yang Anda anggap serius.

Saya akan menentang arus di sini.

Situasi yang Anda gambarkan tidak biasa di tingkat tim Teknik , terutama setelah proyek / rilis yang sangat terlambat. Dalam banyak situasi, manajemen Anda dan seluruh organisasi Anda mungkin sebenarnya telah mendaftar untuk tanggal rilis tertentu, dan bagian lain dari organisasi akan diarahkan untuk tanggal tersebut. Mungkin ada tekanan luar biasa pada rantai manajemen Anda untuk mencapai tanggal tersebut.

Di sinilah proses rekayasa umum masuk. Anda mungkin pernah mendengar tentang model air terjun. Ada model-model lain, tetapi tujuan akhirnya adalah untuk secara konsisten memberikan sesuatu ketika diharapkan dan berisi apa yang disepakati. Spesifikasi fungsional, desain, daftar tugas, dll. Semuanya mengarah ke membuat proses ini dapat diprediksi. Komunikasi, analisis risiko, dan (seperti yang Anda katakan) secara teratur memperbarui harapan tentang jadwal mengurangi kejutan dan membuat informasi tersedia sesegera mungkin sehingga rencana dapat disesuaikan. Dan ya, harus ada penyesuaian rencana setiap kali fitur ditambahkan atau dihapus.

Dalam beberapa tim yang telah bekerja sama dengan saya, saya tidak akan ragu untuk memperlakukan perkiraan saya sebagai komitmen yang ditandatangani, tetapi itu mencerminkan kualitas tim dan manajemen, dan bukan keahlian khusus dalam memperkirakan. Sebuah tim yang bersedia menandatangani kontrak untuk memberikan tepat waktu adalah indikator tim yang bekerja dengan baik, bukan bendera merah.

Saya katakan tempatkan diri Anda pada posisinya dan cobalah untuk memahami apa yang memotivasi hal itu. Dari calon Manajer / Akuntan, mereka perlu nomor untuk membenarkan apa yang sedang terjadi dan bagaimana keadaannya.

Mungkin karena diejek di ruang dewan karena menggeser tenggat waktu, kehilangan terlalu banyak tenggat, dia mencoba cara yang paling sederhana untuk membuatnya terkunci. Berikan saya nomor dan tanda tangani di sini! Anda berada di ujung yang lain, hanya bisa merasakan bahwa itu adalah sesuatu yang bertentangan dengan Anda. Bagaimana pun membuat perkiraan dan seiring menyadari bahwa mereka perlu disesuaikan adalah apa yang lebih berguna baginya. Jika Anda memahami apa yang memotivasi permintaan itu dan apa masalah sebenarnya yang ia hadapi, Anda mungkin bisa membantunya dan diri Anda sendiri. Sebagai programmer, kami memecahkan masalah. Ini tidak berbeda, pahami dan selesaikan masalahnya dan ia akan menjadi teman baik Anda. Ada begitu banyak pekerjaan yang harus dilakukan sehingga tidak ada yang punya waktu untuk merencanakan dendam pribadi! Dia butuh bantuan dengan pekerjaannya, solusi paling sederhana adalah meminta seseorang menandatangani surat! Mungkin dia mendapatkan itu dari buku manajemen untuk boneka, "Dapatkan pekerja Anda untuk menandatangani dan bertanggung jawab atas sebuah angka." Lucu tapi sedih

"Berjalan di atas air dan mengembangkan perangkat lunak dari suatu spesifikasi itu mudah jika keduanya dibekukan."

-Edward V. Berard

Jika persyaratan Anda berubah, maka tidak masuk akal untuk mengharapkan perkiraan awal Anda menjadi akurat. Ya, ini seharusnya bendera merah.

Apakah kontrak menentukan hukuman karena tidak memenuhi tenggat waktu? Jika tidak, itu sama sekali bukan masalah - Anda hanya menandatangani perkiraan berdasarkan pengetahuan Anda pada saat itu.