Kami memiliki proyek untuk mengembangkan dan menerapkan sistem TI baru! Dan Anda membutuhkan PM ...
Apa yang terjadi Di mana tanpa itu. Dan tampaknya pasar dipenuhi dengan semua jenis manajer proyek.
- Pilih! Setiap orang memiliki pengalaman kaya yang luar biasa. Ada PM dengan pengalaman dalam mengimplementasikan proyek di Konstruksi dan Pertahanan. Ada PM dengan pengalaman dalam mengimplementasikan proyek medis. Bahkan ada di Pesawat! Apa lagi yang Anda butuhkan !? Tingkat tanggung jawab dan ketepatan dalam industri-industri ini adalah dump total kepala.
"Apakah dia tahu itu?"
- Mengapa kamu membutuhkan ini ?! Dia memiliki pengetahuan yang sangat baik tentang metodologi manajemen proyek ... ini adalah hal utama!
Dan ini juga terjadi ...
Mari kita pahami jika TI diperlukan untuk manajer proyek yang harus datang dan mengatur pengembangan dan implementasi sistem informasi.
Jadi, pertama-tama Anda perlu mengembangkan sistem informasi!
- Ayolah, PM, apa yang akan Anda lakukan pertama kali?
- Tetapkan kebutuhan dan tujuan!
- Bagus Lalu?
- Mari menyusun rencana proyek pengembangan!
- Masuk akal. Dan apa saja tahapan perkembangannya? Penting untuk menentukan tugas-tugas tingkat atas untuk komposisi!
"Kenapa aku butuh ini?" Saya akan bertanya pada seseorang!
- Dan siapa di TI yang memiliki informasi ini?
- Siapa, siapa? Programmernya ... mungkin ...
Baru-baru ini, saya menemukan cerita yang sama. Di satu sisi, semuanya tampak lancar. Memang, programmer tahu tahap pengembangan apa yang biasanya terdiri. Tapi, mari kita buat amandemen. Agar tidak ketinggalan sasaran, mari kita pergi ke Arsitek! Dia pasti tahu pasti.
- Hai Arsitek. Terdiri dari apakah pengembangan itu? Perlu tugas dalam rencana.
- Kita harus mengambil TK dan fungsi fungsional di atasnya!
"Apakah hanya itu?!" Sangat mudah
- Yah, masih tes.
- Dan bagaimana jika TK berubah dalam proses?
"Aku tidak tahu itu." Pekerjaan saya adalah bekerja di TK
Kami turun. Mereka bertanya. Menerima 2 poin: TK dan Pengembangan.
- Apa yang akan kita lakukan, PM?
- Jadi semuanya jelas! Kami akan meminta dan memberikannya kepada Arsitek. Biarkan itu dihargai. Mengatakan batas waktu. Ini akan menentukan titik-titik kesiapan, dan kami akan mengendalikannya pada titik-titik ini. Dan secara berkala menunjukkan hasilnya kepada pengguna.
Begitulah yang terjadi, kira-kira, ketika PM tidak tahu.
Dan apa yang akan kita tanyakan padanya ketika kita mempekerjakan? Dan jika Anda melangkah sangat jauh, lalu Apa siklus hidup Sistem Informasi dari lahir hingga mati. Meskipun, sistem tidak mati. Mereka "secara moral" usang.
Saya tidak akan pernah melupakan kisah “lucu” dengan sistem pendingin udara saluran yang terjadi di pabrik kami. Ditemukan, kemudian, suatu sistem. Bagus, kuat. Seharusnya mendinginkan seluruh pabrik dan bangunan administrasi yang berdekatan. Dibeli dengan baik. Sebab, sekitar 200 ribu rubel Amerika. Mereka menaruhnya. Dioperasikan. Setelah beberapa bulan beroperasi, sistem bengkok. Mengapa Ya, karena tidak ada sistem yang dapat bertahan tanpa dukungan dan dukungan teknis reguler!
Tetapi sistem informasinya tidak berbeda. Juga, seperti sistem lain, itu membutuhkan commissioning. Sama seperti yang lain adalah infrastruktur. Dan, kadang-kadang, kesalahan implementasi yang terjadi pada proyek untuk mengimplementasikan sistem keuangan jauh lebih mahal daripada melanggar kondeya.
Jadi bagaimana mungkin PM yang datang ke proyek TI dari industri Penerbangan atau Konstruksi dapat membuat rencana yang harus memuat semua tahapan ini?
Dapatkan saran dari Arsitek? Siapa yang secara terpisah melihat tugasnya dan tidak membayangkan apa yang "sebelum" dan apa yang "setelah"? Sayang Proyek semacam itu sudah ditakdirkan terlebih dahulu.
Oleh karena itu, memahami PM, tugas-tugas apa proyek terdiri, tugas-tugas yang terkait, dan yang dapat dilakukan secara paralel, penting untuk proyek TI.
Dan bagaimana kita sekarang mengerti berapa banyak PM sesuai dengan hasil yang diharapkan? Untuk melakukan ini, ada sejumlah pertanyaan yang tidak sulit yang perlu kita jawab dengan jelas.
Pertanyaan 1: Apa saja tahapan pembentukan spesifikasi teknis untuk pengembangan?Jawabannya adalah:- Dari pembentukan persyaratan fungsional pelanggan
- Pembentukan tugas untuk infrastruktur, yang, pada gilirannya, adalah hasil dari pengembangan Kontrak untuk toleransi kesalahan dan cadangan
- Dan dari peta interaksi sistem masa depan dengan sistem lain.
Bahkan, kami mendapatkan 3 tugas di pintu keluar: fungsional dan teknis, spesifikasi teknis untuk infrastruktur, spesifikasi teknis untuk pengembangan antarmuka. Mereka juga merupakan titik pemeriksaan untuk kontrol.
Pertanyaan 2: Apa saja tahapan perkembangannya?Jawabannya adalah:- Dari distribusi tugas oleh pengembang
- Dari pembentukan rencana penerimaan
- Dari pengujian komprehensif (uji coba)
- Dari membuat rencana migrasi, dan mengembangkan rencana ini
Pertanyaan 3: Apa saja tahapan commissioning?
Jawabannya adalah:- Uji beban
- Pembentukan bahan ajar
- Pelatihan pengguna
- Mengisi semua NSI (Informasi Referensi Normatif + akses pengguna)
- Migrasi data
- Rekonsiliasi saldo
- Mulai dari pekerjaan operasional (uji coba)
- Bantuan panas saat peluncuran pertama
Pertanyaan 4: Seperti apa skema untuk mentransfer sistem untuk mendukung setelah commissioning?Jawabannya adalah:Setidaknya sistem memiliki 3 level dukungan:
- Dukungan infrastruktur dan pemantauan beban server
- Dukungan fungsional dan pemantauan utas, jika terjadi kesalahan dalam sistem.
- Dukungan metodologis memberikan jawaban atas pertanyaan mengapa ini bekerja dengan cara ini dan bukan sebaliknya, serta mengumpulkan kebutuhan untuk evolusi
Dan masing-masing tahap ini harus memiliki SLA sendiri. Berikut ini juga kata yang tidak selalu jelas bagi orang di luar TI.
Jika kandidat PM tidak menyebutkan semua tahapan - tidak masalah. Bisa melupakan sesuatu atau khawatir. Ketika rencana itu terbentuk, entah bagaimana ia akan menemui mereka. Jauh lebih buruk jika dia tidak membayangkan ini sama sekali. Situasi akan menjadi lebih rumit jika dia mulai memproyeksikan pengalaman sebelumnya dari bidang bisnis lain ke TI. Dalam hal ini, tim akan memulai konflik dan "kematian" pengembang. Manfaat seorang teknisi itu sendiri selalu dapat ditemukan di mana pun manajemen proyek TI yang kompeten akan menjadi zona nyamannya.