RSS

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

[salah kaprah] Beda game bergenre Sandbox dengan Open-World

Yak, masih pada bingung bedain sandbox dan open-world
Jangan ikuti yg kebanyakan beredar, tp ikutilah yg benar :p

  1. sandbox dan open world itu termasuk dalam gameplay non-linear. (cek wikipedia bwt lebih jelas)
  2. sama-sama punya free roam.
  3. Biasanya game dengan style free roam gini disebut sandbox. (ada bbrp sitasi dr penelitian dan buku terkait statement ini, cek aja deh di wiki)
    Namun, sebuah konsep game dgn gaya “open-world” belum tentu game tersebut bergenre sandbox.
  4. Karakteristik di dalam game sandbox itu ya spt yg mas David jelasin : bisa bebas kustomisasi, gak cuma karakter, ntah dunianya, tujuannya, pokoknya semau si gamer. Sbg contoh : minecraft itu termasuk sandbox.
  5. Kalo open-world, ada batasannya kayak MGSV, Tales of series, AC series.

Lah, terus knapa di GTA V dan WD jg masih terbatas? gk bisa ganti kolor doang di butik/toko pakaian, atau nongkrong makan di pinggir jalan? Padahal ada bangunan toko pakaian dan restoran, tp gk bisa dimasukin bebas pilih atau ngancurin tokonya ?! 

maksud bebas kustomisasi di sini adalah..
pemain mempunyai peralatan untuk memodifikasi dunianya si tokoh utama di dalam game dan membuat cara tersendiri dalam bermain. Ya itu tadi, kayak Minecraft dan Garry’s Mod.

Jadi, GTA V dan WD itu termasuk “open world” bukan “sandbox”

 

Referensi :

http://en.wikipedia.org/wiki/Nonlinear_gameplay
http://www.sandbox-games.net/about/
http://en.wikipedia.org/wiki/Open_world
http://www.giantbomb.com/forums/general-discussion-30/whats-the-difference-between-open-world-and-sandbo-421692/
http://www.jasoncarabelli.com/sandbox.html

 
Leave a comment

Posted by on June 21, 2014 in Celoteh, Hobby

 

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

Pernyataan Jokowi soal “panggil programmer 2 minggu selesai” buat kalangan programmer melek dengan e-gov negeri sendiri

well, banyak sekali sisi positif gara-gara statement Jokowi “e-gov, panggil programmer 2 minggu selesai” di debat capres tempo hari. Di kaskus, facebook, twitter, berkumpul dan berdiskusi soal e-gov. Nama “programmer” pun jadi makin dikenal.

Namun, ada banyak gap yg terjadi di kalangan profesional TI, apalagi di kalangan fanatisme kedua kubu capres, akibat dari pernyataan Jokowi tersebut.

Sebagian kalangan mengkritik itu hanya bualan atau kalimat berlebihan dr seorang capres, krn sejatinya membangun sebuah aplikasi tidak hanya terkait programmer dan codingannya, tetapi ada metodologi dan tahapan pengembangan softwarenya, ditambah regulasi dan birokrasi dengan pihak pemerintah.

Namun sebagian kalangan menganggap ini tantangan besar buat indonesia, mereka menyadari bahwa e-gov tidak dikembangkan dalam satu malam, tp bertahun-tahun. Semua sudah jelas, apalagi untuk kalangan IT.

Korea saja misalnya, dr kuliah online pakar e-gov dengan judul “Ten Lessons from Korean Experiences of e-Government”, Professor Sang W. KIM, Ph.D. bilang kalau Pemerintah Korea telah melaksanakan secara berdampingan berbagai master plan, program dan proyek untuk menerapkan “masyarakat berorientasi informasi” secara nasional selama 20 tahun terakhir. Banyak project, dimulai dari 1987 (NBCN) sampai dengan e-gov nya mereka (2001-sekarang)

Di Indonesia sendiri, bbrp informasi yg sy dpt dr berbagai surat kabar online, menyebutkan sudah ada e-gov yang berhasil di beberapa daerah, di Jawa Timur (http://www.surabayapagi.com/index.php?read~Jawa-Timur-Terbaik-Kedua-di-Pemeringkatan-e-Gov-Indonesia). Berhasil di sini maksudnya sudah diuji secara teknis (aplikasi dan jaringan) dan tanggapan masyarakat.

Dan polemik di sini adalah e-gov yang sudah sukses tersebut tidak disosialisasikan oleh pemerintah pusat agar diterapkan di berbagai pemerintah daerah. Pemerintah tidak menjalankannya secara utuh. Alhasil, saat ini yang terjadi adalah tidak ada transparansi di kalangan pemerintah ke masyarakat. (mungkin ini yg dikhawatirkan bbrp elit politik, biar tidak ketahuan belangnya..makanya e-gov tdk dijalankan)

Kalo pak Jokowi memang pernah terlibat dlm pengembangan e-gov dan bilang “panggil programmer, 2 minggu selesai”, maka mungkin sebaiknya perlu diklarifikasi “selesai” di sini utk tahap apanya?  Karena beliau menyebut “programmer” bukan “vendor TI” maka mungkin bisa diasumsikan ini maksudnya “development-nya” (LOL) Drpd para simpatisan debat kusir dan para programmer berasumsi yg rumit-rumit.

Dan kembali lg ke topik yang disampaikan prof. Sang W. KIM, Ph.D, kalau Sistem Informasi tidak dibuat sekaligus, tapi bertahap. Dan suksesnya sebuah sistem informasi itu tidak ditentukan oleh ouput dari Sistem Informasi tersebut, tetapi hasilnya dapat dirasakan dan bermanfaat oleh pengguna. Manajemen data untuk mengelola atribut dalam e-gov harus lebih baik (Membangun Data Warehouse dari OLTP ke OLAP). Dan ini juga dipengaruhi bbrp domain sosial seperti Kepemimpinan (leadership), Strategi (strategi), Hukum & Peraturan (law & regulation) di pemerintah tersebut.

 
Leave a comment

Posted by on June 15, 2014 in Celoteh, Internet

 

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

Pengembangan perangkat lunak dari sisi realita disiplin ilmu TI

X : “mas, aku pgn buat kyk gini, tp kalo aku pake software A, katanya mesti convert ke XML atau pake software B”
saya : “ya, kalo sy memang lebih ringan pake XML, pak, ntar ditaruh di project app.nya”
X : “kalo sy pake software A ini, mas, gimana? saya tuh pengennya kayak aplikasi yg di d*** atau di *****, tau kan mas?”
saya : “yup, pernah pake, pak, install juga kok, malah sy nemu yg lebih bagus lg, smooth di iOS dan Android, tp ya itu tetap saja enakan pake XML atau pake file tambahan dr Adobe AIR (SWF), pak”

Well, sebagai developer, jangan terpaku pada satu tools/software/teknologi saja, ingat, teknologi bisa kadaluarsa, bakal ada terus teknologi2 baru, dan sepantasnya memang kita masih harus terus belajar, biar bisa bersaing.

Ada pernah kejadian : “mas, knapa web servicenya pake rest, pdhal ada SOAP di sini” | “krn rest sdh terbukti lebih ringan, pak” | “lah, kata siapa? teman saya pake SOAP dgn php lancar-lancar aja”
beda case, pak, kalo itu kan infrastukturnya kyk gitu, sedangkan punya kita sekarang terlalu boros kalo pake SOAP. Banyak javascript di sini, kalo pake SOAP, ntar definisiin lg strukturnya di XML dll.. sementara timeline yang ada 3 bulan, pak.”

Nah, satu pelajaran lg, gk bisa kita generalisir satu masalah itu sama dgn masalah lain. Kasus lain, kamu bisa kerjain satu aplikasi dlm 1 malam, liat dulu skala aplikasinya.. krn sejatinya, permasalahan di dalam TI itu beda-beda, tidak bisa semua app itu bisa dalam 1 malam. Maka dari itu, banyaklah bergaul dgn sesama profesional TI, rajin berdiskusi (tidak sekedar bertanya, kadang orang lain jengkel kalo ditanya-tanya terus), dan kembangkan (sambil latihan terus).

Seseorang ingin dibuatkan aplikasi dgn metode re-use, kalau developer sebelumnya rapih dalam mengerjakan dan terstandar, enak, developer lain yg melanjutkan tidak akan keteteran, apalagi kalo dokumentasinya jelas dan lengkap. Tapi kalo yg sebelumnya develop gk selesai, ditinggal programmernya, terus developer yg baru disuruh gantiin dan lanjutin, apalagi tidak ada dokumentasi, dan mesti baca-baca codingan developer sebelumnya yg berantakan, apa gk stress tuh developernya? 

Kalo yang pernah saya hadapi di bank-bank (dulu kebetulan jd developer asp.net di Plasmedia kliennya bank kabeh | loh knapa skrg jd dev. Android? gk laku y? | klo sy skrg msh jd dev. asp.net, mungkin sy msh jomblo, mas soalnya hidupnya kost-kantor-mall-kost-kantor-mall, pas ramadhan aja, terawih gk pernah sempat, buka puasa sering di jalan/di kantor, makanya pas ada kesempatan S2, sy beraniin diri resign dan nyambi2 di jogja, eh alhamdulillah, salah satu klien sy, dr Pusat Kajian Hadis Jakarta menarik sy, skrg bs kenal ust. Lutfi, ust. YM, ust. Arifin Ilham, dll, sambil belajar agama dr beliau2 tsb), mereka (tiap bank) sudah punya core sistemnya, mereka tidak akan mengganti core sistem dan itu tetap berjalan (bahkan ada upgrade core sistem berkala), ketika ada penambahan aplikasi/software, ya biasanya tinggal re-use dengan beberapa penambahan modul dan desain sesuai pakem (guide book) yang sudah diberikan mereka. Dan itu bisa cepat selesai, bahkan untuk aplikasi besar, bisa 1-2 bulan kelar (bukan satu malam/2 minggu, krn birokrasi, kesiapan database, server, sampai konfigurasinya, dsb juga butuh waktu). Tapi gak tau juga ya kalo di tempat lain, pernah sm temen-temen grup PPP di DepKeu, denger-denger sampe ada debat internal antar pejabat dirjen. Itupun ngurusin database sampe cronnya juga njelimet di birokrasi. Syukur PMnya mental baja bisa ngadepin mereka. Dan 3 orang developernya : mas Mulia, Radita dan Nur Hidayat juga handal dalam development app.

“halah banyak ngomong, yg penting ngerjain!” |  “nah iya, yg penting kerjain, anda sudah pernah ngerjain yg kyk gitu belum? mengerjakan sesuatu itu harus rapih, tdk bisa asal jadi, tepat sasaran untuk stakeholdernya, tepat guna dalam fungsi, teknologi dan biaya. Karena sejatinya, software itu mesti memiliki prinsip : useful, usable dan beautiful. Dengan proses bisnis yang tertata dan metodologi yang tepat sehingga siklus pengembangannya berjalan sesuai rencana”

Satu lagi..software personal jelas beda dgn software pemerintahan. software setipe front-end jelas beda dengan setipe backend.
Satu teknologi di satu tempat itu cepat, belum tentu di tempat lain jg cepat. Ada beberapa karakteristik dan parameter yg mendukung/menghalangi hal tsb. untuk bisa dikatakan itu cepat/lambat.

Ada kalanya kita sbg. developer sudah berbuat sesuatu utk klien, tp kurang puas dgn hasil kerja keras sendiri krn terkendala waktu yang diberikan sedikit, ada kalanya kita nemu kelompok developer yang diberikan waktu banyak, tp ngerjainnya asal-asalan, yang penting duitnya turun..alhasil tidak dipakai dan merepotkan user. Dan banyak kejadian-kejadian dengan plot twist yang dihadapi developer. “Kalo ketemu klien yg awam TI, minta cepet, ya garap aja, kalo ntar klien ngerasa tidak puas atau kurang pas, tinggal buka penawaran baru” 

Yang jelas, teruslah berusaha sebaik mungkin, jangan pesimis, kalo ada orang berusaha menjatuhkan, coba gerak terus saja. Dan satu hal, tidak ada salahnya mendengar dan belajar dari yang sudah berpengalaman/ahli biar makin meningkat ilmu yang kita pelajari, dan tentunya jadi bermanfaat lebih luas hasil yang kita kerjakan.

 
Leave a comment

Posted by on June 14, 2014 in Celoteh, Programming

 

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

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

 
Leave a comment

Posted by on June 14, 2014 in Celoteh, Internet

 

Tags: , , , , , , ,

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  😀

 
3 Comments

Posted by on June 6, 2014 in Celoteh

 

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