Mengapa waktu proyek tidak dapat dihitung dengan pasti?

Pengembangan software ataupun aplikasi itu tidak pernah menggunakan ilmu pasti.

Untuk waktu pengerjaan proyek dan biaya proyek juga selalu menggunakan estimasi: estimasi waktu dan estimasi harga.

Di luar sana, selalu menggunakan pendekatan “agile”, di mana interaksi antara tim pengembang dengan tim user ataupun klien lebih penting daripada proses.

Mengapa demikian? dengan kita berinteraksi, persepsi tim pengembang dengan tim “user”/klien akan selalu seirama.
Itulah mengapa terkadang walau sudah kita definisikan rancangan sistem dari “software” ataupun aplikasi di awal, pas di proses terkadang ada saja perubahan atau tidak tepat 100% sesuai dengan rancangan awal, mesti ada yang bergeser. Ini dikarenakan apa yang ditangkap tim pengembang dengan apa yang disampaikan tim “user”/klien ketika menyampaikan “scope” pekerjaan ataupun masalah yang harus diselesaikan, tidak semuanya 100% sama.

Contoh: tim klien meminta dibuatkan rumah yang ada tangganya. Tim developer menerjemahkan maksud dari si tim klien tangga kayu vertikal. Padahal, yang dimaksud tim klien adalah tangga spiral terbuat dari besi (ini contoh sederhana saja).

Jika di awal terlalu detail mendefinisikan semua, yang ada waktu akan banyak terbuang. Itulah mengapa pekerjaan pengembangan software dilakukan bertahap dan ada batas waktu, selanjutnya ya tinggal evaluasi bersama. Dan penting juga bagi tim developer memahami apa masalah klien dan apa solusi yang tepat (tidak harus menuruti 100% keinginan klien, karena terkadang sebenarnya klien juga tidak memahami masalahnya sendiri).

Nah, itulah mengapa pentingnya dipahami bersama jika waktu dan harga proyek itu tidak bulat sama dengan yang direncanakan di awal, mesti ada perubahan, ya lazimnya kalau ada tambahan “task”, di-charge di akhir, biar fair. Atau dibuat per fase, jadi kalau ada pekerjaan tambahan, dilanjutkan di fase kedua (tergantung prioritas).

Demi mencapai hal tersebut, biasanya ada “daily meeting/call”, “weekly meeting/call”, laporan dwi-mingguan, dll. demi mencapai target yang diinginkan agar semua tetap pada tempo-nya, pada prinsip yang sama, dan tetap “on-track” sesuai “task” pekerjaannya.

Tim klien juga harus menyadari, tidak bisa menuntut “loh, kok molor, kan di kontrak kerja targetnya tanggal sekian” | “pak, itu yang di proposal kami dan di kontrak kerja sudah kami sampaikan kalau itu estimasi. Bapak juga mestinya paham, di tengah proses pengembangan kemarin, bapak minta perubahan di bagian form tertentu, itu tentu memakan waktu dan mempengaruhi timeline dari pekerjaan ini. Tidak bisa sama waktunya, pak. Ibarat bapak bangun rumah, bapak minta tambahin garasi mobil, yang sebelumnya minta garasi motor, tentu akan merubah requirement yang sudah disepakati, meskipun sama-sama garasi”.

Di tambah lagi, terkadang di tengah proses, ntah tim klien ataupun tim developer, “discover” sesuatu yang lebih baik, ntah berdasarkan “feedback” dari “end-user”-nya, ntah karena sudah terlihat wujud desainnya, dirasa kurang pas, dan lain sebagainya.

—————————————-

Apakah perubahan di tengah proses dapat diatasi dengan menambah personil? belum tentu, terkadang “transfer knowledge” sampai dengan progress terakhir itu butuh waktu bagi personil baru, dan bahkan untuk “menyamakan tempo” saja butuh keahlian khusus, tidak semua bisa. Paling aman ya waktunya yang bergeser, atau personil baru mengerjakan “task-task minor”.

Oleh karena itu, penting dipahami bersama, masalah waktu dan harga di dalam proyek itu hanya bisa dihitung sebatas estimasi saja (lazimnya seperti itu), dan harus mengetahui resiko-resiko(resiko teknis, “scope” pekerjaan, SDM, man hour, dll) dari setiap keputusan perubahan yang diambil di dalam pengembangan aplikasi atau software.

Advertisements

Port Forwarding In Nintendo Switch

For those who has a problem when playing Splatoon 2 on Nintendo Switch, i think i figured it out the problem.

The problem is when you got NAT type “C” or worst type “E”, you could connecting to Splatoon multiplayer match. The game uses P2P for connection management, and if the required ports is closed, you could join any match in the game. So basically, the NAT type on Nintendo Switch is represent what port and protocol that open for playing this game. If all the required ports and protocol open, you will get NAT type “A”, and if several ports and protocol open, you will get NAT type “B” or “C”, and if the required ports and protocol are close, you will get NAT type “D” or “E”.

So how to upgrade your internet NAT type to NAT “B” or the best “A”?

Here’s the method to do that:

Access your router configurations using web browser (usually on IP: 192.168.1.1), login and search the configuration of “Port-forwarding”. After that, you need to open ports range between 45000 till 65535, and don’t forget to using UDP protocol. Make sure that your port range and protocol input is correct, and then restart your router. And then check your Nintendo Switch Internet connection again. Goodluck!

 

Port-forwarding

Penjelasan Soal NAT di Dalam Nintendo Switch Beserta Penanganannya

Kalo ada orang jaringan (network engineer) di sini mesti bisa jelasin lebih mudah apa itu NAT. Apalagi yang sudah CCNA certified
Jadi begini, apa itu NAT?
NAT atau Network Address Translation adalah suatu metode atau salah satu protocol di dalam jaringan untuk menghubungkan lebih dari satu device ke jaringan internet dengan menggunakan satu alamat IP (melalui router).
Router internetmu akan menggunakan NAT tersebut untuk menyimpan setiap catatan (log) dari semua request device yang terhubung ke jaringan router tersebut, dan kemudian mengirimkan semua request tersebut ke server yang dituju (dalam hal ini server Nintendo) di internet. Request ini kalau dalam game bisa berupa request ID/user ide pemain di dalam game multiplayer, request data pergerakan pemain, dsb. Ketika routermu menerima respon dari server (dari internet), kemudian router tersebut mengirimkan respon-nya ke perangkat yang sesuai. Ya, yang request si Switch yang nerima juga tentu si Switch.
Dengan banyaknya request tersebut dan banyaknya perangkat yang terhubung ke internet dan terutama server Nintendo, untuk itulah diperlukan pengklasifikasian NAT (NAT juga dapat membedakan mana IP public dan mana IP static).
Mengapa pengklasifikasian NAT dilakukan? salah satunya, agar menjamin komunikasi antar device (dalam hal ini Switch) dapat berjalan lancar sesuai dengan type NAT-nya.
Mengapa Nintendo, Sony, dan Microsoft melakukan klasifikasi NAT ini? ya karena beberapa provider internet tidak mengizinkan NAT dibuka (biasanya port diblokir), atau bahkan dibatasi oleh vendor tersebut, jadi kalau NAT-nya gak OPEN ya bakal susah melakukan koneksi ke server.
Nah, di dalam dunia games Nintendo Switch, klasifikasi NAT adalah sebagai berikut:
    1. NAT type A (dalam hal ini OPEN): artinya kamu akan mendapatkan skala 1:1 mapping port di dalam jaringan, koneksi tidak terblokir. Buat nge-game splatoon gak masalah.
    2. NAT type B (dalam hal ini OPEN tapi mengerucut ke MODERATE): artinya koneksi tetap berlangsung dari device ke server namun terjadi di belakang NAT, dalam hal ini console Switch bakal terkoneksi ke server STUN punya Nintendo. Buat nge-game Splatoon mestinya masih OK, gak masalah.
    3. NAT type C (dalam hal ini MODERATE, yang mengerucut ke Strict): artinya koneksi terbatas hanya pada port yang dibuka saja, jadi kalau ada gamer dengan koneksi dan port yang sama ya dapat terhubung. Sayangnya Splatoon menggunakan port yang acak, jadi ya kalau port-nya gak cocok gak bakal bisa konek ke server Splatoon (gak bisa main multiplayer). Buat nge-game Splatoon ya nasib-nasib-an.
    4. NAT type D & E (dalam hal ini STRICT): artinya routernya tidak ada pengaturan NAT, alias sepenuhnya diatur oleh ISP (provider internet-nya), yang model gini biasanya sangat-sangat terbatas.

Klasifikasi NAT
Untuk tipe NAT C sampai dengan B, sebenarnya ada cara dan masih memungkinkan untuk bisa naik ke type A. Karena NAT ini berhubungan dengan settingan Port, maka kamu harus melakukan port-forwarding.
Apa itu port-forwarding?
Fitur dari router di mana fungsi ini akan membuka akses terhadap perangkat pada jaringan lokal untuk bisa diakses dari internet) di router ISP-mu. Bila di console sebelah dikasih tau port berapa aja yang harus dibuka untuk device tertentu, sayangnya di Nintendo Switch sampai saat ini belum diketahui (Nintendo belum memberitahukan port apa saja dan protocol apa saja yang harus dibuka).
Nah, langkah lain adalah membuka semua port untuk koneksi yang masuk dari internet.
Biasanya di pengaturan router ada yang namanya pengaturan NAT type: “full-cone NAT”, yang berarti semua tipe NAT di mana port-nya dibuka secara permanen (OPEN) dan mengizinkan permanently open and mengizinkan semua koneksi dari luar.
Namun, ada beberapa router tidak menyediakan hal tersebut, akan tetapi menyediakan menu untuk pengaturan port-forwarding. Di menu port-forwarding tersebut, kita diminta mengisi IP address device dan port yang ingin dibuka, seperti pada gambar di bawah ini:
Contoh pengaturan PORT FORWARDING untuk console sebelah
Nah, seperti yang sudah dituliskan;disampaikan sebelumnya kalau kita tidak mengetahui port berapa saja yang harus dibuka. (*ada pembaharuan tulisan ini, cek di bawah ya untuk pengaturan port-forwarding di Nintendo Switch)
Untuk itu, pengaturan lain agar dapat mengubah type NAT menjadi OPEN, adalah dengan membuat pengaturan DMZ server.
DMZ atau DeMilitarized Zone sederhananya adalah fitur yang memungkinkan perangkat dibalik router untuk diakses dari internet.
Jadi, kalau tadi kita sudah tahu kalau port-forwarding hanya akan membuka akses sesuai dengan port yang dibuka dan bisa digunakan terhadap beberapa IP, nah sedangkan DMZ akan membuka seluruh port sebuah IP lokal untuk bisa diakses dari internet dan hanya bisa membuka satu ip local saja (satu perangkat, dalam hal ini Switch).
Perlu diperhatikan juga, karena DMZ ini membuka semua port tanpa terkecuali, oleh karena itu jangan sekali-kali membuat koneksi DMZ host untuk PC/laptop, karena akan sangat rawan diserang intruder/cracker. Untuk Switch, sampai saat ini masih relative aman lah.
Bagaimana pengaturan DMZ server di router? Berikut ini langkah-langkahnya:
        1. Login ke routernya: biasanya menggunakan IP 192.168.1.1 (buka dari browser). Atau kalau tidak tahu IP routernya, cek di pengaturan Network di OS PC/Laptop, biasanya ada keterangan IP router/gateway (untuk TCP/IP)
        2. Pilih menu DMZ host atau DMZ server seperti di gambar ini (biasanya di dalam menu Application):

          DMZ Host
        3. Nyalakan Nitendo Switch, masuk ke Pengaturan>Internet, cek Mac Address Switch kamu, seperti pada gambar di bawah ini:
          Cek mac address di Nintendo Switch

          Mengapa menggunakan Mac Address? karena Mac Address ini sifatnya permanen, berbeda dengan IP (apalagi cuma punya IP dinamis) yang berubah-ubah setiap ganti koneksi/restart koneksi. Jadi, tidak perlu setting ulang IP di DMZ Host, karena yang dikenali Mac Address-nya si Switch.

        4. Input MAC Address dari Switch ke DMZ Host dengan cara memberi tanda centang “Enable Mac Mapping” dan mengisi alamat Mac Address Switch tersebut, setelah itu submit.
        5. Jika sudah selesai langkah-langkah di atas, lakukan restart router dan koneksi ulang Switch kamu ke internet rumahmu melalui router tersebut. Semestinya sih dari B bisa naik ke A.

Updated, Port Forwarding:

Bagaimana pengaturan port forwarding di Nintendo Switch?

Berdasarkan informasi yang beredar di forum reddit dan nintendo, port yang harus dibuka untuk koneksi ke server Nintendo adalah dari port 45000 sampai dengan port 65535, dan protocol UDP.
Bagaimana caranya?
  1. Login ke routernya: biasanya menggunakan IP 192.168.1.1 (buka dari browser). Atau kalau tidak tahu IP routernya, cek di pengaturan Network di OS PC/Laptop, biasanya ada keterangan IP router/gateway (untuk TCP/IP)
  2. Masuk ke Menu Application>Port Forwarding seperti pada gambar berikut:

    Menu Port-forwarding
    Menu Port-forwarding
  3.  Centang tombol enable, beri nama, misal “Switch”, Protocol UDP, WAN host IP address start dan end biarkan kosong, kemudian pilih WAN Connection “pppoe_1”, WAN start port, input angka “45000”, dan WAN end port, input angka “65535” (berlaku juga untuk LAN Host port start dan end), kemudian centang “Enable MAC Mapping”, dan masukkan Mac Address Switch (*untuk cara mengetahui mac address switch, cek tulisan di atas ya, dibahas di pengaturan DMZ, atau search aja di tulisan ini dengan mengetik “mac address”). Jika sudah, pastikan yang diinput benar, seperti pada gambar berikut:
    Pengaturan port-forwarding Switch
  4. Tekan tombol “Add”, selesai, selanjutnya restart router dan coba koneksi ulang dari Switch ke Router.
Sekianlah tulisan singkat, semoga bermanfaat.
Referensi :

Meninggalkan zona nyaman haruskah “resign” dari kantor?

Seseorang teman bilang: “yah, masa’ lo balik ke zona nyaman di kantor sebelumnya hanya krn lokasinya jauh?”
tak balas: “yg pgn balik ke zona nyaman siapa? itu pertimbangan jauh ya krn faktor kesehatan dan tingkat stress kalo macet. Tempat kerja baru, jauh sekali..trs saya minta balik ke kantor sebelumnya bukan berarti itu zona nyaman”

Meninggalkan lokasi kerja sebelumnya tidak sama dengan meninggalkan zona nyaman.
Zona nyaman jangan diartikan sempit sebatas tempat kerja.
Zona nyaman itu adalah tempat di mana seseorang merasa aman dan nyaman dan gak mau lagi mencoba hal baru, ragu mencoba sesuatu yang baru dan ragu buat belajar hal baru. Jadi zona seperti itu ya ditinggalkan, bukan kantornya yang ditinggalkan

Contohnya…misal orang tersebut posisi programmer, terus upgrade skill berbeda dengan “push” dan memotivasi diri sendiri untuk belajar sesuatu yang baru. Bisa juga dengan terjun langsung ke tantangannya. Misal: programmer kantoran, kerjaannya gitu2 aja, malah lbh banyak santai youtube-an di kantor, main game, terjun ke dunia proyek (bisa sambilan, bisa ngisi waktu pas liburan atau pas malam hari), walaupun dia belum punya pengalaman, dengan dia berani..dia sdh meninggalkan zona nyaman. Toh, dengan begitu dirinya tertantang buat belajar menghadapi klien, belajar berkomunikasi dengan orang yang berbeda, belajar mencari solusi dari permasalahan yang dihadapi klien dan bagaimana menyampaikannya dengan baik agar solusi tsb dapat diterima oleh orang lain, dan belajar pemrograman baru, teknologi baru, dll. Tanpa meninggalkan kantornya, dia sdh meninggalkan zona nyaman. Itu hanya sebagian contoh loh. Masih banyak contoh lain.

Contoh lainnya, misal dari programmer, tapi pengen naik tingkat ke level yang lebih tinggi, yaitu posisi analyst atau mungkin lebih tinggi lagi, posisi project manager. Jadi sembari dia kerja di kantor sebagai programmer, dia proactive, moving forward memperhatikan bagaimana analyst dan PM bekerja, dia gak malu bertanya, berdiskusi, ngajak makan bareng analyst atau PMnya, buat sekedar mendapatkan ilmunya dan menjalin komunikasi yang baik. Dia akhirnya punya inisatif tinggi di grup dan di kantor, tidak hanya menunggu bola, tapi juga menjemput bola sambil menyampaikan apa strateginya. Ini juga termasuk meninggalkan zona nyaman. 🙂 


Balik ke masalah lokasi, tempat lokasi itu jadi faktor penunjang performa kerja. Kalau tempat jauh, capek atau tua di jalan, performa menurun, boro-boro meninggalkan zona nyaman, buat dapet kenyamanan di kantor aja akan jadi sulit, lah sdh stress di jalan, kerja tentu jadi gak maksimal. Makanya tiap mulai kontrak kerja itu sebisa mungkin pro-active, nego, nanya, dan berdiskusi dengan baik agar ada jalan keluar dan solusi bersama, toh sama-sama butuh kan.


“Tapi kok kamu malah minta balik ke kantor lama sih, wid?” | “eittss, jangan salah..itulah strategi tarik ulur dalam negosiasi.. dengan klien-klienku juga tak pake cara serupa hehe..toh yang penting tiada yang dirugikan, dan kita tidak merugikan orang lain” (terinspirasi ibu-ibu yang nego harga di pasar..wkwkwk)

HTML5 atau Native?

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

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

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

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

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