Software Development

Software Development

Membantu dalam pembuatan Software Custom sesuai kebutuhan perusahaan anda

Network Infrastruktur

Network Infrastruktur

Membantu dalam membangun, memelihara dan mengimplementasikan network

IT Consulting

IT Consulting

Menyusun kerangka acuan bagi pengembangan TI secara sistematis & berkesinambungan.

Software House di Indonesia

Mungkin saya bukan yang pertama membahas tentang software house karena ini merupakan tugas mata kuliah, jadi pasti banyak orang yang menulis tentang software house juga.

Software house dapat diartikan sebagai sebuah perusahaan yang menghasilkan produk dalam bentuk software. Contoh software house besar yang kita kenal seperti Microsoft, Apple Inc, Oracle Corporation, dll.

Sebuah software house biasanya terdiri dari beberapa tim, diantaranya:

    * bisnis analis : bertugas untuk menganalisa apa yang dibutuhkan pasar
    * programmer : untuk membuat program/software
    * tester : untuk mengetes apakah software sudah berjalan sesuai yang diinginkan

Untuk yang ingin membuka sebuah software house, ini ada life cycle dalam sebuah software house:

1. Cari kabar dimana ada yang perlu aplikasi
2. Kalau ada, janjian untuk mendengarkan requirement
3. Menunjukkan bahwa anda bisa mengerjakan aplikasi sesuai requirement. Caranya :
- paling gampang tunjukkan portofolio aplikasi yang pernah dibikin
- Paling efektif tunjukkan produk yang sesuai dengan requirement(ini agak sedikit mustahil)
- Presentasikan kembali requirement dalam bahasa yang sedikit lebih teknis
- Presentasikan SDLC dan proses pengembangan aplikasi di perusahaan anda. Gimana requirement gathering, prototyping, demo sampai ke user acceptance test (UAT). Trus garansi, change request management.
4. Biasanya point 2 dan 3 bisa dalam satu sesi meeting, tapi lebih sering sesi 3 dilaksanakan beberapa hari setelah sesi 2
5. Setelah point 3 disetujui biasanya sih ada proses nego harga dan termin pembayaran. Usahakan di termin pembayaran ada DP dan ada step2 pembayaran yang berdurasi pendek, misalnya setiap satu modul selesai dibayar sekian persenya.
6. kalau deal baru mulai developmet.
7. Requirement gathering dengan mewawancara client dan user yang akan menggunakan aplikasinya. Kemudian minta segala macem form, data, dokumen yang di print beserta semua dokumen bisnis.
8. Mulai develop
9. Demo setiap modul, jangan sampai demo di akhir saja untuk semua modul, kalau ada perubahan bisa berdarah2. Release often release fast.
10. Sign off modul yang udah disetujui, minta dibayar
11. Implementasi, biasanya ada proses migrasi data dari sistem lama atau dari excell kalau masih manual.
12. Bug fix dan maintenance
13. closing
14. makan2

Kemudian pembagian kerjanya:
1. Tukang nanyain user apa yang mau dibikin->bisnis analis
2. Tukang coding level jago, supaya bikinnya gak sembarangan->programmer expert
3. Tukang coding level pemula, supaya ada yang disuruh2 bagian coding yang boring seperti validasi, geser2 tombol, pasang icon, dsb -> programmer pemula
4. Tukang ngetes ->tester
5. Tukang ngurusin hal2 lain supaya tukang no. 1 sampe 4 bisa kerja dengan nyaman Misalnya: reimburse taksi, janjian meeting sama client, laporan progress ke client dan ke bos, cari pengganti kalo ada yang sakit/resign/cuti/dipecat, mengucapkan, “You’re fired” kalo ada yang gak bener
6. Tukang tagih invoice kalau sudah tiba masanya

cara untuk menentukan project estimation:

1. Cara kasar : tentukan deadline berdasarkan kebutuhan bisnis, misalnya: PT A akan memulai usahanya pada juli bulan ini, maka aplikasi harus selesau bulan juni. Pokoknya aplikasi harus selesai,
2. Cara Marketing : Ikut tender, terus dengarkan tim lain presentasi, hitung waktu penyelesaianya kirakira 40% lebih cepat dibanding pesaing. Kalau pesaing bilang 5 bulan, ya kita bilang 3 bulan ).
3. Cara logis : Tentukan kapan deadlinenya, kemudian tentukan feature apa yang diperlukan agar aplikasi Accounting bisa berjalan. Kemudian bentuk tim, training tim, setup teknologinya. Lalu bersama-sama dengan tim estimasi setiap feature berapa lama bisa dikerjakan. Kalau timnya berisi programmer berpengalaman dan pernah terlibat project development aplikasi serupa, peluang estimasi akurat bisa cukup tinggi, kalau semuanya belum pernah membuat aplikasi tersebut ya coba tanya sama yang pernah bikin

Estimasi pada intinya dibagi menjadi beberapa tahap :
1. Estimasi dulu seberapa besar aplikasi yang akan dibuat. Ada beberapa satuan yang umum digunakan untuk mengukur besarnya aplikasi, diantaranya Function Point dan Line of Code (LOC) LOC lebih akurat, tapi sulit diestimasi di awal project. FP lebih mudah, karena berkaitan langsung dengan requirement.

2. Setelah didapat besarnya aplikasi, estimasi effortnya. Berapa manday yang dibutuhkan untuk menyelesaikan. Perusahaan berpengalaman dan rajin ngumpulin data seperti Balicamp biasanya sudah punya data historis tentang kemampuan pasukannya. Satu FP bisa diselesaikan berapa manday. Nah dengan data ini, tinggal dibagi aja, berapa FP jadinya berapa manday.

3. Setelah manday didapat, estimasi durasi. Durasi adalah jumlah hari kalender untuk membuat aplikasi, satuannya hari kerja. Apa bedanya effort dan durasi? Misalnya satu fitur effortnya 8 manday. Ini belum tentu selesai dalam 1 hari. Mungkin saja durasinya bisa 4 hari, sbb :
2 jam meeting dengan client 2 jam coding.
2 hari clientnya lagi sibuk, sehingga gak bisa ngetes
2 jam UAT, dapat 10 bug
1 hari programmer mules-mules, gak bisa coding.
2 jam fixing
Total effort 8 jam, tapi durasi jadi 5 hari karena ada 2 hari nungguin user dan 1 hari programmer murus.

saran untuk yang ingin membuat software house:

Jadi, apa rekomendasi saya? Kerja dulu di software house yang sudah mapan dengan tujuan sbb :
- belajar siklus mulai dari sales sampe project closing
- memperluas wawasan business process, misalnya akunting, procurement, dsb
- memperdalam kebijaksanaan dalam mendesain software
- menabung uang untuk modal bikin perusahaan
- menabung relasi untuk modal bikin perusahaan
- menabung reputasi biar gampang dapet orderan

Nanti setelah 2 – 3 tahun kerja, udah tau project dari kepala sampe buntut, baru deh bikin sendiri.

Setelah diulas sedikit tentang membuat software house,sekarang kita bahas hal yg membuat software house hancur/bangkrut:

Penyebab bangkrutnya software house

   1. Terlalu mengandalkan lelang dari Aplikasi di Lembaga Pemerintahan
      Tak dipungkiri memang Nilai lelang yang diadakan oleh lebaga pemerintahan
      nilai pagunya ratusan juta sampai miliaran rupiah untuk sebuah aplikasi yang hanya dikerjakan beberapa bulan saja. Lelang aplikasi biasanya muncul ketika menjelang akhir tahun istilahnya sich untuk menghabiskan anggaran tahun tersebut. Ketika musim lelang sudah selesai maka pekerjaan pun nyaris selesai dan pemasukkan yang mempunyai nilai yang tinggi hanya dari sektor ini. Jadi bisa disimpulkan perusahaan tidak mempunyai produk yang bisa dijual tanpa harus banyak penyesuaian.
      Tak jarang software hasil lelang dipakai hanya pada saat serah terima saja setelah itu dibiarkan tanpa dipakai dan dirawat, padahal untuk membuat aplikasi tersebut Programmer dan Analis, rela untuk tidak tidur hanya untuk mengejar agar aplikasi bisa launcing tepat pada waktunya
   2. Konflik pemilik saham
      Untuk hal ini biasanya awal hari runtuhnya perusahaan, untuk point 1 dan 2 kemungkinan bisa diperbaiki. Namun klo berbicara ego pemilik saham maka karyawanlah yang menjadi korban. Mereka bisa menutup perusahaan kapan saja mereka mau meskipun banyak project yang sedang ditanggani.
   3. Manajemen Project yang buruk
      Saya pernah mengalami kondisi saat perusahaan mampu membayar upeti yang nilainya mencapai puluhan juta rupiah untuk mengoalkan sebuah lelang agar bisa didapat, namun ketika jatuh tanggal gajihan karyawan, maka karyawanpun gigit jari karena perusahaan tidak ada kas untuk membayar gaji, alhasil gajian bisa pending untuk periode minggu, bahkan bulan. hal ini karena pihak manajemen lupa skala prioritas.
   4. Manajemen Sumber Daya Manusia yang buruk
      “Tidak bisa memanusiakan manusia”, Bisa dikatakan demikian klo tidak berlebihan. Programmer adalah ujung tombak software house. Namun kesejahteran programmer dan lini karyawan yang lainnya kurang mendapatkan perhatian lebih. Manajemen mengganggap karyawan hanyalah sebuah robot yang bisa di On dan OFF kan sesuai dengan kebutuhan. Masalah kontrak kerja karyawan merupakan hal yang luput dari perhatian manajemen, ditambah lagi pemenuhan kebutuhab hidup standar yang kadang belum terpenuhi 100 %.

sumber:

http://fauzilhaqqi.net/2010/02/sop-dan-pembagian-kerja-di-software-house/

http://en.wikipedia.org/wiki/Software_house

http://plat-e.blogspot.com/2009/09/runtuhnya-sofware-house-di-indonesia.html