[Manajemen Proyek IT] Menetapkan harga project

[Muhammad Fauzil Haqqi]

Lama gak ada email baru dari milis ini nih. Jangan sampai mati donk, ayo diskusi lagi. Hehe

Lagi mencoba menjajaki jadi freelancer team, ada masalah yang biasa muncul di "pemain baru" seperti saya ini. Kalau ada kerjaan yang bersifat project base, pasti ada percakapan gini:

C (Clinet): Ada project nih... bla2...
T (Team): Hm, oke. requirement apa? waktu pengerjaan berapa lama? worth harga berapa?
C: Loe minta berapa lama? minta harga berapa?
T: (sigh)

Nah, di tahap itu, pasti para newbie seperti saya juga bingung. Kalo requirement jelas, dan waktu pengerjaan juga jelas, pasti masih mending lah dalam menentukan harga project. Kalo seperti ini, gimana? Lha waktu kita yang nawar, harga kita yang nawar. Gimana ya strateginya?

Thanks

--
HaQQi
YM: fauzil.haqqi
Skype: fauzil.haqqi
Twitter: http://www.twitter.com/haqqi
Site: http://www.fauzilhaqqi.net

[Azwar Akbar]

2010/6/30 Muhammad Fauzil Haqqi <fauzil...@gmail.com>

Lama gak ada email baru dari milis ini nih. Jangan sampai mati donk, ayo diskusi lagi. Hehe

Lagi mencoba menjajaki jadi freelancer team, ada masalah yang biasa muncul di "pemain baru" seperti saya ini. Kalau ada kerjaan yang bersifat project base, pasti ada percakapan gini:

C (Clinet): Ada project nih... bla2...
T (Team): Hm, oke. requirement apa? waktu pengerjaan berapa lama? worth harga berapa?
C: Loe minta berapa lama? minta harga berapa?
T: (sigh)

Nah, di tahap itu, pasti para newbie seperti saya juga bingung. Kalo requirement jelas, dan waktu pengerjaan juga jelas, pasti masih mending lah dalam menentukan harga project. Kalo seperti ini, gimana? Lha waktu kita yang nawar, harga kita yang nawar. Gimana ya strateginya?

Thanks

Saya coba ikut berpendapat ya, :)

Kalo dalam keadaannya seperti itu, saya lebih suka bertemu dulu dengan yang punya project secara langsung. Dari pertemuan itu kita diskusi, kita telusuri gambaran projectnya secara jelas, kita pancing-pancing dengan pertanyaan yang bisa merangsang dia buat njelasn lebih lengkap. Soalnya kalo dalam keadaan kaya gini, biasanya orang tsb agak susah mengungkapkan apa yg dia inginkan. Sebetulnya kita yang jadi sangat repot, mesti mancing2 dia buat njelasin projectnya secara rinci, dari situ kemudian kita dapat gambaran requirementnya. Kalo kira2 sanggup, resource yang dibutuhin terbayangkan dan estimasi waktunya juga terbayangkan, maka estimasi biaya bisa diprediksi. Untuk selanjutnya, kita tinggal hitung saja estimasi2 tersebut dengan metode perhitungan tertentu sesuai pilihan kita agar estimasi biayanya jadi lebih tepat.

Mungkin itu pendapat saya, mohon maaf kalo ada salah, saya sendiri masih belajar dan mencoba, kalo ada yang salah mohon dikoreksi. ;)

  

--
HaQQi
YM: fauzil.haqqi
Skype: fauzil.haqqi
Twitter: http://www.twitter.com/haqqi
Site: http://www.fauzilhaqqi.net

--
Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

--



regards,
Azwar Akbar
http://azwar-akbar.blogspot.com
http://azwar.crystalbamboo.com

[Muhammad Fauzil Haqqi]

Hm, bener memang. Itu kalau yang berurusan dengan kita bisa ditemui secara langsung. Tapi sekarang kan jamannya internet. Gimana kalau client itu cuma sekedar menghubungi kita lewat YM? Requirement lebih sulit untuk dipancing. Sementara kita nggak tahu scope project-nya seperti apa. sulit sekali menentukan berapa harga yang kita tawarkan. apalagi, sekali lagi, untuk "newbie" yang baru2 aja nerima project-an... hehe...

2010/6/30 Azwar Akbar <az...@crystalbamboo.com>

[Martinus Ady H]

Muhammad Fauzil Haqqi wrote:
> Hm, bener memang. Itu kalau yang berurusan dengan kita bisa ditemui secara
> langsung. Tapi sekarang kan jamannya internet. Gimana kalau client itu cuma
> sekedar menghubungi kita lewat YM? Requirement lebih sulit untuk dipancing.
> Sementara kita nggak tahu scope project-nya seperti apa. sulit sekali
> menentukan berapa harga yang kita tawarkan. apalagi, sekali lagi, untuk
> "newbie" yang baru2 aja nerima project-an... hehe...
>

Sekalipun lewat !YM harusnya ga masalah kan ? Asalkan bisa dipancing
*sedetail* mungkin kebutuhan si *client*. Mungkin gambarannya spt ini
kali ya :

&<-------------------------------------------------------------------->8
C: Eh ada project nih, kantor saya minta dibuatin aplikasi penjualan
nih. Kira-2x sanggup ngerjain brp lama dan harga brp?
T: Hm.. klo boleh tahu penjualannya ini penjualan apa ya pak?
C: Oh ini sederhana koq cuma penjualan barang2x elektro, yach sama spt
aplikasi2x penjualan yg lain gitu. Gampang kan ?

(jebakan 1 client biasa omong gampang2x aja, nah jangan termakan omongan
client disini. Anggap gampang klo kita emang bener2x paham ma bisnis
prosesnya)

T: Oh. penjualan barang elektro yah pak, ok deh sekarang kebijakan di
tempat bapak untuk harga jual per item gmn ya pak ?
C: Oh itu, gampang koq. Utk perhitungan harga jual kita sih pakai metode
rata-rata.
T: Oh rata-rata ya pak, ok deh klo begitu. Nah sekarang ini kan jualan
barang elektro yah pak, sedangkan kita tahu harga barang elektro itu
makin lama makin turun bukan naik. Nah masih mau pakai metode rata-rata
pak ?

C: Hm.. bentar deh klo gitu. Dipikir2x dulu
T: Ok deh pak klo gitu, silahkan di pikirkan dulu ama team bapak. Klo
sudah ok nanti kita ketemu lagi ya pak.
&<-------------------------------------------------------------------->8

Yach mungkin seperti diatas kali yah cara *mancing-mancing*-nya :) Ini
sih cuma sekedar asumsi *ngawur* yg ada di pikiran saya, meskipun
kenyataan-nya tidak se-indah mimpi :D

Mungkin ada teman-teman yg lebih tahu gmn cara yg *bener* :D Monggo di
share :D

--
Regards,

Martinus Ady H.

[Muhammad Fauzil Haqqi]

2010/6/30 Martinus Ady H <martin...@gmail.com>

Haha, iya banget. pasti tidak seindah mimpi.
 

Mungkin ada teman-teman yg lebih tahu gmn cara yg *bener* :D Monggo di share :D

--
Regards,

Martinus Ady H.

Btw, kan juga ada beberapa macam sumber project. Ada yang langsung dari client, ada yang dari broker, atau perantara lah. Kalau lewat client sih gak masalah. Bisa langsung pancing2 gitu. tinggal gimana tekniknya yang bisa dishare sama yang sudah ahli di sini :p

Masalahnya kalau kita dapet project dari broker, apalagi broker yang pelit yang nggak ngasih tahu siapa client-nya. Kalo gini, requirement pasti berubahnya nggak bisa dicontrol kita sendiri. ada pendapat?
 

--
Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

[Azwar Akbar]

2010/6/30 Muhammad Fauzil Haqqi <fauzil...@gmail.com>

Seandainya tetep bersedia ngambil project tersebut, bikin dulu batasannya, dan yang lebih penting adalah prototypenya, kalo prototypenya udah sesuai menurut mereka dan udah ditandatangani sama mereka(client), baru deh mulai diambil project tsb.

Betul banget, kadang client suka bilang: 'simpel aja kok aplikasinya, cuma gini gini gini' buat dia yang orang non IT mungkin simpel, nah disini kita jangan sampe terjebak dengan kata-kata "simpel". terkadang requirementnya malah mengembang dan bertambah. Untuk menghindari hal spt ini, prototype bisa digunakan sebagai salah satu cara. Jadi ketika prototype sudah ditandatangani, dan requirement specification udah ditandatangani, maka jangan lupa poin perjanjian yang intinya bahwa jika permintaan yang akan datang melebihi requirement dan tidak sesuai dengan prototype yg telah disepakati maka akan dikenakan biaya berdasarkan titik titik... (entah itu kompleksitas permintaan, waktu/resource yg dibituhkan atau yang lainnya).

Hati-hati saja dengan project seperti ini, kadang bisa jadi lobang jebakan, tapi tergantung kitanya juga ya, setiap orang pasti punya cara tersendiri dalam menangani.

Mohon maaf apabila ada yg salah, CMIIW.

Opini teman2 yang lain ditunggu... agar semakin menemukan jalan yang baik.. :)
 

 

--
Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

--
HaQQi
YM: fauzil.haqqi
Skype: fauzil.haqqi
Twitter: http://www.twitter.com/haqqi
Site: http://www.fauzilhaqqi.net

--

Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

--

[Fajar Sulaksono]

iys sering ngalamin ini calon client sering bilang
ini nih ada project "gampang kok" / "gak sulit kok" :D
hati-hati tu yg seperti itu, menurut saya sih imho di gali saja
requirementnya sedalam dan sedetail mungkin trus nanti
dibuat dokumen requirement yg di freeze/document sign-off
gitu

trims

[yayang...@gmail.com]

mumpung ada thread ini,
gimana cara menghadapi klien yang bilang "jangan mahal2 ya"
padahal belum fase requirement.
terus gimana cara menghadapinya ya??
mohon saran suhu :)

tq

2010/6/30 Fajar Sulaksono <fajar.s...@gmail.com>:

> --
> Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT"
> dari Grup Google.
> Untuk mengeposkan pesan ke grup ini, kirim email ke
> it-project...@googlegroups.com.
> Untuk berhenti berlangganan dari grup ini, kirim email ke
> it-project-indon...@googlegroups.com.
> Untuk opsi selengkapnya, kunjungi grup ini di
> http://groups.google.com/group/it-project-indonesia?hl=id.
>
>

--
Yayang

[Rizky Prihanto]

2010/6/30 <yayang...@gmail.com>

mumpung ada thread ini,
gimana cara menghadapi klien yang bilang "jangan mahal2 ya"
padahal belum fase requirement.
terus gimana cara menghadapinya ya??
mohon saran suhu :)

semua client tentu akan bilang gitu. itu prinsip dagang 101 dude...

dan untuk menyikapinya, kita juga perlu pake prinsip dagang juga.

kalo gw sih biasanya akan tanggapi gini:

C (client): jangan mahal-mahal ya?

Q (eRQee): so pasti brur... kalo di kita murah koq.

C : berapa?

Q : yaa kita pelajari dulu lah keperluan situ, ntar saya coba hitung2 dulu. kita juga nggak pengen cost membengkak koq. ntar saya bikin quotation-nya deh utk harga pas-nya.

intinya, 'kondisikan' supaya kita diberi kesempatan utk 'telaah' dulu keperluan dia.

termasuk dengan pas berhubungan dengan client yg ternyata broker. biasanya dia akan 'menghindar' kalo kita minta dia terlibat dalam fase requirement ke client "yg dia sembunyikan itu".

B (client padahal broker): requirement-nya biasa koq.. standar program2 POS lah..

Q : kalo "biasa" sih, biasanya kita pasang segini brur (langsung sebut nominal tinggi)

B : wakz!! apa nggak kemahalan tuh?

Q : nah itu dia makanya, gw mo tau dulu requirement loe dulu. siapatau nggak sekompleks apa yg biasa kami bikin. ada A, B, C, D, E, F, G, H (ngomong tinggi dihalalkan koq kalo dalam pembicaraan marketing)

B : kami sih perlunya A, B, C doank.

Q : ooh, cuman segitu yah. (usahakan ngomong kata "cuman"-nya itu diberikan intonasi berlebih). kalo gitu gw hitung2 dulu deh biayanya... tapi kalo ada perubahan requirement ente lo ya yg tanggung jawab. kita akan kenakan charge lagi.

di sini yg paling berperan adalah faktor PeDe -- selain pemahaman terhadap konteks bisnis tentunya. Perhatikan pedagang2 di Malioboro, mereka PeDe aja nawarin barang 100rebu padahal harga pokok-nya 10rebu. Dan bargaining position akan semakin kokoh kalo kita juga paham konteks bisnis yg sedang dihadapi. Misalnya si broker nawarin project Point of Sales, kita musti tunjukin kalo kita ngerti banyak Point of Sales.

Tapi kalo untuk newbie sih, kebanyakan 'aura' PeDe-nya masih kurang muncul. Orang2 yg udah lumayan jam terbangnya dalam hal negosiasi bisa mudah mengidentifikasi koq lawan bicaranya itu tergolong newbie ato enggak.

Tambah jam terbang. Sering baca2 buku akuntansi, hukum, pendidikan, ekonomi, perbankan sebagai selingan kita baca buku2 pemrograman. Trik paling mudah: ikutan milis-milis bisnis dan milis2 project management (seperti milis ini sih) -- walaupun jadi pendengar setia itu nggak apa2, yg penting wawasan nambah.

*tapi jangan lupa berkontribusi kalo udah expert yak? ^_^ karna katanya sih sedekah ilmu itu sama ganjarannya dengan sedekah uang. akan dibalas berlipat2 oleh Nya.

Rizky Prihanto
Information Systems Consultant | 0812 535 22 392 | http://rizky.prihanto.web.id

Sent from my Chromium© Browser, under Ubuntu© Lucid Lynx

[Didin Nurdin Ahmadi]

ngomong2 soal prototype, bagaimana sih cara membuat prototye yang baik? kadang bingung harus mulai dari mana. selain itu ketika memulainya bingung juga cara menyusunnya?

--
Kind Regards,

---
Didin

[yayang...@gmail.com]

hahahhaha
betul betul betullll
inspired banget,
saya coba di klien baru, mudah2 an cara ini ampuhhhh :)

thanks banget

2010/6/30 Rizky Prihanto <ri...@prihanto.web.id>:

[Endy Muhardin]

2010/6/30 Muhammad Fauzil Haqqi <fauzil...@gmail.com>:

>
> Nah, di tahap itu, pasti para newbie seperti saya juga bingung. Kalo
> requirement jelas, dan waktu pengerjaan juga jelas, pasti masih mending lah
> dalam menentukan harga project. Kalo seperti ini, gimana? Lha waktu kita
> yang nawar, harga kita yang nawar. Gimana ya strateginya?
>

Kalo saya sih, *selalu* minta daftar fitur.
Nanti kita akan bikin penawaran dan perjanjian based on daftar fitur itu.

Terima project tanpa daftar fitur yang definitif itu namanya bunuh
diri, jadi ya jangan dilakukan.

Dari daftar fitur, bisa dihitung berapa mandays, berapa days, dan
berapa rupiah.
Tanpa daftar fitur, ya gak bisa ngitung, mau tanya Mama Loren juga
udah gak bisa lagi.
:D

--
Endy Muhardin
http://endy.artivisi.com
Y! : endymuhardin
-- life learn contribute --

[Eko Kurniawan Khannedy]

Pada 1 Juli 2010 10:58, Endy Muhardin <endy.m...@gmail.com> menulis:

Tanpa daftar fitur, ya gak bisa ngitung, mau tanya Mama Loren juga
udah gak bisa lagi.
:D

masih ada ki joko bodo om :D

haha, sory ah oot :D

--
Eko Kurniawan Khannedy
Student of Indonesia Computer University
+6285292775999

[Fajar Sulaksono]

ini nih mas endy selau keren tips nya .. :D

On 7/1/2010 10:58 AM, Endy Muhardin wrote:
> 2010/6/30 Muhammad Fauzil Haqqi<fauzil...@gmail.com>:
>

[Azwar Akbar]

>
> ngomong2 soal prototype, bagaimana sih cara membuat prototye yang baik?
> kadang bingung harus mulai dari mana. selain itu ketika memulainya bingung
> juga cara menyusunnya?
>

Mengenai prototype yang baik, ada beberapa versi pendapat, bagi saya
prototype yang baik adalah yang benar2 mewakili gambaran fungsional
aplikasi, sesuai requirement/fitur aplikasi. Jika prototype menyimpang
dari apa yang sebenarnya akan dibuat, nantinya akan membuang waktu
pada tahap development. Hal yang perlu diperhatikan adalah, tetaplah
berkomunikasi dengan client ketika membuat prototype, hal ini
dilakukan untuk menghindari kesalahpahaman. Jika terjadi salah paham,
dan prototype tidak sesuai maka kita harus mengulanginya, lebih
parahnya lagi jika ketidaksesuaian ini baru diketahui pada saat
development... tentu saja ini akan menjadi urusan lain.. Masalahnya
kadang ada client yang ketika dibuatkan prorotype, dia kurang jeli
mengamatinya, hanya bisa mengangguk2 saja dan bilang "sip sip.. bagus,
kira-kira yang kami/saya inginkan seperti itu". Maka berhati2lah jika
terjadi hal semacam ini. "Paksa" client untuk benar2 mangamati, apakah
benar seperti itu yang diminta, atau seperti apa. Setelah selesai,
buat dokumentasi acceptance prototype tersebut untuk ditandatangani
oleh client sebagai simbol persetujuan dan komitmen bahwa aplikasi
yang akan dibuat adalah benar adanya seperti prototype yang telah
dibuat.

Mungkin seperti itu, mohon maaf jika ada yg salah.

> --
> Kind Regards,
>
> ---
> Didin
>

> --

[Azwar Akbar]

On 7/1/10, Fajar Sulaksono <fajar.s...@gmail.com> wrote:
> ini nih mas endy selau keren tips nya .. :D
>

mas endi, thread ini dibahas di blog dong... kaya requirement
development yang kemarin... nanti saya baca :)

> --
> Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT"
> dari Grup Google.
> Untuk mengeposkan pesan ke grup ini, kirim email ke
> it-project...@googlegroups.com.
> Untuk berhenti berlangganan dari grup ini, kirim email ke
> it-project-indon...@googlegroups.com.
> Untuk opsi selengkapnya, kunjungi grup ini di
> http://groups.google.com/group/it-project-indonesia?hl=id.
>
>

--

regards,

[Didin Nurdin Ahmadi]

--
Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

hm... sebenarnya saya masih bingung. ohhh jadi prototype yang dimaksd adalah sama seperti quotation ya?? ataukah sama dengan proposal penawaran?

maklum masih awam dalam management IT... tapi sangat membantu penjelasannya.. :-)

Suwun

[Ifnu bima]

tergantung processnya. yang sering saya jumpai prototype yg dimaksud
dilakukan setelah deal, kl sebelum quotation cm propodal penawaran dgm
daftar fitur aja.

--

regards

[Ifnu bima]

tergantung processnya. yang sering saya jumpai prototype yg dimaksud
dilakukan setelah deal, kl sebelum quotation cm propodal penawaran dgm
daftar fitur aja.

On Thursday, July 1, 2010, Didin Nurdin Ahmadi <didino...@gmail.com> wrote:
>
>

--

regards

[Endy Muhardin]

2010/7/1 Didin Nurdin Ahmadi <didino...@gmail.com>:

>
>
> hm... sebenarnya saya masih bingung. ohhh jadi prototype yang dimaksd adalah
> sama seperti quotation ya?? ataukah sama dengan proposal penawaran?
>
> maklum masih awam dalam management IT... tapi sangat membantu
> penjelasannya.. :-)
>

Ya jelas aja bingung, soalnya :
1. Anda melakukan thread-hijacking.
Ini kan threadnya sedang ngomongin penentuan penawaran harga.
Kok tiba2 Anda tanya prototyping.
Lho memangnya apa salahnya thread-hijacking?
Jawabnya ada di alasan #2, yaitu

2. Kalau pertanyaannya dijawab, maka konteksnya akan tercampur.
Anda akan dapat kesan bahwa prototyping ada hubungannya dengan penawaran harga.
Padahal tidak ada, penawaran ya penawaran, prototyping ya prototyping.

Nah, jadi saya jawab saja sesuai konteks penawaran harga.
Pada fase penawaran, jangan bikin prototype.
Kenapa?

1. Effortnya terlalu besar, padahal kita belum tentu dibayar.

2. Durasinya terlalu lama, sehingga tidak kunjung deal, tidak kunjung
ada agreement, dan tidak kunjung dibayar.
Padahal kita ke tempat (calon) client kan juga butuh ongkos

3. Membuat prototype = membuat user requirement.
Ini adalah proses intelektual yang butuh skill, knowledge, dan experience.
Sudah sepantasnya kegiatan ini dihargai dengan layak.

Di banyak project, ada yang memisahkan antara fase requirement dan
construction.
Pisah di sini maksudnya adalah dikerjakan oleh vendor berbeda.
Ini menegaskan bahwa prototyping itu adalah satu kegiatan yang layak dicharge.

Kembali lagi ke penawaran, cukup daftar fitur saja.
Contoh : calon client minta dibuatkan SMS Gateway.
Coba kita ajukan daftar fitur seperti ini :

1. Interfacing dengan GSM Modem melalui AT command
2. Interfacing dengan Operator menggunakan SMPP
3. Interfacing dengan Content Provider menggunakan SOAP (spec terlampir)
4. Support multiple gateway secara dinamis (ada add/remove gateway via UI web)
5. Prefix handling dengan customizable action, misalnya
kalau ada pesan REG MAMA akan direply dengan pesan
UnsupportedOperationException.
6. Bisa kirim/terima sms via web interface.

Nah, ini akan memaksa kita untuk mikir, berapa sih effortnya untuk
implement 6 fitur di atas.
Sehingga ada gambaran, berapa lama dan berapa rupiah.
Calon client juga bisa melihat apa ada kebutuhan dia yang belum
tercantum atau sebaliknya, apa ada fitur yang dia gak perlu.

Tidak perlu sampai prototype screen per screen.
Paling juga, kalau client gak yakin dengan kemampuan kita atau
arsitektur yang kita ajukan, kita bisa demokan aplikasi prakarya
dengan fitur minimalis. Misalnya, send sms via gsm modem, dirun dari
Netbeans menggunakan 1 main class saja.

Jadi, gimana cara bikin prototype yang baik?
Coba tanya lagi di thread baru, nanti saya jawab.

[Muhammad Fauzil Haqqi]

@bung Endy: nice. saya bingung kok tiba2 tercampur dengan prototype.

Balik ke masalah penentuan harga.
Buat yang sudah berpengalaman dalam mengerjakan project, apalagi project tersebut banyak yang sejenis, pasti nggak ngerasa kesulitan untuk menentukan harga setelah melakukan listing fitur (at least, tanpa requirement jelas). Tapi bagaimana buat yang masih newbie?

Ada beberapa cara sih, tapi ini hasil pemikiran sendiri, belum dicoba:
1. Cari-cari harga project sejenis di internet atau sesama pekerja project.
Ini cukup susah juga. Mengingat biasanya orang sangat rahasia terhadap harga project yang dia kerjakan. Selain itu, biasanya project yang benar-benar dibuat dalam bentuk project, bentuknya kemungkinan berbeda besar. Jadi tambah sulit.
2. Memancing client sendiri yang mengeluarkan range harga.
Ini butuh teknik social engineering. Kelemahan lainnya adalah kita nggak tahu range sebenarnya yang ada di pasaran.

Jadi, ada pendapat?

2010/7/1 Endy Muhardin <endy.m...@gmail.com>

--

Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

[Didin Nurdin Ahmadi]

Pada 1 Juli 2010 20:47, Endy Muhardin <endy.m...@gmail.com> menulis:

2010/7/1 Didin Nurdin Ahmadi <didino...@gmail.com>:

>
>
> hm... sebenarnya saya masih bingung. ohhh jadi prototype yang dimaksd adalah
> sama seperti quotation ya?? ataukah sama dengan proposal penawaran?
>
> maklum masih awam dalam management IT... tapi sangat membantu
> penjelasannya.. :-)
>

Ya jelas aja bingung, soalnya :
1. Anda melakukan thread-hijacking.
Ini kan threadnya sedang ngomongin penentuan penawaran harga.
Kok tiba2 Anda tanya prototyping.

wah maaf pak endy, saya pikir prototype tidak serumit itu...
ternyata prototyping berbeda dengan quotation..
mungkin memanag benar, harus ada thread khusus untuk membahas ini, OK pak... 

Nah, ini akan memaksa kita untuk mikir, berapa sih effortnya untuk
implement 6 fitur di atas.
Sehingga ada gambaran, berapa lama dan berapa rupiah.
Calon client juga bisa melihat apa ada kebutuhan dia yang belum
tercantum atau sebaliknya, apa ada fitur yang dia gak perlu.

Tidak perlu sampai prototype screen per screen.
Paling juga, kalau client gak yakin dengan kemampuan kita atau
arsitektur yang kita ajukan, kita bisa demokan aplikasi prakarya
dengan fitur minimalis. Misalnya, send sms via gsm modem, dirun dari
Netbeans menggunakan 1 main class saja.

 
oh ya..ya, saya faham pak, jadi yang paling penting dalam penetuan harga adalah informasi tentang fitur apa yang diinginkan oleh calon client.

[Ifnu bima]

penentuan harga itu butuh pengalaman, bukan masalah besar kecilnya
harga, tapi masalah menghitung biaya produksi, karena masih newbie
jadi blom tau kan biyaya produksimu berapa?

nah penentuan harga tentu saja harus dihitung tterhadap biaya
produksi. misalnya buat gaji diri sendiri dan karyawan 2 orang per
bulan total 15jt, durasi pengerjaan aplikasi 6 bulan. trus ditambah
biaya operasional kantor sebulan 2jt total 102jt nah keuntungan 30%
jadi 130jt tambah buffer kalo-kLo ditawar setengahnya jd total sekiyar
200jt.

--

regards

[Endy Muhardin]

2010/7/1 Muhammad Fauzil Haqqi <fauzil...@gmail.com>:

> @bung Endy: nice. saya bingung kok tiba2 tercampur dengan prototype.
>
> Balik ke masalah penentuan harga.
> Buat yang sudah berpengalaman dalam mengerjakan project, apalagi project
> tersebut banyak yang sejenis, pasti nggak ngerasa kesulitan untuk menentukan
> harga setelah melakukan listing fitur (at least, tanpa requirement jelas).
> Tapi bagaimana buat yang masih newbie?

Penentuan harga itu memang butuh experience.
Tidak ada jalan pintas, memang harus sering latihan.

Bikin daftar fitur juga butuh latihan. Contohnya, bikin aplikasi minimarket.

Daftar fitur newbie akan tampak seperti ini :
- CRUD master produk
- Entri penjualan (mungkin pakai barcode)
- Laporan penjualan

Daftar fitur orang yang pengalaman, bisa jadi seperti ini :
- CRUD master produk
- Entri penjualan (mungkin pakai barcode)
- Laporan penjualan
- CRUD User
- CRUD Permission
- Sinkronisasi dengan kantor pusat
- Backup & Restore tools
- Tools untuk import data produk dari excel file
- Laporan stok
- Stok Opname (koreksi stok)
- Entri void (gak jadi beli)
- Entri retur (udah beli tapi dikembalikan)
- Laporan void
- Laporan retur
- Pembayaran non tunai

Wah kok jadi banyak fiturnya?
Ya karena udah pengalaman bikin dengan daftar fiturnye newbie,
ternyata clientnya merasa kurang.
Tentu saja, karena bisnis gak bisa jalan tanpa stok, void, dan retur.
Ini adalah fitur mandatory yang seringkali gak disebutkan calon
client, entah karena dia sendiri belum sadar kalo dia perlu, atau dia
asumsikan kita sebagai konsultan udah tau kalo itu adalah fitur
standar.

>
> Ada beberapa cara sih, tapi ini hasil pemikiran sendiri, belum dicoba:
> 1. Cari-cari harga project sejenis di internet atau sesama pekerja project.
> Ini cukup susah juga. Mengingat biasanya orang sangat rahasia terhadap harga
> project yang dia kerjakan. Selain itu, biasanya project yang benar-benar
> dibuat dalam bentuk project, bentuknya kemungkinan berbeda besar. Jadi
> tambah sulit.

Walaupun tau harga project orang lain, tetap aja gak relevan.
Misalnya, bikin aplikasi kasir di atas, harga ArtiVisi dengan harga
vendor besar seperti Sigma atau Jatis pasti beda.
Walaupun aplikasi yang dibikin sama persis.
Lalu apakah saya bisa pasang harganya Sigma di quotation ArtiVisi?
Belum tentu.
Atau sebaliknya, apakah Sigma bisa pasang harga ArtiVisi di quotation mereka?
Ya belum tentu juga.

> 2. Memancing client sendiri yang mengeluarkan range harga.
> Ini butuh teknik social engineering. Kelemahan lainnya adalah kita nggak
> tahu range sebenarnya yang ada di pasaran.
>

Intinya sih, penentuan harga itu ada dua pendekatan :
1. Cost plus.
Biaya kita berapa, tambahin profit, itulah harganya.

2. Perceived value
Kita perkirakan kira2 market mau bayar berapa untuk produk kita, lalu
charge segitu.

Yang jelas, harus tau dulu bottom-line nya (biaya modalnya).
Kalo udah tau, terserah mau pakai pendekatan yang mana.

[Martinus Johan Wahyudi]

Klo boleh saya simpulkan:
1. Untuk memastikan anda sanggup untuk menerima sebuah proyek, anda harus punya pengetahuan yang cukup mengenai bisnis proses klien anda. jgn sekali-sekali mengiyakan, karena semata-mata anda merasa tahu.
2. jangan meremehkan semua modul yang ada, meskipun semua modul mungkin berupa entry. tapi hampir 100% proyek IT indonesia berupa data entry.
3. pastikan klien anda memahami bahwa Proyek IT bisa mahal, karena risiko IT yang fragile.
4. Jgn buat prototype di awal (ini saya amini) penawaran, karena makan waktu. kecuali anda sudah punya demo-demo aplikasi.
5. Memang sebaiknya anda jgn terjun langsung ke sebuah proyek klo memang newbie (karena pasti bakal sakit hati, pengalaman pribadi), mending magang dulu ke para suhu yg telah ada.

2010/7/1 Endy Muhardin <endy.m...@gmail.com>

--
Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

--
Sincerely,
Martinus J Wahyudi
Software Engineer

[Ramlan Maulana]

Wah... masukan yang bisa saya serap ini, terimakasih atas tulisannya meskipun itu bukan secara pribadi untuk saya, tapi saya yang membaca merasa ini masukan yang sangat bagus, terimakasih pak Martinus :)

[Muhammad Fauzil Haqqi]

Balik ke gimana menentukan harga project. Langsung ambil kasus saja. Ambil contoh untuk project website.
Saya kepikiran untuk menentukan harga berdasarkan berapa halaman/template yang harus dibuat untuk website itu.
Katakanlah tiap page adalah 750rb. Kalau request client ada 10 page, berarti 750rb.

Tapi, waktu di tengah2 pengerjaan, jumlah page pasti berubah. kalau jadi kurang sih nggak masalah, kita untung. kalo ternyata nambah, dan itu banyak gimana? sementara biasanya kontrak harga kan sudah disepakati di awal...

2010/7/3 Ramlan Maulana <iam.r...@gmail.com>

--
Haqqi
YM: fauzil.haqqi
Twitter: http://www.twitter.com/haqqi
Site: http://fauzilhaqqi.net

[Eko Kurniawan Khannedy]

Pada 8 Juli 2010 22:59, Muhammad Fauzil Haqqi <fauzil...@gmail.com> menulis:

Balik ke gimana menentukan harga project. Langsung ambil kasus saja. Ambil contoh untuk project website.
Saya kepikiran untuk menentukan harga berdasarkan berapa halaman/template yang harus dibuat untuk website itu.
Katakanlah tiap page adalah 750rb. Kalau request client ada 10 page, berarti 750rb.

Tapi, waktu di tengah2 pengerjaan, jumlah page pasti berubah. kalau jadi kurang sih nggak masalah, kita untung. kalo ternyata nambah, dan itu banyak gimana? sementara biasanya kontrak harga kan sudah disepakati di awal...

kalo bisa kesepakatannya dari awal, Project sudah Deal, tidak ada yang akan berubah, jika tiba2 projectnya berubah, contoh yang nambah halaman itu, ya pasti harga berubah. itu sudah resiko si klien.

 

[Wisnu Manupraba]

2010/7/9 Eko Kurniawan Khannedy <echo.k...@gmail.com>

harusnya dan idealnya seperti itu
tapi kadang-kadang si kliennya minta dalam bentuk getlment aggrement, kadang juga dananya udah abis, tapi fitur itu dibutuhin.

kalau aku seringnya ga serta merta bilang ya atau tidak, tapi evaluasi dulu khususnya dari biaya sebenarnya masih ada kelebihan buffer atau tidak, kalau ada dan dianggap mencukupi ya sudah dikerjakan saja anggap service lebih ke klien, nanti di charge di project berikutnya (selalu berposifit thinking si klien bakal repeat order) tapi kalau benar-benar ga bisa ya sudah dikomunikasikan ke klien.

mangkanya pas nentuin harga usahakan ada buffer yang cukup bahkan besar, kalau aku minimal keuntungan 30% dari total project.
 

--
Eko Kurniawan Khannedy
Student of Indonesia Computer University
+6285292775999

--

Anda menerima pesan ini karena Anda berlangganan grup "Manajemen Proyek IT" dari Grup Google.
Untuk mengeposkan pesan ke grup ini, kirim email ke it-project...@googlegroups.com.
Untuk berhenti berlangganan dari grup ini, kirim email ke it-project-indon...@googlegroups.com.
Untuk opsi selengkapnya, kunjungi grup ini di http://groups.google.com/group/it-project-indonesia?hl=id.

--
Wisnu Manupraba
CEO of Javan IT Services
Mobile : 081321965086
Email  : wi...@javan.co.id
YM     : wisnumanupraba
Website: http://www.javan.co.id

[Ifnu bima]

Client indonesia biasanya tidak mau tandangtangan project yang
mempunyai ukuran kuantitatif yang rigid, misalnya web dengan 100
halaman. Biasanya yang ada di dalam proposal dan surat perintah kerja
adalah daftar feature. Setiap feature dalam web diterangkan dengan
cukup mendetail apa saja yang akan diimplementasikan, tetapi tidak ada
batasan berapa page.

Kemudian di sisi konsultanya, penentuan harga selalu memperhitungkan
30% keuntungan dan buffer. Misalnya total biaya produksi 5jt ya harga
6,5jt ditambah buffer, misalnya 30% juga, total harganya bisa di
kisaran 8 jt.

Jadi yang penting dihitung itu adalah biaya produksi dan standard
mandays. Km harus bisa memperkirakan berapa hari kerja per programmer
yang harus diluangkan untuk menyelesaikan project. setelah itu harus
ada kalkulasi keuntungan dan buffer.

Poin yang harus diperhatikan ketika ada perubahan adalah km harus
bikin change request, user harus aware bahwa ini adalah tambahan
pekerjaan diluar perjanjian, walaupun pada akhirnya tidak ada tambahan
charge dari change request itu client harus tetap tahu bahwa ini
tambahan pekerjaan yang kita lakukan diluar kontrak kerja. Apa
gunanya? seperti wisnu bilang, kita bisa charge di project berikutnya
dan client biasanya tidak keberatan karena sudah tahu dan aware bahwa
di project ini ada tambahan pekerjaan di luar perjanjian yang user
tidak bayar.

--

regards

[Martinus Johan Wahyudi]

wah blom jadi PM kok dah salah itung tho mas..750rb, 10 page = 10x750= 7.500

wakakakakakak..sorry..lanjutin diskusinya.. (jadi OOT)

klo page @7

2010/7/8 Muhammad Fauzil Haqqi <fauzil...@gmail.com>

Balik ke gimana menentukan harga project. Langsung ambil kasus saja. Ambil contoh untuk project website.
Saya kepikiran untuk menentukan harga berdasarkan berapa halaman/template yang harus dibuat untuk website itu.
Katakanlah tiap page adalah 750rb. Kalau request client ada 10 page, berarti 750rb.

Tapi, waktu di tengah2 pengerjaan, jumlah page pasti berubah. kalau jadi kurang sih nggak masalah, kita untung. kalo ternyata nambah, dan itu banyak gimana? sementara biasanya kontrak harga kan sudah disepakati di awal...

[Muhammad Fauzil Haqqi]

Ah iya, salah ketik. Gila aja 1 page 750rb.. Wkwk..

[Muhammad Fauzil Haqqi]

Tiba-tiba kepikiran, masalah harga project.

Dari tahap yang saya pikirkan, tahap requirement development ini bisa cukup menguras waktu dan pikiran. Tentunya ini harus dimasukkan dalam pembiayaan. Di sini yang saya bingung, seperti lingkaran setan.

Pada awal kontak dengan client, kita biasanya diminta untuk mengestimasi berapa harganya. Sementara, kita nggak bisa tahu berapa detailnya sebelum requirement development. Terus, bagaimana bisa deal? Ini juga berkaitan bagaimana proses deal dengan client.

Jika memang deal, berarti dengan estimasi biaya yang tidak jelas.
Jika tidak deal, betapa bodohnya menolak rejeki. :p

Setelah requirement development jadi, pasti bisa menentukan harga fix project. Di situ pasti ada sisi bimbang client yang muncul. Kalau ternyata harga lebih tinggi dari estimasi awal, apa bisa batal kontrak (eh, kontrak udah dibikin atau belum ya?). Kalau ternyata lanjut sih gak masalah. Tinggal menentukan kapan bayarnya.

Apa mungkin kalau di tahap pembayaran itu ada pembayaran awal untuk requirement development?


*maaf agak ruwet ngomongnya, saya juga bingung flow-nya*

2010/7/10 Muhammad Fauzil Haqqi <fauzil...@gmail.com>

[Endy Muhardin]

2010/8/23 Muhammad Fauzil Haqqi <fauzil...@gmail.com>:

> Tiba-tiba kepikiran, masalah harga project.
>
> Dari tahap yang saya pikirkan, tahap requirement development ini bisa cukup
> menguras waktu dan pikiran. Tentunya ini harus dimasukkan dalam pembiayaan.
> Di sini yang saya bingung, seperti lingkaran setan.
>
> Pada awal kontak dengan client, kita biasanya diminta untuk mengestimasi
> berapa harganya. Sementara, kita nggak bisa tahu berapa detailnya sebelum
> requirement development. Terus, bagaimana bisa deal? Ini juga berkaitan
> bagaimana proses deal dengan client.

Ada 2 jenis project :
1. project yang requirementnya cenderung stabil
2. project yang requirementnya cenderung bergeser.

Contoh #1 : project yang melibatkan ISO-8583 atau web services.
Spesifikasi protokol sudah ditentukan di awal, dan biasanya jarang bergeser.

Contoh #2 : aplikasi bisnis seperti akunting
Bilangnya GL ternyata ERP.

Untuk yang #1, harusnya gak ada masalah.
Estimasi aja seperti biasa, harusnya gak meleset jauh.

Untuk yang #2, idealnya pisahkan menjadi 2 project dan 2 quotation :
1. Project Requirement Gathering, charge per mandays.
Sekali datang sekian Rp.
Biaya pembuatan spec per fitur sekian Rp.
Jadi kalopun GL ternyata ERP, no problem, karena bayarnya per hari/jam

2. Setelah requirement firm, baru keluarkan quotation Development.
Ini harusnya gak meleset jauh juga, asal change management-nya bagus.
Tiap perubahan, harus jelas berapa tambahan mandays dan Rp nya.

Teknik splitting ini sulit diterapkan kalo perusahaannya belum punya
track record yang bagus.

Solusi lain ya, lakukan assessment sampe ke daftar fitur.
Pasang buffer yang besar, dan
setelah deal berlakukan change management yang ketat biar gak
kebobolan di belakang.