09.Gambaran umum manajemen proyek

GAMBARAN UMUM MANAJEMEN"

KONSEP MANAJEMEN PROYEK

3.1. Spektrum Manajemen

Manajemen proyek perangkat lunak yang efektif berfokus pada tiga P : People (manusia), problem (masalah), process (proses). Urutan ini tidak dapat berubah.

3.1.1. Manusia

Faktor manusia sangat penting sehingga Software Engineering Institute telah mengembangkan sebuah model kematangan kemampuan manajemen manusia (PM-CMM) ”untuk mempertinggi kesiapan organisasi perangkat lunak untuk mengerjakan aplikasi yang semakin kompleks dengan membantu menarik, menumbuhkan, memotivasi, menyebarkan, dan memelihara bakat yang dibutuhkan untuk mengembangan kemampuan perkembangan perangkat lunak mereka”

Model kematangan manajemen manusia membatasi area praktikj berikut kunci bagi masyarakat perangkat lunak : rekruitmen, seleksi, manajemen unjuk kerja, pelatihan, kompensasi, perkembangan karir, desain kerja dan organisasi, dan perkembangan tim/kultur.

3.1.2. Masalah

Sebelum proyek direncanakan, obyektivitas dan ruang lingkupnya harus ditetapkan, pemecahan alternatifnya harus dipertimbangkan, teknik dan bataspun harus didefinisikan. Tanpa informasi ini tidak mungkin melakukan estimasi biaya yang dapat dipertanggungjawabkan (akurat); penilaian yang efektif terhadap resiko; merinci secara realistis tugas-tugas proyek; atau jadwal proyek yang dapat dikelola yang memberikan indikasi kemajuan yang berarti.

Pengembang dan pemakai perangkat lunak harus bertemu untuk menentukan tujuan dan ruang lingkup proyek. Di dalam banyak kasus, aktivitas ini dimulai sebagai bagian dari proses rekayasa sistem dan berlanjut sebagai langkah pertama dalam analisis kebutuhan perangkat lunak.

3.1.3. Proses

Proses perangkat lunak memberikan suatu kerangka kerja di mana rencana komprehensif bagi pengembangan perangkat lunak dapat dibangun. Sejumlah kumpulan tugas yang berbeda – tugas-tugas milestone, kemampuan penyampaian, dan jaminan kualitas – memungkinkan aktivitas kerangka kerja disesuaikan dengan karakteristik proyek perangkat lunak serta kebutuhan tim proyek. Akhirnya aktivitas pelindung seperti jaminan kualitas perangkat lunak, manajemen konfigurasi perangkat lunak, dan pengukurannya – melapisi model proses yang ada.

3.2. Manusia

Hasil dari wawancara dengan beberapa wakil president direktur menandakan pentingnya manusia dalam proses rekayasa perangkat lunak.

3.2.1. Para Pemain

Proses perangkat lunak diisi oleh para pemain yang dapat dikategorikan ke dalam salah satu dalam lima konstituen berikut ini :

1. Manajer Senior, yang menentukan isu-isu bisnis yang sering memiliki pengaruh penting di dalam proyek.

2. Manajer (teknik) Proyek, yang harus merencanakan, memotivasi, mengorganisir, dan mengontrol sebuah produk atau aplikasi.

3. Pelaksana, yang menaympaikan ketrampilan teknik yang diperlukan untuk merekayasa sebuah produk atau aplikasi.

4. Pelanggan, yang menentukan jenis kebutuhan bagi perangkat lunak yang akan direkayasa.

5. Pemakai Akhir, yang berinteraksi dengan perangkat lunak bila perangkat lunak telah dikeluarkan untuk digunakan.

3.2.2. Pimpinan Tim

Jerry Weinberg cenderung mengusulkan model kepemimpinan MOI :

Motivasi. Kemampuan untuk memberi dorongan orang teknik untuk menghasilkan sesuatu dengan kemampuan terbaiknya.

Organisasi. Kemampuan untuk membentuk proses yang sedang berlangsung yang memungkinkan konsep dasar diterjemahkan ke dalam suatu hasil akhir.

Gagasan dan inovasi. Kemampuan untuk mendorong manusia untuk menciptakan dan bertindak kreatif meskipun mereka bekerja di dalam suatu ikatan yang dibangun untuk suatu produk atau aplikasi perangkat lunak yang spesifik.

Pandangan lain tentang karakteristik seorang manajer proyek yang efektif memberikan tekanan pada empat kata kunci :

Pemecahan masalah. Seorang manajer proyek yang efektif dapat mendiagnosis isu-isu organisasi dan teknis yang paling relevan, yang secara sistematis membentuk sebuah pemecahan atau dengan tepat memotivasi para pelaksana yang lain untuk membuat pemecahan.

Identitas manajerial. Seorang manajer proyek yang baik harus bersentuhan secara langsung dengan proyeknya. Dia harus memilki rasa percaya diri untuk melakukan kontrol bila perlu dan membolehkan orang-orang teknik yang baik untuk mengikuti insting mereka.

Prestasi. Untuk mengoptimasi produktivitas sebuah tim proyek, seorang manajer harus memiliki inisiatif dan prestasi, serta dengan caranya sendiri memperlihatkan bahwa pengambilan risiko yang terkontrol tidak akan dikenai hukuman.

Pengaruh dan pembentukan tim. Seorang manajer proyek yang efektif harus mampu “membaca” manusia; dia harus mampu memahami sinyal verbal dan nonverbal serta bereaksi terhadap kebutuhan-kebutuhan orang-orang yang mengirimkan sinyal tersebut. Manajer harus dapat menguasai diri meskipun berada pada situasi tekanan yang sangat tinggi.

3.2.3. Tim Perangkat Lunak

Mantei mengusulkan tiga organisasi tim yang umum :

Demokratis terdesentralisasi (DD). Tim rekayasa perangkat lunak ini tidak memiliki pemimpin yang permanen. Tetapi “koordinator” dipilih untuk bertugas di dalam durasi waktu yang pendek, yang kemudian diganti oleh yang lain yang mungkin bertugas untuk mengkoordinasi tugas-tugas yang berbeda. Keputusan terhadap masalah dan pendekatan yang dilakukan dibuat oleh konsensus kelompok. Komunikasi di antara anggota tim bersifat horisontal.

Terkontrol terdesentralisasi (CD). Tim rekayasa perangkat lunak memiliki pemimpin tertentu yang mengkoordinasi tugas-tugas khusus serta memiliki pemimpin-pemimpin sekunder yang bertanggung jawab atas masalah sub-sub tugas. Pemecahan masalah merupakan aktivitas dari kelompok, tetapi implementasi dari pemecahan masalah dipecah di antara sub-sub kelompok oleh pimpinan tim. Komunikasi antar kelompok dan orang bersifat horisontal, tetapi komunikasi vertikal sepanjang hirarki kontrol juga terjadi di sini.

Terkontrol terdesentralisasi (CC). Koordinasi pemecahan masalah tingkat puncak dan internal tim diatur oleh pimpinan tim. Komunikasi antara pimpinan dan anggota tim bersifat vertikal.

Tabel 3.1. merangkum pengaruh karakteristik proyek terhadap organisasi tim. Karena struktur tersentralisasi dapat menyelesaikan tugas dengan lebih cepat, struktur tsb paling banyak digunakan pada penanganan masalah-masalah yang sederhana. Tim terdesentralisasi memberikan solusi yang lebih banyak dan lebih baik daripada individual sehingga tim semacam itu memiliki kemungkinan keberhasilan lebih banyak pada saat bekerja pada masalah yang sulit. Karena tim CD tersentralisasi untuk penyelesaian masalah, baik struktur tim CD ataupun CC dapat diterapkan dengan baik pada masalah-masalah yang sederhana. Struktur DD merupakan yang terbaik untuk masalah-masalah yang sulit.

Tabel 3.1 Pengaruh karakteristik Proyek Pada Struktur Tim

Tipe tim :	DD	CD	CC
Tingkat kesulitan
Tinggi	X
Rendah		X	X
Ukuran
Besar		X	X
Kecil	X
Umur tim
Singkat		X	X
Panjang	X
Modularitas
Tinggi		X	X
Rendah	X
Keandalan
Tinggi	X	X
Rendah			X
Tanggal pengiriman
Ketat/pasti			X
Longgar	X	X
Sosiabilitas
Tinggi	X
Rendah		X	X

Karena unjuk kerja dari sebuah tim berbanding terbalik dengan jumlah komunikasi yang harus dilakukan, proyek-proyek yang sangat besar paling baik bila diserahkan kepada tim dengan struktur CC atau CD bila kelompok-kelompok sub dapat diakomodasi dengan baik.

Telah dibuktika bahwa struktur tim DD menghasilkan kepuasan kerja dan moral yang tinggi sehingga baik untuk tim dengan jangka waktu hidup yang lama.

Struktur tim DD paling baik diaplikasikan pada masalah-masalah dengan modularitas relatif rendah karena di sini dibutuhkan volume komunikasi yang lebih tinggi. Bila modularitas tinggi dimungkinkan (dan manusia dapat melakukan tugas-tugas mereka sendiri), struktur CC dan DD akan bekerja dengan baik.

Tim CC dan CD terbukti menghasilkan cacat yang lebih sedikit dibanding struktur tim DD, tetapi berhubungan erat dengan aktivitas jaminan kualitas khusus yang diaplikasikan oleh tim tersebut. Tim yang terdesentralisasi biasanya membutuhkan lebih banyak waktu untuk menyelesaikan sebuah proyek daripada struktur yang tersentralisasi, dan pada saat yang sama merupakan pilihan yang terbaik bila sosiabilitas yang tinggi diperlukan.

Constantine mengusulkan empat “paradigma organisasional” bagi tim rekayasa perangkat lunak :

1. Paradigma tertutup membentuk sebuah tim di sepanjang hirarki otoritas tradisional (sama dengan tim CC). Tim semacam ini dapat bekerja dengan baik pada saat memproduksi perangkat lunak yang sangat mirip dengan apa yang dilakukan sebelumnya; tetapi tim ini kurang inovatif ketika bekerja dalam paradigma tertutup.
2. Paradigma random membentuk sebuah tim secara longgar dan tergantung pada inisiatif individual anggota tim. Pada saat terobosan inovasi atau teknologi dibutuhkan, tim yang mengikuti paradigma random akan unggul. Tetapi tim semacam ini dapat berjuang keras bila “unjuk kerja yang teratur” diperlukan.
3. Paradigma terbuka cenderung membentuk tim dengan cara tertentu sehingga tercapai banyak kontrol yang berhubungan dengan paradigma tertutup, tetapi sekaligus juga banyak inovasi pada saat menggunakan paradigma random. Kerja dilakukan secara kolaboratif dengan komunikasi yang sarat serta konsensus yang didasarkan pada pengambilan keputusan. Struktur tim paradigma terbuka sesuai bagi pemecahan masalah-masalah yang kompleks, tetapi tidak akan bekerja seefisien tim yang lain.
4. Paradigma sinkron bertumpu pada pemggolongan alami dari suatu masalah serta mengorganisasi anggota tim untuk bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif di antara mereka sendiri.