Software Engineering #Chapter 22 : Project Management – Risk Management

risk_management-removebg-preview

 

Hallo teman-teman Akhdani, aku mau sedikit sharing nih dari buku yang udah aku baca

Apa itu Project Management?
Project Management adalah metode penyelesaian proyek dengan melakukan proses initiating, planning, executing, control and monitoring, hingga closing untuk mencapai output/tujuan yang sudah ditentukan.

Dalam pengelolaan proyek dapat mengikuti panduan dari PMBOK Guide 4th Edition yang salah satu isinya ada Risk Management.

Apa itu Risk Management?

Risk Management adalah salah satu pekerjaan terpenting seorang Project Manager yang memikirkan kemungkinan terjadinya risiko dan konsekuensinya terhadap proyek. Risk Management dapat mengantisipasi risiko yang mungkin mempengaruhi jadwal proyek atau kualitas software yang sedang dikembangkan, kemudian mengambil tindakan untuk menghindari risiko tersebut.

Beberapa tahapan yang dapat dilakukan:

screenshot-2023-10-30-105801

  1. Risk Identification
    Pada tahapan ini tim berkumpul untuk bertukar pikiran mengenai kemungkinan risiko yang terjadi sehingga project manager dapat mengidentifikasi risiko berdasarkan pengalaman pada proyek sebelumnya.
    Sebagai titik awal untuk identifikasi risiko, ada 6 (enam) jenis risiko yang dapat dimasukkan dalam daftar risiko:
    a. Estimation
    b. Organizational
    c. People
    d. Requirements
    e. Technology
    f. Tools
  2. Risk Analysis
    Pada tahapan ini project manager harus mempertimbangkan setiap risiko yang teridentifikasi dan mengambil tindakan penilaian tentang kemungkinan dan keseriusan risiko tersebut. Project manager tidak mungkin membuat penilaian numerik yang tepat mengenai probabilitas dan keseriusan setiap risiko, sehingga dapat dilakukan penilaian dengan cara berikut ini:
    a. Kemungkinan risiko dapat dinilai sebagai tidak signifikan (rendah, sedang, tinggi, atau sangat tinggi).
    b. Dampak risiko dapat dinilai sebagai bencana besar (mengancam kelangsungan hidup proyek), serius (akan menyebabkan penundaan besar), dapat ditoleransi (keterlambatan akan terjadi kontingensi yang diperbolehkan), atau tidak signifikan.
  3. Risk Planning
    Pada tahapan ini project manager mengembangkan strategi untuk mengelola risiko-risiko utama yang mengancam proyek. Untuk setiap risiko, project manager harus memikirkan tindakan yang memungkinkan dalam meminimalisir gangguan terhadap proyek jika masalah yang diidentifikasi dalam risiko tersebut terjadi.
  4. Risk Monitoring
    Pada tahapan ini project manager harus memantau risiko secara teratur di semua tahapan proyek, mempertimbangkan dan mendiskusikan setiap risiko utama secara terpisah, memutuskan apakah risiko tersebut lebih besar atau lebih kecil kemungkinannya untuk timbul dan apakah konsekuensi risiko telah berubah.

Sehingga dapat disimpulkan untuk pengajuan proposal manajemen proyek bagian Risk Management tertulis seperti berikut ini: 

421315

Mengenal Business Intelligence

Cover BI

Halo Sobat Akhdani! Di era teknologi saat ini, para pelaku usaha mulai menggunakan Businesss Intelligence sebagai tools untuk memonitoring performa bisnisnya. Secara umum, Businesss Intelligence dapat membantu mengumpulkan informasi dari berbagai sumber, yang kemudian disimpan, diolah dan diproses menjadi data visual. Untuk mengenal lebih dalam apa itu BI dan bagaimana cara kerjanya, mari simak artikel berikut ini!

Apa itu Business Intelligence?

Business Intelligence merupakan bentuk pengolahan data menggunakan model matematis dan analitis yang kemudian akan menghasilkan informasi untuk memudahkan perusahaan dalam pengambilan keputusan pada proses bisnis yang dijalankan.

Dalam artian lain, BI dapat membantu perusahaan melihat secara rinci dan real-time kondisi bisnis yang sedang berjalan saat ini, apakah sedang mengalami penurunan, peningkatan, atau bahkan stagnan. BI juga dapat membantu menyajikan informasi secara lebih ringkas, sehingga perusahaan dapat mengambil langkah lebih cepat dan tepat untuk perencanaan bisnis kedepannya.

BI

Komponen Business Intelligence

Business Intelligence terdiri atas beberapa komponen pembentuk, antara lain:

  • OLAP (On-line Analytical Processing)

OLAP melakukan query data dari berbagai sumber untuk menghasilkan berbagai sudut pandang. Dengan kata lain, BI menggunakan OLAP untuk menggabungkan dan mengelompokkan data ke dalam beberapa kategori untuk memberikan informasi yang lebih ringkas dalam bentuk pelaporan, analisis, pemodelan, dan perencanaan. Beberapa operasi OLAP yang digunakan adalah roll up, drill down, slice and dice, dan pivot.

  • Analisis lanjutan

BI menerapkan teknik machine learning, otomasi proses bisnis, teknik statistik tren, mengenali pola, karakteristik, serta menganalisa anomali dari berbagai sumber data.

  • Manajemen Kinerja Perusahaan

Peran utama BI adalah integrasi dari beberapa data untuk menghasilkan informasi kinerja bisnis. Dalam komponen ini, BI berperan untuk meningkatkan kinerja perusahaan dengan melacak fluktuasi pasar, menganalisis tren jangka pendek dan jangka panjang, serta menciptakan peluang investasi

Cara kerja Business Intelligence

Untuk menghasilkan sebuah data visual berbentuk laporan, BI perlu melewati beberapa proses seperti pengumpulan data, pemrosesan dan penyimpanan data, serta analisis dan penyajian.

konsep BI

Sumber: Pengantar BI dalam Bisnis

  • Pengumpulan data

Pada tahapan ini, BI akan melakukan ekstraksi pada data-data “mentah” yang telah tercatat pada database, seperti data penjualan, laporan laba rugi, penggajian, dan lain-lain sebelum disimpan dan diintegrasikan antar satu dengan yang lain.

  • Penyimpanan pada Data Warehouse

Data mentah yang telah dikumpulkan berikutnya akan disimpan dalam bentuk Data Warehouse untuk dilakukan proses integrasi dari beragam database yang ada.

  • Akses dan Analisis Data

Setelah proses integrasi data, peran BI berikutnya adalah mengakses informasi dari Data Warehouse untuk kemudian dianalisa dan diinterpretasikan dalam bentuk tren, pola, dan menyajikannya dengan bentuk yang lebih ringkas.

  • Pembuatan Laporan

Dari hasil analisa dan interpretasi data tersebut, dilakukan proses pembuatan laporan yang nantinya akan menampilkan data visual beserta informasi pendukung agar pengguna dapat lebih mudah memahami data yang telah diolah.

Aplikasi Business Intelligence

Nah, berikut ini terdapat beberapa rekomendasi aplikasi yang dapat mendukung penerapan Business Intelligence, antara lain:

  1. Microsoft Power BI
  2. Tableau
  3. Oracle BI

 


Referensi:
Business Intelegent (Pengantar Business Intelligence dalam Bisnis)
PT. Sonpedia Publishing Indonesia
Bagian 1 - Pengenalan dan Konsep Dasar Business Intellegence

Meningkatkan User Interface dan User Experience (UI/UX) melalui Pendekatan Berbasis Pengguna

user-1

Pengembangan aplikasi yang sukses tidak hanya bergantung pada teknologi canggih, tetapi juga pada kemampuan untuk memahami, menghormati, dan memenuhi kebutuhan pengguna. Salah satu pendekatan yang fading efektif dalam mencapai tujuan ini adalah Metode User Centered Design( UCD). UCD adalah kerangka kerja yang difokuskan pada pengguna dalam pengembangan tampilan antarmuka aplikasi. Pada kesempatan kali ini ARS Mania akan membahas tentang metode UCD dan mengapa ini sangat penting dalam menciptakan aplikasi yang sukses.

Berdasarkan penelitian yang dilakukan oleh (Kaligis & Fatri, 2020), berikut adalah penjelasan mengenai User Centered Design (UCD).

Apa Itu User Centered Design?

Menurut ISO 9241- 210 yang mengatur tentang Prinsip- prinsip Ergonomi Antarmuka Manusia Sistem Interaktif, metode UCD merupakan pendekatan dalam pengembangan sistem secara interaktif dengan tujuan untuk mengembangkan sistem yang berguna bagi penggunanya. UCD menempatkan pengguna sebagai pusat dari proses desain, dan berfokus pada pemahaman mendalam tentang kebutuhan, dan pengalaman pengguna. Pada metode pengembangan aplikasi, UCD diterapkan pada tahap perencanaan, perancangan, dan pengujian.

Tahapan Metode User Centered Design

the-user-centred-design-process-according-to-iso-9241-21020101. Understand and Specify the Context of Use (Memahami dan Menentukan Konteks Penggunaan)

Pada tahapan ini kita melakukan identifikasi yang berfokus pada kondisi siapa yang akan menggunakan sistem, di mana mereka akan menggunakannya dan apa yang menjadi alasan pengguna menggunakan sistem. Kita mencoba memahami apa yang mereka butuhkan dari sistem tersebut

2. Specify the User Requirements (Menentukan Kebutuhan Pengguna)

Setelah kita tahu siapa pengguna, di mana sistem akan digunakan, dan mengapa pengguna menggunakan sistem, kita menuliskan dengan jelas apa yang pengguna butuhkan dari sistem ini. Kita menentukan apa tugas yang harus mereka lakukan dan apa keinginan mereka.

3. Produce Design Solutions to Meet User Requirements (Menghasilkan Solusi Desain yang Memenuhi Kebutuhan Pengguna)

Dalam tahap ini, kita mulai membuat desain sistem. Desain ini harus mencakup antarmuka yang memudahkan pengguna untuk mengoperasikan sistem dan mencapai tujuan mereka. Pada tahapan ini juga kita berfokus pada untuk meningkatkan user experinece.

4. Evaluate the Design Against Requirements (Evaluasi Desain Berdasarkan Kebutuhan)

Setelah desain dibuat, kita menguji desain ini dengan pengguna. Pengguna mencoba sistem dan memberikan masukan atau feedback. Dari masukan tersebut akan dilakukan perbaikan secara berulang hingga memenuhi ekspektasi pengguna, karena pada metode ini berjalan secara iteratif.

Kesimpulan

Metode User-Centered Design (UCD) adalah pendekatan yang kritis dalam pengembangan aplikasi yang bertujuan untuk meningkatkan pengalaman pengguna. Dengan memahami dan memenuhi kebutuhan pengguna, aplikasi dapat menjadi lebih efisien, efektif, dan memuaskan. UCD membantu mengurangi risiko kesalahan desain dan meningkatkan peluang kesuksesan aplikasi. Oleh karena itu, pengguna seharusnya selalu menjadi fokus utama dalam pengembangan aplikasi yang sukses.

Referensi : 
¹Kaligis, D.L. & Fatri R.R. (2020). Pengembangan Tampilan Antar Muka Aplikasi Survei Berbasis Web Dengan Metode User Centered Design. Jurnal Sistem Informasi, Teknologi Informatika dan Komputer, Vol 10. No 2, Hal 106-114.
²Saputri, I.S.Y. Fadhli, M. & Surya, I. (2017). Penerapan Metode UCD (User Centered Design) pada E-Commerce Putri Intan Shop Berbasis Web. Jurnal Nasional Teknologi dan Sistem Informasi. Vol 03. No 02. 269-278.

Understanding Requirement Engineering

cover-1

Fase Requirement Engineering merupakan proses memahami kebutuhan sistem, baik dari segi bisnis, kebutuhan fungsional, ataupun dari segi interaksi pengguna dengan sistem nantinya.

Tujuan dilakukannya fase Requirement Engineering adalah untuk menyamakan presepsi setiap pemangku kepentingan yang terlibat, agar dapat menghasilkan solusi yang efektif dan efisien.

Fase ini terdiri dari beberapa tahapan:

  1. Identifikasi permasalahan
  2. Analisa kebutuhan pengguna
  3. Klasifikasi kebutuhan pengguna
  4. Pemodelan sistem
  5. Negosiasi dan spesifikasi kebutuhan
  6. Validasi kebutuhan
Identifikasi Permasalahan

Tahapan ini merupakan awal dari proses Requirement Engineering. Identifikasi permasalahan biasanya dilakukan menggunakan teknik kolaborasi meeting yang akan dihadiri oleh pihak user atau pengguna, serta vendor atau tim yang akan melakukan pengembangan sistem. Tahapan ini dapat juga disebut Requirement Gathering.

Tujuan utama dari Requirement Gathering adalah memahami permasalahan yang dihadapi oleh user yang kemudian dilanjutkan dengan penawaran solusi secara garis besar.

Analisa Kebutuhan Pengguna

Tahapan ini merupakan tindak lanjut atas informasi yang telah diperoleh pada tahap sebelumnya. Pemasalahan akan dipetakan menjadi poin-poin kebutuhan yang nantinya akan direalisasikan dalam bentuk fitur-fitur pada sistem yang dikembangkan.

Klasifikasi Kebutuhan Pengguna

Setelah diperoleh daftar kebutuhan pengguna, maka selanjutnya akan dilakukan klasifikasi kebutuhan berdasarkan level kepentingannya, yaitu:

  1. Normal Requirement (Kebutuhan objektif sesuai dengan permintaan user)
  2. Expected Requirement (Kebutuhan dasar sebuah sistem)
  3. Exciting Requirement (Kebutuhan tambahan yang berada di luar ekspektasi user)

Klasifikasi kebutuhan dilakukan untuk memudahkan tim pengembang dalam menentukan prioritas ketika proses pengerjaan nantinya.

Pemodelan Sistem

Tahapan ini bertujuan untuk menggambarkan sistem dalam bentuk dokumen teknis untuk memperjelas elemen apa saja yang dibutuhkan, bagaimana hubungan antar entitas, serta bagaimana behavior atau perilaku sistem atas berbagai kondisi yang diminta oleh setiap aktor.

Pemodelan dapat dilakukan menggunakan Use Case Skenario ataupun Use Case Diagram, UML, Class Diagram, ataupun Prototype sistem.

Negosiasi dan Spesifikasi Kebutuhan

Setelah dilakukan pemodelan, gambaran alur serta fungsional sistem akan semakin jelas. Tahapan berikutnya adalah melakukan diskusi dan negosiasi antara vendor dan user untuk menentukan prioritas pada proses pengembangan, biaya yang dibutuhkan, risiko yang akan ditimbulkan, serta kemungkinan untuk menggabungkan, memodifikasi atau bahkan mengeliminasi kebutuhan-kebutuhan yang telah dituliskan di awal agar mencapai kesepakatan bersama.

Hasil terbaik negosiasi adalah terbentuknya Project Plan dimana pihak user dapat memperoleh sistem yang diinginkan sesuai spesifikasi yang telah diminta, dan pihak vendor dapat bekerja dengan realistis, mendapatkan upah yang sesuai, serta deadline yang wajar.

Validasi Kebutuhan

Setelah proses negosiasi menghasilkan kesepakatan bersama, maka tahapan berikutnya adalah proses validasi dari kedua belah pihak yaitu user dan vendor. Hal ini dilakukan untuk mencegah kesalahan interpretasi, kurangnya informasi, inkonsistensi, serta kemungkinan tidak terpenuhinya kebutuhan yang telah disepakati di awal.

Jika seluruh informasi telah dinyatakan valid, maka dilanjutkan dengan proses pengembangan sistem sesuai dengan kebutuhan yang telah dituliskan dalam dokumen Requirement Engineering.

Dalam beberapa kasus, proses Requirement Engineering dapat berlangsung secara paralel atau beriringan dengan proses pengembangan sistem, tergantung pada kebutuhan setiap projectnya. Semakin banyak pemangku kepentingan yang terlibat, maka akan bertambah pula kebutuhan yang harus diidentifikasi. Maka dibutuhkan kemampuan manajemen informasi dan pendokumentasian yang baik, agar memudahkan pelacakan perubahan sepanjang proses pengembangan.

Beberapa kendala yang memungkinkan terjadi pada proses Requirement Engineering adalah:

  1. User kesulitan dalam mengkomunikasikan kebutuhannya.
  2. Terlalu banyak pemangku kepentingan yang terlibat, sehingga menyulitkan dalam proses pengambilan keputusan.
  3. Ketidaksesuaian antara permintaan, deadline, serta budget yang ditawarkan.

It’s your worst nightmare. A customer walks into your office, sits down, looks you straight in the eye, and says, “I know you think you understand what I said, but what you don’t understand is what I said is not what I meant.” Invariably, this happens late -Ralph Young

Reference: Software Engineering A Practitioner’s Approach / Roger S. Pressman / Seventh Edition

Akhdani Tech Talk 2021 Series #5 – Test Driven Development

Test Driven Development

Oleh: Agus, Dimas, Moris

Apa itu Test Driven Development (TDD)

Praktek koding yang pertama kali dibuat adalah uji tesnya, lalu membuat koding yang bisa membuat test tersebut lolos. Menagapa harus TDD ? TDD baiknya digunakan apabila Anda ingin menjaga base code dalam waktu yang lama.  TDD itu merupakan proses tertutup yang berulang. Hal ini membuat programmer paham dengan apa yang dia buat. Sebagai contoh berikut adalah gambaran dari proses pembuatan TDD tersebut

Mengapa menggunakan TDD?

Karena TDD adalah cara paling sederhana untuk mencapai kode berkualitas baik dan cakupan pengujian yang baik.

Untuk Jawaban lebih panjang, keep scrolling!

Lima langkah dalam flow TDD

  1. Baca, pahami dan proses permintaan fitur atau fix-bug.
  2. Terjemahkan persyaratan dengan menulis tes unit. Jika memiliki pengaturan hot-reload, unit test akan berjalan dan gagal karena belum ada kode yang diimplemen.
  3. Tulis dan implementasikan kode yang memenuhi persyaratan. Jalankan semua tes dan pastikan test berhasil/lulus. Jika ada yang tidak lulus ,silakan ulangi langkah ini.
  4. Bersihkan kode dengan refactoring.
  5. Check dan ulangi hingga test sudah bisa diimpelemtasikan untuk produksi (production).

tdd

tdd-red-green-refactoring-v3

 

 

Terdapat beberapa keuntungan dan kekurangan yang didapatkan jika menggunakan metode TDD. Berikut adalah contohnya :

Keuntungan : 

  1. Bisa memberitahu pada kondisi apa kodingan tersebut bisa berjalan sempurna dan tidak jalan sempurna. Programmer bisa mengetahui jika terjadi kesalahan karena sebelumnya kodingan tersebut berjalan dengan baik.
  2. Membuat waktu yang lebih singkat untuk melakukan refactor kodingan jika diperlukan, karena programmer dapat mengetes dengan mudah.
  3. Membuat programmer lebih percaya diri. karena apabila ada penambahan fitur, dapat dites dengan mudah.

Kekurangan : 

  1. Tidak mudah untuk memulai dengan TDD. Anda harus mengetahui mengetahui banyak praktik dan teknik baru. Contoh: unit testing, dan asertions, dll.
  2. Dibutuhkan lebih banyak waktu diawal saat melakukan pengembangan, karena Programmer harus menguji kode saat membuat kodingan juga.

Secara umum, TDD dapat dibagi menjadi 4 bagian yaitu : 

  1. Unit Testing: Unit test yang paling rendah. Biasanya yang di test hanya 1 method. Hal ini membuat unit testing mudah untuk digunakan.
  2. Integration Testing: Integration testing yang menyentuh beberapa class. Selain berhubungan dengan beberapa class, ada juga yang berhubungan dengan pihak external lainnya, misalnya API lain. 
  3. Functional Testing: Functional testing adalah tipe testing yang dilakukan kepada semua fitur. Testing ini agak memakan banyakan waktu karena fitur yang dites nya lebih banyak dari integration testing.
  4. Acceptance Testing: Acceptance testing merupakan test yang paling atas. Testing ini hanya dianggap sukses apabila customer sudah mengatakan testnya selesai.

Sebagai contoh, disini kita akan membuat 1 bagian TDD yaitu unit testing. Sebagai awalan, framework yang digunakan adalah menggunakan laravel (contoh menggunakan laravel karena saat menginstal laravel sudah sekaligus otomatis terinstal contoh unit testnya). Untuk menjalankan TDD secara otomatis, ketikan “vendor\bin\phpunit” pada root folder laravel.

Script test yang dibuat biasanya disimpan pada folder test\Unit

folder

lalu pada terminal akan muncul tampilan seperti ini

success1

hal tersebut menandakan bahwa semua test lolos.

sebagai contoh lain, kita buat 1 class yang bernama Calculate yang isinya 1 methode untuk menghitung luas

public function areaOfSquare($length)
{
    return pow($length, 2);
}

lalu buat class testnya yang bernama CalculateTest pada folder “tests\Unit”

 

folder-2

 

buat 1 method pada CalculateTest yang berfungsi untuk mengetes hasil balikan dari method “areaOfSquare” pada class “Calculate”

public function test_areaOfSquare_WhenCalledWithLength2_Return4()
{
    $this->calculate = new Calculate();

    $length = 2;

    $response = $this->calculate->areaOfSquare($length);

    $this->assertTrue(is_int($response));
    $this->assertEquals(4, $response);
}

jalankan test maka akan menghasilkan tampilan seperti berikut

success1

untuk apabila ada logic yang salah pada method “areaOfSquare” pada class “Calculate”, maka akan muncul tampilan seperti berikut.

error

 

disana disebutkan bahwa pada test “test_areaOfSquare_WhenCalledWithLength6_Return36″ hasil yang diharapkan adalah 36, sedangkan hasil yang keluar dari uji test adalah 216. dari sana bisa diambil kesimpulan bahwa kodingan di method “areaOfSquare” pada class “Calculate” terdapat kesalahan. Namun tidak menutup kemungkinan juga jika output yang ditulis pada script test yang dibuat salah. padahal hasil yang dikeluarkan oleh kodingan di method tersebut betul.

Kesimpulan :

Pengembangan berbasis tes (TDD) adalah teknik pengembangan di mana harus terlebih dahulu menulis tes yang gagal sebelum menulis kode fungsional baru. TDD dengan cepat diadopsi oleh pengembang perangkat lunak tangkas untuk pengembangan kode sumber aplikasi. TDD tidak menggantikan pengujian tradisional, melainkan mendefinisikan cara yang telah terbukti untuk memastikan pengujian unit yang efektif. Efek samping dari TDD adalah bahwa tes yang dihasilkan adalah contoh kerja untuk menjalankan kode, sehingga memberikan spesifikasi kerja untuk kode tersebut. Pengalaman pribadi, bahwa TDD bekerja dengan sangat baik dalam praktiknya dan ini adalah sesuatu yang harus dipertimbangkan oleh semua pengembang perangkat lunak.

 

Efek Dunning Kruger dan Teknologi Informasi

Keberadaan internet, biaya koneksi dan penetrasi perangkat mobile yang makin terjangkau (terutama Android) telah membuat kita semakin mudah dan cepat menemukan informasi. Tak hanya dari situs-situs berita, kita juga bisa mendapatkan informasi yang di-share di media sosial. Selain informasi, internet juga dapat membuat kita mendapatkan kualitas layanan yang lebih baik dan lebih cepat. Sayangnya, kecepatan menemukan informasi dan melakukan sesuatu ini dapat menjadi candu dan memiliki efek samping, salah satunya adalah tuntutan akan hasil yang instan (sering disebut dengan instant gratification).

Suka tidak suka, paradigma instan makin menyusup dalam kehidupan kita, salah satunya dalam penilaian kita terhadap kompetensi / keahlian diri kita sendiri. Lebih lanjut, hal tersebut menimbulkan ilusi terhadap superioritas. Misalnya, baru baca beberapa artikel sudah merasa jadi orang sholeh. Baru ikut beberapa seminar bisnis, tiba-tiba merasa siap jadi pengusaha dan berkoar-koar bahwa jadi karyawan itu tidak mulia. Nonton acara diskusi politik, tiba-tiba merasa jadi pakar politik.

road-to-success

Ditambah mentalitas intimidatif, judgement plus hobi mem-bully, ilusi superioritas membuat media sosial (atau di era pra-medsos dulu berupa mailing list) menjadi makin “berisik”. Kalau orang lain tidak sepaham / sepemikiran, maka dianggap pasti salah, karena kita merasa “paling” (paling benar, paling tahu, paling pintar). Kalau kehabisan argumen, kita tiarap dulu. Buka Google, cari informasi, kalau hasil googling ternyata kurang mendukung argumen kita, cari terus sampai halaman kesekian, yang penting mendukung argumen kita hehe :)

Namun, fenomena mengganggu dan menyebalkan di atas ternyata lumrah jika dilihat dari sudut pandang psikologi, ilusi superioritas ini disebut dengan efek Dunning-Kruger. Efek Dunning-Kruger adalah bias kognitif yang terjadi pada orang yang tidak kompeten plus memiliki pengetahuan dangkal pada tugas/area tertentu, dimana mereka cenderung menakar kemampuan diri di atas kenyataan yang ada dan menganggap mereka jauh lebih kompeten dibandingkan orang lain serta mengabaikan ketidaktahuan mereka sendiri.

dunning-kruger-chart

Penelitian David Dunning dan Justin Kruger (keduanya dari Cornell University) diinspirasi oleh perampok bank bernama McArthur Wheeler yang sangat over-confidence. Wheeler menggunakan sari lemon pada wajahnya sebelum merampok dua bank di Pittsburgh pada tahun 1995. Wheeler sangat percaya bahwa sari lemon merupakan invisible ink yang dapat membuat wajahnya tidak terekam kamera keamanan. Malam harinya pada hari yang sama, Wheeler ditangkap dan ketika diperiksa oleh polisi, reaksi Wheeler adalah terkejut dan masih tidak percaya bahwa rencana briliannya bisa gagal.

Menurut Dunning, bias kognitif tersebut terjadi karena :

“If you’re incompetent, you can’t know you’re incompetent. The skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is.”

Para pemuda yang masih sangat bersemangat relatif lebih rentan mengalami efek Dunning-Kruger. Sewaktu kuliah, mata kuliah pemrograman di Informatika ITB tidak menekankan pada penguasaan bahasa pemrograman, namun lebih kepada pemahaman algoritma, bukan kepada tools. Beberapa kawan yang pernah ngoprek bahasa pemrograman dari SMP/SMA ada yang merasa tidak nyaman, karena hal yang pernah dipelajari sebelumnya dibabat habis, mereka harus legowo dan learn to unlearn secara bersamaan dengan proses learning yang baru. Uniknya di akhir semester, nilai mata kuliah beberapa kawan yang tidak pernah belajar pemrograman (bahkan ada yang baru belajar menghidupkan komputer ketika kuliah) ternyata bisa lebih tinggi ketimbang yang sebelumnya pernah memprogram.

Bagi beberapa kawan, perkuliahan juga terkesan membosankan dan ketinggalan dibanding kawan-kawan dari kampus lain. Kawan di kampus lain sudah membuat program GUI, HTML hingga mengakses SQL, sementara kami masih console/text based, sorting dan struktur data. Namun beberapa tahun kemudian ketika kami melakukan rekrutmen programmer, ternyata terbukti pengajaran dasar yang benar akan menghasilkan programmer dengan kemampuan problem solving yang lebih terstruktur.

Selepas kuliah, di awal pendirian perusahaan, kami sempat meragukan beberapa saran dari mentor. Saran-saran tersebut bagi kami terasa sangat pragmatis, tidak keren dan tidak kekinian (pada waktu itu), apalagi jika dibandingkan dengan perusahaan baru lainnya (jaman itu belum booming istilah startup / perusahaan rintisan). Jujur, sempat muncul arogansi bahwa kami merasa lebih tahu mengenai jaman dan masa depan :P . Beruntung, kami menuruti saran mentor tersebut. Dua – tiga tahun kemudian barulah terlihat ternyata saran yang disampaikan benar adanya.

Perlu kita pahami bahwa semua bias kognitif adalah natural dan manusiawi. Oleh karena itu, efek Dunning-Kruger bisa dialami pada berbagai lapisan usia maupun jenis profesi. Faktor kultur organisasi / industri juga bisa memiliki pengaruh. Fenomena argumentasi tanpa tanggung jawab atau debat kusir akan relatif lebih sedikit kita temui di bidang kedokteran dan militer jika dibandingkan dengan bidang lain seperti Teknologi Informasi.

Terkait dengan efek Dunning-Kruger di bidang Teknologi Informasi, berikut ini beberapa contoh yang pernah kami temukan :

  • klien yang memiliki kompetensi ilmu hukum bisa merasa jauh lebih kompeten dalam membuat software ketimbang konsultan IT yang mereka hire sendiri dan menganggap konsultan IT mereka tidak melakukan apa-apa (Anda bisa mengganti ilmu hukum dengan bidang-bidang lainnya, tidak ada maksud merendahkan ilmu hukum)
  • para script kiddies yang baru belajar hacking lebih banyak berkoar-koar ketimbang hacker profesional
  • programmer software bisa merasa lebih jago mengenai HRD daripada praktisi HRD yang minta dibuatkan software-nya
  • klien merasa lebih jago dan update tentang web design ketimbang web designer
    classics : http://theoatmeal.com/comics/design_hell
  • non-programming programmer yang beberapa kali kami temukan dalam tes rekrutmen Akhdani. Yang kami amati, beberapa individu yang merasa sudah menjadi programmer berpengalaman tersebut tidak memahami konsep fungsi/prosedur, kondisional dan variabel dengan baik. Jadi mereka lebih banyak menggunakan copy-paste + trial error ketimbang analisis masalah dan memahami kode
  • hasil ngobrol dengan beberapa kawan, laju kenaikan expected salary programmer pemula semakin tinggi, di atas inflasi dan tidak sebanding dengan hukum permintaan-penawaran / kelangkaan. Kehadiran Google dan Stackoverflow sepertinya membuat banyak orang merasa lebih kompeten ;)

Beruntung kami tidak terlalu lama terjebak efek Dunning-Kruger di awal-awal perusahaan. Adalah wajar dan manusiawi jika kita mengalami efek Dunning-Kruger, yang lebih penting adalah bagaimana meminimalisir dampak negatifnya, misalnya :

  • Menerapkan prinsip adab sebelum ilmu
    Prinsip klasik yang sering diajarkan di pesantren ini bisa membuat kita berpikir dan lebih hati-hati dalam bersikap, berpendapat dan mengambil tindakan. Efek Dunning-Kruger cenderung akan berakibat negatif apabila dikonkritkan dalam bentuk tindakan spontan dan minim pikir, seperti kasus perampokan bank oleh McWheeler dan kebisingan perdebatan di media sosial
  • Terus belajar dan berusaha menambah pemahaman
    Sebagaimana bisa kita lihat pada grafik di atas, makin bertambahnya pemahaman akan menurunkan level kepercayaan diri karena kita merasa ternyata banyak yang belum kita ketahui, dan fase awal ini akan memicu pembelajaran yang lebih dalam hingga pada titik tertentu kepercayaan diri kita berbalik naik kembali.

Sejalan dan koheren dengan kutipan yang dipopulerkan Steve Jobs

“stay hungry, stay foolish”

Seorang ulama Islam, Imam Al-Ghazali pernah menyampaikan ada 4 jenis manusia, yaitu :

  1. Seseorang yang tahu (berilmu), dan dia tahu kalau dirinya tahu
  2. Seseorang yang tahu (berilmu), tapi dia tidak tahu kalau dirinya tahu
  3. Seseorang yang tidak tahu (tidak atau belum berilmu), tapi dia tahu alias sadar diri kalau dia tidak tahu
  4. Seseorang yang tidak tahu (tidak berilmu), dan dia tidak tahu kalau dirinya tidak tahu

Di era overload informasi seperti sekarang, sangat mungkin jika kita mengalami promosi-degradasi posisi antara nomor 1 hingga 4. Yang penting adalah cepat menyadari apabila kita sedang berada pada posisi nomor 4.

Disclaimer : penulis bukan praktisi psikologi dan tidak pernah masuk pesantren, oleh karena itu sangat mungkin ada efek Dunning-Kruger dalam tulisan ini sendiri, harap dimaklumi, cheers ;)

Bacaan lainnya :

https://en.wikipedia.org/wiki/Dunning–Kruger_effect

https://en.wikipedia.org/wiki/Invisible_ink

http://arstechnica.com/science/2012/05/revisiting-why-incompetents-think-theyre-awesome/

https://mindhacks.com/2010/02/11/the-burglar-with-the-lemon-juice-disguise/

https://blog.codinghorror.com/the-nonprogramming-programmer/

Membaca Akhdani

image

Dalam beberapa kesempatan ada beberapa kawan yang menanyakan konsep apa yang dipakai dalam menjalankan perusahaan (Akhdani Reka Solusi – ARS) selama hampir 10 tahun ini. Buat kami itu adalah pertanyaan gampang-gampang susah,  mengingat pada dasarnya latar belakang kami adalah software engineer. Modal saya pribadi ya membaca buku & bertanya kepada orang-orang yang saya anggap lebih mumpuni.

Kebetulan tahun lalu saya membaca artikel yang menyebutkan beberapa buku yang melandasi konsep pemikiran Ridwan Kamil dalam mengelola kota Bandung, yang saya catat antara lain :

  • The Rise Of Creative Class
  • Cities and the Creative Class
  • The Flight of the Creative Class
  • Who’s Your City

Buku pada list di atas, semuanya merupakan buah pemikiran Richard Florida. Terinspirasi artikel tersebut, jadi ada ide untuk membuat tulisan dengan judul di atas, sekaligus dalam rangka menuju 10 tahun ARS.

Singkat saja, untuk “membaca” konsep-konsep yang dijalankan ARS, kawan-kawan bisa membaca beberapa buku berikut ini :

Pada kesempatan lain saya akan mencoba membahas secara singkat mengenai ide-ide dan pemikiran yang disampaikan oleh buku-buku di atas, harap maklum #soksibuk :D

Evaluasi Untuk Para Enterpreneur Pemula

Postingan berikut ini kami dapatkan dari sebuah group WhatsApp, mengenai evaluasi & pengingat kepada enterpreneur pemula. Mencakup ketenaran, lomba, fokus, financial literacy, pendapatan, motivasi, akuntansi dan lain-lain. Sayangnya belum kami temukan sumber penulis aslinya untuk dicantumkan (Adakah yang tahu?). Mengingat isinya cukup bermanfaat bagi para enterpreneur, maka layak untuk dicatat dalam blog ini, dengan beberapa modifikasi tentunya. By the way, setelah running business selama 9 tahun, kami pun masih merasa sebagai pemula :D .

15 Evaluasi & Pengingat untuk Para Entrepreneur Muda Pemula :

  1. Hati-hati dengan publikasi dan ketenaran

    Seiring dengan perkembangan bisnis, akan ada masa dimana media akan menghampiri atau orang-orang / komunitas mengundang jadi pembicara. Hal ini adalah pedang bermata dua. Ingat, bagaimana pun kita ini bukan artis atau pembicara, kita adalah pebisnis. Jangan sibuk jalan-jalan terus, namun
    bisnis riil kita ternyata malah tidak berjalan. Jangan sibuk ngomong ke orang lain, eh sama karyawan malah diomongin dari belakang :( . Jangan-jangan pendapatan kita malah berasal dari kegiatan sebagai pembicara, bukan dari bisnis riil :D

  2. Menang lomba tidak menggambarkan sehatnya bisnis kita

    Juara lomba diputuskan oleh orang luar dan sifatnya subyektif, bisa jadi yang jadi penilai juga bukan praktisi. Bahkan terkadang, lomba yang diadakan memuat kepentingan dari pihak yang punya lomba, entah kepentingan Public Relation, branding, atau CSR sekedarnya agar laporan pajak aman. Belum tentu mereka juga peduli dengan bisnis kita. Ikut banyak perlombaan boleh, tapi jangan melupakan aspek how to build business, karena kita bukan sedang berlomba, tapi sedang berbisnis.

  3. Membaca kesehatan bisnis (financial literacy)

    Kita bisa tahu bisnis kita sehat, secara sederhana dari melihat 3 hal : laporan laba rugi, neraca, dan cashflow. Laporan laba rugi memperlihatkan seberapa untung bisnis yang kita jalankan. Neraca menggambarkan seberapa banyak kekayaan dan aset yang kita punya. Cashflow memperlihatkan seberapa liquid perputaran uang kita dan menggambarkan seberapa lama perusahaan kita bisa bertahan “berpuasa”. Tiga laporan keuangan tersebut sebaiknya harus dikuasai sebelum berbisnis.

  4. Praktek, evaluasi dan optimasi

    Stop ikut seminar-seminar, training-training ketika sudah 2 tahun tidak ada perubahan. Bisa jadi kita sedang terperangkap oleh genjutsu (naruto : ilmu
    mempengaruhi 5 indra) dari pembicara. Untuk tahun-tahun pertama memang sangat disarankan untuk ikut seminar-seminar dasar tentang bisnis. Tapi, trennya, masih banyak yang tidak keluar dari jeratan seminar-seminar atau training selama bertahun-tahun, bahkan hal ini berkembang menjadi salah satu industri sendiri yang menjamur.

    Mereka yang ikut seminar berkali-kali sampai hafal materi pembicara dan akhirnya nyoba-nyoba buka seminar sendiri. Tadinya mau bisnis kuliner, eh malah jadi pembicara bisnis kuliner yang jika dilihat dengan poin (3) di atas sebenarnya bisnisnya amburadul. Di lapangan, orang seperti ini banyak.

  5. Be objective

    Jangan terlalu kagum berlebihan dengan orang-orang yang kita anggap sukses, bisa jadi ternyata hanya sekedar pencitraan saja. Coba kenal lebih dalam dengan mereka, bisa jadi Anda akan menemukan banyak hal yang berbeda dari pencitraan orang-orang yang Anda kagumi.

    Bagi yang muslim, Islam telah mengajarkan untuk mengenal orang yaitu dengan cara: menginap bersamanya minimal 3 hari, berpergian jauh bersama, dan berbisnislah bersama mereka.

  6. Segera hilangkan rasa bahwa diri ini hebat

    Mungkin komunitas atau lingkungan Anda akan menganggap Anda sudah hebat, tapi di luar sana ada yang jauh berkali-kali lipat lebih hebat dari Anda. Mungkin, saat ini Anda disandingkan dengan para orang-orang hebat di luar sana, tapi sebenarnya belum pantas. Yang terjadi akhirnya muncul jebakan “merasa hebat”. Ketika sudah muncul, maka kita akan merasa ilmu, pengalaman, kejeniusan kita telah berada pada level / ruang orang yang sebenarnya lebih tinggi dari kita. Kemudian, kita tak akan pernah bergerak kemana-mana.

  7. Jangan cepat mau jadi boss atau menjadi orang atas

    Ada sindrom pada anak muda cerdas merasa layak untuk diberi tempat dan penghargaan ini itu dalamw aktu yang relatif singkat. Akhirnya muncul keangkuhan dan menilai apa-apa dari kacamata sendiri. Merasa harus dihargai berlebih, sementara perbandingan yang dipakai bukanlah perbandingan yang objektif.

    Kita akan terjebak tidak mau belajar dari bawah, karena merasa sudah di atas sehingga susah untuk bekerjasama jika ada pada posisi menjadi bawahan.Jika hidup rata-rata manusia 60an tahun, tidak apa-apa dalam usia 22 tahun jadi bawahan dulu selama beberapa tahun, anggap beberapa tahun tersebut sebagai waktu belajar bagaimana menjadi atasan.

    Wah panjang juga ya, bersambung ke Part 2

Akhdani Culture Series : Result Oriented

Beberapa kenalan menyarankan kami berbagi mengenai budaya kerja / corporate culture di Akhdani yang mungkin cukup unik bagi mereka. Karena admin sedang (beralasan) banyak pekerjaan, maka sebagai awalan, berikut ini adalah hasil copy paste dari tulisan blog (sayangnya sudah mati suri) salah satu founder sekaligus direksi, ditulis pada tahun 2009, mengenai prinsip result oriented. Tulisan tersebut bisa jadi adalah salah satu dokumentasi pertama mengenai kultur kerja di Akhdani sejak 2006.


Sesi Mimpi : anti penindasan korporat

Dulu waktu mentoring agama Islam (saya mentor cadangan dengan pengetahuan syar’i yg pas-pasan :D ) di kampus, beberapa adik kelas menanyakan kenapa kok jadi pengusaha, apakah karena potensi memiliki pendapatan hingga tak terbatas ? Sebenarnya alasan utamanya bukan itu, lebih kepada passion, saya jadi pengusaha sebenarnya lebih karena :

  • Tidak cocok dengan jam kerja kantoran yang fixed
  • Tidak suka dengan atasan yang seenaknya, tidak mau mengerti apakah stafnya punya masalah atau tidak. Tidak semua atasan seperti itu, namun populasi atasan yang baik pasti langka :D
  • Otak technical saya sepertinya moody, lebih sering “hidup” dan kreatif di waktu santai ketimbang office hours:D
  • Tidak suka dengan office politics. Kedua ortu saya berstatus PNS dan karyawan, beliau berdua terkadang menceritakan beberapa dampak office politics yang mereka alami .. :) banyak bekerja & berprestasi tapi sering kali tidak dihargai karena berbagai faktor non objektif, ide-ide yang dicuri oleh teman sekantor sendiri, teman sekantor yang tidak mau action, tetapi luar biasa menjilatnya kpd atasan, dsb …
  • Sepertinya lebih menyenangkan membuka lowongan kerja ketimbang mencari pekerjaan, lebih bermanfaat bagi orang lain :)

Jadi boleh dikatakan bahwa saya mungkin termasuk orang yang cukup anti “penindasan korporat”. Contoh penindasan korporat : saya pernah meeting sore hari dengan 2 ibu dari sebuah perusahaan IT besar, ketika sudah maghrib dan meeting selesai ternyata mereka masih ada meeting dengan bos jam 20, lantas nasib suami dan anak-anaknya gimana? Mereka sempat curhat : harus datang jam sekian, dan pokoknya harus kerja padahal di rumah sedang ada masalah. Dimarahi bos karena membantu mengurusi tetangga yang meninggal dunia, dsb.

Karena saya tidak ingin diperlakukan seperti itu, jadi saya tidak boleh memperlakukan orang lain seperti itu. Beberapa efek pemikiran anti “penindasan korporat” ini di kantor antara lain :

  • karyawan boleh datang tidak tepat waktu
  • boleh bekerja di rumah dulu atau di kampus, kemudian datang untuk koordinasi
  • boleh main game di kantor, asal jangan main game sepanjang hari
  • dan beberapa kebebasan lain

Namun tentunya dengan beberapa syarat :

  • target pekerjaan tercapai, deadline tidak boleh lewat
  • kalau telat atau tidak masuk memberi tahu pihak berwenang :)
  • tidak merugikan/merepotkan orang lain
  • maklum dengan gaji yang tidak terlalu besar dibandingkan perusahaan lain yang sejenis, jadi jangan menuntut terlalu banyak dulu hihi :D

Pak Harry Sufehmy mungkin menyebutnya dengan istilah KBH / result oriented:) . Baru-baru ini, ketika browsing, saya menemukan link berikut ini :
http://askmonty.org/wiki/index.php/The_hacking_business_model

Dokumen tersebut dibuat berdasarkan pengalaman di masa-masa awal MySQL AB dan perusahaan open source lainnya. Banyak hal-hal ingin saya terapkan di perusahaan liliput saya, ternyata tertulis di dokumen tersebut. Sambil menerapkan pola result oriented ini, sebenarnya masih ada beberapa pertanyaan yang mengganjal :

  • Saya sebenarnya masih ingin memberikan beberapa benefit lagi, seperti waktu cuti yang lebih banyak, asuransi kesehatan, bonus Idul Adha : terserah untuk beli qurban atau keperluan lainnya, dsb. Namun apakah karyawan akan memberikan kontribusi maksimal seiring dengan kebebasan yang diberikan perusahaan ? Jujur saja, perilaku orang Indonesia cukup “unik”, dulu beberapa kali saya menemui orang-orang yang tidak tahu berterima kasih, malah cenderung menusuk walaupun sudah dibantu, hanya berfikir keuntungan jangka pendek dan memanfaatkan niat baik orang lain :(. Saya berharap rekan-rekan yang kami rekrut tidak seperti itu dan hingga saat ini alhamdulillah belum ada.
  • apakah klien beranggapan bahwa kami profesional dengan pola kerja seperti ini ?

Well, sejauh ini alhamdulillah beberapa mitra masih percaya dengan kinerja perusahaan liliput ini, dari 2006 perusahaan konsisten mencetak laba. Prediksi saya tantangan dan ujian sebenarnya terhadap pemikiran anti “penindasan korporat” ini akan datang ketika perusahaan ini makin membesar, makin banyak kontrak pekerjaan dan makin banyak orang bergabung sebagai anggota perusahaan. Buat teman-teman dan rekan kerja, saya mohon doanya moga-moga rezeki perusahaan liliput ini dilancarkan dan tetap anti penindasan korporat, amiin…

Meja Knockdown dan Sembilan Tahun Akhdani

Akhir bulan April lalu, putra penulis berusia 9 tahun. Ingatan pun kembali ke 9 tahun yang lalu, ketika penulis menunggu istri melahirkan, teman-teman di kantor merakit meja knock down, memotong kabel listrik dan LAN, membuat ekstensi stop kontak dan melakukan cabling di rumah kontrakan di kawasan pasar Citamiang yang kami jadikan kantor. Berarti, usia perusahaan Akhdani secara de facto sudah berumur 9 tahun juga.

Ada beberapa versi penelitian mengenai survival rate perusahaan baru, bahwa perusahaan yang bertahan melewati masa 1 tahun = x%, 2 tahun = y%, 3 tahun = z% dan seterusnya. Hasilnya mengarah pada kesimpulan yang mirip, bahwa banyak perusahaan yang gagal sebelum berusia 5 tahun dan makin sedikit lagi yang berusia 10 tahun. Dari aspek survival, Akhdani sudah terbukti sukses bertahan selama 9 tahun. Namun bila dilihat dari aspek-aspek fisik yang “kasat mata”, sah-sah saja jika orang menilai kesuksesan Akhdani belumlah impresif.

Jujur saja, sepanjang perjalanan selalu muncul godaan untuk memperlihatkan kesuksesan fisik seperti menyewa kantor yang “representatif” atau hal-hal yang bersifat premature scaling lainnya. Bagaimana tidak tergoda, melihat perusahaan lain (seangkatan atau bahkan lebih muda) berekspansi dengan agresif, merekrut banyak karyawan brillian dengan gaji relatif besar atau menyewa kantor yang representatif di kawasan perkantoran Jakarta.

Namun, dahulu salah seorang mentor kami memberi wejangan :

  1. Bangun dan matangkan “isi” terlebih dahulu, jangan “bungkus”. Jika “isi” berkembang, “bungkus” akan mengikuti dengan sendirinya.
  2. Definisi mengenai kesuksesan itu relatif, masing-masing perusahaan atau individu dapat memiliki definisi suksesnya sendiri. Parameter sukses tertentu menurut orang lain, belum tentu sesuai bagi kita
  3. Pikirkan cara untuk membangun perusahaan yang langgeng, tidak sekedar tumbuh dengan cepat atau parameter fisik semata.
  4. Mindset, kesabaran dan reputasi lebih penting ketimbang modal finansial.

Sebagaimana yang ditulis oleh Prof. Rhenald Kasali, fundamental usaha itu sesungguhnya hanyalah kepercayaan dan daya tahan. Ada orang yang bertahan 6-7 tahun sampai usahanya benar-benar meledak dan ia mulai menangguk untung. Namun ada yang hanya bertahan dua tahun saja. Keduanya sama-sama menghabiskan total biaya yang sama. Sekarang, Akhdani ternyata bisa bertahan lebih lama ketimbang beberapa perusahaan yang pada waktu itu lebih keren dan ekspansif. Apakah mereka gagal bertahan karena premature scaling? Wallahu’alam, mungkin kami hanya lebih beruntung saja ….

Kembali ke masalah sukses atau tidak sukses, jika ada pertanyaan prestasi apa yang membanggakan selama 9 tahun terakhir? Selain dari usia perusahaan, jika dilihat dari aspek yang lebih luas, dari kacamata stakeholder (di mana karyawan adalah salah satu elemen stakeholder), maka menurut pendapat pribadi penulis, prestasi tersebut berupa konsistensi dan disiplin dalam penggajian. Sejak Mei 2006, Akhdani selalu konsisten tepat waktu untuk masalah payroll, selama 9×12(+1 THR) bulan tidak ada keterlambatan sekalipun. Mengapa ini kami anggap sebagai prestasi? Karena bagi kami hal tersebut adalah value yang sangat-sangat penting. Ada beberapa perusahaan yang lebih terkenal, kantornya keren, petinggi perusahaan pakai mobil keren, namun pernah mengalami keterlambatan gaji, bahkan ada yang menelantarkan karyawan.

Bagi korporasi yang memiliki akses kepada permodalan, hal tersebut mungkin hal yang biasa saja. Namun bagi Akhdani (yang didirikan dengan modal meja dan laptop), itu adalah prestasi tersendiri. IMHO, melakukan pencapaian kecil namun konsisten bisa jadi lebih sulit ketimbang pencapaian mengesankan yang bersifat single shot. Misalnya, masyarakat cenderung lebih menyukai berinfak besar pada bulan Ramadhan saja, ketimbang berinfak lebih kecil namun konsisten sepanjang tahun.

Saat ini, sebagian besar meja-meja knock down murah dan ekstensi stop kontak yang dirakit 9 tahun lalu masih berfungsi. Begitu juga dengan laptop biru bongsor dengan RAM 512 MB…..So, the stones are still rolling …. mari menuju 10 tahun Akhdani … ;)

-ZH-

Inspirasi :

  1. http://blog.startupcompass.co/discover-the-patterns-of-successful-internet
  2. http://www.washingtonpost.com/blogs/fact-checker/wp/2014/01/27/do-9-out-of-10-new-businesses-fail-as-rand-paul-claims/
  3. http://www.ciputra-uceo.net/blog/2015/5/12/umur-perusahaan-definisi-dan-analisa-selama-4-tahun
  4. http://bisniskeuangan.kompas.com/read/2015/05/06/054500826/Fenomena.Bisnis.Kuliner.di.Jalan.Senopati.Jakarta
  5. http://www.quora.com/What-percentage-of-startups-fail