Seputar Manajemen Proyek TI (bag.2)

Alhamdulillah, bisa nge-blog lagi. Kali ini saya mencoba melanjutkan tulisan sebelumnya di bagian pertama.
Jika di bagian sebelumnya, saya membahas Q & A seputar ManPro TI. Kini saya mencoba menjelaskan hal yang paling mendasar dari Manajemen Proyek IT itu sendiri.

Apa sih Manajemen Proyek? Kita mengetahui manajemen ya melakukan dan mengatur (doing and control), namun bagaimana dengan proyek? apa hal yang bisa dikatakan itu sebagai proyek? adakah kunci atau point-point utama dalam proyek itu sendiri?

Proyek TI sendiri memiliki ciri-ciri utama yaitu : direncanakan, memiliki batasan (biaya dan waktu), tujuan atau target (goal), tindakan (implementasi dan control), bersifat sementara (dalam satu garis waktu; timeline. Kalo seumur hidup, itu bukan proyek namanya :p ), ada aktornya (pihak eksekutif, client/sponsor, vendor/tenaga pelaksana yang terangkum dalam deliveriable), dan yang terakhir mengandung kata “business”.

Manajemen Proyek ini dipimpin oleh seorang Manager, yang tentunya sudah tentu memiliki skill manajemen yang bagus dan memiliki jam terbang yang tinggi di dalam dunia perproyekan. Lantas apakah bisa seseorang yang baru bergabung dalam ManPro bisa menjadi manager? bisa iya, bisa tidak. Jika, ia memiliki karakter pemimpin, mampu mangatur setiap tindakan yang ada dalam proyek, termasuk bertindak cepat tentunya. Bisa dijadikan sebagai manajer (namun masih junior), dan itu perlu didampingi oleh yang senior.

Managers do things right, leaders do the right thing

Pengelolaan proyek TI harus seimbang antara Scope (Lingkup Pekerjaan), Cost (biaya), Resource (sumber daya) dan Time (Waktu). Dan peran pengelolaan dipegang oleh seorang Manajer Proyek TI tersebut.

Adapun goal yang harus dicapai oleh pihak vendor, terutama oleh si Manajer adalah mampu memenuhi kebutuhan dan memuaskan pihak client. Bentuk kepuasan itu terletak pada :

      • Scope atau Lingkup Pekerjaan. Apakah proyek yang sudah dikerjakan sesuai dengan cakupan yang diminta pihak client? Jangan sampai kurang, jangan sampai lebih, diusahakan pada tingkat yang pas. Jika kekurangan, tentu akan mengganggu kestabilan software yang dibangun, ntah itu fiturnya tidak lengkap, atau kurang bagusnya code/design, dan sebagainya. Atau kelebihan? misal : konsumen meminta kepada tukang jahit untuk dibuatkan celana dengan bahan yang sudah ditentukan, kemudian tukang jahit melihat bahannya masih banyak sisa, kemudian bahan sisa tersebut ditambahkan ke celana yang sudah jadi dengan motif bunga-bunga misalnya. Kan jadi gak sesuai scope πŸ˜› Ya, dalam industri TI juga demikian, ketika pihak vendor meminta dibuatkan web untuk perusahaannya, harus pas sesuai yang diminta (requirement), jangan dilebihkan dengan hal-hal yang tidak perlu. Di awal, client akan bercerita (user stories) apa dan kapan yang ia butuhkan, dan apa yang tersedia dan yang perlu disediakan. Inilah yang menjadi kunci awal untuk menjadi milestone yang dipegang pihak vendor TI, tentang apa saja yang dikerjakan pada tahap execution projectΒ tersebut.

Tahapan project itu biasanya : opening Project>brainstorming (kick-off meetings bahas concept; user stories) > planning > execution > control > closing Project.

      • Time atau waktu. Bila disiplin dengan metode pengembangan software yang sudah ditentukan, biasanya bisa ontime. Namun, terkadang luput dari sasaran yang sudah ditentukan. Bisa banyak sebab, bisa jadi karena Resource-nya yang kurang. Ntah itu infrastruktur yang disediakan yang kurang memadai untuk digunakan, atau SDMnya yang kurang banyak atau terlalu banyak sehingga komunikasinya terhambat, atau karena kehabisan/tersendaknya biaya yang dikeluarkan oleh pihak client. Ada baiknya diperhatikan betul waktu yang dibutuhkan untuk mencapai setiap cakupan (scope) tersebut. Baiknya ya dari pengalaman. “eh, dulu kita ngedevelop fitur x berapa lama y?” | “oh waktu itu 2 minggu, pak” | “ok, bisa kita coba 17 hari, kita lebihkan 3 hari untuk mencegah hal-hal yang tidak diinginkan”.
        Namun, dilihat juga berapa panjang timeline yang diberikan client, berapa banyak fitur yang dikerjakan dan berapa SDM yang tersedia.
      • Cost atau biaya. Dalam menentukan biaya, ada banyak faktor yang perlu diperhatikan. Saya tidak akan menjelaskan secara detail, namun setiap menentukan biaya itu ada peran “pengalaman” atau “jam terbang” atau “portofolio” yang bermain di sini. Semakin tinggi, harga yang ditawarkan semakin tinggi pula. Tentunya, dengan tinggi pengalaman, teknologi dan metode yang dipakai tentu sudah baik, tepat dan berkualitas. Dan tentunya, pihak client juga sudah “jatuh hati” pada pandangan pertama setelah mengetahui portofolio yang telah dikerjakan. Selain itu, berapa banyak deliveriables dan personil yang menjadi aktor di dalamnya menentukan besaran biaya yang dibutuhkan untuk investasi tersebut. Setiap posisi dalam aktor yang mengerjakan memiliki harga yang berbeda. Dan itu sudah disepakati melalui kontrak kerja. Ada yang menentukannya melalui work unit. Misal : harga per work unit : Rp 100.000 untuk seorang programmer. Si Programmer bekerja selama 5 hari dengan 8 jam kerja. Berarti work unitnya : 5 * 8 = 40 work unit. Kemudian menentukan harga si programmer dengan : 40 work unit * Rp 100.000 = Rp 4.000.000,-
      • Quality atau Kualitas. Banyak yang beranggapan, kualitas ini tidak termasuk dalam bentuk kepuasan dari client tersebut. (ya tergantung, kalo proyek atas dasar kepentingan pihak tertentu, yang penting asal jadi aja…biasanya kualitas itu malah hilang :p) Semakin baiknya kualitas, tentu lifetime dari software tersebut bisa berlangsung sangat lama. Dan tentunya, pihak client menjadi “terpesona” dengan apa yang sudah dibuat, dan meningkatkan rate biaya juga πŸ˜€ Tetapi, kualitas bukan hal yang sederhana, untuk membuat software yang berkualitas, dibutuhkan jam terbang yang tinggi, mengikuti trend teknologi dan cakap dalam hal merancang, membangun dan memelihara software itu sendiri.

RBT = Resource, Budget, Time => “on time, on budget, to the specifications”

Portofolio menunjukan jati diri kita, apa yang sudah dikerjakan. Dan ini lebih ke arah strategic business ke client.

Agar sukses mencapai tujuan tersebut, ada beberapa hal yang diperhatikan, yaitu :

  • Tools yang dimanfaatkan harus tepat, tools di sini meliputi tools untuk manajemen proyeknya tersebut. Kalau biasa dengan produk Microsoft, mungkin bisa mencoba Ms. Project, atau dengan produk opensource seperti Redmine. Adapula tools yang lain, seperti CASE (Computer Aided Software Engineering) tools : Enterpisce Architect, Rational Rose, Power Designer, dll.
  • Selain itu, perlu digunakan metode formal dalam manajemen proyek TI. Tiap perusahaan menggunakan metode atau pendekatan berbeda dalam melaksanakan aktivitas proyek TI. Itu tergantung pada kenyamanan mereka bekerja dan jam terbang masing-masing. Namun, ada baiknya disesuaikan dengan kondisi proyek tersebut, ntah itu kondisi personilnya, biayanya, timelinenya dan apa yang akan dibuat.
    Metode Software Development yang banyak digunakan adalah metode Agile. Ada yang menggunakan XP (eXtreme Programming), Scrum. Selain Agile juga ada yang masih memanfaatkan metode classic, matematis ataupun waterfall (eh, waterfall bukannya biasa dipake anak-anak kuliah? πŸ˜› )
  • Peran pimpinan proyek (project manager) dalam mengatur dan mengelola proyek itu sendiri sehingga prosesnya berjalan dengan baik (tiap proses menghasilkan sesuai target). Mampu berkomunikasi dengan baik dengan personil, menumbuhkan kesan dan pengalaman berarti untuk soft-skill tiap personil dan tentunya mampu menjalin hubungan bisnis yang baik dengan client maupun personil.Β 
  • Pengukuran kesehatan project sedini mungkin. Bentuk pengukuran ini dapat diperhatikan dengan tingkat kepuasan client untuk setiap progress proyek itu sendiri, apa yang sudah dikerjakan, bagaimana hasilnya, bagaimana waktunya, tepat waktu dan benarkah? Bagaimana dananya? apakah menipis? biasanya bila dana menipis, ya kesehatan project terganggu, dan mempengaruhi aspek lain juga (time dan resource).

“Project dikendalikan oleh strategi, dapat dilakukan bagaimana setiap project dapat fit dengan strategy business, menghilangkan yang tidak dibutuhkan sesegera mungkin. Dan sedapat mungkin menggandeng stakeholders. Mengabaikan stakeholders sama saja membuat project gagal.” -Robert Butrick

Sumber : dari berbagai sumber, pengalaman di lapangan dan dari perkuliahan πŸ™‚

Seputar Manajemen Proyek (bag.1)

Q : Jika misal klien kita sebuah perusahaan, nah masalah tarifnya gimana? Tarifnya menyesuaikan besarnya company gak? Misal perusahaannya itu perusahaan baru dan yang lagi berkembang skala nasional, kan income mereka juga beda gitu. Gimana mas?

A : masalah tarif proyek TI itu ada beberapa pertimbangan :

  • Ketersediaan infrastruktur untuk lingkungan implementasi.
  • banyaknya personil yang terlibat dalam pengembangan sistemnya + beban job descnya (manajerial & staff teknis & staf pendukung).
  • milestone pekerjaan systemnya (apa saja yang dikerjakan dan berapa lama waktunya (timelineny).. nah ini ada penjelasannya lagi).
  • Teknologi yang dipakai.

Dan itupun tidak menyesuaikan besarnya perusahaan kok.

Q : oh, brarti menentukan harga memang tahapnya banyak juga ya…hehe…oh, trus klo kliennya personal/individu gimana, mas? Kan tarifnya mesti beda sama klien company ya?

A : Banyak.. dan semuanya tertulis. Jadi pihak vendor dan pihak client jelas. Tetapi terkadang juga sulit diterapkan hal tersebut, apalagi dari clientnya yg “kotor”, itu yg gawat, biasanya mereka memang mengadakan apa gitu (tender), buat menghabiskan anggaran belanja saja, tanpa keperluan dan tujuan yang jelas, akhirnya useless. Hehehe..tetapi tidak semua begitu. Hanya sedikit. Dan kalau bisa ya mending dihindari. πŸ˜€
Kalau clientnya personil, liat skala pengerjaannya juga, apakah besar atau kecil? Jika kecil, tidak serumit seperti yang dijelaskan di atas.

Biasanya meliputi hal berikut :

  1. biaya hosting, domain, dll (adakah?)
  2. Milestone pekerjaan perangkat lunaknya
  3. Teknologi yang dipakai, biasanya semakin baru maka semakin bagus
  4. Tidak dikenai pajak, karena ratenya rendah πŸ˜€

Walau personil/pribadi atau proyek bersama, keduanya mesti ada kontrak tertulis, dan jangan lupa, kasih aturan, terutama menghindari client yang hobi telat bayar, kalo telat = denda. Haha πŸ˜€

modelnya ada 3 loh :

  1. Tender (jadi si client sudah punya harga, sudah menentukan jumlah personil yang harus disediakan)
  2. Dari permintaan (permintaan client ke kita, via pribadi atau via vendor)
  3. Dari penawaran (kita yang menawarkan diri ke client)

nah, untuk no.1 ada tata urutannya. Biasanya sebagai berikut :

  1. Opening project (meeting internal) dgn client, rapat, dengerin user stories – ini siapin analyst dan team dokumentasi (buat nyatet+dokumentasiin) dan PM.
  2. Breakdown keperluan app yg mau dibuat.
  3. Dokumentasi dibuat secara rapi sesuai format, terus diperiksa oleh client apakah sudah benar dan sesuai belum.
  4. Kalo no.3 sudah, tinggal system architecture (db+server), system analyst yg kerja.
  5. Kerjaan si no.4 dikasih ke pimpinan developer (lead programmer atau supervisor) dan dijelaskan jg ke designer UInya.
  6. Rapat lagi ke programmer, jelasin job descnya, negosiasi harga, blablabla..ini agak panjang jg.
  7. Masuk masa implementasi.
  8. PM control pekerjaan beserta analyst bantu ngarahin biar kerjaan programmer terarah.
  9. Closing project, dokumentasi akhir, dll.

Q : Oya satu lagi, cuma pengen tau pembagian gaji tiap orang. Misal : utk proyek diatas PM dapet berapa trus analyst berapa, programmer, dst…itu juga masih kurang tau aku πŸ™‚

A : Lebih detailnya malah bisa berlembar-lembar hahaha. Intinya masih sama dengan yang diajarkan di RPL, walau sebenernya ada beberapa yg “basi” sudah ditinggalkan, kayak model “waterfall” dan masalah user testing.

  • PM tanggung jawab 100% kegiatan
  • Analysis itu component pekerjaannya 20% dari seluruh kegiatan,
  • Dokumentasi+testing itu 20% juga dari seluruh kegiatan
  • Programmingnya 60% dari seluruh kegiatan (makanya kerjaan programmer itu banyak daripada analyst LOL)

Tapi kenapa dari setiap personil, bobot pekerjaan sedikit, namun gajinya lebih besar? Ya, sebagai contoh Analyst terhadap Programmer, terlihat karena tanggungjawab, tingkat pemahaman serta tingkat stressnya lebih tinggi daripada programmer πŸ˜€

Nah, masalah hitung menghitung masing-masing personil+job desc-nya. Tergantung kesepakatan dan kebijakan si PM (project manager) dan si pemilik vendor dan bagian keuangannya. Ada beberapa perusahaan, yang mewajibkan setiap investasi harga proyek dari client itu 25%-nya masuk ke kas perusahaan. Jadi misal, kalo 25% dari harga proyek itu sudah PASTI masuk kas perusahaan, maka yg didapet personil adalah 75% dari harga proyek. Kenapa? demi kemajuan perusahaanlah πŸ˜€ dan juga penggajian karyawannya. Nah, harga personilnya di-breakdown lagi.

Ini personilnya ada yang outsourcing atau dari pegawai sendiri? πŸ˜€ Sayangnya kalo pegawai sendiri itu hitungannya gaji.. jadi agak sedikit rugi, namun untungnya pas tutup buku akhir tahun biasanya.

Sedangkan outsourcing, itu dibagi lagi, apanya? dia posisinya apa? analyst, bisa dapet sekitar 15%-20% dari harga proyek, kalo programmer (total loh..jadi kalo ada 6 ya dibagi 6 aja) itu sekitar 30%-40%. Tapi masing-masing punya kebijakan berbeda-beda.

Q : Ada tips-tipsnya gak mas mengenai proyek agar aplikasi yang kita kembangkan mendekati keinginan user?

A :

tipsnya :
punya “koneksi” + “komunikasi” yang bagus, mas πŸ™‚ Dan dengan koneksi dan komunikasi yang bagus, tentunya kita dapat memahami bagian “user stories” dengan baik, mulai dari bagian manajerial sampai ke teknisnya. Semua itu kita bagi menjadi bagian kerangka acuan kerja, timeline, wireframe kemudian milestone dan kemudian kita bagi lagi menjadi lebih spesifik menjadi tasks yang akan dikerjakan oleh programmer.

Untuk masalah koneksi, sedia link di mana-mana, bahkan di luar kota sekalipun, artinya mas wajib punya relasi dan partner yang bener-bener se-visi. Agak susah memang, itu dari pengalaman soalnya. Kalau sudah bagus koneksinya, biasanya akan dapat rekomendasi dari mana-mana : “eh, dia itu bagus loh..buat ngerjain ini, coba contact dia” dan “blablabla..” spt itu πŸ™‚

Apalagi urusan SDM, karena koneksi yang kita maksud di sini adalah ketersediaan SDM, jika salah pilih, gk akan maksimal hasilnya.

Masalah investasi, ada tolak ukur sendiri-sendiri c..jadi tepat jg mengukur apa saja beban personil dan berapa besar biayanya.

Jangan jg “membodohi” personil, apalagi urusan investasi ini.

Mengenai masalah teknologi yg dipakai, hmm..kebanyakan pakai framework c mas, lebih enak buat pelebaran dan bongkar pasang, kalopun pake CMS juga bisa. πŸ™‚

Nah urusan timeline (waktu), ada banyak hal yg harus diperhatikan dan sepakati bersama dengan si Client.
Jangan sampai salah satunya melanggar atau mengulur waktu, dan konsistensi ini perlu ada perjanjian di atas kertas.

Dan bagi temen-temen yang butuh template dokumen business plan, kerangka acuan kerja, dan lain-lain untuk startup ataupun proyek, bisa mampir ke link : <a href=”http://www.businessinsider.com/document-center”>ini</a&gt; πŸ˜€