Teknologi
- Minta sistem inti ditulis ulang selama 6–18 bulan. Salahkan CTO sebelumnya.
- Dorong setiap orang untuk memakai bahasa dan framework yang berbeda-beda.
- Bagi sistem dengan batas yang sewenang-wenang sehingga banyak sistem terlibat dalam satu fitur.
- Ciptakan lingkungan pengembangan yang rumit. Paksa menjalankan service mesh yang mencakup setidaknya 12 layanan.
- Buat lingkungan produksi dan lingkungan developer semaksimal mungkin berbeda.
- Lakukan deployment sesering mungkin? Tidak, buat deployment sesering mungkin jarang. Sarankan agar sangat berhati-hati terhadap deployment.
- Perkenalkan proses yang sangat rumit untuk perubahan kode dan alur kerja umum. Jadikan alasan "keamanan" atau "kepatuhan".
- Catat semua pekerjaan di pelacak tugas dan pastikan minimal 5 orang meninjau, memprioritaskan, dan menyetujuinya.
- Larang semua hal di luar cakupan pekerjaan awal. Misalnya, larang pembersihan kode atau pekerjaan perbaikan lainnya.
- Bangun hampir semua hal yang bukan kompetensi inti secara internal. Benarkan dengan alasan "untuk menghindari ketergantungan vendor".
- Bersikeras menambahkan lapisan abstraksi ke segala hal. Gunakan vendor yang sudah diabstraksikan lalu tambahkan lagi lapisan abstraksi tambahan.
- Dorong keputusan teknis dengan skala yang terlalu optimistis dan tidak realistis. Rencanakan beban setidaknya 3 kali lebih besar dari saat ini.
- Dorong kepemilikan bersama atas sistem. Buat agar tidak ada yang merasa bertanggung jawab terhadap pemeliharaannya.
- Bersikeras memusatkan hampir semua hal ke dalam "platform". Biarkan tim platform kekurangan personel dan cegah tim lain membangun hal-hal yang bisa dimiliki platform.
- Biarkan tim platform sering mengiterasi API dan paksa tim lain merefaktor kode mereka ke versi terbaru.
- Rekrut "arsitek" dan wajibkan "tinjauan arsitektur" bahkan untuk perubahan kecil.
- Wajibkan "tinjauan keamanan" bahkan untuk perubahan kecil.
Produk
- Abaikan metrik yang berguna dengan alasan akademis. Misalnya, sebut saja sebagai "bias" atau "indikator yang tertinggal".
- Pilih vanity metrics yang tidak terkait dengan nilai bisnis. Pilih metrik yang penuh noise.
- Anggap segala hal sebagai "taruhan besar" dan bersikeras untuk tidak merilis apa pun sampai semuanya benar-benar selesai.
- Anggap semua fitur sebagai "wajib" dan sebagai bagian penting dari "versi nol". Jangan pernah mengalah.
- Kembangkan rencana "strategis" yang sangat rinci.
- Sering-sering ubah arah.
- Abaikan perbaikan yang jelas sebagai "optimasi lokal".
- Ikat sumber daya pada tren terbaru. Mulai "strategi AI" yang tampak meyakinkan di permukaan. Keluarkan banyak biaya untuk vendor dan konsultan demi itu.
- Dorong manajer produk agar menghabiskan sebagian besar waktunya untuk "strategi" dan "perencanaan".
- Buat engineer dan manajer produk sulit atau tidak mungkin memakai produk secara internal.
- Secara internal, anggap pengguna sebagai "orang bodoh".
Kepemimpinan
- Kaitkan kompensasi dengan jabatan dan ukuran tim untuk mendorong pembengkakan organisasi.
- Banyak bicara keras tentang strategi, fitur, atau kompleksitas teknis.
- Lakukan akuisisi mahal untuk masuk ke area produk baru. Sebut-sebut "sinergi". Lalu buang produk hasil akuisisinya.
- Gunakan banyak garis putus-putus dalam struktur pelaporan.
- Buat sebanyak mungkin orang melapor ke manajer dari tim, lokasi, atau fungsi yang berbeda. Pastikan manajer tidak bisa benar-benar mengawasi bawahannya.
- Sering-sering pindahkan orang yang berkinerja rendah ke tim lain.
- Tempatkan orang berkinerja tinggi pada proyek R&D yang sangat spekulatif dengan hasil yang tidak pasti.
- Selalu minta rapat bahkan untuk keputusan sepele.
- Bersikeras bahwa semua "pemangku kepentingan" harus hadir di rapat.
Perekrutan
- Buat proses perekrutan yang tampak objektif tetapi sebenarnya subjektif.
- Tolak talenta terbaik dengan alasan "tidak cocok budaya" atau kriteria kabur lainnya.
- Rekrut kandidat terlemah dengan alasan "potensi" atau "sikap" atau kriteria kabur lainnya.
- Rekrut pemimpin senior yang sangat mahal dengan komitmen perekrutan besar-besaran.
- Gunakan jabatan yang dibesar-besarkan dan peran yang dibuat-buat untuk menarik orang oportunistis.
- Rekrut "pakar" yang sangat terspesialisasi lalu ciptakan proyek artifisial agar mereka tidak pergi.
- Gunakan spesialisasi sebagai pembenaran untuk merekrut orang lain yang saling melengkapi.
Manajemen proyek
- Minta estimasi yang sangat rinci untuk setiap proyek.
- Dorong proyek lintas sebanyak mungkin tim, idealnya tim-tim yang berada di lokasi berbeda.
- Tambahkan persyaratan baru yang bergantung pada pekerjaan yang dilakukan tim lain.
- Sering gunakan agensi mahal. Buat cakupan kerja kabur dan serahkan prototipe yang belum selesai ke tim internal untuk dirampungkan.
- Bangun sistem "swalayan" yang rumit untuk pemangku kepentingan dari tim lain.
Hasil
- Menurunkan produktivitas adalah hal yang sulit. Tetapi jika Anda mendarat dengan parasut di belakang garis musuh dan mendapatkan pekerjaan sebagai CTO, Anda bisa mewujudkannya.
- Bagi orang yang tidak destruktif: ini adalah cerita tentang cara benar-benar memaksimalkan produktivitas tim. Produktivitas terbentuk dari hal-hal kecil yang menumpuk.
- Jika 100 hal kecil masing-masing mengenakan pajak produktivitas sebesar 5%, semuanya menjadi 131 kali lebih lambat. Untuk menjaga engineer tetap bahagia, Anda harus menolak 100 hal kecil yang terdengar masuk akal itu.
Opini GN⁺
- Artikel ini secara humoris menjelaskan berbagai cara yang dapat menghambat produktivitas dalam pengembangan perangkat lunak. Melalui ini, kita bisa melihat dengan jelas perilaku yang sebenarnya harus dihindari.
- Penting untuk mengurangi utang teknis dan mempertahankan budaya pengembangan yang efisien. Kuncinya adalah menghindari kompleksitas dan birokrasi yang tidak perlu.
- Penting untuk menciptakan lingkungan yang meningkatkan moral tim dan mendorong kolaborasi. Ini berdampak langsung pada peningkatan produktivitas.
- Artikel ini membantu memahami kompleksitas rekayasa perangkat lunak dan manajemen. Terutama, artikel ini memberikan wawasan yang berguna bagi engineer junior.
- Proyek lain dengan fungsi serupa termasuk buku seperti "The Phoenix Project". Buku tersebut membahas cara meningkatkan efisiensi IT dan DevOps.
11 komentar
Apakah ada perusahaan yang tidak seperti itu? huhu. huhu
Bahkan perusahaan kecil yang sukses pun, begitu membesar, rasanya semuanya jadi seperti itu...
Sepertinya sebagian besar berisi hal-hal yang diperintahkan di perusahaan saya sebelumnya. Pemaksaan penggunaan platform yang bahkan tidak terpakai... mengabaikan metrik kinerja standar... menyuruh mengerjakan lagi task yang sudah pernah dikerjakan, dan sebagainya
Eh..?
Ini benar-benar seperti 'Cara membuat kode yang sulit dipelihara: Anda juga bisa santai hidup sebagai developer seumur hidup'...
Saya akan memilih mati.
Aduh.. aduh!.. aaah!!.. ah!... a......
Sedihnya, beberapa hal seperti itu juga terlihat di dalam organisasi kami. terisak
Saya jadi teringat buku legendaris "Cara Menulis Kode agar Sulit Dipelihara".
Saya juga buku ini!
Sebanyak itu? Mungkin ada yang berpikir begitu, tetapi rasanya hal-hal di atas juga bisa dicapai oleh satu orang atau satu organisasi.^^
Opini Hacker News
Kurang yakin apakah usulan CIA benar-benar efektif: Saya belum pernah melihat alasan yang meyakinkan bahwa usulan CIA itu benar-benar efektif sejak awal, dan organisasi secara alami cenderung mengabaikan orang-orang seperti itu.
Cara menghancurkan perusahaan: Mempromosikan orang yang buruk ke posisi manajemen dan mengoptimalkan hal-hal yang tidak menguntungkan dapat memberi pukulan besar pada perusahaan.
Cara menjadi CTO yang destruktif: Sangat mudah untuk hampir tidak melakukan apa-apa, menyingkirkan orang-orang yang kompeten, dan membangun budaya yang mendorong tanggung jawab ke bawah.
Bekerja melalui saluran resmi dan menuntut perintah tertulis: Bagi sebagian orang, bekerja melalui saluran resmi dan menuntut perintah tertulis bisa jadi lebih produktif.
Perbedaan OSS dan CIA: OSS (Office of Strategic Services) membuat buku yang sangat bagus selama Perang Dunia II, dan CIA didirikan pada 1947.
Pentingnya visi: Langkah paling penting adalah menyingkirkan orang-orang yang memiliki visi yang konsisten tentang cara kerja keseluruhan produk atau masa depan yang lebih baik.
Perlu memperbarui bagian perekrutan: Perlu menuntut penyelesaian soal Leetcode yang sulit dalam 30 menit, serta tidak mentoleransi ketidakpastian dan keraguan.
Perbedaan antara lingkungan produksi dan lingkungan pengembang: Dalam arsitektur modern, ada begitu banyak layanan eksternal sehingga lingkungan produksi dan lingkungan pengembang mau tak mau berbeda, yang berarti para pengembang harus selalu terhubung ke internet.
Keputusan untuk melindungi diri sendiri: Banyak keputusan untuk melakukan "sabotase" berkaitan dengan meyakinkan orang lain bahwa itu adalah upaya untuk menutupi kesalahan diri sendiri.
"Praktik terbaik" di perusahaan: Delapan aturan yang disajikan di awal artikel dijalankan secara ketat sebagai "praktik terbaik" di perusahaan.
Perilaku para konsultan: Banyak konsultan melakukan sebagian besar, kalau bukan semuanya, dari perilaku ini.
Masalah di industri teknologi: Di industri teknologi ada banyak orang yang melakukan perilaku ini, dan mereka percaya bahwa mereka sedang membantu.
Pengalaman di perusahaan besar: Pengalaman terbatas di perusahaan besar sangat selaras dengan isi tulisan ini.