Bahkan di perusahaan yang sangat besar, mereka sering memperlakukan pengembang seperti jamur: mereka disimpan dalam kegelapan dan diberi makan dengan pupuk kandang. Tulis kode, keluarga, dan jangan menjulurkan kepala. Pendekatan ini mungkin nyaman bagi banyak orang (termasuk kadang-kadang untuk pengembang sendiri dalam hal manajemen yang tidak memadai), tetapi dari sudut pandang bisnis tidak optimal. Posisi saya: pengembang harus dapat mempelajari segala sesuatu yang terjadi di perusahaan dan di pasar, tetapi tanpa tekanan. Dicari - dia menggali dan mencari tahu, tidak mau - tidak.
Jarang ada pengembang yang tidak mau mengerti mengapa dan apa yang dia lakukan. Beberapa yang tidak ingin melihat dampak dari fitur yang diimplementasikan pada dunia sekitar. Ayo, jujur saja: kita semua ada di sini karena uang, atau karena kemampuan untuk melakukan sesuatu yang bermakna. Ada uang di mana-mana. Tetapi proyek yang menarik kurang umum.
Saya ingin membagikan proses bagaimana kami memiliki informasi seperti itu yang diatur dalam tim Tutu.ru. Mungkin bagi sebagian orang itu kelihatannya sebuah program pendidikan, tetapi bagi seseorang itu akan berguna. Baik, atau Anda memberi tahu saya cara berbuat lebih baik.
Posisi umum
- Tim pengembang, sejauh mungkin, akan mengatakan apa yang terjadi di pasar, hubungan seperti apa dengan pesaing, apa dan bagaimana hal itu terjadi.
- Penting bagi manajemen puncak perusahaan untuk mengetahui apa yang sebenarnya dilakukan dalam proyek dan bagaimana hal ini mengarah pada tujuan strategis. Biasanya kita berbicara tentang tingkat kelompok proyek, tetapi jika Anda mau, Anda bisa gagal melaporkan ke pekerjaan tertentu.
- Tim lain tertarik untuk melihat apa yang dilakukan rekan kerja. Kami menggunakan berbagai jenis transportasi (kereta api, udara, bus) untuk memecahkan masalah yang sama, dan Anda sering dapat menggunakan kembali kode, memata-matai ide atau melihat bagaimana berbagai alat digunakan. Dan bertanya.
Apa pengaruhnya?
Mungkin terlihat bahwa jika pengembang jatuh tugas dari atas, maka maksimum yang mampu ia miliki dengan gambaran pengetahuan yang lengkap adalah memilih solusi arsitektur yang sedikit lebih benar. Dipercayai bahwa ini mengurangi tingkat pertumbuhan hutang teknis, seiring dengan meningkatnya kebenaran arsitektur. Ya, itu benar, tetapi dalam praktiknya, mengatur dan mendukung proses informasi di luar jamuan makan adalah sama sulitnya dengan berurusan dengan hutang teknis.
Tetapi kemudian hal penting kedua muncul. Yakni, mereka yang ingin berpartisipasi dalam sesi curah pendapat bersama dengan bisnis. Yaitu, jika sebelumnya bisnis itu sendiri direncanakan, tetapkan tugas dan prioritas dan katakan pada diri sendiri apa dan bagaimana melakukannya, sekarang perkembangan memengaruhinya.
Dan di sini kita sering mengalami fenomena yang sangat menarik. Pemikiran seorang insinyur berbeda dari orang biasa. Di suatu tempat yang lebih terstruktur, di suatu tempat keputusan yang tidak terduga baik, di suatu tempat penyimpangan kognitif. Ada tampilan tanpa awan. Ada penolakan terhadap praktik "itu terjadi" karena bagi sebagian mereka itu diberikan, dan bagi insinyur itu adalah warisan yang kelam. Dan tidak peduli berapa usianya.
Awalnya, diskusi melambat. Para pengembang jelas mengalami kesulitan besar dengan analisis keuangan, dan itu perlu memuat mereka sangat sering untuk membenarkan kemungkinan atau ketidakmungkinan (lebih sering) dari suatu solusi.
Kemudian beberapa kali saya berhasil menemukan tempat-tempat di mana bisnis itu bahkan tidak berpikir bahwa sesuatu dapat dilakukan dengan hampir satu gerakan. Jadi, misalnya, menggunakan model matematika dari pergerakan bus, kami dapat mengikat perhentian ke rute dan mengembalikan jadwal di kedua arah.
Ini ceritanya .
Hal penting berikutnya adalah bahwa sistem tunggal diharapkan muncul di pasar dalam 1-2 tahun ke depan. Setahun yang lalu, itu tampak fantastis, dan masing-masing operator, termasuk SP kecil dengan bus tahun 80-an berkarat, memiliki standar sendiri. Sekarang semua ini berakhir dalam satu sistem informasi. Kami telah membangun sebagian fungsinya, tetapi sekarang mungkin untuk menghapus lapisan ini dan segera mendapatkan data bersih. Tentu saja, dengan perubahan di pasar seperti itu, kita perlu seluruh tim untuk berdiskusi. Paling tidak, ini menghilangkan pertanyaan dari tingkat "mengapa kita tidak menyelesaikan kode keren saya dari fitur keren", dan pada batas maksimum memungkinkan untuk mempersiapkan perubahan lebih efektif daripada orang lain. Pemasaran berkonsultasi dengan tim teknis, menanyakan bagaimana mereka akan membuat sistem baru dan batasan apa yang dimilikinya. Kami menggambarkan arsitektur tentang bagaimana hal itu akan diterapkan di tingkat federal, dan menyadari bahwa sistem kami akan menjadi tambahan untuk mengelola merek, kampanye pemasaran, dan alat lainnya untuk mempromosikan dan berkomunikasi dengan pengguna. Ini tidak akan menjadi duplikat bersaing, tetapi terintegrasi.
Atau di sini adalah contoh apa yang harus dilakukan jika kita perlu menghubungkan banyak mitra kecil ke sistem. Bisnis mengenal semua orang dengan pandangan dan mengerti bagaimana mereka berpikir. Pengembang tidak mengenal siapa pun, tidak mengetahui pembatasan pasar, jadi dia menghitung model dan mengusulkan solusi rasional yang dingin. Dalam upaya untuk membenarkan mengapa hal itu tidak mungkin, bisnis menyadari bahwa sebenarnya pembatasan pasar agak ilusi. Dan di sini kita memiliki terobosan lain, tetapi tidak dalam pengembangan lagi. Tim untuk bekerja dengan mitra mengalihkan fokus ke mitra lain, yang memberi kami lebih banyak data ke sistem.
Contoh berikut. Pengembang berbicara di konferensi, berbicara tentang solusi teknis. Dia berbicara tentang sistemnya sendiri untuk memesan penerbangan - akun pribadi operator. Dia ditanyai pertanyaan yang sepenuhnya khusus dari penonton di tingkat "apa yang akan terjadi jika saya duduk di halte berikutnya." Dalam 98% kasus, pengembang akan merespons dalam hal integrasi dan pertukaran data. Di sini dia berbicara tentang cara kerja bisnis, hubungan seperti apa antara pembawa dan stasiun. Dan berdebat setiap detail.
Oke, bagaimana cara menginformasikan sesuatu?
Ketika perusahaan memiliki lima pemilik produk, kami berkumpul dan bertukar seminggu sekali tentang apa yang berguna dalam produk dan apa yang mungkin berbeda. Lalu kami menjadi delapan. Lalu - 13 orang. Dan 13 orang sudah lebih sulit untuk berkumpul. Mereka menyarankan untuk bertukar hasil analitik dalam surat. Mereka mulai berbicara tentang apa yang mereka lakukan berguna dalam produk, dan untuk memberikan rekomendasi tentang cara menerapkannya pada produk lain. Sekali sebulan setengah, lalu - sebulan sekali.
Jadi aturan-tradisi dengan laporan bulanan dibentuk. Menurut hasil kerja tim, surat besar dan kuat dikirim dalam sebulan (waktu terakhir di bus adalah 27 halaman A4). Anda hanya dapat membaca bagian atas, tetapi Anda dapat melakukan semuanya dalam satu baris atau dalam potongan. Ini membantu untuk mendapatkan umpan balik, ide-ide baru.
Laporan ini digandakan oleh kinerja rapat: tidak perlu datang, tetapi sering kali orang-orang dari tim tetangga datang. Yang penting pada pertemuan itu pendek, Anda bisa mengajukan pertanyaan dengan cepat. Kemudian baca surat itu dan pahami detailnya jika Anda mau. Pada salah satu pertemuan ini, seorang karyawan kereta api memberi tahu bagaimana penggunanya pergi ke Sverdlovsk (Ukraina) alih-alih Yekaterinburg (Rusia, mantan Sverdlovsk di wilayah Sverdlovsk). Ada juga tabrakan seperti itu di bus. Bersama-sama mereka memikirkan analisis probabilistik (ke mana Anda harus pergi) dan sistem peringatan tentang rute atipikal. Mengubah urutan kiat untuk huruf pertama kota, sehingga arah yang tidak mungkin diurutkan lebih lambat daripada yang paling penting.
Saya mengumpulkan intisari pada pendekatan makanan. Artinya, ia pertama-tama mengirimkan apa yang menurutnya benar dari nilai-nilai pengguna akhir (pengembang tim, pemilik proyek, pebisnis yang berkomunikasi dengan mitra), dan kemudian ia mulai mengumpulkan umpan balik. Di suatu tempat, seseorang mulai mengajukan pertanyaan yang sebelumnya tidak ada. Di suatu tempat mereka meminta lebih banyak detail. Lalu saya mengirim polling kepada semua orang tentang apa yang bermanfaat dan apa yang tidak.
Akibatnya, struktur berikut muncul:- Tugas utama yang ada di produk: untuk apa, mengapa, mengapa, bagaimana. Sangat penting untuk dicatat bahwa setiap tugas entah bagaimana mempengaruhi pasar. Kelompok fitur berkumpul dalam poin strategi seperti "melakukan pemesanan tercepat" atau "memiliki jadwal paling akurat",
- Kemudian kami mengambil hasil studi analitik. Jadi, misalnya, berkat penelitian kami, kami belajar bahwa sering kali naik bus hanyalah langkah pertama dalam perjalanan, dan kemudian seseorang bepergian dengan kereta api. Atau dari kereta berganti ke bus (jika bepergian ke pedalaman). Dan ini sangat penting, karena dalam pendekatan pertama itu mempengaruhi pemasaran, dan yang kedua - secara umum pada semua antarmuka. Karena tugas yang sudah bukan untuk membeli tiket bus, tetapi untuk berlabuh dengan kereta api untuk mendapatkan tempat yang nyaman. Analis berikutnya - membandingkan jaringan rute kereta api, kereta api, bus untuk duplikasi atau ekspansi. Sehingga pada halaman jadwal kereta Moskow-Dmitrov dan sekitarnya, bus di seluruh distrik Dmitrovsky ada di widget. Sekarang - dalam implementasi.
- Mungkin ada berita pasar. Semuanya dangkal: hanya agar semua orang tahu apa yang diharapkan dan apa yang telah dilakukan besar.
- Survei - pertanyaan apakah seseorang perlu tertarik. Kami mengumpulkan informasi di dalam siapa yang mengemudi dan masalah apa yang mereka temui. Mereka bertanya kepada tim bagaimana akan lebih mudah untuk menerapkan tiket elektronik. Menurut bermacam-macam bus - yang melaju di mana, bagaimana itu, betapa berkarat semuanya. Terkadang kami meminta Anda untuk mengambil gambar jadwal di halte ke arah tertentu.
Menurut hasil intisari pertama, mereka memulai studi tentang apakah tiket kereta api lebih murah atau lebih mahal daripada tiket bus untuk segmen yang sama. Dan mereka sampai pada banyak hasil yang tidak terlalu jelas. Mungkin saya akan menulis tentang ini nanti.
Banyak penelitian kami bermanfaat bagi rekan kerja. Dan kami mengambil sesuatu. Mengikuti contoh produk lain - wisata - yang dibuat oleh pengguna CJM. Kami terbiasa berpikir bahwa pendekatan untuk membeli tiket adalah tipe saluran linear. Bahkan, orang-orang berkeliaran di antara halaman-halaman, membuka puluhan tab, dengan percaya diri menekan "kembali" di browser dalam berbagai bentuk dan umumnya browser secara bersamaan dari perangkat yang berbeda (mereka mentransfer dari ponsel ke desktop saat Anda perlu membeli). Melacak semua lintasan aneh ini memungkinkan untuk memutuskan bahwa beberapa langkah tambahan, di suatu tempat orang ditutup. Masalah khas Rusia: ketika memilih bus, banyak yang tidak bisa mengalahkan antarmuka pemilihan kursi. Biarkan saya mengingatkan Anda, kami berbicara tentang orang-orang yang tinggal di desa dan tidak tahu perbedaan antara permintaan pencarian dan alamat situs. Ini hanya mereka yang tidak tahu cara menggunakan gulungan pada timbangan di supermarket, jika ada. Secara umum, sebuah hipotesis lahir: Anda harus memilih tempat secara otomatis, dan kemudian Anda harus menyetujui atau mengubahnya. Dan - lihatlah! - Penduduk desa Rusia yang jauh, pekerja migran dan sejumlah kategori pengguna tidak lagi bingung dalam antarmuka.
Sebuah pusat panggilan datang ke salah satu pertemuan untuk mengatakan bahwa mereka tercengang oleh pertanyaan bodoh di baris pertama, dan selama sebulan sekarang - yang sama. Lapisan pertanyaan sangat banyak dihilangkan dengan menandatangani kiat untuk bidang tersebut, menambahkan lebih banyak detail pada surat itu setelah membeli tiket, dan sebagainya. Dari hal yang paling aneh: pada kartu bus, tautan ke rute itu adalah dadu berwarna biru menyala, tetapi orang-orang tidak menyodok ke sana, tetapi menelepon. Artinya, seseorang tidak mengerti secara sederhana bahwa ini adalah tautan.
Penemuan lain yang menarik - kami mendengarkan rekan-rekan dari udara pada pertemuan tersebut dan menemukan cara kerja harga maskapai untuk penerbangan. Dan kemudian mereka menawarkan operator kami untuk memuat bus. Ketika penerbangan berangkat dengan cakupan 40 persen atau kurang, kami mendiskon harga untuk periode waktu yang singkat sehingga kami mendapatkan lebih sedikit kereta di arah yang sama. Biaya tiket 1.300, 400 rubel menjadi: itu tidak menguntungkan bagi operator untuk 400 untuk mendapatkan seluruh bus, tetapi mengambil 10 orang untuk 400 dan mengambil mereka lebih baik daripada tidak mengambil orang lain.
Bagaimana laporan itu dibentuk?
Tugas dan kemajuan mereka. Contoh:
Aturan keputusan baru untuk CC
- Apa yang kamu putuskan? Spesialis pusat kontak dalam beberapa kasus harus secara independen membuat keputusan yang mendukung klien, tanpa menunggu situasi dengan mitra (stasiun bus, operator) untuk dianalisis, yang dapat memakan waktu berminggu-minggu, atau analisis dari dukungan. Oleh karena itu, mereka mengevaluasi di mana ambang harga kerugian berada, di bawahnya para spesialis CC dapat langsung mengambil keputusan.
- Hasilnya, dan apa yang harus kita lakukan selanjutnya? Harga ditentukan, kami akan terus bekerja pada skenario lain. Dalam hal ini, semua data dikumpulkan, dan kami akan mengontrol metrik ini (kehilangan tiket). Spesialis KC mulai secara mandiri menyelesaikan beberapa kasus dari klien.
- Bagaimana ini bisa berguna dalam produk lain? Kadang-kadang itu lebih efektif dan lebih baik mempengaruhi merek jika Anda segera membantu klien daripada terjun ke proses yang mendalam. Evaluasi, mungkin di sini Anda juga memiliki sesuatu untuk dikerjakan.
Pada masalah kosong termasuk semua CTIS (kereta api, udara, kereta api)
- Apa yang kamu putuskan? Pada masalah kosong, ketika kami tidak dapat menawarkan bus ke klien, mereka mulai menunjukkan semua CTIS, mengembalikan kereta. Penting untuk melihat bagaimana ini memengaruhi perilaku, apakah alternatifnya menarik, dan apakah perlu dikembangkan lebih lanjut.
- Hasilnya, dan apa yang harus kita lakukan selanjutnya? Dalam 36% kasus, klien ditawari alternatif. Diasumsikan bahwa pelanggan masih mencari bus nyata (di mana mereka benar-benar pergi), jadi sebenarnya ada banyak pelanggan yang tidak puas. Ini adalah potensi untuk bus dan PTT, di mana kami memperluas jangkauan produk kami. Ada minat dalam hal ini, mereka menonton, tetapi kami tidak berencana untuk secara aktif mengembangkan isu-isu kosong, tetapi kami akan memikirkan lebih lanjut bagaimana mengintegrasikannya dengan benar ke dalam isu saat ini.
- Bagaimana ini bisa berguna dalam produk lain? Bagi negara besar kita, bis dapat menjadi bagian yang sangat diperlukan dalam suatu perjalanan. Oleh karena itu, kombinasi moda transportasi (multimodalitas) dapat secara strategis masuk akal jika Anda membiasakan pelanggan untuk berpikir dalam hal kategori dari A ke B.
Penelitian dan hipotesis, contoh:
Apa yang membuat orang kembali?
- Apa yang kamu putuskan? Jelaskan pengguna yang kembali ke kami, dan bagaimana mereka berbeda dalam perilaku mereka dari mereka yang tidak kembali.
- Hasil, dan apa yang harus kita lakukan selanjutnya? Kami menyusun serangkaian karakteristik perilaku yang menggambarkan pengguna dan yang berpotensi memengaruhi pengembaliannya. Penting bahwa ini bukan model prediksi, tetapi model deskriptif. Selanjutnya kami akan melakukan eksperimen, memaksakan karakteristik dan menonton kembalinya. Pada akhirnya, kami ingin membuat model prediktif untuk memahami bagaimana melibatkan pengguna dalam produk, apa yang harus dilakukan untuk meningkatkan kemungkinan pengembalian. Jelas, tetapi benar: orang yang sudah membeli di bagian lain kemungkinan akan kembali untuk pembelian kembali dengan bus.
- Bagaimana ini bisa berguna dalam produk lain? Jika Anda tertarik untuk menggali arah ini, maka lakukan analisis serupa dan bandingkan persimpangan.
Kemudian - jawaban atas pertanyaan: "Apa yang terjadi?", Contoh agenda:
- Mengapa membeli lebih sedikit? Ya, semuanya baik-baik saja, hanya musim yang tidak kita ketahui.
- Lalu lintas langsung. Mengapa terjadi peningkatan yang tajam? Sudahkah Anda berjanji dengan benar? Dan Anda tidak parsit? Dan juga jawaban untuk beberapa pertanyaan (spoiler: ya, kami diuraikan).
- Platform. Kami melibatkan pengguna. Hasil pertama dari keterlibatan nyata orang dalam manajemen konten di situs. Orang-orang secara aktif membantu.
- Pembelian lintas platform. Tiket elektronik sambil menghentikan orang di PC tanpa printer. Apa selanjutnya 83% dari mereka yang melakukan pembelian pertama mereka di PC terus membeli di PC.
- Analisis kohort. Grafik tidak untuk menjadi lemah hati.
- Bagaimana penjualan di udara. Kami memahami banyak tentang tiket bagasi dan tidak hanya ... (431 pesanan di bus oleh pengguna yang memesan di pesawat selama periode yang sama, 42% di antaranya - bus untuk menambah pesawat (mis., Busnya bisa ke titik keberangkatan atau ke titik kedatangan), 12% - berlawanan arah.)
Eksperimen tidak manusiawi (ini menarik bagi semua tim), contoh:Apa yang mempengaruhi permintaan penerbangan?
- Peringkat pembawa. Perbedaan satu poin dalam peringkat, menurut umpan balik dari pengguna kami (misalnya, 9,4 berbanding 8,4), meningkatkan kemungkinan membeli penerbangan sebesar 23%. Ini bisa menjadi argumen yang sangat signifikan bagi operator untuk meningkatkan tingkat layanan bagi penumpang.
- Probabilitas membeli penerbangan promosi (ditandai dengan Tutu.ru. Menawarkan lencana dengan harga dicoret) meningkat sebesar XX%.
- Menambahkan penawaran promosi pertama dengan kenaikan XX%, ceteris paribus, probabilitas konversi dari penerbitan. Dan ini berarti Anda perlu memperluas kisaran arah dengan saham.
- Jika dalam uji A / B pada setiap penerbangan penerbitan, jumlah kursi yang tersedia berkurang satu, maka kemungkinan konversi dari penerbitan akan meningkat rata-rata X%.
- Jika Anda membuang (menyembunyikan) satu penerbangan pada penerbitan dengan lebih dari 10 penerbangan, maka probabilitas pembelian akan meningkat sebesar 0,6%.
Saya harus mengatakan segera bahwa kami tidak berencana untuk mengganti data dalam hasil sesuai dengan metode 3 dan 4, tetapi kami akan memeriksa faktor pilihan yang sebenarnya. Tes A / B menyangkut sekitar 1% dari audiens situs dan agak terbatas waktu. Semua percobaan etis dalam arti bahwa mereka memungkinkan seseorang untuk memecahkan masalah dan tidak menyembunyikan data penting darinya, dan manfaat dari mereka kadang-kadang lebih penting daripada ketidaknyamanan yang mungkin terjadi.
Umpan balik dari pasar, contoh:- Kami bekerja dengan validasi data jadwal input. Sekarang musuh tidak akan lewat (yaitu, pembawa tidak akan dapat secara tidak sengaja memasukkan data dari rute yang tidak realistis).
- Mereka memberi operator kesempatan untuk mengedit jadwal dan penerbangan mereka. Teman-teman senang, dan kami memiliki lebih sedikit pekerjaan :)
Berikutnya - bongkar dari Jira (sebenarnya) dalam bahasa sederhana bagi mereka yang menyukai detail. Setiap penambahan dan catatan. Itu saja.
Ringkasan
- Bisnis mulai memahami potensi produk, ini memungkinkan untuk dengan sangat jelas membuktikan anggaran untuk solusi teknis.
- Pengembang mulai memberikan ide-ide baru dan melihat bagaimana implementasi fitur berakhir dan bagaimana hal itu mengubah dunia.
- Tim terdekat mampu menyampaikan kepada pengembang pentingnya beberapa masalah, dan mereka dengan cepat diselesaikan.
- Tim lain menerima pengalaman dari kami dan membagikan pengalaman mereka dan kode yang kami gunakan kembali.
- Pengguna senang (kecuali untuk 1% dari lalu lintas yang terkait eksperimen tidak manusiawi).
Jadi saya memberitahu semua orang tentang apa yang terjadi di dalam produk. Secara terpisah, pertanyaan rahasia dagang muncul: laporan itu sangat mudah untuk diteruskan atau digeledah, tetapi kami mempercayai orang-orang kami. Namun, data mengalir di antara pemain pasar yang berbeda, dan jika Anda benar-benar perlu menyembunyikan sesuatu, maka laporan tersebut membuat tautan ke sumber daya internal, yang sudah memiliki lapisan otentikasi tambahan.