Programmer lama menghilang. Akan merekrut programmer lain. Bagaimana saya mendekati ini? [Tutup]

Setelah menghabiskan lebih dari satu tahun bekerja pada proyek jaringan sosial untuk saya menggunakan WordPress dan BuddyPress , programmer saya telah menghilang, meskipun ia dibayar setiap minggu, untuk seluruh periode. Ya, dia belum mati karena saya menggunakan pelacak email untuk mengonfirmasi dan melihat dia membuka email saya, tetapi dia tidak merespons. Sepertinya dia mendapat pekerjaan lain. Saya heran mengapa dia tidak bisa mengatakannya. Dan saya bahkan membayarnya uang muka untuk pekerjaan yang belum dilakukannya.

Masalahnya adalah saya tidak pernah meminta dokumentasi lengkap untuk sebagian besar fungsi yang dikodekannya. Dan ada fungsi BANYAK untuk periode 1+ tahun ini, dan beberapa dari mereka memiliki bug yang masih belum diperbaiki. Sekarang sepertinya semua membingungkan.

Apa hal pertama yang harus saya lakukan sekarang? Bagaimana saya melanjutkan?

Saya kira hal pertama yang harus dilakukan adalah mendapatkan programmer lain, tetapi saya ingin memulai dengan langkah yang benar dengan mendokumentasikan semua kode saat ini sehingga setiap programmer dapat bekerja pada semua fungsi tanpa masalah.

Apakah itu hal pertama yang harus saya lakukan? Jika ya, bagaimana saya melakukannya?

Apa jenis standar dokumentasi yang diperlukan untuk hal seperti ini? Bisakah saya mendapatkan programmer yang hanya akan melakukan dokumentasi untuk semua kode dan memperbaiki bug atau dokumentasi tidak terlalu penting?

Juga, apakah Anda pikir mendapatkan programmer "individu" yang lain lebih baik atau mendapatkan perusahaan yang memiliki programmer yang bekerja untuk mereka, sehingga jika programmer yang ditugaskan untuk proyek saya menghilang, orang lain dapat menggantikannya, tanpa keterlibatan saya? Saya merasa ini adalah pendekatan yang seharusnya saya lakukan di awal.

Berdasarkan interaksi yang kami lakukan di komentar, saya akan pergi dengan asumsi bahwa Anda tidak mengusir satu-satunya pengembang Anda karena hal-hal pribadi. Namun, berdasarkan percakapan itu, saya akan menebak bahwa kemunduran ini sebagian besar masih menjadi tanggung jawab Anda sebagai manajer perekrutan. Seperti yang Anda sebutkan, Anda sama sekali tidak memiliki pengalaman dengan pengembang, tetapi kemudian bagaimana Anda membuat keputusan tentang cara merekrut?

Kedengarannya seperti Anda melakukan yang terbaik, tetapi Anda mempekerjakan seseorang yang tidak bisa menangani skala proyek ini, ia membangun fondasi yang rapuh yang runtuh di bawahnya dan kemudian ia pergi begitu saja. Sayangnya, perbedaan antara pengembang dan pengusaha adalah bahwa mantan dibayar per jam / gaji tetapi mereka dapat memilih untuk datang dan pergi sesuka mereka. Dia dibayar untuk jam kerjanya dan dia pergi ketika dia memilih untuk tidak dibayar lagi. Tidak ada yang bisa Anda lakukan tentang itu.

Jadi bagaimana sekarang? Sepertinya Anda mulai menempuh jalan untuk mengganti orang dengan proses. Andai saja Anda memiliki cukup dokumentasi, orang-orang dapat pergi dan orang lain dapat mengambil dari mana mereka tinggalkan. IMO yang tidak bekerja dan jika itu bekerja, itu masih akan jauh lebih mahal daripada memiliki tim karyawan permanen yang dapat diandalkan. Manajemen di berbagai perusahaan selama 30 tahun terakhir telah mencoba untuk mengganti orang dengan dokumentasi yang cukup (termasuk pekerjaan terakhir saya) dan mereka gagal setiap saat. Itu sebabnya saya memutuskan untuk berganti pekerjaan dan sekarang mereka terjebak dengan dokumen mereka yang sudah ketinggalan zaman dan tidak akurat, sementara saya memiliki waktu dalam hidup saya di sebuah startup baru.

Apa yang akan saya lakukan jika saya adalah Anda adalah mencoba untuk menemukan orang yang tepat dengan keterampilan dan pengalaman yang cukup untuk mengambil proyek ini dan menyelesaikannya. Ini tidak hanya mencakup keterampilan pengkodean, tetapi juga desain, arsitektur, serta manajemen proyek dasar. Jangan mencoba mendefinisikan bagaimana dia melakukan pekerjaannya, atau berapa banyak dokumen yang perlu dia hasilkan. Fokus saja pada menemukan orang yang tepat dan bersiaplah untuk membayar sesuai. Ketika Anda menemukannya, pastikan peran Anda adalah mendukungnya dan menghilangkan rintangan dari jalannya, bukan memantau / manajemen mikro. Saya tidak menyiratkan bahwa Anda melakukan itu sebelumnya, tetapi saya tahu banyak manajer cenderung melakukan itu dan itu hanya kontra produktif.

Bicaralah dengan pengusaha lain, mungkin yang memiliki latar belakang rekayasa perangkat lunak lebih banyak. Baca forum-forum ini dan berikan serangkaian pertanyaan untuk diajukan kepada calon karyawan Anda. Sampaikan masalahnya dan tanyakan pendekatan apa yang akan dilakukan. Jika dia adalah orang yang tepat (dan dengan asumsi dia tidak melihat halaman ini), dia seharusnya dapat menyarankan banyak hal yang sudah disarankan orang lain dalam hal apa yang harus dilakukan di perusahaan Anda ketika Anda mulai pulih. Minta dia untuk menentukan rencana dari saat dia disewa hingga kapan v1.0 Anda akan dikirimkan. Bagaimana dia akan membawamu ke sana. Minta bantuan untuk mewawancarai orang seperti itu.

Hanya beberapa dari pikiran saya: Pelacakan bug adalah suatu keharusan (Jira berharga $ 10 untuk tim yang terdiri dari 10 orang). Kontrol sumber adalah suatu keharusan (git gratis. Biaya memaksa kacang untuk tim hingga 5 atau lebih orang). Kode Anda adalah dokumentasi Anda. Bukan dokumen kata-kata tertulis Anda. Dia harus meninjau kode dan menyimpan apa yang bisa diselamatkan; buang sisanya dan fokus pada penulisan kode yang dapat dikelola dan dibaca. Simpan dokumentasi untuk beberapa dokumen desain tingkat tinggi, beberapa halaman. Dia harus tahu teknologi yang sedang Anda kerjakan. Jangan mempekerjakan seseorang dengan niat baik; Anda tidak dapat membiarkan mereka belajar pada waktu Anda. Tanyakan kepada mereka apa proyek lain yang telah mereka lakukan (sayangnya Anda atau seseorang yang Anda temukan mungkin harus mengikuti aspek teknis dari hal-hal tersebut). Anda mencari seseorang dengan pengalaman yang cukup tetapi pada saat yang sama tidak terlalu banyak bahwa gairah telah padam. Temukan seseorang yang lapar untuk memberi dampak. Metodologi yang ia usulkan atau ikuti harus memungkinkan Anda untuk melihat pekerjaan secara berkala (satu atau dua minggu) dan untuk memberikan umpan balik instan. Jangan mempekerjakan siapa pun yang mengatakan, itu akan siap tepat dalam 7,4 bulan, saya akan memberi tahu Anda ketika sudah selesai.

Semoga berhasil

Ini adalah situasi yang aneh, dan saya cukup yakin Anda tidak menceritakan keseluruhan cerita. Saya bekerja dengan banyak orang, beberapa di antaranya pergi karena berbagai alasan (saya menjadi kolega mereka), tetapi jangan mencoba memberi tahu kami bahwa semuanya super baik dan suatu hari tidak ada kontak.

Tapi itu bukan masalah. Setidaknya tidak lagi; Anda harus belajar dari kesalahan Anda dan mencoba untuk tidak mengulanginya di masa depan. Dan ya, saya sangat menyarankan bahwa 50% adalah kesalahan Anda atas kepergiannya.

Sekarang tentang memecahkan masalah saat ini:

1. Cobalah untuk menghubungi programmer Anda. Dia membaca email Anda - menawarkan uang kepadanya untuk dokumentasi / memperbaiki bug yang paling penting. Tidak ada orang lain yang bisa memperbaikinya lebih cepat daripada dia. Tidak berhasil? Cobalah untuk menemukan di mana dia bekerja, hubungi perusahaan itu dan ceritakan kisah Anda. Perusahaan yang baik tidak akan mempekerjakan orang yang dapat melakukan hal yang sama untuk mereka. Setidaknya mereka akan memberitahunya untuk menyelesaikan dokumentasi untuk Anda.

   CATATAN: Anda tidak ingin orang itu kembali, Anda hanya perlu dokumentasi yang sudah selesai

2. Bersiaplah bahwa pekerjaan satu tahun Anda akan batal. Dia mungkin melarikan diri ketika Anda meminta hasil dan dia tahu dia tidak bisa memberikan. Ada kemungkinan bahwa kode ini penuh dengan peretasan, implementasi kotor, dan kualitas keseluruhan buruk. Bahkan jika dia kembali - dia mungkin tidak akan memiliki keterampilan atau bahkan waktu untuk melakukannya dengan benar.

3. Cari orang lain. Dia perlu mengetahui teknologi yang sama (bahasa pemrograman, kerangka kerja, dll.). Jika kualitas kodenya bagus - ia bisa melanjutkan, jika tidak, ia akan bisa memperbaikinya. Ya, refactoring membutuhkan waktu tanpa penerapan fitur baru, tetapi itu membuat kode dapat dipelihara dan itulah yang Anda butuhkan. Plus, seseorang yang dapat memperbaiki kode buruk adalah programmer yang sangat baik, pegang dia.

   CATATAN: Adalah konyol untuk membayar uang muka. Seluruh gagasan gaji adalah untuk membayar pekerjaan yang dilakukan. Bukan karena janji yang dibuat :)

4. Buat daftar. Adalah kepentingan terbaik Anda untuk memiliki rencana. Spesifikasi teknis yang pernah dibaca akan memungkinkan programmer baru untuk memahami pekerjaan dan tonggak sejarah. Memiliki setidaknya tiga dokumen penting:

   • Deskripsi keseluruhan proyek - dokumen yang akan memungkinkan bahkan non-programmer untuk mengetahui apa proyek tersebut.

   • Timeline - bagian apa dan kapan Anda berharap siap? Apa yang sudah dilakukan?

   • Spesifikasi teknis - ini panjang. Ini adalah dokumen yang ingin dibaca oleh seorang programmer. Pisahkan menjadi beberapa bagian logis dan jelaskan sedetail mungkin fitur dan alur kerja dari bagian tertentu itu.

Bekerja dengan perusahaan tidak terlalu baik; peluang Anda tidak akan menjadi lebih baik. Dan Anda akan membayar lebih dari 10 kali jika Anda hanya mempekerjakan satu programmer. Jika Anda memiliki tim kecil, misalkan 3-5 orang, pekerjakan seorang programmer yang bersedia menjadi pemimpin tim. Dia akan melakukan pekerjaan yang jauh lebih baik mengelola tim.

Mendokumentasikan kode setelahnya oleh programmer lain? Ini hanya pengalaman dan pendapat saya sendiri untuk memberi tahu Anda jangan mengambil jalan itu.

Tanpa pengetahuan yang lebih terperinci tentang kualitas basis kode itu, pendapat saya adalah bahwa pendekatan terbaik Anda adalah menyewa seorang programmer baru untuk memperbaiki bug, memelihara, dan mungkin membuat modifikasi yang Anda butuhkan.

Pendapat itu memiliki poin kunci dari kemungkinan modifikasi (mengubah atau menambahkan), karena mereka membutuhkan persyaratan yang harus dipenuhi. Ini berarti bahwa semacam spesifikasi kebutuhan harus ditulis. Ini adalah dokumen.

Yang mengarah ke titik pemeliharaan seluruh proyek. Anda tidak memberi tahu dalam pertanyaan Anda apakah persyaratan program saat ini atau bahkan dokumentasi fungsional kasar ada, tetapi di situlah Anda harus fokus sekarang.

Jika Anda tidak memiliki dokumentasi sama sekali, pada titik ini, maka terserah Anda untuk mengisi kekosongan itu. Anda tidak dapat menyewa seorang programmer untuk merekayasa balik aplikasi Anda dan secara ajaib membuat dokumentasi darinya . Anda harus "menjelaskan" apa yang Anda ingin program lakukan (bahkan jika itu berarti menjelaskan kembali apa yang sudah diprogram.)

Ketika Anda memiliki dokumen yang ditulis (baik itu dalam bentuk persyaratan atau spesifikasi fungsional), Anda akan mendapatkan hasil yang jauh lebih baik dari mempekerjakan seorang programmer baru karena Anda dapat menyerahkan dokumentasi dan mulai bekerja dari sana.

Ada juga banyak program yang menghasilkan dokumen dari kode sumber, yang merupakan cara yang baik untuk menghasilkan kerangka menjelaskan kode sumber yang sebenarnya (ini dalam bidang spesifikasi teknis) yang Anda hanya dapat bekerja dalam konteks menjelaskan aspek teknis dari fungsionalitas yang ditentukan dalam spesifikasi fungsional, yang menentukan fungsionalitas persyaratan yang ditentukan dalam spesifikasi persyaratan.

Jadi ya, pendapat saya adalah menyewa seorang programmer untuk memperbaiki bug. Setelah dia memperbaiki bug yang Anda setujui harus diperbaiki, Anda dapat mendiskusikan aspek dokumentasi sebagai kontrak lain. Dengan keberuntungan Anda menyewa seorang programmer yang memiliki pengalaman dan dapat berkontribusi pada langkah-langkah apa yang harus Anda ambil selanjutnya dari sana.

Begini cara saya mendekati masalah:

• Anda memiliki pengetahuan domain. Anda tahu fitur mana yang tersedia di situs web sekarang, yang mana yang ingin Anda tambahkan di masa depan, dan mungkin dapat membuat daftar beberapa bug yang dilaporkan oleh pengguna juga.

• Ada tumpukan kode ini duduk di sana, dibiarkan di sudut. Mungkin buggy, tetapi masih memberikan nilai karena situs tersebut memiliki pengguna aktif. Menulis ulang yang lengkap dengan demikian akan menjadi kesalahan IMO.

Jembatan antara keahlian domain Anda dan kode rusak saat programmer pergi. Anda perlu membangunnya kembali sehingga basis kode dapat disinkronkan dengan kebutuhan Anda lagi dan pembaruan di masa mendatang dapat dikembangkan.

Masalahnya, jembatan itu tidak bisa sepenuhnya terbuat dari dokumentasi. Perangkat lunak adalah masalah manusia seperti halnya teknis. Jika Anda tidak menjelaskan kepada programmer baru apa yang Anda harapkan dengan sangat rinci, ia akan kesulitan menyimpulkannya hanya dari kode - terlebih lagi jika programmer sebelumnya menulis kode yang samar, tidak terdokumentasi, dan kurang teruji. Dan jika Anda tidak bekerja dalam kerjasama erat dengan programmer baru untuk menemukan cara yang otomatis dan berkesinambungan untuk memverifikasi kode sesuai dengan persyaratan Anda, dengan kata lain untuk membuat jembatan lebih kuat, masalahnya pasti akan terulang kembali.

• Secara teratur duduk (bahkan secara virtual) dengan programmer baru untuk sesi pemrosesan pengetahuan domain. Selama setiap sesi ini, tulis bersama spesifikasi untuk sebagian kecil dari produk Anda. Ini bisa berupa satu halaman web, bisa juga fitur. Menjadikannya spesifikasi yang dapat dieksekusi (ala Behaviour-Driven Development ) akan meningkatkan tingkat kepercayaan Anda bahwa jembatan berfungsi, karena Anda dapat menjalankannya terus menerus dan diperingatkan ketika ada sesuatu yang salah. Ini juga akan membuat hidup pengembang lebih mudah.

  Setelah sesi, pengembang dapat kembali ke pekerjaannya dan menulis tes tingkat rendah yang memvalidasi bahwa kode saat ini sesuai dengan spesifikasi. Jika tidak sesuai, maka programmer memiliki semua yang dia butuhkan untuk memperbaikinya. Penting juga untuk tetap tersedia untuk setiap pertanyaan yang mungkin dia miliki.

• Coba pertahankan kolaborasi yang erat dan terus-menerus antara Anda dan programmer pada proyek Anda, dan pastikan ini juga berlaku di antara mereka. Ini diperlukan jika Anda ingin budaya fungsional dan teknis di sekitar proyek Anda hidup, menghindari masalah seperti yang Anda alami sekarang. Ini tentu saja membutuhkan tidak hanya 2+ pengembang yang mengerjakan proyek Anda, tetapi juga bahwa mereka berbagi satu sama lain pengetahuan tentang semua yang mereka tulis. Dengan demikian seseorang dapat bertindak sebagai gagal ketika yang lain hilang. Teknik seperti pemrograman pasangan dan ulasan kode adalah cara yang baik untuk mencapai itu.

Hanya menambahkan apa yang dikatakan semua orang,

Jika Anda tidak dapat membuat programmer lama mendokumentasikan kodenya meskipun dengan harga mahal, maka jangan berharap orang lain dapat mendokumentasikannya dengan lebih baik. Jadi di sini ada beberapa opsi pada apa yang dapat Anda lakukan untuk saat ini untuk membuat programmer baru produktif pada hari pertama.

1. Dapatkan basis data bug, dan mulai masukkan semua bug yang Anda temukan di dalamnya. Ini adalah daftar tugas yang harus dilakukan programmer. Dokumentasikan dengan baik dan sedetail mungkin (sumber file / penyebab root, apa yang dilakukannya, dan apa yang harus dilakukan). Ada banyak perangkat lunak pelacakan bug gratis, seperti Bugzilla , Redmine dan JIRA . Jangan ragu untuk menggunakan mana pun yang Anda suka.
2. Buat lembar spesifikasi untuk proyek Anda. Ini akan memberi programmer beberapa arah setelah bug telah dibersihkan Anda dapat melihat panduan Joel tentang spesifikasi penulisan .
3. Buat jadwal atau garis waktu untuk proyek Anda. Mereka harus memiliki tenggat waktu dan tonggak di mana mereka dibayar untuk pekerjaan yang mereka berikan daripada membayar mereka di muka.

Sekarang itu keluar dari jalan, Anda dapat mulai mencari seorang programmer. Dan seperti yang dikatakan Creative Magic, mengalihdayakan pekerjaan ke perusahaan dapat menyebabkan bencana atau meledakkan harga hingga tak terbatas dan seterusnya.

Kali ini, mulai merencanakan dengan benar untuk faktor bus ketika merekrut programmer. Orang-orang datang dan pergi dan tidak ada yang bisa Anda lakukan untuk itu, jadi bersiaplah untuk yang terburuk kali ini dengan mendapatkan dua programmer, atau seperti kata Uooo, dapatkan satu programmer dan satu tester.

Sekarang, begitu programmer berada di toko bersama Anda, Anda dapat mulai meminta mereka untuk mendokumentasikan kode mereka ke depan daripada meminta mereka untuk mendokumentasikan kode lama, sungguh, lupakan itu.

Hal-hal lain yang perlu dipertimbangkan ketika mendapatkan programmer baru, pastikan mereka tahu kontrol sumber dan pengujian otomatis. Juga, cobalah untuk mendapatkan sebanyak mungkin pemeriksaan pada Tes Joel sebanyak mungkin dengan bantuan mereka, Anda hanya dapat melakukan begitu banyak pada Anda sendiri.

Jadi, satu-satunya programmer Anda ditabrak bus , dan Anda perlu penggantian sekarang.

Anda dapat mencoba menuntut mantan programmer Anda, berdasarkan kontrak Anda, atau mencari tahu apa yang salah dengannya. Dengan asumsi bahwa dia tidak akan kembali, ini tidak akan membantu Anda.

• Anda ingin menyelesaikan produk Anda, jadi cari seorang programmer yang memiliki pengalaman dalam memelihara dan mengembangkan sistem yang ada. Saya tidak akan fokus memberi tahu programmer Anda apa yang harus dilakukan dalam urutan apa. Pastikan Anda mempekerjakan seseorang yang profesional, yang menulis dokumentasi dan unit test kapan pun diperlukan.
• Dari pihak Anda, Anda dapat memastikan bahwa programmer baru memiliki semua yang diperlukan untuk pekerjaannya : Spesifikasi kebutuhan, mesin kerja yang kuat, dan sebagainya. Anda menginginkan programmer profesional, jadi berikan dia lingkungan kerja yang profesional.

Juga, pikirkan untuk mempekerjakan pengembang kedua untuk membuat situasi sulit seperti ini lebih mudah di masa depan. Penguji juga akan berguna untuk jaminan kualitas.