Get best of the week

Bagaimana Amazon diatur

Seperti banyak perusahaan AS lainnya, organisasi alur kerja Amazon dibangun berdasarkan prinsip-prinsip dasar yang tujuan utamanya adalah membantu karyawan membuat keputusan yang tepat berdasarkan nilai-nilai perusahaan. Kami berbicara dengan manajer produk di Amazon, yang berbicara tentang prinsip-prinsip apa yang diikuti perusahaan, bagaimana mereka membantu tugas, dan proses apa yang dilalui tim saat mengembangkan produk baru. Di bawah ini kami meninggalkan tautan ke video dengan wawancara lengkap.

Misi, Visi, dan Prinsip Amazon


Dalam pemahaman saya, misi Amazon adalah menjadi perusahaan yang paling berorientasi pelanggan di dunia. Semua produk yang sedang dikerjakan korporasi dikembangkan dengan tujuan pertama membuat produk untuk pelanggan, dan kemudian meningkatkan penjualan mereka.

Ada 14 prinsip di mana sebuah perusahaan hidup dan mereka digunakan dalam semua proses kerja. Prinsip-prinsip ini sangat mendasar, tidak ada yang istimewa. Mereka dipandu oleh peluncuran produk baru, selama wawancara, atau ketika memberikan umpan balik kepada seorang rekan. Mereka tidak dipaksa untuk menghafal, tetapi ketika Anda bekerja di perusahaan, jika Anda mau, Anda tidak mau, Anda mulai mengikuti prinsip-prinsip ini.

Banyak dari mereka berpisah satu sama lain. Misalnya, seperti Think Big dan Bias for Action. Yang satu berkata, "Berpikir global," dan yang lain berkata, "Bertindak, bukan merencanakan." Sebenarnya, ada banyak prinsip yang saling bertentangan. Tapi inilah intinya. Jika karyawan terpaku pada prinsip Think Big, maka semua orang akan memenuhi tenggat waktu. Dan jika hanya Bias untuk Aksi dipatuhi, mereka akan dengan cepat melaksanakan proyek-proyek kecil dan tidak memikirkan yang besar.

Banyak yang mengatakan budaya Amazon lebih menuntut. Orang-orang datang ke sini untuk bekerja, belajar, dan berkembang. Dan ketika mereka lelah, pergi ke Microsoft.

Ini karena Amazon adalah perusahaan yang lebih dinamis dan tumbuh cepat. Kami berusaha untuk tumbuh ke arah yang berbeda. Tetapi model bisnis Boeing dan Microsoft tidak berubah selama bertahun-tahun. Google memiliki hal yang sama: mesin pencari tetap menjadi sumber penghasilan utama mereka.

Amazon didorong untuk terus-menerus menghasilkan ide-ide baru. Selalu ada banyak proyek dalam proses pengembangan. Ketika bekerja pada satu produk berakhir, segera semua orang beralih ke yang lain. Dan pada saat yang sama, tujuan tinggi untuk setiap proyek selalu ditetapkan dalam departemen.



Proses pengembangan produk


Hal pertama yang harus Anda lakukan sebelum menetapkan tugas adalah menguji hipotesis. Untuk ini, MVP atau MLP digunakan. Berdasarkan konsep-konsep ini, sebuah dokumen besar dikompilasi, yang kemudian dipertimbangkan oleh seluruh tim. Dua hal yang harus disorot dalam dokumen:

Bagaimana proyek menyelesaikan masalah klien? Dokumen ini memiliki 1 halaman untuk menjelaskan ide secara ringkas dan menyampaikan nilainya.

Pertanyaan apa yang bisa ditanyakan konsumen tentang produk? Dan pertanyaan teknis: bagaimana kita akan menghasilkan uang? Di mana membeli peralatan teknis? Siapa yang akan menjadi kontraktor? Semuanya harus dijelaskan dalam dokumen dalam format pertanyaan dan jawaban.

Jika kita mengerti bahwa semua orang menyukai ide itu, itu akan berkembang. Manajer produk mengkompilasi daftar persyaratan, memecahnya pada tahap rilis Agile. Semuanya diatur sedemikian rupa untuk menguji langkah demi langkah satu hal dan mendapatkan umpan balik.

Hal terpenting dalam tim adalah jangan menunggu instruksi. Jika Anda datang ke kepala dengan beberapa jenis masalah, maka Anda seharusnya sudah memiliki solusi. Dan manajer hanya dapat memberikan umpan balik - apakah Anda menemukan solusi yang baik atau tidak.

Tim selalu memiliki jadwal untuk hari-hari ketika akan selesai. Setiap minggu, karyawan berkumpul untuk membahas tugas. Kami menunjukkannya di dasbor dengan status - hijau, kuning dan merah.

Hijau berarti bahwa semuanya baik-baik saja, perhatian pada tugas tidak diperlukan. Kuning - ada yang salah, tapi kami tahu cara memperbaikinya. Misalnya, mereka berencana menyelesaikan proyek pada 1 Mei, tetapi ada masalah yang akan kami coba selesaikan pada 1 Mei. Dan merah - ada yang salah, dan kami belum tahu bagaimana memenuhi tenggat waktu.

Setelah itu, setiap pengembang menunjukkan demo dengan pekerjaan yang dilakukan. Selama pertemuan tersebut, manajer produk memiliki kesempatan untuk memberikan umpan balik dan mengubah jalur tugas. Selebihnya - kesempatan untuk meminta saran rekan kerja, jika tidak jelas bagaimana menyelesaikan salah satu masalah. Laporan tim mingguan mendukung budaya Agile ketika semua orang mencoba untuk merilis sesuatu untuk dirilis, daripada menariknya selama setahun penuh.

Ketika proyek sudah siap, itu disetujui oleh manajer produk dan dikirim ke tahap berikutnya - pengujian. Perusahaan memiliki penguji internal yang memeriksa apakah fitur rusak, dan sekelompok penguji beta, yang pada gilirannya memberikan umpan balik mereka. Setelah tes mereka, pengembangan dirilis dalam beberapa hari. Dan disinilah pekerjaan tugas berakhir.



Organisasi proses kerja di perusahaan


Scrum - metode memprioritaskan tugas untuk 2-3 minggu ke depan - untuk lari cepat.

Sprint - ini adalah jangka pendek di mana Anda berkata: "Oke, dua minggu ke depan kita akan melakukan 10 tugas ini. Dan kami akan bekerja hanya pada mereka dan tidak ada yang lain. " Ini memiliki pro dan kontra. Di satu sisi, Anda tidak terganggu oleh tugas-tugas lain. Tetapi Anda harus terus-menerus membuat tambahan, dan mereka akan berlari cukup banyak.

Tidak ada hal seperti itu dalam pemrograman yang Anda hanya duduk dan mulai menulis kode. Pertama, manajer produk mengumpulkan semua persyaratan, menjelaskan fungsi-fungsi produk baru. Lalu semuanya berjalan ke desain. Programer duduk dan menjelaskan apa yang perlu mereka lakukan berdasarkan persyaratan, misalnya, berintegrasi dengan sistem, membuat kerangka kerja tertentu, dll. Tahap ketiga adalah kode yang sedang berjalan, di mana karyawan sudah duduk dan mulai menulis kode. Lalu uji coba. Dan tahap terakhir adalah rilis.

Dan di sini Kanban adalah metodologi di mana Anda menetapkan batas untuk setiap tahap. Sekelompok "persyaratan" tidak dapat memiliki lebih dari 3 fungsi. Sampai saya mentransfer salah satu persyaratan ke desain, saya tidak dapat menambahkan tugas baru.

Artinya, alur tugas diatur. Jika Anda memiliki lebih banyak pengembang, Anda dapat memperluas tugas. Kelebihan dari metodologi ini adalah fleksibel. Minus - prioritisasi dapat terus berubah tidak seperti Scrum. Kapan saja, Anda bisa memasukkan tugas yang belum ada sebelumnya.

Kedua pendekatan berhubungan dengan metodologi Agile. Artinya adalah Anda selalu memecah rilis besar menjadi potongan-potongan kecil dan melepaskannya sesering mungkin agar tidak melakukan apa yang tidak diperlukan pengguna.

Dalam Scrum, kami mengevaluasi setiap tugas dalam poin. Anda tidak dapat mengukurnya dengan apa pun, itu lebih merupakan nilai relatif. Misalnya, tugas 4 poin lebih banyak dari perkiraan tugas 2. Poin tersebut memungkinkan Anda melihat seberapa banyak pengembang telah menutup tugasnya.
Di Kanban, ini lebih rumit.

Aturan kami yang lain adalah hanya menjalankan 3 tugas. Jika tim memiliki 10 pengembang, maka semua orang mengerjakan tugas-tugas ini, tidak ada yang bisa mengambil yang baru. Karena jika setiap pengembang mengerjakan satu tugas, yang membutuhkan waktu pengembangan 2 bulan, maka masing-masing hanya akan ada 2 rilis.

Itulah sebabnya ada pembatasan setidaknya 3 tugas, yang masing-masing memiliki 3 pengembang. Apalagi, jika seseorang dilepaskan, maka ia tidak dapat mengambil proyek baru. Dia harus membantu kolega menyelesaikan sisa tugas yang ditetapkan untuk sprint. Dan hanya setelah proyek dirilis, Anda dapat mengambil tugas baru.

More articles:


All Articles