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 🙂

Advertisements

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 🙂

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.

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 ^_^

cara berkomunikasi dengan klien via e-mail

Bagaimana cara berkomunikasi dengan klien by e-mail?

Ada banyak cara yang bisa kita lakukan untuk berkomunikasi dengan klien via e-mail, terutama untuk melaporkan progress pekerjaan kita.

Beberapa tips yang bisa disampaikan :

1. Ketika e-mail request dari klien datang, biasanya ada due date, kapan batas waktunya. Maka kerjakanlah sebelum batas waktu. Kadang kala kita melihat banyak sekali request yang datang, maka prioritaskanlah mengerjakan dari yang diberikan terlebih dahulu dan yang paling mudah. Jika anda sudah pengalaman, biasanya tinggal buka2 hal lama, tinggal edit dan gunakan untuk perkembangan;

2. Biasakan membuat progress report pribadi, buat saja sederhana di excel, misal : kolomnya no, progress yang diberikan, tgl+waktu diberikan, tgl+waktu dikerjakan, tgl+waktu dilaporkan, keterangan. Dengan bgitu anda bisa melihat seberapa banyak yang anda kerjakan per hari, seberapa lama waktu anda mengerjakannya dan seberapa beragam task yang diberikan. Knapa ini penting? kita bisa mentrace dengan cepat, adakah task yang serupa yang pernah diberikan? kalo ada ya, tinggal pake yg sebelumnya. Selain itu, kita bisa saja sewaktu-waktu ditanya atasan apa saja yang kita kerjakan, dan apa saja yang sudah dilaporkan, dan mana yang belum, kadang atasan itu tidak bgitu perhatian mengenai itu, khawatirnya kita disangka tidak bekerja. Dan dengan begitu juga, ketika sudah setahun atau dua tahun, kalo kita lupa apa yang dulu kita kerjakan, kita bisa search dari dokumen tersebut;

3. Ketika melaporkan sebuah pekerjaan, biasakan bahasa yang tegas dan jelas, tidak ada mengeluh kesulitan, tidak ada kalimat bertele-tele, langsung pada pokok permasalahan. Ditambah, apabila memberikan instruksi ke yang kita tuju, gunakan kalimat yang mudah dipahami dan berurut. Layaknya kita memberikan tutorial singkat. Dan gunakan kalimat sopan, baku dan terstandar dengan salam pembuka, isi, penutup;

4. Gunakan e-mail khusus untuk kerja dan pisahkan dari email pribadi. Hal ini juga meminimalisir kesalahan pribadi, gunakan email yang baku, dengan id singkat, supaya berkesan profesional, seperti : namadepan[titik]namabelakang[at]domainemailnya

5. Balaslah e-mail dari klien sesegera mungkin, apalagi teknologi sudah canggih ada smartphone. Biar klien tidak menunggu. Jika belum anda kerjakan, ya balas saja, bilang belum dikerjakan, gak usah takut, tapi ya..dengan kalimat yang elegan. Jangan anda kerjakan dulu, baru balas, otomatis bisa membentuk citra negatif di mata klien.

Berikut beberapa screenshot contoh yang pernah saya pelajari dan terapkan.

6-14-2014 10-11-31 PM 6-14-2014 10-15-40 PM

Fighting Spirit mahasiswa sekarang lemah!

Pelajaran yg saya dapatkan hari ini dari pak Lukito dari ngobrol di plurk.

mungkin banyak orang bisa berbagi ilmu, tp belum mampu mengajarkan mereka untuk mandiri, menyadari hak dan kewajibannya. Hanya fokus pada hal membagi, tidak mengajarkan..
Alhasil, kebanyakan mahasiswa itu fighting spiritnya lemah, kurang menghargai orang lain, menunggu dijemput, bukan datang mencari, dan terlalu fokus pada hal yang ada.

Karena ini lagi musim ributin capres, saya coba berikan analoginya, seperti calon pemerintah yang punya visi : “menaikan tunjangan 3x lipat”, tp tanpa menjabarkan misinya hal-hal yang bisa membuat rakyatnya mandiri, mengajarkan mereka buat lebih berkualitas. Jatuhnya, ketika pemerintah memberikan apa yang rakyatnya inginkan, selanjutnya rakyat nanti akan banyak menuntut pemerintah (manja).

Dan ini ada beberapa contoh yang dihadapi :

“maaf, mas kuota internet sy gk cukup, boleh copy gk mas, kita ketemuan, mas”

“maaf/maklum masih newbie, mas, ajarin dong dr dasar”

“saya googling ga nemu, mas”

“mas ada tutorial bahasa indonesia gk? sy gk bisa baca yg bhs inggris”

“mas, sy pake cara ini, tp gagal, bisa dicekin gk mas, errornya?”

“mas, sy bikin aplikasi kyk gini, itu rasanya kok jd panjang bgt, ada cara singkat gk mas?”

kadang saya gk suka dengan orang yg apa adanya… ujung2nya ada apanya… gk mw usaha lebih keras..
malah bbrp message FB saya diamkan saja pas lagi sibuk ataupun karena terlalu sering mendapatkan seperti itu. Kurang sabarnya saya.

Jaman sekarang, internet murah, hdd murah, jaman sy kuliah, flashdisk max. 128 MB, itupun mahal, duit jg ngepas dikirimnya, internetpun mesti di warnet, krn blm ada model modem dan provider internet murah. Apalagi zaman dosen-dosen kita? 
Yang sewajarnya, mencari informasi itu lebih mudah di zaman sekarang.

Bila tidak bisa bahasa inggris, ya belajar, masih sempat belajar, daripada waktu banyak habis buat ngegame dan berjejaring.

Lalu bagaimana etikanya?
Ini masalah yg saya hadapi dengan panitia sebuah workshop, saya berkeluh kesah di plurk, dan pak Lukito memberikan tanggapan :
“Bilang saja klo anda tdk suka diperlakukan dmk. Tunjukkan bhw apa yg mrk lakukan itu tdk menghargai pembicara..Ttg jadwal, ttg HR, ttg pemberitahuan yg mepet. bbrp panitia mhs sptnya perlu diberitahu ttg adab terkait pembicara, jd ajarilah mrk. Kalau saya, saya ga akan mau disuruh menemui panitia atau mengunduhkan file2 yg diperlukan utk demo..Bukan apa2, tp justru utk ngajarin mrk ttg hak dan kewajiban masing2. Sptnya mhs panitianya blm pengalaman mengadakan acara2 gini ya”

dan ini membawa hikmah ke yang lain, bahwa pentingnya membagi pengetahuan ke yang lain tapi juga mengajarkan, ya mengajarkan mereka tentang hak dan kewajiban.

Jadi, ketika orang bertanya, coba jawab, tp jangan abaikan untuk beritahukan ia bahwa alur belajarnya yg benar ttg ilmu tsb seperti ini.

Dengan memberikan mereka : arah yg benar, cara yang baik dalam belajar, dan juga mengajarkan mereka buat semangat belajar (dengan memotivasi dengan arah yang kita beri tersebut), insya’ Allah, mereka bisa mandiri mencari informasi sendiri.
Karena, mereka tentu tersesat dalam belajar, bingung harus belajar apa dulu. Saya juga dulu mengalami demikian.

Terus ajarkan mereka, “mas, kalo bertanya, sebaiknya spesifik, ke kasus yg dihadapi, jangan minta ajari dari awal, kasian saya nantinya mas, membagi banyak waktu buat mas, padahal saya ada hak dan kewajiban.. Jadi coba aja dulu, pelan-pelan, pelajari dari berbagai sumber..ini saya kasih link-link yang bagus, terus coba bikin aplikasi sederhana, seperti mengganti background, rumus menghitung luas misalnya, atau deteksi lokasi sederhana, baru kalo kesulitan, bertanyalah ke pokok masalah. Jangan dateng-dateng langsung nanya, dan minta ajarin bikin aplikasi yang lebih besar.”

Tp jangan takut juga bertanya, bila mengasyikan, malah terkadang orang yang kita tanyai itu ikut2an belajar dari situ. Apalagi mereka bisa mengakrabkan diri dengan baik. Datang bawa masalah, tentu harus diceritakan kronologinya, sedang buat aplikasi apa, errornya muncul apa, terus input-outputnya apa… jangan datang-datang, copas sourcecode, dan minta carikan errornya 

Semoga ini bisa memberikan pelajaran bersama, khususnya bagi diri saya pribadi. 🙂

Mohon maaf bila menyinggung, semoga tidak dinilai negatif  😀

Sebentar lagi memilih presiden negara kita

Menurut saya pribadi, seorang presiden itu mengenal hal-hal konseptor secara luas, tidak hanya satu dua hal, misal pendidikan, yang dimajukan jangan hanya SMK saja, tetapi semua, dari wajib belajar 9 tahun sampai dengan perguruan tinggi.

Ia juga mampu menyampaikan informasi atau pesan apa yang sebaiknya pendengar ketahui. Oleh karena itu, seorang presiden yang baik adalah presiden yang mampu berpidato dengan wibawanya sebagai seorang presiden, bukan seorang komik. Dan juga tidak mengada-ada atau membuat guyon yang tidak pantas diucapkan oleh seorang presiden. Skill public speaking ini penting, apalagi menyangkut hubungan diplomatis. Karena jika tidak diplomatis, orang lain akan memandang rendah negara kita karena pemimpinnya lemah.

Ditambah untuk hubungan internasional, skill bahasa asing harus dikuasai dengan baik, jangan sampai apa yang disampaikan oleh seorang presiden itu adalah hal-hal yang tidak dimengerti oleh delegasi asing/wakil dari negara asing. Lebih-lebih lagi, walaupun nanti memakai jasa ajudan untuk translator, karena tidak pandai menyampaikan, akhirnya info yang disampaikan translator ke wakil negara asing tersebut jadi keliru. Itu berbahaya.

Semoga calon-calon presiden negara kita Republik Indonesia, yang bernomor urut satu ataupun dua, mampu hal penting ini.
Demi martabat negara kita.

Mohon jangan komentar negatif atau jelek di status ini.
Ingat, kita ini Umat Islam, dimuliakan dengan Islam. Mengolok-olok (Al-Hujurat:11, bawa-bawa keturunan (seorang nabi Nuh as saja anaknya kafir), bawa-bawa harta kekayaan (inget kisah Qarun, Fir’aun), bawa-bawa amalan ibadah (amalan itu diterima/tidak hanya Allah yang Maha Mengetahui), itu tidak dibenarkan dan di larang dalam agama islam.

Ini hanya pandangan saya sebagai seorang profesional TI.

Namun, penting diingatkan untuk saya pribadi dan teman-teman, bahwa kita sebentar lagi akan memilih calon presiden, pilihlah sesuai ajaran agama kita, yang menegakan agama kita, dan prioritaskan pada kriteria seorang pemimpin (khalifah). Kriteria memilih seorang pemimpin (Khalifah) itu sederhana.
cukup dengan empat hal:

  1. Jujur (Shidiq)
  2. Dapat Dipercaya (Amanah)
  3. Cerdas (Fathanah)
  4. Menyampaikan Kebenaran (Tabligh)

Jika tidak ada yang sempurna, maka menjadi tugas kita masing-masing untuk berusaha mencari yang lebih mendekati kriteria ideal di atas.

Dan ini sifatnya Ijtihady, Dzanny (dugaan), bukan Qath’iy (valid). maka perbedaan adalah konsekwensi yang mustahil terelakkan. Wallahu A’lam.

Dan sebentar lagi, masa jabatan bapak presiden Susilo Bambang Yudhoyono berakhir. Beliau sudah banyak berjasa untuk Indonesia. Membawa nama baik untuk Indonesia. Mari kita do’akan, semoga beliau mampu menyelesaikan kewajiban beliau sampai akhir jabatan dan membuat indonesia lebih baik dan semoga apa yang telah beliau kerjakan untuk indonesia ini menjadi amalan yang baik yang membawa pengaruh baik kepada kita semua agar menjadi mandiri, tangguh dan sejahtera, dan amalan tersebut mudah-mudahan diterima oleh Allah. Aamiin Allahuma aamiin.
Terima kasih, pak SBY 🙂

Berikut saya sertakan video pidato pak SBY di Harvard dari VOA-Indonesia  :