Tentang pesawat ruang angkasa dan ruang angkasa. Cara membuat fitur dengan mengubah seluruh produk di sepanjang jalan

Pada tanggal 24 April, perubahan penting terjadi pada platform Wrike: tim mengumumkan rilis publik fitur baru - "Spaces", dalam versi Rusia - "Spaces".
Tujuan Spaces adalah untuk meningkatkan kinerja tim di task manager dan menyederhanakan navigasi dalam produk, menjadikan proses lebih organik dan transparan. Apakah kita melakukannya? Teruslah membaca dan pelajari cara meluncurkan pembaruan serius di perusahaan besar dan tidak mengacaukannya, bagaimana memastikan interaksi 30 tim scrum dan pelajaran apa yang kami pelajari dari proses pengembangan produk, rilis yang kemudian menghabiskan banyak darah dan semangat tim terobosan.

Mengapa Spaces ditemukan?

Ketika Wrike dibuat, itu difokuskan pada pemecahan masalah efektivitas tim kecil 15-20 orang. Adalah nyaman bagi tim semacam itu untuk bekerja di satu tempat di mana ada “ruang” untuk semua orang.

Seiring waktu, ukuran akun telah meningkat beberapa kali. Sekarang produk digunakan oleh tim terdistribusi dalam akun dengan ribuan orang, dan di masa depan kita melihat Wrike sebagai alat yang nyaman untuk pekerjaan banyak departemen perusahaan: di satu sisi, bekerja dalam proses yang berbeda, di sisi lain - masih harus berinteraksi satu sama lain.

Karena di dunia nyata tim ada di kantor, kantor, dan negara yang berbeda, tim Wrike berpikir untuk menciptakan ruang khusus bagi mereka sehingga mereka dapat bekerja secara bersamaan sebagai bagian dari proses mereka dan tidak kehilangan kontak dengan departemen lain.

Spaces memungkinkan masing-masing kelompok kerja untuk secara efisien mengatur alur kerja mereka: memberi mereka alat dan struktur data yang mereka butuhkan, akses ke berbagai bentuk kueri, sehingga mereka dapat mengatur ruang kerja mereka sendiri dan bertindak lebih fokus. Spaces juga memungkinkan Anda untuk mengontrol distribusi informasi dengan lebih baik dalam tim multi-fungsi dan meningkatkan keamanan data.



Gagasan menciptakan Spaces adalah milik Sasha Plotvinov dan Van Saveliev, manajer produk Wrike. Pertama, mereka melakukan penelitian, menggambar prototipe solusi untuk tim di papan tulis, menyusun mock-up dan memvalidasi ide. Kemudian, itu diselesaikan di Wrike Hackathon , di mana mereka mengambil langkah ke samping dan merakit prototipe Ruang Pribadi yang melengkapi konsep.

“Spaces” adalah, pertama-tama, fitur untuk tim. Namun, ini didasarkan pada konsep ruang pribadi yang hidup, yang setiap orang perlu untuk mengecualikan informasi yang tidak perlu dan kebisingan yang tidak ada.

Masalah apa yang dipecahkan Spaces?

Untuk mempermudah, Wrike terdiri dari proyek dan alat untuk bekerja dengannya. Misalnya, saat mengerjakan rilis komprehensif, Anda membuat sejumlah proyek, memantau kemajuan mereka melalui bagan Gantt, mengontrol pemuatan tim menggunakan Beban Kerja, dan, berdasarkan hasilnya, membuat laporan untuk pemangku kepentingan.

Segalanya tampak sederhana, tetapi jika Anda memiliki ribuan orang yang bekerja dalam satu akun di sejumlah besar tim dengan proses yang tumpang tindih dan menggunakan banyak alat, muncul dua masalah: menjadi sulit untuk mengelola proses dan antarmuka pengguna dipenuhi dengan elemen yang tidak perlu .


<sub>adalah


telah menjadi</sub>

Rintangan semacam itu untuk kerja tim yang efektif muncul karena sejumlah alasan: pertama, di pohon folder yang sama ada banyak tim; pengguna terus-menerus melihat informasi yang tidak relevan dan secara tidak sengaja melanggar struktur tim "alien". Kedua, hanya administrator yang memiliki akses ke manajemen proses, dan struktur akun sering kali dibentuk oleh kepala manajer-administrator.

Dalam proses pengembangan Spaces, kami sampai pada dua tugas utama:

• Pengguna harus melihat hanya apa yang relevan dengannya
• Delegasi dan pengorganisasian diri harus datang ke tempat manajemen vertikal

Wrike adalah salah satu perusahaan yang percaya bahwa manajemen horizontal mengungguli organisasi vertikal dan "pirus" menunjukkan diri mereka dengan cara yang paling efisien. Pendekatan yang diterapkan dalam Spaces akan membantu tim mencapai tingkat transparansi dan swasusun baru, di mana manajemen horizontal akan berlaku.

"Jika sebelum administrator akun memiliki tanggung jawab yang tinggi untuk proses tersebut, sekarang ia akan dapat mempercayakan pengorganisasian alur kerja tim kepada atasan langsungnya, yang seringkali lebih tahu fitur-fitur timnya."

- Ivan Savelyev, Manajer Produk Wrike

Kesulitan apa yang kita hadapi?

Tentu saja, perubahan signifikan dalam produk ini mengandung risiko besar dan sejumlah kesulitan. Inilah beberapa di antaranya:

Kesulitan 1. Mengurangi risiko

Menyesuaikan akun dengan cara baru mengatur pekerjaan adalah tugas yang agak memakan waktu. Di dalam Wrike, masalahnya ditemukan segera: sebagai perusahaan dengan banyak tim dan proses, kami masuk dalam kategori pelanggan yang kami anggap sebagai audiens kami sendiri dan menggunakan produk kami setiap hari. Di dalam akun tim (lebih dari 800 orang dari semua kantor internasional), kami meluncurkan rilis dan segera menerima umpan balik dari dalam - ini membantu mempersiapkan rilis publik dan memaksimalkan risiko di muka.
Bagi mereka yang belum pernah menggunakan Wrike, pada tahap awal kami melakukan serangkaian wawancara solusi, meluncurkan pengujian menggunakan layanan UserTesting , dan juga membuat program akses awal untuk fungsi Spaces untuk pelanggan yang tertarik.

Sebelum diluncurkan ke seluruh audiens, kami juga melakukan pengujian A / B pada uji coba baru untuk memastikan bahwa paradigma navigasi baru intuitif untuk pengguna baru. Dari pengujian menjadi jelas bahwa pengguna baru berhasil mulai menggunakan produk. Kami juga mewawancarai kelompok uji dan kontrol dan menemukan bahwa di antara responden, pengguna lebih cenderung berbicara tentang pemahaman antarmuka dan kemudahan penggunaan Wrike.

Kesulitan 2. Membawa nilai solusi ke klien

Wrike memiliki banyak pelanggan yang sudah menggunakan layanan dan mengatur proses kerja mereka, sehingga ada risiko bahwa fungsionalitas baru akan enggan.

Kami meluncurkan beta pribadi untuk klien utama dan menghubungkan departemen Layanan Profesional kami ke proses.
Untuk menyampaikan masalah, dan, selanjutnya, solusinya kepada pelanggan, manajer Kesuksesan Pelanggan bersama dengan administrator akun mengidentifikasi masalah proses pengorganisasian pada tahap awal dan memberi tahu pelanggan bagaimana Spaces bisa menyelesaikannya. Dengan demikian, kami mentransmisikan nilai maksimum Spaces, yang melebihi ukuran biaya restrukturisasi. Kami tidak tiba-tiba "meluncurkan fitur", tetapi secara sistematis mempersiapkan pelanggan untuk penampilannya: Manajer Sukses Pelanggan melakukan webinar, mengajari pelanggan cara menavigasi fungsi baru, melakukan pelatihan buletin email, berbicara tentang praktik terbaik.

Kemudian, kami tidak melakukan panggilan sama sekali: klien mulai datang ke program pengujian awal sendiri dan menggunakan fitur baru.

Kesulitan 3. Satu perbaikan membutuhkan banyak perubahan

Peningkatan platform memengaruhi berbagai aspek produk, dan kami memutuskan untuk melakukan modernisasi agar tidak berdiri di satu tempat. Kami beruntung dengan tim pengembangan yang melepaskan ikatan simpul teknis yang paling luar biasa dan menemukan solusi optimal selama pengerjaan proyek. Selain itu, semua orang memahami perlunya inisiatif ini, jadi kami selalu mendapat dukungan kuat dari VP dan CEO.

Sejak awal, tim pengembangan memutuskan untuk membuat arsitektur yang terhubung secara minimal, mengubah seluruh solusi menjadi satu set komponen bisnis terpisah dan aplikasi mini yang mengintegrasikan dan berinteraksi hanya antara Workspace (produk akhir yang dilihat pengguna Wrike).

Repositori terpisah dibuat untuk komponen-komponen ini, termasuk kotak pasir. Adalah mungkin untuk tidak hanya melihat setiap komponen dalam aksi dan menunjukkannya, misalnya, dalam tinjauan sprint, tetapi juga untuk melakukan pengembangan dan pengujian penuh. Perakitan, uji coba unit, dan autotest mengambil urutan besarnya lebih sedikit daripada saat berkembang di ruang kerja yang lengkap. Ini memungkinkan pengembang untuk beralih dengan cepat, menunjukkan hasil di akhir setiap sprint, dan, jika perlu, dengan cepat membuat perubahan pada fungsionalitas dan API. Setelah beberapa waktu, langkah berikutnya diambil - penciptaan semacam "taman bermain", di mana antarmuka yang sangat disederhanakan dari produk utama dibuat, termasuk integrasi sebagian besar komponen. Ini memungkinkan kami untuk merancang dan men-debug interaksi mereka satu sama lain.

Bagaimana tim berinteraksi satu sama lain?

Wrike memiliki sekitar 30 tim scrum yang mengerjakan bagian produk mereka, yang masing-masing saat ini dipengaruhi oleh fitur, atau akan dimasukkan dalam proses dalam waktu dekat. Masalah interaksi tim selama pengembangan Spaces terkadang muncul sangat tajam - lagipula, masing-masing tim memiliki produk OKR sendiri untuk kuartal ini.

Masalah komunikasi adalah prioritas: di mana dimungkinkan untuk membahas semuanya terlebih dahulu, untuk menyetujui dan meresmikan perjanjian, interaksi ternyata lebih baik daripada dengan tim-tim yang tidak ada diskusi awal. Dalam kasus terakhir, tim pengembangan harus membuat perubahan atau memodifikasi fungsionalitas orang lain.

“Ada kasus-kasus luar biasa: sekali diperlukan untuk mengintegrasikan komponen yang agak besar dan kompleks yang dikembangkan oleh tim eksternal sebelum selesai oleh tim ini (sebagai hasilnya, itu muncul di bagian fungsionalitas kami lebih awal dari pada dasarnya). Apa yang harus dilakukan - kami mencoba menyelesaikan pekerjaan sebagai bagian dari tenggat waktu dan harus keluar. Dan waktu yang kami habiskan untuk menata semuanya setelah komponen selesai, kami harus mengolesinya dengan lapisan tipis ketika mengerjakan fitur-fitur lain - integrasi sesuai rencana sudah lama berakhir! ”

- Alexey Kartavenko, Frontend Teamlead

Jumlah masalah yang muncul ketika 30 tim berinteraksi satu sama lain dalam lingkungan yang sangat gesit seharusnya tidak mengecilkan hati. Untuk hampir semua perusahaan, mengatur proses scrum sudah merupakan suatu pencapaian, dan scrum of scrum adalah sebuah fantasi: di sini produk-ower, lead, dan pengembang biasa harus belajar cara bekerja satu sama lain.

Ini adalah tips yang diberikan oleh tim Spaces kepada mereka yang bersiap untuk membuat proyek besar:

1. Sesering mungkin, diskusikan pilihan-pilihan antara proyek dengan peserta yang berbeda dalam proses, terus-menerus mengumpulkan umpan balik dan mencari makanan tambahan untuk dipikirkan.
2. Jika apa yang Anda lakukan dapat digunakan secara internal (kami sangat beruntung dengan ini di Wrike), mulailah proyek percontohan. Gulung semua orang, beri tahu semua orang, jalankan formulir umpan balik!
3. Tentukan tingkat kesiapan di mana Anda dapat mengaktifkan fungsionalitas untuk pelanggan setia: di antara mereka selalu ada yang suka mengikuti perkembangan zaman dan mengaktifkan semua jenis fitur eksperimental. Umpan balik mereka akan sangat berharga karena mereka adalah audiens target Anda. semua mekanisme pengujian awal siap membantu Anda: percobaan A / B, peluncuran terbatas dan terkontrol versi alfa dan beta, akses Akses Awal sesuai permintaan, dll.
4. Seimbangkan antara kecepatan perkembangan dan kualitasnya, seperti di papan selancar: jangan takut untuk meninggalkan utang teknis dalam sprint saat ini, tetapi segera mulai tugas untuk menghilangkannya segera setelah situasinya menjadi jelas. Ingatlah untuk memberikan tugas-tugas ini prioritas tertinggi. Hal ini bukan pandangan pendek untuk melakukan cakupan penuh unit dan auto-test fungsional yang dapat berubah setelah umpan balik di sprint berikutnya. Selain itu, ini bukan hanya bodoh, tetapi kriminal bagi insinyur untuk meninggalkan kode sampah pada akhirnya dan membiarkannya sampai ke rilis.
5. Coba persiapkan dengan benar untuk setiap sprint berikutnya: lakukan PBR (Penyempurnaan Backlog Produk), pastikan untuk mengambil tugas dalam sprint saat ini untuk meneliti apa yang Anda rencanakan untuk dilakukan di sprint berikutnya, berbicara dengan Pemilik Produk dan perancang UX sebanyak yang Anda inginkan: mengejar mereka di dapur dan di ruang merokok, mengklarifikasi detailnya. Cobalah menyinkronkan backend, frontend, dan pengujian sedemikian rupa sehingga interaksinya "menjilat", sehingga tidak ada yang menganggur, menunggu kesiapan rekan kerja dari spesialisasi lain, sehingga Anda tidak perlu duduk di atas mok dan kemudian membuangnya, dll.
6. Lebih dekat dengan tanggal rilis, ketika gairah memanas dan sebagian besar pekerjaan sedang ditransfer dari pengembang ke insinyur QA, gantikan pundak Anda: uji sendiri kode Anda, jalankan regresi, bantu parsing, dan coba tulis autotest.
7. Saat berinteraksi dengan tim lain, mulailah diskusi rutin sebelumnya tentang bagaimana tepatnya Anda akan melakukan ini. Tuliskan semua perjanjian dan rencana, hasilkan dokumentasi, Anda bahkan dapat membuat kontrak - bukan karena seseorang akan mencoba menipu Anda dan tidak melakukan terlalu banyak, tetapi karena setiap orang memiliki hari-hari mereka sendiri dan masalah Anda hanya alien lima persen. Sinkronisasi Sprint sangat ideal, bertujuan untuk itu.
8. Saat menggunakan sesuatu yang dikembangkan oleh tim lain, berhati-hatilah dengan pernyataan bahwa "hampir semuanya siap, ambil, dan integrasikan." Pertama, Anda harus mencari tahu apakah Anda tidak ingin membuat kekacauan, dengan membabi buta mengambil apa yang mereka berikan dan membangun rencana Anda di atasnya (terutama yang kalender).
9. Dan yang paling penting: tidak ada satu pun hal yang serius dalam dunia TI yang kompleks dilakukan dengan satu klik saja, oleh karena itu, jika proyek ini dalam pengembangan untuk waktu yang lama dan mereka mulai "melihat ke samping", jaga saraf Anda dan ketahui: bahkan jika tidak hari ini, tetapi besok atau lusa, benang yang terpeleset tanpa akhir akan terjalin, kabut akan berhamburan dan kesuksesan menanti Anda - Anda percaya pada apa yang Anda lakukan, bukan?