Mungkinkah Paralalelisme Tugas di Tim Software?

Minggu ini, kami bertiga menjadwalkan presentasi dua proyek ke customer. Akhrinya proyek yang satu di pegang Harry, proyek yang satu di pegang Dankos. Gw bantu mereka diskusi dan nyusun-nyusun jadwal dan ngerinciin pekerjaan yang harus selesai pada waktunya dan kapan ngerjainya - simply to say, me-manage. Semakin hari, perkara manajemen ini semakin pusing. Padahal timnya kecil. Tapi memang proyeknya juga aga gak masuk diakal dikerjain dengan jumlah tim segini. Tapi gimanapun, semua harus selesai.

Mengenai paralelisme tugas. Satu orang, bertanggung jawab untuk mengerjakan beberapa pekerjaan. Sebelum kita bahas tentang paralelismenya, kita bahas dulu, pekerjaan apa aja yang harus ada waktu kita ngembangin software.

1. Project Management, kita yang kerjaannya selalu teknis, akan memandang sebelah mata pekerjaan ini. Kita terbiasa membuat software yang (setidaknya menurut kita) bagus. Karena itu kita mikir, kitalah (para engineer) superhero :). Kalo di proyek kecil, ok. Tapi kalo udah agak besar sedikit. Rasain sendiri deh tuh :) Project Manager (PM) tugasnya bikin perencanaan secara umum, bikin jadwal, bagi-bagi pekerjaan, dan kontrol pekerjaan2 itu. (mungkin ada yang kurang nih). Bayangin apa yang PM musti bisa? Dia harus paham seluruh proses (analisis, disain, coding, testing, deployment) yang ada di tim, dia juga harus bisa memprediksi lama waktu pengerjaan berdasarkan pemahaman proses tersebut dan berdasarkan kemampuan anggota2 tim.
2. Analisis sistem, ini juga pekerjaan yang dianggap enteng. Mungkin yang baca tulisan ini pernah mengalami proyek yang ga beres2, modul-modul yang gak kepake setelah dibikin, modul-modul yang salah akhirnya harus dirombak, laporan-laporan yang kacau... dsb dsb. Nah, dosa-dosa ini sebagian besar disebabkan oleh orang yang mengerjakan project management dan analisis sistem :) Kenapa begitu? Kalo sistem analis salah, maka itu akan jadi domino effect, semua pekerjaan salah, karena yang dikerjain selama ini adalah sesuatu yang dipahami secara salah, atau solusi yang disimpulkan tidak tepat. PM salah, soalnya dia tidak kontrol keadaan ini.
3. Disain sistem, pekerjaan ini juga gak mudah. Mari kita liat faktanya. Berapa banyak programmer jago yang bisa disain dengan baik? Yang paham betul tentang loosly coupling, cohession, modularitas dsb dsb. Banyak banget programmer jago, cuma dari segi disain, belum tentu bagus. Apa manfaat disain yang bagus? Manfaatnya adalah memudahkan ketika ada perubahan, dan pada masa maintenance.
   
4. Programming. Pekerjaan yang kita semua sukai :)
   
5. Testing. Ada banyak fase-fase testing. Setiap orang dalam tim harus melakukan testing berdasarkan tingkatanya masing-masing. Programmer, harus melakukan tes, apakah pekerjaanya sudah berjalan dengan baik dan benar. Benar, artinya input, proses, dan output sudah benar. Baik, artinya sudah sesuai dengan disain. Disainer harus testing apakah pekerjaan sudah sesuai dengan disain atau belum, dan apakah memenuhi spesifikasi yang dijelaskan analis. Analis juga harus testing, apakah pekerjaan sudah memenuhi kebutuhan client atau belum, dan apakah semua proses sudah benar. Idealnya proses ini dikerjakan oleh orang-orang khusus.
6. Deployment. Proses ini isinya instal, pelatihan, terus perbaiki kalo ada masalah. Untuk aplikasi2 kecil, proses ini sangat mudah. Gimana kalo softwarenya udah dipake banyak divisi dengan kemampuan komputer yang seadanya? Kalo analisisnya ngaco, disainya ngaco, programmingnya berantakan, datanglah hari-hari penuh derita untuk tim pengembang.
7. Maintenance. Proses ini harusnya sudah tidak terlalu ribet. Karena software harusnya sudah berjalan lancar. Tapi ada aja yang gak seharusnya :)

Seluruh pekerjaan di atas, disadari atau tidak, HARUS bin WAJIB dikerjakan pada pengembangan software. Kalo ada salah satu yang gak diperhatiin, maka hari-hari penuh derita yang dateng.

Sekarang bicara paralelisme. Satu orang ngerjain beberapa tugas. Setelah didaftarin di atas, kebayang gak pusingnya kalo ada satu kerjaan dipegang oleh dua orang? Misal, PM digabung sama sistem analis. Orang itu harus bikin planing, jadwal.........., dia juga harus ketemu customer, wawancara, simpukan solusi.................. Bisa kebayang bebannya?

Lalu gimana dengan programmer dan disainer dijadikan satu? Ini yang sering dianggap biasa. Yang akhirnya software yang dihasilkan disainya kacau balau berantakan. Orang-orang yang maintain bisa gila ngurusinnya.

Sekarang, gimana kalo timnya kecil? Apakah tidak bisa paralelisme? Menurut gw sih bisa, tapi harus diliat kombinasi paralelisme yang pas. Sekarang mikir dulu, ntar kalo dah ketemu yang pas gimana baru tulis lagi :)