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


19

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.


29
"Dan aku bahkan membayarnya uang muka untuk pekerjaan yang belum dia lakukan." - yang mungkin menjadi alasan untuk menuntutnya, Anda harus mengkonfirmasi pengacara.
Doc Brown

dapatkah Anda memberi kami beberapa rincian tentang seberapa mahir Anda dalam memahami kode sumber sisa?
Maru

10
Pertanyaan pertama dan PALING PENTING: apakah Anda memiliki kontrak?
Radu Murzea

5
Jika saya adalah programmer pengganti, maka dokumentasi yang saya inginkan adalah apa yang dia kerjakan: ruang lingkup, tonggak, deskripsi masalah, dll. Saya lebih suka kode itu dibiarkan apa adanya, dan saya tidak akan merasa berguna jika kodenya "didokumentasikan" oleh seseorang yang mungkin tidak bisa menganalisisnya sebaik yang saya bisa.
user16764

15
Hal pertama adalah mengubah login dan kata sandi ke server Anda.
Michael Riley - AKA Gunny

Jawaban:


17

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


1
@pocto: orang-orang di luar sana tetapi Anda harus dapat ... a) membayar mereka b) menemukan mereka (sayangnya tidak dapat membantu Anda di sana karena saya tidak pernah melihat). Tapi begitu Anda menemukan orang yang tepat, ia akan mengambil stok situasi saat ini termasuk situs web yang ada dan melakukan panggilan. Sangat penting untuk memperbaiki bug yang ada dan mempertahankan pelanggan yang ada. Pastikan itu adalah bagian dari rencananya untuk maju. Hal lain yang perlu Anda pertimbangkan adalah bahwa Anda benar-benar perlu menemukan seseorang untuk membawa sebagian besar perusahaan Anda. Mungkin alih-alih mencari hanya seorang karyawan, cari ...
DXM

1
... rekan. Sebagai bagian dari paket kompensasi, tawarkan sebagian dari perusahaan Anda (mungkin 20-30%?). Jika Anda berhasil, Anda akan menghasilkan 20% lebih sedikit tetapi jika Anda gagal memiliki 20% lebih dari 0 tidak akan ada gunanya bagimu. Ini mungkin membantu dengan memberikan insentif kepada karyawan / mitra baru Anda untuk memastikan ia memiliki minat yang serupa dengan minat Anda (yaitu membuat situs web berhasil, tidak hanya mengumpulkan gaji mingguan)
DXM

1
Pocto, beberapa pendapat yang disajikan di sini tidak diterima secara universal. Misalnya, memiliki tim pengembangan yang sama selamanya memang menyederhanakan banyak hal, tetapi (seperti yang Anda ketahui) Anda tidak dapat memastikan hal itu. Jadi dokumentasi dan kode yang baik diperlukan agar orang lain dapat turun dengan biaya yang lebih rendah (tetapi masih signifikan). "Percikan kegembiraan belum padam" terdengar seperti agisme murni bagi saya. Mengelola pengembangan perangkat lunak itu sulit - membedakan programmer yang baik dari yang buruk akan sulit, saya khawatir.
psr

@psr: Saya akan mengambil kode yang ditulis dengan baik dengan penamaan / struktur yang baik dan dokumen desain tingkat tinggi setiap hari melalui kode yang tidak dapat dibaca dengan satu ton dokumen desain yang hebat. Dan saya tidak bermaksud menjadi agist (sp?) Tapi saya percaya profesi kami membutuhkan pembelajaran dan pertumbuhan yang konstan dan banyak yang tidak dapat dilakukan hanya pada pekerjaan karena teknologi akan bergeser di bawah Anda. Namun, saya telah melihat banyak orang yang lebih muda dan lebih tua dari saya, yang dari waktu ke waktu tampaknya hanya mengatakan, "Saya sudah cukup belajar, sekarang saya hanya akan bekerja". Saya juga melihat orang-orang yang jauh lebih tua dari saya yang suka rock, tetapi mereka melakukan lebih dari sekadar bekerja 40 jam.
DXM

13

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.


15
Saya tidak merekomendasikan menghubungi perusahaan barunya dan berbicara dengan mereka tentang dia. Benar atau tidak, di AS setidaknya itulah yang menciptakan potensi gugatan pencemaran nama baik.
GrandmasterB

3
Jawaban yang bagus, tetapi ... "Seluruh gagasan gaji adalah untuk membayar pekerjaan yang dilakukan" .. di negara mana itu? Kami baru saja mengajak seorang pria bergabung dengan tim kami, menghabiskan waktu satu bulan di sana dan tidak mengubah satu baris kode pun (di antara masalah lain). Kami membayar gaji sebulan penuh tetapi harus melonggarkannya karena kami tidak tahu kapan ia produktif. Dalam pengalaman saya sendiri (yang mencerminkan dilbert), saya bisa datang untuk bekerja dan bekerja keras atau menghabiskan sepanjang hari berjalan dan berbicara, dan saya akan dibayar dengan gaji yang persis sama.
DXM

@DXM, Anda sebagian benar: Anda akan mendapatkan gaji selama sebulan bahkan jika pekerjaan Anda tidak layak untuk itu. Tapi ini efek dari perlindungan oleh pemerintah. Itu hal yang baik, tetapi tidak selalu adil. Dan seperti yang Anda katakan - orang yang malas tidak akan bisa mempertahankan posisinya lama. Tapi saya sangat setuju dengan pendapat Anda.
Creative Magic

Saya harus -1 untuk menghubungi perusahaan baru tempat orang ini bekerja. Jika mereka kehilangan pekerjaan, mereka dapat menuntut Anda. Lebih penting lagi, setiap dokumentasi atau perbaikan kode yang berasal dari orang yang pahit akan memiliki kualitas yang buruk sehingga Anda mungkin tidak menginginkannya sejak awal.
MrFox

8

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.


Itu jawaban yang SANGAT komprehensif dan bermanfaat, Raybarg. Saya pikir apa yang Anda katakan sangat masuk akal - untuk pertama-tama mempekerjakan programmer lain untuk memperbaiki bug yang ada dan kemudian membahas aspek dokumentasi sebagai kontrak lain. Saya bahkan berharap memiliki programmer dalam jangka panjang, setelah dia memperbaiki bug, jadi ini akan berhasil.
pocto

@ Raybarg Tentang "setelah memperbaiki bug, berkomentar hal-hal": Saya mendorong Anda untuk melakukan komentar ketika memperbaiki bug. Bagaimanapun juga, tahap itu adalah tempat Anda mengumpulkan semua pengetahuan untuk didokumentasikan. Jadi, mengapa tidak segera menuliskannya? Ini hanya akan membantu menemukan dan memperbaiki lebih banyak bug lebih cepat.
Marcel

@ Raybarg, dapatkah Anda menjelaskan lebih lanjut tentang apa yang Anda katakan di sini tentang "program yang menghasilkan dokumen dari kode sumber". Betulkah? Program apa ini dan bagaimana cara kerjanya?
pocto

3

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.

1

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.


0

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.


Terima kasih banyak, Uooo, atas jawaban Anda. Saya terutama menyukai bagian dari mempekerjakan pengembang kedua untuk membuat situasi seperti ini lebih mudah di masa depan. Tapi apa yang akan menjadi pekerjaan pengembang kedua?
pocto

@pocto Memelihara dan mengembangkan perangkat lunak Anda. Seperti yang tertulis: Saya tidak akan fokus memberi tahu programmer Anda apa yang harus dilakukan dalam urutan apa . Ketika bug perlu diperbaiki, ini harus dilakukan. Ketika fitur dan unit test baru perlu diimplementasikan, dokumentasi perlu ditulis, ini harus dilakukan. Anda tidak menyewa "Perbaikan Bug" atau "Penulis dokumentasi" atau "Pembuat fitur", Anda menyewa pengembang perangkat lunak. Dan tugasnya adalah melakukan semua itu.
Uooo
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.