- Proyek pelanggan besar dari perusahaan Fortune 500 dimulai dengan ketergantungan pada produk vendor, tetapi kenyataannya itu adalah perangkat lunak yang nyaris seperti produk setengah jadi dan memerlukan kustomisasi berat
- Integrasi vendor menciptakan sekaligus kelemahan paket yang tidak fleksibel dan pengembangan kustom, lalu berujung pada death march integrasi untuk mengejar penyerahan pada Agustus dan peluncuran pada Oktober
- Desain yang menyimpan semua transaksi pelanggan dalam satu dokumen JSON raksasa menimbulkan masalah performa, dan batas 16MB per dokumen di MongoDB pada saat itu terbukti menjadi batas fatal saat migrasi data nyata
- Perusahaan menyembunyikan masalah itu dari pelanggan dan vendor, menunda peluncuran satu bulan, lalu menjalankan penulisan ulang skunkworks untuk menggantikan integrasi vendor dengan tim internal beranggotakan 3 orang dalam sekitar 2 bulan
- Ketika CTO memerintahkan kerja saat liburan tepat sebelum Natal, pimpinan tim melaporkan seolah-olah pekerjaan yang sebenarnya sudah selesai masih terus berlangsung setiap hari agar para pengembang bisa beristirahat, dan tim tetap memenuhi jadwal pengujian Januari serta peluncuran
Desain keliru yang dimulai dari produk vendor
- Di sebuah perusahaan Fortune 500, CTO menjanjikan pengiriman proyek besar untuk pelanggan penting yang punya hubungan pribadi dengannya
- Bagian inti dialihdayakan ke outsourcing pada sebuah perusahaan layanan teknologi besar, dan vendor mengklaim mereka punya produk yang akan menangani sebagian besar pekerjaan berat
- Produk aslinya hanya kira-kira sesuai dengan kebutuhan, sehingga diperlukan kustomisasi besar untuk menghasilkan perilaku yang dibutuhkan
- Akibatnya, kelemahan perangkat lunak vendor dan perangkat lunak kustom muncul bersamaan
- Menjadi paket yang tidak fleksibel karena harus dipaksa melakukan pekerjaan yang berbeda dari tujuan desain awalnya
- Di-fork dari codebase utama vendor sehingga biaya pemeliharaan membengkak, dan ada kemungkinan dukungan akan berakhir suatu saat
- Orang-orang yang terlibat dalam proyek melihat pendekatan ini sebagai ide buruk, tetapi dalam situasi ketika jalur pelaporan langsung CTO sering berubah, rapat status berjalan seperti “ide bagus, Bos”
Jadwal yang meleset dan struktur data yang fatal
- Tim pengembang internal membangun sendiri bagian lain dari proyek, sementara vendor sepanjang musim panas berjanji bahwa produknya segera siap untuk diintegrasikan
- Saat produk vendor diserahkan pada Agustus, dimulailah death march integrasi dengan target peluncuran Oktober
- Pada September, muncul bug yang cukup parah untuk menggagalkan peluncuran
- Produk vendor menyimpan semua transaksi pelanggan sebagai record JSON di dalam satu dokumen JSON raksasa
- Semakin banyak data uji menumpuk, performanya makin melambat
- Setiap kali transaksi baru ditambahkan, seluruh dokumen JSON dibaca dari basis data lalu record baru ditempelkan di bagian akhir
- Vendor mengatakan ini bisa diperbaiki dengan menambahkan indeks pada field transaksi, dan pendekatan itu sempat terlihat membantu untuk sementara
Batas 16MB MongoDB dan penulisan ulang yang disembunyikan
- Masalah yang lebih besar adalah basis data yang dipilih vendor adalah MongoDB, dan saat itu MongoDB memiliki batas 16MB per dokumen
- Pada Oktober, ketika tim migrasi mulai memasukkan data pelanggan nyata, mereka mulai menabrak batas 16MB itu
- Perusahaan memutuskan memulai operasional satu bulan lebih lambat sambil menyembunyikan batas ini dari pelanggan
- Pada saat yang sama, mereka memulai proyek skunkworks untuk menggantikan integrasi vendor
- Vendor juga tidak diberi tahu soal ini
- Artinya, situasi inti ini disembunyikan baik dari pelanggan maupun mitra teknologinya
- Awalnya sekitar 70 orang ditempatkan di sisi vendor, tetapi pekerjaan pengganti internal hanya diberi 3 orang
- 1 orang untuk desain basis data
- 1 orang untuk membangun backend yang berinteraksi dengan basis data
- 1 orang untuk membangun logika bisnis dan layanan web
Keputusan tepat sebelum death march liburan
- Kepada pelanggan disampaikan bahwa versi baru untuk pengujian akan diberikan pada Januari, dan versi itu akan memperbaiki cacat paling kritis yang sempat diterima saat operasional awal dimulai
- Namun fakta bahwa seluruh sistem inti sedang ditulis ulang dalam waktu sekitar 2 bulan tidak diberitahukan kepada pelanggan
- Proyek awal memakan waktu lebih dari 1 tahun hingga peluncuran, tetapi penulisan ulang harus dilakukan oleh 3 orang, termasuk selama masa liburan
- Sekitar pertengahan Desember, para peserta proyek diberi tahu bukan sebagai permintaan melainkan perintah untuk kerja saat liburan
- Sebagian besar anggota tim sudah bekerja 60–80 jam per minggu selama 6 bulan dan berada dalam kondisi burnout
- Peluncuran perangkat lunak memberi tekanan dan imbalan yang mirip dengan pertunjukan panggung
- Hasil persiapan berbulan-bulan atau bertahun-tahun akhirnya sampai ke pengguna nyata pada hari peluncuran
- Pengembang mendapat rasa pencapaian yang kuat dari perasaan “aku berhasil” dan dari reaksi pengguna
- Peluncuran perangkat lunak bisa terasa seperti pertunjukan langsung bagi orang-orang introvert
Seminggu berbohong kepada CTO agar tim bisa istirahat
- Menjelang Natal, tim beranggotakan 3 orang itu hampir menyelesaikan perangkat lunak pengganti hanya dalam waktu 1 bulan
- Masih ada fitur yang perlu dirapikan, tetapi selama tim tidak mengalami burnout, jadwal pengujian Januari masih bisa dipenuhi
- Ketika CTO memerintahkan pembatalan liburan, pimpinan tim secara lahiriah menjawab “OK”
- Kenyataannya, ia berkata kepada 3 pengembang itu, “Istirahatlah seminggu. Biar aku yang urus.”
- Setiap pagi, pimpinan tim masuk ke rapat status wajib dan melaporkan kepada CTO seolah-olah pekerjaan yang sebenarnya sudah selesai bulan lalu masih terus berjalan
- “Tim bekerja sangat keras. Hari ini kami mencapai milestone integrasi #73”
- “Kemarin tim membuat kemajuan yang bagus, dan kami menyelesaikan satu layanan web lagi”
- Para pengembang kembali seminggu kemudian dalam keadaan segar kembali
- Tim memenuhi jadwal Januari, menyelesaikan peluncuran yang baik, dan untuk sesaat merasa seperti bintang rock
- Menurut kenangan mereka, rasanya memang lebih dekat ke Herman’s Hermits daripada The Beatles, tetapi tetap terasa menyenangkan
1 komentar
Komentar Hacker News
Jika seseorang membatalkan cuti dan terus bekerja dengan alasan “berorientasi tenggat”, sebagai orang yang pernah mengalaminya sendiri, saya ingin bilang: berhentilah bertindak bodoh
Sulit sekali untuk berhenti, terutama ketika kerja keras kita diakui, tetapi pada akhirnya Anda akan menyesali semua waktu itu
Jika struktur perusahaan menganggap wajar untuk menarik hari libur dan cuti karyawan demi menjual produk, maka itu ikut membentuk dunia bermasalah yang kita lihat sekarang
Jika banyak orang melakukannya, makin banyak orang lain harus melakukan hal yang sama; tetapi jika tidak ada yang melakukannya dan semua orang bertindak seolah tuntutan semacam itu tidak masuk akal, perusahaan akan membuat estimasi yang realistis meskipun kantong CEO terasa sakit
Cukup beri tahu rencana cuti, siapkan pengganti, masukkan ke kalender tim, lakukan serah terima, lalu beristirahatlah
Proyek datang dan pergi, dan jadwal kadang molor dengan sendirinya
Begitu Anda mulai memindahkan cuti agar sesuai jadwal proyek, seumur hidup Anda tidak akan pernah bisa cuti
Pengecualian mungkin hanya peran dengan periode sibuk yang sudah jelas diketahui, seperti akhir tahun, akhir kuartal, atau musim pajak, sehingga menghilang pada saat itu memang tidak pantas
Sepupu saya bekerja hampir setiap hari sampai pukul 1 dini hari dari September 2023 sampai Januari 2024 untuk menyelesaikan proyek yang dikelola dengan sangat buruk, dan hanya libur saat Natal; itu pun karena direktur mengizinkannya sebab hari libur keagamaan dan khawatir karyawan akan menggugat
Ia melewatkan hal-hal penting dan berat badannya turun sekitar 20 pon karena stres
Perusahaan punya tenggat ketat untuk migrasi ke sistem baru; mereka sudah tahu sejak 5 tahun sebelumnya, tetapi baru mulai tahun sebelumnya
Jika gagal memenuhi tenggat, biayanya bisa mencapai jutaan dolar di luar kontrak, dan pada akhirnya tim berhasil memenuhi tenggat, tetapi imbalannya beberapa minggu kemudian adalah PHK dengan alasan posisinya dihapus
Sekarang, di usia lewat 50-an, ia sedang mencari pekerjaan pada masa terburuk untuk berburu kerja
Mereka kecanduan merasa bernilai dan penting, dan setelah pulang kerja pun tidak punya hal lain untuk dilakukan
Dalam beberapa kasus, karyawan yang menerima penghargaan juga ikut bertanggung jawab atas kekacauan itu
Baru setelah kira-kira kisah keempat, para manajer senior di ruangan itu menyadari bahwa perusahaan memiliki masalah struktural
Jika ada orang muda yang membaca ini, alur cerita seperti ini sangat bergantung pada perusahaan dan keberuntungan
Di perusahaan yang sehat, cara implementasi outsourcing seperti itu kemungkinan besar tidak akan dimulai sejak awal
Karena itu adalah pola kegagalan yang terlalu jelas, yang bisa diprediksi orang berpengalaman sebelum dimulai
Pada tahap yang lebih awal, orang-orang tidak akan berbohong kepada CTO bahwa semuanya berjalan baik, melainkan akan mengatakan bahwa semuanya tidak berjalan baik
Jika diperlukan cara yang lebih cerdas atau kreatif untuk menyelamatkan proyek, mereka akan berkoordinasi dengan CTO, mungkin juga dengan pelanggan
Mereka juga tidak akan memaksa tim yang sudah burnout bekerja berjam-jam pada hari libur
Manajer atau lead akan menantang atasan demi keberhasilan proyek dan kesehatan tim, dan jika perlu bersikeras bahwa tim harus beristirahat pada hari libur
Dalam organisasi yang “setengah sehat”, manajer mungkin sengaja bersikap ambigu atau menghilangkan informasi, dan baik buruknya itu bergantung pada situasi
Namun jika, seperti dalam cerita ini, manajer atau lead berulang kali berbohong secara terang-terangan ke atas dalam rantai komando, biasanya itu dianggap sangat buruk, baik di perusahaan sehat maupun tidak
Tentu situasi seperti ini jauh lebih mudah dinilai belakangan sambil bersedekap
Di posisi sulit atau saat kelelahan karena kerja berlebihan, siapa pun bisa melakukan kesalahan, tetapi ada gunanya melihat skenario seperti ini dan belajar agar bisa merespons lebih baik ketika kembali dilempar ke situasi berat yang serupa
Jika Anda berada di perusahaan seperti ini, sebaiknya mulai mencari pekerjaan baru
Jika kebusukan di atas sudah sejauh ini, itu mustahil diperbaiki, dan mereka juga tidak akan menjadikan Anda CTO
Selama 25 tahun bekerja, saya belum pernah melihatnya sekali pun
Butuh satu setengah tahun untuk memperbaikinya, dan selama itu penjualan tidak bisa dibatalkan dengan alasan “pakaian dalam” sudah dikirim
Padahal sebenarnya kami tidak menjual pakaian dalam, hanya layanan jaringan, tetapi kami baru bisa membantu pelanggan setelah sistem selesai menutup proses pesanan
Anggota dewan itu pergi setahun kemudian, dan saya rasa ia cukup puas karena berhasil menipu CEO yang bodoh
Pada akhirnya saya di-PHK dari sana, dan saya sama sekali tidak bersimpati pada perusahaan yang kalang kabut itu
Mereka adalah orang-orang bodoh yang mencoba mengalihdayakan “solusi” dan hanya menambah penderitaan bagi semua orang
Memang ada masalah yang benar-benar perlu diselesaikan, tetapi separuhnya hanyalah sampah untuk memberi kesan “menghemat uang dengan tidak membangunnya sendiri”
Pada akhirnya, mereka harus terus membayar biaya kontrak untuk memelihara sampah yang sejak awal tidak mereka buat sendiri
Maksudnya menyampaikan fakta apa adanya tanpa menyembunyikan masalah, tetapi itu benar-benar jarang terjadi
Lihat saja memo keamanan Microsoft
Bahwa tidak ada death march pada hari libur memang cukup benar jika Anda bekerja di bank atau FAANG
Kalau perusahaannya punya “budaya startup”, sebaiknya lupakan saja
Dalam praktiknya, ketika kepentingan pribadi ikut dipertaruhkan, sikap terhadap pekerjaan berubah cukup cepat, tetapi menurut saya tidak banyak perusahaan yang memberi kesempatan seperti itu sehingga kita bisa melihatnya
Saya sering menyelesaikan hal yang perlu dilakukan diam-diam tengah malam dengan membengkokkan aturan, dan banyak orang kompeten juga menempuh jalan seperti itu
Bahkan di bank pun saya pernah melihat hal seperti ini
Selama Anda tidak membuat taruhan finansial yang lebih besar daripada nilai perusahaan atau tim, banyak hal bisa saja dibiarkan berlalu
Entah Anda berhasil lalu dipromosikan, atau karena Anda sendiri sudah mengurangi peluang promosi, Anda akhirnya mencari pekerjaan baru
Bagian yang mengatakan “produk vendor menyimpan semua transaksi pelanggan sebagai record JSON di dalam sebuah dokumen JSON raksasa, dan untuk menambahkan transaksi baru, ia membaca seluruh dokumen JSON dari database lalu menempelkan record baru di bagian akhir” memang seharusnya terdengar gila
Mirip dengan itu, saya pernah membantu technical due diligence untuk sebuah fund terhadap calon investasi, dan tabel pengguna startup itu juga berisi data tiket/reservasi
Karena satu tiket adalah satu kolom, jika pengguna paling aktif punya 5 tiket sepanjang riwayatnya, diperlukan 5 kolom
Saat ditinjau, sudah ada lebih dari 500 kolom, dan mereka sedang mencari investasi untuk “scaling”
Tentu saja itu masalah yang bisa diselesaikan, tetapi seperti yang bisa diduga, semuanya dirancang dengan cara yang terbalik dan kusut, dan itu adalah momen “apa-apaan ini” yang paling jelas
Mereka tidak mendapat investasi
Seluruh database pelanggan dan produk disimpan bersama password plaintext dalam satu file
.jspublik berukuran beberapa megabyte, dan dengan kecepatan internet awal 2000-an, aplikasi harus memuat seluruh file itu sebelum bisa melakukan apa punSelain itu, aplikasinya adalah satu file raksasa, dan direktorinya penuh dengan nama seperti
index.1.js,index.final.js,index.newest.js,index.45.jsSaya punya cukup pengalaman untuk tahu praktik yang baik, jadi saya mendatangi CEO dan membuatnya memecat CTO, lalu mulai membangun ulang dengan
git,mysql, logika sisi server, dan struktur yang sungguhanSetelah itu, server Windows tempat semua ini berjalan diretas dan berubah menjadi server porno; saya bahkan belum pernah melihat server itu dan tidak punya hak admin, tetapi entah bagaimana itu menjadi tanggung jawab saya
Beberapa pekerjaan awal benar-benar mendidik
Seorang engineer senior yang membanggakan diri sebagai lulusan Stanford merancang sistem itu
Saya berdebat panjang lebar, berdasarkan data operasional nyata, bahwa sistem itu tidak akan bisa diskalakan jika diluncurkan, tetapi tidak ada yang mendengar, dan beberapa minggu setelah rilis sistemnya ambruk
Tak lama kemudian saya pindah tim, dan yang paling buruk adalah engineer senior itu akhirnya dipromosikan, sementara sistem tersebut diserahkan ke tim yang benar-benar baru agar mereka yang bergulat dengannya
Desain keseluruhan sistemnya mengerikan, dan Anda mungkin bisa menebak alasannya
Mereka meluluhkan para eksekutif dengan makan malam mewah dan perjalanan, lalu menyerahkan produk berantakan agar mereka tetap terus dibutuhkan ke depannya
Dalam cerita itu sendiri, CTO tidak tahu apa-apa
Dari sudut pandangnya, pada akhirnya semuanya tampak berjalan baik
Ini kemenangan untuk semua orang, kecuali para developer yang bekerja 80 jam seminggu
Semua hal dalam cerita ini rusak, termasuk pendekatan tokoh utamanya
Seorang team lead memberi orang-orang cuti lalu menyembunyikannya dengan berbohong itu sama sekali tidak bisa diterima, dan cukup masuk ke wilayah yang bisa membuat perusahaan memecatnya
Bahkan tampaknya bisa menjadi pemecatan dengan alasan yang sah
Namun, karena jajaran atasnya tampak sudah sangat melenceng, mungkin saja itu dibiarkan dan bahkan dipuji
Memang terlihat seperti tindakan yang disesuaikan dengan lingkungan tempat ia berada
Jika memberi saran kepada team lead baru, tidak ada yang patut dibanggakan di sini; pilihan yang lebih baik adalah mengangkat masalah besar bahwa orang-orang sedang lembur, dan menuntut vendor menerapkan standar yang normal atau meninjau ulang cakupan proyek agar sesuai dengan minggu kerja normal
Jika Anda membuat situasi seperti ini tetap berjalan entah bagaimana caranya, orang-orang bisa saja burnout atau dipecat tanpa mendapat keuntungan apa pun
Kecuali Anda benar-benar terdesak untuk menafkahi keluarga, team lead bertanggung jawab melindungi jam kerja yang wajar bagi timnya dari tuntutan gila
Itu adalah bukit yang layak dipertahankan meski harus siap dipecat, bukan bukit untuk berbohong
Jadi selama tidak memengaruhi hasil kerja, team leader memberi orang-orang cuti, bahkan sampai berbohong, masih cukup bisa diterima
Kalau dibagikan, apa yang akan dilakukan manajemen? Mereka akan memajukan proyek lebih cepat lagi
Orang-orang yang ingin membuat orang lain bekerja lebih keras demi kejayaan mereka sendiri memang perlu diberi pelajaran
Sebenarnya hari siapa yang diselamatkan?
Vendor buruk yang mengirim sampah?
CTO yang jelas mengelilingi dirinya dengan yes-man dan sama sekali tidak tahu apa yang terjadi di perusahaan?
Para developer yang bekerja sampai remuk tulangnya, tetapi akhirnya jadi “tidak apa-apa, kan aku sudah memberimu libur seminggu”?
Tokoh utama yang berbohong kepada semua orang demi memenuhi tenggat sewenang-wenang perusahaan yang tidak peduli pada karyawannya?
Cerita ini membuat saya bergidik di setiap momennya
Saya termasuk orang yang bekerja keras, dan kadang bekerja ekstra agar peluncuran untuk pelanggan berjalan mulus, tetapi cerita ini adalah kegilaan murni
Saya kadang meluangkan waktu lebih karena ada hubungan saling percaya dengan atasan, dan saya tahu saya selalu bisa mengatakan yang sebenarnya
Sebenarnya itulah konsep inti dari budaya tanpa menyalahkan, dan itu hanya mungkin jika semua orang mengatakan kebenaran
Berbohong habis-habisan demi memenuhi tenggat CTO bodoh itu benar-benar tidak waras
Jika Anda berada dalam situasi seperti ini, segera keluar dan cari tempat kerja yang lebih baik
“Rasa bangga dan pencapaian” lalu burnout?
Kata “kami” dalam bagian “kami juga memenuhi jadwal Januari, meluncurkannya dengan hebat, dan sempat menjadi rockstar” jelas berarti saya
Mungkin saya hanya beruntung, tetapi saya tidak pernah dipecat karena mengatakan kebenaran, dan kebenaran lebih mudah untuk diselaraskan
Misalnya dengan mengatakan, “Ada bug di pustaka pihak ketiga yang berada di jalur kritis. Kita bisa membuat bug itu lebih sulit terkena, tetapi kita tidak bisa memperbaikinya sebelum vendor memperbaikinya,” atau, “Pertumbuhan pengguna membuat masalah performa muncul lebih cepat dari perkiraan. Selama 2 bulan yang dibutuhkan untuk memperbaikinya, kita bisa meredakannya dengan mengeluarkan biaya infrastruktur tiga kali lipat, atau kehilangan pelanggan karena performa,” atau, “Pelanggan terbesar baru tahu apa yang mereka inginkan setelah menerima iterasi pertama. Itu sama sekali berbeda dari yang kita kira akan kita bangun. Kita bisa membangunnya lalu menghasilkan uang, atau mengejar mimpi saja lalu mati.”
Sekali lagi, mungkin saya hanya beruntung, tetapi kejujuran bekerja dengan baik bagi saya
Jadi seperti yang dikatakan orang lain, katakan “akan saya tinjau” lalu dorong perlahan ke pinggir, atau tempatkan mereka pada pekerjaan remeh
Pilihan kedua adalah diam saja dan menyaksikan mereka berjuang lama lalu gagal
Biasanya butuh sekitar 1 tahun, tetapi saya juga pernah melihat sesuatu dilipat dalam 2–3 bulan dan pada kuartal berikutnya kepemimpinannya praktis dipangkas
Jika seseorang meminta pendapat, Anda bisa menjelaskan kekhawatiran secara diplomatis, tetapi jika tidak ditanya, Anda juga bisa tetap diam
Intinya adalah apakah Anda akan secara aktif menunjukkan masalah dalam rencana orang yang posisinya lebih tinggi dari Anda dan yang ingin mengambil kredit
Begitu Anda mengatakannya, mereka merasa penilaian mereka diragukan dan menerimanya sebagai serangan pribadi
Sangat sulit melakukannya tanpa menciptakan musuh, dan musuh bertahan lama; kerugian dari satu musuh sulit ditutupi bahkan oleh beberapa teman
Jadi Anda harus memainkan permainannya
Fakta bahwa tokoh utama berbohong tentang pekerjaan yang sebenarnya sudah selesai adalah detail yang sangat penting
Setiap pagi ia masuk ke rapat status death march wajib dengan CTO dan berkata, “tim bekerja keras,” “hari ini kami mencapai titik integrasi milestone #73,” “kemarin ada kemajuan bagus dan kami menyelesaikan satu web service lagi,” padahal sebenarnya itu adalah pekerjaan yang sudah diselesaikan pada bulan sebelumnya
Dari sudut tertentu, ini terlihat seperti menjanjikan rendah dan memberikan lebih
Kalau ia berbohong bahwa pekerjaan yang belum selesai sudah selesai, rasanya akan jauh lebih buruk
Itu jelas lebih berisiko, dan ketika tim kembali, mengatakan “ini tiket-tiketnya, tapi saya sudah bilang ke CTO bahwa semuanya selesai, jadi cepat kerjakan” juga tidak akan baik bagi tim
Interaksi antara developer dan manajemen sangat menderita karena asimetri informasi dan kurangnya kepercayaan
Saat ini saya sedang mengerjakan proyek untuk memperbarui codebase yang berjalan di compiler yang sangat tua
Kami sudah mengerjakannya selama 1 tahun dan bagian-bagian besar sistem sudah selesai, tetapi masih ada satu bagian yang cukup penting tersisa
Manajemen tidak memahami prosesnya dan juga tidak yakin bahwa proyek ini pada akhirnya akan berhasil
Saya tidak menyalahkan mereka karena cemas, karena proyek software, terutama pekerjaan migrasi, punya sejarah panjang kegagalan
Rapat progres tadinya dilakukan setiap minggu, dan sekarang meningkat menjadi 2 kali seminggu; sepertinya mereka berpikir itu akan membuatnya lebih cepat
Mereka biasanya tidak hadir langsung, dan manajer menengah berperan sebagai penyampai pesan
Dari sudut pandang developer, tentu saja ini akan berhasil, dan secara pribadi saya tidak pernah meragukan keberhasilannya
Hanya saja sistemnya besar dan tua, sehingga durasinya tidak pasti
Yang tersisa bukan hitungan tahun, melainkan bulan; saya juga tahu aturan 80/20, tetapi kami sudah masuk cukup dalam ke 20% itu
Bagi manajemen, statusnya hanya biner: selesai/belum selesai, sehingga sulit menilai progres, dan tidak ada “kepercayaan” pada apa yang kami katakan
Saya bisa memahaminya
Bahkan jika selama 1 tahun kami tidak melakukan apa-apa dan hanya mengadakan rapat, mereka tidak akan tahu
Karena ini kontrak harga tetap, kami tidak punya alasan untuk mengulur-ulur, tetapi seluruh risikonya ada pada mereka
Mereka sudah menghabiskan banyak uang dan merasa cemas
Mereka sudah membuat keputusan teknis yang baik berdasarkan saran pakar teknis eksternal, tetapi tetap kurang yakin
Pada akhirnya, jika proyek gagal, merekalah yang terkena dampaknya, bukan kami, relatifnya
Tidak ada solusi mudah
Kita tidak bisa sekadar mengatakan para manajer harus teknis, dan teknologi itu juga bukan bisnis inti mereka
Mendatangkan lebih banyak konsultan pun tidak akan membuat hati mereka lebih tenang
Hal terbaik yang bisa kami lakukan adalah terus maju dan mengirimkannya
Bahkan jika berupa potongan satu bulanan, pecah saja menjadi lebih rinci, dan bagi semuanya menjadi subtugas
Tidak harus sempurna, dan tidak apa-apa jika masih kasar
Saya menyarankan memberi tiap potongan nama yang ramah dan menyenangkan
Misalnya nama tarian klasik seperti tango, cha-cha, atau waltz bagus
Jadwalkan rapat dengan para manajer, termasuk manajer senior, dan minta manajer menengah ikut mengamati daily standup
Buat semua orang berdiri agar rapat cepat selesai, dan lacak progres terhadap pekerjaan yang ada di daftar
Jika satu pekerjaan ditambahkan atau sedikit terlambat, itu tidak akan mengejutkan orang selama secara keseluruhan tetap mendekati target
Kita berdua tahu deployment sebenarnya adalah rintangan besar, tetapi tidak perlu memberi tahu mereka sampai semuanya siap
Keterlambatan membuat manajemen cemas, dan itu bisa dimengerti, tetapi lebih banyak rapat tidak akan membuatnya lebih cepat
PM yang check-in 30 menit setiap hari sambil berkata “saya akan mendukung dan menyediakan apa pun yang diperlukan untuk mengembalikan proyek ke jalur yang benar” tidak membantu
Yang dibutuhkan hanyalah lebih sedikit rapat
Hambatannya hanya waktu, dan alasan waktu menjadi hambatan pun karena sejak awal pihak atas bersikeras pada jadwal yang tidak realistis
Pada akhirnya, dengan menunjukkan bahwa mereka tidak memercayai developer, mereka juga berarti tidak memercayai kemampuan manajerial mereka sendiri dalam merekrut developer yang tepat
Mereka sangat buruk dalam salah satu bagian inti pekerjaan mereka
Proyek 1 tahun tidak semestinya berstatus biner selesai/belum selesai
Harus ada indikator progres yang bisa ditangani
Eksekutif puncak tidak harus teknis, tetapi di suatu lapisan hierarki harus ada seseorang yang mampu menerjemahkan progres ke dalam format yang dapat dipahami
Ada dua hal yang saya tahu pasti tentang vendor itu yang sulit dimaafkan
Yang pertama, mereka membuat logika inti bergantung pada pembesaran record Mongo tanpa batas; yang kedua, tiga orang yang sedikit di atas rata-rata, jika berupaya secara sengaja, bisa menggantinya dalam sekitar 3 bulan
Fakta bahwa vendor itu bisa sampai pada tahap berurusan dengan pelanggan Fortune 500 menunjukkan betapa organisasi yang mirip dengan pelanggan ini merasa tidak berdaya bahkan di hadapan pekerjaan software yang tidak terlalu besar
Sebenarnya, cakupan proyek itu tampaknya bisa dikerjakan sebagai proyek hobi oleh beberapa orang di sini
Jadi saya juga paham mengapa Retool populer di kalangan pemimpin teknologi, tetapi belum tentu di kalangan engineer
Saya penasaran pendekatan produk lain apa yang bisa menjembatani kesenjangan yang sama
Berkat spreadsheet, siapa pun di level jabatan rendah bisa membuat prototipe tool kasar yang hampir berfungsi dalam beberapa hari, tanpa harus berurusan dengan orang lain di organisasi
Sebelum spreadsheet, Anda harus meyakinkan atasan agar departemen IT mengambil permintaan tersebut, dan proses itu saja setidaknya memakan waktu 3 bulan
Setelah itu, Anda mungkin masih harus menunggu beberapa kuartal lagi untuk menerima implementasi kasar yang hampir berfungsi, ditulis dengan sesuatu seperti Cobol atau C, dan tidak sesuai dengan kebutuhan
Beberapa developer dan beberapa staf support pergi menemui para pengguna, dan para developer itu sudah 6 bulan membuat tool baru untuk menyelesaikan masalah besar
Namun hari itu adalah pertama kalinya para pengguna akhir melihatnya
Tak lama kemudian kami sudah dalam perjalanan pulang melintasi perbatasan negara bagian, dan para developer tampak tertunduk lesu
Sepengetahuan saya, proyek itu tidak pernah dibicarakan lagi
Modelnya menyuruh para karyawan baru mengerjakan semuanya lalu menagihnya dengan tarif per jam developer senior
Saya berharap orang-orang berhenti memakai gambar header buatan AI
Sejak awal sudah memecah konsentrasi
Apakah kodenya ada di belakang monitor?
Dan apakah ada kode juga di sandaran kursi di belakang? Atau yang diduduki itu iPad raksasa?
Kalau mau memakai gambar AI, setidaknya berusahalah agar tidak terlihat sepenuhnya aneh dan gila
Gambar seperti ini secara harfiah bisa dibuat dalam hitungan detik; apakah ini yang terbaik dari pilihan yang ada?