Pelajaran yang bisa dipetik dari Belajar Rekayasa Perangkat Lunak – Bagian I adalah bahwa mahir di bidang pemrograman bukanlah jaminan bahwa kita akan sukses mengerjakan proyek rekayasa perangkat lunak (ini keyakinan jahiliyah saya waktu masih mahasiswa, jangan ditiru yah :D ). Pemrograman hanyalah salah satu pekerjaan (task) dalam rekayasa perangkat lunak. Setelah mengingat kembali proyek-proyek yang saya pernah terlibat di dalamnya, saya menyimpulkan bahwa proyek-proyek tersebut gagal karena kelemahan dalam hal-hal berikut:

  1. Manajemen Proyek
  2. Mungkin kesalahan saya dulu adalah tidak mengambil mata kuliah Manajemen Proyek sehingga proyek-proyek saya jadi gagal semua :D . Jadi apa itu manajemen proyek? Kalau menurut saya, secara singkat manajemen proyek adalah mengenai bagaimana kita bisa merencanakan dan menjalankan proyek agar hasilnya sesuai dengan tujuan proyek, tentunya dalam waktu yang sesuai jadwal dan biaya yang sesuai anggaran.

    Teorinya, pertama-tama kita tentukan dulu tujuan proyek (seperti apa hasil atau produk yang diharapkan dari proyek). Selanjutnya, kita tentukan pekerjaan-pekerjaan apa saja yang perlu kita lakukan untuk mencapai tujuan tersebut. Untuk setiap unit pekerjaan, kita perkirakan berapa lama waktu dan orang yang dibutuhkan untuk menyelesaikan pekerjaan tersebut. Setiap orang dapat memiliki “tarif” yang berbeda (bisa juga sama, ini masalah bisnis) per satuan waktu (bisa jam, hari, atau bulan). Dengan menggunakan informasi waktu yang dibutuhkan dan “tarif” setiap orang yang terlibat dalam keseluruhan pekerjaan proyek, maka kita dapat menentukan biaya proyek untuk bagian sumber daya manusia (SDM). Untuk mendapatkan biaya total proyek kita dapat menambahkan biaya-biaya lain (kalau ada) seperti biaya lisensi perangkat lunak dan transportasi. Jangan lupa juga menambahkan margin keuntungan yang ingin kita peroleh :D .

    Setelah semua rencana mengenai tujuan proyek, unit-unit pekerjaan, jadwal, SDM, dan anggaran kita mulai menjalankan proyek. Selama proyek berjalan, kita evaluasi secara berkala apakah pelaksanaan proyek sesuai dengan rencana atau tidak.

    Teorinya sih seperti itu :D . Kenyataan di lapangan seringkali tidak sesederhana teori yang saya ceritakan. Langkah pertama, menentukan tujuan proyek, merupakan salah satu faktor utama penyebab kegagalan proyek. Seringkali tujuan proyek terlalu abstrak atau high-level, atau sering juga tujuan proyek tersebut berubah-ubah selama proyek berjalan. Penentuan unit pekerjaan dan perkiraan waktu juga merupakan hal yang sulit dilakukan jika proyek tersebut merupakan proyek pertama kita dalam suatu domain. Yang saya maksud domain di sini bisa dari segi bisnis maupun teknologi. Dari segi bisnis misalnya: biasanya kita membangun perangkat lunak untuk industri retail, namun dalam proyek saat ini klien kita adalah rumah sakit. Demikian juga jika kita sebelumnya biasa menggunakan platform Java dan untuk proyek saat ini kita harus menggunakan platform .NET.

    Sebenarnya, manajemen proyek tidak hanya membahas mengenai masalah tujuan proyek, membagi unit pekerjaan, memperkirakan jadwal, menentukan SDM yang diperlukan, dan menghitung anggaran. Rujukan otoritatif mengenai manajemen proyek dapat Anda baca di A Guide to the Project Management Body of Knowledge (PMBOK). Ada 9 knowledge area dari PMBOK, yaitu: integrasi, scope, waktu, biaya, kualitas, SDM, komunikasi, resiko, dan procurement. Mungkin saya akan membahas PMBOK pada tulisan yang terpisah karena akan terlalu panjang jika disampaikan di sini.

    Jika pembaca ingin mempelajari manajemen proyek lebih lanjut, saya juga merekomendasikan buku The Mythical Man-Month. Frederick P. Brooks, Jr. menulis buku ini dengan gaya bercerita sehingga enak untuk dibaca, tidak seperti buku teks kuliah. Selain itu, saya juga sering membaca artikel dari blog Endy Muhardin, pemilik perusahaan pengembang perangkat lunak Artivisi. Beliau memiliki banyak pengalaman dalam bidang manajemen proyek rekayasa perangkat lunak dan untungnya, beliau banyak membagi ilmunya melalui blog :D .

  3. Penerapan Metodologi Rekayasa Perangkat Lunak yang Benar
  4. Kalau faktor kedua ini saya sudah mengambil mata kuliahnya :D . Dari mata kuliah Rekayasa Perangkat Lunak saya mengetahui mengenai metodologi waterfall, spiral, iteratif, prototyping, Rapid Application Development (RAD), dan object-oriented. Selain semua itu, ada juga suatu kelompok metodologi yang baru saya ketahui secara otodidak: Agile. Terdapat banyak metodologi yang termasuk dalam kelompok Agile, di antaranya adalah Scrum, Extreme Programming (XP), Rational Unified Process (RUP), dan Test-Driven Development (TDD). Metodologi-metodologi dalam kelompok Agile ini lahir sebagai kritik terhadap metodologi-metodologi sebelumnya yang kebanyakan berbasis waterfall. Para pencetus Agile secara garis besar menyampaikan kritik mereka dalam Agile Manifesto.

    Teori dan metodologi dalam rekayasa perangkat lunak itu ada banyak sekali. Dan dalam prakteknya metodologi rekayasa perangkat lunak juga tidak semudah teori karena:

    1. Tidak semua ahli sepakat mengenai bagaimana metodologi rekayasa perangkat lunak yang benar.
    2. No Silver Bullet, tidak ada suatu metodologi yang cocok diterapkan untuk semua kasus rekayasa perangkat lunak.
    3. Jadwal, jumlah SDM, dan biaya dari suatu proyek kadang-kadang berbenturan dengan metodologi yang digunakan. Yang ini merupakan permasalahan bisnis.

    Sebenarnya masih ada lagi 2 hal yang menjadi penyebab utama kegagalan proyek-proyek saya, yaitu bagaimana berhubungan dengan klien/pengguna dan pemahaman akan proses bisnis klien. Kedua hal tersebut memang tidak diajarkan dalam kuliah. Saya akan membahas kedua hal tersebut dalam tulisan saya selanjutnya (kalau masih semangat nulis :D ).

    Related posts:

    1. Belajar Rekayasa Perangkat Lunak – Bagian I
    2. Sebuah Jawaban Atas “Misteri Proyek Rekayasa Perangkat Lunak”
    3. Tantangan Dalam Membangun Perangkat Lunak untuk Domain Bisnis