Get best of the week

Bagaimana memahami bahwa suatu proyek adalah proyek dan menjalankannya dengan benar

Dua hari sebelum demo. Tim melihat fungsionalitas khusus - integrasi produk kami dengan Google Maps. Integrasi digergaji "pada lutut" - yang utama adalah memiliki waktu untuk menunjukkan klien potensial kemampuan sistem.

Demo berlalu dan klien berhenti untuk berpikir.

Enam bulan kemudian, penjual menjual solusi lain dengan integrasi Google Maps ke pelanggan lain. Yah, mereka melihat bahwa setengah tahun yang lalu semuanya bekerja di demo.

Apa masalah yang terjadi di sini?

Saya bekerja di perusahaan yang berbeda. Di suatu tempat jelas bahwa kami akan melakukan proyek ini. Mengapa ini jelas? Klien datang dan berkata, saya perlu membuat sistem seperti itu dan menjelaskannya. Manajer merencanakan berapa banyak proyek akan memakan waktu dan uang, bernegosiasi dengan klien dan bekerja di depan. Ini adalah - piagam, rencana proyek, risiko, kontrol kualitas dan artefak proyek lainnya. Jelas dan bisa dimengerti.

Di organisasi lain, proyek diluncurkan dari atas - kami melakukan ini dan ini, membawa orang dan pergi. Kurang ekspansi, tetapi juga jelas dan jelas.

Ketiga, yang paling sulit, dengan proyek itu tidak mudah. Menurut pendapat saya, ada sejumlah masalah yang sulit bagi saya untuk menilai dari tingkat saya. Segala sesuatu terjadi seperti yang dijelaskan di awal - proyek lebih mungkin mati daripada hidup.

Masalah apa yang muncul?

  • , — . , .
  • .
  • , .

Tim proyek mulai mengerjakan rencana implementasi dan nuansa “tiba-tiba” muncul.

Akan tetapi, genre klasik - baik kita dan klien memahami secara berbeda "integrasi", misalnya, atau istilah "audit". Bagi mereka, itu adalah kata yang mengerikan yang terkait dengan verifier jahat, dan bagi kami, istilah yang berarti fungsionalitas.

Akibatnya, proses implementasi diterjemahkan menjadi proyek revisi. Secara formal, rancangan piagam tidak berubah, semua tujuan tingkat tinggi tetap sama.

Bagaimana cara taksi? Tugas utama adalah mencari tahu apa yang perlu dilakukan, menentukan prioritas, jadwal, sumber daya, risiko, memberi tahu semua pihak yang berkepentingan, menyiapkan beberapa skenario pengembangan. Akibatnya - untuk setuju dengan klien tentang jumlah yang diperlukan yang akan masuk ke dalam anggaran yang terjangkau.

Nuansa utama - proyek telah terjual, sudah memiliki anggaran dan jumlah pekerjaan. Pembatasan yang cukup sulit. Tetapi ini tidak berarti bahwa Anda harus menelan semuanya dan mengambilnya untuk kebenaran pada contoh pertama. Dalam 99% kasus, Anda dapat bernegosiasi, apakah itu klien atau sponsor.

Kami memulai proyek


Kebetulan saya lebih mendukung rencana yang jelas. Air terjun dan pendekatan PMI serupa dalam semangat, meskipun beberapa aspek Agile tidak asing.

Jadi, proyek dimulai dan bukti bahwa proyek itu diluncurkan adalah piagam proyek. Bagi mereka yang sedikit akrab atau tidak terbiasa, saya akan menjelaskan apa jenis binatang itu.

Menurut ideologi PMI, ini adalah dokumen yang menggambarkan tujuan tingkat atas, jadwal, anggaran, risiko, dan juga memberikan otoritas formal kepada manajer proyek dan, yang penting, menentukan nama proyek. Di bawah ini saya akan menjelaskan alasannya.

Seringkali, piagam disiapkan oleh manajer proyek, disepakati dengan sponsor, pelanggan dan pemangku kepentingan utama lainnya.

Di salah satu perusahaan tempat saya bekerja, tidak ada definisi yang jelas tentang apa proyek itu. Ada kegiatan tertentu, aliran tertentu, yang disebut proyek, tetapi kenyataannya tidak. Itu asumsi. Oke, mari kita sebut itu proyek dan setidaknya putuskan nama sehingga semua orang mengerti apa yang kita bicarakan. Ada kebingungan dengan nama-nama, ketika sponsor berkata, "Apa kemajuan pada proyek untuk mengintegrasikan solusi?", Kepala departemen dan manajer berpikir berbeda. Kepala departemen menyebut proyek ini "integrasi pelanggan", dan manajer proyek "optimasi database". Semua orang berpikir pada levelnya sendiri.

Agile tidak memiliki anggaran dan tenggat waktu, bahkan yang tingkat atas, karena semuanya fleksibel dan dapat berubah kapan saja. Ya, Agile dapat memperkirakan waktu penyelesaian, tetapi hanya setelah beberapa iterasi ketika kinerja tim dievaluasi. Tetapi ada tujuan. Kami tahu apa yang ingin kami lakukan.

Saya akan memberi contoh. Ada dua tim pengembangan. Keduanya memiliki proyek yang sama - untuk mengembangkan solusi seluler untuk pengendalian kualitas makanan.

Tim A bekerja di Air Terjun. Tim B bekerja pada Agile. Berbagai pendekatan untuk perencanaan dan pengembangan. Tetapi tujuannya adalah satu. Jadi mengapa tidak memperbaikinya di awal? Bagaimana kemungkinan tim B di tengah sprint akan memahami bahwa klien tidak memerlukan aplikasi untuk kontrol kualitas, tetapi membutuhkan aplikasi untuk merekam pertandingan sepak bola? Sangat kecil, dengan probabilitas yang lebih besar mereka akan tetap mencapai tujuan awal mereka.

NB: Saya membuat asumsi dan berbicara tentang pengembangan kustom, bukan tentang startup.

Dengan nama, waktu, anggaran, kurang lebih jelas. Bagaimana dengan risikonya?

PMI mengacu pada ini secara resmi. Menurut pendapat saya, proses manajemen risiko adalah hal yang independen. Izinkan saya menjelaskan apa yang saya maksud.

Proses manajemen risiko terdiri dari tahapan-tahapan berikut:

  1. Identifikasi
  2. Analisis
  3. Perencanaan
  4. Pemantauan

Ini pada dasarnya adalah proses berulang. Ini berlaku untuk operasi dan pendekatan Agile.

Saat memulai proyek, ada satu risiko global - mungkin gagal.
Buku Edward Yordon, The Kamikaze Path, memiliki pemikiran yang menarik - ada baiknya memperlakukan proyek apa pun sebagai kegagalan. Dengan sikap ini, Anda perlu membangun strategi pengembangan, yaitu, memikirkan serangkaian tindakan yang akan membuat proyek yang sukses gagal.

Jadi mengapa tidak menjauh dari pemikiran ini dan mewujudkannya? Ya, ada sedikit data di awal. Tapi itu sebabnya mereka adalah risiko tingkat tinggi, untuk menunjukkan kepada pihak yang berkepentingan apa yang salah.
Total - draft charter adalah dokumen yang memungkinkan semua pihak utama untuk menyetujui satu terminologi, tujuan global, dan risiko tingkat tinggi. Semua orang mengerti ke mana kita pergi, apa yang ingin kita capai dan apa yang bisa terjadi salah.

Penentuan sasaran proyek


Banyak manajer proyek pemula melewati ini - Anda perlu menyusun piagam dan menentukan tujuan proyek. Dan monster seperti itu lahir:

  • Pengembangan dan implementasi program perusahaan dan sistem manajemen proyek untuk meningkatkan interaksi antar departemen;
  • Daur ulang sistem akuntansi pajak untuk mengoptimalkan proses akuntansi;
  • Penerapan sistem kendali biaya untuk meningkatkan laba departemen.
  • Proyek semacam itu tidak dapat diselesaikan. Jika Anda melihat kata-kata ini dalam piagam, maka proyek ini sudah mati.

Mengapa "sistem perusahaan" harus meningkatkan kolaborasi? Bagaimana pelanggan memahami bahwa dia melakukan ini?

“Daur ulang sistem akuntansi” - kami akan memperbaikinya, tetapi bagaimana? Ubah item menu di antarmuka. Apakah ini merampingkan proses akuntansi?

“Implementasi sistem kontrol” - bagaimana kita memahami bahwa sistem diimplementasikan? Misalkan semua orang setuju bahwa itu diterapkan, tetapi apakah itu akan meningkatkan laba departemen? Bagaimana jika kita tidak menerapkan apa pun, tetapi laba meningkat, dengan alasan di luar kendali kita? Bisakah kita berasumsi bahwa proyek telah mencapai tujuannya?

Jika kita merumuskan tujuan proyek, maka ini harus menjadi serangkaian tujuan: apa yang perlu dilakukan secara spesifik dan bagaimana kita memahami bahwa kita melakukannya? Apa yang harus kita lihat, rasakan? Apa yang harus diubah? Biaya apa yang harus dicapai? Kapan? Jika ada beberapa tujuan, lalu apa prioritas mereka. Mungkin ternyata tujuan tersebut saling tergantung satu sama lain, atau ternyata beberapa tujuan saling eksklusif.

Menetapkan sasaran SMART


  • Spesifik - spesifik.
    Apa yang ingin kita lakukan? Sesuatu untuk ditingkatkan? Dan berapa banyak?
  • Terukur - terukur.
    Bisakah kita mengukur sasaran dengan uang, persen, menghemat waktu?
  • Dapat dicapai - dapat dicapai. Apakah kita memiliki sumber daya, pengetahuan, pengalaman, waktu yang cukup untuk mencapai tujuan?
  • Relevan - relevan atau signifikan.
    Di sini Anda perlu menentukan apa yang diperlukan untuk mencapai tujuan?
  • Batas waktu - waktu terbatas.
    Berapa lama tujuan harus dicapai?

Contoh: Menerapkan sistem manajemen proyek berdasarkan Server Proyek untuk 20 tempat kerja kantor proyek menggunakan register risiko elektronik dan email dengan fungsi pemberitahuan otomatis tentang penundaan tenggat waktu.

Sistem harus membantu mengurangi jadwal setiap proyek sebesar 15% dalam waktu 2 bulan setelah diluncurkan.

Sistem harus diimplementasikan dalam 6 bulan, paling lambat 15 Desember.

Sudah lebih dekat, tetapi masih memungkinkan untuk disempurnakan.

Pertanyaan tambahan yang dapat Anda tanyakan:

  • Apa yang harus dilakukan?
  • Mengapa Anda perlu melakukan ini?
  • Manfaat apa yang harus diberikan proyek?
  • Apakah semua orang akrab dengan rencana ini?
  • Apakah semua orang memahaminya dengan cara yang sama?
  • Apakah semua orang setuju dengannya?
  • Kapan Anda harus menyelesaikan pekerjaan?
  • Siapa pengguna akhir?
  • Kualitas apa yang Anda harapkan untuk terima?
  • Fungsi apa yang diharapkan?
  • Fasilitas apa yang tersedia?
  • Siapa yang mengendalikan kesuksesan dan dengan kriteria apa?
  • Apa yang seharusnya tidak terjadi?
  • Pekerjaan apa yang bukan milik proyek?

Dua pertanyaan terakhir adalah apa yang disebut "bukan tujuan".

Mereka menggambarkan apa yang tidak relevan dengan proyek dan apa yang tidak boleh terjadi, karena ini mengganggu kemajuan proyek atau melanggar batasan internal. Hasil yang tidak relevan dengan proyek tidak boleh dikategorikan sebagai berbahaya, tetapi Anda harus menyadari bahwa pelanggan tidak membayar untuk itu.

Ringkasan


Anda lihat, ada sejumlah pekerjaan dengan garis besar tertentu dan bahkan ada garis waktu dan anggaran untuk itu? Dengan tingkat probabilitas yang tinggi, ini adalah proyek. Kami sedang bernegosiasi dengan orang-orang penjualan sehingga manajer dan insinyur terlibat dalam proses penjualan. Setidaknya sebagai konsultan - dan kemudian mereka akan bekerja dengannya.

Sebelum memulai, kami menentukan nama proyek dan terminologi. Kami menulis piagam dan membentuk tujuan yang jelas dan dapat dipahami. SMART adalah segalanya bagi kami.

More articles:


All Articles