Di masing-masing dari enam tim pengembangan kami, jaminan simpanan dijadwalkan sekitar dua tahun ke depan, dengan mempertimbangkan refactoring, perbaikan, fitur, dan pakar produk yang hampir tak terhindarkan. Di dalam, semuanya bisa berjalan sesuai prioritas, dan beberapa blok besar menjadi lebih penting, sekarang mereka dipindahkan, lalu sesuatu yang baru ditambahkan di sana. Tapi selalu ada pemahaman tentang tempat untuk menggali dalam beberapa bulan mendatang.
Selain banyak keuntungan, sistem seperti itu memiliki dua kelemahan yang jelas:
- Ini membosankan membosankan, dan kebosanan bukanlah yang memotivasi kita untuk menulis kode.
- Banyak hipotesis terakumulasi bahwa, menurut proses yang biasa, jatuh di suatu tempat di akhir tumpukan, tetapi masing-masing dapat memberikan hasil yang cepat. Atau mungkin juga tidak. Beberapa di antaranya menarik.
Dalam mode normal, sulit untuk menganalisis hipotesis ini, karena Anda memerlukan interaksi antara ilmuwan produk, pelaku bisnis (biasanya manajer lini), dan beberapa orang lagi dari tim pengembangan lain. Artinya, ketika Anda memiliki dua jam gratis, Anda masih tidak bisa melakukannya. Dan karena kita sering menghasilkan uang dengan menginjak-injak jalur bisnis ke antarmuka baru dan fitur baru, pengujian hipotesis adalah kehidupan.
Pertama, kami menyisihkan waktu di dalam kantor dan melakukan alur kerja secara keseluruhan. Ternyata jika Anda memeriksa secepat mungkin, Anda mendapatkan solusi rata-rata. Untuk meningkatkan kualitas, Anda harus keluar dari rutinitas umum.
Karena itu, kami telah melakukan perjalanan ke kota asing tiga kali dan bekerja di sana.
Mengapa ini dibutuhkan?
Jika Anda sudah membaca posting tentang bagaimana kami mengakumulasikan
utang teknis dan apa yang kami lakukan dengannya, dan tentang apa yang perlu diketahui
pengembang tentang bisnis , maka Anda tahu bahwa dari waktu ke waktu kami memiliki lusinan hipotesis tentang apa harus dilakukan. Sekitar setengahnya berasal dari pengembang, sebagian dari cerita dari departemen lain dan pengalihan pengalaman ke diri sendiri, sebagian dari ilmuwan produk, pendiri, atau hanya karena fase bulan.
Selanjutnya, kami menentukan daftar orang yang diperlukan untuk menyelesaikan sebagian besar tugas ini. Sebagai aturan, ini adalah tim pengembangan spesifik (arah udara, kereta api, tur, kereta api, petualangan atau analitik), seorang insinyur infrastruktur, beberapa orang dari bisnis (untuk gambaran umum dan penilaian konsistensi keuangan), seorang analis untuk mentransfer kesana kemari, orang-orang dari tim lain .
Proses dasarnya tampak seperti ini: ambil pemasar, pengembang, perancang, analis, dan pemimpin. Tepat di kantor, seminggu sekali kami mengatur diskusi tentang sprint tentang hipotesis. Suatu hari dialokasikan ketika pekerjaan dilakukan hanya pada hipotesis. Jika solusi dari satu masalah hilang dalam enam jam, maka itu terputus dan meninggalkan proses ini. Tugasnya adalah meluncurkan beta miring dalam enam jam. Sepuluh hipotesis per minggu diuji untuk semua tim.
Ini bekerja dengan baik, tetapi keterbatasan yang Anda lihat di atas.
Pengembangan penuh mengambil apa yang senang dengan manajer proyek berdasarkan hasil beta.
Kami berkonsultasi dengan guru manajemen proyek, dan beberapa orang yang berbeda mengatakan sekaligus bahwa pasukan khusus harus dibentuk di dalam perusahaan, yaitu, mereka yang secara khusus terlibat dalam mempromosikan hipotesis cepat. Di suatu tempat ini disebut kelompok pengembangan, di tempat lain. Intinya adalah hackathon permanen untuk satu tim.
Kedengarannya logis, tetapi tidak diimplementasikan dengan cepat: perlu untuk mengumpulkan para ahli di enam bidang bisnis yang berbeda dan menghilangkan tim utama yang paling menarik, karena semua kismis dari roti dipilih oleh "pasukan khusus" ini.
"Pasukan Khusus" diperlukan karena jika tidak 100% waktu pengembang dialokasikan untuk menyelesaikan masalah, itu akan menjadi lebih buruk. Dinilai berdasarkan pengalaman. Tetapi kami tidak bisa melakukan itu.
Kami mengambil TRIZ dan menyarankan bahwa kami perlu memfokuskan sebagian waktu pada hipotesis, paruh waktu pada pekerjaan utama "dalam jangka panjang". Apa yang mencegah kami melakukan ini, seperti yang kami lakukan di kantor? Konteks, gangguan dan peraturan konstan, pekerjaan konstan anggota tim dan umpan balik panjang.
Beginilah cara orang-orang membuat hackathon. Mereka menghapus semua batasan kantor dan memberikan waktu untuk fokus. Hanya hackathon yang merupakan cerita sukarela gratis, dan biasanya tentang pelatihan. Pengembang menghabiskan hari Sabtu mereka, karena mereka dapat belajar sesuatu yang baru, dan tidak lebih baik untuk melakukan pekerjaan mereka.
Karena itu, kami memutuskan untuk melakukan percobaan dan pergi ke Istanbul dengan tim yang terdiri dari 14 orang.
Eksperimen Istanbul
Kenapa Istanbul? Kami membutuhkan kota yang memenuhi persyaratan makanan:
- Dapatkan penerbangan dengan cepat tanpa penundaan sering (sisi lain dari planet ini tidak cocok, pulau-pulau dengan cuaca yang tidak terduga tidak cocok).
- Aksesnya relatif murah (Islandia biasanya tidak cocok).
- Kota ini lebih menarik daripada Moskow saat ini (tidak semua orang suka keluar dari kantor hanya karena bepergian, Omsk tidak cocok, tetapi penduduk kota ini akan memaafkan saya).
- Ada banyak hal menarik yang Anda tidak perlu melakukan perjalanan jauh (Norwegia tidak cocok).
- Tim dengan suara bulat ingin pergi ke kota ini.
Kami membuat daftar kota yang cocok dan berdiskusi dengan semua orang. Penting bahwa semuanya diperiksa sekaligus, dan ini bukan tugas yang mengerikan.
Kami memutuskan bahwa kami akan mengadakan pertemuan besar di Istanbul dengan imbalan cuti dua hari (dibayar), tetapi kami membeli tiket sendiri. Logika ini cocok untuk semua orang, karena ini adalah kesempatan untuk berlabuh dua hari libur dengan akhir pekan dan mendapatkan liburan mini di pertengahan tahun.
Ya, pada akhirnya, kita masih orang yang bersemangat bepergian.
Di tempat mereka menyewa sebuah rumah besar di dekat pusat.
Siapa yang melakukan Salah satu pengembang menghabiskan waktu pribadinya untuk mengatur semua ini. Saya tidak yakin apakah ini karena dia ingin mempelajari proses perjalanan bisnis (kami baru mempromosikannya), atau hanya karena dia ingin membantu semua orang.
Selama seminggu mereka memperingatkan
dapur bahwa kami membutuhkan makanan ringan di jalan, tetapi beban makanan akan berkurang dalam beberapa hari mendatang.
Kami bekerja pada hari Jumat pagi, seperti biasa, pada pukul 12:30 kami pergi ke bandara, sekitar pukul 15.00 - keberangkatan, pukul 18.00 kami di sana.
Kami tiba di rumah, sudah ada wi-fi dikerahkan di sana, saya sudah mencetak materi dengan saya. Semua dengan laptop perusahaan. Kami makan, duduk, dan mendiskusikan hal-hal utama. Bahkan, itu adalah perdebatan tentang apa dan bagaimana yang harus dilakukan dalam produk. Artinya, kami memutuskan apa yang harus masuk ke dalam simpanan. Saya ingin membahas hipotesis "cepat", dan nasib, dan prioritas tugas jangka panjang.
Hari berikutnya kami datang ke format ini: pada hari Kamis daftar masalah bermasalah muncul (selain yang sudah diketahui), jadi kami berbicara tentang mereka hampir semua Jumat. Dua sisi ditemukan: satu untuk hipotesis, yang lain menentang. Kemudian mereka mengatur duel, yang dinilai semua orang. Artinya, hampir seperti uji coba hipotesis: jaksa penuntut menarik apa yang tidak perlu Anda lakukan, dan pengacara menarik untuk kesuksesan dan kegembiraan. Benar, maka mereka tidak berpikir untuk mengganti jaksa dan pengacara, dan ini adalah prosedur standar dalam perdebatan semacam itu.
Jadwal kerja adalah ini: kami memilih waktu terburuk untuk jalan-jalan (di Istanbul ini adalah tengah hari), kami menempatkan pertemuan di sana. Pagi dan sore gratis, tetapi kami makan siang bersama, ini adalah kesempatan untuk berkomunikasi. Dalam perjalanan itu, beberapa orang masih menyelesaikan tugas-tugas kecil, yaitu, mereka tidak bisa sepenuhnya mematikan proses yang biasa. Di sisi lain, saya tidak akan mengatakan bahwa butuh waktu yang cukup lama.
Contoh hipotesis run-in
Bus tidak memiliki tiket elektronik yang disetujui secara hukum. Ini sangat menyedihkan kami, karena penumpang harus mencetak formulir di rumah atau mencetak pada printer di stasiun bus (yang kadang-kadang menjadi masalah, dan kadang-kadang dangkal dengan dikenakan biaya). Russian Railways telah lama menerima pendaftaran elektronik hampir di mana-mana, pesawat terbang mencetak kepada Anda di bandara tanpa pertanyaan di terminal atau di meja depan (dan di beberapa tempat Anda tidak perlu mencetak). Dan di bus di beberapa tempat masih 70-an USSR.
Dalam praktiknya, ada stasiun progresif yang hanya menunjukkan tiket dari ponsel. Mereka masih memiliki data ini dalam pernyataan di pihak mereka, dan Anda hanya perlu melihat di sana dan di dokumen orang tersebut. Tetapi ada stasiun konservatif dan mereka yang hanya "Baba Yaga menentang." Dan semua stasiun memiliki bentuknya sendiri.
Dari sudut pandang stasiun, tiket elektronik adalah pengembangan. Keamanan stasiun meningkat, lebih mudah bagi pengendali dan pengemudi, operasi dipercepat, kertas disimpan, anak muda tidak bertanya.
Ngomong-ngomong, di bus, satu atau dua penumpang lupa tiketnya, dan bagaimanapun mereka dikembalikan dari data stasiun. Tetapi di beberapa tempat mereka menemukan kesalahan sangat banyak. Latihan telah menunjukkan bahwa jika seorang penumpang mulai melakukan skandal, mereka membiarkannya masuk. Jika dia pergi dengan tenang (paling sering pensiunan) - kita harus memahami situasinya.
Hal pertama yang kami lakukan adalah mengalokasikan stasiun konservatif dan ketika membeli tiket kami membuat pemberitahuan terpisah dengan mereka kepada penumpang bahwa perlu untuk mencetak tiket: mereka tidak akan diizinkan tanpa itu.
Kemudian kami memutuskan untuk membuat "daftar putih" dari stasiun bus semacam itu tempat pendaftaran elektronik bekerja. Pemeriksaan tiga kali lipat: penarikan penumpang, panggilan pelanggan rahasia kami, pertanyaan langsung ke manajemen stasiun.
Jika undang-undang ketinggalan kenyataan dalam hal mengizinkan tiket elektronik, tetapi ada solusi melalui pemulihan tiket menurut stasiun, lalu mengapa tidak mengotomatiskan dan membuat tongkat penyangga Anda yang cepat dan nyaman?
Secara umum, kami menemukan stasiun seperti itu dan tanda yang ditandai di situs.
Verifikasi diulangi dari waktu ke waktu.
Dalam prosesnya, ternyata ada stasiun yang datang sendiri ke skema semacam itu, tetapi tidak benar-benar memberi tahu penumpang tentang hal itu. Integrator untuk ini juga berjalan dengan gembira.
Kemudian kami memberikan bonus kecil dalam sistem kepada stasiun-stasiun yang memiliki tanda sedemikian rupa sehingga ada insentif ekonomi untuk melakukannya.
Sebagai hasilnya, ternyata kami dengan cepat menggabungkan (yah, sebenarnya bukan kami, tetapi mereka sendiri menggabungkan, khususnya, dengan alat kami) beberapa stasiun dan operator yang sudah melakukan registrasi elektronik sendiri.
Artinya, Anda tidak bisa hanya duduk dan menunggu sampai semuanya muncul secara legislatif, tetapi mencari tahu bagaimana melakukannya secara terprogram. Dan itu dia. Kami membutuhkan sekelompok pengembang, manajer, orang dalam komunikasi dengan mitra dan desainer.
Apa hasilnya?
Kehilangan pengalaman pertama:
- Minus tiket dan akomodasi.
Manfaat:
- Hampir seperti liburan di pertengahan tahun.
- Selama enam bulan berikutnya, mereka memutuskan semua pertanyaan sekaligus.
- Mereka mampu berkomunikasi secara khusus dengan tim. Untuk beberapa alasan, kantor tidak berfungsi seperti itu.
- Hal-hal yang sulit diukur pada tingkat sensasi: hubungan dalam tim telah berubah.
- Kami melihat produk kami sendiri dari luar: setelah semua, kami menggunakan alat kami (dan tim lain) sepanjang waktu, datang dengan beberapa fitur "on the fly".
- Mereka hanya mengendarai dalam perjalanan, yang logis untuk perusahaan yang tentang perjalanan.
- Kawan-kawan "senior" mengajar "Junees" untuk berpikir secara rasional, tidak hanya dalam pengembangan, tetapi juga dalam perencanaan untuk hari itu. Ini sangat tidak penting, tetapi transfer pengalaman sangat terasa.
- Mereka mampu menarik pengembang jarak jauh ke dalam komunikasi, yang biasanya tidak cukup.
Nezhdanchiki:- Kami belajar bahwa kedua gadis itu memiliki masalah bencana dengan orientasi ke daerah: mereka hilang, kami menemukan mereka, tidak pernah melepaskan. Ini hampir mengganggu sesi kerja.
- Pengembang yang mengambil organisasi menunjukkan manifestasi kepemimpinan situasional. Tidak terlalu diharapkan, eychar dan leader terkejut.
- Kami menemukan bahwa rekan kami Misha mengambil foto-foto keren. Dia mengambil kamera, melepas semuanya, lalu memberikan cetakan kertas. Untuk memori.
Sangat sulit untuk melakukan sinkronisasi pada perjalanan, dan ini belum menjadi proses. Tapi saya pikir itu akan, karena manfaatnya jelas. Sekarang kami menggunakan kedua pendekatan: kami mengalokasikan waktu tim di kantor untuk menganalisis hipotesis dan kadang-kadang pergi. Keberangkatan diperlukan lebih banyak untuk menentukan visi dan tugas-tugas yang tidak setara, dan "jangan ganggu" di kantor untuk memecahkan hipotesis dalam mode hackathon pribadi.
Tujuh hipotesis dipilih dan diuji dalam iterasi pertama, dimana tiga menunjukkan hasil. Misalnya, ke arah bus.
Pada tahap entri data, penumpang mulai menunjukkan sepiring dengan tulisan "Pembelian tiket terakhir untuk penerbangan ini N menit yang lalu". Pada versi seluler A / B menunjukkan + N% terhadap penjualan, di desktop tidak ada hasil yang signifikan. Kami memperluas formulir pencarian pada versi seluler halaman dengan jadwal - sebagai hasilnya, kami mendapat + NN% dari penjualan. Kami menerima data dari pelanggan agar dapat mengembalikannya. Pada masalah kosong, mereka mulai mengumpulkan email pengguna untuk mengirim bus, jika mereka muncul di arah, ada ratusan dari mereka per minggu. Berdasarkan preferensi pengguna, kami mengumpulkan penawaran di buletin. Hasilnya. Hit: 91-93%. Penjualan dari mereka yang membuka surat itu: + NN, 3% (signifikan). Tapi! Orang-orang naik bus ke arah yang sama, yang artinya ramalannya sama. Sejauh ini, ternyata surat-surat akan selalu sama. Kami akan memikirkan bagaimana melakukan diversifikasi.
Pada saat itu, ada tugas-tugas khas dalam jaminan, misalnya, seperti rutin:
- Jalankan dua integrasi dengan stasiun bus.
- Perbarui tiga integrasi saat ini.
- Mengintegrasikan pembawa bus Lithuania.
- Buat konektor untuk 16 operator akun Anda.
Secara umum, ini berfungsi, tetapi kami akan senang mendengarkan pengalaman Anda bekerja “secara terpisah” dari kantor dan bepergian ke suatu tempat jika Anda memilikinya.