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.

Harga pengembangan aplikasi mobile yang dipasang, kemahalan atau kemurahan kah?

Mari kita berhitung harga aplikasi mobile. 🙂 Bila ada yg beranggapan harga 4-7jt itu kemahalan untuk membuat aplikasi bisnis berbasis mobile (android, iOS, BB) artinya temen-temen perlu membaca ini.

Ini dikerjakan secara profesional, bukan dikerjakan oleh mahasiswa tingkat akhir yang dipekerjakan (sadis, gan!) :p

Dan jangan dianggap, karena aplikasi yang dikembangkan itu cuma seukuran layar HP dan lebih kecil “keliatannya” tampilan daripada di website, bukan berarti harganya pasti lebih murah daripada mengembangkan versi web. Itu salah kaprah. Karena, bisa jadi kerumitannya lebih rumit daripada pengembangan website. Dan bisa jadi lebih mahal daripada pengembangan versi websitenya. Walau tampilannya keliatan kecil, tetapi di situ ada banyak kerumitan dalam hal UI, fungsionalitas, pemodelan, user-behavior aspect/user experience design, resources, dll. Hampir mirip saat mengembangkan website.

Dari hasil diskusi saya dengan beberapa teman project TI yang sudah 2 tahun mendalami pengembangan aplikasi mobile dan project TI di bidang mobile apps. Dan pengalaman pribadi yang mendalami project programming Android di beberapa tempat sejak memiliki HP Android di juni 2010.

Dan ini berlaku hampir di semua client dan client/perusahaan pun rata-rata mematok harga segitu.

Ok, kebanyakan aplikasi mobile itu faktanya, dikembangkan dalam jangka waktu paling tidak 6 bulan, dengan jam kerja full-time (mengikuti jam kerja) dan berkisar di harga 10 sampai 50 juta.

Eits, tetapi tidak serta merta semua begitu, mari kita buat lebih spesifik. Pertama, perlu kita perhatikan adalah tipe aplikasi yang akan dikembangkan. Kita berhadapan dengan klien, ngobrol panjang lebar dengan orangnya apa yang ia inginkan (user stories) dan mencatatnya untuk dianalisa setiap kebutuhan supaya menjadi milestone pekerjaan (per task, per man-days, per man-power, per period) dalam jangka waktu (timeline) yang sudah disepakati.

Kita bagi dalam dahulu menjadi 2 kategori :

A. Untuk digunakan konsumen (umum)

  1. Aplikasi dasar, yang memiliki fungsi-fungsi dasar android. Sekedar menampilkan teks, diinputkan, diproses ditampilkan secara sederhana. Seperti : aplikasi maps sederhana yang menampilkan petunjuk jalan lokasi penjualan produk, aplikasi alarm, jam, dsb..yang tidak menampilkan fitur-fitur selain itu.
  2. Aplikasi Native, yang menyediakan berbagai tipe konten (gambar, tulisan, suara, dll), dengan logika matematika yang kompleks dan arsitektur software yang terdiri dari beberapa level. Dan biasanya menggunakan framework tertentu atau library tertentu, dan database tertentu (mysql, sqlite, sql server, dsb)
  3. Games, dari berbagai info saja, aplikasi games Angry Birds seharga $125k-180k hanya untuk biaya coding saja. Dan games sama saja mencakup beberapa hal, seperti : rendering 2d/3d graphics, logika ilmu matematika, ilmu fisika, dll. Belum lagi nanti ada sound artist, artwork design, dll. Makin mahal.

B. Untuk digunakan perusahaan (bisnis/internal)

  1. Aplikasi enterprise kecil
  2. Aplikasi enterprise sedang
  3. Aplikasi enterpise besar

Mengenai kecil, sedang, dan besarnya ditentukan dari banyaknya scope-pekerjaan, timeline yang diberikan, dan kompleksitas masalah (apakah nanti cross-platform kah? artinya perlu menyediakan web-services, database-support library, Share Capabilities  dengan apps lain, dsb)

Ok, soal harga, berapa?

Menentukan harga itu harus ditambahkan juga dengan biaya penyediaan resources (tools/software/IDE) dan biaya produksi (publishing) jika memang semua diusahakan oleh pihak pengembang.

Begini, ketika kita akan mengembangkan apps. games dengan menggunakan Game Maker Studio seharga $299 dolar, artinya itu masuk hitungan nilai investasi kita, kecuali sudah disediakan oleh pihak client, kalau tidak? masa’ kita yang membeli sendiri? Kalau sudah punyapun, harus dihitung lagi. Karena secara profesional, semuanya disediakan oleh client, kecuali ada hitam di atas putih yang menyatakan kita ikhlas menyediakannya [yaoming.jpg] 🙂

Jika menggunakan tools yang gratisan ya jangan hehe..

Begitu juga biaya publishing ke PlayStore ataupun AppsStore, itu ya biaya pendaftaran akun untuk publishing-nya ya dihitung juga.

Dan untuk masalah harga yang berlaku, bisa dicek di sini :

  1. Aplikasi dasar seperti pada poin A.1 di atas : berkisar 2-5jt (di luar sana berkisar $1,000)
  2. Aplikasi native, seperti pada poin A.2 di atas : berkisar 6-50jt (di luar sana berkisar $8,000-$50,000)
  3. Aplikasi games, seperti pada poin A.3 di atas : berkisar 8-150jt (di luar sana berkisar $10,000-$250,000)
  1. Enterprise kecil, seperti pada poin B.1 di atas : berkisar 20jt (sekedar ekstrak data dari database, kemudian ditampilkan)
  2. Enterprise sedang, seperti pada poin B.2 di atas : berkisar 20-50jt (sudah mencakup masalah seperti : client-server apps, cache data, penggunaan library native, hardware support)
  3. Enterprise besar, seperti pada poin B.3 di atas : berkisar 80-300jt (full-scale enterprise, office automation, enterprise financial monitoring, mobile apps. banking, dsb)

Apalagi akan ada continuing cost setelah masa development, guarantee, maintenance, dll.

Harap diperhatikan juga, besar kecilnya harga yang ditawarkan itu bisa bergeser karena dipengaruhi banyak faktor. Ketersediaan SDM, Ide, Waktu, Budget, Fungsionalitas, Layout Design, dan negosiasi.  🙂

Apakah harga segitu wajar?

Jelas wajar, dilihat dari lifecycle development-nya, benefit dari pemanfaatan aplikasi mobile kepada user (yang jelas lebih mudah dipakai di manapun, kapanpun, tanpa perlu membawa laptop), promosi (iklan) produk dan monitoring (untuk keperluan survey statistik penggunaan) juga dapat dimanfaatkan dengan mudah melalui apps yang dikembangkan dan di-publish, demi memperhatikan konsumen dan mencari aspek penting buat menentukan kebijakan perusahaan. Dengan rata-rata per sekali publish, dalam seminggu bisa sampai 100-500 yang downloads, tentunya akan meningkatkan keuntungan bagi pihak client. Apalagi trend sekarang ini adalah mobile apps.

NB : tulisan ini mix teori (minim) dan hasil praktek, bukan money-oriented tanpa dasar, tetapi supaya kita juga paham memasang harga pengembangan aplikasi biar tidak dirugikan. :p Newbie belajar nulis.

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 🙂