Startup perangkat lunak saat ini memiliki keunggulan yang signifikan dibandingkan lima hingga sepuluh tahun yang lalu, sebagian karena proliferasi penyedia cloud hosting skala besar seperti Google Cloud Platform (GCP), Amazon Web Services (AWS), dan Microsoft Azure. Dengan sejumlah besar layanan terkelola yang tersedia dengan satu klik tombol, mereka dapat dengan cepat membuat prototipe solusi mereka dan membawanya ke pasar dalam waktu singkat, dan dalam skala yang hampir tak terbatas. Meskipun saat ini mungkin tampak lebih sederhana, menyiapkan startup untuk penskalaan di cloud tetap membutuhkan pertimbangan yang cermat.

Saya beruntung telah menjadi bagian dari berbagai organisasi teknologi selama lebih dari dua puluh tahun, mulai dari perusahaan rintisan bootstrap greenfield, hingga perusahaan yang didanai ventura dan didanai ekuitas swasta, dan bahkan konglomerat global dengan IPO. Belajar dari begitu banyak orang berbakat dan mentor di sepanjang jalan, saya "memilih ceri" pelajaran, alat, teknik, dan proses untuk dijalankan.

Dalam upaya untuk "membayar ke depan", saya ingin berbagi beberapa pelajaran. Artikel pertama dalam seri ini akan memperkenalkan konsep dan sumber daya yang menurut saya berguna untuk membangun dan menskalakan startup perangkat lunak. Di artikel kedua , kami akan merancang startup kencan online fiktif untuk mengilustrasikan bagaimana bagian-bagian ini cocok satu sama lain. Di artikel ketiga , kami mengilustrasikan bagaimana mereka pada akhirnya menginformasikan arsitektur cloud Anda menggunakan GCP.

• Bagian 1: pengantar latar belakang dan metodologi
• Bagian 2: menerapkan metodologi dengan startup fiktif
• Bagian 3: merancang dan menskalakan infrastruktur cloud

Awal tahun 2020 saya memutuskan untuk mencoba sesuatu yang baru; alih-alih membangun dan mengembangkan startup perangkat lunak, saya mulai memberi nasihat dan mendukung mereka dengan bergabung dengan mitra cloud yang berakar di Israel bernama DoiT International . Perusahaan kami sepenuhnya terpencil dan sejak itu berkembang dari sekitar 50 orang menjadi hampir 500 orang secara global hanya dalam waktu dua tahun, mendukung lebih dari $1 miliar dalam konsumsi cloud tahunan. Saya selalu kagum dengan seberapa baik kami melestarikan budaya kami melalui pertumbuhan yang begitu cepat sambil menarik dan mempertahankan begitu banyak orang berbakat.

Ribuan organisasi memilih DoiT sebagai mitra layanan cloud mereka. Mereka mendapat manfaat dari saran dan dukungan tanpa biaya, dan perangkat lunak canggih yang dirancang untuk memenuhi janji awal cloud — fokus pada produk dan pelanggan Anda, dan jangan khawatir tentang hal lainnya. Meskipun kami ingin menganggapnya sesederhana itu, biasanya pelanggan kami memiliki tim teknis yang sangat terampil sebelumnya.

Salah satu tren yang baru-baru ini saya perhatikan adalah pertumbuhan startup perangkat lunak tahap awal yang mengadopsi teknologi cloud yang mungkin tidak memiliki tim besar atau keahlian cloud yang mendalam. Sebagai seorang pengusaha perangkat lunak, saya berharap bahwa berbagi pelajaran yang didapat baik dari “kehidupan lampau” saya dan di DoiT akan membuat perjalanan Anda semakin sukses.

Hari-hari awal

Mengambil langkah menjauh dari teknologi, pertama-tama mari kita jelajahi perjalanan dari mengidentifikasi masalah, hingga membangun perusahaan yang berdedikasi untuk menyelesaikannya, dan seterusnya. Ada beberapa metodologi dan kerangka kerja populer di luar praktik terbaik cloud yang mungkin Anda hargai saat organisasi Anda semakin matang.

Setiap teknik yang diilustrasikan di atas adalah iteratif itu sendiri, tetapi seperti yang akan kita lihat di artikel berikutnya dalam seri ini, keluaran dari masing- masing teknik akan memberi tahu orang lain.

TL;DR; Sumber daya daring yang bermanfaat

Daripada menjelaskan teknik dan konsep di atas, saya sarankan menonton video ini untuk mengisi kekosongan dan berfungsi sebagai primer bagi kami untuk menerapkannya.

• Haruskah saya membangun startup (14 mnt)— Michael Seibel, Y Combinator
• Strategi vs perencanaan (9 mnt) — HBR [gunakan rencana 1 halaman seperti OGSM]
• Rangkuman Lean Startup (13 mnt)— Eric Ries
• Memvalidasi ide bisnis Anda (9 mnt)— Eric Ries
• Lean UX (60 mnt)— Jeff Gothelf
• Menggunakan kanvas Lean UX (15 mnt)— Jeff Gothelf
• Produk Bangunan (59 mnt)— Michael Seibel, Y Combinator
• Bagaimana merencanakan MVP (13 mnt)— Michael Seibel, Y Combinator
• Pemetaan Cerita Pengguna (50 mnt)— Jeff Patton
• Panduan Utama untuk Pemetaan Cerita Pengguna — Nick Muldoon, Easy Agile
• Arsitektur Perangkat Lunak dengan Model C4 (35 mnt)— Simon Brown
• Membangun budaya eksperimen di Spotify (47 mnt)— Ben Dressler
• DevOps vs SRE (44 mnt)— Seth Vargo, Google

Setelah Anda mengenali masalah yang ingin Anda selesaikan, ada baiknya Anda menggambarkan ke mana Anda akan pergi, dan beberapa indikator kunci yang Anda berada di jalur untuk memberikan nilai. Ini mirip dengan cara Amazon meminta tim untuk membuat draf siaran pers yang menggambarkan apa yang mereka bangun di masa mendatang, sebelum mereka disetujui untuk membuatnya.

Sekitar 10 tahun yang lalu selama sesi perencanaan sepanjang hari, seorang mentor yang telah menjadikan perusahaannya publik, dan kemudian menjualnya ke Oracle seharga hampir $2 miliar, memperkenalkan saya pada OGSM Framework . Itu singkatan dari Tujuan, Sasaran, Strategi, dan Ukuran. Ini memaksa Anda untuk secara ringkas menggambarkan di mana Anda akan berada 3–5 tahun ke depan, beberapa tujuan terukur di sepanjang jalan, sambil menelusuri strategi dan taktik jangka pendek untuk mencapainya.

Anda berakhir dengan rencana bisnis satu halaman, dokumen hidup yang Anda tinjau kembali dan perbaiki, sehingga seluruh tim dapat berkumpul dan menyelaraskan fokus dari semua aktivitas. Misalnya, jika beberapa aktivitas tidak dipetakan ke strategi yang ditetapkan untuk mencapai tujuan, Anda mempertanyakan apakah aktivitas tersebut benar-benar layak dilakukan, atau apakah Anda memperbarui strategi Anda.

Beberapa orang mungkin bertanya-tanya apa bedanya dari framework populer lainnya Objectives and Key Results (OKR). OGSM melihat ke masa depan, sedangkan OKR kebanyakan berfokus pada tujuan jangka pendek. Bergantung pada tahapan perusahaan Anda, memperkenalkan OKR mungkin masuk akal, tetapi seringkali satu visi jangka panjang yang dapat didukung semua orang adalah yang dibutuhkan "Bintang Utara".

Ada banyak teknik lain seperti analisis SWOT, Porter's 5 Forces, Balanced Scorecard, atau McKinsey's 3 Horizons, yang dapat dimasukkan ke dalam keseluruhan rencana strategis Anda, tetapi OGSM tetap menjadi alat bantu pribadi saya untuk mempersempit fokus tim pada hal-hal yang penting dan berbagi penglihatan yang lebih besar.

Membuat ide

Prinsip dan proses panduan di awal perjalanan Anda dapat membantu menyelaraskan tim saat Anda berkembang. Saya percaya bahwa budaya yang digerakkan oleh data, dan pola pikir mengukur segala sesuatu, harus menjadi bagian dari budaya Anda dan datang dari atas, dan terbukti dalam setiap interaksi.

Beberapa sumber favorit saya yang memperkuat budaya eksperimental ini termasuk Lean Startup (dan Lean Canvas) oleh Eric Ries, dan Lean UX oleh Jeff Gothelf. Hampir setiap penasihat dan inkubator startup menyarankan para pendiri untuk mengukur segalanya, melakukan iterasi dengan cepat, dan membangun produk yang layak minimum (MVP) untuk menguji ide mereka melawan pasar. Ini semua beresonansi dengan prinsip "Lean".

Jeff Gothelf menerapkan prinsip "Lean" ke arah yang saya suka karena prinsip ini berlaku untuk setiap tim, departemen, dan gagasan dalam organisasi dengan berbagai ukuran. Premisnya adalah "kami tidak tahu apa-apa" dan untuk mempelajari [apa yang diinginkan pelanggan], dan apa yang benar-benar menyelesaikan masalah, kami menerapkan metode ilmiah — membentuk pernyataan hipotesis, mengujinya sambil mengukur, menganalisis hasil, dan mengoreksi sesuai kebutuhan . Nilai dari pendekatan ini adalah meminimalkan upaya yang sia-sia dan memvalidasi bahwa Anda memecahkan masalah yang tepat dengan lebih cepat.

Rancangan

Ketika saya menyaksikan orang lalai mendokumentasikan sistem dan arsitektur perangkat lunak mereka, itu mengingatkan saya pada seseorang yang mencoba membangun rumah dengan tumpukan kayu. Tentu Anda bisa mengetahuinya pada akhirnya, tetapi Anda akan jauh lebih cepat dengan lebih sedikit kesalahan jika Anda punya rencana. Dua teknik favorit saya untuk desain produk meliputi Pemetaan Cerita Pengguna , dan Model C4 .

Dengan menuliskan semuanya, Anda memastikan pemahaman bersama dan meminta pertanggungjawaban setiap orang untuk menyampaikan apa yang telah disepakati.

Beberapa tahun yang lalu saya diundang sebagai pembicara di KTT CTO tahunan untuk firma ekuitas swasta (PE), Francisco Partners . Saya duduk di sesi lain dan salah satu yang paling menarik adalah salah satu mitra memberi nasihat kepada CTO dan eksekutif portofolio lain tentang metrik pelacakan dalam organisasi produk mereka. Salah satu metrik yang mengejutkan saya, tetapi sekarang sangat masuk akal, adalah mengukur jumlah pengerjaan ulang untuk menilai efektivitas manajer produk. Saya telah bertanya kepada para pemimpin teknik lainnya sejak mereka mengukur pengerjaan ulang, dan sebagian besar menghargainya tetapi belum.

Pengerjaan ulang adalah metrik utama yang dapat Anda pengaruhi dengan meluangkan waktu untuk memahami pelanggan, dan memprioritaskan memberikan nilai paling cepat kepada mereka. Inilah tepatnya yang dibantu oleh latihan pemetaan cerita pengguna sambil mendorong kolaborasi di antara berbagai pemangku kepentingan. Argumen saya untuk itu, di setiap tahap perusahaan, adalah jauh lebih murah dan lebih cepat untuk memindahkan beberapa kotak di papan tulis bersama daripada memulai siklus pengembangan yang kemudian menghasilkan pengerjaan ulang.

Saya pertama kali mengakui bahwa saya memiliki beberapa diagram arsitektur yang jelek di zaman saya; Saya telah menyaksikan lebih banyak lagi. Penting untuk meluangkan waktu untuk menuliskan arsitektur Anda, dan hubungannya dengan sistem lain. Model C4 adalah salah satu cara terbaik untuk melakukannya dengan cara standar tanpa memerlukan pengetahuan UML. Seperti yang dijelaskan dalam tautan video di atas, praktik standarnya adalah mendesain hingga kedalaman 3 level (tampilan komponen). Ada produk seperti IcePanel yang membuat ini lebih mudah, atau berbagai plugin atau perkakas di platform lain. Ini lebih cepat dari yang Anda kira, dan kami mengilustrasikannya di artikel berikutnya dalam seri ini.

Membangun

Anggaplah tim Anda berpengalaman dalam fase ini. Saat Anda berkembang, mengadopsi kerangka kerja yang terdefinisi dengan baik untuk menerapkan ideologi Agile dapat membantu Anda meningkatkan skala. Jika Anda mengikuti prinsip "Lean", dan mengubah prioritas Anda berdasarkan pembelajaran, Anda sudah berada di jalur yang benar. Saat fokus organisasi bergeser dari kecepatan dan inovasi, ke pertumbuhan dan stabilitas, perhatikan titik belok dan komposisi tim di sepanjang jalan.

Operasional

Seiring dengan mematangkan praktik pengembangan produk Anda, Anda juga ingin mempertahankan budaya tanggung jawab bersama. Di sinilah prinsip-prinsip DevOps berperan. Google telah membagikan penerapan DevOps mereka yang disebut Site Reliability Engineering (SRE), dan banyak organisasi telah mengadopsi praktik ini.

Meskipun mungkin tidak perlu memiliki tim atau fungsi terpisah, tim staf minimal dengan insinyur yang memiliki kecenderungan untuk operasi, pemantauan, dan otomatisasi akan memberikan keuntungan. Kami akan mengeksplorasi konsep-konsep ini secara lebih rinci saat kami mempelajari lebih dalam tentang contoh startup, dan menentukan arsitektur dan infrastruktur cloud-nya.

Merencanakan pertumbuhan

Ketika sebuah startup tumbuh melampaui tim pendiri yang kecil, begitu pula kompleksitas komunikasi, dan tata kelola, seperti yang diilustrasikan di bawah ini.

Perusahaan telah memecahkan tantangan penskalaan ini dengan mengenali titik belok bisnis mereka, dan membentuk tim yang berdedikasi, sebagian besar otonom, untuk mengatasi tantangan tertentu.

Sumber yang bagus untuk meningkatkan tim perangkat lunak Anda, misalnya, adalah posting blog ini oleh Seth Blank , yang sangat saya rekomendasikan untuk dibaca. Blank memperingatkan bahwa proses, dan dalam beberapa kasus bahkan orang-orang, yang membantu perusahaan berdiri di beberapa titik dapat menjadi penghambat pertumbuhan dan skalabilitasnya di masa depan, atau paling baik diarahkan ke "hal berikutnya". Di sinilah 3 Cakrawala McKinsey menjadi relevan untuk perencanaan strategis masa depan. Sebaliknya Blank yang berbeda, Steve Blank, berpendapat mengapa itu tidak berlaku lagi hari ini .

Ada sumber daya lain yang disebut " Topologi Tim " yang menyediakan model adaptif langkah demi langkah yang praktis untuk desain organisasi dan interaksi tim. Fokusnya adalah pada perampingan organisasi, dan platform, dengan apa yang mereka sebut sebagai platform yang layak tertipis (TVP).

Konsep lain yang menurut saya berguna untuk meningkatkan organisasi, atau produk, adalah Kubus Skala Mitra AKF . Saya pertama kali mengetahui hal ini bertahun-tahun yang lalu ketika direferensikan dalam sebuah buku berjudul " The Art of Scalability " yang saya beli untuk pimpinan tim saya di startup sebelumnya — ini juga merupakan referensi lain yang berguna kapan saja, melompat ke bab yang relevan sesuai kebutuhan.

Hampir semua orang bisa setuju, namun, karena perusahaan Anda terus berkembang, dan membentuk tim yang berdedikasi, kebutuhan akan tata kelola dan proses, dokumentasi, pendampingan, dan pelatihan yang terdefinisi dengan baik tumbuh bersamanya. Saya telah menyaksikan banyak organisasi pada tahap ini baru-baru ini juga mencari panduan tentang cara terbaik menyusun infrastruktur cloud mereka untuk mengakomodasi banyak tim mereka secara efisien. Kami akan membahasnya nanti di seri ini.

Di bagian 2 dari seri ini , kami mengeksplorasi menyatukan bagian-bagian ini untuk merancang, membangun, dan menskalakan startup perangkat lunak kencan online fiktif.

Terima kasih telah membaca sejauh ini, dan saya harap Anda menikmati bagian 2 .