Mengapa desain Gmail baru begitu lambat?

gambar
Seperti yang Anda tahu, pada tahun 2018, Google melakukan desain ulang terbesar dari antarmuka layanan emailnya Gmail. Seperti biasa, tidak semua orang senang dengan hal itu - dan kali ini ada alasan yang cukup objektif untuk ketidakpuasan dengan layanan ini. Mengapa memuat Gmail membutuhkan banyak waktu, dan tindakan seperti menghapus atau mengarsipkan percakapan dapat memakan waktu 4-6 detik?

Beberapa hari yang lalu, seorang pengguna Hacker News mengajukan pertanyaan serupa - dan ia menerima tanggapan dari seorang karyawan Google anonim yang menatap budaya pengembangan di dalam perusahaan dan rekan-rekannya.

Menurutnya, semua ini terjadi karena fakta bahwa Google tidak memberikan hukuman untuk "misses."

Di dalam dinding perusahaan, mereka secara aktif mendorong peluncuran - rilis publik tentang sesuatu. Dan fakta bahwa produk mungkin hanya berisi setengah dari fitur yang diperlukan, tidak berfungsi, hanya bekerja di bawah Chrome dan sebagainya - ini tidak mengganggu siapa pun, karena pembuatnya tidak berisiko untuk ini. Ini adalah norma.

Arti dari tindakan semacam itu hanya satu hal - dalam kemajuan karier, karena tanpa peluncuran besar di atas tingkat tertentu Anda tidak akan dapat melangkah. Jadi kita berakhir dengan ratusan aplikasi obrolan yang tidak perlu, pendesainan ulang dan restart yang tidak ada habisnya - jika tidak, orang tidak akan dapat dipromosikan.

Ketika manajemen perusahaan mencoba untuk memecahkan masalah dengan mengeluarkan dokumen internal yang bukannya memotivasi untuk mencapai โ€œpendaratanโ€ yang sukses ( pendaratan , peluncuran yang sukses) - semua yang telah diubah karyawan dalam hidup mereka adalah s / launch / landing / g dalam ulasan kinerjanya.

Ambil contoh, utusan Allo. Butuh dua tahun untuk mengembangkannya, setelah itu perusahaan memutuskan untuk menunda pengembangan dan membekukan proyek. Ternyata, orang-orang yang bertanggung jawab atas utusan itu tidak menderita pada saat yang sama - sebaliknya, beberapa dari mereka bahkan dipromosikan.

Sayangnya, tampaknya, masalah mendesak dari pengguna perusahaan saat ini tidak terlalu tertarik:
Apakah Anda tahu berapa banyak bug yang perlu Anda perbaiki untuk mendapatkan kenaikan gaji? Sangat banyak. Tidak masalah berapa banyak bug yang Anda perbaiki - tidak akan pernah memberi Anda "kontribusi" yang cukup untuk meningkat, tidak akan pernah. Tapi itu cukup untuk menjalankan hanya satu desain ulang - bahkan jika itu praktis tidak berguna - dan promosi ada di saku Anda.

Secara alami, di dalam tembok perusahaan itu sendiri ada orang yang memperingatkan tentang kemungkinan ini dan mengeluh, memasukkan bug kinerja ke pelacak - hanya itu saja yang diabaikan; kebanyakan pekerja akhirnya menyerah dan berhenti menulis tentang bug, karena jawaban khasnya adalah "Anda bukan target audiens kami."

Dan kita semua tahu tentang masalah ini! Kita semua! Beberapa berhenti ketika datang ke mereka; yang lain hanya mulai "mengoptimalkan" ke atas - alih-alih mengoptimalkan ke arah apa yang baik bagi pengguna atau perusahaan.

Dalam pemikirannya, pengembang tidak sendirian. Graham Wheeler membagikan sebuah kisah dari hidupnya di Google yang menegaskan posisinya.
Setelah di Google saya menerima ulasan kinerja negatif. Saya memutuskan bahwa cara terbaik untuk menghabiskan waktu saya adalah dengan memperbaiki kode yang saya miliki untuk membawa tingkat cakupan tes dari 0% menjadi 80%, memperbaiki banyak bug di sepanjang jalan. Akibatnya, saya mendapat ulasan jelek tentang ulasan kinerja, dan penulis govnokoda asli mendapat kenaikan gaji.

Cerita tentang masalah manajemen pengembangan dalam Google muncul secara teratur di Web. Reaksi pengguna juga tidak lama. Pelanggan bisnis yang menggunakan Google Apps beralih ke FastMail , prinsip utamanya adalah email dan tidak lebih.

Begitulah kami dan kami mendapatkan hal-hal seperti Gmail baru. Yang, di satu sisi, mendapat desain ulang dalam semangat Desain Material, mode offline, dan banyak perbaikan kecil lainnya yang ditransfer dari Google Inbox, yang akan memesan tahun yang panjang di tahun depan. Di sisi lain, ia melakukan 358 permintaan untuk memuat penuh dan mengunduh 6.3MB. Sebagai perbandingan, mode "kuno" dari Tampilan HTML di Gmail hanya 14 permintaan dan 25,3KB, yang memungkinkan untuk memuat dalam 2 detik.

Tentu saja, praktik ini tidak hanya berlaku untuk Google, tetapi juga untuk banyak perusahaan besar lainnya. Kami mengamati prinsip terkenal "Anda mendapatkan apa yang Anda ukur" dalam aksi.

Kisah serupa diceritakan oleh pengembang Steve , yang bekerja di Apple di MacOS X Snow Leopard. Untuk sebagian besar, Steve berkomitmen untuk memperbaiki bug di semua kerangka kerja OS utama - dan sebagai akibat dari rilis, ia ditolak promosi karena fakta bahwa kehadirannya "tidak kritis pada salah satu proyek."

Ironi di sini adalah bahwa versi OS ini, berdasarkan ide manajemen perusahaan, seharusnya menjadi rilis di mana semuanya ditujukan untuk meningkatkan stabilitas dan kinerja sistem. Namun, sementara beberapa dari mereka diharapkan bekerja pada stabilitas, yang lain secara aktif "mendorong" fitur baru seperti pengumpul sampah untuk Objective-C ke dalam rilis, yang menunda pekerjaan orang lain dan membuat Xcode tidak bisa digunakan selama beberapa bulan.

Tetapi pekerjaan pada bug itu tidak sia-sia bagi pengguna biasa yang mengingat kinerja yang sangat baik dari Snow Leopard dan Lion berikutnya - tidak seperti Chrome, yang hanya berhasil membekukan beberapa kali selama penulisan posting ini dan menyebabkan crash pada tab draft.

Source: https://habr.com/ru/post/id429018/


All Articles