Penafian: Hari ini kami akan berbicara secara eksklusif tentang proyek yang tidak berhasil, jadi kami tidak akan menyebutkan nama, kata sandi, dan kehadiran.
Semua kasus gagal dari pengalaman saya dan teman saya dapat dibagi menjadi tiga jenis menurut sumber masalahnya:
1. Bekerja dengan pemangku kepentingan
Alasan banyak masalah proyek adalah kita tidak mendengarkan atau mendengar pelanggan. Hal ini sangat penting di awal, ketika ada risiko kehilangan jawaban atas pertanyaan "Mengapa proyek dimulai?"
Kasus 1
Kami dihadapkan pada tugas sederhana - untuk memblokir semua kemungkinan transaksi keuangan di bawah kontrak yang tidak disepakati dalam perusahaan. Kami menghitung efeknya dan bekerja, seperti yang terlihat bagi kami, semua risikonya. Namun, selama diskusi, pengguna utama berpendapat bahwa ini tidak akan berhasil: "Kami akan memiliki proses produksi." Itu tampak seperti alasan, dan pelanggan utama mengkonfirmasi hipotesis kami dan bersikeras untuk melakukannya.
Pada hari X, kami meluncurkan fungsionalitas sesuai dengan rencana kami, dan sekitar satu setengah jam kemudian, pelanggan utama kami, dalam suasana hati yang tidak terlalu baik, menelepon dan meminta untuk mengembalikan semuanya: "Tidak berfungsi!".
Bagaimana itu diperlukan?Dengarkan kekhawatiran pengguna, yang mengetahui secara spesifik pekerjaan organisasi dari dalam, dan selesaikan risiko ini. Selalu ada kesempatan untuk menemukan opsi yang cocok untuk semua orang.
Kasus 2
Itu adalah pelanggan fungsional yang sangat memahami tugas dan sistem yang telah kami buat. Tetapi kami tidak memperhitungkan minat departemen TI dalam implementasi proyek ini dan datang kepada mereka agak terlambat: pada tahap pengembangan arsitektur. Saya harus merevisi proyek dan memindahkan tenggat waktu pengirimannya. Kami kehilangan waktu, uang, dan reputasi dengan melebih-lebihkan pengaruh dan kapabilitas pelanggan fungsional dan meremehkan hubungan internal antar departemen di perusahaan besar.
Bagaimana itu diperlukan? Untuk melibatkan semua pihak yang berkepentingan dalam pengerjaan proyek sejak awal dan mempertimbangkan kepentingan mereka, meskipun ada jaminan dari pelanggan.
Kasus 3
Dan ini adalah kasus yang hampir tidak berhasil. Pelanggan fungsional, yang diwakili oleh CEO, ingin mengubah metodologi akuntansi biaya dan, menurut semua kalkulasi, pengaruh perubahan tersebut seharusnya signifikan. Tim dari blok keuangan siap untuk perubahan dan pada saat tugas mencapai analis TI, keputusan sudah dibuat. Dan di sini kami melakukan hal yang benar dan bertanya: Mengapa? Bagaimana cara kerjanya? Siapa yang akan mendukung proses tersebut? Bagaimana Anda mempertimbangkan efeknya?
Akibatnya, efeknya dihitung ulang dengan mempertimbangkan perubahan dalam sistem ERP dan biaya pemeliharaan proses dan alat. Tidak hanya efeknya "menghilang" dalam uang, tetapi risiko tambahan juga ditemukan. Proyek ditutup, dan untuk karyawan divisi otomasi internal, sudah menjadi aturan untuk mengajukan pertanyaan di awal, bahkan jika tugas berasal dari CEO.
kesimpulan
- Selalu cari alasan, tujuan, efek. Perdebatkan posisi Anda. Seperti yang dikatakan seorang teman saya (manajer kelas): "Dengarkan, jangan jual ... Kemudian dengarkan lagi ... dan baru jual";)
- Hidup satu hari dengan pengguna langsung produk dan kenali rutinitas mereka secara detail. Ini akan membantu mengantisipasi semua kemungkinan nuansa.
- Atasi semua risiko yang tampak signifikan bagi Anda, pelanggan fungsional, dan setiap orang yang tertarik. Berikan perhatian khusus pada pelanggan / pengguna yang paling negatif terhadap proyek. Mereka jelas tahu sesuatu! ;)
- Jangan lewatkan satu peserta pun dalam prosesnya. Tidak boleh ada satu peserta dalam proses, dan departemen TI harus selalu diperhitungkan!
2. Deskripsi kebutuhan
The Holy of Holies untuk setiap analis adalah deskripsi dari persyaratan. Mari pertimbangkan kesalahan di area ini pada dua kasus lainnya.
Kasus 1
Salah satu tim pengembang menerima proyek yang membutuhkan revisi. Sistem dilengkapi dengan dokumentasi, di mana deskripsi logika sistem ditulis menggunakan kueri SQL. Pada saat pekerjaan dimulai, sistem telah didesain ulang secara serius dan kueri SQL tidak lagi relevan. Saya harus menghabiskan waktu melakukan reverse engineering untuk memahami logika dan fungsionalitas sistem.
Bagaimana itu diperlukan? Periksa kembali dokumen untuk relevansi dan kepatuhan dengan tingkat perkembangan proyek. Apalagi saat meneruskannya ke developer lain.
Kasus 2
Itu adalah proyek yang menarik untuk mengotomatiskan semua proses dalam organisasi. Proyek ini melibatkan 5 sistem dari berbagai kelas, yang harus diintegrasikan satu sama lain agar proses dapat berlanjut tanpa gangguan. Tim merancang arsitektur solusi selama sekitar dua bulan, ketika saya terhubung ke proyek.
Dalam proses komunikasi dengan pelanggan, saya menyadari bahwa dia melihatnya dalam satu cara, dan pengembang dengan cara lain. Ini adalah kesepakatan minimum dengan kata-kata yang benar-benar mengubah proyek. Saya harus mulai dari awal dan mengerjakan semua persyaratan dari awal: Mengapa? Apa? Bagaimana?
Bagaimana itu diperlukan? Jelaskan dengan jelas tidak hanya persyaratan untuk implementasi proses dan sub-proses (cara kerjanya), tetapi juga bagaimana hasil akhir akan terlihat.
kesimpulan
Seringkali, tim takut dengan komentar pelanggan dan berlari untuk berkembang ketika mereka mendengar "baiklah, semacam itu." Kami dapat berasumsi bahwa Anda menemukan bahasa yang sama dengan Pelanggan hanya jika dia sendiri mulai membuat penyesuaian dengan tangannya sendiri. Beberapa orang merasa nyaman untuk membaca teks, yang lain - skema, dan lainnya - tata letak antarmuka. Layak untuk mencoba semuanya sampai Anda menemukan bahasa yang sama, bahkan jika itu adalah "gambar di atas serbet".
3. Pengembangan ide, produk atau solusi
Ini adalah cerita tentang manajemen produk, ketika ide membanjiri pikiran, dan yang lainnya tidak menjadi masalah.
Kasus 1
Kami memiliki produk hebat untuk mengotomatiskan tugas-tugas rutin dalam organisasi: mulai dari memasukkan informasi hingga menjawab pertanyaan apa pun dari karyawan. Dan semuanya luar biasa: kami menemukan pelanggan pertama, kami memahami pasar - sepertinya ada banyak uang - kami meluncurkan beberapa proyek dan berhasil menyelesaikannya. Dan pada saat itu kami membuka mata: tidak ada yang menghitung biaya untuk mendukung solusi tersebut. Dan itu menghapus semua kemungkinan upaya untuk menghasilkan uang menjadi nol.
Bagaimana itu diperlukan? Hitung dengan cermat semua aspek proyek: dari pengembangan hingga dukungan solusi.
Kasus 2
Cerita lainnya adalah ketika kami tidak berhasil di pasar. Sebuah ide ditemukan untuk produk bagus yang tidak memiliki pesaing di pasar, tetapi memiliki pelanggan. Setidaknya satu, dan dia bersedia membayar dan berinvestasi. Kami masuk ke proyek ini dan dihadapkan pada kekurangan dasar teoritis untuk pengembangan fungsi tersebut, tetapi kami berhasil.
Dan setelah memasuki pasar dengan produk, mereka menyadari bahwa tidak ada pesaing yang sia-sia. Banyak orang mengabaikan fitur ini terlepas dari semua efek yang dijaminnya.
Bagaimana itu diperlukan? Pikirkan mengapa tidak ada pesaing di sektor pasar yang menguntungkan dan cari tahu kebenarannya.
Kesimpulan:
Periksa kelayakan proyek dalam kerangka bukan hanya satu pelanggan, tetapi daya saing - sesuai dengan situasi pasar saat ini.
Budaya kegagalan
Untuk mengatasi kesulitan dan tidak terjebak lagi di dalamnya, Anda perlu menemukan alasannya. Lebih sering daripada tidak, itu terletak pada budaya kegagalan yang diadopsi dalam organisasi. Ada dua cara buruk untuk menanggapi kegagalan dalam organisasi:
- Penghukuman / Hukuman
Mengutuk kesalahan, kita membunuh inisiatif. Karyawan takut untuk menjadi kreatif dan hanya membuat keputusan yang aman. Hal ini menyebabkan terjadinya stagnasi di perusahaan.
Solusi: tentukan batasan untuk kesalahan. Perlu untuk mengalokasikan sumber daya untuk perwujudan inisiatif dan memeriksanya di pos pemeriksaan. Nah, lacak keberhasilan proyek sesuai dengan kriteria ketat yang disepakati sebelumnya. - Diam
Taktik ini mengarah pada pengulangan kesalahan yang sama berulang kali. Dan ini, pada gilirannya, menyebabkan hilangnya posisi perusahaan di mata pelanggan, pesaing, dan pasar.
Solusi: bangun sistem pertukaran pengalaman antar karyawan. Diskusi tentang solusi yang mungkin untuk kegagalan pada akhirnya mengarah pada metodologi yang membantu menghindari kesalahan ini.
Refleksi yang masuk akal membantu untuk berkembang, tetapi ini bukan alasan untuk mengelilingi diri Anda dengan kegagalan saja. Carilah keseimbangan, karena belajar dari proyek yang sukses jauh lebih menyenangkan