RSS

5 tahun berlalu

Ada pepatah bijak mengatakan “Jika ingin berubah maka lakukanlah saat ini juga
Ya, saat ini juga, tanpa keraguan dan tanpa takut akan gagal.

Dahulu lulus kuliah hanya mengenal 1 bahasa pemrograman yaitu PHP (PHP: Hypertext Preprocessor), dan tidak banyak yang saya persiapkan, hanya mengikuti arus, bekerja setelah lulus, terima gaji yang waktu itu sangatlah kecil, sekitar 3jt, dan itu tinggal di Jakarta dengan menghabiskan biaya hampir 3 jt per bulan. Tidak mengerti bagaimana mengelola uang, tidak mengerti bagaimana nego gaji, tidak mengerti memilih tempat nge-kost, karena waktu itu kebetulan lulus sendiri, sementara teman seangkatan cuma 3 orang yang lulus, termasuk saya pribadi. Dan di Jakartapun bertemu teman-teman angkatan sebelumnya yang lumayan memandu saya untuk bertahan hidup di Jakarta.

Saya bukan tipe orang yang mudah sekali berteman, mungkin introvert. Dan bahkan selama kuliah saya hanya punya sedikit teman yang akrab, malah di kampus beberapa dijahilin teman seangkatan yang menganggap saya sombong (lambat laun saya menyesalinya). Kesulitan itu makin menjadi ketika banyak masalah pribadi pada waktu itu yang mengharuskan saya dipecat dari kantor karena bolos 3 minggu. Ya, jangan ditanya masalah apa, masalah anak muda hahaha…

Saya tidak akan bahas masalah itu, tapi yang saya coba cerita adalah saya bersyukur sampai hari ini, dengan lika-liku jalan yang sudah dilalui yang jujur saja banyak jalan sulitnya, tapi alhamdulillah bisa saya lakukan.

Alhamdulillah dengan banyak dukungan orang tua, teman, dan sekitar, buat move-on itu tidak sulit. Dahulu teman-teman yang saya cuekin, ternyata ketika saya jatuh, mereka malah memberi banyak dukungan. Pada waktu itu saya benar-benar menangis. Betapa berartinya teman. Dan sampai pada satu ketika saya memutuskan kembali ke Jogja, untuk mencoba memperbaiki semua, mengakrabkan kembali dengan teman-teman angkatan, walaupun agak sulit. Tapi alhamdulillah bisa saya nikmati, mulai dari tahun baru berkesan sampai pagi dengan teman seangkatan kuliah sampai acara-acara nonbar yang bener-bener penuh canda. Dalam hati, mengapa tidak saya lakukan dari dahulu. Tapi malah sibuk dengan kuliah, fokus belajar, menghilangkan segala sesuatu yang saya anggap penghalang dan ternyata semua itu tidak benar.

Saya kira karir saya bakal tamat,  setelah pemecatan itu, sampai menganggur 3 bulan, bingung, dan akhirnya saya coba lamar sana kemari, dan dari puluhan surat lamaran, ada 4 yang memanggil saya interview ke Jakarta.

Dengan biaya masih minta orang tua pada waktu itu untuk tiket pesawat dan uang makan selama perjalanan di Jakarta, rasanya sungguh malu sekali.

Dari 4 itu, ke-empat-empatnya pun menjawab “menerima”, sampai pada akhirnya saya diharuskan memilih, alhamdulillah, saya sempat mengira bakal pupus harapan, akhirnya bisa dijalani. Dari ke-4 itu, ada 3 lowongan sebagai php developer, dan 1 adalah asp.net developer. Apa yang saya pilih? sudah bisa ditebak, saya keluar dari zona nyaman saya. Memilih asp.net developer.

Saya tidak akan bercerita banyak bagaimana saya berani menerima tawaran asp.net padahal tanpa skill dasar asp sama sekali.Akan tetapi yang jelas, saya yakin saya bisa belajar. Ya, motivasi yang kuat. Di sana saya mendapatkan banyak pengalaman mencoba hal-hal baru. Sampai pada satu masa, saya tiba-tiba diangkat manager jadi system analyst yang merangkap jadi senior maintenance developer.
Dan hal gila pun terjadi, ketika bertemu dengan klien pertama kalinya, diterjunkan langsung ke kantor-kantor perbankan (BNI, BCA, BII, BRI, Danamon, Indonesia EximBank..hampir semua perbankan pernah saya datangi dan hinggap langsung bertemu dengan para manager dari berbagai divisi yang berkepentingan), saya selalu didampingi teman yang senior, tidak mengerti apa-apa selain teori yang saya pelajari selama kuliah. Bahkan sering kali melakukan kesalahan yang akhirnya diperbaiki oleh teman senior. Berani mencoba, berani menerima kesalahan dan berusaha memperbaiki. Sampai pada satu masa saya pernah merepotkan, seorang teman senior, yang saya ingat betul namanya, mas Aang (bukan pengendali udara). Mas Aang rela menemani saya di kantor klien sampai malam ketika semua orang sudah pulang dari kantor (yang pada waktu itu bank export import a.k.a. Indonesia Exim Bank). Dari kesulitan dan rasa tidak enak tersebut, ditambah rasa malu, motivasi belajar pun meningkat. Sampai pada satu ketika saya akhirnya memahami bagaimana proses bertemu klien, bagaimana menulis proposal, bagaimana cara nego dengan klien bagaimana cara berkomunikasi dengan klien dan segala hal yang berbau manajemen proyek.

Ya, benar, dari situlah saya akhirnya sekarang berani mengelola proyek, bukan sebagai developer ataupun freelance developer, tetapi menjadi manajer dari berbagai proyek langsung. Siapa yang jadi developer? saya merekrut teman-teman yang sama-sama senang dengan proyekan.

Pada tahun 2011, saya memutuskan untuk resign dari kantor di Jakarta, yang telah memberikan saya banyak teman dan pengalaman sangat-sangat berarti. Bahkan sampai manajer saya kaget, mengapa saya resign, apakah gaji saya kurang layak? ternyata sampai seperti itu yang tidak saya sangka-sangka. Ya saya akhirnya memutuskan untuk lanjut S2 karena pada waktu itu ibu saya ingin saya S2 saja, dan pas kebetulan pada waktu itu cukup biaya. Resign dari situ bukan berarti saya langsung menganggur, tetapi pada waktu itu saya sudah mempersiapkan dengan hati-hati kira-kira di Jogja kerja apa? dan akhirnya saya menerima tawaran teman yang saya kenal dari jejaring sosial Plurk, mas Yo, beliau punya start-up bernama PT. Dipeta, di sana saya memulai kembali menjadi php developer sekaligus android developer! Ya, dari situlah saya memulai menjadi android developer new wanna be.

Studi S2 saya tidak sepenuhnya mulus, saya seperti kurang siap dengan apa yang dihadapi, saya kira studi S2 saya bisa menunjang karir saya seperti yang teman saya ceritakan, ternyata sebaliknya, apa yang dipelajari malah kembali membawa saya dengan materi sistem cerdas dan sejenisnya yang tidak begitu saya sukai. Saya kira, saya bisa memilih kosentrasi di manajemen proyek ataupun Sistem Informasi, ternyata kebijakan kampus mengharuskan voting semua mahasiswa S2 seangkatan memilih kluster dengan suara terbanyak, dan didapatlah “SISTEM CERDAS”.

Sambil kuliah saya bekerja, ngoding ngoding dan ngoding, bikin sistem SMS-gateway, bikin sistem berbasis lokasi dan sejenisnya, dan selama 3 bulan berjalan, hubungan saya dengan atasan saya tidak berjalan mulus sejak kedatangan orang baru. Bahkan saya merasakan sekali perbedaannya ketika atasan saya meminta semua serba cepat, padahal saya memiliki 2 tanggungan di web dan di android yang tidak bisa dikerjakan instant. Dan akhirnya saya putuskan untuk resign.

Apakah saya jadi pengangguran? tidak, selama saya join dengan start-up tersebut, saya sudah terikat kontrak dengan BNI. BNI tertarik merekrut saya karena saya sering datang troubleshooting dan patching modul baru di front-end perbankan mereka ke kantor pusat BNI. Dan dari situ beberapa divisi mulai kenal saya secara pribadi sampai memiliki kontak saya. Pas di Jogja, alhamdulillah direkrut dan saya bekerja sebagai administrator fan-page facebook BNIdan juga developer di beberapa micro-site milik BNI. Bekerja di sana sangat menyenangkan, dengan bayaran 2jt per minggu bukanlah sesuatu yang murah. Dan alhamdulillah sangat mencukupi kebutuhan selama di Jogja.

Dan sambil bekerja di BNI, akhirnya saya memutuskan jadi project hunter. Saya menggunakan teknik self-promotion di facebook dengan cara  “show-off” karya-karya sendiri dan akhirnya dikenal. Dan dari situ tawaran-tawaranpun datang. Dari tawaran-tawaran tersebut, saya mulai praktekan teknik yang saya pelajari selama bekerja di Jakarta. Mulai dari menyiapkan proposal, menyusun kalimat-kalimatnya menjadi sistematik, menyusun rancangan aplikasi, menyusun deliveriables, menyusun gantt-chart timeline pekerjaan, menyusun anggaran proyeksi investasi sampai dengan layanan yang saya persembahkan untuk klien.

Apakah berjalan lancar ? ya sebagian besar, alhamdulillah lancar, sebagian kecil tidak. Berhadapan langsung dengan proyek bukan sesuatu yang mudah, penuh dengan rintangan. Rintangan pertama adalah menghadapi klien. Saya menyadari betul pada akhirnya, setiap klien itu berbeda karakteristiknya, komunikasinya dan cara pandangnya. Ditambah lagi dengan tingginya persaingan.
Awal mulanya, ketika mengajukan proyek, tidak semuanya lancar, bahkan gagal, melakukan kesalahan menyusun jadwal, melakukan kesalahan mengatur anggaran sampai akhirnya merasakan kerugian di diri sendiri.

Ya, merugi, apa yang saya kerjakan ternyata terlalu murah sampai-sampai harus begadang garap proyek padahal hasilnya tidak seberapa, dan pada akhirnya saya belajar dari situ untuk mengkalkulasi dengan pas dari masalah waktu sampai biaya.

Proyek pertama yang saya berhasil adalah dengan klien PDAM, digarap berdua, saya mengelola proyeknya, dan teman sebagai developernya. Harga proyek waktu itupun wah, yaitu 40jt, dan itu kami bagi 2 masing-masing 20jt. Dan dari situlah saya punya tv, gadget dan console sendiri di kost-kostan waktu S2 itu (jangan ditiru foya-foyanya)

Sejalannya waktu, proyekpun datang lagi dari tawaran teman di Departemen Keuangan, tawaran di BNI lagi, tawaran di hotel Pullman Jakarta, PLN Bandung, Humanitarian OpenStreetMap, JTETI-UGM, PLN Medan, Kementerian Agama RI, PLN Medan lagi, dan seterusnya…dan karena itu akhirnya bisa keliling beberapa kota di Indonesia secara gratis sambil menikmati hotel-hotelnya😀 tawaran yang saya ambil bukan yang kecil, kadang satu proyek bernilai 35jt, kadang 40jt, dan bahkan pernah lebih, apakah tanpa tantangan? besar banget, ya kudu kuat hadapi yang besar, great power, great resposibility, great income too.

Dan bukan juga tanpa hambatan dan tanpa kegagalan, taruhlah dengan pengalaman saya akhir-akhir ini di mana, developer yang saya rekrut melakukan keteledoran dengan jadwal yang ia buat dan akhirnya ia ingkari hingga telat 1 bulan. Dan juga dahulu pernah mengalami demikian sampai-sampai harus menggunakan uang pribadi untuk membayar designer dan developer padahal telatnya ya karena klien minta macem-macem dan ngeyelan padahal sudah dipandu cara buat reporting ke developer jika menemukan bugs. Ya dulu pengalaman dengan salah satu perusahaan di Sukabumi yang benar-benar jadi pelajaran buat saya pribadi sekaligus harus lebih cermat memilih tim dan mengelola proyek, terutama bagaimana menghadapi klien yang jumlah anggotanya banyak dan semuanya ikut campur. Ya kesalahan ada di saya selaku manajer kenapa kurang tegas dan kurang cermat mengelola proyek ini sampai jadi gagal.

Gagal dari 1 proyek itu bukan berarti saya lengah dan menyerah, dari situ saya mulai menerima tawaran dari PusatKajianHadis dapet proyek membuat aplikasi Alquranalhadi di Android. Dan sampai pada akhirnya, alhamdulillah, menjelang saya melamar wanita pujaan hati, saya malah direkrut jadi karyawan tetap di PKH. Pas banget! dengan begitu menghadapi calon mertua jadi agak PeDe (walau masih degdegan) karena waktu itu saya minder dengan status pekerjaan saya yang kurang jelas (apalagi kerjanya dari kost-kostan, gimana mau yakin, ntar dikira pelihara tuyul), alhamdulillah, lamaran diterima dan menikah oktober 2013 kemarin. Dan dikaruniai seorang putri cantik yang sekarang usianya 1 tahun🙂

PKH memberikan keleluasaan kepada saya, membolehkan saya menyambi proyek asalkan semua pekerjaan di PKH dapat tuntas sesuai jadwal dan terus monitoring setiap aplikasi yang saya kembangkan di PKH agar tetap berjalan sebagaimana mestinya setiap waktu untuk semua pengguna.

Sampai detik ini, alhamdulillah, saya sudah 3 tahun bekerja di PKH dan masih aktif dengan proyek-proyek, bahkan sempat mengajar jadi mentor developer android di beberapa kampus di Jogja (UGM, UMY, UNY, AtmaJaya), dan sempat jadi dosen 1 semester di STMIK A.Yani, dan saat ini terikat kontrak kerja proyek dengan SaleStock dan Samsung (padahal dulu sempat manggil interview jadi developer android, tapi saya tolak), dan alhamdulillah, 2 tahun lebih kami menikah, dan sekarang punya rumah sendiri dan menikmati perjalanan hidup ini bersama istri dan anak tercinta.

Saat saya sudah bekeluarga, saya harus pahami hak dan kewajiban saya sebagai seorang suami dan kepala keluarga, dan diputuskan sampai saat ini saya hanya fokus di pekerjaan PKH dan max. 2 proyek saja. Maka dari itulah saya berhenti dari profesi dosen yang lumayan menyita waktu dan lokasinya cukup jauh dari tempat tinggal. Dan bekerja dari rumah sekaligus menemani istri dan anak, tiap hari conference call via skype dan telpon dengan klien dan tiap hari bertemu laporan-laporan, trello, basecamp dan tiap hari masih ngoding, dan yang terpenting adalah..rasa syukur. Rasa syukur menambah nikmat di sanubari. Makan seadanya, ya bersyukur, makan banyak juga bersyukur, punya rezeki, sedekah sbg rasa syukur, lagi sempit rezeki, tetep bersyukur sambil introspeksi diri.

Perjalanan ini masih berliku, mungkin yang diceritakan seakan hidup ini mudah, padahal banyak rintangannya. Namun, saya slalu yakin, rezeki tidak pernah tertukar, tiap orang punya jalannya masing-masing, yakin Allah akan mencukupi kebutuhan, dan terus berusaha agar orang-orang di sekitar senang dengan keberadaan saya.

Semoga Allah selalu memudahkan jalan ini dan melimpahkan rezeki, kesehatan dan kekuatan untuk kita semua agar dapat mengarungi hidup dan slalu pada jalan yang lurus. aamiin.

 

 
Leave a comment

Posted by on March 2, 2016 in Celoteh

 

Tags: , , , , , , ,

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

Pentingnya bagi seorang designer mobile app. memahami “design pattern” dan guidelines desain aplikasi

Waaah…. desainer baru…. begitu dilihat pengalamannya ternyata basic-nya adalah desainer web yang sudah bekerja selama 5 tahun lebih.

Tiba-tiba kebutuhan akan aplikasi mobile begitu tinggi, alhasil beberapa desainer web beralih profesi mengerjakan desain-desain antarmuka aplikasi mobile.

Nah, ada kesalahan fatal yang terjadi, menyebabkan potensi kesalahan di dalam pengembangan, ntah itu timeline menjadi tambah panjang, developer yang menjadi sulit mengimplementasikan desain yang diberikan, dan sebagainya.

Siapapun yang menjadi desainer aplikasi mobile, dimohon jangan samain seperti mendesain website yah..hehe
Desain aplikasi platform apapun itu, baik itu iOS, Android, Windows Phone, Blackberry, ada prinsip-prinsip desain yang harus dipahami, ada guidelines yang harus dipatuhi. Setiap OS mobile punya pattern desain sendiri yang mesti diikuti. Tidak bisa “semau gue, menurut gue itu keren”.

Seorang designer antarmuka aplikasi mobile mesti mendalami pengetahuan seputar perangkat OS platform tersebut, mindset-nya juga harus diubah. Sama seperti pada waktu seorang designer web mendapatkan job dari perusahaan ternama (pernah saya alami di BNI, Jakarta), mereka (BNI…yg saya tau) punya guidelines terhadap website mereka. Misal : Warna tema website mereka.. di guidelines-nya dijelasin hexa codenya apa, logo web-nya pakai yang mana, resolusi “width height“-nya berapa, ukuran hurufnya berapa, pake typeface apa, dan sebagainya..maka terjadilah konsistensi desain di web yang dimiliki perusahaan ternama tersebut.

Begitu juga dengann platform mobile. Antarmuka di aplikasi mobile punya konsistensi, ketika mendesain layout, peletakan menu slalu di sebelah mana, icon aplikasi bentuknya seperti apa, di hape layar kecil resolusinya berapa, di hape layar besar resolusinya berapa, kalo bikin tab taruh di mana, default typeface pake apa, dan sebagainya.

Saya rasa tantangan yg mereka (designer web) hadapi ketika menjadi designer apps adalah bagaimana caranya agar menguasai design interaksi dan UX-nya.

Untuk mengubah sebuah tampilan website menjadi tampilan aplikasi yg mungil, layar terbatas, jangkauan pengguna ketika menyentuh layar bagaimana, dan hal-hal lain yang perlu diperhatikan… bukanlah sebuah pekerjaan yang mudah. Sebagai contoh : ketika mengatur ukuran huruf yang nyaman dibaca pengguna aplikasi, mengatur komponen apa aja yang dapat dijangkau pengguna aplikasi ketika menyentuh layar, dan dari langkah tersebut, desainer masih dibuat pusing lagi ketika menguji hasil karya antar mukanya.

Si desainer sudah merasa yakin mendesain aplikasi di hape layar besar (di atas 5 inch), ternyata di hape layar kecil membuat pengguna kurang nyaman, terkadang mengalami masalah komponen layout-nya oversize di hape layar kecil, terkadang ukuran hurufnya kegedean diterapkan di hape layar kecil, dan masih banyak lagi masalah-masalah yang mungkin terjadi. Dan akhirnya si desainer aplikasi  mencoba mengatur ulang layout-nya.

Dengan kata lain, mau tidak mau si desainer harus menyiapkan beberapa layout design untuk beberapa jenis ukuran layar smartphone maupun tablet (dari ldpi, mdpi, hdpi, xhdpi, sampai dengan xxhdpi).

Seperti yang sudah saya jelaskan, masing-masing perangkat mobile, baik itu smartphone maupun tablet punya UX berbeda. Apalagi beda platform, tentu User Experience di tiap platform berbeda. Pengguna device Android sudah terbiasa melihat menu dengan slide ke kanan atau tap pada pojok kiri dan kanan, sedangkan pengguna device iOS terbiasa dengan menu slide di bawah ke atas, dan berbeda lagi dengan pengguna WindowsPhone, menu disajikan per tab dengan label yang besar di atasnya, tidak ada menu pojok seperti di Android ataupun menu bawah seperti di iOS. Setiap platform punya guidelines-nya bagaimana meletakkan komponen design, seperti yang saya sampaikan yaitu menu, slide menu, tombol, tab, tabel, dan komponen lainnya.

Biasanya, seorang desainer itu melakukan coret2 dulu di wireframe (wireframing), diskusikan dengan tim (ntah dengan desainer web ataupun aplikasi mobile yang lain ataupun dengan developer dan system analyst) apa yang telah di-wireframing sudah pas atau belum, kemudian periksa guidelines di docs platform tersebut apakah sudah sesuai pattern OS tersebut atau belum, kemudian UX-nya bagaimana.. apakah sudah sesuai dengan kebiasaan pengguna di platform tersebut atau belum, setelah itu baru memulai perbaiki designnya agar menjadi tampilan antarmuka aplikasi yang ideal yang siap diimplementasikan ke dalam aplikasi.

Bagi teman-teman yang belum mengetahui guidelines atau panduan mendesain di masing-masing platform mobile, bisa merujuk ke link berikut ini :
Semua udah ditulis lengkap, resmi dan terstruktur, tinggal kitanya mau belajar dengan tekun atau tidak.
iOS : https://developer.apple.com/…/UserExp…/Conceptual/MobileHIG/
Android : http://developer.android.com/de…/get-started/principles.html
WP : https://dev.windows.com/en-us/design

Sekian🙂

 
Leave a comment

Posted by on November 2, 2015 in Android, Design

 

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

HTML5 atau Native?

Kemarin baru saja membaca perkembangan aplikasi facebook di Android maupun iOS. Awalnya facebook menerapkan html5 di aplikasi mobilenya, kemudian akhirnya beralih ke native. Pada tahun 2011 lalu, facebook masih memakai html5, karena banyak keluhan dari pengguna, mendapatkan rating bintang 1 & 2. Akhirnya beralih ke native sampai dengan tahun ini. Hasilnya, pengguna meningkat 200%.

Konsep “build once, deploy everywhere” tidak selalu menjadi solusi untuk menghasilkan produk yang cepat dan tepat. Tentunya beda Sistem Operasi, beda pula pattern UInya (kecuali jenis games), tampilan yang dihasilkan terkadang nampak asing di sisi pengguna masing-masing platform. Pada waktu pengguna smartphone Android mencoba aplikasinya : “loh kok tampilannya mirip di iOS?”, padahal experience pengguna di iOS dengan di Android itu berbeda.

Pelajaran yang diambil adalah terapkan teknologi sesuai desain, bukan membuat design sesuai teknologi. Buatlah design untuk berbagai jenis platform terlebih dahulu, kemudian lihat apakah bisa diterapkan dengan model “build once, deploy everywhere”
Kalau tidak bisa ya, perlakukan dengan native.

Jangan pernah melakukan : “ah, yang penting cepet jadi aplikasinya, sesuai keinginan kita” ternyata malah fatal di belakang karena ego kita tersebut. Perlu riset lebih dalam bagaimana konsep desain masing-masing platform, perilaku pengguna, biaya dan waktu agar pengembangan aplikasi tersebut benar-benar siap dan terarah.

 
Leave a comment

Posted by on May 8, 2015 in Android, Celoteh, Internet

 

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

Panduan untuk developer dalam menyusun Kontrak Kerjasama dengan klien

Tulisan saya kali ini mencoba menjabarkan apa saja komponen yang harus ada di dalam menyusun berkas Kontrak Kerja antara developer (vendor software) dengan klien.

Mengapa saya tidak menyertakan contoh kontrak kerja?
Karena tidak ada yang instant di dunia ini, semuanya berproses, begitu juga apabila teman-teman developer menggarap kontrak kerja, tentu tiap kerjasama ada pelajaran yang berarti yang dapat membuat teman-teman developer sadar bahwa ada komponen yang tertinggal di kontrak kerja dan jadi pelajaran bahwa teman-teman harus menyertakan komponen tersebut di kontrak kerja berikutnya.

Ditambah, kontrak kerja itu bersifat rahasia, tidak bisa bebas dibeberkan ke publik. Dan setiap teman-teman punya ciri khas dalam menulis kontrak kerja yang menjadi nilai tambah mengapa klien memilih anda dalam kerjasama pengembangan software.

Ok, kita mulai bahas satu per satu apa saja komponen yang harus ada di dalam kontrak kerja kerjasama dengan klien.

Komponen-komponen yang sebaiknya ada di kontrak kerja :

  1. Yang bertanda tangan, tuliskan diawali dengan tanggal, kemudian disertai nama lengkap, alamat lengkap, no.telepon pihak pertama dan pihak kedua. Di dokumen pertama ini saya tuliskan bahwa pihak pertama adalah klien dan pihak kedua adalah developer.
  2. Pasal-pasal :
    • Bentuk Kerjasama
      Kerjasamanya dijelaskan seperti apa dari pihak pertama ke pihak kedua, dan dari pihak kedua ke pihak pertama.
      Karena di sini tidak satu arah.
      Tidak hanya developer yang punya tugas/peranan, tapi juga Klien punya peranan.
      Nah dijelaskan saja satu per satu. Masing-masing tugasnya (bukan menjelaskan apa saja yang dibuat tapi lebih general, karena kalau membicarakan apa yang dikerjakan itu masuk ke proposal dan laporan pekerjaan bukan kontrak kerja)
      Contoh :
      Pihak Pertama memberikan pekerjaan kepada pihak kedua yaitu ….

      Pekerjaan yang dilaksanakan adalah : a. …. b. …. c….

      Pekerjaan tersebut dilaksanakan pihak kedua.

      Sedangkan untuk pihak pertama sebagai penanggungjawab proyek mempunyai peranan sebagai : a… b… c….

    • Jangka Waktu Pelaksanaan
      Tulis jangka waktu pelaksanaannya, dituliskan dengan jelas, tanggal mulai dan tanggal berakhirnya proyek, terus jangka waktu dijelaskan masing-masing tahap.
      contoh :
      kontrak kerja tanggal …
      pengumpulan data yang dibutuhkan tanggal …
      setup server tanggal …
      development tanggal….
      testing dan review tanggal …
      bugs fixing tanggal…
      maintenance tanggal..
      penutupan proyek tanggal…
    • Hak dan Kewajiban
      Setiap pihak, baik itu pihak pertama maupun pihak kedua, memiliki hak dan kewajiban, maka dari itu tulislah semua hak dan kewajiban tersebut sampai bagian terkecil, jangan sampai ada yang terlewat, mengapa? karena pekerjaan yang kita lakukan bukan hal cuma-cuma, ya jasa developer dipakai tentu dibayar, jangan sampai developer mengerjakan sesuatu yang bukan kewajibannya. Semakin spesifik detail hak dan kewajiban di kontrak kerja, maka makin bagus. Tentunya menguntungkan kedua belah pihak menghindarkan pihak pertama menuntuk pekerjaan kepada pihak kedua yang bukan kewajiban pihak kedua (sayangnya sering terjadi yang seperti ini, karena pihak kedua/developer kurang spesifik menuliskan kewajiban-kewajibannya) Dan setiap hak masing-masing pihak dipenuhi oleh pihak lain sesuai waktu dan kapasitas yang telah dirumuskan bersama.
    • Nilai Kontrak dan Sistem Pembayaran
      Nilai kontrak dituliskan dengan jelas beserta mekanisme pembayarannya seperti apa.
      misal, pihak kedua dibayar 4x cicilan, yaitu di waktu : awal kontrak (DP), pada saat alpha testing (atau pada waktu masa development berakhir sebelum masuk masa review/bugs fixing), pada saat mulai tahap bugs fixing / beta testing, dan terakhir ketika proyek dinyatakan selesai/penutupan proyek. Biasanya dibuat dalam persentase..atau bisa juga ditentukan porsinya masing-masing tahap tersebut. Dan masing-masing waktu pembayaran yang diamanahkan ke pihak pertama ada masa jatuh tempo dituliskan supaya jelas dan menghindarkan dari hal klien terlambat melakukan  pembayaran (sering kejadian). Misalnya : jatuh tempo 1 minggu dari tanggal invoice diberikan ke pihak pertama (klien).
    • Denda Keterlambatan (development, testing, reviewing, payment)
      Denda harus ditentukan dengan hati-hati. Developer/pihak kedua biasanya dikenakan denda apabila terlambat di dalam menyelesaikan pekerjaannya, ntah itu denda per hari atau per minggu, nominalnya mesti dibicarakan bersama antara kedua belah pihak. Jangan sampai ada yang dirugikan. Denda telat testing atau telat review dan telat pembayaran jg mesti dibahas bersama.
    • Perselisihan
      Perselisihan terkadang dapat saja terjadi, baik itu perselisihan kecil ataupun yang sudah membesar karena permasalahan yang kompleks. Nah di sini diatur pasal mengenai perselisihan tersebut, tulislah keterangan akan diselesaikan di mana perselisihan tersebut, dan dengan cara seperti apa? misalnya : apabila masalahnya dapat diselesaikan secara musyawarah mufakat, maka ini menjadi prioritas, namun apabila memang tidak ada titik temu, ya melalui jalur hukum di pengadilan, maka dari itu tuliskan nama pengadilan dan alamatnya.
    • Aturan lain-lain
      Aturan tambahan disertakan di bab pasal ini, apapun itu pasalnya, contohnya : klien berkeinginan mengubah fitur di tengah jalan development, aturannya mainnya seperti apa jika klien ingin mengubah fitur yang sudah disepakati? maka dari itu tulislah tata cara/aturan mainnya. Jika nanti memang harus ada bentuk kerjasama tambahan, mekanismenya seperti apa dicantumkan di pasal ini. Pasal penting di bab kali ini juga harus menyertakan ketentuan perubahan dari bentuk kerjasama, misalkan klien ingin mengajukan perubahan fitur, maka harus diajukan ke developer paling tidak 2 minggu sebelum fitur itu dikerjakan (disesuaikan dengan jadwal), jika sudah dikerjakan dan minta diubah, maka harus ada aturan yang mengatur tentang ini, apakah klien dikenakan denda atau biaya tambahan, atau perubahan tersebut dikerjakan di akhir proyek dengan kontrak kerja baru. Dan jangan lupa cantumkan batas waktunya berapa lama untuk merumuskan dan pengajuan (menghindari masalah jangan sampai dadakan yg dapat merugikan developer).
    • Ketentuan Penutupan Kontrak
      Mulai berlakunya kontrak kerja, ketentuan kontrak kerja, dan tanda kalau kontrak kerja berakhir itu seperti apa nantinya, dicantumkan di bab ini. Dengan penutupan bab ini, menandakan tidak ada aturan baru yang terjadi. Jikalau memang ada aturan baru, maka akan berlaku adendum. Adendum adalah dokumen yang berisi perubahan kontrak kerja tanpa ada penambahan ataupun pengurangan klausa kontrak yang telah disepakati.
  3. Tanda tangan pihak pertama dan pihak kedua di atas materai. Masing-masing pihak memegang surat kontrak kerja dan 1 materai yang ditandatangani kedua belah pihak.

Beberapa catatan :

  • Berkas Kontrak kerja dipegang masing-masing pihak dan kedua berkas tersebut telah ditandatangani dan dibubuhi materai.
    Kontrak kerja yang dipegang developer itu, pihak pertamanya adalah developer, sedangkan pihak keduanya klien (aktif).
    Sedangkan untuk kontrak kerja yang dipegang klien, pihak pertamanya klien, pihak keduanya developer (pasif).
  • Isinya kontrak kerja yang dipegang masing-masing pihak dapat dibuat sama, tapi perlakuannya beda. Atau Kontrak Kerja masing-masing pihak itu dibuat sama persis, dengan ketentuan pihak pertama klien, pihak kedua developer.
  • Ada alasan mengapa terkadang kontrak kerja pihak pertama dan pihak kedua dibuat berbeda, biasanya dengan kondisi pasal-pasal untuk developer dan untuk klien banyak perbedaan dan lebih spesifik.
  • Kemudian, apabila ada tulisan angka, baik itu tanggal, nominal pembayaran, denda, jumlah hari, dll, dituliskan dengan angka dan dieja (ditulis dengan huruf).

Semoga bermanfaat. Jika ada tambahan..silahkan ^_^

 
Leave a comment

Posted by on April 9, 2015 in Celoteh, Internet, Workit

 

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

Menentukan harga jasa untuk programmer dan desainer

Setelah pernah dibahas mengenai menentukan harga project TI khususnya mobile apps. Kini saya mau berbagi info mengenai bagaimana menentukan harga jasa untuk programmer dan desainer mobile apps (mungkin bisa dipakai untuk develop 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/honor kamu berapa yang pernah kamu terima? terus itu dikerjakan berapa lama?
    Misal :
    Kamu pernah kerja 2 minggu (10 hari kerja, minus sabtu-minggu) dibayar 3juta
    Sehari kerja dari jam 09:00 – 12:00, dilanjut ishoma, terus jam 13:00 – 16:00, berarti kalo ditotal : 6 jam kerja.
    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.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)
  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, dan biaya : Rp 82.000 (2000+1000+….+6500)

    Rumusnya : hourly rate x total proses kerja + investasi

    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 investasi dari project ini (project? emang ke sekolah bisa jadi project? ngawur, ini kan cuma contoh!) : Rp 149.000,-

  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, buat rules juga (biasanya klien bikin rules, kalo kamu telat ngumpul, atau tidak sesuai apa yang diharapkan klien, harga dikurangi), kamu buat rules, misal masalah server bukan tanggungjawab kamu, atau apabila klien telat bayar, mesti denda juga :p ya pinter-pinter kamu menyiasati perkara ini.

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