Pengembangan produk adalah proses yang melelahkan. Pasar terus membutuhkan solusi baru, tetapi kegagalan menunggu perusahaan mana pun di jalur penciptaan inovasi. Dalam artikel ini, kami telah mengumpulkan pengalaman kami sendiri
dalam layanan teknologi tinggi untuk mencoba mencari tahu masalah apa yang mungkin timbul ketika mengembangkan produk baru dan bagaimana cara menghindarinya.
1. Lupakan prosesnya, bekerjalah untuk hasilnya
Ketika mengembangkan suatu produk, perusahaan seringkali mencurahkan seluruh perhatian dan sumber dayanya untuk proses penciptaan dan produksi. Bahkan jika setiap tahap pekerjaan dilakukan "secara ketat sesuai dengan teknologi", hasilnya mungkin tidak semerah kelihatannya di awal.
Studi kasusTiga bulan lalu, tim Rookee memperkenalkan proses analisis sistem yang canggih. Analis harus meminta dan mengumpulkan riset pemasaran, menyiapkan opsi solusi, meminta perhitungan keuangan, merancang algoritma, menetapkan tugas untuk UX, menentukan persyaratan bisnis, melindungi keputusannya, melacak hasilnya setelah perhitungan, mentransfernya ke operasi, dll. Beban pada satu analis bisa mencapai 15 tugas per hari. Secara fisik, seorang spesialis tidak dapat melewati begitu banyak tugas yang beragam per hari. Tidak mengherankan bahwa dengan volume seperti itu, pekerjaan analis adalah leher sempit dalam memecahkan masalah umum. Untuk meningkatkan efisiensi, banyak hal berputar. Akibatnya, perusahaan meninggalkan proses yang rumit dan secara radikal menyederhanakannya, mendistribusikan tanggung jawab di antara para spesialis yang berbeda. Efisiensi meningkat, dan proses analitik mulai terjadi lebih cepat.Bagaimana cara menghindarinyaJika proses pengembangan produk terlalu rumit dan hasilnya tidak memenuhi harapan, perlu untuk meninjau proses saat ini dan menjadi lebih fleksibel dengan perubahan pada setiap tahap pekerjaan.
2. Jaga agar sinkronisasi perintah tetap tinggi
Kemampuan untuk bekerja dalam tim adalah keterampilan penting yang tidak dimiliki semua orang. Dalam praktiknya, situasi sering muncul ketika pelaksanaan satu tugas membutuhkan keterlibatan beberapa spesialis sekaligus.
Sebagai contoh, tugas memperkenalkan kode promosi ke dalam sistem menyiratkan pekerjaan baik dari pengembang front-end dan backend. Jika orang-orang ini tidak dapat sepakat di antara mereka sendiri, berbagai masalah dapat muncul. Misalnya, dari sudut pandang visual, tugas akan dilakukan, tetapi tanpa algoritma untuk mengembangkan mekanisme kode promosi, tugas ini tidak akan memberikan nilai apa pun.
Studi kasusKetika beberapa produk berbeda muncul di layanan kami, tim pengembangan untuk setiap produk tetap menjadi milik mereka. Satu pengguna, satu akun, dan produk serta tim berbeda. Entah bagaimana, seorang klien memanggil kami dan mengatakan bahwa kami telah mengecamnya. Ternyata semua tim mengiriminya surat ketika ada situasi yang membutuhkan perhatian (misalnya, keseimbangan mendekati nol dan layanan dapat ditangguhkan). Akibatnya, pengguna menerima sekitar 40 surat dari layanan per minggu. Analisis newsletter email dilakukan. Beberapa huruf digabungkan. Sekarang kami sedang mengerjakan strategi email yang akhirnya akan memperbaiki semua kekurangannya.Bagaimana cara menghindarinyaUntuk mencapai sinkronisasi antar tugas, koordinasikan tindakan tim / tim yang bekerja pada produk yang sama. Misalnya, melakukan "Demo" umum desain dan pengembangan, beri tahu tim lain tentang fitur baru. Buat dokumen yang tersedia untuk umum dengan riwayat rilis yang dengan jelas menjelaskan apa, kapan, dan apa yang dilakukan tim, menambahkan tautan ke tugas di pelacak tugas.
3. Hindari peningkatan produk sebagaimana diminta oleh pengguna.
Produk baru telah mengidentifikasi masalah selama operasi. Bukan rahasia lagi bahwa beberapa perbaikan pada proyek diprakarsai oleh pengguna yang menghubungi layanan dukungan. Tidak ada yang berpendapat: produk perlu ditingkatkan, tetapi sebelum bergegas untuk "menambal lubang", Anda harus mencari akar penyebab masalah.
Kumpulkan permintaan pengguna untuk jangka waktu yang cukup. Tergantung pada jumlah panggilan ke layanan dukungan, periode ini dapat berupa satu minggu atau satu bulan atau lebih. Menganalisis masalah, mengidentifikasi masalah berulang dan memecahkan masalah yang paling sering dikeluhkan pengguna. Jika masalah tersebut memblokir di alam, yaitu, itu mempengaruhi operasi yang benar dari pengguna dalam sistem, segera selesaikan.
4. Undang pengembang untuk mendiskusikan tugas proyek dan desain
Seringkali, setelah menerima persyaratan bisnis pelanggan, perancang melanjutkan untuk menggambarkan logika tugas. Jika Anda tidak mempertimbangkan fitur teknis sistem, Anda mungkin mendapatkan solusi yang akan menghasilkan pengembangan selama 3 bulan.
Studi kasusSetelah di Rookee , sebuah situasi terjadi. Mereka menggambar antarmuka di mana ada wizard untuk membuat proyek di salah satu produk: pada langkah pertama, pengguna masuk ke layanan lain untuk mendapatkan informasi darinya (di Yandex.Direct), pada langkah kedua, daftar parameter untuk pekerjaan dipilih. Parameter diperoleh dengan mengeksekusi permintaan token yang ditentukan pada langkah pertama.
Antarmuka ditunjukkan kepada pelanggan, disetujui, dikirim ke pengembang. Ketika pengembang melihat ini, mereka berkata: "Di sini Anda harus menunjukkan film, karena jika pengguna memiliki banyak data, maka dia bisa menunggu waktu yang sangat lama. Selain itu, solusi front-end ini tidak ramah pengguna. "
Akibatnya, saya harus mengulang semuanya, mengingat umpan balik dari para programmer.Bagaimana cara menghindarinyaUndang pengembang untuk berpartisipasi dalam diskusi proyek, menyusun persyaratan, melibatkan mereka dalam desain. Dengan memasukkan pengembang ke dalam pekerjaan pada tahap awal, Anda dapat secara signifikan mengurangi waktu yang diperlukan untuk membuat proyek, menghindari biaya pengerjaan ulang yang tidak perlu, dan melakukannya tanpa rambut beruban tambahan karena tenggat waktu yang terlewat.
5. Sederhanakan. Cemerlang, saat efektif
Secara berkala, spesialis komersial muncul dengan ide-ide cemerlang ketika membuat produk baru atau menyelesaikan yang lama. Sayangnya, tidak semua yang cerdik dibutuhkan dan dapat direalisasikan.
Studi kasusUntuk meningkatkan penjualan, sering menggunakan strategi email hak cipta. Ada banyak cara untuk mengimplementasikannya: mengatur pengiriman acara, layanan buletin email pihak ketiga yang mengirim email atas sinyal layanan Anda, menerapkan logika pemicu tunggal di sisi layanan Anda dan menggunakan templat standar atau universal untuk pengiriman surat, dll.
Terkadang perusahaan memutuskan untuk menempuh jalannya sendiri dan tidak menyukai orang lain. Saat menulis surat pertama untuk pengguna di tim, mereka pikir itu akan menjadi yang terakhir. Dan kemudian mereka mengirim surat terakhir. Dan banyak lagi ... Ketika ada banyak surat, tim menerapkan layanannya untuk membuat template. Itu dilakukan selama 2 bulan dan tidak sebagus layanan khusus yang ada. Akibatnya, perusahaan datang dengan solusi optimal - terintegrasi layanan pengiriman pihak ketiga.Bagaimana cara menghindarinyaJika implementasi inovasi tampaknya terlalu rumit, buang saja.
Jangan buang waktu untuk membuat layanan yang jelas akan hilang dari layanan yang sudah ada. Jawab pertanyaan Anda, apakah Anda benar-benar membutuhkan alat yang sulit dirawat, tetapi milik Anda sendiri?
6. Hindari interpretasi persyaratan yang ambigu
Tugas yang diajukan secara ambigu menciptakan kesalahpahaman yang dapat menyebabkan hasil yang tidak diinginkan. Misalnya, seorang analis mungkin bertanya: "Tambahkan lima gajah di sebelah bidang pendaftaran." Untuk anggota tim yang berbeda, begitu saja mungkin ada versi yang berbeda dari "di sebelah" ini: kanan, kiri, atas dan bawah.
Jika persyaratannya tidak sepenuhnya dipahami, pertanyaan klarifikasi harus diajukan. Anggota tim harus belajar cara memaksimalkan detail setiap tugas untuk menghindari kebingungan dan pemikiran. Tingkat perincian persyaratan dibahas dalam tim. Anda juga dapat mengembangkan template TK yang sesuai untuk semua orang, dan menuliskan tujuan tugas, logika, dan antarmuka pengguna di dalamnya sedetail mungkin.
7. Ingat audiens target.
Cukup aneh, ada orang yang percaya: lebih baik menarik sebanyak mungkin pengguna, dan di antara mereka pasti akan ada target audiens produk. Ini tidak benar. Anda mungkin memiliki produk tertentu yang konsumennya adalah segmen pengguna tertentu.
Studi kasusTarget pengguna produk ini adalah ibu rumah tangga, tetapi proyek ini ingin mendapatkan banyak lalu lintas. Setelah menghabiskan banyak uang untuk iklan, perusahaan mulai menerbitkan spanduk yang ambigu pada portal bisnis besar dengan harapan membawa pelanggan pelarut. Lalu lintas telah meningkat secara dramatis, tetapi penjualan belum. Ketika kami melakukan survei tentang mengapa pengguna mengunjungi situs dan tidak membeli apa pun, ternyata sebagian besar dari mereka bukan audiens target. Produk yang diusulkan sama sekali tidak menarik bagi mereka. Perubahan dilakukan pada kampanye iklan, dan masalah teratasi setelah beberapa waktu.Bagaimana cara menghindarinyaPada awalnya, lebih baik memfokuskan upaya Anda untuk menarik lalu lintas bertarget dan melakukan penyesuaian kampanye iklan dan penentuan posisi jika pengunjung situs jelas bukan pelanggan potensial Anda.
8. Hindari perpotongan tes split saat menguji hipotesis
Masalah seperti itu dapat muncul jika hipotesis tidak direncanakan dengan baik atau analis tidak memiliki kualifikasi yang baik.
Studi kasusPerusahaan mulai menguji dua versi formulir pendaftaran pada halaman arahan (50% pengguna melihat satu versi, 50% melihat yang lain). Maka menjadi perlu untuk menguji hipotesis lain di bidang pembayaran, dan tes lain diluncurkan. Ini mempersulit pekerjaan analis, karena butuh waktu lama untuk membagi kohort sedemikian rupa untuk menilai dampak perubahan pada tindakan akhir pengguna. Butuh waktu lebih lama untuk mengumpulkan data daripada yang diperlukan saat melakukan tes satu demi satu.Bagaimana cara menghindarinyaSaat melakukan tes A / B, jangan biarkan perpecahan berpotongan. Coba pisahkan pengguna sehingga satu orang berpartisipasi hanya dalam satu percobaan. Jika tiba-tiba Anda masih menjalankan dua tes sekaligus, evaluasi 4 kelompok:
- versi pertama pendaratan + opsi pertama di area pembayaran;
- versi pertama pendaratan + opsi kedua di area pembayaran;
- opsi pendaratan kedua + opsi pertama di zona pembayaran;
- opsi pendaratan kedua + opsi kedua di zona pembayaran.
9. Jangan bingung pendapat Anda dengan pendapat pengguna
Salah satu kesalahan umum adalah pengadopsian opini seseorang untuk pendapat pengguna. Jika Anda menyukai produk, desain, dan kegunaannya, Anda memahami cara berinteraksi dengannya, bukan fakta bahwa pengguna akan berbagi antusiasme Anda.
Saat mengembangkan setiap zona antarmuka yang terpisah, pertimbangkan visual dari seluruh layanan secara keseluruhan. Jangan berpikir untuk pengguna. Tanyakan padanya (misalnya, menggunakan metode kelompok fokus) bagaimana dia lebih nyaman, lebih akrab, lebih baik daripada apa yang dia harapkan dari produk baru. Sebelum meluncurkan produk, Yandex melakukan tes tatap muka: bertemu dengan pengguna, melihat reaksi mereka, mengajukan pertanyaan tidak nyaman pada hipotesisnya.
Jika Anda tahu sebelumnya pendapat pengguna tentang pengembangan, Anda dapat menghindari banyak masalah di masa depan.
10. Log peristiwa ke maksimum
Jika ada situasi kontroversial dalam pengoperasian modul sistem apa pun, lebih cepat dan lebih mudah untuk beralih ke log peristiwa. Kecuali, tentu saja. Jika Anda malas dan tidak mencatat peristiwa, Anda harus bekerja keras untuk menemukan sumber utama masalah saat itu terjadi.
Bagaimana cara menghindarinyaLog peristiwa ke maksimum. Ini tidak berarti bahwa Anda harus mulai mencatat setiap detail kecil, seperti gerakan pengguna dengan mouse, tetapi informasi dasar yang terjadi dengan objek harus direkam.
Kesimpulan
Perusahaan mana pun dapat mengalami masalah ketika mengembangkan produk baru. Hal utama adalah mengakui kesalahan, menarik kesimpulan, dan mengambil tindakan agar tidak terjadi lagi di masa depan.
Dan dalam praktik pengembangan Anda, kegagalan terjadi dan bagaimana Anda menghadapinya? Ceritakan tentang pengalaman Anda di komentar.
Diposting oleh Ekaterina Hindikainen, Lead System Analyst,
Rookee Service