Pemrograman dengan sekelompok orang yang belum pernah saya temui


50

Saya telah ditugaskan proyek kelompok dari kelas ilmu komputer AP saya, dan saya diminta untuk bekerja dengan tiga orang lainnya. Saya belum pernah berbicara dengan mereka sebelumnya, saya tidak tahu tingkat keahlian mereka, dan yang saya miliki hanyalah alamat email mereka. Tugasnya, diringkas, adalah ini:

"Sebagai tim, kamu akan menyelesaikan minimal tiga Modul ke Kelas ...."

Saya akan mencoba dan menjadi "Kapten tim" karena tidak ada dari mereka yang mencoba menghubungi satu sama lain tetapi saya ingin tahu: bagaimana caranya? Saya sudah mengirim email kepada mereka dan bertanya apakah ada metode komunikasi yang mereka sukai daripada saling mengirim email, tetapi begitu kita benar-benar memulai proyek, saya harus mencari tahu siapa yang melakukan apa.

Apa yang harus saya lakukan? Bagaimana saya "mengambil alih" dan memimpin tiga orang yang belum pernah saya temui?

Berikut adalah kutipan dari tugas yang sebenarnya:

Karena itu, Anda perlu mendiskusikan berbagai peran yang akan diambil setiap anggota tim dalam proyek ini di awal minggu. Anda dapat berkomunikasi melalui Pronto (atau Blackboard IM), email, wiki, grup google, blog atau metode lain yang Anda suka. Jika seorang anggota kelompok tidak terlibat dengan kelompok pada akhir minggu, beri tahu instruktur Anda dan mereka akan memberikan panduan tambahan.
...
Juga karena pada akhir proyek akan menjadi evaluasi tim di mana Anda akan menilai kontribusi setiap anggota tim untuk penyelesaian proyek ini bersama dengan nilai yang disarankan.

Sunting: Banyak orang menyarankan agar saya bertemu mereka di kedai kopi, atau semacamnya. Satu-satunya masalah adalah, kita semua berada di negara yang berbeda. Saya juga menemukan salah satu dari mereka tidak diperbolehkan menggunakan Facebook / Skype / twitter, jadi saya harus mengirim pesan kepada mereka melalui yahoo messenger dan email.


10
Bagaimana dengan "berbicara dengan orang-orang ini", "mengenal mereka", "mendengarkan apa yang mereka inginkan dari proyek itu" dan "berpikir dengan pikiran Anda" alih-alih bertanya pada SE tentang arah ... itu tidak bisa memberi Anda? Tidak ada seorang pun di sini yang mengenal mereka. Maksudku, jika mereka memiliki beberapa disfungsi perilaku dan jika mereka di mana dalam posisi berkuasa, menanyakan arah bisa masuk akal ... tapi itu hanya orang-orang sepertimu. Anda berada di kotak pasir: waktu untuk mencari tahu.
ZJR

6
@ zjr Siapa yang membakar angsa Anda? Tentu saja saya bekerja dengan mereka dan mencoba mencari tahu. Tetapi saya ingin mendapatkan saran dari orang-orang yang telah menangani tugas ini sebelumnya daripada hanya melakukan proyek ini secara membabi buta. Juga orang menyebutkan beberapa aplikasi manajemen proyek yang hebat dan saya belajar beberapa hal baru.
Gabriel

2
@ ZJR Saya tidak yakin itu adalah inti dari pertanyaannya. Sementara dia mengatakan bahwa dia belum benar-benar berkomunikasi dengan mereka sebelumnya, pertanyaannya adalah sehubungan dengan ini menjadi proyek pemrograman dan bagaimana dia harus mendekatinya dengan tim yang telah dia tangani untuk berurusan dengannya.
Jarrod Nettles

Jawaban:


90

Pemimpin proyek ini adalah orang yang maju dan bertanggung jawab di awal.

Ini berlaku untuk sebagian besar hal dalam hidup - bukan hanya pengembangan perangkat lunak. Ketika semua orang berlarian seperti ayam tanpa kepala, orang yang memikirkan semuanya, melangkah maju dan berkata, " Inilah yang akan kita lakukan dan bagaimana kita akan melakukannya ." biasanya orang tersebut dipandang sebagai pemimpin untuk sisa proyek. Ingatlah bahwa dengan melakukan ini, Anda bertanggung jawab atas keberhasilan atau kegagalan utama proyek.

Anda ingin memimpin proyek ini? Berikut adalah beberapa hal yang dapat Anda lakukan segera untuk membuat dampak besar.

  1. Gunakan alat manajemen proyek seperti Trello dan kirim undangan ke semua orang dan mulailah menugaskan sebagian proyek kepada orang-orang.
  2. Hasilkan database bug dan mulai menambahkan tugas dan bug - lagi, mulailah menetapkan.
  3. Siapkan repositori kontrol versi dan periksa sepotong kode awal yang baik yang dapat digunakan semua orang. Menolak berurusan dengan segala bentuk kontrol kode lainnya.
  4. Tawarkan untuk membantu orang-orang memulai pengembangan dengan menunjukkan kepada mereka cara menggunakan sistem kontrol versi dan basis data bug.
  5. Kirimkan email mingguan yang merinci status proyek dan kemajuan minggu sebelumnya.

Tidak satu pun dari langkah-langkah ini yang sangat sulit, atau memakan waktu, tetapi mereka akan menghemat waktu . Selanjutnya, itu akan membuat tim Anda berbicara satu sama lain, dan membuat mereka terbiasa melihat Anda yang bertanggung jawab.


17
Jika dua anggota tim mencoba pendekatan ini, berhati-hatilah. Perjuangan untuk mengendalikan dan memimpin bisa menjadi bencana - jauh lebih buruk daripada sekelompok rekan tim yang tidak melakukan apa-apa.
Corbin

3
@CorbinMarch Setuju. Ini hanya bekerja jika ada kurangnya kepemimpinan dalam tim - semua orang menunggu orang lain untuk menyelesaikan sesuatu. Jika ada orang lain yang muncul sebagai pemimpin, hal terbaik yang dapat Anda lakukan untuk proyek Anda adalah mendukung orang itu dan mendukung mereka.
Jarrod Nettles

4
Setelah membaca ini, saya memeriksa Trello dan saya langsung tergoda oleh kesederhanaannya. +1 untuk tautan. Jika ada cara untuk menginstal hal ini secara lokal, itu akan menjadi hal yang paling sempurna ...
Radu Murzea

2
The leader of this project will be the person who steps up and takes charge at the beginning.Semua sambut Blog Tuanku :)
yannis

5
Bagaimana kalau hanya bertemu dengan mereka di kedai kopi? Bagaimana Anda akan memberikan tugas kepada mereka, jika Anda tidak tahu keterampilan apa yang mereka miliki? Secara pribadi, saya tidak suka mendapat email "Ini Trello, ini pelacak bug dan inilah tugas Anda" tanpa bertemu siapa pun sebelumnya.
Simon

24

Jawaban Jarrod Nettles meringkas banyak hal tentang apa yang akan saya sarankan, jadi saya akan memasukkan beberapa yang berhasil dalam pengalaman saya baru-baru ini dalam situasi yang sama.

Saya menyarankan mencari cara untuk berbicara dengan mereka secara vokal, bukan melalui email. Jika Anda tidak berada di area yang sama, dapatkan semuanya di Skype. Jika Anda berada di area tersebut, temui mereka di kedai kopi atau sesuatu. Berbicara langsung dalam pertemuan awal akan membuat Anda benar-benar membuat keputusan dan menyelesaikan pekerjaan saat itu juga; utas email memungkinkan mereka yang pemalu atau sering tidak di komputer mereka untuk menahan proses - kita semua tahu betapa malasnya siswa!

Dalam pertemuan pertama Anda, saya akan mencoba untuk mengenal grup Anda lebih dari mencoba untuk melanjutkan proyek - tetapi jangan abaikan proyek! 10 atau 20 menit menghabiskan ice breaking mungkin cukup di antara 4 orang.

Ketika berbicara tentang proyek, saya sarankan menjalankan apa yang menurut Anda melibatkan proyek. Saya pikir ini penting untuk Anda jelaskan ini adalah pemahaman Anda, dan bukan kasus Anda yang memberi tahu mereka apa yang harus dilakukan. Semua orang harus dapat melemparkan pemikiran dan ide-ide mereka ke ring jika mereka punya, dan Anda harus pergi dari pertemuan awal itu dengan pemahaman yang cukup layak tentang apa yang Anda, sebagai kelompok, rasakan dari proyek tersebut.

Dalam pertemuan (reguler) yang akan datang, Anda dapat mulai melihat berbagai bagian proyek secara lebih rinci; lihat apa yang perlu dilakukan dengan tepat, sumber daya apa dan berapa banyak waktu yang dibutuhkan dan siapa yang bisa melakukan apa. Bagi potongan lebih lanjut jika perlu. Mungkin mencoba menetapkan tenggat waktu yang lunak?


4
+1 untuk menyebutkan kontak suara. Secara pribadi adalah yang terbaik, videochat berikutnya yang terbaik, panggilan konferensi masih lebih baik dari sekadar surat.
Barend

@andybursh Sayangnya, satu siswa bahkan tidak diperbolehkan menggunakan facebook. Jadi Skype keluar dari pertanyaan ... semoga kita dapat memecahkan masalah melalui teks.
Gabriel

10

Apakah ada di antara Anda yang memiliki pengalaman bekerja dengan sekelompok orang yang belum pernah Anda temui online, dan Anda tidak bisa bertemu langsung dengan mereka tetapi harus menyelesaikan proyek bersama?

Tambahkan tenggat underbudgeting, konyol dan dijual di sungai dengan pemasaran dan ini terdengar seperti sekitar 65% dari proyek pengembangan perangkat lunak di dunia nyata.

Anda mungkin lebih baik dilayani dengan membuat orang-orang menjadi sukarelawan untuk bagian-bagian yang akan mereka sukai daripada mengambil alih secara sepihak dan menugaskan tugas. Mereka semua mungkin duduk di sana memikirkan bagaimana mereka harus bertanggung jawab. Atau bagaimana mereka bisa mendapatkan tanah miskin yang terlalu peduli untuk melakukan semua pekerjaan kelompok sehingga mereka bisa naik kelas.


2
Anda lupa fakta bahwa banyak dari kita harus bekerja dengan tim lepas pantai yang belum pernah kita temui sebelumnya juga.
maple_shaft

7

Hal pertama yang harus dilakukan dalam kasus seperti ini adalah membuat pelacak masalah dan mempelajari cara menggunakannya.

Untuk pengantar yang lebih mendasar tentang cara menangani pengembangan seperti yang Anda jelaskan, referensi favorit saya berlaku untuk artikel Martin Fowler Menggunakan Proses Perangkat Lunak yang Agile dengan Pengembangan Lepas Pantai . Artikel ini menguraikan dasar-dasar dan konsep-konsep lanjutan tentang pengaturan komunikasi tim terdistribusi:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

Untuk proyek Anda, Anda yakin tidak akan dapat mengikuti semua tips dan trik yang disebutkan di sana (mis. Kemungkinan tidak ada Duta Besar atau Kunjungan Kontak untuk Anda :) tetapi tetap perlu dipelajari.

  • Untuk banyak tim yang memiliki semua hal di atas tentu saja merupakan pembunuhan yang berlebihan. Namun, saya merasa sangat membantu untuk memiliki daftar periksa yang komprehensif seperti itu - sehingga bahkan barang yang dilompati diperiksa dan telah mendokumentasikan dengan jelas alasan penolakan - hanya untuk memastikan tidak ada hal penting yang terlewatkan.

6
Saya setuju dengan poin-poin itu tetapi timnya hanya datang bersama untuk waktu yang sangat singkat, dan sebagian besar dari saran ini akan menjadi kerja keras yang serius untuk apa yang dia butuhkan. Sangat dapat diterapkan, untuk tim yang lebih maju.
Jarrod Nettles

@JarrodNettles itu poin yang bagus terima kasih - Saya memperbarui jawabannya
nyamuk

3
... ya, mari kita cepatkan mereka ke neraka birokrasi alih-alih membiarkan mereka menghasilkan kode nyata apa pun. silahkan.
ZJR

1
@ZJR Seperti yang saya katakan, daftarnya sedikit luas untuk proyek semacam ini, tetapi tim dan organisasi kode yang tepat akan membiarkan mereka menghasilkan kode kerja alih-alih hanya kode di layar mereka.
Jarrod Nettles

@ ZJR baik untuk hal-hal yang tercantum oleh Fowler Saya lebih suka mengikuti standar "birokrasi". Gagasan untuk menemukan cara kreatif saya sendiri untuk melacak bug, mengintegrasikan perubahan kode, dan berbagi pengetahuan tim, entah bagaimana, tidak menyalakan api saya
gnat

5

Anda belum memberi tahu kami berapa banyak waktu yang Anda miliki untuk ini, atau bahasa tempat Anda bekerja (saya akan mengatakan satu kelas sangat kecil, tapi mungkin dalam bahasa Anda jauh lebih baik).

Pertama-tama, miliki produk yang berfungsi dengan biaya berapa pun.

Jika proyek berlangsung selama dua minggu atau kurang, anggaplah Anda akan menjadi satu-satunya yang melakukan sesuatu dan sangat senang dengan bantuan yang Anda dapatkan. Cobalah untuk menjadwalkan hal-hal untuk semua orang, tetapi pastikan bahwa jika tidak ada yang melakukan sesuatu, Anda masih akan memiliki produk yang berfungsi. Bahkan jika seseorang melakukan sesuatu, jangan bergantung pada mereka untuk melanjutkan: bersiaplah bagi siapa saja untuk keluar kapan saja.

Jika Anda memiliki lebih dari satu minggu, pertimbangkan untuk menjadwalkan satu hari dalam seminggu ketika produk tersebut harus ditandai sebagai tonggak sejarah dan berpegang teguh pada itu sebanyak mungkin. Pastikan Anda memiliki sesuatu yang dapat ditendang dan periksa kekurangan: jika yang terburuk menjadi yang terburuk, ini akan menjadi apa yang Anda serahkan. Masing-masing yang Anda buat, Anda akan melihat seberapa banyak Anda dapat meningkatkan hal-hal, yang akan memotivasi Anda untuk pergi di. Jangan merencanakan terlalu jauh ke depan: tentu saja, Anda harus memiliki gagasan tentang apa yang akan Anda dapatkan, tetapi simpan rencana jangka pendek Anda yang paling spesifik.

Perhatikan bahwa keduanya tumpang tindih sedikit: ini disengaja, karena menurut saya dua minggu sedikit area abu-abu di mana dua iterasi dilakukan sulit, tetapi hanya bekerja dalam satu iterasi yang berisiko.

Saya mengasumsikan kasus terburuk, di mana Anda akan bekerja dengan orang-orang yang sangat baru dalam pemrograman. Saran umum saya adalah:

  • Simpan daftar fitur yang ingin Anda terapkan segera, dan siapa yang akan mengerjakannya. Jarrod menyarankan Trello, dan aku sepenuhnya mendukung itu: jika teman satu timmu tidak terlalu berpengalaman, itu akan banyak membantu. Anda dapat mencoba menyimpan bug di sana juga.
  • Dalam tim empat, Anda perlu kontrol versi. Mungkin membuat orang lain lebih enggan untuk berkontribusi jika mereka tidak tahu bagaimana cara melakukannya, tetapi itu sepadan.
  • Setiap dependensi eksternal dapat menakuti pemula. Jika Anda menulis unit test, beri tahu orang-orang bahwa mereka tidak perlu khawatir untuk memecahkannya. Beri tahu orang-orang bahwa mereka tidak perlu khawatir melanggar bangunan, terutama pada awalnya. Jauh lebih sulit untuk mengoreksi orang yang tidak melakukan kode apa pun daripada mereka yang melakukan kode kereta.
  • Periksa apakah hal-hal yang disarankan di sini benar-benar berlaku untuk Anda. "Integrasi berkelanjutan" adalah istilah umum - untuk program kecil, yang mungkin berarti "program ini berjalan dan semua fitur dapat digunakan". Apakah Anda punya situs? Apakah membagi menjadi beberapa tim membantu Anda?
  • YAGNI, seratus kali lipat. Jika Anda benar-benar harus, tuliskan terlebih dahulu untuk fitur yang akan Anda buat sendiri. Buat itu berfungsi, kemudian refactor, atau Anda tidak akan bisa membuatnya bekerja.
  • Refactor. Setelah berhasil, luangkan waktu untuk memperbaikinya. Jangan lupa rekan tim Anda harus membaca kode Anda juga: satu hari dihabiskan untuk memperbaiki bagian-bagian yang jelek dan mengganti solusi sederhana dengan yang berkinerja lebih baik bukanlah hari yang sia-sia.
  • Awasi semua bagian. Melacak changelogs dan sesekali membaca kode orang lain membantu memastikan bahwa semuanya sesuai dengan standar kualitas yang Anda rasa harus Anda tegakkan dan pastikan tidak sulit untuk menyelam jika orang tersebut keluar.
  • Jangan ragu untuk mengerjakan hal yang paling penting, yang bertentangan dengan hal yang Anda tentukan. Jika seseorang terlambat, buat catatan tertulis di suatu tempat dan lakukan sendiri. Tanyakan kepada mereka terlebih dahulu, tetapi lanjutkan jika mereka tidak menjawab, atau jika Anda bertanya sekali atau dua kali dan kemudian merasa mereka masih tidak akan melakukannya.
  • Fokus pada membuat sesuatu yang Anda banggakan. Bahkan jika itu menyimpang dari penugasan. Bahkan jika Anda harus memotong fitur-fitur besar demi membuat apa yang Anda miliki menjadi lebih lancar. Setiap iterasi berpikir "Apakah saya bangga dengan ini?", Dan pada iterasi berikutnya, cobalah untuk memperbaiki hal-hal itu.

Saya punya proyek yang gagal baru-baru ini; Anda dapat membaca pikiran saya tentang mengapa itu gagal jika Anda mau, tetapi ini merangkum bagaimana saya akan melakukan sesuatu seperti ini jika saya punya kesempatan lain.


Baca menarik, saya sudah dalam situasi yang sama dan tampaknya beberapa kegagalan sangat umum
Joe Taylor

4

Jawaban Jarrod Nettles bagus. Saya akan menambahkan ini:

  1. Berharap bahwa setidaknya satu dari tiga orang lainnya akan sama sekali tidak berguna.
  2. Hanya menerima bahwa Anda akan merasa seperti Anda melakukan sebagian besar (atau semua) pekerjaan, tetapi semua orang akan mendapatkan kredit yang sama. Upaya apa pun untuk membuat hal-hal "adil" hanya akan menyebabkan konflik yang tidak perlu dan memperlambat Anda.
  3. Tetap berkomunikasi dengan anggota tim yang baik. Orang-orang seperti itu sulit ditemukan, dan Anda akan ingin bekerja dengan mereka lagi.

Saya tidak setuju dengan dua poin pertama Anda. Jangan berharap yang terburuk dari orang atau itulah yang akan Anda dapatkan. Anda akan membangun kebencian dan mungkin kehilangan dukungan dari anggota tim yang berguna jika mereka merasakan penghinaan Anda. Membimbing anak yang tidak terbiasa dengan bahasa itu bisa menjadi pengalaman hebat dan mengurangi beban kerja Anda. (Tapi waspadalah terhadap lintah yang menolak untuk berpikir.) Juga, proyek memiliki "evaluasi tim" sehingga siapa pun yang melakukan pekerjaan bisa mendapatkan kredit. (Atau siapa pun yang membuat semua orang merasa seperti tanah tidak mendapatkan apa-apa.) Jujurlah dengan brutal dan jangan khawatir bahwa pria yang tidak melakukan apa pun gagal. Ini adil bagi tim Anda.
idbrii

3

Saya telah berada di posisi yang sama beberapa kali karena saya yakin memiliki banyak orang. Namun hal utama adalah melakukan yang terbaik untuk membuat semua orang puas dan bahagia, jadi saya pikir itu baik bahwa Anda ingin mengambil tugas pemimpin tim, namun seperti seseorang yang disebutkan di atas - ini perlu didekati dengan hati-hati seperti orang lain mungkin merasa mereka harus melakukan pekerjaan itu sebagai gantinya.

Saya tahu Anda mengatakan bahwa tidak ada seorang pun yang mengambil tindakan untuk menghubungi satu sama lain, tetapi kadang-kadang situasi ini bisa menyulitkan orang, seperti Anda mengatakan Anda bekerja dengan orang yang belum pernah Anda temui dan mungkin sulit untuk berkomunikasi, dll.

Saya akan mulai dengan email yang hanya ditujukan kepada semua orang dan memberi tahu mereka siapa Anda tentang bagaimana perasaan Anda terhadap proyek yang harus ditangani dan memberitahukan bahwa Anda ingin memimpin proyek yang bertanggung jawab untuk menetapkan peran, tujuan, tenggat waktu, waktu komunikasi, pertemuan ( jika diinginkan / diinginkan) dan pembaruan proyek.

Meskipun Anda tidak dapat sepenuhnya memengaruhi orang lain, Anda dapat melacak siapa yang melakukan apa dan siapa yang tidak. Mendelegasikan pekerjaan memungkinkan pekerjaan dibagi secara merata atau sesuai kepada orang-orang dengan keahlian atau level yang berbeda.

Dengan cara ini jika pekerjaan tertentu tidak dilakukan, Anda dapat mengambilnya sendiri untuk membagi pekerjaan antara orang-orang yang benar-benar ingin mengerjakannya. Dengan cara ini Anda tidak akan berakhir dengan proyek yang gagal di akhir dan Anda akan memiliki catatan mencoba untuk mengkomunikasikan tanggal, waktu dan semua informasi yang relevan yang dapat Anda tunjukkan di akhir jika ada yang salah. Banyak hal yang membuat Anda tetap benar jika beberapa orang tidak menarik berat badannya.

Dalam hal kiat:

Saya pribadi menyukai lingkungan kerja kolaboratif yang ditemukan di sini: https://docs.google.com/

Ini memungkinkan Anda untuk berbagi dokumen kata, spreadsheet, dll. Ini adalah cara hebat untuk bekerja sama. Saya tidak bisa menekankan betapa bermanfaatnya hal ini terkadang. Saya menggunakannya dengan beberapa orang yang bekerja dengan saya yang tidak ada di negara saat ini.

Semoga ini bisa membantu seseorang, ada begitu banyak aspek dalam memimpin sebuah proyek yang bisa kita jalani selamanya tetapi itu tergantung pada banyak hal. Setidaknya ini sedikit membantu.


Selamat datang di P.SE! +1 untuk saran di sini. Saran yang bagus.
Jarrod Nettles
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.