The Mythical Mythical Man-Bulan

Sebagai pemimpin produk di perusahaan teknologi, saya sangat membutuhkan. Pekerjaan saya sebagai Chief Product Officer di Mailchimp adalah membawa produk ke pasar yang akan menang dalam ruang yang sangat kompetitif. Aspirasi Mailchimp sangat tinggi, dan untuk mewujudkannya, kami perlu mengirimkan sejumlah besar produk ke pasar. Seringkali bagi banyak orang di perusahaan, rasanya seperti kita melakukan terlalu banyak. Kami selalu berada di ujung roda yang lepas.

Dan ketika Anda melakukan terlalu banyak dan Anda memutuskan untuk melakukan lebih dari itu, Anda pasti akan mulai mendengar The Mythical Man-Month dirujuk. Ini seperti salah satu bola pelepas stres di mana jika Anda menekan salah satu ujungnya, maka keluarlah Mythical Man-Month di ujung lainnya.

Diterbitkan oleh Frederick Brooks pada tahun 1975 (Anda ingat 1975, kan? Ketika pengembangan perangkat lunak 100% menyerupai pengembangan perangkat lunak pada tahun 2020?), buku ini agak terkenal di kalangan insinyur perangkat lunak. Secara khusus, ada satu poin di seluruh buku yang terkenal (saya tidak yakin orang membaca apa pun kecuali poin ini jika mereka sudah membaca buku itu sama sekali):

"...menambahkan lebih banyak pria memperpanjang, bukan memperpendek, jadwal."

Perbaikan mudah. Saya hanya akan menempatkan wanita di proyek mulai sekarang (lihat Kembalinya Sang Raja dan pertarungan melawan Raja Penyihir dari Angmar).

Tapi mari kita asumsikan bahwa poin Brooks berlaku terlepas dari identifikasi gender dari para insinyur perangkat lunak yang bersangkutan. Inilah intinya: perangkat lunak sulit dibangun dengan banyak ketergantungan yang kompleks. Dan semua orang perlu bekerja sama untuk menyelesaikannya.

Saat saya menambahkan orang ke dalam tim, mereka perlu dimasukkan dan dicangkokkan ke dalam proyek. Seseorang harus mengukir pekerjaan yang tepat untuk mereka. Tim harus berkomunikasi untuk memastikan semua barang mereka bekerja bersama, dan setiap orang tambahan meningkatkan kompleksitas komunikasi itu secara geometris. Dan pada titik tertentu, menambahkan orang menjadi beban proyek — bukan keuntungan.

Berikut grafik dari buku yang menggambarkan hal itu:

Ini benar-benar poin yang adil. Itu sebabnya saya sering mendengarnya di tempat kerja. Kontributor individu yang kelelahan dan pemimpin yang kelelahan sama-sama akan membuangnya — kita tidak bisa pergi lebih cepat, kita tidak bisa berbuat lebih banyak, menghentikan perekrutan, membaca The Mythical Man-Month dan putus asa! Satu-satunya solusi tampaknya berhenti tumbuh dan membunuh beberapa proyek.

Ketika saya sebagai CPO mengatakan, “kita akan melakukan hal ini!” jawabannya kemudian sering, "Oke, jadi apa yang akan kita bunuh?" The Mythical Man-Month mengubah pengembangan produk menjadi permainan zero-sum. Jika kita menginginkan satu hal, kita harus menghentikan yang lain. Nah, itu mitos yang sebenarnya, dan saya sebut omong kosong.

Dan dibawa ke kesimpulan yang disalahartikan secara patologis (kita akan sampai pada ini), buku itu tampaknya mengatakan bahwa perusahaan teknologi tercepat adalah perusahaan yang mempekerjakan empat orang — empat orang , rupanya. Apa pun yang lebih hanya memperlambat semuanya. Seseorang harus mengirim salinan buku ke Amazon, Apple, dan Google, sehingga mereka dapat memperbaiki organisasi mereka yang membengkak.

Satu-satunya masalah dengan pendekatan ini adalah bahwa di ruang di mana persaingan tumbuh dan mengulangi dan mengeksekusi — hanya menghambat pertumbuhan organisasi — mengedit dan memfokuskan beban kerja agar sesuai dapat menjadi resep untuk kepunahan. Anda akan lebih waras dan tidak stres — sampai Anda keluar dari pekerjaan.

Dan sebagai pemilik manajemen produk untuk perusahaan saya, saya bukannya tidak simpatik dengan kebutuhan untuk memperlambat dan fokus ini. Kita harus memprioritaskan dengan kejam! Tanpa keraguan. Tetapi menjalankan produk adalah latihan yang kontradiktif. Saya harus memprioritaskan apa yang saya miliki sambil secara bersamaan merencanakan untuk menyelesaikan lebih banyak. Tapi apa yang harus saya lakukan dalam menghadapi Mythical Man-Month ?

Anehnya, jawaban atas pertanyaan ini berasal dari buku yang sama dari Brooks. Berikut grafik lain di bab yang sama:

Ada pertempuran dalam menskalakan pengembangan produk. Jika pekerjaan yang ingin Anda selesaikan murni dapat dipartisi, lanjutkan dan tambahkan orang! Jika pekerjaan Anda semua terhubung, maka pada titik tertentu menambahkan orang salah.

Jika seseorang mengatakan bahwa saya benar-benar harus menghentikan sebuah proyek untuk memulai yang lain, itu tidak benar. Jika kedua proyek tersebut hanya membutuhkan sedikit komunikasi dan koordinasi, maka kami dapat menguranginya.

Inilah sebabnya mengapa menambahkan inti ke CPU dapat meningkatkan kecepatan pengalaman komputer atau ponsel Anda hingga titik tertentu — sesuatu yang harus diketahui oleh para insinyur. Tentu, menambahkan inti tidak akan membantu saya menyelesaikan komputasi utas tunggal yang rumit. Tapi itu mungkin membantu saya menjalankan banyak tugas independen .

Konflik bagi seorang eksekutif produk kemudian antara penskalaan dan prioritas yang kejam dapat dikelola.

1. Anda dengan kejam memprioritaskan di tempat-tempat yang memiliki utas tunggal (misalnya, simpanan tim produk).
2. Anda menskalakan dengan menambahkan lebih banyak inti untuk menangani pekerjaan mandiri.

Sangat jarang, bagaimanapun, adalah sesuatu yang sepenuhnya independen dari semua hal lain di sebuah perusahaan. Minimal, perusahaan Anda akan memusatkan fungsi pendukung (TI global, hukum, SDM, dll.) yang mengarah ke kemacetan.

Ini Semua Tentang Manajemen Ketergantungan

Tugas seorang eksekutif produk kemudian menjadi tidak hanya menciptakan strategi, tetapi mengeksekusi dengan cara yang memaksimalkan nilai bagi pelanggan dan bisnis dengan memastikan throughput dan mengurangi risiko interdependensi sebanyak mungkin. “Sebisa mungkin” menjadi kunci di sini. Dengan cara itu Anda dapat membuat perusahaan terlihat seperti grafik yang terakhir daripada yang pertama. Saling ketergantungan adalah penyakit yang tidak dapat disembuhkan , tetapi gejalanya dapat dikelola dengan banyak perawatan.

Salah satu solusinya adalah menyusun arahan strategis bagi perusahaan yang meminimalkan atau membatasi ketergantungan melalui portofolio inisiatif yang dipilih dengan cermat. Yang lucu di sini adalah bahwa banyak orang akan mendorong kembali ini. Katakanlah saya memiliki dua opsi, satu di mana saya dapat menjalankan proyek A, B, dan C yang memiliki koordinasi sangat sedikit (katakanlah mereka memengaruhi produk yang berbeda ), dan opsi lain dengan proyek D1, D2, dan D3 yang memiliki banyak ketergantungan ( katakanlah semuanya berdampak pada produk yang sama ). Sering terjadi bahwa Mythical Man-Bulan akan dipanggil melawan rencana sebelumnya daripada yang terakhir. Karena di atas kertas sepertinya lebih .

Memang, itu kurang "fokus." Tapi, sebenarnya lebih mudah dari perspektif ketergantungan dan karenanya lebih baik dengan penambahan personel.

Perlu diingat, saya tidak mengatakan untuk memilih banyak pekerjaan untuk perusahaan yang tidak terkait. Mailchimp tidak akan membuat oven microwave dalam waktu dekat. Semua pekerjaan harus mengarah ke arah jangka panjang yang sama. Pendekatan ini dapat meningkatkan risiko pengalaman pelanggan (yang akan kita bahas nanti) serta beban fungsi global seperti riset pelanggan. Perhatikan hal itu.

Perlakuan lain adalah menciptakan proses manajemen produk dan program yang memfasilitasi koordinasi ketergantungan dan komunikasi jika diperlukan tanpa membebani tim dengan koordinasi jika tidak diperlukan . Kadang-kadang dalam upaya mengelola koordinasi sehingga kita dapat berbuat lebih banyak, kita akhirnya menciptakan proses yang berat sehingga kita akhirnya melakukan lebih sedikit. Ini adalah keseimbangan antara melakukan koordinasi yang terlalu sedikit yang menyebabkan bagian-bagian itu tidak saling beroperasi dan melakukan terlalu banyak koordinasi yang menyebabkan bagian-bagian itu tidak pernah bisa dibangun karena kita semua dalam posisi berdiri untuk selama-lamanya.

Perdebatan dalam Mythical Man-Month adalah bahwa saat Anda menambahkan orang ke proyek perangkat lunak, komunikasi perlu meningkat secara geometris. Misalnya, jika Anda memiliki 3 orang dalam proyek, itu adalah 3 jalur komunikasi. Tetapi jika Anda memiliki 4, itu adalah 6 jalur komunikasi. Satu orang tambahan, dalam hal ini, akan menggandakan komunikasi! Seru. (Ini, tentu saja, merupakan penyederhanaan komunikasi yang berlebihan pada proyek pengembangan perangkat lunak.)

Orang yang berbeda memiliki peran yang berbeda dan karenanya menerima jumlah otonomi yang berbeda. Mungkin manajer proyek perlu berkomunikasi dengan semua orang di tim. Tetapi apakah seorang insinyur yang mengerjakan API perlu berkomunikasi dengan pemasar produk? Atau bisakah pemasar melalui manajer produk saja? Proses dan irama pertemuan yang baik kemudian dapat menghilangkan komunikasi dan pertemuan yang tidak perlu. Intinya adalah bahwa rumus interkomunikasi Brooks adalah batas atas koordinasi , bukan hukuman mati.

Terakhir, gunakan alat, prinsip, dan kerangka kerja yang dikombinasikan dengan kerja mandiri di atas kolaborasi nyata untuk memerangi gejala saling ketergantungan. Misalnya, jika saya dapat mengoordinasikan indikator kinerja utama dua tim (KPI, yaitu pengukuran keberhasilan) untuk mendorong gerakan ke arah yang kurang lebih sama, maka pekerjaan independen mereka kemungkinan besar akan berakhir "lebih dekat" daripada jika KPI mereka mendorong gerakan ortogonal. Ini tidak akan memastikan semuanya cocok bersama dengan sempurna, hanya saja pekerjaan yang perlu saya lakukan untuk membuatnya cocok bersama di masa depan kurang dari yang seharusnya. Contoh lain mungkin termasuk menggunakan pernyataan "genap", sistem desain, dan pengujian otomatis.

Jadi ada permulaan. Tetapi saling ketergantungan mengambil banyak bentuk di luar kode. Biarkan saya memberikan contoh dari Mailchimp.

Risiko Pengalaman Pelanggan: Biaya Pekerjaan Firewall yang Tersembunyi (Tapi Dapat Diterima?)

Karena pelanggan Mailchimp sering kali adalah pemilik usaha kecil yang merupakan pemula pemasaran (dan ada jutaan pemilik usaha kecil yang beralih menjadi pemasar di seluruh dunia), kami harus memberikan pengalaman yang mulus dan langsung dapat dipahami dari ujung ke ujung . Kami tidak diberikan kemewahan untuk merakit monster awan Frankenstein melalui akuisisi seperti yang bisa dilakukan oleh pemain perusahaan. Kami tidak dapat membahas perangkat lunak yang tidak terintegrasi dengan baik dengan konsultan dan manajer akun.

Sebagai produk konsumen (pikirkan Instagram atau Nintendo Switch atau Roomba), kita harus dapat digunakan secara langsung. Untuk platform pemasaran all-in-one yang dimaksudkan untuk memperkuat bisnis Anda, itu sulit! Dan itu berarti setiap hal yang dibuat Mailchimp harus terhubung dengan mulus dari perspektif pengalaman.

Namun, mempartisi proyek dengan sempurna kemudian menimbulkan risiko pengalaman . Bukannya kode tersebut tidak dapat ditulis secara mandiri. Itu bisa dicapai, tetapi masih ada risiko bahwa produk akan terlihat seperti dibuat oleh tim yang berbeda, dan pengalaman itu bisa sangat membingungkan bagi pengguna. Kami bertemu dengan hukum Conway — pelanggan kami dapat mengetahui di mana pekerjaan satu tim berakhir dan pekerjaan tim lain dimulai.

Jadi, Anda mencoba menghubungkan pekerjaan semua orang bersama — tidak hanya di bagian belakang tetapi juga di bagian depan. Di era ekosistem, yang didominasi oleh keunggulan CX dari pemain seperti Apple, ini hampir menjadi taruhan meja di ruang konsumen. Tapi ini adalah mimpi buruk Mythical Man-Month , meski kali ini bukan dari sudut pandang engineering. Ini dari perspektif desain layanan. Saat kami menambahkan lebih banyak orang ke semua pekerjaan terhubung "ujung ke ujung" ini, semuanya melambat menjadi perayapan kolaboratif.

Selain perbaikan ketiga yang saya sebutkan di atas, menggunakan alat dan kerangka kerja daripada pengamat berlebihan dan gerbang panggung, ada katup pelepas lain: buat beberapa pertukaran pengalaman pelanggan yang disengaja . Secara khusus, di mana kita nyaman melepaskan pengalaman yang terputus dari yang lain (yaitu di bawah standar)? Menerima risiko dan bergerak maju adalah tugas pemimpin produk. Jadi Anda menggunakan beberapa kriteria untuk menyelesaikannya (mungkin itu tidak memegang area aplikasi baru dengan lalu lintas rendah dengan standar pengalaman yang sama dengan "sapi perah" Anda), dan membuat keputusan (mis. inovasi). Ini, tentu saja, melampaui desain.

Anda selalu dapat memutuskan hukum Brooks dengan memilih upaya firewall, termasuk upaya yang, di dunia yang sempurna, tidak boleh di-firewall!

“

Saya akan memperingatkan ini dengan mengatakan bahwa perangkat lunak yang saya buat tidak membunuh siapa pun. Saya tidak akan menganjurkan pendekatan ini jika saya sedang membangun perangkat medis. Namun di perusahaan perangkat lunak pemasaran, saya dapat dengan sengaja mengisolasi tim dengan mengetahui bahwa saya telah meningkatkan kemungkinan ketidakcocokan sebagai pertukaran untuk meningkatkan personel dan bergerak lebih cepat.

Saya sedih untuk mengakui bahwa Mythical Man-Month adalah kenyataan di perusahaan saya, dan saya curiga di perusahaan Anda juga. Tapi itu bisa diatur — itulah intinya. Paralelisasi dan mitigasi ketergantungan menawarkan kita jalan keluar yang membatasi status hampir mitos dari Mythical Man-Month . Jadi, pada saat dikotomi yang mencolok muncul di perusahaan Anda (skala untuk memperlambat atau melepaskan aspirasi Anda), ingatlah bahwa jika Anda pintar dalam mengatur pekerjaan, Anda masih bisa tumbuh besar.

Jangan Lupa Tentang Sisi Lembut Penskalaan

Ingatlah bahwa mengelola Mythical Man-Month tidak akan menghentikan para insinyur untuk menerapkannya seperti sihir gelap. Mereka menerapkan prinsip bukan hanya karena ada beberapa kebenaran di dalamnya, tetapi karena penskalaan hanya menyebalkan (selalu) dari perspektif emosional dan kognitif. Jika saya pikir saya dibayar untuk menulis kode dan memecahkan masalah pelanggan, hal terakhir yang ingin saya lakukan adalah mengubah rutinitas saya dan mencari cara untuk bekerja dengan orang baru dan tim yang lebih besar.

Saat Anda mengukur perusahaan Anda, ingatlah untuk berempati dengan rasa sakit karena penskalaan dan perubahan. Sebuah tim yang menambahkan bahkan satu anggota menjadi tim baru dari perspektif kepercayaan dan budaya. Orang-orang sudah bosan dengan perubahan ini. Itu berarti bahwa saat Anda mengelola dan mengurangi Mythical Man-Month , Anda harus mengelola emosi di sekitar pertumbuhan. Itu mungkin tugas yang paling penting dari semuanya.

Keyakinan yang kuat pada Mythical Man-Month oleh sebuah tim di dalam dan dari dirinya sendiri dapat membawa kesimpulannya menjadi kenyataan. Ini pada dasarnya setara dengan kepercayaan terbang di Peter Pan. Jika tim percaya bahwa penskalaan akan memperlambat mereka dan mereka tidak menerima perubahan, mereka memang akan melambat.

Jadi, saat Anda bekerja untuk mengelola dependensi dan memperkenalkan alat untuk membantu menskalakan, pastikan Anda mengomunikasikan dengan jelas alasan di balik praktik tersebut. Libatkan orang-orang dalam memilih pekerjaan dan proses yang mengurangi masalah man-month, karena ketika mereka menjadi bagian dari perubahan dan pandangan mereka berubah, tiba-tiba penskalaan menjadi setidaknya mungkin secara budaya.