10 langkah untuk membuat MVP dalam 6 minggu.

Perjalanan Startup.

Startup adalah hal yang sangat sulit untuk dilakukan. Pada dasarnya, karena Anda harus melakukan banyak hal berbeda secara bersamaan: kasus bisnis, pemasaran, promosi, riset pasar, desain, riset pesaing, makalah hukum, banyak komunikasi dan percakapan, mencari bakat ... Misi jauh lebih mudah jika Anda memiliki tim yang luar biasa, yang dapat mengatur dan mendistribusikan tugas sebagai tim yang berkinerja tinggi. Tetapi bahkan untuk tim yang penuh semangat & rekan yang terkoordinasi dengan sempurna, itu adalah hal yang sangat sulit untuk dilakukan (saya akan mengatakan hampir mustahil untuk melakukannya dengan benar!).

Perjalanan menjadi lebih sulit jika Anda sangat ketat dengan uang dan sumber daya. Semuanya harus dilakukan dengan cepat dan harus dilakukan dengan satu tembakan, tidak ada peluang untuk kesalahan. Kedengarannya seperti petualangan yang fantastis, bukan? Itu sebabnya sangat dihargai ketika semangat dan ketekunan mendapatkan hasilnya.

MVP

MVP adalah Produk Berharga Minimum, beberapa menyebutnya Produk Layak Minimum dan secara emosional cerdas di antara kita menyebutnya MLP, Produk Minimum Cinta, untuk cerita ini saya akan dengan Produk Berharga Minimum. Saya suka menggebrak pasar dengan produk yang menciptakan nilai berdasarkan kebutuhan nyata orang - tempat yang baik untuk membangun dan kemahiran

Saat ini orang menaruh arti berbeda pada MVP dari apa yang awalnya didefinisikan oleh Frank Robinson pada tahun 2001 http://www.syncdev.com/minimum-viable-product/.

Beberapa orang bahkan percaya, MVP bukan fokus sebenarnya lagi, mungkin tidak relevan:

  • https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02
  • https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-membuat-produk-minimal-loveable-51800164ae0c
  • https://blog.leanstack.com/dont-start-with-an-mvp-aa883de5cd18

Tapi katakan saja, MVP ini adalah produk awal, yang menciptakan nilai nyata bagi pelanggan Anda. Ini bisa berupa situs web, whitepaper, atau platform perangkat lunak besar. Ini adalah eksperimen yang dipikirkan dengan baik yang harus menjadi langkah maju yang kuat ke pasar yang ingin Anda masuki.

6 minggu MVP Story kami!

Di Madappgang, suatu hari kami bertemu dengan kasus nyata dari sebuah misi startup yang sangat menantang. Wirausahawan Mr.Donnavan, pendiri proyek Creator Connect, menginginkan kami membuat MVP dalam 6 minggu. Tujuan dari proyek ini, untuk memberikan setiap bakat artistik platform untuk membuat, menghubungkan, dan berkolaborasi dengan menekan sebuah tombol. Berikut adalah persyaratan utama:

  • Seharusnya aplikasi iOS asli, untuk tumbuh dan skala cepat dan mudah setelah rilis MVP desain terdiri dari 163 layar
  • Harus menyediakan komunikasi pesan waktu-nyata
  • Seharusnya memiliki alat moderasi untuk mengontrol dan memblokir konten dan pengguna yang buruk
  • Seharusnya memiliki aliran pembayaran terintegrasi
  • Harus dapat membuat data grafik terkait dengan menyebutkan dan tagar
  • Itu harus dilakukan dan dirilis dalam 6 minggu

Pelajaran yang dipetik

Tugas ini terlihat seperti pekerjaan 6 bulan, bukan 6 minggu. Tetapi jika Anda melihat titik pertama di yayasan kami, Anda akan mengerti, mengapa itu tidak menghentikan kami. Kami sangat percaya, bahwa tidak ada kasus yang mustahil!

Sesuai dengan keyakinan kami, kami berhasil. Itu terutama sulit, berisiko dan menantang. Dan inilah pelajaran yang kami pelajari.

Berkomunikasi banyak

Sekilas sepertinya saran yang buruk, tapi ternyata tidak. Miskomunikasi adalah alasan utama kegagalan proyek. Komunikasi yang tepat dalam tim adalah nomor satu dan perlu cepat dan efisien. Jadi apa artinya memiliki komunikasi yang baik? Pertama, CEO / pendiri harus menjadi bagian dari tim. Kami menggunakan metodologi scrum untuk bergerak cepat dan mengoordinasikan pekerjaan kami, jadi kami perlu meluangkan waktu untuk memastikan bahwa CEO / pendiri memahami cara kerja Scrum. Orang mungkin berpikir itu terlihat mudah: hanya memindahkan tugas di baris dari kiri ke kanan, tetapi masalahnya adalah itu tidak mudah. ​​Scrum adalah rapat harian, perencanaan sprint, estimasi tugas, rapat retrospektif, prioritas backlog, dan yang terpenting itu cepat percakapan untuk mendorong kecepatan. Pendiri harus berada di halaman yang sama dengan semua orang di tim dan menjadi Pemilik Produk nyata. Pemilik Produk memiliki peran penting dalam proses Scrum dan untuk memainkan peran tersebut, CEO harus memahami aturan dan makna setiap ritual. Untungnya, kami memiliki buku yang luar biasa untuk membantu kami menavigasi, panduan yang cepat dan mudah dipahami kepada orang-orang non-teknis yang ada di tim. Scrum: Seni Melakukan Dua Kali Berfungsi di Setengah Waktu

Gunakan teknologi untuk kecepatan

Ada puluhan teknologi di pasar untuk membantu mempercepat proses. Hanya perlu diingat, beberapa solusi mungkin sulit untuk diukur setelah MVP, dan beberapa tidak cocok satu sama lain. Pikirkan baik-baik, hanya jangan ulangi diri Anda demi yang sudah dikenalnya dan juga jangan mencoba menemukan kembali roda. Jadilah nyata, pahami kebutuhan proyek Anda dan dengarkan pengalaman tim. Teknologi utama membantu kami dalam proyek ini:

  • AWS AppSync, GraphQL
  • S3 dengan CloudFront
  • AWS lambdas (Golang dan Nodejs)
  • Identifo oleh MadAppGang
  • Invisi

Prioritaskan backlog

Habiskan waktu bersama tim dan buat backlog. Backlog adalah jalur Anda dan satu-satunya cara untuk mengukur kecepatan Anda. Setelah 1-2 sprint Anda akan menemukan langkah Anda, memahami kecepatan Anda dan akan dapat memprediksi tonggak rilis. Dalam kasus kami, setelah sprint pertama, kami menyadari bahwa kami membutuhkan 2 pengembang lagi untuk merilis MVP pada waktunya.

Pengorbanan

Sebagai pemilik produk, kemungkinan besar Anda akan percaya bahwa setiap fitur itu penting, lebih banyak lebih banyak - tetapi kita semua tahu bahwa aplikasi paling sukses hanya melakukan 1 atau 2 hal dengan sangat baik, semakin sedikit semakin banyak. Bersiaplah untuk menghapus fitur yang tidak penting untuk rilis MVP. Jujur saja dengan diri Anda sendiri, jujur ​​tentang kebutuhan nyata pelanggan dan dengarkan tim. MVP Anda seharusnya tidak sempurna. Semakin cepat Anda mendapatkan umpan balik dari pengguna Anda semakin baik peluang Anda untuk melakukan sesuatu yang sangat berharga bagi pengguna Anda. Rencana awal Anda hanyalah prediksi Anda tentang apa yang mereka butuhkan, kenyataannya selalu berbeda. Kami menghapus daftar besar fitur untuk memungkinkan MVP dalam 6 bulan:

  • Tidak ada pembayaran dan aliran pembayaran
  • Tidak ada kemampuan untuk mengikuti pengguna
  • Sederhanakan umpan berita
  • Tidak ada pemberitahuan
  • Orientasi yang disederhanakan
  • Tidak ada gambar dalam percakapan waktu nyata
  • Tanpa berbagi
  • Tidak ada pemrosesan kesalahan (pengguna melihat kesalahan ramah pengembang :-))
  • Proses pengunggahan gambar yang sangat sederhana

Jangan berhemat saat pengujian

Kami memiliki insinyur QA pada proyek sejak hari ke-0. Dia menerapkan tes otomatis UI, integrasi berkelanjutan dan melakukan tes manual pada setiap rilis internal. Sayangnya, sebagian besar orang sering melewatkan proses pengujian untuk MVP. Sebagian besar karena mereka berpikir, pengujian hanya tentang memiliki aplikasi akhir bebas bug. Kenyataannya agak berbeda. Tayangan pertama dihitung. Merujuk buku Scrum, ada cerita luar biasa tentang itu.

Di Jepang, perusahaan seperti Honda, Toyota dan Nissan memproduksi mobil mewah rata-rata setiap 17 jam. Sedangkan Produsen mobil di Jerman, seperti Audi, BMW dan Mercedes membutuhkan waktu 57 jam untuk membuat mobil mewah. Mobil-mobil yang diproduksi oleh pabrikan Jepang memiliki rata-rata hanya 34 cacat di setiap 100 kendaraan sedangkan pabrikan Jerman membuat mobil dengan rata-rata 78,7 cacat per setiap 100 kendaraan. Perbedaannya adalah bahwa ketika seseorang di jalur produksi Toyota menemukan cacat, dia akan menghentikan seluruh jalur produksi dan semua orang akan memperbaiki cacat itu bersama di sana dan kemudian. Metode ini juga memberikan umpan balik langsung ke tempat di mana cacat itu dibuat, dan suatu proses dapat dilakukan sehingga tidak terjadi lagi. Sedangkan di BMW, cacat diperbaiki di mobil setelah mereka keluar dari jalur produksi pada akhirnya. Untuk mendukung hal ini, Jeff juga mereferensikan penelitian yang dilakukan oleh Palm yang menunjukkan bahwa jika bug dalam perangkat lunak diperbaiki setelah enam minggu sejak ditemukan, diperlukan 24 kali lebih lama untuk memperbaikinya daripada jika diperbaiki saat ditemukan .

Anda harus menyusun tim penuh

Bekerja dalam jangka waktu terbatas mengharuskan Anda seefisien mungkin. Memiliki ketergantungan eksternal menghabiskan banyak waktu. Misalnya, jika Anda sudah memiliki desain premade, dan tim sudah mulai mengimplementasikannya. Dan kemudian Anda menyadari bahwa Anda kehilangan layar, atau Anda perlu membuat versi layar yang disederhanakan baru karena Anda telah melucuti beberapa fungsi. Anda berpotensi diblokir saat Anda mencari desainer Anda, yang sekarang bisa offline berlibur di pegunungan. Jadi ingat untuk menjaga semua rekan tim, setidaknya saat menerapkan MVP!

Bersiaplah untuk rencana B

Manusia bukan mesin. Jangan menaruh semua telur Anda dalam satu keranjang. Pengembang adalah orang-orang (kadang-kadang sulit untuk percaya :-)). Mereka dapat memiliki perubahan dalam keadaan pribadi, mereka bisa menjadi sakit, dll. Jadi siap untuk terhubung ke pengembang lain sebagai rencana cadangan. Di MadAppGang, kami sengaja melibatkan pengembang pengganti untuk melakukan tinjauan kode dan peer sepanjang waktu. Ini memecahkan dua masalah. Tinjauan eksternal membantu kami meningkatkan kode dan proyek. Lebih jauh, jika pengembang utama tidak dapat bekerja karena suatu alasan, pengembang pengganti tidak memerlukan waktu onboarding. Dia atau dia bisa melompat dan mulai menulis kode segera.

Percaya pada dirimu sendiri

Bekerja di lingkungan yang penuh tekanan dapat membahayakan kesehatan mental Anda. Kenali diri Anda, pahami batasan Anda, kebutuhan Anda, dan pahami kepemimpinan. ingat jika Anda berhenti percaya pada apa yang Anda lakukan, jangan berharap anggota tim lainnya tetap termotivasi. Mendukung dan membantu semua orang, menjadi contoh yang baik untuk semua orang, menjadi pemimpin. Anda mungkin telah membaca atau setidaknya mendengar buku ikonik ini, mungkin terlihat kitsch tetapi beberapa konsep sederhana bekerja sangat baik untuk saya. Temukan sumber inspirasi Anda sendiri dan pertahankan setiap hari. Berolah raga, mandi air dingin, makan dengan baik, bermeditasi, mencoba ritual syukur - itu luar biasa untuk tetap kuat di bawah tekanan dan tetap positif. Kepemimpinan itu menantang, tetapi ini adalah kesempatan besar bagi Anda untuk menjadi diri Anda yang lebih baik! Bagaimana Cara Menang Teman dan Mempengaruhi Orang

Bekerja keras

Kedengarannya jelas. Tetapi ada sejumlah besar kasus ketika tim (atau bagian dari tim), menjaga ritme yang sama, untuk mengarsipkan hasil yang luar biasa. Setiap orang dalam tim harus memahami, untuk mencapai hasil yang luar biasa di bawah tekanan waktu yang sedemikian besar sehingga seluruh tim harus setuju untuk bekerja keras sejak awal. Saya sangat menghargai tim MadAppGang kami yang secara sukarela mengorbankan akhir pekan dan waktu luang mereka, mengubah jadwal mereka dan mendorong semua upaya untuk memberikan MVP tepat waktu. Sangat penting untuk memberikan keseimbangan alami, tim Anda harus merasa nyaman bahwa mereka dapat memiliki waktu henti setelah bekerja sama dan berusaha keras.

Temukan pengembang yang baik

Semuanya, yang kita bicarakan di sini, benar-benar hanya mungkin terjadi dengan tim yang luar biasa, tim yang berbagi ide Anda memiliki proses kerja yang baik dan memiliki semangat tim yang nyata dan semangat untuk pekerjaan mereka. Pada akhirnya jika Anda menciptakan lingkungan kerja positif yang baik untuk tim Anda, Anda mempercayai orang, memberikan fleksibilitas, memungkinkan manusia menjadi manusia, maka orang-orang baik akan datang, menciptakan bersama, membangun bersama, dan tetap bersama. Ceritakan tentang perjalanan startup Anda dan pembelajaran Anda, apa rahasia Anda untuk membangun tim yang hebat ?! Silakan merujuk ke blog kami untuk mempelajari lebih lanjut tentang memilih tim pengembangan yang baik.

Baca lebih banyak kisah keren di blog kami: https://madappgang.com/blog