Teman-teman, halo semuanya! Nama saya Kolya Arkhipov, saya bertanggung jawab untuk Riset & Pengembangan di Delivery Club.
Tim kami menyelesaikan tugas intensif sains dalam platform FoodTech: kami mengembangkan komponen berdasarkan algoritme dan data, yang banyak di antaranya ada di platform DC. Dalam proses penyelesaiannya, kami dihadapkan pada banyak ketidakpastian baik dari sisi bisnis maupun pembangunan.
Materinya ternyata sangat banyak dan, saya harap, berguna untuk Anda. Oleh karena itu, saya merekomendasikan untuk memasukkan teko dan membuat kopi yang nikmat, saya melakukan ini sendiri saat mengerjakan artikel ini.
Hari ini saya akan memberi tahu Anda tentang balapan yang telah dilewati tim kami selama setahun terakhir. Analoginya muncul dengan sendirinya - kami bekerja di perusahaan yang sangat dinamis, pemimpin pasar FoodTech di Rusia. Kami dengan cepat mengembangkan berbagai bidang bisnis, dan itu benar-benar mendorong! Kami tidak hanya sukses sampai di garis finis, tapi juga mendapat banyak wawasan dalam balapan. Inilah yang ingin saya bagikan dengan Anda.
Artikel tersebut muncul setelah laporan pada konferensi RIT ++ 2020 . Bagi yang suka video, carilah di akhir artikel.
Apakah ketel sudah mendidih? Super! Nah, apa yang akan kita bahas hari ini:
- R&D dan ketidakpastian. Apa yang kami hadapi.
- Eksperimen. Bagaimana dan mengapa kita memimpin mereka dalam pertempuran.
- Pengukuran. Mari kita bahas pilihan metrik dan bekerja dengan risiko.
- Otonomi. Bagaimana kami di DC Tech mengadaptasi kerangka kerja GIST dan pendekatan Sumber Dalam.
Lampu hijau, kopling, pertama - ayo pergi.
R&D dan ketidakpastian
Di beberapa perusahaan, tim R&D terlibat dalam penelitian fundamental dari teknologi baru. Tujuan dari penelitian semacam itu dapat berupa pengembangan proses saat ini dan vertikal yang benar-benar baru dalam bisnis. Misalnya, blockchain adalah teknologi seperti itu beberapa tahun yang lalu.
Segera, kita sedang membicarakan hal lain. R&D di Delivery Club adalah tentang memecahkan masalah terapan. Bisnis kami berkembang pesat, pesanan berkembang, dan sebagian besar proses internal kami didasarkan pada data dan algoritme. Dengan peningkatan jumlah data masukan, beberapa algoritme tidak lagi efektif, dan komponen yang benar-benar cocok untuk kita kemarin, hari ini kita sering menemukan tidak dapat dioperasikan.
Seperti yang sudah Anda duga, masalah seperti itu seringkali bersifat deterministik lemah, dan akibatnya, disertai dengan banyak ketidakpastian dari semua sisi. Mari kita soroti yang utama:
Mari kita lihat lebih dekat apa yang kita hadapi, dan apakah ini benar-benar kesulitan.
Bagaimana mencapai tujuan
Kita selalu memahami dengan jelas tujuan bisnis - ke arah mana kita berencana untuk bergerak, ke mana kita harus pergi. Tetapi masih jauh dari selalu jelas bagaimana mendekati tujuan ini dalam hal tugas penelitian. Strategi mana yang harus diterapkan: melalui eksperimen atau peluncuran fitur secara besar-besaran? Bangun lingkungan dengan simulasi atau eksperimen dalam pertempuran? Pilihannya besar - mata terangkat.
Apa sebenarnya yang layak dilakukan
Oke, kami memahami tujuan bisnis dan menyetujui strategi mana yang akan kami ikuti. Saatnya memutuskan serangkaian fitur tertentu yang akan kami gunakan untuk bekerja. Bagaimana memilihnya, apa yang akan dimasukkan ke dalam backlog, dalam urutan apa: Anda perlu menentukan tidak hanya "apa sebenarnya yang layak dilakukan", tetapi juga siapa yang akan memiliki keahlian maksimal di bidang kita.
Kapan Kita Dapat Mencapai Tujuan Kita Pengaturan
waktu tentu sangat penting untuk bisnis. Penelitian itu keren dan menghibur, Anda dapat mencari fitur-fitur baru dalam data, algoritme penelitian, membaca catatan menarik dari kolega kami dari negara lain. Namun penting bagi bisnis untuk memahami kapan tujuan akan tercapai, karena fitur yang diluncurkan pada waktu yang salah sering kali tidak diperlukan - pasar FoodTech sangat dinamis sekarang.
Mengapa ada orang yang membutuhkan kode saya sama sekali
Ketidakpastian terakhir, tetapi jauh dari signifikan, adalah masalah memotivasi pengembang. R&D sebagian besar merupakan pengembangan eksperimental, akibatnya, kode kami tidak selalu mengakar dalam produksi. Awalnya kami sangat kesal karena kami tidak mengerti mengapa kami membuat fitur tersebut, dan dengan segenap hati kami, dan bisnis memutuskan bahwa itu tidak berfungsi dan perlu digergaji. Pertanyaan - mengapa saya melakukan ini? Mengapa ada orang yang membutuhkan kode saya? - sering muncul bersama kami. Dalam prosesnya, kami menyadari bagaimana kami dapat dan harus bekerja dengan ini, dan sekarang kami yakin bahwa ini adalah salah satu ketidakpastian paling kritis yang perlu diatasi terlebih dahulu.
Jadi, setelah mengisi banyak masalah, kami mengumpulkan semua masalah kami di satu tempat dan menyadari bahwa untuk kebahagiaan kami kekurangan tiga proses di persimpangan ketidakpastian ini.
Secara skematis pada gambar di bawah ini.
Eksperimen akan menjawab pertanyaan tentang bagaimana mencapai tujuan dan apa yang sebenarnya harus dilakukan. Metrik akan memungkinkan untuk menjawab pertanyaan dengan sangat jelas dan transparan apakah kode ini benar-benar harus tetap dalam produksi. Otonomi penuh akan membantu menilai dan memenuhi tenggat waktu.
Kami tidak berhenti. Kopling, gigi kedua, kami mendapatkan momentum dengan cepat.
Eksperimen
Pertimbangkan platform penugasan otomatis kurir khusus. Dia memiliki tugas yang agak sederhana - untuk mempertemukan tiga peserta pasar: mitra kami, ahli logistik (yaitu, kurir mereka) dan pelanggan, sehingga semua peserta merasa puas. Artinya, ketika pesanan diterima, kita harus memilih kurir yang akan datang ke restoran tepat pada saat restoran selesai menyiapkan hidangan, segera mengambilnya dan mengirimkannya ke klien panas dan enak pada waktu yang kami janjikan.
Terlihat sangat mudah, dan di sini Anda bisa mengatakan - cukup teori! Saatnya beralih ke peluncuran nyata.
Saya setuju dengan Anda, tetapi mari kita membahas sedikit tentang proses eksperimen. Mari kita lihat gambaran keseluruhannya.
- - — . — , , .
- — . . — , .
- — Just In Time. , : , , . , , , . , FoodTech- : , . , .
Mari kita lihat lebih dekat proses apa yang ada di balik terpal peningkatan produk.
3.1 Hipotesis. Ini dapat dirumuskan dalam kata-kata atau ditampilkan secara skematis. Hal utama adalah untuk secara jelas membenarkan mengapa itu harus berhasil. Artinya, eksperimen harus memiliki pelatihan teoretis.
3.14 Pengembangan. Saya tidak akan sampai di sini, lebih detail tentang perkembangan kami dijelaskan di artikel ini . Kami menggunakan Scrum, iterasi dua minggu dengan semua aktivitas yang diperlukan.
3.2 Persiapan. Selanjutnya, Anda perlu menyiapkan eksperimen. Artinya, kita perlu memutuskan geosegment atau audiens yang ingin kita komunikasikan selama percobaan ini. Dan juga pilih segmen yang akan kita bandingkan hasilnya.
3.3 Eksperimen. Selanjutnya, kami memulai eksperimen itu sendiri. Poin penting: bahkan sebelum memulai, kami menyetujui metrik bisnis yang akan kami pantau. Mari kita tinggalkan hari ini pembahasan tentang metrik teknis, yang memberi tahu kita bahwa eksperimen diluncurkan dan secara teknis stabil, kita akan berbicara lebih banyak tentang indikator bisnis. Kami pasti akan memperbaiki tanda bahaya - ini adalah beberapa nilai ambang yang tidak boleh kami lewati selama percobaan kami.
3.4 Analisis. Kami telah mengumpulkan banyak data keren dan unik yang hanya kami miliki. Aneh jika tidak mengekstrak informasi yang berguna dari mereka, yaitu untuk menarik kesimpulan yang masuk akal tentang validitas hipotesis yang sedang diuji, serta untuk menekankan hal-hal baru tentang audiens layanan kami.
3.5 Kesimpulan.Mungkin poin terpenting dalam proses ini. Dalam kasus kami, hasilnya selalu menekan tiga tombol:
- meluncurkan eksperimen lebih jauh, ke geografi berikutnya atau segmen pemirsa berikutnya;
- rollback jika terjadi kesalahan;
- terus. Ada beberapa kasus ketika kami melihat pengaruh faktor pihak ketiga yang tidak kami perhitungkan, dan akibatnya, kami tidak dapat menarik kesimpulan yang tidak ambigu. Dalam kasus ini, kami memutuskan untuk melanjutkan.
Eksperimen nyata
Akhirnya saatnya untuk melihat bagaimana ini bekerja dengan contoh dunia nyata. Apakah kamu sudah lelah Kesenangan dimulai.
Kembali ke platform penugasan otomatis. Sebelumnya, kami menyarankan bahwa pendekatan Just In Time akan sangat keren bagi kami untuk mengurangi waktu pengiriman. Kami akan membandingkannya dengan strategi penugasan saat ini, yang kami nyatakan sebagai algoritme rakus.
Pertama, mari kita mendukung hipotesis.
Algoritme serakah
Fitur utamanya adalah segera meresepkan. Segera setelah pesanan tiba di platform, kami mencari kurir mitra kami yang paling sesuai untuk pesanan ini, menunjuk tanpa penundaan dan memberi tahu kurir tentang pesanan ini. Hasilnya, kami akan mengoptimalkan waktu yang dihabiskan untuk mencari kurir. Tetapi pendekatan ini tidak selalu efektif, karena dalam satu menit situasinya dapat berubah: pesanan baru tiba atau kurir lain dibebaskan. Algoritme tidak lagi bereaksi terhadap ini. Di bawah ini adalah ilustrasi.
Dalam contoh ini, kami mendapatkan total 45 menit untuk memilih dua pesanan. Sepertinya kita bisa lebih baik.
Tepat waktu
Tugas dari algoritma ini adalah memilih kurir yang akan tiba di restoran tepat pada saat pesanan sudah siap. Apa yang akan diberikannya kepada kita? Ini pada akhirnya akan mengurangi waktu pengiriman karena fakta bahwa:
- kurir akan menghabiskan lebih sedikit waktu di restoran;
- kami akan memilih kurir dengan lebih optimal.
Secara teknis, ini cukup mudah diterapkan. Saat pesanan diterima, kami langsung memilih kurir, tetapi kami tidak memberi tahu dia tentang pesanan tersebut, sehingga membuat "janji temu virtual" dan memberi diri kami waktu untuk mengubah pilihan kami. Dan kami akhirnya akan memutuskan (apakah akan mentransfer pesanan ke kurir) hanya jika jalur ke restoran sama dengan waktu yang tersisa untuk menyiapkan pesanan. Secara skematis - dalam ilustrasi di bawah.
Akibatnya, kami memilih pesanan hanya dalam 30 menit, yang sepertiga lebih sedikit dari kasus sebelumnya.
Menurut pendapat saya, hipotesis itu dibenarkan, kami membawanya ke dalam pengembangan. Sesuai kesepakatan, kami tidak akan mempertimbangkan proses pengembangan secara detail.
Mari lanjutkan dengan mempersiapkan percobaan
Apa yang perlu disiapkan dalam kasus kita? Tidak terlalu banyak: periode pengujian A / B, geografi eksperimen, dan eksperimen yang akan kita bandingkan. Kami menetapkan kota tertentu, memilih kondisinya untuk meminimalkan dampak dari satu strategi janji temu pada yang kedua.
Kami pasti akan bernegosiasi dengan bisnis tentang tanda bahaya dan reaksi terhadapnya. Bendera merah adalah ambang metrik bisnis yang tidak ingin kami lewati selama eksperimen. Jika disilangkan, maka dalam sejumlah besar eksperimen ini adalah rollback. Tetapi ada pengecualian ketika kita mengetahui dengan pasti bahwa persimpangan itu bukan karena kita, melainkan karena faktor lain. Dalam kasus ini, terkadang kami dapat memutuskan untuk melanjutkan eksperimen.
Apa lagi yang perlu disiapkan? Setuju dengan kolega kami dari ruang kontrol, yang mengamati secara real time bahwa semuanya baik-baik saja dengan pesanan. Bagi mereka, perubahan kami akan terlihat, karena sebelumnya kami menetapkan pesanan untuk kurir segera, tetapi sekarang kami tidak melakukan ini, kami memberi diri kami waktu untuk berubah pikiran. Itulah mengapa rekan kerja harus diperingatkan tentang eksperimen yang direncanakan.
Oke, ayo lanjutkan. Mempersiapkan percobaan, melaksanakannya dan mendapatkan hasilnya. Dan inilah bagian yang menyenangkan - analisis.
Analisis Eksperimen
Kami sepakat untuk meningkatkan total waktu pengiriman, dan tiba-tiba ada empat jadwal. Perlu dijelaskan di sini. Saat memulai eksperimen, penting untuk tidak melihat satu metrik utama, tetapi pada beberapa indikator bisnis yang penting untuk bisnis - dalam hal ini, kami dapat secara signifikan mengurangi risiko hipotesis yang gagal yang memengaruhi proses nyata di platform. Jujur saja, kami membuat kesalahan seperti itu di awal eksperimen, dan terkadang kesalahan itu menyebabkan konsekuensi yang sangat tidak menyenangkan. Tapi kesalahan itu bagus, kita belajar darinya.
Mari kita lihat hasilnya. Kami akan menampilkan grafik tanpa nilai tertentu, karena tujuan artikel ini bukanlah analisis mendetail tentang efisiensi algoritme Just In Time. Kami ingin lebih fokus pada pendekatan kami saat melakukan eksperimen. Untuk alasan yang sama, kami tidak akan memikirkan teori melakukan pengujian A / B dan menentukan signifikansi statistik hasil, ini adalah topik besar untuk publikasi berikutnya, dan mungkin bahkan untuk keseluruhan siklus.
- « ». , , . , . , — , . , . , , . , . , , (/), — , , . -, .
- « ». . , , , . , . , .
- « » « ». : . .
Akibatnya, kami mengalami penurunan metrik kunci (1), penurunan metrik yang sangat penting (2), nilai stabil dari dua metrik utama lainnya (3, 4), bendera merah tidak menyala. Hal ini memungkinkan kami untuk menyimpulkan tentang keberhasilan eksperimen dan validitas hipotesis yang sedang diuji.
Kelas! Apakah Anda melanjutkan ke hipotesis berikutnya? Ini sangat menghibur dan dirancang untuk meningkatkan kehidupan semua orang! Tapi tidak, itu belum semuanya. Mungkin masih ada salah satu langkah terpenting, yang tidak boleh kita lupakan. Ini untuk menekan salah satu dari tiga tombol:
- Mulai tersedia
- Rollback
- Terus
Dalam proses eksperimen, tim harus memiliki rekan kerja yang bertanggung jawab atas fitur sepenuhnya, yang akan menekan salah satu dari tiga tombol ini. Pada awalnya, kami memiliki kasus ketika kami lupa tentang langkah ini, sebagai hasilnya, kami menerima beberapa lusin eksperimen yang diluncurkan secara bersamaan tanpa status yang dapat dimengerti untuk masing-masing eksperimen. Mereka memberikan hasil yang positif, tetapi tidak sepenuhnya diluncurkan, yang tidak efektif untuk bisnis. Selain itu, kami harus menghabiskan banyak sumber daya hanya untuk mengingat detailnya dan mengatur semuanya. Tapi, sekali lagi, kita belajar dari kesalahan.
Eksperimen dunia nyata
Mari kita bahas secara singkat mengapa kita segera bereksperimen dalam pertempuran. Pendekatan ini biasanya ditentang oleh lingkungan simulasi analitik, yang, berdasarkan data historis, dapat, dengan akurasi tertentu, menjawab “jadinya” jika kita menerapkan fitur seperti itu.
Mengapa kami memilih pendekatan pertama? Dua alasan.
- -, .
, , . , - , , . — .
. .
? , , , — . , , , , , . , .
Sejujurnya di sini bahwa ini adalah pendekatan yang agak berisiko. Resiko mengecewakan penonton, pelanggan, bisnis. Artikel ini sebagian besar dikhususkan untuk cara mengurangi risiko tersebut: dengan hati-hati dan akurat memilih metrik (beberapa) dan memantaunya secara real time. Jika terjadi kesalahan, kami segera menonaktifkan eksperimen tersebut.
- Yang kedua , tentu saja, kecepatan. Eksperimen dalam kondisi pertempuran akan menunjukkan hasil yang jauh lebih akurat dan lebih cepat.
Sebelum kita melangkah lebih jauh, mari kita perbaiki beberapa kemenangan kecil.
Proses percobaan yang transparan memberi kita jawaban atas pertanyaan tentang bagaimana mencapai suatu tujuan. Dan dengan segera melakukan tes dalam kondisi nyata, kami mulai lebih memahami audiens kami. Hasilnya, tim pengembangan memiliki keahlian yang cukup untuk mengusulkan fitur spesifik yang dapat memecahkan masalah bisnis.
Tidak buruk, tapi itu belum semuanya. Saatnya berbicara lebih banyak tentang keterukuran. Dan sementara itu kita menyalakan yang ketiga, gas ke lantai, angin bersiul.
Pengukuran
Mengapa kita membutuhkan metrik? Terutama untuk mengkonfirmasi hipotesis atau mengurangi dampak dari asumsi yang gagal. Hipotesis, bahkan teori yang beralasan kuat, tidak selalu tepat. Dan saat mereka menembak, terkadang di lutut.
- -, FoodTech, : , , , .
- -, , , . , , , . ! , , , . , , -.
Pengalaman kami menunjukkan bahwa resep yang bagus adalah bila ada beberapa metrik. Satu metrik target - meningkatkannya; dan beberapa lagi yang penting - kita tidak boleh menjatuhkannya.
Memperkenalkan ruang pemantauan terpadu di mana bisnis dan pengembangan terlihat. Tidak harus satu alat, kami menggunakan dua: Metabase dan Grafana, tetapi ke depan kami berencana untuk memilih salah satunya. Yang terpenting, harus ada satu ruang tempat kolega dari bisnis dan pengembangan akan melihat. Dan pastikan untuk mengidentifikasi bendera merah.
bendera merah
Ya, ini adalah beberapa nilai ambang metrik yang tidak boleh kita lintasi selama percobaan. Layak untuk menyetujui bisnis tentang reaksi, jika mereka telah menyeberang, dan memposting peringatan pada mereka.
Dan satu kemenangan kecil lagi: kami menjawab pertanyaan "Mengapa ada orang yang membutuhkan kode saya sama sekali". Jangan lupakan dia!
Izinkan saya mengingatkan Anda bahwa ketidakpastian dari bagian pengembangan ini adalah bahwa kami tidak selalu memahami mengapa kode kami tidak tetap diproduksi, dan, terus terang, kami sedih tentang ini. Dengan mengadopsi pendekatan pencelupan peer-to-peer dari pengembangan ke metrik bisnis, kami tidak hanya meningkatkan pemahaman kami tentang solusi pelanggan, tetapi juga menyediakan diri kami sendiri dengan dosis dorongan dalam memecahkan masalah bisnis dengan berfokus pada hasil akhir.
Oke, kami menemukan eksperimen dan proses transparan, metrik, dan keterukuran. Di depan adalah garis finis, kami berbelok di urutan keempat, dan dengan kecepatan maksimum hingga kemenangan.
Otonomi
Semua hal di atas bekerja sebaik mungkin hanya jika kita menjadi otonom baik dari sisi bisnis maupun pembangunan.
INTI
Di sini, yang kami maksud dengan otonomi adalah ketergantungan minimum ketika membuat keputusan. Apa yang telah kita lakukan di sisi bisnis untuk membuat keputusan dengan cepat dan tidak tenggelam dalam proses persetujuan? Kami telah menerapkan kerangka GIST.
Pendekatan ini adalah Tujuan, Ide, Langkah-proyek, Tugas. Perusahaan memiliki tujuan bisnis yang jelas yang dikomunikasikan secara transparan oleh manajemen kepada seluruh karyawan. Untuk mencapai tujuan tersebut, karyawan melontarkan ide. Mungkin ada selusin atau satu ide. Penting bahwa sebuah ide belum menjadi proyek. Ini adalah beberapa pendekatan yang ingin saya terapkan. Langkah-proyek - ini sudah proyek: fitur yang cukup besar yang menerapkan ide-ide ini. Dalam contoh Just In Time kami, tujuannya persis dengan proyek Step. Pada tingkat terakhir adalah tugas-tugas yang biasa kita lakukan - ini adalah proyek Langkah yang sudah membusuk, diperkirakan dalam biaya tenaga kerja.
Jadi, bagaimana pendekatan tersebut membantu Anda mencapai otonomi? Saat kami mengusulkan untuk membuat fitur ini (Just In Time), bisnis secara transparan melihat:
- Ukuran dan biaya penerapan fitur.
- Ide apa yang dia terapkan.
- Apa tujuan spesifik perusahaan (dampak).
Kemudian kita hanya perlu membandingkannya dengan proyek Langkah tetangga sesuai dengan kriteria yang sama: biaya, dampak. Kami mengadakan pertemuan (mereka biasa dengan kami), berdiskusi, memprioritaskan dan membuat keputusan.
Ini terlihat sangat sederhana dan lugas. Dalam kasus kami, ini benar, dan berhasil: bisnis membuat keputusan dengan cepat, kami senang. Tapi ini baru langkah awal menuju otonomi, karena dari sisi pembangunan kita juga tidak boleh terhalang.
Sumber Batin
Ini seperti open source, hanya di dalam perusahaan. Arsitektur Delivery Club adalah layanan mikro, sekarang ada lebih dari seratus. Seringkali, untuk membuat fitur, Anda perlu memodifikasi tidak hanya komponen yang menjadi tanggung jawab tim kami, tetapi juga layanan di sekitarnya. Dan di sini kami memiliki dua cara:
- Letakkan perbaikan di simpanan tim lain, setujui bahwa orang-orang akan membuatnya.
- Lakukan sendiri.
Dalam adaptasi kami, prosesnya bekerja sebagai berikut. Ada fitur Just In Time yang besar, yang memengaruhi tiga grup layanan:
- platform penugasan otomatis di mana R&D bertanggung jawab,
- platform logistik,
- komponen interaksi dengan mitra (restoran dan toko).
Kami melakukan ini:
- mengumpulkan semua tugas ke dalam simpanan tim R&D;
- kami memprioritaskan dan mendistribusikan dalam tim mana di antara orang-orang yang akan menyempurnakan komponen mana;
- kami setuju dengan para pemimpin teknis dari tim logistik dan area mitra tentang nuansa implementasi;
- kami mengembangkan diri, kolega melakukan tinjauan;
- lalu kita menguji diri kita sendiri;
- Kami sudah memberikan pemilik layanan untuk bergulir ke produksi.
Setelah mulai berproduksi, peningkatan ini tetap menjadi tanggung jawab tim yang memiliki layanan ini.
Sejujurnya, pendekatan ini tidak sempurna dan memiliki risiko. Yang utama adalah waktu. Paling sering, kami memodifikasi komponen 2-2,5 kali lebih lama daripada yang akan dilakukan pemilik layanan.
Tetapi manfaatnya juga jelas, ini jauh lebih besar daripada penundaan kecil dalam penerapannya - ini dapat diprediksi. Penting untuk dicatat di sini bahwa tim lain memiliki backlog mereka sendiri, prioritas mereka sendiri, dan mereka paling sering tidak dapat mengambil tugas kita "segera". Oleh karena itu, tenggat waktu bisnis kita realistis; tidak akan terpengaruh oleh kemungkinan perubahan prioritas di tim lain.
Jadi, selamat - selesai, kemenangan!
Kami telah menerapkan kerangka kerja GIST untuk pengambilan keputusan yang cepat dan transparan, dan pendekatan Sumber Dalam untuk otonomi dalam pengembangan, dan sekarang semua potongan teka-teki telah disusun. Saatnya untuk menutup balapan, balapan yang menarik, terima kasih atas partisipasinya! Mari kita rangkum.
kesimpulan
- Eksperimen adalah alat yang transparan dan efektif untuk mencapai tujuan.
- Melaksanakannya di lingkungan nyata, kami mempelajari audiens kami, yang memungkinkan kami membuat perubahan yang semakin berguna setiap saat, serta memahami mengapa tidak semua fitur harus tetap dalam produksi.
- Namun untuk menghindari kekacauan, Anda memerlukan proses yang jelas, pembagian peran dan penunjukan orang yang bertanggung jawab.
- Pada fase aktif eksperimen dan selama analisis, ada baiknya memantau beberapa metrik utama sekaligus dan tidak lupa untuk menarik kesimpulan (dalam kasus kami, tekan salah satu dari tiga tombol).
- Membuat keputusan cepat dan otonomi dalam pengembangan membantu mencapai hasil dan menjaga tim tetap termotivasi.
Rekaman video dari laporan dari konferensi RIT ++ 2020 .
Itu saja, terima kasih telah bersamaku dalam lomba ini. Saya yakin kami berada di awal dan tantangan besar masih menanti. Saya akan dengan senang hati membagikannya, sampai jumpa!