Menentukan harga jasa untuk programmer dan desainer

Setelah pernah dibahas mengenai menentukan harga project TI khususnya mobile apps. yang ingin kita bahas adalah bagaimana menentukan harga jasa untuk programmer atau desainer mobile apps (mungkin bisa dipakai untuk developer software secara global)

Begini, akhir-akhir ini saya sering ditanya mahasiswa : “mas, bagaimana cara menentukan harga desain saya? saya ragu mau pasang harga”

Kalau menghendaki harga yang pantas dan ideal, itu subjektif, silahkan tentukan berdasarkan usaha yang akan dikeluarkan dan alokasi waktunya. Dan pasang harganya. Yang penting berani dan sudah mengukur sendiri harga yang pantas. Jangan sampai, kamu pasang harga 3 juta rupiah, namun, ternyata uang yang dikeluarkan untuk usaha begadang, internet dan ngemil serta ngopi sambil bekerja itu ngepas 3jt, atau mepet 3juta, alhasil tekor dan gak ada untungnya.

Namun, beberapa programmer/desainer software junior, masih bingung, harga jasa saya berapa?

Mari kita perhatikan 5 hal yang mempengaruhi harga jasa kamu di dunia software engineering sebagai berikut :

  1. Scope pekerjaan.
    Scope adalah segala hal yang ada di dalam produk software/produk dari project TI dan segala proses di dalamnya.
    Mendefinisikan apa yang diminta, apa yang mesti dikerjakan, dibagi step-stepnya (rencana->rancangan) sampe menjadi rangkaian berurut apa saja yang dikerjakan. Dengan demikian, dapat diestimasi jadwal dan waktu pengerjaannya.
    Contoh, ketika saya dari tidur pengen berangkat ke sekolah :

    1. Saya bangun tidur (15 menit), kemudian
    2. saya mandi (15 menit), kemudian
    3. saya sarapan (30 menit), kemudian
    4. saya berangkat ke sekolah (20 menit).
  2. Proses pengerjaan,
    Sulit kah? mudah kah? simple kah? kompleks kah?
    Terus bagaimana proses yang mesti saya ikuti? banyak kah? tentu mesti memperhatikan, jika ternyata proses untuk mengerjakan codingannya ataupun desainnya, bisa memakan waktu berjam-jam.
    Mulai dari :

    1. memahami klien kemudian menganalisis kehendak si klien;
    2. brainstorming, berguna untuk mendefinisikan semua kebutuhan biar bisa dikerjakan menjadi karya kita;
    3. inisialisasi, mulai dari kamu corat-coret desain/coba-coba code init/awal sampe jadi prototyping;
    4. prototyping, membuat karyamu sampe dengan prototype;
    5. development/design, mulai deh ngembangin sampe memroses semua kebutuhan menjadi produk
    6. revisi, mesti ketemu bagian ini, kadang ada saja bagian yang tidak sesuai kehendak klien, nah ini mesti diperhitungkan;
    7. final version, ketika sudah direvisi, dipoles, dibungkus, terus diserahin deh ke klien.

    panjang kan prosesnya? 😀 Makanya perlu diperhatiin betul, jangan sampe harga yang kamu pasang gak sesuai.
    Nah, ada beberapa hal itu bisa dikerjakan bebarengan, serentak (jika kamu ngerjainnya berdua atau lebih sama teman), tentu ada beberapa proses bisa dihemat waktunya. Coba lihat ilustrasi berikut :

    Critical Chain Project Schedule
    Critical Chain Project Schedule

    Kalo dilihat dari gambar di atas, tentu kita bisa memperkirakan, task apa saja yang bisa dikerjakan dalam 1 waktu bersamaan, dan mana yang tidak bisa. Jika tidak bisa, terus taruh di mana prosesnya..apa dikerjakan duluan, apa dikerjakan belakangan? tentu kalau ingin mengerjakan sesuatu, kerjakan dari yang paling mendasar.

  3. Standar harga per jam kerja (hourly rate)
    Kalo bagian ini, gak bisa sembarangan ditentuin. Kamu mesti sadari gaji/rate bayaran kamu berapa yang pernah kamu terima? terus itu dikerjakan berapa lama?
    Misal :
    Kamu pernah kerja 2 minggu (10 hari kerja, minus sabtu-minggu) dibayar Rp 3.000.000
    Sehari kerja dari jam 09:00 – 12:00, dilanjut ishoma, terus jam 13:00 – 16:00, berarti kalo ditotal : 6 jam kerja.
    Dan jika kita konversi menjadi perjam, rumusnya: Harga / total jam kerja / total hari
    Rp. 3.000.000 / 6 / 10 = Rp 50.000
    Berarti kamu dibayar Rp50.000,- per jam. Rate ini selalu naik seiring pengalaman, tentunya bila dinamika perubahannya naik, dalam artian, kamu sudah mengalami pengalaman yang banyak, yang dulunya sulit, jadi gampang, skill bertambah, dan beberapa project kamu jadi terbiasa garap (pengalaman). Semakin tinggi pengalaman, rate tentu semakin tinggi juga.
    Apalagi dibarengi skill yang makin tinggi pula (semakin banyak pengalaman, mestinya semakin beragam pula soft skill yang dikuasai). Bila kamu sudah 10 kali project dalam 2 tahun dengan hourly rate Rp 50.000,-… pas tahun ke-3, ya naikin lagi hourly rate jadi Rp 75.000,- atau Rp 100.000,-.Apalagi dalam 2 tahun itu kamu sudah belajar banyak, ditambah sekolah lagi, bisa berkali-kali lipat.Dan lagi-lagi, perhatiin juga standar gaji di dunia saat ini. (coba googling : salary guide [tahun], contoh : salary guide 2014, saya gak akan jelasin ini, cari di google dan baca sendiri sesuai posisi kamu di pekerjaan, bila orang kerja dibayar per bulan (20 hari kerja) sekian rupiah, tentu bisa dihitung per jamnya). Tentunya jika kamu di tahun kedua pernah mendapatkan proyek membuat sistem informasi perkantoran dengan harga Rp 60.000.000,-, kemudian di tahun ke empat jangan pasang 60jt lagi, tapi dinaikin. Berapa besar kenaikannya? kalau masih kesulitan menentukan, kembali ke pembahasan kita di atas yang baru kita bahas dan perhatikan di salary guide untuk profesi kita di tahun ke-4 besar gaji/rate-nya berapa.

    Berikut ini contoh hourly rate di beberapa negara

    Screen Shot 2017-03-31 at 2.21.26 PM

    Mahal ya? iya, di sana dihargai lebih. Kalo rate di atas diterapkan di indonesia, tentu gak pas 😀 makanya tadi saya sampaikan cek salary guide untuk Indonesia. Contohnya di sini: Salary Guide 2016. Cek profesimu sebagai developer apa. terus cek berapa tahun pengalaman kerjanya. Jika sudah dapat, ya tinggal konversi ke per jam.

  4. Investasi
    Seluruh hal yang berhubungan dengan proses yang dikerjakan di atas, dan biaya yang keluar karena hal tersebut. Seperti yang saya jelaskan di atas.

    1. Saya bangun tidur (15 menit) -> gratis
    2. saya mandi (15 menit) -> sabun : Rp 2000, sampoo Rp 1000, pasta gigi+sikat giginya : Rp 8000
    3. saya sarapan (30 menit) -> sarapan ketoprak : Rp 6000, jalan kaki ke TKP
    4. saya berangkat ke sekolah (20 menit) -> berangkat naik motor, bensin Rp 6500

    Terus, kalo ditotalin : makan waktu 1 jam 20 menit (1,33 jam), dan biaya : Rp 82.000 (2000+1000+….+6500)

    Rumusnya : hourly rate x total proses kerja
    Jadi, ketika hourly rate kamu Rp 50000, berarti :

    Rp 50000 x 1,33 jam + Rp 82.000 = Rp 148666,66 (mari kita bulatkan ke atas :p Rp 149000)

    Ya nilai dari project ini : Rp 149.000,-

    Contoh di atas mungkin sedikit membingungkan, pada intinya saja ya. Jadi kalau kamu dapat proyek dalam waktu 1 bulan, ya dikonversi saja dalam satuan hari. 1 bulan = 20 hari kerja, 1 hari = 8 jam kerja. 20*8=160 jam.

    Misal hourly rate kamu adalah Rp 250.000,- dengan pengalaman sudah 3 tahun. Ya untuk proyek dengan waktu 1 bulan…tinggal dikalikan saja: Rp 250.000*160 jam= Rp 40.000.000

    Nilai 40 juta ini bukanlah nilai mutlak, jadi ada nilai resiko juga di dalam proyek, nah ini kita bahas di poin nomor 5 di bawah.

  5. Resiko
    Segala hal tentu ada resiko, nah jangan sampe resiko ini terjadi dan menimpa kamu. Resiko mungkin bisa dihindari, tapi jika terjadi, pikirkan dampaknya dan apa antisipasinya.
    Resiko besar yang biasanya terjadi itu : project diberhentikan di tengah jalan (bahaya dong, ntar ketabrak), requirements berubah (nah ini dia yang biasanya bikin jengkel, udah bikin capek-capek, gak dipake, mesti diganti)
    Resiko kecil : perubahan minor aplikasi/software, jadi menyita waktu juga walaupun perubahannya dikit-dikit.
    Resiko juga mesti diklasifikasikan berdasarkan :

    1. kesempatan terjadi
    2. potensi yang diakibatkan (parah apa nggak?)
    3. kesulitan mendeteksi resiko supaya bisa dihindari

    Contoh : bugs di aplikasi
    Kesempatan terjadi : menengah lah, gak sedikit juga, gak banyak juga kesempatannya.
    Potensi yang diakibatkan : tinggi, kadang 1 bugs, bisa bikin aplikasi gagal jalan sebagaimana mestinya
    Kesulitan mendeteksi : tinggi, kadang bugs itu sulit banget dicari >.<

    contoh lain : server kebanjiran
    Kesempatan terjadi : kecil, ini sih kesempatan langka banget sampe-sampe server kebanjiran, kecuali kamu taruh servernya di pinggir kali ciliwung.
    Potensi yang diakibatkan : tinggi, server tenggelam, nangislah kliennya. Kamu juga mesti ikutan nangis!
    Kesulitan mendeteksi : kecil, lah wong hujan deres, knapa gak disingkirin tuh server ke tempat yang tinggi.

    Nah, resiko-resiko seperti ini yang mesti diperhitungkan. Terutama ya bayaran kamu. Misal kalo kejadian macem-macem, bayaran kamu telat, bagaimana?. Atau kamunya yang telat ngumpul kerjaan bagaimana?

    Dari sisi developer, pas di kontrak kerja, jangan lupa cantumkan aturan-aturan untuk klien (biasanya klien bikin aturan-aturan juga di poin proposal proyek (misal: apabila kamu telat mengumpulkan progress, atau progress tidak sesuai apa yang diharapkan klien, biasanya klien punya hak mengurangi harga proyek), nah, di sini kamu juga perlu membuat aturan-aturan atau klausa yang memperjelas batasan kamu selaku developer, misal: masalah konfigurasi server ataupun backend bukan tanggungjawab kamu yang seorang developer mobile app, masalah akun PlayStore tanggungjawab klien dan harus menggunakan data dari klien, atau apabila ada permintaan tambahan di luar scope pekerjaan yang telah disepakati, maka klien harus di-charge bayaran baru. Itu harus ada klause kerjasama tambahan yang menyatakan poin-poin apa saja tambahannya dan berapa besar biayanya. Nah yang model ini, developer sering luput, lalai, klien menghendaki revisi ini itu, tambahan ini-itu, tapi nilai proyeksi investasinya tetap. Jatuhnya kita yang rugi. 🙂
    Berikut ini ada gambar ilustrasi bagaimana harga sebuah proyek apabila dideliver ke klien lebih awal, tepat waktu atau terlambat. Dan berapa harga yang diharapkan. Dari sini bisa kamu kenali kalau untuk deliver sebuah progress pekerjaan ada resiko pinalty dari klien. Dan itu seharusnya kamu sudah antisipasi.

    Decision Trees
    Decision Trees

Sekian dulu yang dapat saya sampaikan, kurang lebih mohon maaf dan mohon dikoreksi 🙂

Terima kasih.

Pernyataan Jokowi soal “panggil programmer 2 minggu selesai” buat kalangan programmer melek dengan e-gov negeri sendiri

well, banyak sekali sisi positif gara-gara statement Jokowi “e-gov, panggil programmer 2 minggu selesai” di debat capres tempo hari. Di kaskus, facebook, twitter, berkumpul dan berdiskusi soal e-gov. Nama “programmer” pun jadi makin dikenal.

Namun, ada banyak gap yg terjadi di kalangan profesional TI, apalagi di kalangan fanatisme kedua kubu capres, akibat dari pernyataan Jokowi tersebut.

Sebagian kalangan mengkritik itu hanya bualan atau kalimat berlebihan dr seorang capres, krn sejatinya membangun sebuah aplikasi tidak hanya terkait programmer dan codingannya, tetapi ada metodologi dan tahapan pengembangan softwarenya, ditambah regulasi dan birokrasi dengan pihak pemerintah.

Namun sebagian kalangan menganggap ini tantangan besar buat indonesia, mereka menyadari bahwa e-gov tidak dikembangkan dalam satu malam, tp bertahun-tahun. Semua sudah jelas, apalagi untuk kalangan IT.

Korea saja misalnya, dr kuliah online pakar e-gov dengan judul “Ten Lessons from Korean Experiences of e-Government”, Professor Sang W. KIM, Ph.D. bilang kalau Pemerintah Korea telah melaksanakan secara berdampingan berbagai master plan, program dan proyek untuk menerapkan “masyarakat berorientasi informasi” secara nasional selama 20 tahun terakhir. Banyak project, dimulai dari 1987 (NBCN) sampai dengan e-gov nya mereka (2001-sekarang)

Di Indonesia sendiri, bbrp informasi yg sy dpt dr berbagai surat kabar online, menyebutkan sudah ada e-gov yang berhasil di beberapa daerah, di Jawa Timur (http://www.surabayapagi.com/index.php?read~Jawa-Timur-Terbaik-Kedua-di-Pemeringkatan-e-Gov-Indonesia). Berhasil di sini maksudnya sudah diuji secara teknis (aplikasi dan jaringan) dan tanggapan masyarakat.

Dan polemik di sini adalah e-gov yang sudah sukses tersebut tidak disosialisasikan oleh pemerintah pusat agar diterapkan di berbagai pemerintah daerah. Pemerintah tidak menjalankannya secara utuh. Alhasil, saat ini yang terjadi adalah tidak ada transparansi di kalangan pemerintah ke masyarakat. (mungkin ini yg dikhawatirkan bbrp elit politik, biar tidak ketahuan belangnya..makanya e-gov tdk dijalankan)

Kalo pak Jokowi memang pernah terlibat dlm pengembangan e-gov dan bilang “panggil programmer, 2 minggu selesai”, maka mungkin sebaiknya perlu diklarifikasi “selesai” di sini utk tahap apanya?  Karena beliau menyebut “programmer” bukan “vendor TI” maka mungkin bisa diasumsikan ini maksudnya “development-nya” (LOL) Drpd para simpatisan debat kusir dan para programmer berasumsi yg rumit-rumit.

Dan kembali lg ke topik yang disampaikan prof. Sang W. KIM, Ph.D, kalau Sistem Informasi tidak dibuat sekaligus, tapi bertahap. Dan suksesnya sebuah sistem informasi itu tidak ditentukan oleh ouput dari Sistem Informasi tersebut, tetapi hasilnya dapat dirasakan dan bermanfaat oleh pengguna. Manajemen data untuk mengelola atribut dalam e-gov harus lebih baik (Membangun Data Warehouse dari OLTP ke OLAP). Dan ini juga dipengaruhi bbrp domain sosial seperti Kepemimpinan (leadership), Strategi (strategi), Hukum & Peraturan (law & regulation) di pemerintah tersebut.

Menjadi suami seorang pekerja TI

Masa di mana suami jd spontan merenung itu ketika suami melihat istrinya sedang tidur.. Ada rasa bersyukur ada rasa bersalah…menyadari bahwa suami itu cenderung lebih egois. 

Ntah alasannya mencari nafkah, ia sudah merasa paling capek sendiri..selesai bekerja dgn penuh keringat, kadang mukanya kusut, ia pulang sudah dilayani istri spt tuan rumah. Namun istri tetap setia menanti dengan senang hati, menyambut suami dengan manja walau suami kusut, dan siap menjadi tempat berlabuh lelahnya suami.

Ntah alasan suami krn ia seorang developer, designer ataupun analis yg minta dimengerti kalau kerjaannya butuh konsentrasi tinggi berjam-jam kerja memperhatikan layar komputer bahkan seorang programmer yg asyik ngoding sampai “gak sengaja” overtime (lembur). Membuat suami jd lalai dengan kewajibannya.

Sudahkah jadi suami yg terbaik utk istri?
Nasehat yg datang dari orang tua dan dari dosen ketika di plurk yg slalu sy tanamkan dr sejak menikah ketika sy menulis status kesibukan saya di jejaring : “ingat, ada yang harus diperhatiin, sekarang bukan hidup sendiri lagi. Sesibuk apapun, keluarga nomor satu”

Suami ya jangan gila kerja, rezeki sudah diatur, waktu kerja yg normal jg sudah diatur Undang-undang.
Lakuinlah hal-hal ringan yg bisa membuat nyaman istri.
Ntah pulang langsung segera mandi, peluk cium istri dlm keadaan wangi. Menyuapi istri dikala makan bersama, berangkat ke masjid dengan boncengan sambil ngobrol ngalor-ngidul, nemenin istri belanja di pasar, dll. Bahkan kalau istri lg hamil yg tidak bisa aktifitas rumah tangga yang berat, suami siap mengemban pekerjaan rumah tangga sambil dengan cermat mensupport, memperhatikan pola makan dan istirahat istri.
Dan bukan hanya itu saja, keharmonisan memang slalu harus dijaga. Canda-tawa, tingkah lucu suami yg bisa membuat istri tersenyum tertawa..pulang kerja bukan membawa masalah kantor tapi membawa hal-hal lucu, romantisme…dan obrolan-obrolan ringan seputar kegiatan td pagi, obrolan soal tetangga, soal keadaan orang tua, dll. yg dapat membinasakan rasa kaku membisu yg bisa membuat problematika renggangnya hubungan rumah tangga.

Ada satu curhatan yg pernah terdengar…biasanya suami yg kerja di bidang TI, jam kerjanya tinggi per hari, istri bersyukur orang macem gini biasanya gk akan mungkin sempat selingkuh apalagi lirik cewek lain..(sempetnya selingkuh sm komputer), biasanya sih romantisnya garing hahaha…( tapi ya suami jangan egois) 

Kecocokan bisa dibentuk dan tersusun rapi dengan slalu terbuka berbagi cerita antara suami istri 

PS : kata2 ini sy dpt wkt denger ceramah di radio rodja, pengalaman pribadi, perkataan ortu dan dosen yg balas plurk saya.

6 pelajaran hidup yang dapat kita pelajari dari seni pemrograman

  1. Flow Chart sederhana adalah segalanya
    Sama halnya seperti seorang programmer, ketika kita dihadapi masalah besar, sebisa mungkin dipecahkan menjadi bagian-bagian terkecil, Baru dengan mudah kita dapat mengambil keputusan atas masalah tersebut.
  2. Setiap hal ada tempatnya.
    Selalu, ktika kita men-develop aplikasi, tentu di tahap awal kita menempatkan variable2 yang ingin kita pakai beserta tipe datanya (inisialisasi), begitu jg hal lain, slalu ada tempatnya, semua ada aturannya.
    Sama seperti kehidupan nyata, di mana letak tempat menaruh peralatan kerja, menaruh makanan, menaruh permasalahan kantor ya di kantor, bukan di rumah, dan sebagainya.
  3. Re-use/menggunakan kembali module yang sudah ada untuk menghemat waktu
    Setiap programmer yg baik akhirnya belajar bahwa ketika sudah membuat sebuah function ataupun module, dapat digunakan kembali untuk pengembangan aplikasi yang lain/berikutnya. Jadi menghemat waktu tentunya
    Henry Ford pernah berkata tentang Model T, “Setiap pelanggan dapat memiliki mobil dicat warna apa saja yang dia inginkan, asalkan itu hitam.”
    Alasan ini yang dipake Ford untuk merakit mobil dan membuat produk-produknya keluar pintu lebih cepat jika ia bisa menggunakan kembali peralatan yang sama (cat warna yg sama) tanpa harus menciptakan proses setiap kali mobil baru dibuat.
  4. Dokumen(tasi) adalah segalanya
    Kalo programmer yang “khilaf” 😐 dokumentasi itu malah diabaikan, atau malah dikerjakan pas aplikasi selesai 😐 sama aja boong :)) keasikan ngoding sih jadinya males, malah terkadang dianggap repot 😐 “gak ah, mending ngoding aja, ntar jg gampang diinget-inget, gak taunya mesti tracing code lagi”
    Sebenernya dokumentasi itu penting, dengan adanya dokumentasi, kita mencatat setiap hal yg kita perbuat dengan aplikasi itu, apa kesalahan dan perbaikannya, apa fungsi-fungsinya, dan tau tata letaknya, jadi mempermudah developer lain (berikutnya) untuk mengembangkan, dan bahkan bagi user.
    Sama seperti sehari-hari, terkadang jadwal penting, rutinitas sehari-hari, dan apa saja yang mesti dilakukan perlu dicatat di dalam sebuah catatan/agenda, memudahkan anda mengingat dan tidak tertinggal satu halpun.
  5. Jangan terjebak di satu situasi yang buruk.
    Ketika aplikasi mengalami looping gk berujung, process CPU jadi tinggi, dan tentunya si programmer harus mencari alternatif cara agar aplikasi berjalan lancar. Begitu jg dengan kehidupan nyata, ketika sudah merencanakan sesuatu, tau2 datang hal yg tidak diprediksi, satu2nya cara adalah menyiapkan “skenario terburuk” dari rencana itu, jadi tidak stuck di situ saja.
  6. Free Up Memory ketika kamu selesai.
    Kalo buat aplikasi, misal aplikasi Android, terapin masalah service, yang jelas setiap execute dalam durasi beberapa waktu, butuh free-up memory, agar app.tersebut tetap efisien ketika berjalan. Jika tidak, bakal makan banyak memory.
    Di kehidupan sehari-hari, sama juga, abis kerja, abis makan, cepetan diberesin dan dibersiin ruangannya, jangan sampe numpuk sampah, peralatan kerja berserakan, dsb. Malah buat aktifitas berikutnya jadi lambat.

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; 😀