Di bagian 1 dari seri ini , kami menjelajahi metodologi dan kerangka kerja yang menurut saya berguna dalam membangun dan mengembangkan perangkat lunak rintisan. Tujuan dari posting ini adalah untuk mengilustrasikan bagaimana Anda dapat menerapkan teknik-teknik ini untuk meminimalkan upaya yang sia-sia dan bagaimana perencanaan untuk bisnis perangkat lunak Anda diterjemahkan ke dalam infrastruktur cloud Anda.

Prasyarat untuk bergerak maju

• Anda telah membaca bagian 1 dari seri ini
• Anda sudah familiar dengan kerangka kerja / metodologi yang kami jelajahi di bawah ini dengan menonton tautan video yang dibagikan di bagian 1

Diagram di atas mengilustrasikan konsep kunci dari metodologi yang disebutkan di atas. Untuk posting ini, kita akan bersenang-senang menciptakan startup kencan online fiktif, dan "mengukurnya". Kami akan mengilustrasikan penerapan prinsip-prinsip ini dan hubungan dari strategi perusahaan, hingga kebutuhan produk dan pertumbuhan, dan bagaimana prinsip-prinsip tersebut menginformasikan desain infrastruktur cloud kami.

Identifikasi masalah yang sedang kita selesaikan, dan untuk siapa

Asumsikan Anda dan orang lain muak dengan kesepian, dan solusi yang ada tidak cukup. Anda pernah ke pesta pernikahan, sebenarnya terlalu banyak, dan Anda pernah ke bar, dan bahkan mencoba aplikasi populer tetapi masih merasa ada sesuatu yang hilang. Anda bersemangat dengan masalah ini dan percaya bahwa Anda adalah tim untuk membantu mengatasi kesepian orang lain, termasuk kesepian Anda sendiri. Pertama mari kita menganalisis strategi potensial dari solusi lain.

Penafian

Saya tidak pernah menggunakan aplikasi kencan online, jadi saya hanya "menebak" fitur dan fungsi apa yang disertakan. Menggunakan apa yang ada di televisi atau berita utama tentang berbagai aplikasi populer, kita dapat berpura-pura membangun pesaing. Jika asumsi saya jauh, atau jika kita tidak mengeksplorasi setiap jenis hubungan, saya meminta Anda untuk menangguhkan ketidakpercayaan demi mengilustrasikan konsep-konsep ini .

eHarmoni

Layanan ini memiliki teori bahwa dengan mencocokkan berdasarkan profil kepribadian ilmiah, orang akan merasa tidak terlalu terintimidasi. Strategi mereka adalah dengan menjadikan kepribadian sebagai faktor utama, mereka akan menarik orang-orang yang kurang percaya diri dengan penampilan mereka yang masih kesepian, memanfaatkan pasar yang belum terjamah.

Rabuk

Layanan ini memiliki teori bahwa banyak orang yang kesepian, tetapi tidak mencari hubungan jangka panjang. Strategi mereka adalah menjadi pengganti sambungan kasual, dan merebut porsi pasar ini.

Menggagap

Layanan ini memiliki teori bahwa wanita akan merasa lebih nyaman di platform jika mereka dapat memilih dengan siapa mereka terlibat. Strategi mereka adalah membiarkan wanita memutuskan apakah akan mengirim pesan pertama setelah pertandingan.

eTumble — BARU!

Asumsi kami adalah orang-orang kesepian, dan solusi di pasar belum menyelesaikan kesepian dalam skala global . Kami percaya solusi pemenang adalah kombinasi dari ketiganya di atas. Kami menduga jauh di lubuk hati, pencari hubungan biasa lebih suka memiliki kesempatan untuk hubungan pribadi yang lebih dalam melalui pencocokan kepribadian awal, tetapi perempuan membuat pilihan apakah akan berinteraksi.

Praktik Lean Startup menyarankan untuk beroperasi seperti "eksperimen besar", membuat asumsi yang berani , lalu mengamati (bukan bertanya) perilaku pengguna, sambil mengulang dengan cepat. Seringkali kita mengeluarkan ide menggunakan kanvas "Lean" , tetapi kita akan menganggap tim kita telah melakukannya di atas. Mari kita mulai!

Dimulai dengan visi dan strategi

analisis SWOT

Dengan mengakui kekuatan internal (kekuatan, kelemahan) dan eksternal (peluang, ancaman), Anda dapat memanfaatkan analisis SWOT untuk mengidentifikasi dengan lebih baik apa yang harus terjadi untuk berhasil.

Analisis ini menginformasikan desain produk Anda saat Anda menguji hipotesis tentang penyelesaian naik turun yang tak terhindarkan. Misalnya, jika churn pengguna yang tinggi merupakan ancaman, Anda dapat memprioritaskan fitur yang membuat orang kembali ke platform Anda. Mengingat kelemahannya adalah kurangnya pengalaman psikologi dalam tim, Anda tahu saat merekrut atau menarik penasihat, siapa yang menjadi sasaran. Jika tim memiliki pengalaman terbatas dengan aplikasi pesaing, maka Anda tahu tugasnya adalah menggunakannya, dan berkencan — menang, menang.

Tentukan rencana strategis awal menggunakan OGSM

Tahap awal, tujuan Anda adalah meluncurkan produk minimum yang layak (MVP) dengan cepat untuk mulai mengamati perilaku pengguna, dan menguji hipotesis secara iteratif. Di dunia perangkat lunak, kami sering bercanda bahwa prototipe selalu diproduksi, terlepas dari niat terbaik kami. Menginvestasikan beberapa hari untuk bertukar pikiran dengan tim Anda untuk mendokumentasikan strategi dan tindakan dapat mengurangi pengerjaan ulang dan mempercepat desain dan pengembangan produk Anda —mari jelajahi caranya di bawah ini.

Perhatikan pada contoh OGSM di atas, kami sudah mulai mengidentifikasi kebutuhan tim, produk, metrik, dan infrastruktur kami di masa mendatang. Kami membutuhkan keahlian dalam aplikasi seluler, pembelajaran mesin, dan pengembangan API. Kami juga memerlukan terjemahan bahasa, penyamaran teks dan gambar, dan menerima pembayaran online. Untuk pemirsa global, kami harus memenuhi persyaratan peraturan dan privasi, terutama di Uni Eropa.

UX ramping

Lean UX lebih dikenal di antara tim produk, di mana penulis Jeff Gothelf memiliki permulaan yang sederhana. Keefektifan mengkomunikasikan ide apa pun melalui pernyataan hipotesis saya percaya menjamin kesadaran di seluruh organisasi dan bukan hanya tim produk. Saya pikir Lean UX cocok dengan strategi dan visi dan digunakan di mana-mana.

Setiap strategi, dan selanjutnya taktik (fitur), dalam rencana OGSM di atas pada dasarnya adalah sebuah hipotesis. Semakin banyak kita mengutarakan ide-ide kita dalam struktur ini, semakin dapat ditindaklanjuti dan fokusnya. Misalnya, strategi bahwa kita akan mencapai tujuan kita dengan “menyediakan tempat yang lebih aman untuk berinteraksi” dapat diungkapkan sebagai:

“Kami percaya bahwa [jutaan pengguna] akan bergabung dengan layanan kami jika [wanita] [merasa lebih aman untuk berinteraksi] dengan [hanya mereka yang memilih untuk memulai percakapan setelah pertandingan].”

Ini diterjemahkan secara longgar menjadi "Kami percaya bahwa [hasil bisnis] akan tercapai jika [pengguna] mendapatkan [manfaat] dengan [fitur]." seperti yang dijelaskan dalam kanvas Lean UX. Saya terkadang menukar format ini dengan yang lain yang didefinisikan dalam prinsip tangkas "Penemuan Produk", tetapi premisnya sama — komunikasi terstruktur .

Anda dapat melihat sifat iteratif dari metodologi ini saat Anda menggabungkannya. Jika Anda belum melakukannya, saya mendorong Anda untuk meninjau video tentang Lean UX di bagian 1 dari seri ini .

Desain produk

Berkaitan kembali dengan prinsip "Lean", begitu Anda memiliki asumsi atau hipotesis yang berani tentang masalah yang Anda selesaikan, untuk siapa Anda memecahkannya, dan bagaimana Anda berniat menyelesaikannya, Anda harus dengan cepat mengulang dan mengujinya.

Daripada bertanya kepada pengguna, yang terbaik adalah selalu mengamati perilaku mereka untuk memvalidasi asumsi Anda, oleh karena itu disarankan untuk meluncurkan MVP. Dalam produk langsung, Anda juga dapat memanfaatkan alat uji A/B atau flag/toggle fitur.

Kami tidak memerlukan semua fitur yang dihindari di OGSM kami segera untuk menguji teori kami, tetapi sekarang memiliki pemahaman holistik tentang tujuan kami. Selanjutnya, kami memprioritaskan apa yang harus ditawarkan oleh MVP kami untuk memaksimalkan nilai pengguna saat kami melakukan iterasi dengan cepat setelahnya. Untuk ini, kami akan memanfaatkan Pemetaan Cerita Pengguna .

Pemetaan cerita pengguna

Apa yang Anda lihat di atas sudah versi enam! Dimulai dengan tampilan holistik, saya dengan cepat memetakan perjalanan pengguna secara keseluruhan. Saya kemudian mengacak-acak kotak dan memprioritaskan ulang cerita pengguna untuk mengidentifikasi jumlah terkecil yang dapat kami berikan untuk menguji hasil yang diinginkan untuk audiens target.

Saat Anda menguji hipotesis di sepanjang jalan, Anda menerapkan penemuan Anda dan terus mengedit "dokumen hidup" ini dengan gesit, daripada membuang waktu untuk spesifikasi detail yang stagnan.

Arsitektur Model C4

Kami sekarang memiliki informasi untuk membantu kami menentukan perangkat lunak dan arsitektur sistem kami, namun melakukannya dengan cara standar sering kali diabaikan. Pastikan Anda memiliki rencana (atau cetak biru) tentang apa yang Anda bangun untuk berkomunikasi secara efisien dengan pemangku kepentingan lainnya. Sementara UML tetap menjadi standar lama, Model C4 yang lebih ringan adalah yang saya rekomendasikan hari ini.

Untuk mempersingkat artikel ini, kami akan mengilustrasikan sebagian contoh arsitektur kami untuk eTumble. Meskipun ada 4 level untuk C 4 , praktik standar hanya menggambarkan sedalam yang diperlukan; level "Kode" yang secara efektif akan menjadi notasi UML biasanya dilewati.

Seperti disebutkan dalam penafian saya di atas, ini adalah aplikasi fiktif dan saya tidak pernah menggunakan layanan kencan online jadi ini adalah tebakan untuk menggambarkan prosesnya.

Seringkali saya akan mulai membuat sketsa ide di atas kertas untuk memikirkan desainnya. Begitu ada ide umum tentang apa yang dibutuhkan, saya membuat daftar elemen arsitektur untuk menghilangkan detailnya. Misalnya, kami tahu kami membutuhkan database, tetapi strategi kami menyiratkan permainan global. Kami perlu memutuskan apakah kami dapat memulai dengan Postgres, atau MySQL untuk diluncurkan, dan seberapa sulit nantinya untuk bermigrasi ke sistem terdistribusi seperti Cockroach DB, atau Cloud Spanner GCP.

Mengalami "blok penulis" kadang-kadang sambil menatap kotak dan garis di layar, saya menemukan menggunakan spreadsheet seperti di bawah membuatnya mudah untuk memindahkan barang atau menyisipkan baris saat saya memikirkan lebih banyak hal, sebelum membuat diagram.

Di beberapa aplikasi Anda cukup menyalin/menempel seperti di dalam IcePanel , ditunjukkan di bawah ini. Ada dukungan untuk Markdown, yang bahkan lebih cepat setelah Anda terbiasa.

Mudah-mudahan ini menunjukkan seberapa cepat Anda dapat mentransfer apa yang Anda tulis ke alat pembuatan diagram — membutuhkan waktu kurang dari satu jam untuk menghasilkan diagram yang indah. Bayangkan terlibat dengan desainer dan insinyur dengan desain di atas, dan seberapa cepat (dan lebih murah) mereka nantinya.

Menaikkan skala

Petunjuk sebelumnya bahwa kami akan "menskalakannya" berarti kami mengantisipasi kebutuhan masa depan kami berdasarkan rencana strategis kami, dan gambaran besar kami yang diilustrasikan dalam peta cerita. Saya menyebutkan Kubus Skala AKF sebelumnya, dan dengan menerapkan prinsip sumbu xyz-nya, menyimpulkan bahwa skala global kami dan puluhan juta pengguna akan memerlukan desain stateless, sistem berbasis peristiwa, arsitektur layanan mikro, dan akhirnya beberapa tim, dengan rentang hosting beberapa wilayah geografis pada platform cloud publik.

• Sumbu x kami ( duplikat dan penskalaan ) diakomodasi oleh aplikasi stateless, terkontainerisasi, dan hosting cloud publik.
• Sumbu y kami ( spesialisasi ) diakomodasi oleh layanan mikro yang dibuat khusus, dipicu oleh HTTP/RPC, atau oleh pesan Pub/Sub. Ini juga membantu menentukan bagaimana Anda kemungkinan besar akan mengembangkan tim Anda, memungkinkan otonomi dan hubungan longgar untuk memiliki bagian penting dari nilai dalam sistem; ini sering sejalan dengan UX dasar yang diilustrasikan di peta cerita.
• Sumbu z kami ( membagi hal yang serupa ) diakomodasi oleh regionalisasi. Kami tidak membahas ini sepenuhnya dalam contoh fiktif kami. Mari kita asumsikan dengan strategi global bahwa kendala yurisdiksi pada sistem dan kedaulatan data, mata uang asing, bahasa, dan strategi saluran penjualan masuk ke pasar (GTM) di masa mendatang semuanya dapat memengaruhi cara kita memperluas sumbu ini. Itu bahkan bisa didasarkan pada di mana kita menemukan/membeli bakat untuk tim kita, atau bahkan seperti yang dijelaskan oleh "Topologi Tim", beban kognitif tim.

Apa yang telah kami pelajari dan bangun sejauh ini:

Waktu yang dihabiskan sejauh ini untuk merancang eTumble, startup kencan online fiktif kami:

• Lean [Memulai | UX] — kami tidak mengilustrasikannya, tetapi biasanya ini adalah titik di mana Anda mulai menulis masalah apa yang Anda pecahkan, untuk siapa Anda memecahkannya, dan manfaat/nilai yang Anda tawarkan. Anda dapat memvalidasi ide Anda dengan "MVP layar asap" dan halaman arahan, misalnya. Tonton video di bagian 1 untuk mempelajari lebih lanjut.
• Analisis SWOT — kami mengidentifikasi hal-hal positif yang ingin kami manfaatkan, dan hal-hal negatif yang perlu kami selesaikan, menginformasikan rencana OGSM kami. (30 mnt; perkirakan beberapa jam)
• Rencana OGSM — kami mengidentifikasi fitur utama, teknologi, metrik, dan tim yang kami perlukan untuk mengimplementasikan strategi kami, menginformasikan peta cerita kami. (1 jam; perkirakan 1–2 hari)
• Peta cerita — kami mengatur dan memprioritaskan cerita pengguna, mengidentifikasi kandidat MVP kami, menginformasikanarsitektur holistik kami seperti yang diilustrasikan di atas. (3 jam; perkirakan 1–2 hari)
• Arsitektur model C4 — kami mengidentifikasi sistem, basis data, dan komponen yang diperlukan, menginformasikan infrastruktur kami yang diperlukan. (3 jam; perkirakan 2–5 hari)

Didorong oleh “dokumen hidup” ini, tim dan pemangku kepentingan kami sekarang memiliki pemahaman yang sama tentang mengapa kami melakukan apa yang kami lakukan, bagaimana kami berencana untuk menang (atau setidaknya teori untuk diuji), dan apa yang akan kami bangun untuk memecahkan masalah gambaran besar.

Menginvestasikan waktu ini untuk berkolaborasi dan menuliskan berbagai hal juga menyederhanakan proses perancangan infrastruktur cloud, repositori kode sumber, dan pemantauan/metrik yang nantinya akan kami perlukan untuk mendukung eTumble. Kami akan menjelajahi ini dan lebih banyak lagi di bagian 3 dari seri ini .

Terima kasih telah membaca sejauh ini, dan saya harap Anda menikmati penyelaman mendalam yang lebih teknis di bagian 3 .