Harap dicatat bahwa tidak ada tanda tanya dalam judul. Saya tidak ingin berdebat apakah manajer proyek diperlukan dalam pengembangan perangkat lunak modern atau tidak. Latihan menunjukkan bahwa tidak. Saya hanya mencoba mencari tahu mengapa itu terjadi.
Setelah bekerja selama lebih dari 20 tahun di industri TI, saya mulai membangun setiap pengembangan baru dari kantor proyek. Apalagi beberapa kali saya harus menjelaskan kepada manajemen mengapa harus menyewa piem. Dengan kepala departemen, tidak mudah menjelaskan kepada orang-orang yang tidak terlibat langsung dalam pengembangan perangkat lunak apa yang sebenarnya akan dilakukan manajer proyek. Saya harus mengatasi perlawanan yang nyata.
Tetapi bagi saya itu adalah aksioma bahwa kantor proyek dan manajer proyek adalah dasar keberhasilan. Dan beri tahu saya seseorang sekitar lima tahun yang lalu bahwa manajer proyek tidak diperlukan, saya akan berdebat dengannya sampai akhir.
Catatan Editor: teks ini adalah hasil dari laporan Dmitry Kruglov dari Arrival at the Piemnaya rally.
Atau apakah Anda masih membutuhkannya
Mari kita mulai dengan berusaha melindungi profesi ini. Kalau saja karena hasil di tempat kerja terakhir telah tercapai, termasuk berkat berhasil membangun kantor proyek.
Manajemen proyek bukan hak prerogatif TI. Ini adalah ilmu yang berusia lebih dari 50 tahun. Ilmu yang memiliki kitab suci sendiri. Tentu saja, PMBoK bukan salah satu dari jenis, ada PANGERAN dan, mungkin, beberapa buku lagi yang kurang lebih mengklaim kemenangan. Tetapi PMBK adalah dasar dari standar internasional dan ini menunjukkan tingkat pengakuannya yang tinggi. Jadi kita akan membangunnya.
Ayo mainkan permainan: jika Anda bekerja sebagai manajer proyek, cobalah, tanpa melihat ke depan, untuk mengingat kembali bidang kegiatan utama Anda dari sudut pandang standar internasional dan lembaga yang sudah berusia lebih dari 50 tahun?
Misalnya, kelola persyaratan proyek. Atau kelola harapan. Mungkin Anda ingat tentang manajemen waktu. Tentunya kolega yang mewakili bisnis secara teratur bertanya kapan tepatnya ini atau tugas itu akan siap. Mungkin Anda akan mengingat manajemen pemangku kepentingan, yang jauh lebih jarang terjadi. Apa lagi Manajemen Komunikasi. Yang terakhir jarang terjadi seperti halnya para pemangku kepentingan. Tapi ini adalah tugas yang penting dan sulit di zaman kita, ketika semua peserta proyek lebih suka berbagi informasi penting tentang Telegram, daripada email yang diperlukan oleh draft charter. Bagaimana Anda dapat mengelola komunikasi jika Anda tidak diundang ke obrolan tempat mereka membahas, misalnya, kualitas pekerjaan Anda?
Bandingkan apa yang Anda ingat dengan daftar dari PMBoK:
Semua barang sangat waras. Tampaknya kegiatan ini benar-benar perlu dilakukan oleh setiap manajer proyek. Beberapa di antaranya mungkin kurang jelas, seperti integrasi proyek. Tetapi jika Anda menggunakan kekuatan beberapa tim untuk membuat fitur yang sangat besar, yang perlu Anda kumpulkan sebelum diluncurkan, maka Anda memahami apa maksud dari poin ini. Omong-omong, tugas mengembangkan satu fungsi di beberapa tim secara paralel belum diselesaikan secara sistematis.
Gantt Chart
Jika ada kegiatan, pasti ada hasilnya. Pendapat pribadi saya adalah bahwa pekerjaan itu dilakukan dengan artefak yang sesuai. Untuk seorang programmer, ini adalah kode yang berfungsi. Untuk spesialis pengujian, skrip pengujian yang dikembangkan atau dieksekusi, kesalahan yang diperkenalkan dalam sistem, atau autotest dibuat. Untuk desainer - tata letak grafis.
Apa itu artefak manajer proyek? Dari semua artefak yang mungkin, termasuk pesan di Telegram: "Tambahkan saya, akhirnya, ke obrolan Anda, saya tidak bisa mengelola proyek tanpanya!", Saya pertama-tama akan mencatat grafik Gantt. Ini adalah alat yang hebat yang dapat menjawab banyak pertanyaan tentang proyek dan membantu memvisualisasikan sebagian besar bidang kegiatan manajer proyek. Bagaimanapun, bagan Gantt yang baik berisi waktu, sumber daya, biaya, dan dependensi. Di sana Anda dapat menambahkan persyaratan komunikasi sebagai tugas. Anda bahkan dapat menambahkan kontrol kepada pemangku kepentingan dan harapan mereka dengan tonggak dan deskripsi hasil yang diharapkan. Ternyata alat universal untuk semua kesempatan.
Sebagian besar tugas di bidang ini diselesaikan melalui pengelolaan satu entitas - bagan Gantt.
Popularitas dan keserbagunaannya dikonfirmasi oleh jumlah alat dan layanan yang memungkinkan Anda membuat diagram. Coba cari "Gantt online" dan lihat berapa lama daftar tautan untuk setiap selera dan warna yang Anda dapatkan.
Apa yang terjadi: kita memiliki profesi, memiliki aktivitas dan memiliki artefak yang baik, sebagai hasilnya. Jadi, apa masalahnya?
Ini semua tentang nuansa. Misalnya, dengan Gantt, tidak semuanya begitu baik.
Pertama, diagram proyek besar cepat atau lambat menjadi tidak dapat dibaca. Saya memiliki pengalaman bekerja dengan proyek "lebih dari setahun" di Microsoft Project. Untuk mencetak rencananya, perlu menempelkan enam lembar A4. Di satu lembar, teksnya terlalu kecil.
Kedua, diagram proyek besar sangat padat karya untuk dipelihara. Membuat perubahan sering kali hanya dapat dilakukan oleh penulis sendiri, jika tidak rencananya berantakan karena sistem dependensi yang kompleks.
Ketiga, harus diakui bahwa tidak ada seorang pun kecuali banyak manajer proyek yang membaca banyak diagram. Ternyata artefak ini diproduksi oleh PM dan dia sendiri membutuhkan dan memahaminya.
Dalam pengembangan perangkat lunak modern, Gantt, sebagian besar, ditinggalkan. Kami berhenti menggunakan artefak ini dalam membuat produk, apakah kami benar-benar membutuhkan pembuatnya?
Jika Anda mencoba untuk google topik kegunaan manajer proyek di TI, menjadi jelas bahwa diskusi ini telah berlangsung lama. Dia berhasil menjadi holivar lain, seperti konfrontasi antara pecinta iOS dan Android, Windows atau OS X. Hanya kutipan dalam hasil pencarian yang lebih emosional: "Apakah kita memerlukan PM?", "Mengapa kita memutuskan untuk menyingkirkan PM", "Apakah apakah pekerjaan PM tidak berharga? "
Saya tidak berani mengatakan bahwa keseimbangan dalam perselisihan global mendukung penolakan PM, tetapi setidaknya jumlah pendukung dari sudut pandang ini adalah signifikan.
Metodologi tangkas
Mulai bekerja di sebuah perusahaan di mana saya memiliki tugas membangun tim pengembangan dari nol sekali lagi, saya menyadari bahwa selama enam bulan ke depan satu tahun saya tidak memiliki tugas untuk PM. Awalnya saya menambahkannya ke struktur organisasi karena kebiasaan. Dan kemudian dia menyerang dengan tangannya sendiri. Dicoret secara intuitif, tetapi bertanya-tanya: "Mengapa itu terjadi?".
Penelitian saya tentang alasan menyebabkan pemahaman bahwa TI memiliki sejumlah kualitas unik yang memungkinkan implementasi metodologi yang fleksibel. Ada perbandingan klasik: membangun rumah dan mengembangkan perangkat lunak. Ini adalah disiplin yang agak mirip, bukan tanpa alasan di keduanya ada peran arsitek. Baik di sana, dan di sana ada satu set persyaratan fungsional dan non-fungsional, ada infrastruktur, komunikasi internal, perakitan, pengiriman dan integrasi.
Tetapi konstruksi dilakukan di dunia nyata dan memiliki siklus produksi yang sangat panjang dan mahal sampai pengujian pertama, sebelum menerima umpan balik pertama, sebelum menerima hasilnya. Harga kesalahan dalam konstruksi sangat tinggi.
Produk IT adalah digital. Dan siklus produksinya bisa sangat singkat. Selama dua dekade, kami mampu menciptakan alat dan teknologi yang mengarah pada munculnya metodologi pengembangan yang fleksibel. Di sini saya siap untuk berdebat bahwa hubungan kausal adalah seperti ini: kemampuan untuk bereksperimen dengan cepat dan mendapatkan hasil kerja telah menyebabkan munculnya metodologi tentang cara melakukan ini. Tentu saja, ini umpan balik positif singkat, dan alat terus berkembang. Dan lagi-lagi metodologi itu diselesaikan. Dan seterusnya dalam spiral kita bergegas menuju waktu yang semakin pendek ke pasar.
Peran
Metodologi tangkas telah menjadi standar de facto dan telah membawa peran baru ke proses pengembangan perangkat lunak. Dan peran baru ini mulai mengambil kegiatan dan artefak dari manajer proyek.
Pemilik produk (PO)
Ada proyek yang memiliki beberapa pelanggan, beberapa pemilik dan beberapa pengambil keputusan. PM bagi mereka adalah orang yang mencari kompromi. Dia menyatukan mereka semua, membantu memprioritaskan, mendamaikan. Dia berkata kepada seseorang: "Tidak," lobi seseorang. Tetapi bisnis memahami bahwa dalam pencarian kompromi yang berkelanjutan, sumber daya terbuang secara tidak efisien. Sumber daya yang paling berharga dihabiskan sepanjang masa.
Oleh karena itu, metodologi yang fleksibel melakukan hal itu - mereka berkata kepada satu orang dari bisnis sesuatu dalam semangat: “Anda ekstrem untuk uang, untuk lalu lintas dan untuk konversi. Dan jujur saja, kami tidak peduli apa dan dengan prioritas apa yang Anda lakukan dalam produk. Yang utama adalah bahwa pada akhir tahun konversi akan meningkat dari 1% menjadi 1,1%, jika tidak proyek tidak akan menguntungkan. " Dan PO mendapatkan hak untuk membuat keputusan secara individu, itu menentukan prioritas, menciptakan artefak yang sesuai (rencana, peta jalan, persyaratan) dan mengambil pekerjaan dari PM.
Techlide (TL)
Sekitar sepuluh tahun yang lalu, TI mulai mengubah arsitektur yang ada.
Sebelum perubahan-perubahan ini, teknologi dan alat-alat terutama dibuat untuk "arsitektur berlapis" - lapisan basis data, lapisan proses bisnis, lapisan agregasi, lapisan klien. Tetapi segera setelah pendekatan ini menjadi klasik, segera setelah perusahaan mengakuisisi lapisan departemen yang sesuai, metodologi fleksibel datang. Dan semua orang dengan suara bulat memutuskan bahwa "puff pies" itu buruk dan perlu untuk membentuk tim lintas fungsi.
Bukan untuk mengatakan ini adalah ide baru. Apa yang disebut pengembang universal? Tumpukan penuh Salah satu pengembang berusia lebih dari 30 tahun dalam wawancara mengatakan: "Saya adalah seorang pengembang tumpukan penuh pada saat istilah tumpukan penuh tidak ada." Pernah kami semua penuh, karena kami harus melakukan segalanya, termasuk administrasi basis data dan menyiapkan komputer direktur.
Tim lintas fungsi telah membawa peran baru: techlides. Tehlid tidak hanya menekan kepala departemen, tetapi juga mengambil alih bagian teknis pekerjaan PM. Pertama-tama, semuanya terkait dengan penilaian kompleksitas dan waktu. Pada saat transisi ke metodologi yang fleksibel, banyak yang menerima kenyataan bahwa tim pengembangan harus mengevaluasi sendiri persyaratan kerjanya.
Analis Sistem (SA)
Seorang analis sistem bukanlah peran baru, dan banyak metodologi Agile tidak. Saya tidak berani mengatakan dengan pasti, tetapi ada kemungkinan bahwa itu tersedia secara eksplisit di AMAN. Tetapi SAFE, secara umum, adalah metodologi batas. Namun, peran ini sangat bermanfaat dan menarik. Ini, seperti pelumas dalam mekanisme yang kompleks, memungkinkannya bekerja dengan tenang dan lancar. Seorang analis sistem sebagian adalah pemilik produk, sebagian lagi arsitek. Ini mengklarifikasi dan merinci persyaratan bisnis ke tingkat fitur tertentu. Analis sistem terbaik dapat memajukan ide dan visi mereka di kedua arah, menggunakan kombinasi literasi teknis dan soft skill. Di mana analis sistem bekerja, manajer proyek tidak memiliki kegiatan manajemen persyaratan.
Scrum Master (SM)
Scrum Master sangat memeras peran manajer proyek. Sangat disayangkan bahwa sekarang SM sendiri telah menjadi kandidat untuk kepunahan.
Serius, cepat atau lambat Scrum Master akan mengajar di sekolah. Akan ada pelajaran tentang Agile, di mana Scrum Master akan memberi tahu siswa berusia 12 tahun bagaimana metodologi tangkas bekerja dan praktik apa yang ada. Pengalaman lincah kini telah menjadi pengalaman pengembangan di mana-mana. Dalam sebuah wawancara, 19 dari 20 orang mengerjakan iterasi dua minggu, dan membicarakan proses berubah menjadi daftar parameter mereka:
- Apa penilaiannya?
- Poin Cerita.
- Apa itu Velocity?
- 68.
- Bagaimana Anda merencanakan proyek?
- Di peringkat "t-shirt" S, M, L.
Ini adalah percakapan yang sangat cepat. Dengan techlide saat ini, semua parameter proses dapat didiskusikan dalam satu jam. Setelah itu, mereka pergi bekerja dengan tim dan mereka tidak membutuhkan Scrum Master untuk ini. Industri hampir mencerna peran ini dan terus bergerak.
Tentu saja, ini tidak terjadi di mana-mana. Tentunya ada banyak perusahaan yang perlu mencapai standar pasar dan ini bukan proses yang cepat. Di Rusia, setelah 10 tahun, adalah mungkin untuk menemukan pekerjaan sebagai Scrum Master di semacam "Lenoblkhozpromlespoval" ketika organisasi memutuskan untuk mentransfer ketiga pemrogramnya ke Agile.
Selama popularitas mereka, Scrum Master berhasil menghilangkan semua pertanyaan dari tim proyek dari PM. Mereka membawanya bukan untuk diri mereka sendiri, tetapi untuk anggota tim, memfasilitasi keterlibatan mereka dalam pekerjaan desain. Omong-omong, ini secara signifikan meningkatkan tingkat kematangan TI di mata bisnis.
Atau masih belum dibutuhkan
Apa yang tersisa Saya mengambil kebebasan menyoroti tugas-tugas yang, ketika bekerja pada metodologi yang fleksibel, diselesaikan oleh peran lain.
Apa yang tersisa dengan manajer proyek setelah ini? Komunikasi, integrasi, dan pengadaan yang tersisa. Tampaknya tidak ada banyak orang yang tetap berdedikasi untuk peran ini? Sudah waktunya untuk mengatakan bahwa PM tidak diperlukan. Tapi tidak.
Masih butuh
Ada kategori proyek TI di mana kegagalan tanpa manajer khusus praktis dijamin.
Proyek dunia nyata
Mereka yang bekerja dengan pengembangan ponsel tahu bahwa dengan kecepatan membuat perubahan dan biaya kesalahan, segala sesuatunya tidak begitu lancar. Jika Anda melewatkan kesalahan dalam pengembangan seluler dan tidak segera menyadarinya, maka akan sulit untuk melakukan pembaruan untuk seluruh audiens. Beberapa pengguna tidak akan memperbarui aplikasi mereka dan kesalahan akan tetap ada. Dari masalah ini, misalnya, pendekatan dengan kendali jarak jauh dari fungsionalitas aplikasi seluler telah tumbuh.
Tetapi ini adalah bagian keseratus dari kepedihan para PM yang mengelola pengembangan perangkat lunak, misalnya, untuk mengelola sorting conveyor di sebuah gudang dengan skala 5 juta unit barang. Dalam proyek semacam itu, puluhan ketergantungan pada pemasok peralatan, iterasi diukur dalam beberapa bulan, dan harga kesalahan meningkat dengan urutan besarnya.
Proyek yang berhubungan dengan peralatan membawa kita kembali dari dunia digital ke realitas kita, di mana kontrol PMBoK klasik masih relevan.
Proyek Payung
Pada proyek-proyek payung, metodologi fleksibel terhenti. Proyek-proyek semacam itu besar dan kompleks. Kompleksitas berarti ketergantungan eksplisit dan implisit, dan pada skala tertentu, pengembangan tanpa manajer proyek khusus menjadi sangat tidak efisien. Dalam proyek tersebut, tugas utama PM adalah integrasi proyek, ketergantungan dan manajemen waktu.
Proyek dengan biaya kesalahan tinggi
Akan selalu ada industri di mana kesalahan harus dieliminasi ke maksimum - kedokteran, penerbangan, industri luar angkasa, dan bidang militer. Di area ini, ketika kesalahan terjadi, orang mati atau banyak uang hilang. Contoh mudah ditemukan di Internet. Mulailah dengan cerita tentang rudal Eropa Arian-5.
Dalam bidang seperti itu, PM akan tetap diminati, tetapi permintaan yang sangat tinggi akan diberikan pada mereka dalam hal kompetensi dan pengalaman. Dan semakin kecil proporsi proyek semacam itu, semakin ketat pula pemilihan kandidat.
Proyek tanpa peran
Hidup adalah hal yang keras, dan mengambil orang yang berdedikasi untuk setiap peran tidak selalu mungkin. Sampai dunia sempurna, akan ada PM yang melakukan pekerjaan Pemilik Produk. Atau PM yang secara de facto berfungsi sebagai techlides. Kombinasi semacam itu sering menjadi ciri khas startup.
Jika kita memperpanjang tren yang sedang berlangsung di industri sekarang, kita akan memiliki masa depan di mana peran PM dalam bentuk murni tetap relevan untuk sejumlah kecil proyek pengembangan perangkat lunak yang pekerjaannya belum kita ketahui bagaimana mengotomatisasi atau mendistribusikan antara lain anggota tim.
Teks disiapkan oleh:
Penulis - Dmitry Kruglov
Editor - Eugene Shklyar, Denis Vonsarovsky
Pendapat penulis tentang beberapa masalah mungkin tidak sesuai dengan pendapat dewan redaksi blog dan perusahaan Yandex.Money.