RSS

Tag Archives: harga

Project Hunter wanna be

Kemarin ada teman yang berdiskusi mengenai proyek, teman saya ini dari pegawai kantoran yang akhirnya berhenti dan memilih membangun usaha sendiri dan menjadi project-hunter.
Diskusi panjang lebar.. hingga 2 hari tetap dilanjut dari chat sampai telpon.
Dari diskusi ini saya mendapati beberapa yang mesti dikoreksi, dan smoga menjadi pelajaran bersama..

  1. Jangan pernah membawa perkara teknis pengembangan ke klien (apalagi kalau kliennya gaptek). Cukuplah internal saja yang mengetahui perkara teknisnya bagaimana. Kecuali, si klien memang punya tim engineer yang bakal turut campur di dalam proyek ini, dan mereka harus mengetahui hal tersebut atau emang si klien mengerti soal teknologi dan ingin mengetahui teknologi apa yang nantinya diterapkan di produk software yang ia minta, dan biasanya si klien duluan yang buka omongan teknis, ya kita sebagai vendor TI menjawab pertanyaan tersebut dengan baik dan benar.
    Terkadang salahnya di sini, pas meeting, kita yang merasa sudah jago develop aplikasi. malah menyampaikan hal-hal teknis dari A sampai Z di software yang ingin ia bangun, kalau yang seperti ini yang ada klien cm “angguk-angguk” padahal ya bingung (masuk kuping kanan keluar kuping kiri). Kesan ke kliennya tidak kita dapatkan sama sekali, malahan maksud hati ingin meyakinkan klien dengan cara menjelaskan teknis pengembangan, mulai dari bikin flow diagram/flowchart, bikin pake framework apa, codenya seperti apa, versi berapa, terus nanti pakai web service apa, dan lain-lain, eh malah tidak berkesan.
    Ada baiknya sampaikan presentasi yang bagus dalam bentuk gambar, flow aplikasinya sudah dlm bentuk tampilan antarmuka software, dan kita jelaskan tiap step-nya dari login sampe logout di gambar tampilan antarmuka tersebut, sehingga si klien sudah dapat gambaran, seperti apa nantinya tampilan software tersebut, dan ini lebih meyakinkan daripada kita bawa-bawa hal teknis pengembangan. Dan di situ juga diharapkan klien memberi feedback, kira-kira dari gambar yang disajikan adakah yang kurang pas menurut pengguna, misal warna, susunan menu, dan sebagainya. Atau syukur-syukur kita sudah punya contoh dari prototype/portofolio yang kita punya.
  2. Kebanyakan klien tidak mengetahui apa yang mereka butuhkan, mereka mengikuti trend atau dari apa yang ia ketahui saja. Misal : dia tau Windows itu mudah dipakai, karena memang ia taunya cuma OS itu, dan belum coba Linux atau OSX. Ketika dikasih lihat Linux, mereka bingung, belum terbiasa. Nah sama kasusnya ketika disuruh memilih server, kita menyarankan menggunakan Linux CentOS, si klien lebih memilih OS Windows 10, padahal kebutuhannya si klien ini tidak cocok diimplementasikan di OS tersebut. (ini cuma contoh kecil, ada banyak lagi contoh lain, seperti keinginan klien supaya tampilan softwarenya seperti Facebook, ingin akses message-nya secepat Whatsapp/telegram, padahal si klien belum memahami kebutuhannya seperti apa, ketersediaan resourcenya bagaimana, budgetnya seberapa, jatuhnya kebanyakan keinginan yang tidak tepat sasaran)
    Maka dari itu, coba tawarkan solusi alternatif, misal ketika kita mendapat order membuat aplikasi mobile. untuk broadcast SMS, coba tawarkan alternatif, tulis di proposal dan ketika meeting, sampaikan yg anda tawarkan tersebut yg mungkin bisa menjadi solusi bagi klien: “pak, bagaimana kalo broadcastnya mirip bbm/wa, ntar muncul di smartphone konsumen, promonya apa aja..kalo sms takutnya regulasinya panjang, apalagi sekali broadcast terbatas, dan mungkin ada kendala delay”..syukur-syukur klien angkut dua tawaran yang kita sampaikan, proyek sms broadcast dapet, ditambah proyek messanger jg dapet.
  3. Buang sedikit ego, ketika harga proyek ditawar klien terlalu menyakitkan, cobalah sedikit tenang, berpikir apa yang bisa kita coba agar tetap goal mendapatkan proyek tersebut.
    Dengan berpikir tenang, kita coba koreksi apa saja bagian yang bisa kita kurangi standarnya (tanpa mengurangi esensi pemenuhan kebutuhan klien), misal harga desainnya dikurangi, nego lagi dengan designer, kira-kira apabila harga dikurangi segini bakal dapet seperti apa, dan sebagainya..atau ditambah waktunya, biasanya semakin tipis timeline, harga tentu semakin tinggi, karena jam kerja/hari tentu menjadi tinggi, mungkin dengan melebarkan timeline (misal ditawarkan waktu pengerjaan 3 bulan, kita tawarkan menjadi 5 bulan), mengurangi “beban” kerja dan tentu harganya bisa dikurangi. Atau tawarkan alternatif harga modular : “bapak, silahkan dilihat list harga dari kami, ini kami pasang per module : “Bapak bisa cek untuk kebutuhan yang bapak minta standar harganya segini, namun karena bapak meminta kami mengerjakan bagian X, Y, Z, saya coba tawarkan harganya per module, sehingga bapak bisa pilih yang mana yang akan bapak ambil saat ini dan yang mana bapak pending. Dan apabila nanti ingin melanjutkan kerjasama ini, siapa tau ke depannya, bapak meminta kami mengembangkan modul-modul yang bapak belum kesampean karena terbatasnya budget di penawaran berikutnya.”

Kira-kira seperti itu tips hari ini.
Sekian dan terima kasih ūüôā

 
Leave a comment

Posted by on November 2, 2015 in Celoteh, Programming, Workit

 

Tags: , , , , , , , , , , , , , ,

Memasang harga untuk sebuah aplikasi

Kekeliruan yg pernah saya alami dan jg bbrp tmn2 developer yg terjun ke dunia proyek aplikasi mobile (kebetulan sy blm pernah ngalamin yg model bisnis berjualan, tetapi model request by user/client dan donasi) adalah terlalu cepat menyimpulkan, terkadang tanpa disadari, memberikan layanan ke klien/user dengan kurang cermat.

Menerapkan performa dan kualitas yang sempurna itu hampir mustahil dilakukan, semestinya itu disadari bersama, baik developer maupun user, karena segala yang sudah besar seperti facebook app, dll. Itu dilakukan melalui riset yang panjang dan bekerja bertahap mengikuti kebiasaan pengguna (dan lagi-lagi ini menyangkut User Experience ataupun kebiasaan pengguna)

Ide yang solid dibarengi dengan potensi pasar yang siap dieksekusi adalah kuncinya. Namun, dapet ide yang orisinil juga bukan sesuatu yang mudah (dan ide itu mahal, jadi kalo ada orang yg share status : “kalo temen2 minta dibuatkan aplikasi di OS blabla..apa yg pgn temen2 inginkan?” berarti orang tsb lg kekurangan ide hehehe), mungkin wajar bagi kita selaku developer untuk meniru. Tapi yang perlu digarisbawahi adalah, hindari godaan untuk sukses dengan instant. Lebih baik sedikit demi sedikit berjalan, tidak apa pas launching app masih sederhana, tetapi lambat laun terus diriset, dikembangkan, mendengar tanggapan dari user, ditampung dan ditelusuri lebih lanjut sehingga tercipta gagasan baru untuk membuat aplikasi tersebut bertahap menjadi besar.

Membangun aplikasi bukan serta merta untuk mencari duit, perlu di-explore juga jenis aplikasi apa yang bisa/boleh dijadikan uang. Ada beberapa kategori yang semestinya tidak boleh dijadikan lahan uang.

Aplikasi kategori sosial : jejaring, messaging, religi dan app yg hits yang mencakup semua kalangan pengguna, konten beragam, tapi biasanya harga rendah bahkan gratis (loh kok bisa? gk rugi tuh?). Mereka berani memasang harga rendah karena cakupan pasarnya luas, campaignnya mudah (ntah dengan viral, memasarkan via iklan di jejaring, dsb), dan semua orang bisa pakai. Contoh : chat macem WA yang menarik pembayaran tiap tahunnya dengan harga murah (dan tentu target download sudah lebih dari 1000 pengguna)

Sedangkan yang harga tinggi biasanya menargetkan konsumen yang serius/tertentu. Sebagai contoh app. multimedia/office, biasanya harganya mahal, bahkan sampai mencapai $100, seperti : photoshop, fruity loops, officetogo, dll.

Dan ada yang model premium, konten besar, profit yang didapat besar juga dari per penggunanya. Biasanya model ini lebih sedikit dibandingkan 2 jenis sebelumnya. Dan terkadang menerapkan sistem berlangganan per tahun. Sebagai contoh : game karaoke yang tiap lagunya harus berlangganan, microsoft office, aplikasi kolaborasi, dll.

Dan beberapa kegagalan yang sering terjadi adalah developer tidak memahami target penggunanya, memasang harga yang tidak pas.

 
Leave a comment

Posted by on May 7, 2015 in Celoteh, Internet

 

Tags: , , , , , , ,

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.

 
Leave a comment

Posted by on August 16, 2014 in Celoteh, Hobby, Internet, Programming, Workit

 

Tags: , , , , , , , , , , , , , , , , , ,

Masalah source code, pantaskah diberikan ke klien?

Hari ini saya membaca artikel sangat bagus, mengingatkan kembali sedikit masalah yang pernah saya alami dulu di waktu menjalankan proyek TI dan pertanyaan seorang mahasiswa S1 yang sedang belajar “bermain” proyek TI.

Pertanyaan seorang mahasiswa tersebut kira-kira begini :

kalo misalnya klien ingin mengembangkan softwarenya lg, dia harus menghubungi saya dan membantu dia? Atau saya memperbolehkan klien untuk mengubah source codenya dengan izin dari saya?

Dari beberapa case proyek TI, source code tidak ada apa-apanya, jika dijual kembalipun, istilahnya cost depreciation (penyusutan harga). Yang mampu membuatnya “valuable” tentu proses bisnisnya dan layanan yang ditawarkan bagaimana mampu menyelesaikan masalah si client. Faktor supply and demand juga jadi salah satu faktor utama tingginya harga software.¬†

Ada beberapa vendor yang memang tidak memberikan source-code-nya, ada juga yang sistem sewa, dan ada juga yang dalam bentuk paket layanan software (include source-code)
Memberikan source-code tentu menguntungkan client dari segi pendapatan untuk masa depan.
Bisa jadi source-code tersebut di-“re-engineering“/re-use untuk dikembangkan lebih lanjut ke depannya, dan bisa jadi pengembangnya bukan pihak kita lagi (bisa SDM internal perusahaan, ataupun kita jual putus, dilanjut vendor software lain)
Di sini tentu ada nilai “investasi“, nah nilai ini yang bisa dihargai mahal

Kemudian ada pertanyaan lagi yang menghampiri….

kalau client nya bisa added value di code2 kita trus dijual lagi gimana, om ?  Kira-kira apa motivasi atau latar belakang penjual ikut menyertakan source-code software? begitu pula latar belakang pembeli.

Sudah tentu kita (sbg. vendor) merasa dirugikan jika memberikan source code, apalagi kalau client-nya bisa added value di source-code yang kita berikan, dan kemudian dijual kembali dengan harga tinggi (case nyatanya ada  )

Ntah klien ataupun vendor TI tentu punya motivasi.
Sebelumnya kita mesti pahami source-code bukan segalanya bagi client.

Apa motivasi client kita menggunakan jasa vendor untuk membuat software yang mereka butuhkan? tentunya ada alasan “meningkatkan kinerja perusahaan”, jika tidak, tentu mereka re-engineering source-code atau nambahin fitur2 dari software yang ada. Dan dari situ ada faktor lain juga, seperti ini kebutuhan urgent apa tidak, sistemik atau tidak, urusan maintenancenya, dan tentunya inginkan software yang berumur panjang.

Nah, dari sini keliatan kalau software tersebut ada umurnya (termasuk source-code-nya). Kita tentu sudah memperkirakan purna jual software-nya, sampai dengan post-development dan close-project.

Kebanyakan vendor-vendor TI perbankan, menerapkan sistem “pulsa”, “ok, saya berikan source-code ini kepada anda, tapi anda mesti menggunakan layanan kami sampai maintenance (termasuk update minor, re-design, dan bahkan upgrading)

Mereka tawarkan pulsa 100.000 man-days misalnya dari masa maintenance, kemudian ketika ada perubahan yang diinginkan client, itu kena “charge“, misal re-design homepage dihargai 8000/man-days, tentu 100.000 itu berkurang jadi 92.000 man-days, dan sistem pulsa itu ada masa tenggang sampai 1 tahun, di akhir tahun, vendor menawarkan lagi, mau diteruskan lagi (maka harus mengisi pulsa lagi), atau diputus (project termination)

Kebanyakan klien besar tidak mau repot (secara psikologi), dia akan terus menggunakan sampai jangka waktu lama atau sampai software itu tidak menghasilkan solusi lagi. Apalagi sudah ada “ikatan” yang kuat antara si pihak SDM vendor dengan client (misal karyawan TI internal bank sudah akrab dan mampu berkolaborasi dengan SDM vendor), tentu kerjasamanya bisa sangat panjang dan jasa si vendor akan terus dipakai (karena sudah ada nilai kepercayaan yang tinggi). Dan itu outsourcing, ada yang full-outsource ke vendor, ada yang selective outsource, dan ada yang in-source. (perbankan kebanyakan pakai yg selective, jadi yg internal perusahaan tetap dirahasiakan dari pihak vendor TI)

Nah, kembali ke masalah source-code, bagaimana jika source-code tersebut dijual lagi oleh client, apalagi sampe ditambahin macem-macem dan dihargai lebih tinggi lagi?
ya itu tadi, nilai investasinya (invest order) yang kita tawarkan ke client mesti ditinggikan lagi (tapi lihat juga daya beli client), maka dari itu ada proses negosiasi (ini penting sekali).

Seperti halnya di artikel tersebut, jika kita mampu membuat software tersebut kemudian dipake client untuk ditingkatkan kemampuannya kemudian dijual lagi…ya kita selaku vendor mesti lebih kreatif lagi.

Jika tidak rela, silahkan pasang lisensi di software tersebut.

 
Leave a comment

Posted by on January 9, 2014 in Uncategorized

 

Tags: , , , , , , , , , , , , , , , , , , , ,

Beberapa fenomena yang terjadi di dunia proyek TI dengan instansi atau perusahaan pemerintah

Beberapa fenomena yang sering terjadi apabila salah satu vendor TI lolos 3 besar atau menang tender atau lelang di sebuah instansi atau perusahaan pemerintah:

  1. Ancaman
    Ancaman sangat bisa terjadi ketika sudah lolos 3 besar atau menang tender.
    Contoh yang pernah terlihat : Ancaman pembunuhan, ancaman diminta mundur dr proyek, jika tidak turuti, maka akan mengacaukan proyek tersebut.
  2. Tindakan kolusi
    Jadi, yg masuk 2 atau 3 besar itu mereka bersaing, tetapi ada yg bersaing gk sehat. Mendadak si pesaing menelpon : “mas, proyeknya buat kita aja ya! Nanti mas saya bayar 25% dr harga proyek, drpd mas maju belum tentu jg mas menang. Atau mas mau buka penawaran..kami siap denger?!!”
  3. Tindakan nepotisme
    Kalau sudah masuk 3 besar, ada vendor yg licik mencari rekanan dr orang dalem, biar mulus perjalannya di proyek tsb. Kebanyakan vendor-vendor murni itu kalah di sini pdhal presentasi, prototype dan kesiapannya bagus.
  4. Manipulasi
    Ada beberap vendor yang bisa lolos mulus masuk 3 besar karena datanya fiktif, team yg direkrut bukan orang sebenarnya yg sesuai tercantum dlm proposal penawaran. Ditulis lulusan S2, ternyata malah yg dipekerjakan mahasiswa S1 tingkat akhir. Loh? Kan ada verifikasi tuh biasanya di LPSE dsb. Ya ijazahnya minjem sm teman yg bukan anggota team.

Ya semua itu untuk urusan duit. ūüėÄ

 
Leave a comment

Posted by on October 11, 2013 in Uncategorized

 

Tags: , , , , , , , , ,

Harga pengembangan aplikasi mobile yang dipasang, kemahalan atau kemurahan kah?

Mari kita berhitung harga aplikasi mobile. ūüôā Bila ada yg beranggapan harga 4-7jt itu kemahalan untuk membuat aplikasi bisnis berbasis mobile (android, iOS, BB) artinya temen-temen perlu membaca ini.

Ini dikerjakan secara profesional, bukan dikerjakan oleh mahasiswa tingkat akhir yang dipekerjakan (sadis, gan!) :p

Dan jangan dianggap, karena aplikasi yang dikembangkan itu cuma seukuran layar HP dan lebih kecil “keliatannya” tampilan daripada di website, bukan berarti harganya pasti lebih murah daripada mengembangkan versi web. Itu salah kaprah. Karena, bisa jadi kerumitannya lebih rumit daripada pengembangan website. Dan bisa jadi lebih mahal daripada pengembangan versi websitenya. Walau tampilannya keliatan kecil, tetapi di situ ada banyak kerumitan dalam hal UI, fungsionalitas,¬†pemodelan, user-behavior aspect/user experience design,¬†resources, dll. Hampir mirip saat mengembangkan¬†website.

Dari hasil diskusi saya dengan beberapa teman project TI yang sudah 2 tahun mendalami pengembangan aplikasi mobile dan project TI di bidang mobile apps. Dan pengalaman pribadi yang mendalami project programming Android di beberapa tempat sejak memiliki HP Android di juni 2010.

Dan ini berlaku hampir di semua client dan client/perusahaan pun rata-rata mematok harga segitu.

Ok, kebanyakan aplikasi mobile itu faktanya, dikembangkan dalam jangka waktu paling tidak 6 bulan, dengan jam kerja full-time (mengikuti jam kerja) dan berkisar di harga 10 sampai 50 juta.

Eits, tetapi tidak serta merta semua begitu, mari kita buat lebih spesifik. Pertama, perlu kita perhatikan adalah tipe aplikasi yang akan dikembangkan. Kita berhadapan dengan klien, ngobrol panjang lebar dengan orangnya apa yang ia inginkan (user stories) dan mencatatnya untuk dianalisa setiap kebutuhan supaya menjadi milestone pekerjaan (per task, per man-days, per man-power, per period) dalam jangka waktu (timeline) yang sudah disepakati.

Kita bagi dalam dahulu menjadi 2 kategori :

A. Untuk digunakan konsumen (umum)

  1. Aplikasi dasar, yang memiliki fungsi-fungsi dasar android. Sekedar menampilkan teks, diinputkan, diproses ditampilkan secara sederhana. Seperti : aplikasi maps sederhana yang menampilkan petunjuk jalan lokasi penjualan produk, aplikasi alarm, jam, dsb..yang tidak menampilkan fitur-fitur selain itu.
  2. Aplikasi Native, yang menyediakan berbagai tipe konten (gambar, tulisan, suara, dll), dengan logika matematika yang kompleks dan arsitektur software yang terdiri dari beberapa level. Dan biasanya menggunakan framework tertentu atau library tertentu, dan database tertentu (mysql, sqlite, sql server, dsb)
  3. Games, dari berbagai info saja, aplikasi games Angry Birds seharga $125k-180k hanya untuk biaya coding saja. Dan games sama saja mencakup beberapa hal, seperti : rendering 2d/3d graphics, logika ilmu matematika, ilmu fisika, dll. Belum lagi nanti ada sound artist, artwork design, dll. Makin mahal.

B. Untuk digunakan perusahaan (bisnis/internal)

  1. Aplikasi enterprise kecil
  2. Aplikasi enterprise sedang
  3. Aplikasi enterpise besar

Mengenai kecil, sedang, dan besarnya ditentukan dari banyaknya scope-pekerjaan, timeline yang diberikan, dan kompleksitas masalah (apakah nanti cross-platform kah? artinya perlu menyediakan web-services, database-support library, Share Capabilities  dengan apps lain, dsb)

Ok, soal harga, berapa?

Menentukan harga itu harus ditambahkan juga dengan biaya penyediaan resources (tools/software/IDE) dan biaya produksi (publishing) jika memang semua diusahakan oleh pihak pengembang.

Begini, ketika kita akan mengembangkan apps. games dengan menggunakan¬†Game Maker Studio seharga $299 dolar, artinya itu masuk hitungan nilai investasi kita, kecuali sudah disediakan oleh pihak client, kalau tidak? masa’ kita yang membeli sendiri? Kalau sudah punyapun, harus dihitung lagi. Karena secara profesional, semuanya disediakan oleh client, kecuali ada hitam di atas putih yang menyatakan kita ikhlas menyediakannya [yaoming.jpg] ūüôā

Jika menggunakan tools yang gratisan ya jangan hehe..

Begitu juga biaya publishing ke PlayStore ataupun AppsStore, itu ya biaya pendaftaran akun untuk publishing-nya ya dihitung juga.

Dan untuk masalah harga yang berlaku, bisa dicek di sini :

  1. Aplikasi dasar seperti pada poin A.1 di atas : berkisar 2-5jt (di luar sana berkisar $1,000)
  2. Aplikasi native, seperti pada poin A.2 di atas : berkisar 6-50jt (di luar sana berkisar $8,000-$50,000)
  3. Aplikasi games, seperti pada poin A.3 di atas : berkisar 8-150jt (di luar sana berkisar $10,000-$250,000)
  1. Enterprise kecil, seperti pada poin B.1 di atas : berkisar 20jt (sekedar ekstrak data dari database, kemudian ditampilkan)
  2. Enterprise sedang, seperti pada poin B.2 di atas : berkisar 20-50jt (sudah mencakup masalah seperti : client-server apps, cache data, penggunaan library native, hardware support)
  3. Enterprise besar, seperti pada poin B.3 di atas : berkisar 80-300jt (full-scale enterprise, office automation, enterprise financial monitoring, mobile apps. banking, dsb)

Apalagi akan ada continuing cost setelah masa development, guarantee, maintenance, dll.

Harap diperhatikan juga, besar kecilnya harga yang ditawarkan itu bisa bergeser karena dipengaruhi banyak faktor. Ketersediaan SDM, Ide, Waktu, Budget, Fungsionalitas,¬†Layout Design, dan negosiasi. ¬†ūüôā

Apakah harga segitu wajar?

Jelas wajar, dilihat dari lifecycle development-nya, benefit dari pemanfaatan aplikasi mobile kepada user (yang jelas lebih mudah dipakai di manapun, kapanpun, tanpa perlu membawa laptop), promosi (iklan) produk dan monitoring (untuk keperluan survey statistik penggunaan) juga dapat dimanfaatkan dengan mudah melalui apps yang dikembangkan dan di-publish, demi memperhatikan konsumen dan mencari aspek penting buat menentukan kebijakan perusahaan. Dengan rata-rata per sekali publish, dalam seminggu bisa sampai 100-500 yang downloads, tentunya akan meningkatkan keuntungan bagi pihak client. Apalagi trend sekarang ini adalah mobile apps.

NB : tulisan ini mix teori (minim) dan hasil praktek, bukan money-oriented tanpa dasar, tetapi supaya kita juga paham memasang harga pengembangan aplikasi biar tidak dirugikan. :p Newbie belajar nulis.

 
2 Comments

Posted by on October 10, 2013 in Uncategorized

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,