Selamat liburan, teman-teman! Dalam persiapan untuk awal tahun kerja baru, kami sedang menyelesaikan serangkaian materi dari konferensi FrontTalks 2018. Ini adalah kuliah oleh Andrei Salomatin
filipovskii_off - seorang pengembang dari Polychops. Andrei menawarkan pendekatan yang seimbang untuk membuat prototipe: untuk beralih dari pengrajin yang melakukan pesanan menjadi peneliti - belajar bagaimana bekerja dengan ketidakpastian dan, mungkin, mempertahankan alasan bahkan tanpa rencana yang jelas.
Umpan balik kuantitatif adalah pengujian AV, hasil biner, ketika Opsi A atau Opsi B. menang. Hanya itu yang bisa kita dapatkan dari siklus kuantitatif. Seolah-olah kita berada di ruangan gelap dan tidak ada yang terlihat, tetapi kita memiliki laser pointer. Dari waktu ke waktu, kami menyorotinya di sudut-sudut, menyorot beberapa titik dan memahami apa yang ada di dalamnya.
Apa yang kita inginkan? Seorang pengguna yang akan menggambarkan ruangan gelap ini, yang tahu itu jauh lebih baik daripada diri kita sendiri.
- Halo semuanya! Saya ingin berbicara tentang pembuatan prototipe: mengapa membuat prototipe, apa yang kita dapatkan dari ini dan bagaimana membuatnya, menggunakan contoh.
Saya akan mulai dengan sedikit cerita. Pada 2012, saya bergabung dengan startup ini, rusa yang luar biasa. Kami memiliki sesuatu seperti platform periklanan, saya datang sebagai pengembang Java. Jelas bahwa volume lalu lintas yang besar, tugas-tugas yang menarik, tim hanya gila - semuanya indah. Kami telah bekerja selama sekitar delapan bulan, dengan menggunakan keyboard, kami membuat fitur yang sangat keren, kami dengan cepat membalikkan semuanya. Namun pada tahun 2013, rusa naik kuku.
Apa yang terjadi Saya memikirkan hal ini untuk waktu yang sangat lama, kemudian mulai bekerja sebagai pengembang frontend dan backend untuk perusahaan yang berbeda, kemudian saya adalah pemimpin tim, kemudian manajer produk. Dia bekerja di perusahaan rintisan dan perusahaan outsourcing, di perusahaan besar. Terutama berfokus pada startup.
Saya juga melakukan beberapa proyek ini. Saya cukup beruntung bekerja di MoscowJS, Frontend Union Conf dan RadioJS. Mungkin kita menyeberang denganmu di suatu tempat. Sekarang saya sedang membuat Code Podcast, podcast dalam bahasa Inggris tentang konsep umum dalam pemrograman, dan Polychops, sebuah proyek untuk musisi yang bekerja di browser dan membantu Anda berlatih instrumen, mendapatkan lebih banyak waktu dan latihan.
Apa yang terjadi dengan HeyMoose? Perusahaan ini memiliki orang-orang yang sangat pintar yang sekarang bekerja sebagai pengembang senior di Microsoft atau telah menjadi STO. Kami melakukan apa yang kami lakukan yang terbaik: kami memecahkan masalah teknis yang rumit dengan cepat dan menarik. Tapi ada yang salah.
Dan ada yang salah dengan banyak perusahaan, terutama startup. Startup kebanyakan kehabisan karena dua alasan: entah mereka tidak mengerti produk, di suatu tempat mereka kehilangan produk, atau mereka kehabisan uang. Sangat sering mereka kehabisan uang karena mereka mencari produk dan tidak dapat menemukannya cukup lama.
Tetapi mengapa pengembangan kustom di perusahaan outsourcing tidak ditutup? Atau mengapa perusahaan besar tidak tutup? Mereka tampaknya lebih lambat. Sebagai aturan, tim setidaknya memiliki motivasi yang kurang. Apa bedanya? Mekanisme kerjanya sama: dalam pengembangan kebiasaan kami menulis TK atau meminta TK dari pelanggan, mereka melukisnya untuk kami, memberikannya kepada kami, kami membuat mock-up, kode, dan kami menulisnya - proses yang sama. Apa yang ada di startup, bahwa di perusahaan besar, mungkin ada praktik tepi. Semua sama saja. Jadi mengapa startup tidak berhasil?
Pertama-tama mari kita bayangkan situasi hipotetis: seorang manajer produk mendatangi kami dan menanyakan apakah kami dapat menambahkan metronom yang akan berfungsi di peramban, membuat suara dengan interval berkala dan visualisasi yang disinkronkan, sehingga lampu yang berbeda berkilau dengan metronom satu ke satu. Dan agar semua ini akurat, terlepas dari apa yang terjadi di komputer, proses lain, dll.
Siapa yang 100% yakin bahwa kita bisa melakukan ini menggunakan browser dan API browser? Bukan satu orang. Siapa yang 80% yakin bahwa kami mungkin bisa melakukan ini? 3-4 tangan. Siapa yang yakin 50 hingga 50? Mayoritas. Siapa yang yakin kita tidak bisa melakukan ini sama sekali? Jujur.
Contoh berikut. Misalkan kita sedang bekerja di perusahaan lain di bank seluler. Kami lebih memikirkan produk dan berpikir perlu meningkatkan jumlah pengguna yang menggunakan bank seluler kami. Kami datang dengan fitur: sekarang pengguna dapat berbagi pembelian atau mengisi akun di jejaring sosial. Uang datang kepadanya, dia seperti itu di Facebook - lihat, uang telah datang kepada saya. Apakah Anda pikir ini akan membantu menarik lebih banyak pengguna? Siapa yang 100% yakin akan hal ini? Bukan satu pun. Siapa yang 100% yakin bahwa ini tidak akan membantu kami dengan cara apa pun? Dua atau tiga tangan. Sisanya ada di antara keduanya.
Dan contoh terakhir. Kami membuat layanan cloud, buka perusahaan kami. Layanan cloud akan mengumpulkan log dari proyek, dari frontend dan backend di bisnis kecil dan menengah, mengumpulkannya, mempelajari mesin, AI dan semua itu. Kami akan menjualnya. Siapa yang yakin bahwa ini 100% berhasil atau 100% kerugian? Beberapa orang.
Hanya ada satu jawaban yang benar untuk ketiga pertanyaan ini: "mungkin." Kami 50–80% yakin akan jawaban atas beberapa pertanyaan. Banyak tergantung pada konteksnya, pada implementasinya. Metronom yang sama dengan visualisasi - Saya telah mengerjakannya, Anda tidak dapat membuatnya berfungsi dalam semua konteks: misalnya, dengan headphone Bluetooth. Tapi itu bisa dilakukan untuk dua atau tiga kasus umum. Dalam pemahaman saya, ini "mungkin" - dan ada alasan mengapa startup tutup, dan HeyMoose naik peringkat. Mungkin kita akan melakukan sesuatu yang baik, atau mungkin kita hanya membuang-buang waktu. Dan kita tidak memiliki cara untuk memahami seberapa percaya diri kita dalam apa yang kita lakukan.
Sedikit teori. Apa perbedaan antara pengembangan kustom dan startup? Perbedaannya adalah dalam konteks. Kita berada dalam konteks ketidakpastian ini, kita memiliki probabilitas keberhasilan dan probabilitas kegagalan. Seolah-olah kita mencoba menggunakan metode dan praktik yang sama ketika kita berlari di tanah dan ketika kita berlari di ruang tanpa gravitasi. Tampaknya kita sedang berlari, tetapi tidak ada yang terjadi. Apa yang kita lakukan salah?
Ketidakpastian ini berasal dari tiga bidang utama. Itu berasal dari pasar - karena kita tidak tahu dengan jelas apa perusahaan lain yang terlibat dalam agregasi log. Mungkin pasar ini sudah ditangkap oleh seseorang? Apa demografi di pasar, berapa harganya? Ketidakpastian dapat berasal dari suatu produk. Kami tidak tahu masalah apa yang dimiliki klien kami dan bagaimana menyelesaikannya. Ini adalah contoh dari bank seluler. Kami tampaknya memiliki pemahaman, tetapi kami tidak yakin apakah pengguna memiliki masalah ini dan bagaimana menyelesaikannya.
Dan ada masalah implementasi. Contoh dengan metronom. Kami tidak tahu 100% apakah ini secara teori mungkin atau tidak.
Atau contoh lain. Kami tidak memiliki masalah dengan pasar atau produk, jika kami menemukan obat untuk kanker, yang hanya pil yang diterima dan sehat. Tetapi ada sejumlah besar ketidakpastian dalam bagaimana menerapkan pil ini. Kita berada dalam kabut perang, tetapi pada saat yang sama kita berperilaku seolah-olah kabut itu tidak ada, karena kita memiliki prinsip yang sama yang bekerja dalam pengembangan adat. Kami hanya memindahkan mereka ke dalam konteks ketidakpastian kami.
Kami agak berpura-pura bahwa kabut ini tidak ada, tidak ada ketidakpastian. Dan kami berusaha untuk memprediksi masa depan. Ketika saya mulai bekerja sebagai manajer produk, saya terkejut setelah proses pengembangan oleh berapa banyak ramalan yang harus dihasilkan oleh manajer produk. Ketika Anda melapor kepada direktur atau kepada orang lain, Anda harus terlihat percaya diri, harus mengatakan bahwa kami akan melakukan ini atau itu, merebut pasar pada bulan September, semuanya akan terasa sakit. Semua ini - dilakukan dengan baik, saya memikirkan semuanya. Walaupun pada kenyataannya saya mengerti bahwa semua ini tidak ada, saya hanya menebak-nebak pada kartu dan berusaha terlihat percaya diri dengannya. Kami tidak memiliki budaya kerja dengan ketidakpastian, dengan probabilitas. Selain itu, agar terlihat seperti para ahli, kita perlu terus-menerus memperjuangkan reputasi, percaya diri, berbicara tentang apa yang harus kita lakukan, daripada apa yang perlu kita periksa, atau apa yang tidak kita yakini.
Kami, terutama pengembang, masih memiliki kecenderungan untuk berpikir tentang apa yang kami ketahui, pahami, dan dapat kontrol. Sebagai pengembang, kami sangat suka merencanakan arsitektur, memikirkan masa depan, jangan ulangi diri Anda, pemrograman pola, dan semua itu.
Desainer juga menderita karenanya. Mereka suka berpikir tentang masa depan, membuat tata letak yang sempurna, dll. Kami adalah ahli, meskipun dalam kenyataannya kita mungkin perlu menjadi orang lain.
Bagaimana kita menghadapi ketidakpastian? Metode perjuangan apa yang kita miliki? Metode pertama adalah yang paling penting - untuk meletakkan semua kartu di atas meja, untuk mengakui bahwa kami tidak yakin tentang masalah apa pun. Kami mungkin 50% yakin, tetapi untuk menguji hipotesis, kami membutuhkan dua hari. Lalu mengapa kita tidak pergi saja dan menguji hipotesisnya? Kami mungkin 90% yakin bahwa produk akan lepas landas, tetapi kami membutuhkan delapan bulan untuk menerapkan produk ini dan menguji hipotesis. Akankah kita pergi dan memeriksa? Atau mungkin kita akan berpikir tentang bagaimana mengurangi ketidakpastian hingga 90 atau 100%?
Ini cara pertama. Penting untuk menggantung lencana pada ketidakpastian ini, untuk mengatakan seberapa besar atau kecilnya itu, berapa banyak pekerjaan yang diperlukan untuk menyelesaikannya, dll.
Cara kedua yang telah dikerjakan manusia selama 500 tahun terakhir adalah metode ilmiah. Ini tidak sempurna, ia memiliki bug sendiri, tetapi ini adalah mekanisme terbaik yang kami miliki saat ini. Metode ilmiah mengatakan: untuk menyelesaikan ketidakpastian, pertama-tama kita tebak, menghasilkan hipotesis berdasarkan kesimpulan kami, kemudian pikirkan eksperimen yang akan mengkonfirmasi atau membantah hipotesis ini, kemudian jalankan percobaan, lihat angka-angkanya dan pahami apakah hipotesis kami benar.
Dalam pengembangan, terutama di front-end, kami memiliki peluang unik untuk menjalankan eksperimen ini dengan kecepatan yang sangat tinggi. Metode ini disebut prototyping. Prototipe adalah cara untuk menghadapi ketidakpastian. Ini bukan penemuan produk, bukan penciptaan sesuatu yang ideal yang akan digunakan pengguna. Ini adalah kesempatan untuk belajar lebih banyak tentang dunia di sekitar kita. Kami belajar ini dengan menciptakan ilusi. Prototipe adalah ilusi, bukan produk. Seolah-olah kita sedang membangun pemandangan di panggung teater atau di atas panggung untuk membuat film. Ini hanya ilusi. Tujuannya adalah untuk mengurangi ketidakpastian.
Prototyping berfungsi dalam dua konteks: dalam konteks implementasi, ketika kita tidak tahu secara teoritis dari sudut pandang API, itu mungkin atau tidak, dan dalam konteks produk ketika kita tidak tahu masalah apa yang dimiliki pengguna dan bagaimana menyelesaikannya. Prototipe tidak benar-benar berfungsi dalam riset pasar - Excel ada untuk ini.
Intinya adalah bahwa ketika kita mengerjakan prototipe, kita perlu meninggalkan cara berpikir sebagai ahli. Kita perlu melupakan pola pemrograman ini, kita perlu melupakan bagaimana kita membuat produk yang ideal - karena kita tidak. Kami mencoba untuk meningkatkan penelitian, kami menjadi ilmuwan.
Jadi, alih-alih memikirkan arsitektur, kita perlu menemukan cara untuk beralih dengan sangat cepat. Alih-alih mendekati dan memikirkan masa depan, Anda perlu memikirkan bagaimana melakukannya sekarang, dalam waktu singkat.
Alih-alih memikirkan reputasi Anda, tentang apa yang akan terjadi jika saya mengatakan bahwa saya yakin atau tidak yakin ... Alih-alih, saya harus melepaskan reputasi saya dan menjadi pendatang baru. Dunce. Bagaimana kita melakukan ini? Hal spesifik apa yang dapat kita terapkan untuk menjadi pemula?
Poin pertama dan paling penting adalah umpan balik. Bahkan sebelum kita merencanakan prototipe kita, menggambar tata letak atau sesuatu yang lain, kita berpikir tentang siapa kita akan menunjukkan model atau prototipe ini, bagaimana kita akan menguji produk, dan apa yang kita coba dapatkan dari percobaan ini. Semakin pendek loop umpan balik ini, semakin baik bagi kami.
Contoh dari kehidupan pribadi. Productive Mobile adalah perusahaan tempat saya bekerja baru-baru ini, sebuah startup, mereka datang dengan platform yang memungkinkan Anda membuat aplikasi seluler dari situs web dengan cara drag and drop. Kami menjualnya ke perusahaan besar karena mereka memiliki produk seperti SharePoint atau SAP yang tidak dapat digunakan pada ponsel, pinch zoom, itu saja. Kami menawarkan mereka opsi: Anda dapat membuat aplikasi seluler berdasarkan situs nyata, katakanlah, dalam seminggu. Masalahnya adalah kami memiliki tim pengembangan yang sangat kuat dan siklus penjualan yang sangat lama. Saat Anda menjual produk perusahaan ukuran Daimler atau BMW, siklus penjualan minimal 8 bulan. Selama periode ini, tim pengembang yang berbakat dapat mengajukan banyak hal.
Apa yang telah kami lakukan dan apa yang membantu kami? Kami menciptakan tim mini pengguna di perusahaan kami yang menggunakan produk. Dan jumlah fitur yang kami mulai lakukan dan rilis menurun. Tetapi pada saat yang sama, kualitas fitur meningkat n kali. Dan ketika kami datang ke pengguna kami dan mengatakan bahwa kami memiliki platform ini dan itu, mari kita coba, untuk beberapa alasan, situasi darurat berhenti ketika kita seperti itu: kita tidak memikirkannya, ini adalah sesuatu yang baru. Kami mulai membuat fitur yang sebenarnya mulai membawa hasil. Ini karena fakta bahwa kami hanya mengurangi loop umpan balik.
Sebagai contoh dengan metronom, proyek Polychops yang saya kerjakan sekarang. Pertama-tama, kami membuat video dalam waktu singkat, yang kami pasang di suatu tempat di Internet. Di dalamnya, kami bertanya bagaimana Anda menyukai konsep ini, apa pendapat Anda tentang itu. Menurut ulasan, kami tidak hanya menghargai betapa menariknya ini. Kami masih punya petunjuk yang bisa kami ajak bicara, siapa yang bisa kami undang ke telepon, wawancara, coba prototipe, dll.
Kami mencoba mendapatkan umpan balik sangat dini. Dan bukan sembarang umpan balik, tetapi kualitatif, bukan kuantitatif.
Apa bedanya? Umpan balik kuantitatif adalah pengujian AV, hasil biner, ketika Opsi A atau Opsi B. menang. Hanya itu yang bisa kita dapatkan dari siklus kuantitatif. Seolah-olah kita berada di ruangan gelap dan tidak ada yang terlihat, tetapi kita memiliki laser pointer. Dari waktu ke waktu, kami menyorotnya di sudut-sudut, menyorot beberapa poin dan memahami apa yang ada di dalamnya.
Apa yang kita inginkan? Seorang pengguna yang akan menggambarkan ruangan gelap ini, yang tahu itu jauh lebih baik daripada diri kita sendiri. Kami membutuhkan wawancara, panggilan, hal lain yang berkualitas tinggi untuk menerima informasi dari pengguna dalam bentuk yang diperluas.
Contoh perusahaan yang sangat bergantung pada umpan balik kuantitatif adalah Booking.com. Menurut pendapat saya, ada sesuatu yang berfungsi di situs mereka.
Salah satu prototipe proyek yang sedang saya kerjakan adalah fitur yang dengannya seseorang dapat merekam dirinya sendiri dan pada saat yang sama mereproduksi untuk dirinya sendiri bagaimana dia bermain di bawah metronom - baik atau buruk. Kami menemukan fitur ini karena kami meminta umpan balik kualitas dari orang yang menguji prototipe. Salah satu orang menulis bahwa semuanya hebat, saya suka bagian dengan metronom, tetapi akan lebih keren untuk mengekspor trek ini dengan metronom sebagai trek audio. Kami seperti itu - tidak masuk akal, mengapa? Dia berkata: "Saya memasukkan ini ke dalam program saya untuk bekerja dengan musik, kemudian saya menulis sendiri, dan kemudian saya bisa mendengar apakah saya masuk ke ritme atau tidak." Kami seperti itu - sangat brilian.
Tetapi alih-alih hanya mengekspor, kami memutuskan untuk menguji hipotesis. Kami berbicara dengan orang-orang, bertanya apakah mereka mendengarkan diri mereka sendiri ketika mereka bermain dengan metronom. Banyak yang bilang ya, kita sering punya satu program - metronom, program lain - perekam suara di telepon atau di tempat lain, kita hanya merekam dan mendengarkan diri kita sendiri. Kami seperti itu - kami adalah programmer, kami dapat menggabungkan ini dalam satu aplikasi. Hasilnya, kami mendapatkan fitur ini. Kami tidak akan pernah menebaknya jika kami baru saja melakukan pengujian AV.
Bagian terpenting dari prototipe adalah antarmuka. Dalam arti global. Jika kami memiliki beberapa jenis layanan dengan beberapa jenis API, maka antarmuka kami adalah API, lalu apa yang berinteraksi dengan pengguna. Jika kita mengerjakan metronom, antarmuka kita adalah bagian visual dan suaranya. Jika kita hanya mengerjakan aplikasi seluler, antarmuka kita adalah antarmuka visual. Dalam prototipe, antarmuka adalah satu-satunya bagian yang penting. Segala sesuatu yang kita bisa palsu, ganti dengan yang mewah.
Contoh lain dari Productive Mobile. Pada titik tertentu, kami memutuskan untuk menulis ulang API internal di editor aplikasi seluler drag and drop ini. API memungkinkan JS menghidupkan kembali beberapa bagian kompleks aplikasi seluler Anda. Sebagai manajer produk, saya hanya bisa menulis spesifikasi dan memberikannya kepada pengembang. Saya yakin bahwa dalam maksimal sebulan semuanya akan siap, teruji, dan luar biasa. Tetapi kami memutuskan untuk mencoba jalan yang berbeda. Kami baru saja mendokumentasikan API yang ada di kepala kami, di atas kertas, dan memberikan makalah ini kepada orang-orang yang membuat aplikasi seluler. Mereka bertanya: jika Anda memiliki API seperti itu, bagaimana Anda membangun aplikasi Anda secara teori?
Mereka mengambil kertas lain, mereka memeriksa semuanya. Tanpa implementasi. API tidak berfungsi pada tahap ini. Jadi kami melakukan 5-10 iterasi sebelum kami menyadari seperti apa bentuk API itu. Kami menghemat banyak waktu untuk implementasi. Setelah kami memahami formulir, kami mendokumentasikan spesifikasi, mengimplementasikannya. Segalanya menjadi indah.
Contoh lain dari metronom. Gagasan pertama untuk Polychops adalah metronom untuk bekerja dengan polyrhythms. Kami membuat prototipe pertama dalam sekitar 20 menit, tulis di Flash. Beginilah penampilannya. Bahkan ada suara. Kami baru saja pergi dan menunjukkannya kepada sesama musisi, bertanya - bagaimana Anda menyukainya? Ini satu-satunya hal yang penting.
Lalu kami membuat metronom nyata di browser, itu berhasil, animasi, bla bla, semuanya indah.
Video Metronom Polychops Tetapi butuh sekitar satu setengah bulan, dan prototipe sebelumnya membutuhkan waktu 20 menit.
Fokus pada antarmuka.
Untuk menghemat waktu, gunakan sistem desain. Contoh cepat dari Polychops.
Di sebelah kiri adalah prototipe awal, di mana kita hanya semua tombol, memikirkan semua interaksi sendiri. Setelah beberapa waktu, kami memutuskan bahwa kami memerlukan menu, navigasi, dropdown, sesuatu yang lain. Kita bisa duduk dan berpikir dengan desainer setiap dropdown, setiap tombol, tapi ini adalah waktu yang sangat besar, yang pada prinsipnya kita tidak perlu menghabiskan. Oleh karena itu, kami mengambil sistem desain yang sudah jadi, mengambil desain material, semuanya didokumentasikan dengan sempurna. Kacau, semuanya baik-baik saja.
Mencuri Jangan mencuri dari pesaing. Tidak ada gunanya mencuri dari pesaing. Jika sesuatu berfungsi untuk pesaing, Anda tidak perlu memeriksanya, Anda hanya perlu menyalinnya. Curi dari produk yang sejajar dengan milik Anda, yang bukan produk Anda, tetapi sesuatu yang serupa.
Contoh lain dari Polychops. Antarmuka perekaman praktis dijilat dari program suara yang ada seperti Logic. Secara alami, kami sangat menyederhanakannya, tetapi orang-orang sudah mengerti cara menggunakan Logika, yang berarti mereka dapat memahami cara menggunakan Polychops.
. , . .
: , . , , .
, , . , , . , , , , , . .
— . , , . , .
, , — . . , React . React, React. , , , Redux Apollo, . . .
— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .
, , . . , . — , , .
, . , . . , . . . — , . , .
? « ?» — , . ?
. , . . 10% , , 10%, , — .
. , 90% , . , , 10%. — , . .
, . Productive Mobile , . , , - , .
. React, — React Native. , , — React, React Native. - : «, React Native, , ». .
? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .
, , … ?
Polychops - , . , , , , , . - , , . . .
Saya harap Anda akan mencobanya sendiri. Mungkin Anda tidak bekerja di startup, tetapi perusahaan Anda memiliki proyek di mana ada ketidakpastian. Penting bagi saya untuk memikirkannya, berbicara dengan tim Anda, dengan manajer Anda, memikirkan cara bekerja dengan ketidakpastian, bagaimana membangun proses Anda, sehingga proses pengambilan keputusan meningkat, sehingga Anda berhenti membuang waktu untuk hal-hal yang tidak diperlukan.Jika Anda berhasil dan Anda membuat produk hebat, maka saya berharap bahwa pada titik tertentu saya akan menjadi salah satu pengguna yang sangat bahagia. Terima kasih