Otodidak, Pilihan atau Keharusan? Minimalizing Knowledge Gap

Di jaman internet saat ini dunia telah menjadi ‘flat’, setiap individu di penjuru dunia kini dapat langsung berkompetisi tanpa halangan ruang dan waktu, yang menjadi penilaian adalah kompetensi. Konsep ‘flat’ inipun membuat individu kini dapat berkompetisi secara langsung dengan tim atau perusahaan sekalipun, walau bukan sebuah pertarungan yang fair jika seorang individu harus melawan sebuah perusahaan.

Ada sebuah anugrah dengan adanya internet, arus aliran informasi dan pengetahuan pada negara-negara maju kini menjadi lebih deras dan dapat diakses di belahan dunia manapun. Hal itu setidaknya dapat mengurangi ‘gap’ knowledge antara negara berkembang dan negara maju. Dimana saya yang fokus di dunia IT sangat-sangat terbantu dengan adanya internet saat ini.

Tetapi setelah menelusuri ‘komunitas maya’ yang mayoritas kontributor2-nya dari negara maju, memberikan sebuah gambaran bahwa knowledge gap itu masih cukup besar. Pada sebuah komunitas ‘application framework’ saya menemukan seorang kontributor yang umurnya masih 20tahunan, yang dapat memberikan sebuah ‘knowledge’ yang cukup mendalam dan orisinal hasil kreatifitasnya. Kemudian dari milis-milis yang saya ikuti, kontributor2 negara maju biasanya sangat mengetahui teknologi yang digunakan sehingga paradigmanya tidak lagi sebagai user tetapi sebagai ‘developer’ memberikan masukan-masukan kepada komunitas untuk perbaikan-perbaikan pada aplikasi(software). Sedangkan saya hanya baru bisa bertanya, bagaimana menjalankan ini dan itu, masih sebagai user.

Pertama saya merasa itu hal yang wajar, karena memang asal muasal teknologi itu dari negara-negara berkembang. Wajar kan toh fasilitas edukasi kita masih kalah dibanding mereka. Tetapi setelah berdiskusi dengan teman yang sedang belajar di sono no, ada aspek pendidikan kita yang tidak efisien, dan membuat pemahaman akan keilmuan kita menjadi ‘setengah-setengah’.  Klo kt temen saya itu disana belajarnya tuh “praxis oriented”, yang dalam bahasa lainnya mungkin bisa disederhanakan dengan “knowing, doing, and being context” (ngutip judul buku). Maksudnya?

CMX v 2.0 – Design Pattern – True AJAX

Sekarang saya sedang coba merencanakan pembuatan produk TA, yaitu membuat modular functional content management system (CMX2) menggunakan teknologi AJAX. Ada beberapa perbaikan-perbaikan yang akan dilakukan terhadap hasil pembuatan CMX sebelumnya, antara lain :

1. Konsep pattern (true framework), sebelumnya walaupun ada module API, tetapi terlihat module terinstalasi belum terintegrasi sepenuhnya dengan sistem yang ada.
2. Konsep UI pattern, sebelumnya membuat/mendefinisikan skin sangatlah sulit, sehingga developer luar akan sangat sulit mengembangkan skin, selain itu pendefinisiannya memberikan batasan dalam membuat skin.
3. Konsep true AJAX, keunggulan AJAX, selain tidak memerlukan refresh page, juga dapat melakukan dua request atau lebih secara bersamaan (terlihat bersamaan). Tetapi pada CMX, objek yang dibentuk hanyalah sebuah, sehingga tidak memungkinkan membuat dua request secara bersamaan.
4. Konsep full Object-Oriented UI, pada CMX kita mendefinisikan XSLT sebagai cara mempresentasikan tampilan
5. Menggunakan ADOdb, agar dalam mengeksekusi user CMX dapat menggunakan beberapa database.

Selain itu pada CMX v 2.0 ini akan dipertahankan beberapa fitur-fitur utamanya, yaitu :

1. Drag’n Drop Object Table, selain itu ditambah efek-efek transisi, untuk Membuat sebuah objek baru, Menghancurkan objek, serta ditambah fungsi minimaze, dan maximize dari sebuah Object
2. WYSWYG Text Editor menggunakan FCKEditor

 

Selain itu paradigma pengembangan yang akan dilakukan lebih bersifat user oriented, artinya tidak lagi kepada teknologi, karena batasan teknologi telah ditetapkan. Oleh karenanya produk akhir nanti yang akan dihasilkan harus bisa digunakan oleh end-user.

 

Jikalau melihat postnuke atau CMS-CMS lainnya maka terlihat sekali kekompleksan dari CMS tersebut, oleh karenanya sebaiknya ketika mengembangkan CMX, lebih terfokus pada paradigma kita sendiri, sehingga pemikiran kompleks tidak mengganggu (tidak lagi terfokus pada CMS lainnya), bisa jadi CMX itu simple karena menggunakan suatu pattern tertentu seperti MVC.

Project Manager is Not About Sign a Contract

Sebelumnya ketika menangani sebuah proyek, arti dari seorang PM (Project Manager) biasanya tidak dianggap penting bahkan dianggap sesuatu keberadaannya dapat dihilangkan karena secara teknis tidak mengerjakan sesuatu. Project Manager dianggap sebagai seseorang yang ‘gaji buta’ karena tidak mengerjakan sesuatu.

Tetapi pada bulan ini saya baru menyadari arti pentingnya seorang project manager. dia bukan seseorang yang hanya menyetujui kontrak. seorang PM adalah seseorang yang paling bertanggung jawab terhadap produk yang dihasilkan, keselamatan/kesejahteraan tim proyek, dan juga kepuasan pelanggan.

Hal yang penting yang harus dikuasai oleh seorang PM adalah kemampuan mengestimasikan kapan pekerjaan itu akan selesai, dan juga mendeliverkan requirement yang pasti kepada tim. kesalahan mengestimasikan pekerjaan akan sangat menyulitkan tim, dan kesalahan tersebut harus ditanggung secara kolektif oleh tim….sayangnya yang paling parah mendapatkan efek kesalahan itu adalah programmer…karena programmer mau tidak mau harus mengejar deadline yang kelihatan tidak reliable lagi akibat kesalahan seorang PM mengestimasikan waktu.

Selain itu PM juga bertanggung jawab atas kelayakan nilai proyek sebanding dengan requirement yang diminta oleh client. Dia yang bernegosiasi secara intensif agar tim-nya mendapat imbalan yang seimbang sesuai pekerjaan yang diminta. Dia juga yang harus dapat mengalokasikan resource SDM dengan baik sehingga proyek dapat diselesaikan sesuai dengan yang diharapkan dan juga mengambil inisiatif2 yang diperlukan jika ditengah jalan terjadi sesuatu.

So…PM bukan hanya sebuah hiasan atau hanya formalitas belaka…..

Pattern vs AntiPattern

Karena banyak sekali pengembangan software yang gagal, maka banyak orang berpikir untuk membuat sebuah metode agar bisa membuat pengembangan software berhasil, maka muncullah konsep pattern. Dengan pattern diharapkan software mempunyai fungsionalitas, longevity, reusable yang baik. Tetapi sejalan dengan waktu muncul konsep antipattern, dengan konsep ini orang berpikir bahwa pattern adalah sebuah solusi dan juga masalah (karena menimbulkan efek-efek negatif untuk suatu sisi lain).

Dari permasalahan ini saya teringat perkataan einstein “dibutuhkan tingkat berpikir yang lebih tinggi untuk menyelesaikan masalah yang ditimbulkan oleh sesuatu yang telah kita ciptakan”. Sejauh apapun desain yang kita ciptakan, pada suatu saat perlu perubahan, karena munculnya teknologi-teknologi baru.

Sehingga usaha terbaik adalah mengkrompomikan kebutuhan yang ada saat ini (fokus pada kebutuhan), jangan pada teknologi. Disisi lain kita juga tidak mengabaikan dengan perkembangan teknologi, tapi yang penting adalah konsep mentahnya (yang tidak terpengaruh teknologi). Teknologi adalah bungkusnya sedangkan idenya adalah intinya, bungkus bisa saja terus berubah tapi ide dapat terus berjalan.

Sehingga saya berpendapat, jika kita ingin membuat sebuah software hal yang harus diperhatikan adalah kebutuhan apa yang ingin dipenuhi dengan adanya software tersebut. Lalu jika ingin software kita memiliki keunggulan dibanding software-software yang lainnya adalah konsep dibelakang terciptanya software tersebut (bukan syntax yang mengimplementasikan software tersebut).