Seorang manajer proyek dengan TK di tangan bukan merupakan tanda manajemen proyek

- hai! Nah, bagaimana kabarmu, siapa, di mana? - Lama tidak bertemu.
- Ya, saya seorang manajer proyek TI di sebuah perusahaan besar.
- Oh, PANGERAN, risiko, manajemen ekstrem, keuangan. Sulit
- Oh tidak. Jadi, TK dari klien ke teknisi dan kembali saya seret untuk uang. Omong kosong

Inilah dialog yang nyata. Dan, saya pikir, dialog tersebut relevan untuk banyak perusahaan, terutama jika mereka tidak termasuk dalam sepuluh vendor dan integrator terbesar, di mana prosesnya tetap dianggap tidak jelas dan proyeknya terlihat seperti proyek. Jelas mengapa banyak perusahaan kecil dan menengah berpaling dari konsep "proyek" dan bekerja seperti kartu akan jatuh. Dalam keadaan seperti itu, pekerjaan manajer proyek lebih seperti pekerjaan pengawas, yang datang ke pemrogram dan meminta fitur lebih cepat, kemudian pergi ke penguji dan panggilan untuk menguji sekarang dan tanpa kritik, kemudian ia pergi dengan tim mengarah untuk menyebarkannya dengan produksi dan dengan wajah ungu membawa bug dari wajah klien, terlepas dari apakah itu bug kecil atau kritis, wajahnya selalu sama ungu, dan pidatonya dimulai dengan kata-kata: "Semuanya telah jatuh dari klien". Benar, situasinya sepertinya tidak sehat? Mari kita bicarakan dia.


Seorang manajer proyek tipikal yang tidak benar-benar mengerti apa itu manajemen proyek.

Awal non-acak

Pada bulan Februari 2007, sebuah konferensi manajemen proyek diadakan di Nizhny Novgorod. Kemudian itu adalah tema yang sangat keren dan inovatif. Beberapa ratus perwakilan dari bisnis besar, wirausahawan, deputi, ilmuwan dan mahasiswa mendiskusikan praktik manajemen proyek yang ada dan mekanisme proses bisnis. Sejujurnya, semuanya tampak benar-benar tak bertuhan: perusahaan asing dan raksasa industri dalam negeri berbicara tentang bagaimana mereka mengelola proyek di perusahaan mereka dan meminta mereka untuk mengadopsi pengalaman mereka. Perwakilan bisnis kecil yang bingung duduk di depan mereka dan memahami bahwa sistem otomasi saja menghabiskan biaya jutaan dolar, belum lagi pelatihan, mentor, implementasi. Sepertinya masa depan yang baru saja tiba. Pada awal tahun 2007 yang jauh, RegionSoft CRM kami baru saja memulai perjalanannya, dan peserta konferensi adalah dua karyawan masa depan kami, kemudian siswa yang belum pernah mendengar apa pun tentang perusahaan kami. Dan tidak ada yang tahu bahwa pada bulan Agustus 2018 rilis sistem CRM kami RegionSoft CRM 7.0 akan dirilis, dan kami akan menulis artikel tentang Habr (yang pada waktu itu bahkan belum satu tahun) bahwa manajemen proyek tersedia untuk semua orang.

Tidak percaya Sia-sia. Bahkan, dalam bisnis semuanya adalah proses dan semuanya adalah proyek. Anda hanya perlu sedikit repot.

Perhatian Artikel ini ditulis oleh pengembang profesional dan mungkin mengandung sejumlah sarkasme dan ketidaksukaan untuk RM.

Mengapa kita mengangkat topik ini?

Di perusahaan mana pun, cepat atau lambat sebuah proyek dimulai. Ini bisa berupa peluncuran produk atau layanan baru, pembuatan kampanye iklan Tahun Baru, pengenalan perangkat lunak, peluncuran lini produksi baru, dll. Kemudian tiba saatnya untuk memilih manajer proyek (koordinator) di antara karyawan atau menyewa spesialis dan melakukan segala cara sebaik mungkin. Tetapi seluruh proses tampak jauh dari awan.

• Bisnis tidak tahu apa proyek itu. Sebenarnya, ini tidak rumit: tujuan, sasaran, anggaran, risiko, alokasi sumber daya, pelaporan. Tetapi beberapa komponen terus-menerus diabaikan: baik anggaran melampaui batas (dan ini adalah kesalahan perencanaan), kemudian tugas-tugas tumpang tindih, tumpang tindih dan membuat pekerjaan beberapa karyawan tak tertahankan, sementara yang lain - freebie. Karena itu, seluruh proyek beresiko, yang terutama menyerang kepentingan pelanggan (internal atau eksternal - tidak ada perbedaan).
  
• Dalam manajemen proyek, risiko selalu dilupakan. Dan mereka selalu ada, dari duniawi dan mudah diprediksi (kurangnya sumber daya, kawanan pemasok, penyakit karyawan) hingga yang benar-benar mendadak yang harus selalu diperhitungkan (musiman, situasi ekonomi di dunia, bekerja dengan mata uang, risiko legislatif). Tentu saja, terjadinya risiko membahayakan seluruh proyek. Karena itu, penilaian risiko harus proaktif, bukan reaktif - yaitu, terjadi sebelum rubah Arktik memutuskan untuk mengunjungi Anda. Jika proyek ini panjang, penilaian ulang risiko harus dilakukan setiap 2-3 bulan kehidupan proyek.
  
• Bisnis menyukai metodologi dan lupa tentang esensi pekerjaan, kehilangan waktu pada formalitas. Ini terutama berlaku untuk perusahaan besar dan, anehnya, startup. Selain itu, mereka memiliki alasan berbeda: perusahaan baru berusaha menjadi mode dan selalu mencatat fakta manajemen menurut PRINCE atau PMBOK, dan di perusahaan besar (terutama yang tidak bekerja sesuai dengan ISO) selalu ada kucing yang, seperti Anda tahu, ketika tidak ada yang dilakukan, mereka menjilat telur untuk karyawan yang membutuhkan tunjukkan pentingnya dan komitmen Anda terhadap standar. Seringkali dalam mengejar organisasi dokumentasi, pertemuan, tahapan, dll yang tepat kehilangan kerja cepat dan berkualitas.
  
• Manajer proyek (disebut sebagai manajer proyek) adalah kategori pekerja yang sangat tidak jelas. Hal-hal yang kurang lebih buruk di TI, di mana sebagian besar (tetapi, sayangnya, tidak semua) proyek tumbuh dari dalam, dari lingkungan pengembangan. Tetapi kesedihan perusahaan IT, jika lulusan humaniora atau lulusan Manajemen menjadi manajer proyek teknis. Tidak, ini bukan orang jahat, dan mereka mungkin membaca banyak buku tebal (termasuk banyak sumber "motivasi"), tetapi IT adalah bidang yang terlalu spesifik untuk proyek yang harus dijalankan oleh orang-orang tanpa latar belakang teknis (mereka yakin bahwa mereka akan berdebat dengan kami - dan itu bagus jika ada kisah sukses). Adapun bidang lain, di dalamnya manajer proyek mengambil orang tanpa pengalaman yang tepat, tetapi, misalnya, dengan pendidikan yang relevan atau melanjutkan di mana Anda bisa berbohong dengan tiga kotak. Secara umum, pemilihan harus lebih kritis, dan bahkan lebih baik - dari cadangan internal.
  
• Ketika bekerja dengan proyek, tugas dan sumber daya hanya dari satu sisi diperhitungkan. Setiap proyek memiliki pemegang (pelaksana) dan pelanggan yang sedang menunggu hasil proyek. Paling sering, seluruh proyek ditujukan untuk kepentingan pelanggan, yang harus dipenuhi dengan biaya berapa pun, lebih jarang - itu datang secara eksklusif dari sumber daya kontraktor (proyek internal). Dengan manajemen proyek yang tepat, kepentingan semua peserta harus diperhitungkan, tindakan harus dikoordinasikan.
  
• Ketakutan akan kepemimpinan membuat proyek menjadi krisis. Seringkali karyawan takut untuk melaporkan keadaan sebenarnya, untuk menginformasikan tentang tenggat waktu atau pembengkakan anggaran. Pada akhirnya, proyek tersebut dapat diselesaikan dengan kualitas buruk atau jatuh ke dalam kondisi yang sama sekali tidak ada harapan. Pada gilirannya, manajer dalam situasi seperti itu mungkin tidak memiliki alat untuk mengendalikan dan memantau proyek.
  
• Pekerjaan manajer proyek tidak dapat diukur atau tidak dapat diukur, dan ia sendiri berusaha sekuat tenaga untuk keluar dari KPI (misalnya, dengan alasan bahwa proyek tersebut adalah pekerjaan eksklusif yang tidak dapat diukur) dan mengarah ke premi berdasarkan hasil (satu kali). Pendekatan ini mengurangi tanggung jawab manajer untuk proyek dan "menyebar" di antara peserta lain.
  
• Proyek seringkali tidak menetapkan batas - pemahaman yang samar tentang skala proyek dapat dengan mudah mengubahnya menjadi konstruksi jangka panjang.
  
• Masalah internal proyek dan masalah komunikasi. Awalnya, manajer proyek adalah seorang pemimpin dan, pada saat yang sama, seorang komunikator, yang tugasnya, antara lain, untuk mengoordinasikan dan mengarahkan tim. Tetapi kebetulan manajer menganggap dirinya benar, menempatkan dirinya di atas tim dan mengabaikan tawaran dan bahkan seluruh lapisan pekerjaan, melakukan manajemen mikro, dan berusaha menutup semua tugas. Tim dalam arti kata yang sebenarnya secara bertahap belajar untuk diam. Tentu saja, karya desain, bahkan dipimpin oleh manajer yang paling cerdik, tidak demikian halnya di mana ada satu pejuang di lapangan.
  
  Ya, komunikasi sebagai kekuatan pendorong utama proyek harus transparan dan informatif: semua peserta harus mengetahui status terkini tentang tugas, risiko, dan peristiwa.
  

• Sayangnya, seperti dalam aktivitas apa pun, dalam pekerjaan desain hampir selalu ada tempat untuk prinsip Pareto: 20% tim benar-benar melakukan 80% pekerjaan. Tentu saja, Anda bisa tahan dengan keadaan ini, tetapi lebih baik untuk merangsang pekerjaan dan mendapatkan tim yang lebih efektif.
  

Seperti yang Anda lihat, benar-benar kesalahan manajemen proyek dangkal yang masing-masing dari kita telah bertemu setidaknya sekali. Semakin banyak faktor negatif bertemu, semakin sulit untuk membawa proyek ke final dan berhasil menutupnya. Oleh karena itu, dalam manajemen proyek lebih baik tidak hanya bergantung pada hubungan saling percaya dan penyihir proyek - lebih baik menggunakan alat otomatisasi, karena lebih jelas, dapat diandalkan, transparan dan lebih cepat.

Komponen proyek dan perangkat lunak profesional

Ada formula yang cukup umum yang cocok untuk proyek apa pun, terlepas dari metodologi dan ukuran perusahaan:

proyek = waktu + biaya + ruang lingkup

Inti dari manajemen proyek adalah kemampuan untuk menyeimbangkan pada tiga kendala, meskipun ada intervensi dari manajemen senior.

Dengan demikian, Anda harus memenuhi tenggat waktu, biaya dan tidak kehilangan batas-batas proyek.

Waktu - periode di mana Anda perlu mengimplementasikan proyek, yang biasanya dibagi menjadi jeda waktu yang terpisah. Namun, kinerja tenggat waktu merupakan indikator aerobatik tim, tetapi bukan tujuan itu sendiri: jika eksekusi berkualitas tinggi membutuhkannya, waktunya harus diubah secara wajar. Untuk memenuhi kesenjangan yang diberikan, Anda perlu hati-hati merencanakan kemajuan pekerjaan dan sumber daya yang tersedia.

Biaya (anggaran) proyek adalah parameter terpenting yang membutuhkan perhatian khusus. Kesulitannya terletak pada kenyataan bahwa biaya seluruh proyek harus dihitung dan diumumkan sebelumnya, dan keadaan dan risiko yang tidak terduga tidak seharusnya mengubah biaya secara signifikan. Selama implementasi proyek, perlu untuk memonitor pergerakan dana dan mencatat pengeluaran dan penerimaan. Pendekatan yang cermat terhadap ekonomi proyek menghilangkan sebagian besar sakit kepala dan pembongkaran perusahaan.

Batas-batas proyek tidak hanya penilaian skalanya, tetapi juga kepatuhan ketat terhadap persyaratan pelanggan dan, tentu saja, kerangka acuan dan paspor proyek. Tugas teknis sebenarnya adalah pelindung kontraktor, karena Anda selalu dapat merujuk pada volume pekerjaan dan batasan yang dijelaskan. Agar ToR berhasil, penting untuk secara hati-hati mengumpulkan persyaratan, memecahnya ke dalam tahapan proyek dan menyetujui ketentuan referensi. Ini akan ideal jika Anda menetapkan dan memperbaiki tidak hanya apa yang akan dilakukan, tetapi juga apa yang tidak akan dilakukan.

Pertanyaan penting lainnya: perangkat lunak apa yang cocok untuk manajemen proyek?

Perangkat lunak manajemen proyek membantu sepanjang siklus hidup: dari penetapan tugas dan perencanaan hingga pengelolaan sumber daya, pengendalian biaya dan pelaporan. Selain itu, perangkat lunak ini menciptakan transparansi untuk pihak yang berkepentingan dan anggota tim.

Tentunya, sebagian besar pengembang yang membaca artikel ini telah melihat "tumpukan Atlassian" berulang kali di kepala mereka. Mari kita serahkan kesenangan yang luar biasa ini kepada kami orang-orang TI dan berbicara tentang perusahaan yang tidak begitu maju untuk mempelajari perangkat lunak yang disebutkan. Biasanya, sistem manajemen proyek dipahami sebagai perangkat lunak yang mencakup bagan Gantt dan kartu minimal klien dan karyawan. Tetapi ini sering tidak cukup untuk pekerjaan penuh dengan proyek, jadi Anda harus mengintegrasikan perangkat lunak dengan solusi perangkat lunak lain, dan ini tidak selalu mulus dan selalu mahal.

Jenis program lain adalah CRM, BPM dan perangkat lunak lain dengan mekanisme manajemen proyek bawaan. Oleh karena itu, kami mengintegrasikan modul manajemen proyek ke edisi RegionSoft CRM Enterprise . Selama pengembangan, kami memiliki batasan tambahan (lebih tepatnya, sebaliknya, persyaratan ekspansi) - modul manajemen proyek terletak di dalam RegionSoft CRM kami, yang berarti harus ada koneksi tambahan. Apakah mereka mengganggu tugas manajemen proyek? Tidak, tentu saja - komunikasi dengan pelanggan dan entitas lain hanya akan menguntungkan pengguna:

• bagian umum - informasi tentang tenggat waktu proyek, bertanggung jawab, fakta signifikan, tingkat kesiapan (bilah kemajuan visual), tahap proyek saat ini;
  
• anggaran - pendapatan dan pengeluaran proyek, dengan mempertimbangkan tagihan dan pembayaran;
  
• peserta - informasi tentang penghasilan peserta proyek dan koefisien partisipasi kerja (ini dia, terukur dari setiap kontribusi dan perjuangan dengan prinsip Pareto!);
  
• dokumen - dokumen proyek dalam bentuk file terlampir;
  
• proses bisnis - Anda dapat menjalankan proses yang terkait dengan proyek atau proses perusahaan apa pun yang diperlukan;
  
• peristiwa - peristiwa logging dalam proyek dengan waktu, manajer dan pemegang acara (pemantauan dan transparansi);
  
• tugas - daftar tugas untuk proyek dengan detail maksimum;
  
• penjualan - jika ada penjualan dalam proyek (mungkin juga internal);
  
• layanan - layanan yang disediakan dalam proyek;
  
• deskripsi - bidang gratis untuk deskripsi, catatan, dan hal lainnya.
  

Semua proyek dicatat di bagian khusus tempat Anda dapat menggunakan penyortiran dan filter - proyek yang diinginkan dicari dalam hitungan detik.



Dalam proyek-proyek dalam RegionSoft CRM, anggaran proyek dipertimbangkan dan dimonitor dengan nyaman - dengan memasukkan semua data yang diperlukan, Anda tidak akan kehilangan satu rubel pun. Hanya dengan melihat sekilas pada bilah anggaran sudah cukup untuk memahami bagaimana keadaannya. Dalam bagian anggaran proyek, bagian pendapatan dan pengeluaran diperhitungkan, atas dasar yang mana keuntungan yang direncanakan dan aktual proyek secara keseluruhan, serta remunerasi pesertanya dapat dihitung kemudian.

Pendapatan dan pengeluaran dibagi menjadi terencana dan aktual. Ini memungkinkan Anda untuk mengelola proyek-proyek panjang, yang implementasinya membentang dalam waktu berbulan-bulan atau bahkan bertahun-tahun, merencanakan indikator keuangan proyek pada tahap persiapannya, dan juga memperhitungkan kepatuhan indikator yang benar-benar tercapai dengan yang direncanakan.



Untuk kejelasan lengkap, Anda dapat membongkar seluruh kartu proyek dalam bentuk cetak - alat yang mudah digunakan untuk rapat dan pelaporan.



Masalah utama bisnis kecil dan menengah adalah mereka menolak untuk mengelola proyek dengan cara yang sama seperti mereka menolak untuk mengotomatiskan proses bisnis, mengingat ini adalah hak istimewa dari bisnis besar. Tentu saja, ini pada dasarnya pendekatan yang salah: manajemen proyek yang berfungsi dengan baik sangat menyederhanakan hubungan dalam perusahaan dan hubungan dengan pelanggan. Apakah benar-benar buruk bekerja dalam kerangka kerja yang disepakati, dengan tenggat waktu yang direncanakan dan anggaran yang akurat? Kaif!

Lantas bagaimana cara mengelola proyek?

Tentu saja, kita tidak akan membahas topik manajemen proyek dengan satu artikel ulasan - akan ada materi yang lebih rinci, khususnya tentang manajer proyek, tentang metodologi dan tentang aspek individu dari manajemen. Tapi saya tidak ingin menunda masalah. Oleh karena itu, kami telah merumuskan beberapa aturan manajemen proyek yang dapat diakses dan ditujukan terutama untuk usaha kecil dan menengah - yaitu, tepatnya orang-orang yang dikembangkan RegionSoft dan rasa sakit yang ia tahu tidak seperti orang lain.


joyreactor.cc

• Amati triad utama keterbatasan dalam lingkup manajemen proyek: waktu, biaya, batas. Dengan demikian, bisnis (dan tim!) Akan dikelola lebih efisien dan transparan. Bahkan secara psikologis murni, pawai dalam bentuk proyek dirasakan lebih positif daripada rutinitas abadi: ketika Anda mengetahui istilah-istilah dan melihat cahaya di ujung terowongan, yaitu, akhir tugas, lebih mudah untuk bekerja daripada contoh.
  
• Jangan takut untuk memulai beberapa proyek secara bersamaan - alokasi tugas dan sumber daya yang kompeten akan memberi Anda keuntungan waktu dan pada akhirnya perusahaan akan dapat bekerja lebih cepat dan dengan kualitas tinggi.
  
• Kuda itu mati - menangis. Jika proyek berantakan, batas-batas dan tenggat waktu telah lama dipatahkan, jangan menariknya pada diri Anda dan jangan mencoba untuk melompat lebih jauh, menganalisis penyebab dan masalah dan memulai kembali tugas. Kebetulan semua masalah terletak pada hal-hal seperti, misalnya, proyek yang terlalu rumit - hanya membaginya menjadi beberapa sub proyek kecil dan paralel dan itu akan terbang.
  
• Kumpulkan laporan, lakukan retrospektif, dan analisis masalah, pencapaian, dan jujur. Dengan cara ini Anda dapat menghindari masalah di masa depan. Jika keputusan itu ternyata berhasil, jangan tinggalkan itu hanya satu alasan untuk tim makan pizza dengan bir, pahami alasan untuk sukses dan terapkan dengan berani temuan-temuan dalam hidup.
  
• Jangan lewatkan manajer proyek (paling sering semua masalah dimulai dengan ini). Manajer proyek bukanlah orang dengan persyaratan pendidikan (seperti "Manajemen", penghargaan) dan bukan presenter yang baik, tetapi orang yang memahami topik proyek dan perlu mengatur sistem di mana segala sesuatu ditukar, dengan kata lain, setiap proses memberikan output, yang berfungsi sebagai input untuk proses selanjutnya. Dalam hal ini, tentu saja, terletak komunikasi, dan delegasi, dan kemampuan untuk bekerja dalam tim.
  
• Kelola perubahan - jika sesuatu yang baru muncul di proyek, pastikan untuk memproses acara, jangan mundur dan jangan menolak perubahan. Sekali lagi, semuanya ada dalam kerangka triad: biaya, syarat, batasan.
  
• Proyek harus nyata - untuk tugas-tugas yang diselesaikannya, dan untuk eksekusi. Jika Anda memiliki 200 ribu rubel dan tidak ada sumber pembiayaan tambahan, bodoh untuk memulai gedung sepuluh lantai - bahkan tidak cukup untuk lubang fondasi. Pastikan untuk mengevaluasi relevansi sumber daya yang tersedia dengan tujuan proyek.
  
• Tentukan seberapa efektif biaya dan / atau kelayakan proyek tersebut. Di sinilah kuburan startup yang hilang justru dalam ketidakmampuan untuk menghitung efektivitas. Anda dapat memulai produksi mobil listrik dari kayu atau aplikasi untuk menghitung nyamuk mati, tetapi ini akan menjadi proyek untuk proyek tersebut, tidak ada masalah ekonomi. Mengevaluasi pelanggan nyata atau ukuran pasar di masa depan sebelum memulai proyek. Omong-omong, ini juga berlaku untuk yang nonkomersial - misalnya, amal dan filantropi juga mungkin tidak berguna, tetapi makan satu ton sumber daya.
  
• Rencanakan unduhan dengan cakrawala tertentu - sehingga Anda dapat memahami siapa yang melakukan apa dan sumber daya apa yang sudah terlibat dan akan terlibat di masa depan. Misalnya, untuk tugas-tugas ini, Anda dapat menggunakan perencana grup yang dibangun dalam sistem manajemen proyek atau CRM (baik, atau bagan Gantt).
  
• Kelola dokumentasi - semua dokumen proyek harus dikumpulkan bersama dan berisi informasi komprehensif tentang setiap tahap, pembayaran, persyaratan, dll.
  
• (, , Agile), , , , .
  
• . , , . , . , — .
  

— , , . , , , , , . , , . — , .

?