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 🙂

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.