pemulihan bencana perangkat lunak ketika seorang insinyur tiba-tiba tidak tersedia

8

Baru-baru ini di perusahaan saya, kami memiliki sebuah proyek di mana tenggat waktu sangat ketat, dan semuanya berjalan sesuai rencana sampai saya tidak tersedia karena masalah pribadi yang ekstrem.

Akhirnya kami melewatkan tenggat waktu 4 ~ 5 hari.

Apa rencana pemulihan yang biasa untuk kondisi ini? haruskah perusahaan saya mencoba melakukan outsourcing pengembang untuk menyelesaikan pekerjaan saya? bahkan itu bisa memakan waktu beberapa hari untuk menemukannya?

project-management software deadlines

— Sherif
sumber

3

Jika bagian pekerjaan Anda dapat di-outsourcing-kan tanpa pelatihan atau transfer informasi dari Anda, Anda mungkin tidak menambahkan banyak nilai. Tetapi biasanya, dalam proyek yang dikelola dengan baik, seseorang harus memberikan waktu kontingensi (berdasarkan durasi proyek tetapi tidak pernah kurang dari seminggu) untuk mengelola risiko seperti ini.

— James McLeod

Mengapa tidak ada orang yang menyelesaikan pekerjaan?

— Euforia

7

"Baru-baru ini di perusahaan saya, kami memiliki proyek di mana tenggat waktu sangat ketat" - jadi dengan kata lain, (a) manajer proyek membuat tenggat waktu yang tidak memungkinkan kesalahan terjadi, dan (b) manajer proyek itu tidak dapat memperkirakan risiko apa pun (seperti pengembang tidak tersedia untuk jangka waktu tertentu, bukan keadaan yang eksotis) dan karenanya tidak dapat merencanakannya. Sepertinya Anda memerlukan manajer proyek baru, kecuali yang ini dapat belajar dari kesalahannya.

— Kyralessa

4

@ Kyralessa: Atau (c) manajer proyek terpaksa memeras semua penyangga dari perencanaan karena orang lain membuat janji yang tidak realistis kepada pelanggan. "Membangun ini tidak sesulit itu, jadi mari kita berjanji tanggal pengiriman sebelum kami meminta estimasi dari pengembang."

— Bart van Ingen Schenau

3

@ BartartIngenSchenau, dalam situasi seperti itu, tugasnya sebagai manajer proyek adalah mendorong kembali.

— Kyralessa

10

Itu tergantung pada durasi yang tidak terduga dari waktu yang tersedia, sisa durasi proyek, cara tugas-tugas didistribusikan dan konsekuensi dari kehilangan tenggat waktu.

Pengembang perangkat lunak tidak bisa saling menggantikan. Pengembang membangun pengetahuan tentang sistem ketika sistem tumbuh, dan menambahkan sumber daya baru perlu untuk mengatasi pengetahuan kontekstual yang hilang dari sumber daya baru.

Beberapa praktik baik mengurangi risiko yang terkait dengan tidak tersedianya tiba-tiba:

tinjauan sejawat memastikan bahwa pengetahuan tentang pengembangan dibagi di antara beberapa pengembang. Dalam hal tidak tersedianya, seluruh tim dapat mengatur ulang untuk mengambil alih, atau dalam kasus terburuk membawa pembuat kode baru dan mengatur transfer pengetahuan.
tim colocated terintegrasi yang bekerja sama erat untuk membuat keputusan desain dapat mengurangi ketidaktersediaan dengan cara yang sama. Pengetahuan bersama tentang desain keseluruhan memfasilitasi redistribusi pekerjaan dan pengarahan pendatang baru.
dokumentasi formal pada akhirnya dapat membantu. Namun dalam praktiknya ini hanya berfungsi dengan baik jika dokumentasi yang dihasilkan oleh satu pengembang digunakan oleh pengembang lain (atau model yang digunakan dalam alat pembuat kode). Dokumentasi yang hanya dibaca sendiri seringkali tampak jauh lebih ambigu. Jika seorang pengembang baru harus mengambil alih pekerjaan seperti itu, dokumentasi diri mungkin menimbulkan banyak pertanyaan yang dijawab.

Membawa pengembang baru ketika ada tenggat waktu yang ketat sangat menantang, karena memberi pengarahan kepada pendatang baru membutuhkan waktu tim, dalam periode di mana tidak ada waktu luang. Jika Anda sakit selama 1 minggu tidak masuk akal. Ini harus dipertimbangkan jika biaya pengarahan pendatang baru dikompensasi oleh manfaat dari sumber daya baru, biasanya jika ada biaya tinggi terlambat, atau jika tidak mungkin untuk menunda, atau jika tidak tersedianya jangka waktu yang lebih lama.

— Christophe
sumber

1

Ini cukup dekat. Yang paling penting adalah secara aktif memastikan seseorang dapat melindungi Anda saat pemberitahuan tiba.

— candied_orange

Dalam manajemen proyek ada konsep untuk kasus-kasus ini. Planifikasi harus mempertimbangkan situasi semacam ini. Sekarang sudah terlambat bagi perusahaan untuk meminimalkan dampak. Jujurlah dengan para pemangku kepentingan dan buat mereka tahu bahwa tenggat waktu harus dipindahkan. Memenuhi tenggat waktu hampir tidak ada artinya dibandingkan dengan memenuhi harapan. Mencoba untuk menyelamatkan kekurangan perencanaan ini dengan mengorbankan "kualitas", solusinya bisa lebih mahal daripada yang Anda pikirkan ... Setelah rilis hanya ada satu "kesan pertama".

— Laiv

@Laiv Terima kasih atas tanggapan Anda. Saya tidak bisa menilai apakah dalam kasus ini batas waktu dapat ditunda atau tidak. Di masa lalu saya mengelola beberapa proyek pengenalan Y2K dan EURO yang kritis dimana penundaan bukanlah suatu pilihan. Tetapi saya setuju dengan Anda pada prinsipnya: lebih baik membahas masalah tenggat waktu dengan pelanggan ketika risikonya terlalu tinggi, daripada mencoba secara diam-diam menemukan alternatif yang mustahil dan gagal. Planifikasi kontingensi tentu saja merupakan keharusan; tetapi sayangnya itu tidak cukup untuk menghadapi situasi ekstrem seperti itu (cadangan cenderung habis pada akhir proyek).

— Christophe

Ya itu benar. Saya belum melihat terlalu banyak proyek yang sedang berjalan meskipun ada anggaran untuk kemungkinan.

— Laiv

5

Rencana yang biasa untuk ini adalah membangun kemungkinan ke tenggat waktu. Hal-hal terjadi, Anda sering tidak pernah mencapai tenggat waktu. Anda menjadi tidak tersedia hanyalah cegukan lain dalam rencana yang disusun dengan hati-hati yang tidak pernah berjalan sesuai rencana!

— gbjbaanb
sumber

Anda sepenuhnya benar: setiap rencana memerlukan cadangan darurat untuk menghadapi risiko. Masalah dengan kontingensi yang terlalu banyak adalah efek ramalan yang terpenuhi dengan sendirinya: pada akhirnya kontingensi akan dikonsumsi pula. Dan dalam minggu-minggu terakhir dari rencana itu, orang mungkin masih jatuh sakit meskipun tidak ada margin yang tersisa. Jadi kemungkinan saja tidak cukup.

— Christophe

1

Sebenarnya, kontingensi adalah strategi mitigasi risiko tetapi ada cara lain untuk menangani risiko, termasuk menghapusnya (pastikan orang lain dapat mengambil alih tanpa mempengaruhi jadwal), menerimanya (default jika Anda tidak mengelola risiko), atau transfer itu (dalam hal ini, beri tahu klien / pelanggan bahwa mereka tidak membayar cukup untuk menjamin pengiriman tepat waktu dan mereka harus siap untuk menangani penundaan).

— James McLeod

5

Ini disebut "faktor bus". Pada dasarnya, risiko yang ditimbulkan proyek jika pengembang ditabrak bus. Memiliki pengembang tidak tersedia selama seminggu adalah masalah kecil dibandingkan dengan kehilangan pengembang secara permanen. Ini bisa menjadi kecelakaan atau penyakit yang tiba-tiba, tetapi tidak terlalu dramatis, bisa saja menjadi pengembang inti yang beralih pekerjaan dalam waktu singkat atau dipecat. Atau pengembang inti ditransfer ke tugas prioritas tinggi lain di departemen yang berbeda.

Singkatnya, Anda harus merencanakan untuk menurunkan faktor bus, atau Anda harus siap untuk menguranginya, misalnya dengan memiliki buffer dalam tenggat waktu atau cukup fleksibel untuk dapat mendorong tenggat waktu. Apa yang biasanya tidak dapat Anda lakukan adalah melakukan outsourcing tugas yang kompleks dalam waktu singkat, atau merekrut pengembang baru - hampir selalu membutuhkan lebih banyak waktu untuk memperkenalkan pengembang baru ke sistem yang ada daripada menunggu seminggu bagi pengembang inti untuk kembali. Jika tim kecil kehilangan anggota mereka tentu saja akan lebih lambat, tetapi jika juga harus memperkenalkan anggota baru, mereka bahkan akan lebih lambat .

Anda dapat menurunkan faktor bus dengan meminta tim berbagi pengetahuan secara terus-menerus dan ulasan sejawat (atau bahkan pemrograman pasangan). Tetapi tentu saja ini adalah sesuatu yang harus terjadi sebelum bus tiba.

— JacquesB
sumber

2

Setiap karyawan dapat menjadi tidak tersedia selama seminggu, atau sebulan, atau selamanya, tanpa pemberitahuan, kapan saja. Kecelakaan, sakit, sudah cukup dari pekerjaan ini, banyak alasan lain. Terserah manajemen untuk memastikan bahwa kejadian seperti itu menjengkelkan, mungkin mahal, tetapi bukan bencana.

Jika Anda memiliki tim sepuluh, Anda mungkin kehilangan 10% dari tim Anda. Perusahaan harus dapat mengatasinya jika anggota tim lainnya termotivasi (membayar lembur sangat memotivasi). Jika Anda adalah satu tim, maka pekerjaan itu tidak akan selesai. Jika Anda memiliki karyawan lain yang dapat ikut serta, penundaan dapat diminimalkan. Menyewa seseorang dari luar akan sulit, meskipun Anda mungkin menemukan beberapa kontraktor yang dapat mulai pada pemberitahuan hari selama beberapa minggu dengan tarif per jam yang sangat tinggi.

Hal terbaik untuk dilakukan adalah memiliki kontrak dll. Sehingga penundaan penyelesaian suatu produk bukan bencana keuangan. Dan untuk memiliki tanggal penyelesaian yang terencana dan dapat dicapai sebelum tenggat waktu. Mempunyai karyawan yang dapat membantu satu sama lain membantu (tetapi dapat menjadi masalah untuk dicapai).

Dan jika Anda memiliki tenggat waktu yang harus dicapai, maka mungkin ruang lingkup pekerjaan lebih fleksibel. Dengan kata lain, jatuhkan fitur untuk memenuhi tenggat waktu Anda.

— gnasher729
sumber

1

Salah satu cara kunci untuk mengurangi "Bus Factor" yang @JacquesB sebutkan di atas adalah pemrograman pasangan sebagai teknik inti. (Praktek saya sendiri adalah menggunakan istilah "Faktor Lotere" karena itu kurang morbid tetapi efeknya sama.)

Banyak pengembang membenci pemrograman pasangan; banyak manajer membencinya juga, karena alasan yang sama sekali berbeda (beberapa pengembang benci dipaksa untuk berkomunikasi dengan manusia lain untuk waktu yang lama; beberapa manajer sering merasa salah seolah-olah mereka membayar dua kali lebih banyak uang untuk satu output).

Namun, mempasangkan semua program dengan cara sama-sama menghilangkan risiko satu titik kegagalan manusia, dengan memastikan bahwa tugas pengembangan apa pun dilakukan dan dipahami oleh setidaknya dua pengembang.

— Jim Kiley
sumber

0

Ada beberapa cara saya melihat hal semacam ini ditangani:

Bagikan latihannya

Hal yang paling jelas untuk dilakukan adalah membagikan pekerjaan di antara sumber daya yang ada (dengan asumsi ini mungkin). Bagaimana memastikan para pengembang mulai bekerja hampir merupakan jawaban dalam dirinya sendiri tetapi pada akhirnya, itu bermuara pada persyaratan perekaman yang tepat, desain dan kemajuan. Hal-hal seperti pemrograman pasangan juga dapat sangat membantu di sini.

Dorong tenggat waktu kembali atau coba cakar waktu kembali

Periksa dengan pelanggan untuk melihat apakah tenggat waktu dapat diperpanjang. Atau, dimungkinkan untuk mendapatkan tambahan waktu pengembangan dengan bekerja malam hari, akhir pekan dan hari libur.

Jatuhkan tugas lain

Apakah ada tugas non-kritis lain yang dapat dibatalkan sementara untuk memberi ruang?

Majulah

Apakah ada pekerjaan yang direncanakan setelah pengembangan yang dapat dibawa ke depan seperti dokumentasi, skrip pengujian dan konfigurasi?

Akui saja sudah terlambat

Bicaralah dengan pelanggan lebih awal. Mungkin saja untuk memberikan sebagian - atau paling tidak, Anda bisa mendapatkan pengarahan yang layak pada prioritas relatif dari hal-hal lain.

Sumber daya tambahan

Suatu kemungkinan - tetapi ini sendiri membawa risiko. Ini akan membutuhkan waktu untuk meningkatkan kecepatan mereka dan karena bersifat sementara, mereka bisa membuat Anda lebih buruk.

Periksa jalur kritis

Jika pihak lain terlibat - periksa apakah mereka masih tepat sasaran. Tidak ada gunanya menggerakkan langit dan bumi untuk menyelesaikan sesuatu jika katakan, tim penguji satu bulan di belakang untuk menguji berbagai hal.

Menerima kenyataan risiko

Ada ungkapan umum dalam profesi hukum yang menyatakan bahwa masalah sulit menciptakan solusi yang buruk. Mungkin tergoda untuk mencoba dan membuat semua orang memahami segalanya untuk mencakup semua kemungkinan. Namun, ini adalah tugas bodoh.

Pengembang harus menghabiskan waktu berkualitas untuk perkembangan mereka sendiri. Mengkonsumsi jumlah waktu yang semakin meningkat menjadi au fait dengan perkembangan lain adalah kegiatan yang sangat dipertanyakan. Jalan tengah yang masuk akal mungkin untuk memiliki ahli materi pelajaran dan wakil.

— Robbie Dee
sumber