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 ­čÖé

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

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.

6 pelajaran hidup yang dapat kita pelajari dari seni pemrograman

  1. Flow Chart sederhana adalah segalanya
    Sama halnya seperti seorang programmer, ketika kita dihadapi masalah besar, sebisa mungkin dipecahkan menjadi bagian-bagian terkecil, Baru dengan mudah kita dapat mengambil keputusan atas masalah tersebut.
  2. Setiap hal ada tempatnya.
    Selalu, ktika kita men-develop aplikasi, tentu di tahap awal kita menempatkan variable2 yang ingin kita pakai beserta tipe datanya (inisialisasi), begitu jg hal lain, slalu ada tempatnya, semua ada aturannya.
    Sama seperti kehidupan nyata, di mana letak tempat menaruh peralatan kerja, menaruh makanan, menaruh permasalahan kantor ya di kantor, bukan di rumah, dan sebagainya.
  3. Re-use/menggunakan kembali module yang sudah ada untuk menghemat waktu
    Setiap programmer yg baik akhirnya belajar bahwa ketika sudah membuat sebuah function ataupun module, dapat digunakan kembali untuk pengembangan aplikasi yang lain/berikutnya. Jadi menghemat waktu tentunya
    Henry Ford pernah berkata tentang Model T, “Setiap pelanggan dapat memiliki mobil dicat warna apa saja yang dia inginkan, asalkan itu hitam.”
    Alasan ini yang dipake Ford untuk merakit mobil dan membuat produk-produknya keluar pintu lebih cepat jika ia bisa menggunakan kembali peralatan yang sama (cat warna yg sama) tanpa harus menciptakan proses setiap kali mobil baru dibuat.
  4. Dokumen(tasi) adalah segalanya
    Kalo programmer yang “khilaf” ­čśÉ dokumentasi itu malah diabaikan, atau malah dikerjakan pas aplikasi selesai ­čśÉ sama aja boong :)) keasikan ngoding sih jadinya males, malah terkadang dianggap repot ­čśÉ “gak ah, mending ngoding aja, ntar jg gampang diinget-inget, gak taunya mesti tracing code lagi”
    Sebenernya dokumentasi itu penting, dengan adanya dokumentasi, kita mencatat setiap hal yg kita perbuat dengan aplikasi itu, apa kesalahan dan perbaikannya, apa fungsi-fungsinya, dan tau tata letaknya, jadi mempermudah developer lain (berikutnya) untuk mengembangkan, dan bahkan bagi user.
    Sama seperti sehari-hari, terkadang jadwal penting, rutinitas sehari-hari, dan apa saja yang mesti dilakukan perlu dicatat di dalam sebuah catatan/agenda, memudahkan anda mengingat dan tidak tertinggal satu halpun.
  5. Jangan terjebak di satu situasi yang buruk.
    Ketika aplikasi mengalami looping gk berujung, process CPU jadi tinggi, dan tentunya si programmer harus mencari alternatif cara agar aplikasi berjalan lancar. Begitu jg dengan kehidupan nyata, ketika sudah merencanakan sesuatu, tau2 datang hal yg tidak diprediksi, satu2nya cara adalah menyiapkan “skenario terburuk” dari rencana itu, jadi tidak stuck di situ saja.
  6. Free Up Memory ketika kamu selesai.
    Kalo buat aplikasi, misal aplikasi Android, terapin masalah service, yang jelas setiap execute dalam durasi beberapa waktu, butuh free-up memory, agar app.tersebut tetap efisien ketika berjalan. Jika tidak, bakal makan banyak memory.
    Di kehidupan sehari-hari, sama juga, abis kerja, abis makan, cepetan diberesin dan dibersiin ruangannya, jangan sampe numpuk sampah, peralatan kerja berserakan, dsb. Malah buat aktifitas berikutnya jadi lambat.

Seputar Manajemen Proyek TI (bag.2)

Alhamdulillah, bisa nge-blog lagi. Kali ini saya mencoba melanjutkan tulisan sebelumnya di bagian pertama.
Jika di bagian sebelumnya, saya membahas Q & A seputar ManPro TI. Kini saya mencoba menjelaskan hal yang paling mendasar dari Manajemen Proyek IT itu sendiri.

Apa sih Manajemen Proyek? Kita mengetahui manajemen ya melakukan dan mengatur (doing and control), namun bagaimana dengan proyek? apa hal yang bisa dikatakan itu sebagai proyek? adakah kunci atau point-point utama dalam proyek itu sendiri?

Proyek TI sendiri memiliki ciri-ciri utama yaitu : direncanakan, memiliki batasan (biaya dan waktu), tujuan atau target (goal), tindakan (implementasi dan control), bersifat sementara (dalam satu garis waktu; timeline. Kalo seumur hidup, itu bukan proyek namanya :p ), ada aktornya (pihak eksekutif, client/sponsor, vendor/tenaga pelaksana yang terangkum dalam deliveriable), dan yang terakhir mengandung kata “business”.

Manajemen Proyek ini dipimpin oleh seorang Manager, yang tentunya sudah tentu memiliki skill manajemen yang bagus dan memiliki jam terbang yang tinggi di dalam dunia perproyekan. Lantas apakah bisa seseorang yang baru bergabung dalam ManPro bisa menjadi manager? bisa iya, bisa tidak. Jika, ia memiliki karakter pemimpin, mampu mangatur setiap tindakan yang ada dalam proyek, termasuk bertindak cepat tentunya. Bisa dijadikan sebagai manajer (namun masih junior), dan itu perlu didampingi oleh yang senior.

Managers do things right, leaders do the right thing

Pengelolaan proyek TI harus seimbang antara Scope (Lingkup Pekerjaan), Cost (biaya), Resource (sumber daya) dan Time (Waktu). Dan peran pengelolaan dipegang oleh seorang Manajer Proyek TI tersebut.

Adapun goal yang harus dicapai oleh pihak vendor, terutama oleh si Manajer adalah mampu memenuhi kebutuhan dan memuaskan pihak client. Bentuk kepuasan itu terletak pada :

      • Scope atau Lingkup Pekerjaan. Apakah proyek yang sudah dikerjakan sesuai dengan cakupan yang diminta pihak client? Jangan sampai kurang, jangan sampai lebih, diusahakan pada tingkat yang pas. Jika kekurangan, tentu akan mengganggu kestabilan software yang dibangun, ntah itu fiturnya tidak lengkap, atau kurang bagusnya code/design, dan sebagainya. Atau kelebihan? misal : konsumen meminta kepada tukang jahit untuk dibuatkan celana dengan bahan yang sudah ditentukan, kemudian tukang jahit melihat bahannya masih banyak sisa, kemudian bahan sisa tersebut ditambahkan ke celana yang sudah jadi dengan motif bunga-bunga misalnya. Kan jadi gak sesuai scope ­čśŤ Ya, dalam industri TI juga demikian, ketika pihak vendor meminta dibuatkan web untuk perusahaannya, harus pas sesuai yang diminta (requirement), jangan dilebihkan dengan hal-hal yang tidak perlu. Di awal, client akan bercerita (user stories) apa dan kapan yang ia butuhkan, dan apa yang tersedia dan yang perlu disediakan. Inilah yang menjadi kunci awal untuk menjadi milestone yang dipegang pihak vendor TI, tentang apa saja yang dikerjakan pada tahap execution project┬átersebut.

Tahapan project itu biasanya : opening Project>brainstorming (kick-off meetings bahas concept; user stories) > planning > execution > control > closing Project.

      • Time atau waktu. Bila disiplin dengan metode pengembangan software yang sudah ditentukan, biasanya bisa ontime. Namun, terkadang luput dari sasaran yang sudah ditentukan. Bisa banyak sebab, bisa jadi karena Resource-nya yang kurang. Ntah itu infrastruktur yang disediakan yang kurang memadai untuk digunakan, atau SDMnya yang kurang banyak atau terlalu banyak sehingga komunikasinya terhambat, atau karena kehabisan/tersendaknya biaya yang dikeluarkan oleh pihak client. Ada baiknya diperhatikan betul waktu yang dibutuhkan untuk mencapai setiap cakupan (scope) tersebut. Baiknya ya dari pengalaman. “eh, dulu kita ngedevelop fitur x berapa lama y?” | “oh waktu itu 2 minggu, pak” | “ok, bisa kita coba 17 hari, kita lebihkan 3 hari untuk mencegah hal-hal yang tidak diinginkan”.
        Namun, dilihat juga berapa panjang timeline yang diberikan client, berapa banyak fitur yang dikerjakan dan berapa SDM yang tersedia.
      • Cost atau biaya. Dalam menentukan biaya, ada banyak faktor yang perlu diperhatikan. Saya tidak akan menjelaskan secara detail, namun setiap menentukan biaya itu ada peran “pengalaman” atau “jam terbang” atau “portofolio” yang bermain di sini. Semakin tinggi, harga yang ditawarkan semakin tinggi pula. Tentunya, dengan tinggi pengalaman, teknologi dan metode yang dipakai tentu sudah baik, tepat dan berkualitas. Dan tentunya, pihak client juga sudah “jatuh hati” pada pandangan pertama setelah mengetahui portofolio yang telah dikerjakan. Selain itu, berapa banyak deliveriables dan personil yang menjadi aktor di dalamnya menentukan besaran biaya yang dibutuhkan untuk investasi tersebut. Setiap posisi dalam aktor yang mengerjakan memiliki harga yang berbeda. Dan itu sudah disepakati melalui kontrak kerja. Ada yang menentukannya melalui work unit. Misal : harga per work unit : Rp 100.000 untuk seorang programmer. Si Programmer bekerja selama 5 hari dengan 8 jam kerja. Berarti work unitnya : 5 * 8 = 40 work unit. Kemudian menentukan harga si programmer dengan : 40 work unit * Rp 100.000 = Rp 4.000.000,-
      • Quality atau Kualitas. Banyak yang beranggapan, kualitas ini tidak termasuk dalam bentuk kepuasan dari client tersebut. (ya tergantung, kalo proyek atas dasar kepentingan pihak tertentu, yang penting asal jadi aja…biasanya kualitas itu malah hilang :p) Semakin baiknya kualitas, tentu lifetime dari software tersebut bisa berlangsung sangat lama. Dan tentunya, pihak client menjadi “terpesona” dengan apa yang sudah dibuat, dan meningkatkan rate biaya juga ­čśÇ Tetapi, kualitas bukan hal yang sederhana, untuk membuat software yang berkualitas, dibutuhkan jam terbang yang tinggi, mengikuti trend teknologi dan cakap dalam hal merancang, membangun dan memelihara software itu sendiri.

RBT = Resource, Budget, Time => “on time, on budget, to the specifications”

Portofolio menunjukan jati diri kita, apa yang sudah dikerjakan. Dan ini lebih ke arah strategic business ke client.

Agar sukses mencapai tujuan tersebut, ada beberapa hal yang diperhatikan, yaitu :

  • Tools yang dimanfaatkan harus tepat, tools di sini meliputi tools untuk manajemen proyeknya tersebut. Kalau biasa dengan produk Microsoft, mungkin bisa mencoba Ms. Project, atau dengan produk opensource seperti Redmine. Adapula tools yang lain, seperti CASE (Computer Aided Software Engineering) tools : Enterpisce Architect, Rational Rose, Power Designer, dll.
  • Selain itu, perlu digunakan metode formal dalam manajemen proyek TI. Tiap perusahaan menggunakan metode atau pendekatan berbeda dalam melaksanakan aktivitas proyek TI. Itu tergantung pada kenyamanan mereka bekerja dan jam terbang masing-masing. Namun, ada baiknya disesuaikan dengan kondisi proyek tersebut, ntah itu kondisi personilnya, biayanya, timelinenya dan apa yang akan dibuat.
    Metode Software Development yang banyak digunakan adalah metode Agile. Ada yang menggunakan XP (eXtreme Programming), Scrum. Selain Agile juga ada yang masih memanfaatkan metode classic, matematis ataupun waterfall (eh, waterfall bukannya biasa dipake anak-anak kuliah? ­čśŤ )
  • Peran pimpinan proyek (project manager) dalam mengatur dan mengelola proyek itu sendiri sehingga prosesnya berjalan dengan baik (tiap proses menghasilkan sesuai target). Mampu berkomunikasi dengan baik dengan personil, menumbuhkan kesan dan pengalaman berarti untuk soft-skill tiap personil dan tentunya mampu menjalin hubungan bisnis yang baik dengan client maupun personil.┬á
  • Pengukuran kesehatan project sedini mungkin. Bentuk pengukuran ini dapat diperhatikan dengan tingkat kepuasan client untuk setiap progress proyek itu sendiri, apa yang sudah dikerjakan, bagaimana hasilnya, bagaimana waktunya, tepat waktu dan benarkah? Bagaimana dananya? apakah menipis? biasanya bila dana menipis, ya kesehatan project terganggu, dan mempengaruhi aspek lain juga (time dan resource).

“Project dikendalikan oleh strategi, dapat dilakukan bagaimana setiap project dapat fit dengan strategy business, menghilangkan yang tidak dibutuhkan sesegera mungkin. Dan sedapat mungkin menggandeng stakeholders. Mengabaikan stakeholders sama saja membuat project gagal.” -Robert Butrick

Sumber : dari berbagai sumber, pengalaman di lapangan dan dari perkuliahan ­čÖé

Tips Seputar Menulis Laporan Penelitian atau Tugas Akhir

Tugas akhir menjadi bagian yang tidak terpisahkan bagi mahasiswa yang ingin melengkapi langkahnya menuju Sarjana. Berikut ada beberapa tips sederhana seputar menulis laporan penelitian yang setidaknya bisa membantu teman-teman dalam menyelesaikan tugas akhir. Dan untuk menghindari banyak revisi dalam hal tulisan.

Pahami dahulu setiap bagian dari tugas akhir, misal pada BAB I Pendahuluan yang umumnya berisi :

  • latarbelakang masalah,
  • rumusan masalah,
  • batasan masalah,
  • keaslian penelitian,
  • tujuan penelitian,
  • manfaat penelitian,
  • sistematika penulisan.

Biasanya mahasiswa sering kali menuliskan latarbelakang yang tidak berhubungan dengan topik Tugas Akhir yang ia akan jalankan. Latarbelakang haruslah menjadi bagian pengantar yang mendasari mengapa Tugas Akhir tersebut harus dilakukan.

Kemudian pada bagian rumusan masalah semestinya harus mengungkapkan sesuatu yang penting yang menuntun pada penyelesaian masalah. Bagian ini kadang-kadang berupa suatu pertanyaan yang akan dijawab melalui penelitian. Bentuk kalimat Rumusan masalah adalah kalimat deklaratif (problem statement), bukan kalimat tanya (research question). Sedangkan pertanyaan harus ditempatkan di bagian pertanyaan Tugas Akhir.

Untuk bagian batasan masalah, harus diperhatikan dengan cermat oleh si mahasiswa, karena bagian ini membantu mahasiswa agar penelitian atau Tugas Akhir yang ia lakukan, lebih mudah dalam penarikan kesimpulan serta menjaga agar mencerminkan permasalahan yang dihadapi. (Dengan kata lain, agar permasalahan dan cakupan masalah yang dihadapi di dalam Tugas Akhir tidak melebar atau keluar jalur)

Untuk bagian tujuan dan manfaat, mahasiswa sering kali terbalik mengungkapkan tujuan dan manfaat. Tujuan tidak sama dengan manfaat. Tujuan itu mengungkapkan target apa yang hendak dicapai oleh mahasiswa dalam penelitian atau Tugas Akhirnya tersebut. Tujuan penelitian juga tidak bersifat pribadi, jadi harus dihindari tujuan dari sisi mahasiswa, tetapi tujuan mengapa penelitian itu harus dilakukan.
Sedangkan manfaat, menekankan pada manfaat apa yang didapat diperoleh dari hasil penelitian tersebut (lebih kepada perkiraan apabila tujuan penelitian tercapai), dan lagi-lagi tidak secara pribadi, namun umum, misal manfaat untuk user yang menggunakan software yang sudah dikembangkan, dan sebagainya.

Dan terakhir, sistematika tulisan ini mengungkapan setiap urutan bab yang terdapat dalam Tugas Akhir yang disertakan penjelasan singkat dari masing-masing bab tersebut.

Ada hal lain juga yang harus diperhatikan mahasiswa Tugas Akhir, yaitu :

  • penggunaan kata-kata dalam bahasa indonesia yang baku, penulisan kalimat sesuai standar kalimat : SPOK (Subjek Predikat Objek Keterangan), dan apabila terdapat istilah asing, harus dicetak miring (italic);
  • hindari penggunaan kata yang tidak perlu, atau bila perlu hapus saja agar menjadi kalimat yang sederhana. Biasanya sering dijumpai, mahasiswa menuliskan kalimatnya memiliki kata yang berulang seperti kata : agar, supaya, namun, tetapi, dll. Yang tidak pas apabila dibaca;
  • pahami perbedaan imbuhan di- dan kata depan di. Sering kali dijumpai mahasiswa tidak mengerti apakah di yang dipakai adalah imbuhan atau kata depan yang menerangkan tempat. kata “diatas” adalah keliru, karena kata tersebut menunjukan arah/tempat, berarti bukan memakai imbuhan di-, tetapi kata depan di. Sehingga, kalimat yang benar adalah “di atas”. Kata “di mulai” juga keliru, yang benar adalah dimulai, karena mulai bukan menunjukan tempat, melainkan kata kerja. Dan masih banyak contoh lain, jadi harap diperhatikan ya ­čÖé
  • hal lain adalah menuliskan kata yang kurang pas. Seperti : “data-data yang dipakai”, padahal data adalah kata jamak.┬á Jadi yang benar adalah : “data yang dipakai”
  • apabila ada dua kata : tanggung jawab bertemu awalan dan akhiran, misal : di- dan -kan. Yang benar adalah dua kalimat tersebut melebur menjadi : dipertanggungjawabkan, bukan dipertanggung jawabkan. Dan masih banyak contoh lain ­čśÇ
  • apabila ada dua kata dalam kata bahasa asing yang ternyata terdiri dari satu kata atau sebaliknya, misal : database. Yang benar adalah : basisdata, bukan basis data. Ada pula contoh lain, remote : yang benar adalah : jarak-jauh, bukan jarak jauh.
  • Biasakan ketika sudah menyusun satu bab dalam laporan Tugas Akhir, dicetak, kemudian jangan langsung dibaca. ­čśÇ Coba jalan-jalan santai sejenak, refreshing atau melakukan aktivitas lain, kemudian ketika pikiran santai. Coba baca kembali bab laporan Tugas Akhir yang sudah kamu cetak, biasanya akan menjadikan si mahasiswa menyadari bahwa kalimat atau paragraf yang ia susun itu keliru, nah dari situ, tandai setiap kekeliruan dalam penulisan, lalu lakukan corat-coret untuk me-revisi laporan Tugas Akhirmu. Jika sudah, coba dibaca lagi, apakah sudah pas susunan kata dan kalimatnya di dalam paragraf, apakah satu paragraf dengan paragraf yang lain berhubungan atau tidak. Dan baru deh, menghadap dosenmu dengan yakin dan percaya diri. ­čÖé

Semoga tips-tips ini dapat membantu.

Sumber dari semua ini adalah dari perkuliahan Metodologi Penelitian oleh Pak Abdul Kadir dan Pak Insap Santosa, dosen-dosen JTETI UGM. Tidak sepenuhnya ditulis, namun disampaikan seadanya. Apabila ada kekeliruan di dalam penulisan artikel ini, itu murni kekeliruan penulis. Penulis mencoba menyampaikan dengan bahasa yang santai agar mudah dibaca, insyaAllah. ­čÖé

Terima kasih.

Masih seputas Manajemen Proyek – Masalah alokasi RBT (resource budget time)

Di dalam project management, ada yg namanya Critical Path Method (CPM), di mana dipakai sebagai alat untuk mengeset aktivitas-aktivitas di dalam proyek agar berjalan efektif.
Kasusnya yang terjadi adalah ketika 1 team vendor terpaksa merombak 1 module, ternyata berdampak “keterpaksaan” merombak module-module lain. 1 module fail, yang lain ikut-ikutan fail.
Masalah ini dapat dicegah, dengan sistem arsitektur yang baik. Untuk itu perlu dilakukan tahap-tahap berikut :

  1. Siapkan RBT (resource+budget+time) yang cukup.
  2. Buat list modules dan aktivitas-aktivitas di dalamnya. Dengan cara mem-breakdown permasalahan/kebutuhan client. Meneliti/menganalisa bobot setiap pekerjaan, terutama module depedency (critical item, depedencies between activities) yang dapat mempengaruhi module-module lain. Dari berbagai pengalaman biasanya mereka membuatnya dalam bentuk “sticky-notes” kecil di kertas kemudian di tempel di papan whiteboard, mereka lihat setiap aktivitas tersebut, kira-kira pas tidak dipasang di timeline dalam waktu x misalnya, jika tidak cocok, tinggal lepas perekat note tersebut, ke timeline yang lain. ­čÖé
    Namun ada tools yang berguna berbasis web : www.trello.com. Di Project Management Software – redmine juga ada.
  3. Tentukan cricital item dg melihat workflow module. Dan Tentukan bobot/durasi dari setiap aktivitas tsb.
    Setiap workflow module punya work unit. Sebagai contoh : 4 orang dengan 5 hari kerja (@8 jam), maka Work Unitnya = 4 * 5 * 8 = 160 work units.
    So, jika module login butuh 32 work units, utk 2 programmer. Berapa durasi waktu (hari) untuk pengerjaaan modul login tersebut? =>32/8*2 = 2 hari.

Ketika langkah tersebut sudah diambil, tinggal pelaksanaannya, sesuai dengan yang dirumuskan di atas (sudah dalam bentuk timeline dan scope yang jelas). Semua itu dapat berjalan lancar, dengan resource yang memadai, dan tentunya dengan komunikasi yang baik antar team ­čÖé