Long Distance Relationcode: LDR ala Programmer

Didik Tri Susanto
Teknomuslim
Published in
4 min readNov 11, 2014

Bismillaahirrohmaanirrohiim

Ketika dulu saya masih aktif di salah satu perusahaan Startup di Jakarta, ada kondisi dimana saya harus LDR atau Long Distance Relationcode (maksa dikit ye :D ) dengan tim saya. Saya dan proyeknya ada di Jakarta sedangkan tim programmer ada di Sidoarjo. Dan saat ada masa tenggang, saya bergabung dalam tim baru untuk menjalankan proyek-proyek yang setiap orang berda di daerah yang berbeda alias LDR.

Dalam dunia software development khususnya web development saya rasa ini adalah hal yang sudah biasa karena development sejatinya bisa dikerjakan di mana saja asal ada koneksi internet. Hanya saja development semacam ini gampang-gampang susah.

Communication

[caption id=”attachment_1801" align=”aligncenter” width=”300"]

communication is important

communication is important. (img source: hongkiat.com)[/caption]

Ya seperti LDR pada umumnya, komunikasi harus dijaga agar tidak terjadi kesalahpahaman. Kita tidak mau terjadi sesuatu seperti ini,

X: “Bro, validasi untuk input form sudah dibuat? Hari ini test sama product owner”

Y: “lho, bukannya yang buat si A?”

X: “Lho, katanya si C itu kerjaanmu?”

Ini pentingnya komunikasi agar masing-masing tau apa yang dikerjakan dan sampai mana kemajuannya. Alat komunikasi bisa macam-macam, mudahnya bisa menggunakan messenger seperti whatsApp, BBM, atau lainnya yang mendukung chat group. Beberapa mungkin bisa menggunakan tools seperti forum, milis, issue tracker, atau manajemen tools.

Software Requirement & Spesification

[caption id=”attachment_1802" align=”aligncenter” width=”300"]

requirements analysis

requirements analysis (img source: softwarepaths.ie)[/caption]

Seringkali yang menghambat development secara LDR adalah kurang matangnya requirement dan spesification software itu sendiri. Ini yang membuat developer jadi tidak PD untuk memulai coding karena kepikiran, “ah nanti kalo fitur ini selesai tapi ternyata tidak dibutuhkan bagaimana?”. Adalah penting untuk mendefinisikan secara jelas di awal pengerjaan apa saja requirement dan spesification khususnya yang bersifat mayor agar developer memiliki gambaran apa yang akan mereka kerjakan. Apalagi kondisi tim tidak ada pada satu tempat yang mungkin terjadi hambatan komunikasi. Solusinya bisa dengan cara membuat backlog, workflow, sampai timeline pengerjaan.

Task Assignment

[caption id=”attachment_705" align=”aligncenter” width=”269"]

task assignment

task assignment[/caption]

Setelah requirement sampai timeline sudah mulai ditetapkan, maka setiap developer harus mengambil tugas mana yang siap dia kerjakan. LDR menuntut developer untuk bisa belajar “self organizing” daripada menunggu ditugaskan untuk suatu tugas. Ini diharapkan tiap developer tahu sejauh mana kemampuannya sehingga dia bisa membuat estimasi waktu yang dibutuhkan untuk pengerjaan suatu tugas sehingga timeline pekerjaan bisa lebih terukur. Kuncinya adalah kerterbukaan, siapa mengerjakan apa dan pelaporan progress development yang dilakukan. Dengan begitu ketika ada salah satu tugas yang belum selesai, tim tahu kepada siapa mereka akan mencari. Bisa membuat daftar task assignment sederhana menggunakan google drive atau Trello.com.

Version Control

[caption id=”attachment_1803" align=”aligncenter” width=”300"]

version con-what? (source: smutch.github.io/)

version con-what? (source: smutch.github.io/)[/caption]

Di era belum memanfaatkan version control seperti git, saya merasakan horornya development jika dilakukan oleh beberapa orang. Fitur dan bug sulit terlacak karena tidak ada kontrol dan siapa yang melakukan perubahan kode. Kehororan itu akan bertambah jika kita LDR dengan programmer lainnya karena problem solving mendadak sulit dilakukan. Saya dan tim menggunakan git untuk berkolaborasi, setiap orang bisa membuat branch dengan bebas di tempatnya sendiri-sendiri dan setelah selesai, melakukan review pada saat pull request / merger ke branch lainnya. Saya menyarankan untuk memakai gitflow yang merujuk pada artikel “A Successful Git branching model”.

Trust Building

[caption id=”attachment_1395" align=”aligncenter” width=”300"]

trust building

trust building[/caption]

Bagi yang LDR pernah mengalami kecemasan jika pasangannya nanti bermain serong di tempatnya sana? Itu adalah salah satu dasar mengapa kepercayaan adalah hal utama pada komitmen LDR. Tim Developer juga seperti itu, harus bisa saling percaya dengan kemampuan dan komitmen developer lainnya. Jika tidak begitu yang terjadi adalah insecure tak berkesudahan yang berpotensi merusak irama kerja tim.

“Gak yakin si A bakal bisa nyelesaikan itu tepat waktu, mending gua kerjain sendiri aja tanpa perlu dia tahu. yang penting target kelar”

Kalau komunikasi sudah rusak seperti di atas, bisa bayangkan nanti konflik yang akan terjadi karena lack of trust. Makanya bikin komitmen pada diri sendiri kalo kita layak dipercaya dengan komunikasi yang baik dan finishing task yang baik juga.

Penutup

Saya adalah orang yang masih hijau dalam dunia software development, dan beberapa penjelasan di atas adalah buah pemikiran dan sedikit pengalaman dalam membangun tim yang sedang LDR. Jika rekan-rekan memiliki pemikiran yang lebih bagus bisa donk sharing di kolom komentar.

Semoga bermanfaat :)

--

--

Didik Tri Susanto
Teknomuslim

Proud to be Moslem | Introvert | Backend Engineer | Laravel Developer