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.

Masalah source code, pantaskah diberikan ke klien?

Hari ini saya membaca artikel sangat bagus, mengingatkan kembali sedikit masalah yang pernah saya alami dulu di waktu menjalankan proyek TI dan pertanyaan seorang mahasiswa S1 yang sedang belajar “bermain” proyek TI.

Pertanyaan seorang mahasiswa tersebut kira-kira begini :

kalo misalnya klien ingin mengembangkan softwarenya lg, dia harus menghubungi saya dan membantu dia? Atau saya memperbolehkan klien untuk mengubah source codenya dengan izin dari saya?

Dari beberapa case proyek TI, source code tidak ada apa-apanya, jika dijual kembalipun, istilahnya cost depreciation (penyusutan harga). Yang mampu membuatnya “valuable” tentu proses bisnisnya dan layanan yang ditawarkan bagaimana mampu menyelesaikan masalah si client. Faktor supply and demand juga jadi salah satu faktor utama tingginya harga software

Ada beberapa vendor yang memang tidak memberikan source-code-nya, ada juga yang sistem sewa, dan ada juga yang dalam bentuk paket layanan software (include source-code)
Memberikan source-code tentu menguntungkan client dari segi pendapatan untuk masa depan.
Bisa jadi source-code tersebut di-“re-engineering“/re-use untuk dikembangkan lebih lanjut ke depannya, dan bisa jadi pengembangnya bukan pihak kita lagi (bisa SDM internal perusahaan, ataupun kita jual putus, dilanjut vendor software lain)
Di sini tentu ada nilai “investasi“, nah nilai ini yang bisa dihargai mahal

Kemudian ada pertanyaan lagi yang menghampiri….

kalau client nya bisa added value di code2 kita trus dijual lagi gimana, om ?  Kira-kira apa motivasi atau latar belakang penjual ikut menyertakan source-code software? begitu pula latar belakang pembeli.

Sudah tentu kita (sbg. vendor) merasa dirugikan jika memberikan source code, apalagi kalau client-nya bisa added value di source-code yang kita berikan, dan kemudian dijual kembali dengan harga tinggi (case nyatanya ada  )

Ntah klien ataupun vendor TI tentu punya motivasi.
Sebelumnya kita mesti pahami source-code bukan segalanya bagi client.

Apa motivasi client kita menggunakan jasa vendor untuk membuat software yang mereka butuhkan? tentunya ada alasan “meningkatkan kinerja perusahaan”, jika tidak, tentu mereka re-engineering source-code atau nambahin fitur2 dari software yang ada. Dan dari situ ada faktor lain juga, seperti ini kebutuhan urgent apa tidak, sistemik atau tidak, urusan maintenancenya, dan tentunya inginkan software yang berumur panjang.

Nah, dari sini keliatan kalau software tersebut ada umurnya (termasuk source-code-nya). Kita tentu sudah memperkirakan purna jual software-nya, sampai dengan post-development dan close-project.

Kebanyakan vendor-vendor TI perbankan, menerapkan sistem “pulsa”, “ok, saya berikan source-code ini kepada anda, tapi anda mesti menggunakan layanan kami sampai maintenance (termasuk update minor, re-design, dan bahkan upgrading)

Mereka tawarkan pulsa 100.000 man-days misalnya dari masa maintenance, kemudian ketika ada perubahan yang diinginkan client, itu kena “charge“, misal re-design homepage dihargai 8000/man-days, tentu 100.000 itu berkurang jadi 92.000 man-days, dan sistem pulsa itu ada masa tenggang sampai 1 tahun, di akhir tahun, vendor menawarkan lagi, mau diteruskan lagi (maka harus mengisi pulsa lagi), atau diputus (project termination)

Kebanyakan klien besar tidak mau repot (secara psikologi), dia akan terus menggunakan sampai jangka waktu lama atau sampai software itu tidak menghasilkan solusi lagi. Apalagi sudah ada “ikatan” yang kuat antara si pihak SDM vendor dengan client (misal karyawan TI internal bank sudah akrab dan mampu berkolaborasi dengan SDM vendor), tentu kerjasamanya bisa sangat panjang dan jasa si vendor akan terus dipakai (karena sudah ada nilai kepercayaan yang tinggi). Dan itu outsourcing, ada yang full-outsource ke vendor, ada yang selective outsource, dan ada yang in-source. (perbankan kebanyakan pakai yg selective, jadi yg internal perusahaan tetap dirahasiakan dari pihak vendor TI)

Nah, kembali ke masalah source-code, bagaimana jika source-code tersebut dijual lagi oleh client, apalagi sampe ditambahin macem-macem dan dihargai lebih tinggi lagi?
ya itu tadi, nilai investasinya (invest order) yang kita tawarkan ke client mesti ditinggikan lagi (tapi lihat juga daya beli client), maka dari itu ada proses negosiasi (ini penting sekali).

Seperti halnya di artikel tersebut, jika kita mampu membuat software tersebut kemudian dipake client untuk ditingkatkan kemampuannya kemudian dijual lagi…ya kita selaku vendor mesti lebih kreatif lagi.

Jika tidak rela, silahkan pasang lisensi di software tersebut.

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 🙂

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 🙂

Custom Kernel Android?

Kemarin malam saya mencoba iseng menggunakan custom Kernel Android 2.1.

Bersumber dari blog ini.

Dan juga tutorialnya di sini.
Dan diperolehlah hasilnya seperti ini :

Apa aja kelebihannya? 😀

Ini dia….

Features:
– latest SE sources (2.1.A.0.492)
– FPS cap removed
– overclocked to 1.13GHz
– in-call volume increased
– full netfilter support (droid wall, wifi tether)
– drivemapper support (2.2+ native app2sd)
– working with basebands 54+ (67 recommended)
– no battery drain / sleep issues observed – 100% stock behaviour

 

[Tips for Android Developer] Using Android Emulator or Android Virtual Device

If you don’t have a android phone, don’t worry..you can still develop apps android and try it through Android Emulator (Android Virtual Device – AVD)

you can use the command via command prompt (don’t forget to set adb tools on system variable path on your PC) :

emulator -avd emulator-name

to start the emulator. If you want to customize the emulator appearance, you can use the command:

emulator -avd emulator-name -skin 480×320

where the Andori emulator appearance standard is:

480×320, landscape: emulator -skin HVGA-L
320×480, portrait : emulator -skin HVGA-P (default)
320×240, landscape: emulator -skin QVGA-L
240×320, portrait : emulator -skin QVGA-P