RSS

Project Hunter wanna be

02 Nov

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: , , , , , , , , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: