Apakah merotasi pengembang pada suatu proyek adalah ide yang baik atau buruk?


38

Saya sedang mengerjakan tim kecil yang akan mulai mengerjakan proyek besar baru dengan tim kecil lainnya. Tim lain saat ini sedang mengerjakan sistem warisan yang telah mereka kerjakan selama bertahun-tahun.

Manajer telah memutuskan bahwa pengembang dari tim saya akan berotasi setiap beberapa bulan untuk menggantikan pengembang yang bekerja pada sistem lawas. Dengan cara itu tim lain akan memiliki kesempatan untuk mengerjakan proyek baru dan memiliki pemahaman yang lebih baik tentang sistem baru.

Saya ingin mengetahui manfaat dan kelemahan (jika ada) dari memutar pengembang dari proyek setiap 2-3 bulan.

Saya tahu bahwa ini adalah pertanyaan yang mirip dengan "Apakah memutar pengembang utama merupakan ide yang baik atau buruk?" , tetapi pertanyaan itu berfokus pada pengembang utama. Pertanyaan ini adalah tentang memutar seluruh tim dan mematikan proyek (pimpinan teknologi untuk proyek baru mungkin diputar atau tidak - saya belum tahu).



2
Saya tidak ingin menjadikan ini menjadi pertanyaan subyektif / argumentatif dengan memberikan pendapat pribadi saya dalam pertanyaan itu. Perasaan saya adalah bahwa ini bukan ide yang baik, tetapi mungkin ada sesuatu yang tidak saya ketahui :)
Christian P

1
Alasan apa yang diberikan manajer ketika Anda bertanya mengapa? Adalah kepentingan terbaik perusahaan untuk membagikan pengetahuan tentang suatu produk jika pengembang pergi.
dcaswell

1
Itu masalah. Jika manajemen Anda belum sepenuhnya transparan tentang hal ini maka mungkin itu pertanda bahwa mereka belum memikirkannya sama sekali.
Aaronaught

1
Apa yang saya sarankan adalah Anda membuat tim intital yang memulai proyek yang terdiri dari beberapa penyembah warisan terkini dan beberapa penyembah proyek baru saat ini. Menjaga mereka melalui pagar. Pada akhirnya para pengembang lagacy mendukung produk baru dan para devlopers baru bergabung dengan beberapa pengembang warisan lainnya untuk melakukan proyek berikutnya. Dengan cara itu tim sama melalui proyek (Atau rilis utama) tetapi orang-orang yang sudah tua dapat mempercepat apa yang akan mereka dukung nanti. Karyawan baru harus mulai bekerja di luar negeri kecuali mereka memiliki keterampilan khusus yang tidak Anda perlukan untuk proyek ini.
HLGEM

Jawaban:


76

Saya terkejut bahwa semua orang berpikir ini adalah hal yang baik. Para penulis Peopleware (yang, IMO, masih merupakan salah satu dari beberapa buku manajemen proyek perangkat lunak yang berharga yang layak dibaca) sangat tidak setuju. Hampir seluruh Bagian IV buku ini didedikasikan untuk masalah ini.

Perangkat lunak Tim adalah unit fungsional yang sangat penting. Tim perlu mengental agar menjadi benar-benar produktif. Butuh waktu ( banyak waktu) bagi anggota tim untuk saling menghargai, mempelajari kebiasaan dan kebiasaan masing-masing, kekuatan dan kelemahan masing-masing.

Tentu saja, dari pengalaman pribadi, saya dapat mengatakan bahwa setelah setahun bekerja dengan orang-orang tertentu, saya telah belajar untuk menertawakan hal-hal tertentu yang membuat saya marah, perkiraan saya sebagai pemimpin tim jauh lebih baik, dan tidak terlalu sulit untuk dapatkan pekerjaan didistribusikan untuk membuat semua orang bahagia. Awalnya tidak seperti itu.

Sekarang Anda mungkin berkata, "Oh, tapi kami tidak menghancurkan seluruh tim, hanya memindahkan beberapa orang." Tetapi pertimbangkan (a) betapa tidak produktifnya pengganti mereka pada awalnya, dan (b) berapa kali Anda akan menemukan diri Anda atau tim lain berkata, tanpa berpikir, "Saya benar-benar menyukai X" atau "Ini akan memiliki lebih mudah dengan Y masih ada " , secara halus dan tidak sadar menyinggung anggota baru dan menciptakan perpecahan dalam tim yang ada, bahkan menabur ketidakpuasan di antara anggota" lama ".

Orang-orang tidak melakukan ini dengan sengaja , tentu saja, tetapi itu terjadi hampir setiap waktu. Orang melakukannya tanpa berpikir. Dan jika mereka memaksakan diri untuk tidak melakukannya, mereka akhirnya lebih fokus pada masalah, dan frustrasi oleh keheningan yang dipaksakan. Tim dan bahkan sub-tim akan mengembangkan sinergi yang hilang ketika Anda bermain-main dengan struktur. Para penulis Peopleware menyebutnya sebagai "teamicide".

Yang sedang berkata, meskipun anggota tim rotasi adalah praktik yang mengerikan, tim rotasi sendiri baik-baik saja. Meskipun perusahaan perangkat lunak yang dikelola dengan baik harus memiliki konsep kepemilikan produk, itu tidak mengganggu bagi tim untuk memindahkan seluruh tim ke proyek yang berbeda, selama tim tersebut benar-benar menyelesaikan proyek lama atau setidaknya membawanya ke proyek. tingkat yang mereka senangi.

Dengan menjalankan tugas tim alih-alih tugas pengembang , Anda mendapatkan semua manfaat yang sama seperti yang Anda harapkan dengan pengembang bergilir (dokumentasi, "penyerbukan silang", dll.) Tanpa efek samping buruk pada setiap tim sebagai satu unit. Bagi mereka yang tidak benar-benar memahami manajemen, itu mungkin tampak kurang produktif, tetapi yakinlah bahwa produktivitas yang hilang dengan memecah-belah tim sama sekali mengerdilkan produktivitas yang hilang dengan memindahkan tim itu ke proyek yang berbeda.

NB Dalam catatan kaki Anda, Anda menyebutkan bahwa pimpinan teknologi mungkin satu - satunya orang yang tidak dirotasi. Ini dijamin cukup untuk mengacaukan kedua tim. Pimpinan teknologi adalah pemimpin, bukan manajer, ia harus mendapatkan rasa hormat dari tim, dan tidak hanya diberikan wewenang oleh tingkat manajemen yang lebih tinggi. Menempatkan seluruh tim di bawah arahan pemimpin baru yang belum pernah bekerja sama dengan mereka dan yang sangat mungkin memiliki gagasan berbeda tentang hal-hal seperti arsitektur, kegunaan, pengorganisasian kode, estimasi ... yah, itu akan sangat menegangkan untuk pemimpin yang mencoba membangun kredibilitas dan sangat tidak produktif bagi anggota tim yang mulai kehilangan kohesi tanpa adanya pemimpin lama mereka. Kadang-kadang perusahaan memilikiuntuk melakukan ini, yaitu jika pemimpin berhenti atau dipromosikan, tetapi melakukannya dengan pilihan terdengar gila.


2
Jangan sepenuhnya tidak setuju - namun ini bukan tanpa kekurangannya - Tim dapat dan memang membangun kerajaan, kadang-kadang Produktivitas yang hancur ini tidak selalu menjadi tujuan paling penting dari palungan, yang (jika ada gunanya), lebih melihat ke arah permainan akhir daripada lainnya mungkin.
mattnz

4
@ mattnz: Apa "permainan akhir" yang ada untuk seorang manajer selain produktivitas tinggi, retensi karyawan, dan mampu mengirim tepat waktu / sesuai anggaran? Saya berbicara tentang manajer etis di sini, tentu saja, yang benar-benar ingin melakukan yang terbaik untuk perusahaan dan tidak menggunakan tim atau proyek sebagai kendaraan untuk memajukan tujuan karier pribadi mereka sendiri. Sebuah organisasi perangkat lunak menginginkan kerajaan - kerajaan stabil dan menghasilkan uang - dan ya, kerajaan bisa jatuh, tetapi mereka lebih kecil kemungkinannya jatuh daripada rumah kartu.
Aaronaught

2
rotasi lebih baik daripada orang-orang yang meninggalkan perusahaan sepenuhnya
warren 9'13

4
@warren: Jika kedua opsi itu adalah satu-satunya pilihan Anda, maka yang terakhir hampir tidak bisa dihindari.
Aaronaught

3
Saya benar-benar tidak mengerti jawaban ini sama sekali. Semua orang di tim harus profesional dan bekerja dengan baik dengan orang lain dengan anggapan semua anggota tim benar-benar kompeten yang merupakan masalah yang berbeda. Anggota tim yang berotasi sering kali merupakan satu-satunya pilihan bagi seorang manajer yang secara kronis kekurangan tenaga dalam kedua produk atau ketika gesekan menjadi ancaman serius. Seringkali sangat sulit untuk menemukan bakat yang baik. Anggota tim yang berotasi adalah cara untuk melindungi nilai dari para pengembang yang pergi. Juga lebih adil bagi para pengembang yang mengerjakan perangkat lunak warisan ketika mereka ingin mempelajari sesuatu yang baru.
maple_shaft

18

Saya sendiri tidak melihat banyak kerugian di sini. Rotasi memberi Anda:

  • Penyerbukan silang dari pengetahuan institusional - semua orang akan mengetahui proyek warisan dan yang baru, setidaknya secara teori.
  • Pelatihan lintas - proyek yang berbeda sering membutuhkan hal yang berbeda. Anda tumbuh lebih sebagai pengembang yang bekerja di proyek-proyek lawas yang jelek daripada di proyek-proyek greenfield yang bagus dan bersih.
  • Proyek-proyek yang secara fundamental lebih baik - tidak seperti memiliki tim baru yang datang untuk membuat Anda menyelesaikan dokumentasi dan membersihkan proses-proses buruk yang ingin Anda jalani tetapi tidak diakui secara publik.
  • Kode lebih baik - lebih banyak kepala lebih baik dalam banyak kasus.
  • Kemungkinan perbaikan moral - variasi adalah bumbu kehidupan. Dan yang ingin terjebak dalam mode memperbaiki bug / duct taping proyek lama secara permanen. Juga ingat bahwa proyek "baru" Anda akan menjadi warisan di beberapa titik, apakah Anda ingin terjebak di sana selamanya?

Mungkin satu-satunya downside adalah penurunan produktivitas yang Anda dapatkan dari berpindah tempat tetapi itu hanya akan merugikan buruk pada putaran pertama. Setelah itu kedua belah pihak akan memiliki waktu duduk di kedua tempat dan bagian-bagian buruk handoff mungkin akan lebih dipahami dan mungkin diselesaikan.


18
Saya tidak melihat bagaimana moral saya akan ditingkatkan jika saya "diturunkan jabatan" untuk bekerja pada sistem warisan.
Telastyn

3
Beberapa kelemahan dalam waktu pengembangan awal naik dan tugas spesifik lainnya dari tim warisan mendapatkan prioritas yang lebih rendah.
Oded

16
@ Telastyn Jika perusahaan lama saya sudah keluar dari pekerjaan lama saya masih akan bekerja di sana. Tentu itu menyebalkan untuk diputar, tetapi bahkan lebih menyebalkan untuk mengetahui bahwa Anda tidak akan pernah diputar hanya karena mereka membutuhkan pengembang lama.
BeardedO

8
@ Telastyn dan Christian dan lainnya: Ini masalah Anda jika Anda melihatnya sebagai penurunan pangkat. Mengerjakan sistem warisan merupakan tantangan tersendiri yang dapat memberi Anda pengalaman yang sangat berharga untuk digunakan demi keuntungan Anda dalam pengembangan bidang hijau. Pengembangan Greenfield benar-benar harus memiliki "kredibilitas" yang jauh lebih sedikit daripada yang dimilikinya karena jauh lebih mudah daripada mencoba membuat fitur baru pada basis yang sudah ada bahkan yang tanpa banyak hutang teknis. Pengembangan bidang Brown adalah tempat Anda menemukan pengrajin dan wanita sejati. Ya, Anda menemukan mereka di tempat lain juga, tetapi tidak yang medan perang mengeras.
Marjan Venema

8
@MarjanVenema - Maaf, melakukan beberapa pekerjaan pemeliharaan di Cobol tidak akan memajukan karir saya. Tentu, pekerjaan itu mungkin perlu dilakukan dan itu bahkan mungkin pengalaman yang berharga - tetapi jika manajer saya memindahkan saya ke waktu penuh itu, saya akan meminta resume saya keluar secepatnya. Faktanya adalah bahwa beberapa pengembang akan menganggap ini sebagai penurunan pangkat, terlepas dari apa itu sebenarnya. Menyeimbangkan persepsi ini dengan keinginan untuk melakukan penyerbukan silang bukan masalah saya, itu masalah manajer; itu pekerjaan mereka .
Telastyn

6

Menariknya, dalam pengalaman saya, kami sering memulai proyek kami dengan niat ini. Kami sering gagal menindaklanjuti maksud ini karena kendala pada proyek yang lebih baru dan keyakinan bahwa pelatihan silang terlalu mahal.

Saya selalu berharap kami berhasil, meskipun dalam jangka panjang saya percaya ini bermanfaat bagi semua pihak - tim, perusahaan, klien & perangkat lunak. 2/3 bulan kedengarannya cukup lama bahwa ada risiko terbatas dari dampak negatif serius, tidak ada konteks yang terjadi untuk pengembang yang terlibat kecuali pada titik pergantian di mana mereka dapat mendedikasikan diri mereka pada proyek alternatif.

Beberapa kemungkinan manfaat yang tidak disebutkan:

  • Manajemen proyek yang lebih baik. Jika manajer proyek untuk kedua proyek berada di atas maka itu adalah kepentingan terbaik mereka untuk bekerja keras sehingga periode transisi tidak menyakitkan untuk kedua proyek. Ini giliran (tergantung pada pengaturan Anda) dapat menghasilkan kolaborasi yang lebih erat antara PM dan tim pengembangan.
  • Dokumentasi yang lebih baik (proaktif). Jika Anda tahu Anda masuk dan keluar dari suatu proyek, itu bukan hanya demi kepentingan terbaik proyek, kepentingan terbaik perusahaan, praktik terbaik secara umum, tetapi sekarang di masing-masing pengembang memiliki kepentingan terbaik untuk membuat hidup mudah saat mereka terpental sekitar.
  • Masalah moral adalah masalah besar, jika pengembang Anda belum cukup terjebak pada proyek warisan, maka mereka mungkin bukan pengembang yang Anda inginkan! Jika mereka memilikinya, beralih mereka dan membuat pengembang lain untuk bekerja di dalamnya akan membuat mereka merasa cinta untuk perusahaan Anda - mereka mungkin merapikan bit kode yang mereka pikir tidak akan ada yang melihat juga. Sistem warisan sering dianggap sebagai proyek kelas dua yang seringkali merugikan mereka, mungkin dengan cara ini Anda membantu mengubah persepsi itu.

Saya pikir inilah akhirnya di sebagian besar perusahaan. Tujuan yang tinggi, tetapi tuntutan perubahan haluan yang cepat dan penghindaran biaya segera yang minimal biasanya menghalangi pelatihan silang dan pengembangan silang karena produktivitas yang hilang sehingga membawa seseorang yang baru untuk mempercepat proyek.
BBlake

2
@BBlake Ya, sayangnya itulah masalahnya. Sangat disayangkan, karena sangat picik dan berisiko cukup tinggi bagi perusahaan untuk "membatasi" pengetahuan tentang sistem-sistem penting untuk jumlah orang yang lebih sedikit.
Marjan Venema

1
Sayangnya, sebagian besar bisnis, termasuk bank utama dunia yang baru-baru ini saya tinggalkan untuk bekerja di tempat lain, lebih tertarik pada garis bawah untuk proyek ini atau minggu atau siklus anggaran, daripada merencanakan masa depan untuk biaya yang akan terjadi ketika pengembang senior ( seperti saya) pergi. Tanpa anggaran untuk pelatihan silang pada aplikasi hanya saya sudah terbiasa dengan. Tambahkan lusinan jam kerja yang terbuang untuk melacak masalah produksi yang bisa saya selesaikan dalam beberapa jam karena saya tahu sistemnya. Berpandangan pendek, tapi itulah cara perusahaan.
BBlake

@Marjan: Saya berani bertaruh bahwa biaya yang dikeluarkan karena harus melakukan pelatihan silang secara teratur akan jauh, jauh lebih tinggi daripada biaya melatih karyawan baru yang diperlukan jika seseorang pergi. Sekarang, jika seluruh tim pergi, maka itu masalah yang berbeda.
Dunk

1
@Dunk: Saya tidak tahu itu akan terjadi. Pelatihan lintas tidak harus sejauh membuat salib melatih seorang ahli di bidang yang tidak secara langsung miliknya. Hanya perlu melangkah sejauh untuk memastikan bahwa bisnis tidak akan segera berada dalam acar dan berisiko kehilangan klien ketika para ahli lapangan pergi menyebabkan pengembangan di bidang itu terhenti. Tidak ada yang tak tergantikan, tetapi bisnis benar-benar menghadapi risiko ketika pengetahuan atau keterampilan penting hanya terbatas pada sedikit orang. Dan biaya dari risiko yang menjadi kenyataan itu memang bisa sangat, sangat tinggi.
Marjan Venema

4

Rotasi adalah hal yang baik untuk perusahaan, dan bisa menjadi hal yang baik untuk pengembang juga.

Ada banyak alasan bagus dan Wyatt telah menyebutkan banyak dari mereka dalam jawabannya.

Yang sedang berkata, dalam situasi Anda, Anda mungkin menemukan ketika memperkenalkan ini, pengembang yang pindah dari proyek yang lebih baru ke proyek warisan mungkin tidak senang, jadi perlu ada komunikasi yang sangat jelas mengapa ini terjadi dan berapa lama untuk, dan rencana ke depan.

Mungkin baik untuk berpikir tentang tidak menukar tim grosir untuk memulai dan memutar 1 atau 2 dev untuk memulai dengan, meskipun ini mungkin tampak seperti memilih orang untuk penurunan pangkat (yang beberapa orang mungkin melihatnya).


Saya suka gagasan bertukar hanya 1-2 devs untuk memulai. Itu akan membantu mengurangi dampak negatif awal pada produktivitas.
superM

Anda berurusan dengan pengembang perangkat lunak, bukan orang normal. Pengembang perangkat lunak cenderung logis. Mereka tidak dapat dengan mudah dimanipulasi seperti masyarakat umum dengan memasukkan ide-ide seperti di atas. Trik lain lebih efektif untuk mereka, (mis. Monitor yang lebih besar, komputer yang lebih cepat) tetapi bukan pelanggaran politik seperti yang coba dilakukan oleh ide ini. Ini akan menjadi negatif bagi mereka yang berada di tim pengembangan baru, tidak peduli apa. Janji imbalan (mis. Lihat di atas) adalah satu-satunya cara untuk menutupi rasa tidak enak. Tentu saja, itu akan bagus (pada awalnya) untuk para penjaga, sampai mereka menyadari bahwa mereka tidak cocok untuk itu.
Dunk

2

Setuju dengan Aaronaught yang sangat aneh untuk melihat berapa banyak orang yang tidak melihat kelemahannya. Beberapa orang berpikir buruk, bahwa Anda dapat menunjuk dengan sangat cepat - kode tidak memiliki pemilik dan ketika semua orang bertanggung jawab atas semuanya tidak baik untuk kualitas . Pengembang bukan sumber daya (bahkan mereka disebut seperti itu sangat sering oleh manajer), mereka adalah orang-orang dan untuk tim sangat penting untuk saling mengenal, rotasi membuat sedikit kekacauan di sana. Jika Anda bekerja untuk beberapa proyek untuk waktu yang lebih lama, Anda akan menjadi seorang ahli (tidak hanya dalam domain, tetapi dalam proyek itu), Anda akan tahu dari mana sebagian besar masalah berasal, siapa yang akan memberi Anda jawaban terbaik atau mungkin beberapa pengetahuan domain yang lebih spesifik, dll. Jika Anda baru, Anda perlu mempelajari semua pemikiran ini, sehingga akan memperlambat kemajuan. Tapi tentu saja juga baik untuk mengetahui praktik lain di organisasi Anda, bagaimana tim lain membangun dan mengatur. Sangat baik jika proyek Anda terkait dalam beberapa cara, misalnya satu proyek adalah input untuk yang lain (tidak perlu secara langsung), sehingga akan mendapatkan pemahaman yang lebih baik tentang gambaran besar. Dan tentu saja menyebarkan keahlian itu baik (jika Anda akan mendapatkan waktu untuk mendapatkan pengetahuan ini).


posting ini agak sulit dibaca (dinding teks). Maukah Anda mengeditnya menjadi bentuk yang lebih baik?
nyamuk

2

Saya setuju dengan jawaban teratas Aaronaught dan saya punya beberapa tambahan.

  • Orang tidak suka didorong.
  • Dalam lingkungan bisnis hierarkis, orang mungkin diberi tanggung jawab yang kemudian diambil dari mereka lagi. Ini mungkin hanya bagian dari pekerjaan. Namun, semakin sering hal ini terjadi, semakin kecil kemungkinan orang-orang ini merasa bertanggung jawab atas apa pun yang ditugaskan kepada mereka.
  • Poin sebelumnya juga berlaku untuk pekerjaan pemeliharaan pada hal-hal yang tidak dibuat oleh orang itu sendiri. Membersihkan kekacauan orang lain (atau lebih dirumuskan secara netral: pekerjaan yang belum selesai) tidak secara khusus memotivasi sebagian besar individu yang menciptakan.
  • Filosofi "seorang programmer adalah seorang programmer adalah seorang programmer, mereka adalah plug-in anonim untuk dimasukkan ke dalam proyek-proyek yang diperlukan" tidak membuat programmer merasa dihargai atau lebih peduli dengan tugas-tugas yang diberikan kepadanya.

Waktu yang tepat untuk menetapkan ulang siapa pun adalah ketika mereka mulai bosan dengan apa yang mereka lakukan. Tidak ada lagi yang bisa didapat, semuanya terkendali, pekerjaan selesai. Dalam kasus-kasus ini mereka biasanya akan maju dan meminta peluang lain sendiri.

Tentu saja kenyataan itu keras kepala dan seringkali tidak ada pilihan, seseorang mungkin dibutuhkan di tempat lain karena alasan apa pun. Ini tidak selalu buruk, itu juga bisa membuat seseorang merasa penting dan jika orang itu menyelesaikan beberapa masalah besar, akan ada kredit untuknya.

Hanya dengan menyeret orang di sekitar untuk menyebarkan pengetahuan kemungkinan akan meningkatkan pergantian. Dengan begitu pengetahuan akan tersebar, tetapi akan tersebar di luar perusahaan yang mungkin bukan maksudnya.


0

TL; DR Jadikan satu tim dan kemudian satu tim yang mendukung 2 proyek.

Untuk menggemakan @Aaronaught, saya pikir tim pencampuran bisa bermasalah karena mungkin perlu waktu untuk menyesuaikan diri dengan praktik, proses, dll. Jika Anda memutar terlalu banyak orang dengan cepat tim akan kehilangan identitasnya. Ini mengarah pada lebih banyak pertanyaan, kebingungan, dan waktu yang dihabiskan untuk menebus identitas itu.

Di sisi lain jika ada upaya bersama untuk bergabung dengan 2 tim menjadi satu tim dan memiliki 1 tim mendukung 2 proyek, saya pikir itu bekerja dengan baik selama tim tidak terlalu besar. Saya telah menjadi bagian dari banyak tim yang mendukung banyak proyek. Semakin dekat dalam teknologi 2 proyek, semakin mudah transisi. Dalam pengalaman saya, biaya yang lebih tinggi dalam transisi dari satu proyek ke proyek lain datang ketika melintasi bahasa, klien / server (khususnya GUI), industri (medis, web, game), atau jalur serupa lainnya. Caranya adalah membuat orang yang berbeda untuk mengerjakan proyek cukup sering untuk mendapatkan manfaat, tetapi tidak begitu sering sehingga biaya transisi melebihi manfaatnya.

Maka manfaat untuk mendapatkan lebih banyak orang dalam suatu proyek cukup terkenal, begitu pula biayanya.


1
"Selama tim tidak terlalu besar" adalah kuncinya di sini, saya pikir; jika setiap tim memiliki 10 orang di dalamnya, tim yang terdiri dari 20 orang kemungkinan besar terlalu besar. Juga, jika ada pemisahan fisik antara tim (OP tidak menentukan) maka itu tidak akan berfungsi sebagai tim tunggal dan akan membuat hal-hal lebih terorganisir. Ini pasti bisa bekerja, tetapi itu tergantung pada situasinya (dapatkah tim digabung secara efektif) dan juga tujuan manajemen (penggabungan lebih atau kurang permanen, itu akan menambah lebih banyak sumber daya tetapi tidak akan mencapai tujuan yang sama seperti sebuah proyek rotasi).
Aaronaught

0

Rotasi Programmer adalah hal yang baik dari sudut pandang perusahaan dan sudut pandang pengembang.

Dari perspektif perusahaan

  1. Manajemen akan mengetahui, kekuatan dan kelemahan pengembang tertentu apakah mereka dapat menangani multitasking atau tidak dan adaptif terhadap perubahan.
  2. Jika beberapa pengembang meninggalkan perusahaan karena suatu alasan, perusahaan sudah memiliki cadangan yang siap untuk masa depan.
  3. Ini akan meningkatkan kinerja proyek, karena banyak orang akan mengerjakannya, hal yang sama diuji oleh semakin banyak pengembang. (Pengujian pemborosan sumber daya diminimalkan)
  4. Semua anggota tim bekerja dalam tim dan itu akan meningkatkan kinerja proyek dan di masa depan manajemen akan mengetahui, tim seperti apa yang harus dibuat saat menerapkan modul atau tugas yang sulit.

Dari perspektif pengembang

  1. Itu akan membuat pengembang lebih positif karena kepercayaan dirinya meningkat.
  2. Pengembang mendapatkan ide yang lebih baik dan lebih baik dari kode rekan tim lain dan mereka dapat menggunakan teknik tersebut dalam pengembangan di masa depan.
  3. Dari ide dan saran yang lebih baik dari anggota tim lain, produktivitas pengembang meningkat.

Hanya satu hal utama, perlu diingat bahwa,

Rotasi Programmer tidak boleh terjadi terlalu sering. setelah 60% - 70% pengembangan dilakukan maka hanya pergeseran yang akan bermanfaat.


3
Saya melihat banyak pernyataan botak dibuat di sini. Beberapa dari mereka hampir tidak ada hubungannya dengan rotasi ("manajemen akan mengetahui kekuatan dan kelemahan pengembang tertentu"?), Yang lain entah canggung atau tidak masuk akal ("semua anggota tim bekerja dalam tim dan itu akan meningkatkan kinerja proyek "?). Apa semua poin ini berdasarkan? Apakah anda memiliki sumber? Apakah ini pengalaman pribadi? Jika demikian, pengalaman apa ? Apakah "perspektif perusahaan" Anda berasal dari pengalaman sebagai manajer atau pemimpin tim? Apakah Anda benar-benar melihat hal-hal ini bekerja dalam praktik?
Aaronaught

1
Sebagian besar manfaat yang diusulkan ini tampaknya benar-benar terkait dengan sekadar berada di tim sebagai lawan dirotasi di antara tim ...
Aaronaught

yang pertama "Manajemen akan mengetahui, kekuatan dan kelemahan pengembang tertentu." sebenarnya berlawanan, karena jauh lebih mudah untuk menyembunyikan kelemahan Anda ketika Anda pindah dari satu tempat ke tempat lain, selalu ada lebih banyak orang / perangkat lunak untuk disalahkan, mengapa terlambat, kereta, tidak dilakukan.
Dainius

Tidak mungkin di ... bahwa kinerja proyek tidak akan berdampak negatif. Mengapa Anda percaya bahwa kinerja proyek akan "ditingkatkan"?
Dunk
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.