Akankah memberikan rekrutmen baru suatu proyek terpisah dari pengembang yang berpengalaman membantu para pemula meningkat lebih cepat?

Kami memiliki 7 pengembang dalam satu tim dan perlu menggandakan kecepatan pengembangan kami dalam waktu singkat (sekitar satu bulan). Saya tahu ada aturan umum bahwa "jika Anda mempekerjakan lebih banyak pengembang, Anda hanya kehilangan produktivitas untuk beberapa bulan pertama". Proyek ini adalah layanan web e-commerce dan memiliki sekitar 270 ribu baris kode.

Gagasan saya untuk saat ini adalah untuk membagi proyek menjadi dua sub-proyek yang independen atau kurang dan membiarkan tim baru bekerja pada yang lebih kecil dari dua sub-proyek, sementara tim saat ini bekerja pada proyek utama. Yaitu, tim baru akan bekerja pada fungsionalitas checkout, yang pada akhirnya akan menjadi layanan web independen untuk mengurangi kopling. Dengan cara ini, tim baru bekerja pada proyek dengan hanya 100 ribu baris kode.

Pertanyaan saya adalah: apakah pendekatan ini akan membantu pengembang pemula untuk beradaptasi dengan mudah dengan proyek baru? Apa cara lain untuk memperluas tim pengembangan dengan cepat tanpa menunggu dua bulan sampai pemula mulai memproduksi lebih banyak perangkat lunak daripada bug?

=======

MEMPERBARUI

Perusahaan ini gagal total, tetapi bukan karena alasan yang Anda sebutkan. Pertama-tama, saya salah informasi tentang ukuran dan kemampuan tim baru. Saya harus mengevaluasi mereka sendiri. Kedua, perekrutan ternyata merupakan pekerjaan berat di situs itu. Di lokasi kantor pusat mempekerjakan jauh lebih mudah, tetapi di kota tim kedua tampaknya ada kekurangan pengembang dengan kualifikasi yang diperlukan. Akibatnya, bukannya diproyeksikan 1,5 bulan pekerjaan diperpanjang menjadi sekitar 4,5 bulan, dan dibatalkan di tengahnya oleh manajemen puncak.

Kesalahan lain yang saya buat (dan diperingatkan oleh Alex D) adalah bahwa saya mencoba menjual refactoring ke manajemen puncak. Anda tidak pernah menjual refactoring, hanya fitur.

Startup itu ternyata berhasil juga. Refactoring yang tidak pernah terjadi berubah menjadi utang teknis: sistem menjadi lebih monolitik dan kurang dapat dipertahankan, produktivitas pengembang secara bertahap menurun. Saya tidak di tim sekarang, tapi saya berharap mereka menyelesaikannya dalam waktu dekat. Kalau tidak, saya tidak akan memberikan satu sen pun untuk kelangsungan proyek.

Altought, saya setuju seperti semua orang di sini, bahwa:

"... menambah lebih banyak pengembang ke proyek yang tertunda, membuat proyek, untuk menunda lebih banyak ..."

Saya punya perasaan, Anda akan melakukannya, di mana saja, jadi ...

Gagasan Anda dapat membantu, jika, proyek Anda saat ini, cukup terorganisir, berdasarkan modul, subsistem, atau sub proyek.

Apa yang Anda mungkin ingin coba, itu untuk memberi mereka potongan kecil / modul / formulir / kelas proyek Anda, untuk bekerja dengan, bukan semua proyek.

Jika Anda menggunakan database, Anda mungkin ingin membuat salinan DB yang berfungsi dengan data, dan mengaksesnya dari modul atau subsistem kode yang akan digunakan.

Memiliki pengembang baru yang mengetahui bahasa pemrograman atau lingkungan pemrograman, tidak cukup, aplikasi perangkat lunak bisa menjadi sangat kompleks.

Apakah Anda memiliki beberapa dokumentasi aplikasi seperti: UML, ER, Codd-Yourdon, apa pun?

Semoga berhasil.

Pertanyaan saya adalah apakah pendekatan ini akan membantu pengembang pemula untuk beradaptasi dengan mudah dengan proyek baru?

"Pemula" mungkin berarti baru bagi Anda, atau mungkin berarti baru bekerja sebagai pengembang perangkat lunak sama sekali. Jika Anda akan mempekerjakan sekelompok pengembang untuk mengerjakan proyek penting sesuai jadwal, pastikan bahwa setidaknya sebagian besar karyawan baru adalah pengembang berpengalaman, dan lebih disukai yang pernah menulis proyek yang mirip dengan yang Anda coba untuk membangun.

Apa cara lain untuk memperluas tim pengembangan dengan cepat tanpa menunggu dua bulan sampai mereka mulai memproduksi lebih banyak perangkat lunak daripada bug?

• Beli atau lisensikan produk yang sudah ada daripada mencoba membuat sendiri. Apakah Anda benar - benar perlu menemukan kembali roda checkout?

• Seperti yang saya katakan di atas, pekerjakan orang yang memiliki pengalaman membangun jenis sistem yang Anda inginkan.

• Bahkan sebelum Anda merekrut tim baru ini, Anda harus memikirkan apa yang perlu mereka ketahui tentang barang-barang Anda yang ada. Pastikan Anda memiliki cukup waktu untuk sesi pelatihan untuk membantu mempercepatnya.

• Sudahkah Anda membuat seperangkat persyaratan tertulis? Jika tidak, lakukan itu sekarang. Jika Anda berharap untuk merancang proyek alih-alih membiarkan tim baru melakukan itu, Anda harus menyiapkan dokumen desain yang jelas juga, tetapi terbuka untuk perubahan sebagai tanggapan terhadap masukan dari anggota tim baru.

• Apakah Anda memiliki proses pengembangan yang terdefinisi dengan baik? Basis data bug? Kontrol versi? Proses peninjauan kode? Panduan gaya? Siapkan semuanya.

• Jangan mengharapkan keajaiban. Anda ingin merekrut tim tujuh orang dan membuatnya bekerja secara produktif dalam hitungan minggu, tetapi menginginkannya tidak berarti Anda dapat memilikinya. Tergantung di mana Anda berada, mungkin butuh waktu lebih lama dari satu bulan hanya untuk menemukan tujuh orang yang cocok. Mencoba untuk terburu-buru sekarang hanya akan menyebabkan rasa sakit dan biaya nanti.

IMHO menempatkan semua pengembang baru pada proyek baru, terpisah dari tim yang ada pasti akan membawa masalah. Ya, ini (bolehkan) membiarkan tim lama Anda tetap bekerja kurang lebih sesuai kecepatannya saat ini. Namun, orang-orang baru tidak akan memiliki petunjuk tentang arsitektur keseluruhan dan gambaran besar, sehingga mereka akan mengambil banyak waktu untuk mempercepat ... dan bahkan kemudian mereka mungkin menuju arah yang salah.

Saya sarankan membagi tim Anda yang ada menjadi dua dan merekrut anggota baru ke dalam kedua tim. Dengan cara ini ada orang-orang di kedua tim yang dapat membimbing para pendatang baru dan memastikan bahwa visi arsitektur yang koheren tetap terjaga.

Kalau tidak, saya setuju dengan Caleb tentang mendokumentasikan persyaratan yang jelas, mendefinisikan proses pengembangan dan alat-alat, dan menyediakan waktu untuk pelatihan ... dan juga mengharapkan bahwa tim 7 yang akan dipekerjakan dan mendapatkan kecepatan dalam sebulan adalah tidak realistis.

Dmitry, menggandakan kecepatan pengembangan Anda dalam waktu singkat adalah tujuan yang sangat ambisius. Beberapa saran bagus telah diposting di sini; tetapi, apa pun yang Anda coba, sadari bahwa itu mungkin tidak terjadi . jika laju perkembangan Anda tidak berlipat ganda, apa konsekuensinya, dari perspektif bisnis? Apakah Anda mencoba mendorong untuk memenuhi tenggat waktu?

Jika Anda mencoba memenuhi tenggat waktu, dapatkah Anda melakukannya dengan lebih andal dengan memotong fitur? Saya telah menemukan cara yang bagus untuk membuat "tenggat waktu yang terlewatkan" dapat diterima oleh seorang pelanggan adalah dengan melakukan rilis tambahan; merilis versi yang memiliki subset dari fitur yang diperlukan, dan kemudian karena lebih banyak fitur siap, lepaskan secara bertahap, hingga rilis final.

Jadi, Anda berusaha menjadi tim yang tidak menjadi korban Bulan Mythical Man . Anda akan memiliki beberapa masalah, seseorang dalam tim harus melakukan wawancara teknis, maka Anda harus menunggu beberapa minggu setelah mereka menerima posisi sebelum mereka dapat mulai. Mungkin dua bulan sebelum pengembang baru berada di depan keyboard mereka.

Setiap karyawan baru memiliki produktivitas negatif dalam beberapa bulan pertama. Ini menjadi lebih buruk karena pengembang saat ini perlu membimbing mereka, lebih lanjut mengurangi produktivitas mereka.

Bagian lain dari MMM adalah bahwa seiring pertumbuhan tim, begitu pula masalah komunikasi. Rapat menjadi lebih besar, rantai email menjadi lebih panjang ...

Saya akan membawa mereka dalam kelompok yang lebih kecil dan tahu bahwa untuk waktu yang lama produktivitas tidak akan sebanding dengan peningkatan ukuran tim. Sadar juga bahwa pengaliran pada arus kas selama beberapa bulan pertama dapat menjadi signifikan, karena on boarding biaya, dan peralatan.

Dalam komentar Anda kepada Alex D Anda menyebutkan, "Ini bukan tenggat waktu yang kami kejar, kemampuannya yang dapat dibuktikan untuk menghadirkan fitur-fitur baru." Jadi beralihlah ke gaya pengembangan yang memerankan fitur dalam bongkahan yang lebih kecil, dan lebih sering. Mintalah anggota tim yang baru menguji fitur-fitur baru, yang akan membantu mereka memahami basis kode.

Anda akan lebih baik tidak mempekerjakan orang baru dan melihat proses Anda untuk melihat di mana Anda dapat membuat perubahan untuk membuat segalanya berjalan lebih cepat. Semakin cepat bug ditemukan, semakin sedikit waktu yang dibutuhkan untuk memperbaikinya, jadi bagaimana Anda menguji? Apakah Anda melakukan tinjauan kode? Apakah Anda memperhatikan kualitas persyaratan? Apakah Anda memiliki proses build dan deplotyment yang diautomasi? Apakah Anda memiliki tes otomatis? Apakah Anda mengadakan rapat harian (Luar biasa, seberapa cepat perkembangan bisa terjadi ketika seseorang meminta Anda untuk kemajuan Anda setiap hari!)? Apakah Anda menggunakan proses gesit? Apakah Anda memiliki beberapa kekurangan desain dasar yang harus diatasi untuk membuat sisa pengembangan berjalan lebih cepat (desain yang buruk dapat memperlambat proyek pengembangan dengan sangat buruk).

Silakan baca Mythical Man-month. Anda jelas perlu untuk dapat memberi tahu manajemen senior mengapa mereka membuat pilihan kerja untuk mempercepat proyek. .

Jadi, Anda ingin membuang mereka dari tebing dan melihat apakah mereka bisa terbang? Saya pikir ketika Anda menemukan hal-hal pada Anda sendiri, mereka cenderung tetap dengan Anda dalam jangka panjang sebagai lawan hanya memiliki solusi yang diberikan kepada Anda. Namun, itu mengasumsikan Anda benar-benar menemukan solusi yang lebih baik. Saya tidak mengerti mengapa Anda tidak bisa membiarkan tim ini memiliki pemimpin yang berkualifikasi yang akan menyeimbangkan membiarkan mereka melakukan kesalahan sendiri bersama dengan memberi mereka bimbingan dan instruksi dengan belajar dari contoh-contoh berkualitas.