Cara Mengukur Harga Project
adi sembiring
Kebetulan kami lagi buat tim untuk software development. Tapi kami sedikit kewalahan dibidang sizing project ini.
Saya mau nanya gimana cara menghitung harga project. kira-kira komponen komponen apa saja yang perlu di hitung.
kalau yang kami lakukan saat ini hanya berdasarkan mandays saja. misalkan lama pengerjaan project sekitara 60 hari kerja, tim di project itu ada 4 orang, katakan lah mandays per orang Rp. x.
berarti biaya project 60 * 4 * x.
Setelah dirimang-rimangi berdasarkan pengalaman:
- Biasanya mengerjakan project itu pasti harus ada profit untuk tim/perusahaan itu, soanya mandays itu hanya biaya operasional development project.
- Ketika project sudah live, pastinya ada garansi biasanya satu bulan jika ada problem di sitem yang sudah live. apakah biaya garansi ini dikenakan di biaya project juga, atau diberikan cuma2 ?
- pengalaman kami dalam satu project biasanya waktunya molor. biasanya karena client sibuk, ngga sempat SIT, atau UAT. atau terkadang ada project yang depend dengan project lain. ternyata project lain ini belum kelar2 juga. kita harus nunggu project lain ini kelar agar UAT bisa dilaksanakan. apakah ada hitung2an untuk waktu molor seperti ini ?
jadi kalau saya simpulkan total biaya project:
biaya operasional (total hari pengerjaan * jumlah orang * biaya mandays) + profit + biaya garansi + tolerance (project molor)
Tolong berikan saran dan tanggapan ya.
Salam,
Adi Sembiring
Hira Sirojudin
Dear Expert,
Kebetulan kami lagi buat tim untuk software development. Tapi kami sedikit kewalahan dibidang sizing project ini.
Saya mau nanya gimana cara menghitung harga project. kira-kira komponen komponen apa saja yang perlu di hitung.
kalau yang kami lakukan saat ini hanya berdasarkan mandays saja. misalkan lama pengerjaan project sekitara 60 hari kerja, tim di project itu ada 4 orang, katakan lah mandays per orang Rp. x.
berarti biaya project 60 * 4 * x.
Setelah dirimang-rimangi berdasarkan pengalaman:
- Biasanya mengerjakan project itu pasti harus ada profit untuk tim/perusahaan itu, soanya mandays itu hanya biaya operasional development project.
- Ketika project sudah live, pastinya ada garansi biasanya satu bulan jika ada problem di sitem yang sudah live. apakah biaya garansi ini dikenakan di biaya project juga, atau diberikan cuma2 ?
- pengalaman kami dalam satu project biasanya waktunya molor. biasanya karena client sibuk, ngga sempat SIT, atau UAT. atau terkadang ada project yang depend dengan project lain. ternyata project lain ini belum kelar2 juga. kita harus nunggu project lain ini kelar agar UAT bisa dilaksanakan. apakah ada hitung2an untuk waktu molor seperti ini ?
jadi kalau saya simpulkan total biaya project:
biaya operasional (total hari pengerjaan * jumlah orang * biaya mandays) + profit + biaya garansi + tolerance (project molor)
Tolong berikan saran dan tanggapan ya.
Salam,
Adi Sembiring
--
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.
--
Hira Sirojudin
adi sembiring
betul, semestinya perusahaanpun harus mendapatkan untung dari project. Mungkin pendeketan metoda sizing projectnya diubah bahwa yang disebut mandays itu bukan representasi dari resource kita bisa mengerjakan requirement X dalam sehari per orang, namun harus merupakan gabungan dari nilai biaya activity per orang dalam satu hari beserta nilai garansi qualitas aplikasi+dokumen+proses+bug free. Jadi yang menjadi tolak ukur adalah aktivitas (step-step yang dimulai dari studi kelayakan hingga test acceptance dan traning). Sebagai gambaran Fjts ID nilai manmonthnya ~4-5x biaya operasional realnya dan itu masih wajar, karena yang FID jual bukan hanya kepandaian kemampuan resourcenya dalam mengimplementasikan requirement namun juga unsur kualitas aplikasi,dokumen,proses, dan bugfree.
Kalau di analisis dari tanggapan Mas Hira, berarti:
- Profit tetap di hitung
- Mandays itu adalah biaya development (qualitas aplikasi+dokumen+proses+bug free)
-
asanya cost resiko ini bisa dimasukan dalam recovery cost, yaitu biaya tambahan untuk menutupi masalah-masalah dalam pengembangan yang bersifat non teknis, seperti molornya dev, spec berubah-ubah karena spec tidak detail dan beda persepsi atau miss, dll. Mungkin nilainya bisa mencapai hingga 20% dari biaya dev.
berarti dihitung juga biaya recovery cost itu ya mas. Oh ya .. gimana dengan biaya garansi fixing aplikasi, biasanya 1 bulan garansinya. setelah itu dikenakan ke biaya maintenance.
Apakah biaya garansi ada hitung2annya juga ?
Setelah buka arsip thread di milis ini, ada yang menanyakan hal yang mirip dengan yang saya tanyakan. Pak Endy bilang, ada cost buffer.
@pak Endy
apakah cost buffer ini sama dengan cost recovery seperti yang ditulis oleh pak hira.
Thanks buat sarannya,
Sangat bermanfaat sekali
Yusup Jauhari Shandi
--
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.
--
Trims,
.
ini menjadi dilema, kalau tidak diambil, proyek tidak ada,
kalau diambil dananya sangat2 minim.
bagaimana solusi teman2 menyikapi hal ini?
terima kasih
--
Yayang
Daud Mukadar
baru sadar saya selama ini juga cuman ngumpulin uang capek :D
ikutan nimbrung ya:
>> 1. apakah 'FAIR' pada saat menghitung biaya sebuah project pengembangan
>> aplikasi seperti yang diuraikan tadi untuk segala jenis proses development
>> aplikasi
sangat fair pak,
justru yg tidak fair, jika anda mengajukan harga terlalu murah, dan
akhirnya proyek gagal deliver karena faktor budget,
ya jelaskan saja budget berbanding lurus dengan jumlah SDM, waktu
berbanding terbalik dengan jumlah SDM
kalo mo cepet selesai, orangnya banyak, otomatis yg dibayar juga banyak.
dan IMO, proyek dapat benar2 ditekan budgetnya dengan:
1. menekan jumlah orang yg terlibat, tapi mesti realistis terhadap
waktu, jangan sis. inf rumah sakit modul lengkap, yg garap 3 orang
minta sebulan jadi.
2. sudah punya sistem serupa, tinggal custom aja
3. bener blank, baru garap sistem ini, gak tau perkiraan waktu
seberapa lama, biaya berapa, garap aja mumpung lagi kosong :D
kadang2 yg bikin lama juga kalo kita gak nguasain bisnis prosesnya si
klien, jadi belajarnya lama, untuk mempercepat kita mesti nyewa
konsultan, ini juga biaya tambahan (kecuali klien bisa nyediain free).
>> 2. Pengetahuan apa yang harus kita jelaskan kepada pihak client bahwa
>> sebuah sistem yang akan dibangun tidaklah murah
wah, kalo ini kayaknya sudah masuk separuh2 marketing :D
kalo di saya, rata2 klien yg saya temui memang tidak paham software
development, ada yg ngira kayak beli ms word, tinggal install pake.
perlu penjelasan bahwa sistem tidak sama dengan produk elektronik atau
property, jelaskan juga resiko dan tingkat kegagalan yg ada.
ya ceritakan saja panjang lebar dengan gaya bahasa menarik, bahwa
software adalah barang yg abstrak,
iya kalo beli martabak, nggak enak kan langsung kerasa.
nah, kalo software sebenernya bukan di murah mahalnya, tapi seberapa
nilai yg mo dibayar untuk kualitas dan menanggung kegagalan.
ceritakan saja kasus2 kegagalan proyek yg anda ketahui,
kebetulan ada beberapa klien saya yg datang menjelang deadline karena
programmer (perhatikan kambing hitamnya) sebelumnya wan prestasi,
3 bulan develop tanpa diawasi, tanpa ada tes macem2, seminggu kurang
dari bulan ke-3 ternyata yg jadi hanya form master.
ini masalah umum yg saya temui,
setelah saya jelasin panjang x lebar tentang bagaimana seharusnya
software development dijalankan (perlu lebih dari sekedar programmer,
hanya 1 pula). saya kasih beberapa indikasi proyek mengarah ke gagal
(programmer gak pernah kontak2 sekedar nanya proses atau say hi,
programmer gak bisa dikontak lebih dari 1 minggu -hp mati sms gak
bales, dll). Biasanya klien bisa nerima dengan baik, dan paham kalo
kemudian biaya development tidak semurah yg dikira di awal (ya kan
udah diceritain ada analis, programmer, tester dll).
>Misal hitung2an pihak developer adalah 30 juta, tapi alangkah kagetnya si client coz dia hanya menganggarkan 5 jt, dimana pada waktu sebelumnya >si client pernah dapet tawaran juga dari developer lain yg nilai projectnya sebesar 8 juta pun dia tolak.
Kalo si klien sudah "kepegang", coba nego untuk menaikkan budgetnya,
atau nego jumlah kerjaannya, misalnya dana itu untuk modul core saja,
lalu kerja sama dengan klien untuk menjadwalkan pembuatan modul
lainnya (dengan budget berbeda). kalo nggak ya tinggalkan saja kartu
nama, sudah dapat 1 link lagi :D
> ini menjadi dilema, kalau tidak diambil, proyek tidak ada,
> kalau diambil dananya sangat2 minim.
> bagaimana solusi teman2 menyikapi hal ini?
kalau nilainya gak sepadan usahanya, coba rekomendasikan klien
tersebut ke programmer2 one-man-show yg dikenal baik kualitas
kerjanya,
karena bergerak sendiri biasanya cost-nya lebih rendah dari pada yg rame2.
Timbal baliknya bisa berupa prosentase (lebih baik 20% dari pada nggak kan)
atau bisa juga berupa hubungan baik, satu saat mungkin tim kita diajak
mroyek bareng, who knows?
.daudmukadar
Hira Sirojudin
Ada masalah lain yang saya alami,
--
Hira Sirojudin
Yusup Jauhari Shandi
Angga Sanjaya Lingga
Saya pernah menemukan calon client yang minta dibuatkan aplikasi ecommerce seperti Bhinneka.com dengan harga 2.8 juta. Dan ada yang lain juga minta dibuatkan aplikasi yang fiturnya mirip Facebook dan Twitter dengan budget 1.5 juta.
Angga Sanjaya Lingga
M: +6281361534114
Endy Muhardin
> Ada masalah lain yang saya alami,
> mungkin ketika pihak developer tuntas menghitung total biaya dengan
> detail-detail seperti yang dikemukakan oleh rekan-rekan sebelumnya,
> tibalah pengajuan harga kepada pihak client. Misal hitung2an pihak developer
> adalah 30 juta, tapi alangkah kagetnya si client coz dia hanya menganggarkan
> 5 jt, dimana pada waktu sebelumnya si client pernah dapet tawaran juga dari
> developer lain yg nilai projectnya sebesar 8 juta pun dia tolak.
Beda tim, bisa beda hitungannya.
Kenapa begitu? Karena SOP tiap tim berbeda.
Contohnya, kita ada kerjaan bikin aplikasi ecommerce.
Kalo disuruh kerjain ke mahasiswa,
ya dia akan pikirin detail specnya sendiri,
desain database sendiri,
dites sekedarnya, kemudian dideliver.
Dengan SOP ala kadarnya seperti itu, ya hasilnya tidak konsisten.
Di project A mungkin dia sukses, di project B parah, di project C sedang2 saja.
Aplikasi ecommerce yang sama kita serahkan ke perusahaan sekelas Sigma
yang sudah pernah CMMI, pasti SOPnya beda.
Untuk aplikasi sekecil itu, mereka akan menurunkan tim lengkap, ada PM, ada BA,
ada Senior Programmer, ada Tester, orangnya beda semua,
walaupun mungkin dishare ke beberapa project.
Nah, tentunya costnya pasti bumi dan langit dibanding kerjaan mahasiswa.
Tapi hasilnya pun cenderung konsisten.
Project A ontime, project B overbudget 5%, project C delay 2%.
Tapi standar deviasi atau simpangan antar project tidak besar.
Konsistensi seperti ini penting untuk client yang projectnya gak cuma 1-2,
tapi ada terus sepanjang masa.
Nah, gimana kalo clientnya udah estimasi 5 juta, tapi Anda estimasi 30 juta?
Tandanya segmennya tidak sesuai.
Bergembiralah karena tim Anda sudah terlalu besar untuk project berskala 5 jt.
Ini makanya saya percaya, rejeki orang sudah ada masing-masing.
ArtiVisi misalnya, tentu tidak akan bisa ambil project ecommerce 5 jt itu.
Istilahnya, buat membiayai colo repository Git kita aja kurang.
Tapi ArtiVisi juga untuk saat ini belum mampu ngerjain aplikasi
akuntingnya Bank Indonesia seperti Sigma.
Karena project berskala seperti itu, gak cukup programmer, harus hire
politikus juga :D.
Ada artikel dan podcast bagus dari David Maister, konsultan manajemen
spesialis profesional (maksudnya firma hukum, akunting, dsb).
Judulnya Strategy Means Saying No.
Silahkan disimak.
http://davidmaister.com/articles/4/95/
http://davidmaister.com/podcasts/7/93/
Intinya, yang namanya strategi perusahaan itu, bukan cuma membuat
daftar apa yang ingin dikerjakan,
tapi juga meninggalkan apa yang tidak ada di daftar itu.
--
Endy Muhardin
http://endy.artivisi.com
Aditya Agustyana
Iya terkadang beberapa user yang akan jadi calon client kita selalu berpikiran dengan harga murah.
Saya pernah menemukan calon client yang minta dibuatkan aplikasi ecommerce seperti Bhinneka.com dengan harga 2.8 juta. Dan ada yang lain juga minta dibuatkan aplikasi yang fiturnya mirip Facebook dan Twitter dengan budget 1.5 juta.
kalo segmen pasar kita memang menembak kalangan kecil dan menengah, budget segitu sebetulnya masih bisa menguntungkan koq
kalo client butuh ecommerce ya kasih saja prestashop. opencart etc etc
untuk facebook clone bisa pakai elgg, dan twitter bisa pakai status.net
prinsipnya ada harga ada barang, yg penting sih dalam mengerjakan proyek jangan sampai "kerja bakti", dimana dapat proyek bukannya untung tapi malah merugi :)
--
profile : http://about.me/aditya.agustyana
ym / twitter : kirconboy
skype : adit_skype
Be Nice. Treat others with the same respect you'd want them to treat you. We're all here to learn together. Be tolerant of others who may not know everything you know. BRING YOUR SENSE OF HUMOR (stackoverflow.com)
Endy Muhardin
> Dear Expert,
>
> Kebetulan kami lagi buat tim untuk software development. Tapi kami sedikit
> kewalahan dibidang sizing project ini.
> Saya mau nanya gimana cara menghitung harga project. kira-kira komponen
> komponen apa saja yang perlu di hitung.
Karena kepanjangan di sini, saya tulis di blog aja ya.
http://endy.artivisi.com/blog/manajemen/estimasi-proyek-software/
Isaam Khalid
Untuk masalah project size dan effort, yang kami lakukan mirip dengan
yang Endy lakukan. Hanya saja untuk mekanisme pricing agak berbeda.
Saya ceritakan sedikit di sini. Untuk menyimpulkan price mandays, kita
perlu memperhatikan biaya overhead. Biaya gaji CEO, gaji
manager-manager lainya, biayar marketing, dan lain sebagainya.
Sederhananya, engineer yang "dijual" harus bisa membiayai tidak hanya
diri mereka sendiri, tetapi seluruh perusahaan. Setelah itu, baru ada
perhitungan keuntungan. Jika tidak begitu, project yang terlihat
profit jika dihitung biaya per-team, bisa menjadi rugi jika telah
dimasukkan biaya overhead.
Saya simulasikan penentuan harga mandays. Biaya di bawah
diperhitungkan untuk sebuah perusahaan yang misalnya mempunyai 20
orang engineer. Biaya total yang dibutuhkan untuk operasional setahun
adalah Rp 1.400.000.000.
Biaya Setahun : 1.400.000.000
Profit Diharapkan: 1.400.000.000 (harapanya keuntungan 100% dari
biaya/ 50% dari revenue).
Revenue Diharapkan : 2.800.000.000
Engineer : 20 orang.
Asumsi Hari Kerja Setahun : 240 hari
Harga Mandays = Revenue Diharapkan/(Engineer * Asumsi Hari Kerja Setahun)
Harga Mandays = Rp 583.333
Harga Mandays di atas sudah termasuk profit yang diharapkan. Hanya
saja, kita mungkin sulit untuk menjual 100% kapasitas perusahaan kita.
Karena kita tidak bisa menjamin bahwa akan selalu ada project yang
datang pada waktu yang tepat, dengan lama yang tepat dan jumlah
engineer yang tepat. Untuk mengatasi itu, diasumsikan kita hanya bisa
menjual 70% kapasitas kita.
Maka,
Harga Mandays = (100/70) * Rp 583.333
Harga Mandays = Rp 833.333
Dengan nilai ini, ketika sudah dapat nilai total mandays, tinggal
mengalikan dengan harga tersebut.
Prakteknya tidak sesederhana ini. Kita perlu membedakan pricing senior
dan junior engineer. Selain itu, kita juga bisa memiliki beberapa
pricing agar memudahkan negosiasi. Atau kita juga bisa menentukan
kapasitas yang bisa kita jual dengan lebih baik.
Semoga bermanfaat.
2011/5/11 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.
>
>
--
Isaam Khalid
PT AMN INDONESIA
http://www.amn.co.id
http://ublekutek.blogspot.com
sukamto
Powered by Telkomsel BlackBerry®
mila yuliani
iya soalnya yang terjadi jika kita berurusan dengan project
pemerintah, kita harus selalu waspada dengan nilai timeplan yang kita
berikan pada mereka. karena disaat mereka ngolor, atau kita yang
ngolor akibat UAT mereka yang kepanjangan.. biasanya mereka minta
finalty. gimana klo kasusnya seperti itu?
apa kita estimasikan nilai finalty di awal project ketika proses
pricing? sebagai bahan "wanti-wanti" hehehe..:)
Isaam Khalid
Masalah yang saya pahami berkaitan dengan sulitnya mekanisme yang
bapak jelaskan didasari oleh kesimpulan dari Pressman. Pressman di
dalam bukunya menyatakan "software is engineered, not manufactured".
Selama ini saya memikirkan apa bedanya engineered dan manufactured.
Saya baru paham ketika mengerjakan project software di sebuah pabrik.
Di sana terdapat divisi engineering dan production. Engineering
bekerja untuk menentukan bagaiamna cara membuat produk. Merekalah yang
menyimpulkan bagaimana produk akan dibuat, dan apa saja bahan-bahan
yang dibutuhkan. Lalu divisi production akan melaksanakan produksi
masal berdasarkan hasil kerja para engineer tadi.
Masalahnya di industri software, kita tidak pernah melakukan produksi.
Karena jika memang butuh produk yang identik, tinggal dikopi saja
filenya :). Sehingga setiap project software adalah proses
engineering. Tentunya kita mengembangkan software dengan SOP dan
tool-tool yang membantu. Tetapi tetap di beberapa proses terdapat
proses membuat sesuatu yang baru, yang belum kita buat sebelumnya.
Proses inilah yang akhirnya sulit diestimasi jika kita tidak memiliki
data. Apalagi dengan menyimpulkan beberapa koefisien seperti di teknik
sipil. Teknik Function Point Analysis, saya rasa ada karena
mengusahakan metode seperti ini.
Tetapi saya sangat setuju dengan Pak Sukamto, kita perlu adopsi teknik
dari bidang ilmu lain. Itu yang sedang kami usahakan. Namun belum bisa
sempurna seperti teknik sipil misalnya. Monggo sharing dengan lebih
rinci beserta contoh pak :).
Terima kasih.
2011/5/11 sukamto <abdulla...@gmail.com>:
Isaam Khalid
Masalah ini bisa diselesaikan dengan mekanisme Change Request. Memang
CR digunakan untuk mekanisme perubahan scope, tetapi bisa diadopsi
untuk perubahan jadwal.
Misalnya, kita menjadwalkan untuk UAT pada tanggal tertentu, dan kita
sudah siap pada tanggal tersebut. Lalu mereka tidak merasa siap karena
masalah internal mereka. Dibuat saja CR yang menyatakan hal ini dan
minta mereka menandatangani. Sampaikan saja bahwa ini penting karena
bagian dari SOP kita dan penting untuk dokumentasi project
keseluruhan.
Ketika ada masalah di tahap akhir karena keterlambatan, dokumen ini
bisa dijadikan acuan bahwa keterlambatan tersebut disebabkan bukan
oleh kita, tetapi oleh mereka.
Semoga bermanfaat.
2011/5/11 mila yuliani <dainy...@gmail.com>:
Daud Mukadar
rasakan sendiri kan? buat yg biasa mroyek,
berapa banyak dari teman2 di sini yg proyeknya bisa jalan pake metode waterfall?
saya kira sifatnya teknik sipil dan IT sangat berbeda, adhikarya gak
akan pernah diminta memindah lokasi jembatan setelah pondasi
terpasang.
atau developer rumah diminta memasang jendela besar di kamar mandi dan
setelah jadi stake holder meminta jendela tadi dihapus karena jelek.
pendekatan yg dipakai pak endy di artisi dan pak isam khalid saya kira
inspiratif dan bisa dicontoh (dikembangkan ?)
kalo masalah jadwal yg gak pasti, dulu di milis ini pernah dibahas
masalah tim, waktu kerja dan kalibrasi waktu, saya kira idealnya juga
seperti itu.
kalo semen kering bisa dihitung pake konstanta dan aksioma yg pasti,
hampir gak ada cara mengukur waktu kerja analis+programmer+tester
secara tepat. Joel Spolsky menyarankan pendekatan ala kalibrasi itu,
pake Evidence Based Scheduling, bisa baca di sini
http://www.joelonsoftware.com/items/2007/10/26.html
@mila
mbahas proyek pemerintah ya,
*ambil tiker, sama kacang*
saya ijin memantau saja
--mestinya dengan anggaran 9,7 M, waktu bisa diatur sih :D
.daudmukadar
Teguh Susanto
--
---------------------------------------------------------
Teguh Susanto
IT/SIM Staff
Jogja International Hospital
Jl.Ring Road Utara No. 160
Condong Catur,Depok,Sleman,Yogyakarta 55283
telp : 0274-4462879 ext 609
website : www.rs-jih.com
email : teg...@rs-jih.com
blog : medicalenvironment.blogspot.com
sukamto
mila yuliani
--
Isaam Khalid
Kalo itu sih berarti bukan masalah teknis. Tapi masalah building
relationship. Ini diskusinya lebih di ranah marketing :).
Sebetulnya kita bisa membangun hubungan baik dengan hal-hal kecil dan
tidak melanggar aturan agama (saya beragama Islam). Misalnya dengan
sesekali memberi hadiah, atau traktir makan. Perlakukan seperti teman
saja.
Tapi saya belum terlalu banyak pengalaman di pemerintahan. Kami masih
fokus di solusi bisnis.
2011/5/12 mila yuliani <dainy...@gmail.com>:
--
Abe
Menurut pendapat saya, kalo mo pake cara konvensional dan "aman" untuk
estimasi biaya project,
bisa dilakukan dengan cara me-refer kepada project2 sebelumnya ato
cari bandingannya dg project sejenis.
Dari project lama Anda ato project yg sudah pernah dilakukan oleh
perusahaan Anda, Anda bisa mengetahui
detil soal scope, planning, cost, risk, dll. Berdasarkan analisa
tersebut Anda bisa memperkirakan dan kemudian
menentukan estimasi biaya dan kapasitas project Anda.
Saran saya, jangan pernah mencoba "menurunkan" biaya dari estimasi yg
Anda dapatkan dari project sejenis
sebelumnya, kecuali Anda siap2 menanggung resiko u/ rugi ato
terjadinya pembengkakan biaya.
Dan menurut saya, IT project tidak bisa dibandingkan dengan civil
project karena lebih kompleks dan kadang2
hasil ato produknya tidak bisa "diukur" secara nyata.
Sekedar opini saja.
Salam,
~ab
On May 11, 7:02 pm, mila yuliani <dainyr.3...@gmail.com> wrote:
> Ikutan nimbrung,
>
> iya soalnya yang terjadi jika kita berurusan dengan project
> pemerintah, kita harus selalu waspada dengan nilai timeplan yang kita
> berikan pada mereka. karena disaat mereka ngolor, atau kita yang
> ngolor akibat UAT mereka yang kepanjangan.. biasanya mereka minta
> finalty. gimana klo kasusnya seperti itu?
>
> apa kita estimasikan nilai finalty di awal project ketika proses
> pricing? sebagai bahan "wanti-wanti" hehehe..:)
>
> >> 2011/5/9 adi sembiring <sembiring....@gmail.com>:
Endy Muhardin
> Mungkin sudah saatnya dunia TI mengadopsi ilmu dari teknik sipil. Di teknis sipil ada yg namanya analisa BOW. Disana diatur misalkan untuk pasangan dinding satu meter persegi koefisien tenaga kerja 0,2 pasir 0,3 sehingga untuk pekerjaan 5 meter persegi tinggal dikalikan koefisien dengan volume dan hg satuan untuk tenaga kerja. Mungkin para praktisi TI dan master master bisa merumuskan standar harga atau analisa harga tersebut yg bisa jadi acuan saat dapat pekerjaan khususnya dilingkungan pemerintah
>
Ada beberapa perbedaan mendasar yang menyebabkan kita tidak bisa
mengadopsi metode BOW.
Pertama, masalah bahan baku dan perangkat kerja.
Kalau kita bikin tembok, sudah pasti kita butuh bahan sbb :
- batu bata
- semen
- pasir
- besi 8
- besi 6
- kawat
Dan kita butuh tools sbb :
- ayakan pasir
- sendok semen
- meteran
- benang
- papan cor
- pendulum
- waterpass
Prosesnya sbb :
- aduk pasir semen dan air
- ukur-ukur pakai waterpass dan pendulum supaya temboknya tegak lurus
- pasang bata dengan adukan
- tunggu sampe kering
Dari sekian itu, variasinya sangat sedikit.
Semen semua sama, beda capnya doang, Holcim, Tiga Roda, dsb.
Cara pakai dan kualitas ya beti-lah (beda tipis)
Nah, coba kita bikin website DPR misalnya.
Ada yang kasi quotation 9.6 M, gak tau dibikin pake apa.
Tapi bisa juga kita kasi anak magang SMK, nanti dia customize Joomla
atau Wordpress.
Begitu go live, pasti tidak keliatan bedanya antara modifikasi Joomla
dan yang 9.6 M tadi.
Baik secara fungsi maupun kualitas.
Jadi, dari segi bahan baku dan proses, variasi di software lebih
banyak, sehingga tabel referensinya kalo mau dibuat, akan sangat besar
sekali.
Kedua, perkembangannya sangat cepat.
Kapan sih terakhir kali kita dengar Semen Tiga Roda nambah fitur?
Di dunia IT, pengetahuan teknis kita biasanya obsolete dalam waktu 3 - 6 bulan.
Nah, andaikata kita berhasil membuat tabel referensi di poin pertama tadi,
dalam waktu 6 bulan tabel berukuran besar tersebut harus dikalibrasi ulang.
Kalau tidak, maka tabelnya jadi gak valid, apa gunanya?
Ketiga, perbedaan produktivitas terlalu lebar.
Konon menurut penelitian, perbedaan produktivitas antara programmer
biasa dan super bisa mencapai 1 : 10.
Programmer jelek bahkan produktivitasnya minus, karena bukannya nambah
fitur, dia malah nambah bug :D
Ini tidak ada di teknik sipil. Gak ada tukang disuruh pasang bata
malahan ngebongkar bata.
Lalu, apakah sama sekali tidak bisa dibikin terstruktur?
Tentu bisa, asal kita mau membuat batasan-batasan.
Misalnya, kita batasi stack teknologi yang kita gunakan.
Di .NET misalnya, ini tidak sulit, cukup gunakan saja stack yang disediakan MS.
Tapi di Java atau PHP, nah ini butuh standarisasi tools dan framework,
karena pilihannya ribuan.
Teman saya yang project manager bilang, project .NET lebih mudah
dikelola, karena variannya relatif sedikit.
Sedangkan project Java, sulit diprediksi, karena ada banyak jalan menuju Roma.
Nah, kalo pilihan sudah dibatasi, kita baru bisa bikin tabel referensi
yang manageable.
Possible untuk dibuat, dan possible untuk dimaintain.
Tabel produktivitas juga bisa dibuat kalau orangnya dikit dan
terpantau dengan baik.
Demikian sekilas sharing
Hira Sirojudin
Mungkin sudah saatnya dunia TI mengadopsi ilmu dari teknik sipil. Di teknis sipil ada yg namanya analisa BOW. Disana diatur misalkan untuk pasangan dinding satu meter persegi koefisien tenaga kerja 0,2 pasir 0,3 sehingga untuk pekerjaan 5 meter persegi tinggal dikalikan koefisien dengan volume dan hg satuan untuk tenaga kerja. Mungkin para praktisi TI dan master master bisa merumuskan standar harga atau analisa harga tersebut yg bisa jadi acuan saat dapat pekerjaan khususnya dilingkungan pemerintah
--
Hira Sirojudin
Hira Sirojudin
--
Hira Sirojudin
Pratama Putra
Dear IT Expert