Kerangka Manajemen Proyek: Bagaimana kami menjalankan proyek TI – Beragampengetahuan

Ketika seorang master melakukan tugas, hasilnya akan memberi tahu Anda. Sayangnya, ada sangat sedikit tuan di sana. Bahkan rahasia penguasaan bukanlah rahasia sebenarnya – itu adalah pengetahuan domain plus 10 ribu jam latihan terkonsentrasi. Pada dasarnya, bekerja dalam kondisi sempurna selama lebih dari lima tahun, setiap tugas mengisi celah keterampilan Anda. Tetapi di dunia nyata, kami menghabiskan banyak waktu untuk tugas yang berulang. Sehingga 10.000 jam biasanya memanjang hingga 10 tahun, atau bahkan lebih lama.

Karena menunggu selama itu tidak selalu merupakan pilihan, orang menemukan proses kompromi. Kami juga menerapkannya. Dalam kasus kami, ini adalah kerangka kerja manajemen proyek yang menyelesaikan pekerjaan ini. Jadi mari selami detail dokumen ini dan mengapa penting untuk memiliki dokumen.

Apa itu Kerangka Manajemen Proyek?

Kerangka kerja manajemen proyek adalah serangkaian proses, alat, dan metode yang menguraikan seluruh metode pengiriman proyek. Ini adalah PMBOK (Badan Manajemen Proyek Pengetahuan) Kami beradaptasi dengan proyek yang dibuat khusus untuk proyek TI, yang didasarkan pada pengalaman kami sendiri (ya, kesalahan kami juga kami). Ini menguraikan seluruh siklus hidup eksekusi proyek, dari penyerahan pra-penjualan hingga penutupan setelah proyek, dan setiap manajer proyek harus mengikuti.

Sudah lebih dari 10 tahun sejak kami merilis versi pertama dari kerangka kerja proyek dan setiap PM harus mengikuti. Dalam beberapa tahun terakhir, kami telah melakukan sedikit pengeditan – prosesnya stabil. Saat ini, kerangka kerja proyek adalah manual 14 halaman yang merinci apa yang perlu dilakukan PM di setiap tahap-dari penyerahan pra-penjualan hingga akhir kolaborasi.

Dalam kebanyakan kasus, sudah cukup untuk hanya mengetahui apa yang harus dilakukan – bagaimana menemukannya dalam berbagai kerangka kerja, metode, dan alat manajemen proyek lainnya, yang dalam banyak kasus sudah cukup. Namun, jika ini bukan masalahnya, kami membuat dokumentasi tambahan dan detail bagaimana melakukan sesuatu untuk situasi tertentu.

Salah satu contoh adalah implementasi khusus kami EVM (Hasilkan Manajemen Nilai) – Karena templat siap pakai tidak mencapai keseimbangan yang tepat antara pelanggan dan tingkat detail yang kita butuhkan. EVM kami transparan, dapat diakses oleh pelanggan, mereka dapat melihat kemajuan proyek kapan saja dan memulai pertemuan ketika tampaknya tidak ada yang salah. Kami sangat percaya Transparansi di setiap tahap Eksekusi Proyek – Ini termasuk menjelaskan tujuan setiap dokumen kepada klien, bahkan jika itu membutuhkan waktu dan upaya ekstra.

BACA JUGA ENE VALUE MANAJEMEN (EVM): Bagaimana memprediksi hasil proyek dan kapan EVM akan membantu?

Bagaimana kerangka kerja manajemen proyek membantu

Dengan diperkenalkannya kerangka kerja proyek, PMS sekarang dimulai lebih cepat dan membuat lebih sedikit kesalahan. Inilah lembar curang mereka – disesuaikan dengan berbagai jenis proyek:

• Proyek Pengembangan Siklus Penuh (Frontend + Backend, tim PM, BA dan QA kami (termasuk penyebaran produk) adalah yang paling langsung di bawah model Time and Material (T&M). Anda setuju dengan pelanggan pada ruang lingkup dan jadwal waktu dan bekerja dalam kerangka gesit.
• Beberapa proyek siklus (Biasanya tanpa backend atau jaminan kualitas) juga berjalan di bawah T&M, tetapi membutuhkan kolaborasi erat dengan tim eksternal. Keberhasilan semua orang saling bergantung.
• Kustomisasi komponen dengan harga tetap Ikuti logika air terjun klasik – kisaran tetap, biaya tetap.
• Proyek Peningkatan Tim Artinya kami bergabung dengan tim klien yang ada yang dipimpin oleh PM mereka. Karena kami tidak dapat memprediksi kematangan manajemen proyek klien, kami tidak akan kecewa. Inilah sebabnya kami menemukan peran pejabat XB: mereka menggunakan titik kontrol untuk memantau proyek dan mengingatkan mereka hanya ketika mereka menemukan risiko atau tren negatif. Kami memperkenalkan peran ini pada pertemuan kickoff dan meninjau acara bersama menggunakan matriks tanggung jawab.
• BFS (anggaran untuk rentang mengambang) – Kami menawarkan pendekatan in-house yang unik untuk klien dengan tujuan ambisius dan anggaran yang ketat. Proyek -proyek ini dimulai dengan hanya satu ide dan anggaran tetap. Seiring berlalunya proyek, visi produk akan berkembang seiring dengan perkembangan proyek. Setiap fitur dapat diimplementasikan dalam berbagai cara dengan berbagai biaya. Oleh karena itu, manajemen proyek BFS menggabungkan harga tetap (kendala anggaran), waktu dan material (biaya fungsional masa depan yang tidak diketahui), pertukaran berkelanjutan dan perkiraan untuk menyelesaikan semua aspek saldo. Di sini, kami sangat bergantung pada metode pengiriman yang disiplin dan gesit (ayah). Keberhasilan tergantung pada keterampilan tim dan kepercayaan yang kami bangun dengan klien kami.

Setiap proyek juga dapat diperkenalkan Aturan internalnya sendiri – make up dan ikuti erat dengan ulasan setelah setiap tonggak sejarah. Aturan -aturan ini hidup dalam kerangka peraturan proyek, tetapi meninggalkan ruang untuk fleksibilitas.

Juga melayang seperti kupu -kupu dan sengatan seperti lebah: bagaimana kontrak BFS mengubah pandangan Anda tentang pengembangan produk

Catatan Penting tentang Penggunaan Kerangka Manajemen Proyek

Mari kita bicara tentang kesalahan manusia

Pertama, tidak peduli seberapa bagus dokumentasi Anda, proyek ini dijalankan oleh orang -orang, yang berarti bahwa faktor manusia selalu bekerja. Salah satu bahaya yang paling halus adalah “drift” – bias yang lebih kecil dan tidak diketahui dibandingkan dengan aturan yang dibangun dari waktu ke waktu.

Misalnya, kami setuju untuk sinkronisasi mingguan dengan klien kami dan tim mereka. Pertama, semua orang bergabung, berbagi pembaruan dan rencana. Lalu, ada sedikit diskusi (“di Jira”) dan seseorang melewatkan pertemuan, lalu melewatkannya, dan kemudian dibatalkan. Tiba -tiba, setiap tim baris ke arah yang berbeda, tujuan, dan solusi suboptimal.

Untuk menghindari penyimpangan ini, kami menjalankan audit proyek – periksa silang dokumentasi proyek, seperti komentar kode pengembang. Masalahnya ditandai, didokumentasikan, dan PM diharapkan untuk memperbaikinya dan melaporkannya. Kedengarannya ketat, tetapi prosesnya halus dan ramah. Semua orang mengerti: menemukan masalah ini sekarang lebih baik daripada menyelesaikannya nanti. Audit juga memiliki manfaat hadiah: berbagi pengetahuan. Tidak setiap masalah yang ditandai adalah bug – kadang -kadang ini hanyalah cara yang efektif.

Praktik utama untuk diikuti

Kedua, praktik manajemen proyek tertentu yang tidak boleh dilupakan oleh anggota tim. Beberapa sorotan termasuk yang berikut:

• Nomor item daftar fungsi harus konsisten.
  Sepanjang siklus hidup proyek, angka tidak boleh berubah – dari perencanaan hingga pelaporan. Kerangka kerja proyek dengan jelas menunjukkan hal ini. Ini tidak “bagus” – itu mencegah kebingungan. Jika angka tidak dapat stabil karena alasan apa pun, lebih baik tidak menggunakan angka sama sekali daripada mengubahnya di tengah.
• Ibu (rapat catatan rapat) Setelah panggilan setiap klien.
  Jika sesuatu disepakati, itu harus dicatat. Pikirkan ibu sebagai masa tinggal lengkap di akhir kalimat: jelas, akhir dan jelas. Semua orang meninggalkan telepon dengan pemahaman yang sama. Jika fitur baru dibahas dalam komentar daftar fitur, Anda harus menambahkan fitur ini ke daftar dengan nomor yang sesuai. Daftar fitur bertindak sebagai agenda pertemuan, dan setelah panggilan itu menjadi seorang ibu, atau disertai dengan file ibu yang terpisah.

Bahkan kerangka kerja terbaik tidak menjamin keberhasilan, tetapi mereka mengurangi risiko – terutama ketika kesalahan manusia pasti menyebar. Berpegang teguh pada praktik -praktik utama seperti angka fitur yang konsisten dan dokumen konferensi yang menyeluruh bukanlah birokrasi – itu adalah bagaimana kami membuat semua orang menghadapinya, menghindari kesalahpahaman, menghindari kesalahpahaman, dan memandu proyek dengan aman.

Baca juga siklus hidup manajemen proyek yang dijelaskan dalam lima langkah sederhana

Singkatnya: Prosesnya adalah perlindungan

Setiap proyek unik. Kerangka kerja proyek tidak lengkap – tinjauan singkat tentang aturan pengalaman tim. Mengikuti itu tidak menjamin keberhasilan, itu hanya meningkatkan peluang. Inilah sebabnya mengapa dokumentasi selalu berakhir dengan pengingat:

“Aturan pengalaman ini bukan peluru perak. Terkadang mereka tidak perlu. Terkadang mereka bahkan dapat membahayakan proyek. Jika Anda memilih untuk melewatkan apa yang tercantum di sini, perlu ada alasan yang bagus – Anda harus dapat menjelaskannya. Jika Anda melihat cara untuk meningkatkan aturan, katakan. Dan bersiaplah untuk menjelaskan keputusan Anda dalam tinjauan proyek berikutnya.transparan

Pada akhirnya, kerangka kerja proyek tidak ada hubungannya dengan kontrol yang ketat – adalah untuk menghindari jebakan umum sehingga tim menyediakan struktur yang cukup sehingga mereka dapat fokus membangun produk hebat. Dan, jika Anda menghadapi kekacauan, semakin sakit, atau hanya ingin berbicara dengan mereka yang telah mengalaminya – jangan ragu untuk menghubungi kami. Kami selalu di sini untuk membantu, membimbing, atau melompat ke mitra proyek Anda.