Project manager
Project manager bertanggung jawab agar sebuah pekerjaan benar-benar sampai â terurut, tersedia sumber dayanya, bebas hambatan, dan terlihat oleh pihak yang membiayainya. Peran ini kerap disalahpahami sebagai pekerjaan administratif karena artefaknya berupa dokumen dan rapat, padahal substansinya adalah pertimbangan tentang dependency, risiko dan di mana sebuah rencana diam-diam mulai gagal. Uraian berikut menjelaskan disiplinnya, kondisi yang membuatnya sepadan dengan biayanya, dan bagaimana ia bekerja berdampingan dengan tim yang mengerjakannya.
Apa yang dikerjakan seorang project manager?
Project manager memegang delivery dari satu paket pekerjaan yang terdefinisi: menyepakati ruang lingkup dan urutannya, memetakan dependency antar tim dan pemasok, memantau lini masa dan anggaran terhadap rencana, memunculkan risiko selagi masih bisa ditindaklanjuti, menyingkirkan hambatan yang tidak bisa disingkirkan sendiri oleh tim pelaksana, dan menjaga stakeholder tetap memperoleh gambaran yang bisa mereka tindaklanjuti. Tanggung jawabnya adalah agar pekerjaan itu sampai selesai â bukan menentukan apa yang semestinya dibangun organisasi, karena itu milik product.
Perbedaan antara tanggung jawab atas delivery dan tanggung jawab atas produk adalah sumber kebingungan terbesar di sekitar peran ini. Seorang project manager bisa sepenuhnya berhasil pada proyek yang semestinya tidak pernah dimulai, dan sepenuhnya gagal pada proyek yang berharga. Pertanyaannya adalah apakah pekerjaan yang sudah dikomitmenkan sampai ke production secara terprediksi; pertanyaan apakah pekerjaan itu layak dikomitmenkan adalah pertanyaan orang lain.
Sebagian besar kesulitan sebenarnya berada pada dependency. Setiap proyek yang berarti bergantung pada hal-hal di luar tim pelaksana â sebuah security review, kontrak vendor, migrasi data, API tim lain, persetujuan legal, waktu tunggu perangkat keras, satu orang yang akan cuti dua minggu lagi. Masing-masing tampak baik-baik saja secara terpisah dan masing-masing punya tanggal terakhir yang masih bertanggung jawab. Memegang jalinan itu dalam pandangan, dan bertindak berminggu-minggu sebelum ia menjadi mendesak, adalah bagian pekerjaan yang paling sulit diamati sekaligus paling mahal bila diabaikan.
Kesulitan kedua adalah pelaporan yang jujur di bawah tekanan. Proyek jarang gagal secara mendadak; ia gagal lewat rangkaian pembacaan optimistis kecil yang masing-masing bisa dibela. Project manager yang melaporkan apa yang benar-benar terjadi â termasuk bahwa sebuah tanggal sudah tidak kredibel â memberi organisasinya kesempatan untuk merespons. Yang melaporkan hal-hal yang nyaman didengar menghapus kesempatan itu, dan kegagalannya datang sekaligus, terlambat.
Kapan tim membutuhkan kapabilitas ini
Koordinasi delivery biasanya diserap tech lead atau engineering manager sampai permukaan koordinasinya tumbuh lebih cepat daripada kapasitas mereka untuk itu. Berikut tekanan yang biasanya membuat project management khusus sepadan dengan biayanya.
Pekerjaannya melintasi lebih dari satu tim atau pemasok
Begitu delivery bergantung pada roadmap tim lain, vendor eksternal, kelompok infrastruktur atau persetujuan di sisi klien, koordinasinya berhenti menjadi sesuatu yang insidental. Tidak ada orang di dalam satu tim yang bisa melihat keseluruhan jalur kritis, dan serah terima antar tim menjadi tempat minggu-minggu menghilang.
Pemimpin engineering menghabiskan pekannya untuk koordinasi
Tech lead yang menjadwalkan rapat, mengejar persetujuan dan menyusun laporan status sedang mengerjakan hal yang perlu dengan nilai tukar yang buruk. Sinyal yang lazim adalah engineer senior yang kalendernya penuh dan kontribusi teknisnya diam-diam berhenti, dan itu mahal dua kali.
Komitmennya membawa konsekuensi eksternal
Tenggat regulasi, milestone kontraktual, sebuah pameran dagang, tanggal integrasi mitra, atau migrasi dengan batas waktu penonaktifan sistem lama. Ketika melewatkan sebuah tanggal berkonsekuensi lebih dari sekadar kekecewaan, seseorang perlu melacak jalannya secara sengaja alih-alih berharap irama sprint akan sampai ke sana.
Tidak ada yang bisa menyebutkan keadaan pekerjaannya
Orang yang berbeda memberi jawaban berbeda tentang apa yang selesai, apa yang terhambat dan apa yang tersisa. Ini jarang soal ketidakjujuran; ini ketiadaan satu gambaran yang terpelihara. Biayanya muncul sebagai keputusan yang diambil di atas informasi basi, dan sebagai kejutan yang sebenarnya sudah terlihat oleh seseorang berminggu-minggu sebelumnya.
Ruang lingkup terus bertambah tanpa keputusan yang menyertainya
Permintaan datang lewat jalur samping, diserap oleh siapa pun yang mendengarnya lebih dulu, dan tidak pernah muncul di dalam rencana. Tanggalnya tidak bergeser karena tidak ada yang menghubungkan tambahan itu dengannya, dan kekurangannya baru terlihat ketika tanggalnya tiba.
Sebuah program pekerjaan membutuhkan pengurutan, bukan backlog
Migrasi, penggantian platform, peluncuran ke pasar baru dan integrasi punya urutan yang penting â langkah yang tidak bisa dimulai sebelum yang lain selesai, dan jendela waktu yang tidak bisa digeser. Struktur itu perlu direncanakan secara eksplisit, dan memperlakukannya sebagai daftar tiket berprioritas menghilangkan batasan yang justru mengaturnya.
Kapabilitas inti
Menetapkan dan menjaga ruang lingkup
Menetapkan apa yang termasuk dalam proyek, apa yang secara eksplisit tidak termasuk, dan apa arti selesai untuk setiap bagiannya. Sebagian besar sengketa ruang lingkup bukan perbedaan pendapat tentang pekerjaan melainkan tentang batas yang tidak pernah dituliskan siapa pun, dan bagian pengecualiannya justru sering lebih berharga.
Pengurutan dan perencanaan
Memecah pekerjaan sampai ke tingkat yang membuat estimasi bermakna, mengurutkannya terhadap batasan yang nyata, dan mengenali jalur di mana keterlambatan merambat alih-alih terserap. Rencana yang nilainya hanya karena ia ada bukanlah rencana; keluaran yang berguna adalah mengetahui item mana yang tidak bisa mundur tanpa menggeser tanggal akhirnya.
Pengelolaan dependency
Melacak setiap masukan yang tidak dikendalikan tim â tim lain, vendor, persetujuan, environment, data, orang â masing-masing dengan tanggal terakhir yang masih bertanggung jawab, serta kebiasaan tetap mengejarnya sebelum ia menggigit. Ini bagian disiplin ini yang paling kurang dihargai.
Identifikasi dan respons risiko
Menyebutkan apa yang masuk akal bisa salah, menilai kemungkinan terhadap dampaknya secara jujur, dan â bagian yang sering dilewati â menyepakati pemilik serta responsnya untuk yang benar-benar penting. Register risiko yang dipelihara sebagai dokumen alih-alih sebagai kumpulan keputusan adalah beban administratif tanpa hasil.
Menyingkirkan hambatan
Mencari tahu apa yang sebenarnya menghentikan kemajuan lalu pergi menyelesaikannya: environment yang tidak dimiliki siapa pun, permintaan akses yang mengantre, keputusan yang menunggu seseorang yang tidak tahu bahwa ia sedang ditunggu. Apakah seorang project manager melakukan ini atau sekadar mencatatnya adalah pembeda paling jelas di profesi ini.
Komunikasi dengan stakeholder
Mengetahui siapa membutuhkan informasi apa, sedalam apa dan seberapa sering, lalu memberi sponsor versi yang bisa ditindaklanjuti alih-alih versi yang paling mudah disusun. Audiens yang berbeda benar-benar membutuhkan laporan yang berbeda, dan satu pembaruan yang diedarkan ke semua orang biasanya tidak melayani siapa pun.
Pemantauan lini masa dan anggaran
Mengikuti kemajuan dan pengeluaran yang sebenarnya terhadap baseline yang dikomitmenkan, dan memahami variansnya cukup dalam untuk menjelaskan penyebabnya. Nilainya ada pada peringatan dini: tren yang teridentifikasi selagi masih ada ruang untuk merespons lebih berharga daripada angka presisi yang datang setelahnya.
Pengelolaan perubahan
Menangani permintaan yang datang setelah rencana ditetapkan â menilai pengaruhnya terhadap ruang lingkup, urutan, biaya dan tanggal, lalu menyodorkan trade-off itu kepada pihak yang memiliki keputusannya. Pola kegagalannya adalah penyerapan diam-diam, ketika serangkaian penambahan yang masuk akal menghabiskan cadangan waktu tanpa ada yang memilih untuk membelanjakannya.
Pertimbangan dalam estimasi dan proyeksi
Bekerja dengan estimasi sambil mengingat apa itu estimasi. Artinya memakai rentang alih-alih angka tunggal ketika ketidakpastiannya nyata, memakai throughput yang teramati alih-alih optimisme, dan menahan refleks mengubah sebuah proyeksi menjadi komitmen hanya karena komitmen itulah yang ingin didengar ruangan.
Tata kelola dan kebersihan keputusan
Memastikan keputusan benar-benar diambil, tercatat beserta alasannya, dan disampaikan kepada orang yang terdampak. Bagian keterlambatan yang mengejutkan besar bukan berasal dari ketidaksepakatan melainkan dari keputusan yang semua orang yakini sudah diambil orang lain.
Bagaimana disiplin ini bekerja
Manajemen proyek adalah sebuah praktik, bukan sebuah toolchain. Karena itu berikut ini menguraikan pendekatan delivery, teknik perencanaan dan artefak yang menjadi sandaran disiplin ini di pasar â gambaran tentang bagaimana pekerjaannya dilakukan, bukan klaim tentang perkakas praktisi mana pun secara khusus. Tooling jauh kurang penting di sini dibanding pada peran engineering: teknik yang sama diterapkan di hampir semua sistem pelacakan, dan seorang kandidat lebih baik dinilai dari cara ia merencanakan, memproyeksikan dan melakukan eskalasi daripada dari produk apa yang kebetulan dilisensikan pemberi kerjanya yang terakhir.
Pendekatan delivery
- Scrum
- Kanban
- Tata kelola hibrida dan bertahap
- Delivery inkremental
- Koordinasi program dan portofolio
Teknik perencanaan dan pengurutan
- Work breakdown
- Pemetaan dependency
- Analisis jalur kritis
- Perencanaan milestone
- Rolling-wave planning
- Proyeksi kapasitas dan throughput
Praktik risiko dan perubahan
- Register risiko
- RAID log
- Penilaian kemungkinan dan dampak
- Perencanaan mitigasi dan kontingensi
- Change control
- Jalur eskalasi
Artefak pelaporan dan proyeksi
- Pelaporan status
- Burn-up dan burn-down chart
- Cumulative flow diagram
- Ukuran cycle time dan throughput
- Pelaporan milestone dan varians
- Pemantauan anggaran dan pengeluaran
Praktik stakeholder dan tata kelola
- Pemetaan stakeholder
- Matriks penetapan tanggung jawab
- Perencanaan komunikasi
- Forum steering dan tata kelola
- Log keputusan dan tindakan
Kategori tool yang lazim
- Sistem pelacakan pekerjaan
- Perencana roadmap dan lini masa
- Basis dokumentasi dan pengetahuan
- Spreadsheet dan model proyeksi
- Platform komunikasi asinkron
Bagaimana peran ini bekerja dengan tim Anda
Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.
Tetap milik Anda
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Ditangani Talent.ID
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Seperti apa ini dalam praktik
Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.
- Tantangan
- Sebuah organisasi menjalankan migrasi platform berdampingan dengan roadmap normalnya. Pekerjaan engineering-nya sudah dipahami, tetapi ia bergantung pada tim infrastruktur, vendor eksternal dan sebuah security review, dan tidak ada satu orang pun yang memegang urutannya. Tanggal-tanggal disepakati dalam percakapan yang terpisah lalu direkonsiliasi terlambat.
- Pendekatan
- Kapasitas koordinasi delivery tambahan bekerja di dalam tata kelola yang sudah dimiliki klien â irama perencanaan mereka, garis pelaporan mereka, jalur eskalasi mereka dan forum keputusan mereka. Kepemimpinan klien sendiri tetap memegang roadmap, prioritas dan keputusan tentang apa yang harus dicapai migrasi itu; kapasitas tambahan memelihara gambaran dependency, memantau rencananya terhadap gambaran itu, dan memajukan trade-off selagi masih bisa diputuskan.
- Yang ditambahkan ke tim
- Klien memperoleh kapasitas koordinasi tanpa mengalihkan tanggung jawab atas hasilnya. Untuk apa proyek ini ada, apa yang harus tercakup di dalamnya dan kapan ia penting tetap menjadi keputusan orang-orang yang memiliki bisnisnya.
Disiplin terkait
Pertanyaan yang sering diajukan
- Apa bedanya project manager dan business analyst?
- Project manager bertanggung jawab agar pekerjaannya sampai; business analyst bertanggung jawab agar itu pekerjaan yang tepat. Project manager memegang urutan, dependency, risiko, lini masa dan komunikasi, dan bertanya apakah tim bisa sampai ke sana. Business analyst memegang definisi masalah, kebutuhan dan kriteria penerimaan, dan bertanya apa persisnya yang harus ada agar hasilnya tercapai. Pada proyek yang lebih kecil satu orang kadang memegang keduanya, dan hasil yang lazim adalah separuh yang kurang nyaman baginya mendapat perhatian lebih sedikit.
- Apa bedanya project manager dan product owner atau product manager?
- Pembagian yang diniatkan adalah bahwa product menentukan apa yang harus dibangun dan mengapa, sementara project management membuat paket pekerjaan yang sudah dikomitmenkan itu sampai. Product memegang nilai, prioritas dan roadmap; project management memegang urutan, dependency, risiko dan jalan menuju tanggalnya. Dalam praktiknya batas ini belum disepakati di industri â sebagian organisasi mengharapkan product manager menjalankan delivery, sebagian lain mengharapkan project manager membentuk ruang lingkup, dan sebutan jabatannya dipakai tidak konsisten antar perusahaan. Ada baiknya menyepakati secara eksplisit siapa yang menentukan prioritas di struktur Anda sendiri sebelum menambah salah satu peran ini, karena di situlah gesekannya menumpuk.
- Apakah tim agile membutuhkan project manager?
- Praktik agile menghapus kebutuhan akan project manager untuk membagikan tugas dan mengumpulkan status, dan itu memang kemajuan, sehingga sering dibaca sebagai menghapus perannya sepenuhnya. Pekerjaan yang tersisa tetap nyata: dependency lintas tim, pemasok eksternal, komitmen kontraktual dan regulatori, tanggung jawab anggaran serta komunikasi dengan stakeholder di luar tim. Scrum tidak menentukan pemilik untuk satu pun dari semua itu, karena ia menggambarkan satu tim tunggal dan sebagian besar organisasi bukan satu tim. Ketika pekerjaan itu tidak ditugaskan, ia tidak berhenti â ia mendarat pada tech lead atau engineering manager, biasanya dengan mengorbankan hal yang menjadi alasan mereka ada.
- Apa bedanya project manager dengan scrum master atau delivery manager?
- Scrum master berorientasi pada praktik satu tim â memfasilitasi seremoninya, memperbaiki cara kerjanya dan melindunginya dari gangguan â dan tidak memikul tanggung jawab atas sebuah tanggal atau anggaran. Cakupan project manager adalah paket pekerjaan yang biasanya melintasi beberapa tim dan mencakup komitmen di luar mereka. Sebutan delivery manager dipakai untuk keduanya, dan juga untuk gabungan keduanya, sehingga sebutan jabatan saja tidak akan memberi tahu Anda tanggung jawab mana yang benar-benar pernah dipegang seorang kandidat. Tanyakan apa yang menjadi tanggung jawab mereka, bukan apa sebutan jabatannya.
- Apakah project manager perlu latar belakang teknis?
- Mereka butuh literasi teknis, bukan praktik teknis. Cukup untuk mengikuti diskusi arsitektur, membedakan batasan nyata dari preferensi, memahami mengapa sebagian pekerjaan tidak berguna untuk dipecah, dan mengajukan pertanyaan yang tidak langsung menandakan bahwa mereka berada di luar percakapan. Mantan engineer bisa sangat baik di peran ini, tetapi korelasinya lebih lemah dari yang diperkirakan: project manager yang terlalu larut dalam perdebatan teknis sering berhenti melakukan koordinasi yang justru dibutuhkan timnya dari mereka.
- Bagaimana mengetahui apakah seorang project manager memberi nilai tambah?
- Lihat apa yang terjadi pada hambatan. Di tim dengan project management yang efektif, hambatan ditemukan lebih awal daripada yang akan ditemukan tim sendiri, diselesaikan tanpa rangkaian eskalasi, dan jarang muncul sebagai kejutan di rapat steering. Ketika perannya sudah berubah menjadi administratif, sinyalnya adalah kumpulan dokumen yang terpelihara rapi berdampingan dengan tim yang masih menghabiskan pekannya menunggu masalah berulang yang sama.
- Bagaimana project manager bekerja dengan tim engineering yang sudah ada?
- Dalam pengaturan penambahan kapasitas tim, seorang project manager bekerja di dalam struktur delivery klien â irama perencanaan, garis pelaporan, tata kelola dan jalur eskalasi mereka â dan klien yang mengarahkan pekerjaan. Tanggung jawab atas produk, prioritas bisnis dan roadmap tetap sepenuhnya pada klien, dan kapasitas koordinasi tambahan tidak memindahkannya. Yang dipikul Talent.ID hanya sisi kepegawaian â hubungan kerja itu sendiri, payroll, benefit karyawan, administrasi talenta, dan tetap menjadi mitra karyawan tersebut dari waktu ke waktu.
Ceritakan kebutuhan tim Anda
Jelaskan kekurangannya â pekerjaannya, stack-nya, cara tim Anda berjalan â dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.