Bagaimana Kami Mulai Merilis Fitur Dua Kali Lebih Cepat (Studi Kasus)

Saat bisnis mengandalkan aplikasi Anda untuk pekerjaan sehari-hari, Anda harus cukup gesit untuk memenuhi kebutuhan mereka dengan cepat. Jika tidak, orang lain pasti akan melakukannya. Di dunia SaaS yang tak kenal ampun, menunda fitur penting (atau mempercepat sepotong kode yang sarat bug) akan berarti kehilangan klien. Alur kerja gesit yang solid dapat membuat semua perbedaan.

Kami adalah tim di balik Active Collab , aplikasi manajemen proyek dengan serangkaian fitur yang terus berkembang dan basis pengguna yang cukup besar. Ini berarti bahwa bahkan perubahan terkecil dalam fungsionalitas akan mempengaruhi banyak orang.

Bacaan Lebih Lanjut tentang SmashingMag:

• Cara Meluncurkan Fitur Baru Tanpa Menyakiti Pengguna Setia
• Daftar Periksa Peluncuran Situs Web – 15 Pemeriksaan Penting Sebelum Anda Tayang
• Pendekatan yang Berpusat pada Pengguna Untuk Desain Web Untuk Perangkat Seluler
• Cara Meluncurkan Apa Pun
  

Oleh karena itu, proses pengembangan perlu berjalan dengan lancar dan memenuhi standar, dengan penundaan yang dikurangi seminimal mungkin. Sebelum perubahan apa pun sampai ke pengguna akhir, ia melewati lima fase penting: umpan balik, desain, pengembangan, jaminan kualitas, dan penerapan . Dalam artikel ini, saya akan membagikan apa yang telah kami pelajari (dengan cara yang sulit) tentang setiap tahapan selama lebih dari delapan tahun dalam bisnis ini.

Panggilan Bangun

Sebelum saya masuk ke rincian, mari kita lihat bagaimana semua ini terjadi. Setelah bertahun-tahun menambahkan fitur tanpa pengawasan yang cukup, aplikasi kami mengalami kelebihan fitur. Kami telah menambahkan begitu banyak fungsi selama bertahun-tahun sehingga pengguna baru terintimidasi oleh kompleksitas UI (tidak pernah kembali lagi). Kami tahu kami harus membangun kembali dari awal, bahkan jika itu berarti menulis ulang setiap fitur dari awal.

Kemudian datang penundaan. Fitur untuk versi baru selalu tertinggal dari jadwal. Misalnya, pengembang junior seharusnya mengembangkan integrasi dengan QuickBooks. Kami tidak secara akurat memprediksi kompleksitas, keterampilan, atau pengetahuan yang dibutuhkan. Plus, dia adalah satu-satunya yang ditugaskan untuk tugas itu, dan tidak ada yang bisa dengan cepat melompat untuk membantunya. Akibatnya, apa yang seharusnya menjadi pekerjaan dua minggu akhirnya mengambil lima. Itu adalah beberapa bendera merah.

Jelas sudah waktunya untuk beralih ke pendekatan yang lebih gesit. Kami mengambil apa yang kami suka dari berbagai metode gesit (dan tidak begitu gesit), menggabungkannya dengan pengalaman, dan menghasilkan versi kami sendiri, yang telah memberikan hasil yang luar biasa sejak saat itu.

Mari kita lihat lebih dekat jalan yang harus dilalui sebuah fitur sebelum ditawarkan kepada pengguna akhir.

Dari Saran Ke Fitur

Dalam alur kerja kami, fitur baru mulai terbentuk jauh sebelum mencapai tim pengembangan, dan biasanya muncul dari umpan balik pengguna. Ini bukan kebetulan — kami dulu merilis fitur yang tidak dibutuhkan siapa pun, biasanya hanya karena satu pengguna sangat berisik atau kami hanya berpikir sesuatu akan bagus untuk dimiliki. Alih-alih membayangkan fitur apa yang mungkin dibutuhkan pengguna kami, kami sekarang membuat keputusan berdasarkan permintaan yang sebenarnya.

Jika Anda menyukai lean manufacturing, Anda akan mengatakan bahwa pelanggan kami "menarik" fitur tertentu dengan memintanya lebih sering daripada yang lain. Tim dukungan dan penjualan kami adalah bagian besar dari proses karena mereka terus-menerus berhubungan dengan pengguna yang berbagi kebutuhan dan ide mereka.

Berdasarkan umpan balik, tim kami memperbarui formulir yang terlihat seperti ini:

Jika kami tidak memiliki semua informasi yang kami butuhkan, kami akan menghubungi pelanggan secara langsung. Ini biasanya dilakukan dengan survei yang ditargetkan pada sampel yang dipilih dengan cermat. Intinya kita mendengarkan. Tidak ada umpan balik yang hilang dari kami. Itu selalu diakui dan didokumentasikan.

Langkah selanjutnya adalah analisis. Kami menghitung skor setiap bulan untuk melihat fitur mana yang mendapat suara terbanyak. Juga, dengan kategorisasi yang tepat, kami mendapatkan perspektif yang lebih luas tentang bagian mana dari perangkat lunak kami yang perlu bekerja. Misalnya, jika kalender mendapat banyak keluhan, kami akan mempertimbangkan untuk memperbaiki seluruh bagian, daripada memperkenalkan fitur yang mendapat suara terbanyak (seperti mengekspor kalender).

Namun, meskipun hasilnya sudah masuk, keputusan untuk memperkenalkan fitur belum final. Sebelum masuk ke daftar tugas kami, kami selalu melakukan pemeriksaan kewarasan menyeluruh:

• Manfaat apa yang akan diberikan fitur ini kepada pengguna?
• Apakah itu sesuai dengan filosofi produk kami?
• Apakah itu akan menambah kerumitan yang tidak perlu?
• Apakah itu menyatu dengan baik dengan antarmuka dan fungsionalitas yang ada?
• Apakah kita memiliki sumber daya untuk mengirimkannya dalam jangka waktu yang wajar?

Ketika sebuah fitur lolos dari daftar periksa dan pemilik produk menyetujuinya, saatnya untuk beralih ke papan gambar.

Merancang Untuk Pengguna

Pengalaman telah mengajari kami bahwa menambahkan fitur baru tidak hanya berarti menempelkannya di atas UI — Anda harus memadukannya dengan desain yang ada, dengan mempertimbangkan pengguna. Jika Anda tidak melakukan ini, Anda akan segera berakhir dengan aplikasi yang sangat kompleks sehingga hanya sedikit yang berani yang akan berhasil melewati lima menit pertama uji coba (ya, kami pernah melakukannya). Estetika juga penting untuk kesan pertama yang baik, tetapi perhatian utama kami adalah kemudahan penggunaan . Sebuah fitur perlu ditambahkan dengan cara yang terasa alami bagi pengguna.

Kami menjaga segala sesuatunya dalam perspektif dengan bertanya, Di mana pengguna mengharapkan opsi ini?

Untuk pengguna yang sudah ada, penting bahwa desain baru mengikuti pola yang mereka kenal dan tidak mengganggu alur kerja mereka. Juga, ada standar dan konvensi industri yang kita semua (secara tidak sadar) terbiasa. Jangan pernah berharap pengguna Anda mengubah kebiasaan mereka sepenuhnya. Mereka kemungkinan besar akan mencari di tempat lain jika antarmuka tidak intuitif.

Ambil pintasan keyboard. Anda dapat membuat set pintasan Anda sendiri dan mengharapkan pengguna untuk mempelajarinya (mereka mungkin tidak akan melakukannya). Atau Anda bisa menambahkan yang sudah digunakan orang. Banyak pengguna kami sudah menggunakan Slack, misalnya, jadi kami menambahkan pintasan yang sudah mereka kenal ( Command + K untuk lompatan cepat juga berfungsi di Active Collab ).

Saat alur pengguna sudah ada, desainer UX kami mengolok-olok desain di Sketch. Kami jarang menggunakan HTML pada tahap awal. Visualisasi Sketsa yang dipikirkan dengan matang memberi kami fleksibilitas yang cukup sehingga kami tidak perlu melakukan pelacakan mundur saat memulai pengkodean. Desain awal biasanya cocok dengan sekitar 80% dari produk akhir. Sisanya ditambahkan dan disesuaikan di sepanjang jalan.

Langkah penting lainnya dari proses desain adalah menyalin. Copywriter kami mencurahkan banyak perhatian pada setiap kata. Kami bahkan memiliki panduan gaya kami sendiri, agar terdengar mudah didekati dan semudah mungkin untuk dipahami. Misalnya, mengatakan "sertifikat keamanan" alih-alih "sertifikat SSL" menyampaikan dalam istilah awam sesuatu yang mungkin tidak familiar bagi pengguna biasa.

Setelah semua ini selesai, fitur tersebut ditugaskan ke tim pengembangan. Tim ini terdiri dari manajer proyek, pengembang utama, dan sejumlah pengembang back-end dan front-end, tergantung pada beban kerja. Manajer proyek memastikan semuanya berjalan lancar dan sesuai jadwal, sementara pengembang utama menangani sisi teknis. Mereka juga mengoordinasikan dan membimbing pengembang junior.

Saatnya Memulai Sesuatu

Pertemuan awal kami bukanlah pertemuan motivasi yang membosankan. Ini adalah kesempatan bagi tim pengembangan (terdiri dari pengembang junior dan senior) untuk bertemu dengan manajer proyek dan pemilik produk.

Alih-alih membiarkan monolog kosong, kami fokus untuk menempatkan kata-kata semua orang ke dalam tugas yang dapat ditindaklanjuti. Sepanjang hari, tiga pertemuan penting berlangsung:

• Pemilik produk mempresentasikan fitur yang diberikan kepada tim, ide di baliknya, desain awal, dan hasil yang diharapkan.
• Kemudian, tim mengadakan pertemuan sendiri yang membahas rencana aksi, potensi masalah, dan jadwal pengujian.
• Pertemuan terakhir dihadiri oleh semua orang yang terlibat, dan rencana itu mengambil bentuk akhirnya. Di akhir pertemuan ini, tim memberikan perkiraan untuk demo dan tanggal jatuh tempo akhir.

Tiga pertemuan mungkin terdengar seperti banyak untuk satu hari, tetapi itulah cara kami memastikan masalah diselesaikan sejak dini. Mengisi bagian yang kosong pada tahap ini menghemat banyak waktu bagi pengembang kami, awal yang salah, dan pelacakan mundur. Pertemuan juga mendorong kerja tim dan membuat semua orang merasa bahwa kontribusi mereka disambut.

Setelah rapat, tim akan memiliki semua informasi yang diperlukan:

1. Apa? Ini adalah cakupan fitur dan mencakup semua yang perlu diselesaikan, serta potensi pemblokiran dan kemacetan. Kami mencoba mengantisipasi sebanyak mungkin skenario dan kasus tepi. Memprediksi semuanya tidak mudah; mereka sering muncul saat kita pergi.
2. Mengapa? Pemilik produk memperkirakan nilai bisnis suatu fitur dan menjelaskan mengapa itu sepadan dengan usaha. Dengan cara ini, tim mendapatkan gambaran yang jelas tentang manfaat bagi pelanggan dan produk. Motivator utama di sini adalah bahwa setiap orang harus memahami mengapa pekerjaan mereka penting dan bagaimana hal itu berkontribusi pada perusahaan secara keseluruhan.
3. Bagaimana? Dengan menguraikan langkah- langkah yang diperlukan untuk menyelesaikan sebuah fitur , kami memastikan pengembang kami tidak pernah kehilangan arah. Kami juga menetapkan harapan yang realistis dengan menambahkan tag kompleksitas. Kami memilih ukuran t-shirt — S dapat diselesaikan dalam beberapa jam, sementara XXL membutuhkan waktu berminggu-minggu atau lebih untuk menyelesaikannya.
4. WHO? Pemimpin tim bertanggung jawab untuk menyelesaikan fitur atau tugas tepat waktu dan untuk memperbarui pemilik produk tentang kemajuannya. Anggota tim lainnya ditugaskan ke subtugas mereka sendiri, sehingga sangat jelas siapa yang bertanggung jawab untuk apa. Menjaga ini setransparan mungkin membantu kita untuk melihat apakah seseorang sedang berjuang atau menyebabkan penundaan.
5. Kapan? Dengan semua yang diperhitungkan, tanggal jatuh tempo diperkirakan . Jika tugas tertunda, kami menganalisis alasannya dan menggunakan pengalaman itu di lain waktu. Dengan begitu, tenggat waktu yang terlewat menjadi kesempatan belajar dan bukan sumber stres.

Hari kickoff bisa menjadi sibuk, tetapi juga sangat bermanfaat. Semua orang memberikan ide dan komentar. Tugas berubah dari papan kosong menjadi hub untuk komentar, pengeditan, dan pembaruan. Pada akhirnya, tim pengembangan memiliki gambaran yang jelas tentang pekerjaan di depan dan landasan yang kokoh untuk dibangun.

Kami memeriksa daftar periksa ini sebelum mulai bekerja:

• fitur dijelaskan,
• langkah-langkah penyelesaian diuraikan,
• nilai bisnis yang diberikan oleh pemilik produk,
• kompleksitas yang diberikan oleh tim,
• dependensi fitur dan bug diidentifikasi,
• kriteria kinerja diidentifikasi (jika diperlukan),
• demo dijadwalkan,
• tanggal mulai dan berakhir yang ditetapkan oleh ketua tim.

Ini adalah momen ketika tugas berpindah ke kolom "Sedang berlangsung".

Saatnya pengkodean!

Kerja Sama Tim Di Layar

Pengembang kami tidak pernah bekerja sendiri — selalu merupakan upaya tim, dan sejauh ini merupakan cara paling efisien untuk merilis fitur baru. Sebelum tim diperkenalkan, pengembang (junior) akan terjebak dengan masalah dan mungkin berputar-putar selama berhari-hari (tanpa ada yang menyadarinya). Atau, jika mereka bukan tipe penyendiri, mereka akan terus-menerus mengganggu rekan kerja dan manajer.

Di sisi lain, dengan tim, kami menggabungkan orang-orang dengan keahlian dan tingkat pengalaman yang berbeda. Ini berarti bahwa setiap orang diberi serangkaian tugas yang sesuai dengan level mereka. Selain itu, senior mendapatkan manfaat dari mempelajari cara mengelola dan melatih rekan tim junior — dan junior dapat meminta bantuan. Karena ini adalah upaya tim dan semua orang bekerja menuju tujuan yang sama, pertanyaan tidak dianggap sebagai gangguan, dan tim dapat mengatasi masalah apa pun dengan lebih efisien. Tim menjadi entitas yang mengatur diri sendiri, membagi pekerjaan menjadi beberapa fase (atau sprint) dan mempresentasikan pekerjaan mereka selama demo.

Tunjukkan dan beritahu

Sesuai jadwal, tim akan melakukan demo untuk product owner. Tujuan dari demo adalah untuk menunjukkan seberapa baik kinerja fitur dalam keadaan saat ini dan di mana perlu lebih banyak polesan. Ini adalah pemeriksaan realitas yang tidak memungkinkan untuk alasan seperti, "Hanya perlu beberapa sentuhan akhir" (sentuhan yang akan memakan waktu satu bulan lagi). Juga, jika hal-hal mulai mengambil giliran yang salah, pemilik produk dapat bereaksi dengan cepat.

Pertemuan Mingguan

Kami memulai dengan pertemuan harian singkat yang dihadiri oleh semua pengembang. Setiap pengembang akan menjelaskan secara singkat apa yang sedang mereka kerjakan, masalah mereka, pemblokir mereka, dan apakah mereka membutuhkan bantuan. Segera menjadi jelas bahwa pertemuan-pertemuan ini perlu lebih fokus dan memberikan hasil yang nyata. Jadi, kami beralih ke pertemuan dengan tim individu sekitar seminggu sekali. Beginilah cara pemilik produk dan manajer proyek tetap terhubung dan semua potensi masalah ditangani di tempat.

Mengujinya

Kode telah ditulis, demo telah berhasil, semuanya tampak selesai dengan baik… sampai Anda melepaskan fitur dan melihat bahwa aplikasi mogok. Itu sebabnya setiap fitur yang kami buat melewati jaminan kualitas (Q/A). Selalu. Penguji kami dengan cermat memeriksa setiap skenario yang mungkin, memeriksa semua opsi dan menjalankan pengujian di lingkungan yang berbeda. Sebuah fitur jarang melewati Q/A pada go pertama.

Untuk meningkatkan produktivitas, kami biasanya membiarkan pengembang memulai fitur baru selama fase ini, tetapi itu hanya menghasilkan banyak fitur yang tertunda dan setengah jadi. Jadi, sekarang tim pengembangan tetap sibuk dengan mengerjakan tugas pemeliharaan kecil saat fitur mereka sedang ditinjau. Jika Q/A menemukan masalah, pengembang segera memperbaikinya dan mengirimkan kembali. Proses ini diulangi hingga fitur lolos Q/A dan beralih ke tinjauan kode.

Ini adalah saat pengembang senior memastikan kode ditulis sesuai dengan standar kami. Satu langkah terakhir sebelum rilis adalah menulis dokumentasi — Anda tidak ingin dibanjiri oleh email dukungan setelah merilis fitur yang tidak ada yang tahu cara menggunakannya. Copywriter kami juga memperbarui catatan rilis dan menulis materi pemasaran, seperti pengumuman email dan posting blog.

Berikut definisi kami tentang "selesai":

• tes otomatis tertulis,
• Q/A selesai dan semua tugas yang dihasilkan selesai,
• tinjauan kode selesai dan kode digabung menjadi master,
• catatan rilis diperbarui,
• dependensi fitur dan bug diidentifikasi.

Tugas telah mencapai tahap akhir, yang disebut "Rilis Q."

Hari Rilis

Saat memilih hari untuk rilis baru, kami langsung memutuskan pada hari Jumat dan Senin. Jumat tidak baik karena masalah potensial tidak akan terselesaikan sampai hari Senin; ditambah lagi, tim pendukung sudah cukup sibuk saat itu. Senin bukanlah waktu terbaik karena setiap pembaruan besar memerlukan persiapan, yang harus dilakukan pada akhir pekan. Itu selalu baik untuk meninggalkan satu hari untuk sentuhan akhir. Ini mempersempit opsi menjadi tiga hari — dan kami melanjutkan dengan hari Selasa. Inilah alasannya:

• Kami memiliki hari Senin untuk meninjau rilis dan menambahkan sentuhan akhir sebelum menerapkan.
• Jika ada frasa yang belum diterjemahkan (aplikasi web kami tersedia dalam tujuh bahasa), kami memiliki cukup waktu untuk menyelesaikan terjemahan.
• Tim pemasaran memiliki banyak waktu untuk mengirimkan buletin dan pengumuman melalui media sosial.
• Kami tersedia untuk memberikan dukungan peningkatan dengan cepat dan efisien selama sisa minggu ini.
• Jika tenggat waktu telah berlalu karena alasan apa pun, kami masih memiliki hari Rabu atau Kamis untuk menyelesaikan pekerjaan.

Hari Aktivitas Gratis

Sehari setelah rilis besar adalah hari bebas untuk tim. Ini adalah saat mereka mempelajari keterampilan baru atau melakukan sesuatu yang berhubungan dengan pekerjaan yang menurut mereka menarik. Meskipun semua orang ingin tahu fitur mana yang akan kami luncurkan keesokan harinya, tim belum membahasnya dulu. Sebagai gantinya, mereka akan bersantai dan mungkin menonton presentasi tentang sejarah Erlang, atau menyelesaikan membaca artikel tentang mengapa PSR-7 dan middleware penting untuk pengembangan PHP modern, atau memiliki diskusi retrospektif mereka sendiri. Ini adalah hari yang layak untuk mengisi ulang baterai mereka dan merayakan pekerjaan yang dilakukan dengan baik.

Hari Perburuan Serangga

Selain mengembangkan fitur baru yang utama, selalu ada pekerjaan yang harus dilakukan pada fitur yang sudah ada. Baik itu perbaikan bug, pembaruan desain, atau perubahan kecil dalam fungsionalitas, tim perlu menanganinya dalam waktu yang wajar.

Inilah sebabnya mengapa kami memiliki hari berburu serangga setidaknya sebulan sekali. Saat itulah semua pengembang berhenti mengerjakan proyek utama mereka dan mengalihkan perhatian mereka ke pemeliharaan. Upaya terfokus ini telah terbukti sukses besar. Ketika semua orang hanya bekerja pada bug pada hari yang sama dan tersedia untuk saling membantu, tim memecahkan sejumlah besar masalah.

Apa hasilnya?

Merilis fitur besar sekarang memakan waktu rata-rata sekitar tiga minggu, dari awal hingga pengembangan, pengujian, tinjauan kode, dokumentasi, dan rilis final. Sebuah fitur dengan kompleksitas yang setara yang digunakan untuk membawa kita 45 hari. Dari sudut pandang kami, itu adalah peningkatan 100% dalam produktivitas . Kami menyelesaikannya dengan sumber daya dan orang yang sama, satu-satunya perbedaan adalah alur kerja yang ditingkatkan.

Jadi, jika kami memiliki satu kesimpulan untuk Anda, ini dia: Memelihara budaya perusahaan yang menghilangkan rasa takut akan perubahan akan membuat tim Anda lebih baik dalam melakukan apa yang dilakukannya. Apakah Anda menyebutnya Scrum, Kanban atau Lean tidak masalah, selama itu membantu perusahaan Anda tumbuh. Eksperimen dan inovasi terletak di jantung pendekatan tangkas apa pun. Jangan takut untuk menguji solusi yang berbeda, mengukur hasil dan, berdasarkan hasil, memodifikasi praktik yang ada. Hasil yang baik akan mengikuti.