14 Januari 2009

Bagaimana Menentukan Nilai Proyek

Dalam dunia IT (khususnya dunia sistem informasi) banyak sekali cara menentukan harga sebuah aplikasi yang diterapkan oleh perusahaan jasa aplikasi ataupun freelance programmer. Ada yang memberikan harga per-paket, ada yang berdasarkan jumlah form, ada yang menentukan flat-price, ada pula yang menetukan berdasarkan rate per-jam atau per-hari.
Bagaimana sebuah kerja skill dihargai? Sedemikian sulit-kah menentukan harga sebuah aplikasi? Argumen apakah yang bisa diberikan seorang programmer dalam menentukan harga sebuah aplikasi? Ini adalah masalah klasik dalam dunia sistem informasi, khususnya bagi para freelance programmer.

Perhitungan Harga Penawaran
Berdasarkan obrolan dengan sesama freelance programmer dan juga dari pengalaman, saya mencoba merumuskan bagaimana memberi harga pada sebuah hasil karya skill. Sebenarnya ini bukan rumus mutlak. Tapi paling tidak merupakan satu cara menentukan harga aplikasi yang kira2 mungkin bisa diterapkan dan “cukup fair” yaitu dengan memakai formula:

HP = HT – (d x HT)

dimana: HT = [ R x W ] + K + M

HP = Harga penawaran sebuah aplikasi atau project aplikasi.
HT = Harga total pekerjaan aplikasi.
R = Rate per-hari atau per-jam dari seorang programmer dimana 1 hari = 8 jam kerja.
W = Estimasi waktu amanya pengerjaan aplikasi/proyek.
K = Harga konsep aplikasi.
M = Harga material aplikasi.
d = prosentase potongan harga (discount) yang diberikan.

Mengapa saya bilang “cukup fair”? Ini disebabkan karena dengan formula ini seorang programmer dituntut untuk bisa memberikan estimasi yang masuk akal dan cukup objektif akan hal2 seperti: seberapa objektif seorang programmer menilai skill aplikasi dan pengalamannya, berapa lama sebuah pekerjaan bisa diselesaikan, berapa harga sebuah konsep aplikasi atau perlu/tidaknya memberikan potongan harga kepada klien, dsb. Juga dikatakan “cukup fair” karena dengan menerapkan perhitungan ini, kedua belah pihak (programmer dan klien) diharapkan bisa melihat sisi objektif dari sebuah pekerjaan aplikasi. Calon klien tidak merasa dibohongi dan di sisi lain programmer juga tidak merasa bekerja rodi.

Menentukan Variabel2 Formula.
1. Rate (R)
Rate adalah harga perhari atau perjam yang ditentukan pada kemampuan seorang programmer dalam mengerjakan pekerjaan2 aplikasi. Besarnya bergantung pada skill yang dikuasai, pemahaman konsep aplikasi, pengalaman, portfolio, kredibilitas klien yang pernah ditangani, dsb.

Singkatnya R bergantung pada pengalaman dan jam terbang seorang programmer. Sebagai contoh seorang programmer yang menguasai seabrek software aplikasi mulai dari Delphi sampai program .Net, memiliki pemahaman konsep aplikasi yang dibuktikan dengan portfolio yang ditunjukkan, pernah bekerja di perusahaan sistem informasi terkemuka, berpengalaman menangani klien2 “wah” seperti Nokia, BMW, dsb, bisa dikategorikan sebagai highly priced programmer dengan rate misalnya Rp. 2.000.000/hari. Sementara seorang lulusan sekolah IT yang baru memiliki 2-3 portfolio dari perusahaan2 kecil bisa dikategorikan sebagai pemula dengan rate sekitar Rp. 100.000/hari. Disini, seorang programmer dituntut untuk mampu mengestimasi “nilai jual” dirinya berdasarkan faktor2 tersebut.

R bisa dihitung perhari ataupun perjam. Mengapa? Beberapa programmer menentukan rate/hari dengan alasan kemudahan perhitungan. programmer lain menerapkan rate/jam dengan alasan agar lebih gampang menghitung waktu untuk revisi. Sebenarnya ini sama saja. Seperti disebutkan di atas, 1 hari = 8 jam. Sekarang kembali kepada sang programmer untuk menghitung lamanya pengerjaan sebuah proyek aplikasi dalam hitungan hari (agar lebih sederhana) atau dalam hitungan jam agar lebih detail.
Tetapi ada satu hal lain yang harus dipertimbangkan. Ada kalanya rate/jam sangat sulit diterima oleh klien di Indonesia. Di negara2 maju dimana pekerjaan aplikasi sudah dihargai dengan baik, rate/jam mungkin bisa diterapkan dan diterima oleh calon klien. Ini karena profesi programmer sudah dianggap sejajarkan dengan pekerjaan jasa profesional lain seperti pengacara, dokter, dsb. Akan tetapi bila kita berbicara dalam ruang lingkup lokal, berdasarkan pengalaman saya, rate/jam sangat sulit untuk diterima oleh umumnya klien di Indonesia. Tapi bila seorang programmer merasa confident untuk menerapkan rate/jam untuk klien di Indonesia, well.. why not?

2. Estimasi Lamanya Pengerjaan (W)
Estimasi lamanya waktu pengerjaan adalah jumlah waktu yang dibutuhkan untuk menyelesaikan sebuah aplikasi/proyek aplikasi. Berkaitan dengan rate (R), waktu bisa dihitung dalam satuan hari ataupun jam. Sebagai gambaran, jumlah waktu pengerjaan 1 (satu) form tanpa konsep OOP (Obyek) tentu akan berbeda dengan jumlah waktu pengerjaan 1 (satu) form full OOP maupun ODMS.

Dalam menentukan jumlah hari ini programmer dituntut untuk reasonable dalam arti tidak mengada-ada dan masuk diakal. Sebagai contoh mengerjakan sebuah form simpel tentu tidak akan memakan waktu sampai 7 hari (56 jam), bukan? Bila programmer menetapkan variabel Rate (R) dalam satuan hari, variabel H tidak harus bulat, ia bisa bernilai 0.5 (setengah hari = 4 jam) hari atau 0.25 (seperempat hari = 2 jam).

3. Harga Konsep Aplikasi (K)
Yang agak rumit mungkin menentukan harga konsep aplikasi. Akan tetapi kita bisa mengira2 seberapa original dan brilyan-nya sebuah konsep aplikasi. Disinilah seorang programmer dituntut untuk bisa menguraikan konsep aplikasi yang ia tawarkan. Bukan hanya terbatas pada ide dan tampilan visual semata, tapi juga mencakup hal2 lain seperti ‘kredibilitas’, kestabilan aplikasi, sistem update dan backup database, bug report, pemilihan komponen, dsb.

Seorang teman programmer mengatakan bahwa ia juga menerapkan semacam perhitungan untuk menentukan harga K. Dalam kasus ini, harga K ditentukan dari berapa lama ia melakukan eksplorasi untuk mendapatkan ide dan menguraikannya menjadi sebuah konsep aplikasi dengan kata lain K=Rk x Wk (rate programmer dikalikan jumlah waktu eksplorasi). Rumit? Mungkin terlihat rumit, tapi sekali lagi, di negara2 maju (kebetulan teman saya tersebut pernah bekerja di luar negeri dan baru kembali ke Indonesia), ini merupakan hal yang wajar dan bisa diterima oleh klien.

4. Prosentase Potongan Harga (d)
Mungkin terkesan aneh bila diterapkan potongan harga untuk sebuah aplikasi/proyek aplikasi. Akan tetapi hal ini perlu dipertimbangkan bila seorang programmer menghadapi kasus dimana calon klien merupakan sebuah perusahaan besar dan menurut perkiraan memungkinkan terbentuknya long term relationship dan kontinuitas proyek. Dengan menerapkan discount, programmer bisa memberi alasan “proyek perkenalan” dimana sebagai awal long term relationship, sebuah aplikasi yang bagus diberi harga yang relatif murah. Bila memang tidak mau, programmer bisa memberi harga 0 (nol) untuk variabel ini.

5. Harga Material Aplikasi (M)
Harga material aplikasi adalah total harga pengadaan material untuk pekerjaan aplikasi yang mencakup harga Komputer server, perangkat external, pembelian lisensi additional software, fee copywriting. dan lain2 sekarang mari kita lihat variabel mana yang nilainya bersifat fleksibel dan variabel mana yang bernilai tetap.

Harga W yang pasti nilainya bersifat fleksibel karena bergantung dari skala proyek aplikasi yang dikerjakan. Harga M juga bersifat fleksibel karena bergantung dari harga pihak ketiga yang menyediakan material aplikasi (copywriter, komputer sever, perangkat external, dsb). Harga d juga bersifat fleksibel seperti telah diuraikan di atas.

Harga konsep (K) juga bersifat fleksibel. Masalahnya sekarang adalah cara menentukan harga tersebut. Seperti telah diuraikan di atas, ada beberapa programmer yang menetapkan nilai K dengan rumus K=Rk x Wk. Tapi ada juga programmer yang menetapkan nilai K tanpa menguraikannya seperti itu. K adalah sebuah nilai yang mencakup seluruh hal mulai dari eksplorasi, ide, konsep, dsb. Semata-mata karena pertimbangan kemudahan. Sebenarnya keduanya sama saja, itu hanyalah cara programmer untuk memberikan argumen yang tepat untuk harga sebuah kreativitas.

Bagaimana dengan variabel R?

Ada dua fenomena menarik. Beberapa programmer (dan juga agensi aplikasi) mematok harga R tetap dengan alasan bahwa harga tersebut adalah standar profesionalisme mereka. programmer dengan harga R tinggi harus bisa bekerja dalam waktu yang lebih singkat dibandingkan programmer dengan harga R yang lebih rendah untuk sebuah hasil yang kualitasnya sama. Artinya klien yang menyewa programmer dengan R tinggi akan diuntungkan dengan waktu pengerjaan (W) yang lebih singkat/cepat bila dibandingkan dengan mempekerjakan programmer dengan harga R yang lebih rendah.

Disisi lain ada programmer yang lebih fleksibel dengan harga R yaitu dengan menentukan nilai R sesuai dengan kredibilitas ataupun skala perusahaan klien. Sebagai ilustrasi, programmer seperti ini memberikan nilai R yang tinggi kepada sebuah perusahaan multi-nasional yang memiliki aset milyaran dan memberi rate yang lebih rendah kepada perusahaan kecil berbudget rendah, misalnya.

Contoh berikut mungkin bisa lebih memperjelas:
Seorang programmer level menengah memberikan rate perhari sebesar Rp. 700.000/hari sesuai dengan skill, portfolio, pemahaman konsep dan pengalamannya kepada firma-hukum mid-size untuk mengerjakan Sistem ERP.

Struktur website tersebut adalah sebagai berikut:
Struktur tersebut akan diterapkan dalam halaman2 berbasis Client-Server dengan tambahan features backup, Checking Machine and Porchase or Request Order di frontpage-nya dan aplikasi send data via xml untuk update. Estimasi pengerjaannya adalah 10 hari. Tampilan user friendly, look and feel serta alur sistem aplikasi dari sebuah aplikasi yang akan dibuat sangat sesuai dengan corporate image dari firma-hukum tersebut yang dibuktikan dengan mock-up yang telah dibuat. Untuk itu si programmer memberikan harga Rp. 3.000.000. Entry data untuk aplikasi disediakan oleh client, sehingga harga material = 0 (nol). programmer tersebut memutuskan memberikan discount sebesar 10% dari harga total dengan pertimbangan akan terjalin long term relationship dimana firma hukum tersebut nantinya mungkin juga akan membuat aplikasi custommer service message, dsb.

Dalam kasus ini, harga penawaran adalah sebesar:

HT= (700.000 x 10) + 3.000.000 + 0= 10.000.000
HP= 10.000.000 – (10% x 10.000.000)= 9.000.000

Jadi, harga penawaran yang diajukan adalah sebesar Rp. 9.000.000. Bila ternyata calon klien melakukan bargaining, programmer bisa bertahan dengan memberikan argumen bahwa secara konsep, aplikasi tersebut sangat cocok dengan corporate image perusahaan atau effort yang dikeluarkan untuk pengerjaan proyek memang cukup besar.

Kemungkinan besar, calon klien akan bersikeras melakukan bargaining terhadap harga2 variabel2 tersebut. Disini, programmer bisa memperkecil harga penawaran dengan menurunkan harga rate per-hari menjadi Rp. 650.000 misalnya, sehingga manjadi:

HT= (650.000 x 10) + 3.000.000 + 0 = 9.500.000
HP= 9.500.000 – (10% x 9.500.000) = 8.550.000

atau memperbesar prosentase discount menjadi 15%:

HT= (700.000 x 10) + 3.000.000 + 0 = 10.000.000
HP= = 10.000.000 – (15% x 10.000.000) = 8.500.000

Dalam contoh tersebut bisa dilihat bahwa sang programmer melakukan bargaining dengan menerapkan harga R yang fleksibel dengan tidak mengurangi waktu pengerjaan (W) berdasarkan pertimbangan2 tertentu misalnya load pekerjaan yang tinggi, dsb. Sementara programmer yang menetapkan fix rate R bargaining mungkin bisa dilakukan dengan memberikan discount atau mengurangi waktu kerja (W)

Formula tersebut saya rasa cukup general dan bisa dipakai untuk menentukan harga pekerjaan aplikasi lainnya dan tidak terbatas hanya pekerjaan sistem aplikasi. Sebagai contoh misalnya adalah sistem informasi monitoring kegiatan dosen. Secara teknis pengerjaan poster tersebut mungkin bisa dikategorikan sebagai mudah dan dapat diselesaikan dalam 1 minggu saja. Akan tetapi dengan client sekelas Code Gear, programmer bisa menetapkan rate per-hari (R) yang cukup tinggi. Ditambah lagi dengan konsep aplikasi yang original dan brilyan yang dilengkapi dengan plugin “Everything That Has a Beginning Has an End” mungkin variabel K bisa dihargai jutaan dollar.

Formula tersebut saya rasa cukup general dan bisa dipakai untuk menentukan harga pekerjaan aplikasi lainnya dan tidak terbatas hanya pekerjaan sistem informasi. Sebagai contoh misalnya adalah sistem informasi monitoring kegiatan dosen di atas.

Secara teknis pengerjaan sistem informasi tersebut mungkin bisa dikategorikan sebagai mudah dan dapat diselesaikan dalam 1 minggu saja. Akan tetapi dengan client sekelas Code Gear, programmer bisa menetapkan rate per-hari (R) yang cukup tinggi. Ditambah lagi dengan konsep aplikasi yang original dan brilyan yang dilengkapi dengan plugin “Everything That Has a Beginning Has an End” mungkin variabel K bisa dihargai jutaan dollar.

Contoh diatas adalah dalam kasus programming atau design database dilakukan oleh satu orang programmer yang sama. Namun formula ini juga bisa diterapkan untuk pekerjaan dimana programming atau design database dilakukan oleh orang2 yang berbeda. Jadi bila sebuah sistem informasi misalnya menyangkut juga pembuatan basis-data, programming dan microsystem, harga penawaran adalah akumulasi dari harga yang diajukan tiap2 team member yang terlibat di dalam pekerjaan tersebut.

Formula di atas bukanlah sebuah hal mutlak. Mungkin ada beragam cara penentuan harga aplikasi yang lain. Ini hanyalah salah satu cara dan penerapannya juga kembali kepada programmer yang besangkutan. Satu hal yang pasti, formula ini juga tidak akan menjamin diperolehnya sebuah pekerjaan/proyek aplikasi? Harus dibedakan disini antara menentukan harga aplikasi dengan mendapatkan proyek aplikasi. Deal akan sebuah pekerjaan aplikasi bergantung dari banyak faktor lain seperti relasi, tipe client, budget, kualitas aplikasi, dsb. Tidak ada jaminan bahwa dengan menerapkan formula ini sebuah proyek aplikasi pasti akan diperoleh. Akan tetapi, minimal seorang programmer memiliki dasar untuk menentukan harga sebuah aplikasi dan tidak hanya bisa bergumam sambil berkeringat dingin bila sang klien mempertanyakan dasar penentuan harga aplikasi yang ia tawarkan.

Sumber : http://indocashregister.com/2008/12/03/bagaimana-menentukan-nilai-proyek-software-mesinkasir/

Tidak ada komentar: