Kolaborasi Lebih Baik Dengan Membawa Desainer Ke Dalam Proses Peninjauan Kode

Diterbitkan: 2022-03-10

Ringkasan cepat Melibatkan orang lain sejak dini — terutama orang-orang dari disiplin ilmu lain — dapat terasa menakutkan. Dengan mengambil inspirasi dari ulasan kode, kami dapat meningkatkan kolaborasi baik dalam bidang kami sendiri maupun lintas disiplin, baik itu desain, UX, konten, atau pengembangan.

Kolaborasi yang lancar antara pengembang dan desainer adalah sesuatu yang dicita-citakan semua orang, tetapi ini sangat sulit. Namun dengan web canggih saat ini, sulit — jika bukan tidak mungkin — untuk membangun produk yang benar-benar hebat tanpa berkolaborasi lintas disiplin. Karena berbagai teknologi yang diperlukan untuk membangun suatu produk, produk hanya dapat benar-benar berhasil ketika semua disiplin ilmu — pengembang dan desainer, pembuat konten, dan ahli strategi pengalaman pengguna — terlibat secara mendalam sejak tahap awal proyek. Ketika ini terjadi, semua ujung dari apa yang diperlukan untuk membangun sebuah produk datang secara alami menjadi satu kesatuan yang utuh, dan dengan demikian menjadi produk yang hebat.

Karena itu, tidak ada yang benar-benar mempromosikan proses air terjun lagi. Namun, melibatkan orang lain sejak dini, terutama orang dari disiplin ilmu lain, bisa terasa menakutkan. Dalam skenario kasus terburuk, itu mengarah pada "desain oleh komite."

Selain itu, baik desainer maupun ahli strategi konten sering kali memiliki latar belakang di bidang di mana satu-satunya jenius kreatif masih ideal. Memiliki orang lain yang membuktikan pekerjaan Anda bisa terasa seperti ancaman bagi kreativitas Anda.

Jadi bagaimana Anda bisa melibatkan orang sejak dini sehingga Anda menghindari air terjun, tetapi juga memastikan bahwa Anda tidak menyiapkan diri untuk desain oleh panitia? Saya menemukan jawaban saya ketika belajar tentang ulasan kode.

Lebih banyak setelah melompat! Lanjutkan membaca di bawah ini

Aha! Momen

Pada Juli 2017, saya mendirikan Confrere bersama dengan dua pengembang, dan kami dengan cepat merekrut insinyur pertama kami (saya sendiri bukan pengembang, saya lebih sebagai UX atau perancang konten). Kolaborasi kami berjalan sangat lancar, sedemikian rupa sehingga pada retrospektif kami, tema yang berulang adalah bahwa kami semua merasa bahwa kami "melakukannya dengan benar."

Tiga orang tersenyum dan duduk bersebelahan di sekitar komputer. Dari kiri ke kanan, mereka adalah Dag-Inge (CTO), Ida (CPO) dan Ingvild (Sr. Engineer). — Dag-Inge (CTO), saya sendiri (CPO) dan Ingvild (Sr. Engineer). (Pratinjau besar)

Saya duduk bersama rekan-rekan saya untuk mencoba menunjukkan dengan tepat apa sebenarnya yang kami "lakukan dengan benar" sehingga kami dapat mencoba mempertahankan perasaan itu bahkan ketika perusahaan kami tumbuh dan tim kami berkembang. Kami menyadari bahwa kami semua menghargai bahwa seluruh tim terlibat sejak awal dan bahwa kami jujur dan jelas dalam memberikan masukan satu sama lain. CTO kami Dag-Inge menambahkan: “Ini berhasil karena kami melakukannya sebagai rekan. Anda tidak sedang dicaci maki dan hanya mendapatkan daftar kesalahan”.

Kata "rekan" adalah apa yang memberi saya momen aha. Saya menyadari bahwa kita yang bekerja dalam UX, desain, dan konten harus banyak belajar dari pengembang dalam hal kolaborasi.

Peninjauan sejawat dalam bentuk tinjauan kode sangat penting untuk bagaimana perangkat lunak dibangun. Bagi saya, ulasan kode menawarkan inspirasi untuk meningkatkan kolaborasi dalam bidang kita sendiri, tetapi juga model untuk berkolaborasi lintas bidang dan disiplin.

Jika Anda sudah terbiasa dengan ulasan kode, silakan lewati bagian berikutnya.

Apa Itu Tinjauan Kode?

Review kode dapat dilakukan dengan berbagai cara. Saat ini, bentuk paling umum dari tinjauan kode terjadi dengan cara yang disebut permintaan tarik (menggunakan teknologi yang disebut git). Seperti yang diilustrasikan di bawah, pull request memberi tahu orang lain dalam tim bahwa pengembang telah menyelesaikan kode yang ingin mereka gabungkan dengan basis kode utama. Ini juga memungkinkan tim untuk meninjau kode: mereka memberikan umpan balik tentang kode sebelum digabungkan, jika perlu perbaikan.

Permintaan tarik memiliki peran yang jelas: ada penulis dan pengulas.

Ingvild dan Dag-Inge duduk bersebelahan dan tersenyum. Sebuah panah menunjukkan bahwa Ingvild telah mengirim kode ke Dag-Inge. — Ingvild (penulis) meminta ulasan dari Dag-Inge (pengulas). (Pratinjau besar)

Sebagai contoh, katakanlah insinyur senior kami Ingvild telah membuat perubahan pada alur pendaftaran Confrere. Sebelum digabungkan ke dalam basis kode utama dan dikirim, dia (penulis) membuat permintaan tarik untuk meminta peninjauan dari CTO Dag-Inge (pengulas) kami. Dia tidak akan membuat perubahan apa pun pada kodenya, hanya menambahkan komentarnya.

Ingvild dan Dag-Inge diatur bersebelahan. Sebuah panah menunjukkan bahwa Dag-Inge telah mengirim komentar pada kode kembali ke Ingvild. — Komentar Dag-Inge pada kode Ingvild. (Pratinjau besar)

Terserah Ingvild bagaimana dia ingin bertindak atas umpan balik yang dia terima di ulasan. Dia akan memperbarui permintaan tariknya dengan perubahan yang dia anggap cocok.

Ingvild dan Dag-Inge duduk bersebelahan. Sebuah panah menunjukkan bahwa Ingvild mengirimkan kembali kodenya ke Dag-Inge, setelah melihat kode yang dia komentari. — Ingvild memperbarui kodenya dengan perubahan yang menurutnya sesuai dengan komentar Dag-Inge. (Pratinjau besar)

Saat peninjau menyetujui permintaan tarik, Ingvild kemudian dapat menggabungkan perubahannya dengan basis kode utama.

Ingvild dan Dag-Inge duduk bersebelahan. Acungan jempol ditampilkan pada ulasan kode yang telah dikirim Dag-Inge ke Ingvild. Dan panah menunjukkan dia mendorong kode ini ke repositori utama. — Setelah Dag-Inge mengacungkan jempol, Ingvild dapat mendorong perbaikan ke produksi. (Pratinjau besar)

Mengapa Repot Melakukan Review Kode?

Jika Anda belum pernah melakukan review kode, proses di atas mungkin terdengar birokratis. Jika Anda ragu, inilah banyak posting blog dan penelitian akademis tentang keuntungan dari tinjauan kode.

Tinjauan kode mengatur nada untuk seluruh perusahaan bahwa semua yang kami lakukan harus terbuka untuk pengawasan dari orang lain, dan bahwa pengawasan seperti itu harus menjadi bagian yang disambut baik dari alur kerja Anda daripada dipandang sebagai ancaman.

— Bruce Johnson, salah satu pendiri Full Story

Peninjauan kode mengurangi risiko. Memiliki seseorang yang membuktikan pekerjaan Anda, dan juga mengetahui seseorang akan membuktikan pekerjaan Anda, membantu menghilangkan kesalahan dan meningkatkan kualitas. Selain itu, ini memastikan konsistensi dan membantu setiap anggota tim membiasakan diri dengan lebih banyak basis kode.

Jika dilakukan dengan benar, tinjauan kode juga membangun budaya untuk kolaborasi dan keterbukaan. Mencoba memahami dan mengkritik pekerjaan orang lain adalah cara terbaik untuk belajar, dan juga mendapatkan umpan balik yang jujur tentang pekerjaan Anda.

Selalu meminta setidaknya dua orang melihat kode juga membatasi ide kode "saya" dan kode "Anda". Ini kode kami .

Mempertimbangkan keuntungan ini, ulasan tidak boleh hanya untuk kode.

Tinjau Prinsip Untuk Semua Disiplin, Bukan Hanya Kode

Dengan ulasan, selalu ada satu penulis dan satu atau lebih pengulas. Artinya, Anda bisa melibatkan orang sejak dini tanpa harus terjerumus ke dalam rancangan panitia.

Pertama, saya harus menyebutkan dua faktor penting yang akan mempengaruhi kemampuan tim Anda untuk melakukan tinjauan yang bermanfaat. Anda tidak harus menguasainya, tetapi minimal, Anda harus bercita-cita sebagai berikut:

Anda dan rekan kerja saling menghormati dan disiplin satu sama lain.
Anda cukup percaya diri dalam peran Anda sendiri sehingga Anda merasa dapat memberi dan menerima kritik (ini juga terkait dengan keamanan psikologis tim).

Meskipun kami tidak meninjau kode, ada banyak hal yang dapat dipelajari dari praktik terbaik yang ada untuk tinjauan kode.

Dalam tim kami, kami mencoba untuk mematuhi prinsip-prinsip berikut saat melakukan tinjauan:

Kritik karya, bukan penulisnya.
Bersikaplah kritis, tetapi tetap ramah dan ingin tahu.
Bedakan antara a) Saran b) Persyaratan, c) Hal-hal yang perlu didiskusikan atau diklarifikasi.
Pindahkan diskusi dari teks ke tatap muka. (Jumlah video)
Jangan lupa untuk memuji bagian yang bagus! Apa yang pintar, kreatif, solid, orisinal, lucu, bagus, dan sebagainya?

Prinsip-prinsip ini tidak benar-benar ditulis sampai setelah kami membahas mengapa kolaborasi kami bekerja dengan sangat baik. Kami semua merasa bahwa kami diizinkan dan diharapkan untuk mengajukan pertanyaan dan menyarankan perbaikan, dan bahwa motivasi kami selalu tentang membangun sesuatu yang hebat bersama, dan bukan tentang mengkritik orang lain.

Karena kami jelas tentang umpan balik seperti apa yang kami berikan, dan juga ingat untuk saling memuji pekerjaan baik satu sama lain, melakukan ulasan adalah kekuatan positif daripada demotivasi.

Sebuah contoh

Untuk memberi Anda gambaran tentang bagaimana tim kami menggunakan ulasan lintas disiplin dan selama proses, mari kita lihat bagaimana anggota tim kami yang berbeda beralih antara peran penulis dan peninjau saat kami membuat alur pendaftaran kami.

Langkah 1: Pengumpulan persyaratan

Pengarang: Ida (UX)

Reviewer: Svein (strategi), Dag-Inge (engineering), Ingvild (engineering).

Papan tulis menunjukkan sketsa kasar formulir pendaftaran. Seorang pria (Svein) dan seorang wanita (Ingvild) tersenyum dan berdiskusi. — Tim berkumpul di sekitar papan tulis. Svein (CEO) ke kiri, Ingvild (Sr. Eng), ke kanan. (Pratinjau besar)

Sesi papan tulis bisa melelahkan jika tidak ada strukturnya. Untuk menjaga produktivitas dan kreativitas, kami menggunakan struktur penulis/peninjau, bahkan untuk sesuatu yang tampaknya mendasar seperti curah pendapat di papan tulis. Dalam hal ini, di mana kami datang dengan persyaratan untuk alur pendaftaran kami, saya harus menjadi penulis, dan anggota tim lainnya memberikan umpan balik mereka dan bertindak sebagai peninjau. Karena mereka juga tahu bahwa mereka dapat meninjau apa yang saya buat di langkah 2 (lebih banyak kesempatan untuk penyesuaian, saran, dan peningkatan), kami bekerja dengan cepat dan dapat menyetujui persyaratan dalam waktu kurang dari 2 jam.

Langkah 2: Mockup dengan mikrokopi

Pengarang: Ida (UX)

Pengulas: Ingvild (teknik), Eivind (desain), Svein (strategi).

Tangkapan layar dari Google Doc yang mengejek formulir pendaftaran dengan komentar dari anggota tim Ingvild dan Ida. — Dengan mengejek di Google docs, mudah bagi orang-orang dari semua disiplin ilmu untuk memberikan umpan balik sejak dini. (Pratinjau besar)

Sebagai penulis, saya membuat mockup alur pendaftaran dengan mikroskop. Apakah alur pendaftaran masuk akal, baik dari perspektif pengguna maupun teknik? Dan bagaimana kita bisa meningkatkan aliran dari perspektif desain dan frontend? Pada tahap ini, sangat penting untuk bekerja dalam format yang memudahkan semua disiplin ilmu untuk memberikan umpan balik (kami memilih Google Documents, tetapi juga dapat dilakukan dengan alat seperti InvisionApp).

Langkah 3: Menerapkan alur pendaftaran

Pengarang: Ingvild (teknik)

Reviewer: Ida (UX) dan Dag-Inge (teknik).

Kami telah menyetujui alur, bidang input, dan salinannya, jadi terserah Ingvild untuk mengimplementasikannya. Berkat Surge, kami dapat secara otomatis membuat URL pratinjau dari perubahan sehingga orang yang tidak dapat membaca kode dapat memberikan umpan balik pada tahap ini juga.

Langkah 4: Pengujian pengguna

Pengarang: Ida (UX)

Peninjau: Para pengguna.

Dua wanita (Ida dan seorang pengguna) duduk bersebelahan di depan laptop. — Ida melakukan pengujian pengguna dengan anggaran kecil. (Pratinjau besar)

Ya, kami menganggap pengujian pengguna sebagai bentuk ulasan. Kami menghadirkan alur pendaftaran yang baru dibangun secara langsung dengan pengguna sebenarnya. Langkah ini memberi kami banyak wawasan, dan sebagai hasilnya, perubahan paling signifikan dalam alur pendaftaran kami terjadi.

Langkah 5: Desain

Pengarang: Eivind (desain)

Pengulas: Ingvild (teknik) dan Ida (UX).

Tangkapan layar dari Slack. Eivind, sang desainer, telah memposting tangkapan layar, dan Ida membalas dengan antusias. — Versi pertama dari alur pendaftaran didasarkan pada komponen desain yang ada. Pada tahap ini, Eivind mengembangkan beberapa komponen baru untuk membantu menyempurnakan desain. (Pratinjau besar)

Ketika desain tiba-tiba muncul di sini pada langkah 5, mungkin terlihat seperti proses air terjun. Namun, desainer kami Eivind telah terlibat sebagai peninjau sejak langkah 2. Dia memberikan banyak umpan balik yang berguna pada tahap itu dan juga dapat mulai berpikir tentang bagaimana kami dapat meningkatkan desain alur pendaftaran di luar modul yang ada dalam sistem desain kami. Pada langkah ini, Eivind juga dapat membantu memecahkan beberapa masalah yang kami identifikasi dalam pengujian pengguna.

Langkah 6: Implementasi

Pengarang: Ingvild (teknik)

Reviewer: Eivind (desain), Ida (UX) dan Dag-Inge (teknik).

Dan kemudian kita kembali ke implementasi.

Mengapa ulasan berhasil?

Singkatnya, selalu ada hanya satu penulis, sehingga menghindari desain oleh panitia. Dengan melibatkan berbagai disiplin ilmu sebagai reviewer sejak dini, kita menghindari proses waterfall.

Orang-orang dapat menandai kekhawatiran mereka lebih awal dan juga mulai memikirkan bagaimana mereka dapat berkontribusi di kemudian hari. Peran yang didefinisikan dengan jelas menjaga proses tetap pada jalurnya.

Panduan Tinjauan Reguler

Mengambil inspirasi dari panduan kode, kami juga melakukan penelusuran ulasan reguler dengan fokus berbeda, dipandu oleh prinsip-prinsip berikut:

Pengarahan dilakukan bersama-sama.
Satu orang bertanggung jawab untuk meninjau dan mendokumentasikan.
Idenya adalah untuk mengidentifikasi masalah , tidak harus menyelesaikannya.
Pilih format yang memberikan konteks sebanyak mungkin, sehingga mudah untuk menindaklanjuti temuan nanti (misalnya InvisionApp untuk tinjauan visual, Google Documents untuk teks, dan sebagainya).

Kami telah melakukan tinjauan penelusuran untuk hal-hal seperti audit aksesibilitas, meninjau permintaan fitur, mengaudit implementasi desain, dan melakukan evaluasi kegunaan heuristik.

Saat kami melakukan tinjauan aksesibilitas triwulanan, konsultan aksesibilitas kami Joakim pertama-tama memeriksa antarmuka dan dokumen dan memprioritaskan masalah yang dia temukan di Google Spreadsheet bersama. Joakim kemudian memandu kita melalui isu-isu terpenting yang dia identifikasi.

Pertemuan tatap muka (atau setidaknya di video) untuk membahas masalah membantu menciptakan lingkungan untuk belajar daripada perasaan diawasi atau dikelola secara mikro.

Tiga orang di sofa berkumpul di sekitar laptop. Mereka berdiskusi dan tersenyum. — Tinjauan aksesibilitas: Joakim (kanan) memandu Ingvild dan Dag-Inge melalui masalah aksesibilitas yang dia temukan dalam auditnya. (Pratinjau besar)

Jika Anda mendapati diri Anda selalu terikat dengan sesuatu yang akan dirilis, atau memperbaiki apa pun yang ada di bagian atas kotak masuk Anda, ulasan dapat membantu memperbaikinya. Jika Anda menyisihkan setengah hari reguler untuk meninjau pekerjaan yang telah Anda lakukan, Anda dapat mengidentifikasi masalah sebelum menjadi mendesak. Ini juga dapat membantu Anda memfokuskan kembali dan memastikan prioritas Anda tetap berada di jalur yang benar. Tim Anda mungkin tidak boleh mulai membangun fitur baru itu sebelum Anda yakin bahwa fitur yang ada memenuhi standar Anda.

Pengujian Pengguna Adalah Suatu Bentuk Tinjauan

Motivasi penting untuk tinjauan kode adalah untuk mengurangi risiko. Dengan melakukannya setiap kali Anda memperkenalkan perubahan atau menambahkan sesuatu yang baru ke produk Anda, dan tidak hanya ketika Anda mencurigai ada sesuatu yang mungkin tidak sesuai standar, Anda mengurangi kemungkinan pengiriman bug atau fitur di bawah standar. Saya percaya kita harus melihat pengujian pengguna dari perspektif yang sama.

Anda tahu, jika Anda ingin mengurangi risiko pengiriman dengan masalah kegunaan utama, pengujian pengguna harus menjadi bagian dari proses Anda. Hanya meminta desainer UX Anda meninjau antarmuka tidak cukup. Beberapa penelitian telah menemukan bahwa bahkan ahli kegunaan gagal dalam mengidentifikasi setiap masalah kegunaan yang sebenarnya. Rata-rata, 1 dari 3 masalah yang diidentifikasi oleh para ahli adalah alarm palsu — dalam praktiknya hal itu tidak menjadi masalah bagi pengguna. Tapi lebih buruk lagi, 1 dari 2 masalah yang sebenarnya dimiliki pengguna, diabaikan oleh para ahli.

Melewatkan pengujian pengguna sama besarnya dengan risiko melewatkan tinjauan kode.

Apakah Review Berarti Kematian Bagi Kreativitas?

Orang yang bekerja dalam desain, pengalaman pengguna, dan konten sering kali memiliki latar belakang pendidikan dari sekolah seni atau mungkin sastra, di mana pencipta tunggal atau jenius artistik kreatif dipuji sebagai yang ideal. Jika Anda kembali ke sejarah, ini juga berlaku untuk pengembang. Seiring waktu, ini telah berubah karena kebutuhan karena pengembangan web telah berkembang lebih kompleks.

Jika Anda berpegang teguh pada gagasan kreativitas yang datang dari suatu tempat jauh di dalam diri Anda, gagasan untuk meninjau mungkin terasa mengancam atau menakutkan. Seseorang ikut campur dalam pekerjaanmu yang setengah jadi? Aduh. Tetapi jika Anda berpikir tentang kreativitas sebagai sesuatu yang dapat muncul dari banyak sumber, termasuk dialog, kolaborasi, atau segala bentuk inspirasi (baik dari luar atau dari suatu tempat dalam diri Anda), maka ulasan hanyalah aset dan peluang.

Selama kita membangun sesuatu untuk web, tidak ada cara lain selain berkolaborasi dengan orang lain, baik itu dalam bidang kita sendiri atau orang lain. Dan ide yang bagus akan bertahan dari tinjauan.

Mari kita ciptakan sesuatu yang hebat bersama-sama.