7 alasan mengapa proyek web tidak berakhir, dan bagaimana menghadapinya

Ada puluhan kerangka kerja dan metodologi yang digunakan dalam pekerjaan desain. Tidak ada lagi orang yang tidak mau mendengar tentang gesit, scrum, kanban dan pendekatan lainnya. Masing-masing dari mereka berjanji untuk menjadi peluru perak, yang akan membantu untuk melaksanakan proyek sehingga mereka memenuhi semua parameter keberhasilan. Namun dalam praktiknya, hanya pekerjaan yang kompeten dengan risiko yang memungkinkan Anda menyelesaikan proyek dengan segala cara.

Pada artikel ini kami akan mencoba untuk mempertimbangkan risiko paling penting yang mungkin menghalangi Anda. Materi akan bermanfaat bagi semua orang yang terlibat dalam pekerjaan desain.



Jadi proyek mana yang dianggap berhasil? Merupakan kebiasaan untuk menyoroti parameter berikut:

  • proyek dikirim tepat waktu;
  • tanpa melebihi anggaran;
  • dengan jumlah cacat minimum;
  • bekerja sebagaimana dimaksud;
  • orang menggunakannya;
  • memecahkan tujuan yang ditetapkan di hadapannya;
  • - ;
  • .

Jadi, seberapa seringkah proyek yang selesai memenuhi semua poin ini?

Dengan perbedaan kecil dalam perkiraan studi dari Standish Group, Project Management Institute, Gartner, Wellingtone, dan organisasi terhormat lainnya , kami diberitahu bahwa sepertiga dari proyek TI ternyata gagal, dan setengahnya mengalami kesulitan. Bayangkan, ini adalah statistik yang menakjubkan.

Sulit untuk mengatakan tingkat proyek yang berpartisipasi dalam sampel, tetapi mari kita asumsikan bahwa ini adalah cerita besar seperti kegagalan modernisasi infrastruktur TI dari rantai toko KMart sebesar $ 1,2 miliar, yang telah menjadi salah satu faktor kunci dalam kebangkrutan perusahaan.

Apakah ini berarti bahwa proyek yang lebih kecil yang membuat studio web Rusia tidak mengalami masalah yang sama? Jika Anda membaca ulasan pelanggan pada agregator populer, kita akan melihat bahwa bahkan dalam kasus halaman arahan dan templat toko online biasa, kriteria keberhasilan di atas jarang dipenuhi:

“Kami memesan pengembangan dan desain situs pada tahun 2015. Desain dilakukan dengan cepat, tetapi tidak untuk mengatakan kualitas itu. Pengembangannya diperkenalkan sampai tahun 2017 dan tidak pernah dilaksanakan ”
“Situs setelah pekerjaan seperti itu harus sepenuhnya dibangun kembali, pada awalnya tentu saja pekerjaan berjalan aktif dan sepertinya semuanya baik-baik saja. Tetapi kemudian mereka mulai memperhatikan bahwa kami mengulangi tugas yang sama selama sebulan, akibatnya, kami hampir berhenti menjawab pertanyaan. Akibatnya, hasilnya minus besar, karena saya harus menyewa pemasok lain ”
“Beberapa kali mereka menunda ketentuan implementasi situs dengan perjanjian tambahan. Akibatnya, semua tenggat waktu yang disepakati juga terganggu dan pengembangan situs memakan waktu 1,5 tahun. Outputnya adalah produk mentah yang tidak dapat digunakan. Saya harus memberikan situs untuk revisi ke studio lain ”
Apa yang bisa kita katakan tentang perkembangan individu yang lebih luas? Lagi pula, semakin besar proyek, semakin besar peluang untuk tidak bertahan hingga selesai. Oleh karena itu, setiap pelanggan dan kontraktor harus memiliki pertanyaan - bagaimana tidak sampai ke pemakaman proyek yang belum selesai.

Mari kita cari tahu apa yang bisa salah dalam proyek pengembangan kustom, dan apa yang harus dilakukan:

Risiko 1. Kualifikasi kontraktor yang tidak memadai


Masalahnya di sini adalah bagaimana pengembangan kustom berfungsi. Klien sering tidak mengerti siapa yang dipercaya oleh proyek, karena di setiap sudut mereka menjanjikan siklus pengembangan penuh dan pekerjaan turnkey.

Setelah memutuskan untuk mendigitalkan bagian dari bisnis, perusahaan beralih ke studio web (alias agen digital / integrator web). Layanan dilakukan dalam format jendela tunggal. Klien diminta untuk mengisi brief, berdasarkan TK yang kemudian dikompilasi. Jika proyek ini kompleks dan membutuhkan programmer yang berpengalaman, maka pengembangannya diserahkan kepada produksi.

Subkontraktor diharuskan untuk melakukan pekerjaan pada ToR, yang disusun oleh orang-orang yang tidak kompeten. Jika sebuah proyek bertahan untuk dirilis, sering kali ternyata produk itu tidak menyelesaikan tugas perusahaan, tidak ada yang mau menggunakannya.


— , , . .




Betapapun sepele, yang paling penting adalah memahami masalahnya. Kami tidak menyisihkan sumber daya untuk pencelupan dalam bisnis pelanggan. Kami siap untuk mengatur perjalanan bisnis dan berkomunikasi di tempat tidak hanya dengan para pemangku kepentingan, tetapi juga dengan orang-orang yang akan menggunakan produk akhir. Kami tidak akan mulai menghabiskan anggaran proyek sampai kami yakin bahwa kami telah menemukannya.

Studio web TK terdiri dari analis yang bekerja sebagai penguji kemarin. Tidak memahami seluk-beluk pengembangan, mereka membuat dokumen yang menggambarkan elemen-elemen antarmuka, tetapi pada saat yang sama mengabaikan integrasi kompleks dan algoritma yang tersembunyi di balik elemen-elemen ini.


Sebuah contoh nyata dari formulasi atas dasar yang mengharuskan kontraktor umum menghitung biaya pengembangan akhir.


Kontraktor umum meminta untuk menghitung biaya pengembangan menggunakan contoh yang serupa dalam format, tetapi layanan yang diimplementasikan sangat berbeda. "Buat di sana, kami akan mencari tahu"

Ketika datang untuk mengotomatisasi suatu perusahaan, pendekatan ini tidak benar. Tidak cukup hanya menggambar layout dan menggambarkannya di TOR. Oleh karena itu, lebih baik untuk mempercayakan tahap analitik kepada arsitek sistem yang memahami apa yang disembunyikan "di bawah tenda".

Risiko 2. Kelelahan Anggaran Sebelum Peluncuran Produk


Pasar layanan digital didominasi oleh anggaran tetap dan pascabayar. Oleh karena itu, akun dan penjualan lebih mungkin untuk menyetujui estimasi dan menyimpulkan perjanjian. Jika studio web salah menyusun kerangka acuan, melakukan pelingkupan yang tidak lengkap, dan menggambar subkontraktor untuk pengembangan, neraka produksi dapat terjadi pada proyek.

Volume pekerjaan akan lebih besar, kontraktor umum akan mulai melindungi kepentingan mereka dan mendorong para pemain akhir sehingga mereka masuk ke dalam anggaran. Di kedua sisi, logika yang sesat bekerja, masing-masing muncul dengan alasan untuk melakukan sedikit lebih buruk daripada lawan: “Sudahkah Anda memberikan TK yang buruk, dan sekarang mereka menambah volumenya? Maka kami tidak akan mempertimbangkan beberapa pernyataan! " / "Kami sudah berjanji pada klien ke mana mereka akan pergi, menyelesaikan atau tidak mendapatkan uang!".

Perang politik ini disembunyikan dari mata klien. Dia tidak tahu tentang siapa yang terlibat dalam proyek tersebut, dan bagaimana proses pengembangannya berjalan - mitra studio web menandatangani NDA. Akibatnya, produksi mengorbankan kualitas produk agar tidak bekerja pada kerugian, dan studio web hanya memikirkan cara menandatangani akta dan menerima pembayaran sesegera mungkin. Tidak ada yang peduli tentang manfaatnya bagi klien.

Metode penghindaran


Saat membuat perkiraan, studio web hanya terbatas pada tahapan umum pekerjaan: analitik, desain, tata letak, pemrograman. Sedangkan kontraktor yang kompeten akan memasukkan dalam perkiraan semua elemen fungsional dari sistem yang dikembangkan.

Berdasarkan percakapan lima menit dengan klien, tidak mungkin menilai ruang lingkup kerja pada transformasi digital bisnis. Oleh karena itu, bekerja dengan perkiraan itu sendiri memerlukan beberapa tahap, dan tanpa analitik tidak akan mungkin untuk mendapatkan biaya pengembangan akhir.

Kami menawarkan pelanggan yang ragu untuk menghitung biaya proyek sesuai dengan detail kami. Sejauh ini, tidak ada pesaing yang setuju, meskipun ada studio yang berjanji untuk membuat lebih murah.

Tetapi bahkan dengan spesifikasi teknis dan perkiraan yang rumit, proyek ini tidak dilindungi dari ketidakseimbangan dalam jadwal produksi. Begitu ancaman tersebut muncul, penting tidak hanya untuk memperingatkan klien, tetapi juga untuk mengusulkan rencana tindakan alternatif dan optimalisasi ruang lingkup pekerjaan. Anda tidak bisa diam dan berharap "mungkin itu akan reda."

Risiko 3. Perubahan di tengah proyek


Proyek untuk pengembangan sistem digital berlangsung rata-rata setidaknya setahun. Apa pun bisa terjadi selama ini.

Mungkin saja bahwa di tengah proyek klien telah mengubah cara berbisnis, atau teknologi yang lebih maju telah muncul, atau mungkin ada sesuatu yang baru saja berubah di dunia.

Misalnya, mereka mengembangkan sistem pengiriman kurir, tetapi karena situasi politik, pasar berubah, agregator besar mengurangi komisi mereka, dan proyek tidak lagi menyelesaikan tujuan yang ditetapkan untuk itu. Dalam keadaan seperti itu, sangat normal jika klien mulai mengubah tugas tanpa menunggu selesainya pengembangan. Anda harus bisa bekerja dengan ini.

Metode penghindaran


Jika klien menawarkan untuk mengubah sesuatu, maka pertama-tama Anda perlu mencari tahu mengapa ini dan keadaan apa yang menyebabkan keputusan ini. Ajak klien bicara jujur ​​untuk memahami rasa sakitnya.

Hanya setelah itu, menilai apakah perubahan ini akan bermanfaat bagi proyek, dan mencoba mengantisipasi risiko yang menyertainya, termasuk melebihi anggaran. Selanjutnya, temukan pendekatan terbaik untuk mengimplementasikan perubahan ini dalam produk dan menawarkannya. Tetapi pilihan harus tetap di tangan klien.

Risiko 4. Kehilangan minat dari pihak pemilik


Ketika sesuatu berubah di dunia, klien mungkin terbawa oleh lini bisnis lain, dan melupakan proyek saat ini. Kehilangan minat menyebabkan fakta bahwa pemain diminta untuk benar-benar membatasi pekerjaan, atau, lebih buruk, dibiarkan limbo. Menunggu keputusan mengarah pada waktu henti dan biaya.

Tetapi lebih sering, minat menghilang ketika perubahan serius dalam struktur organisasi terjadi di sisi klien, orang-orang berubah pada proyek. Sebagai aturan, orang-orang ini tidak memiliki konteks penuh, dan oleh karena itu, tidak melihat nilai proyek. Motivasi mereka untuk meluncurkan produk sangat rendah.

Metode penghindaran


Untuk terus mempertahankan minat pada proyek, kami menunjukkan kepada klien semua hasil antara. Proyek besar biasanya terdiri dari serangkaian layanan, oleh karena itu, sebagai hasil dari setiap iterasi pengembangan, kami berusaha untuk menunjukkan fungsionalitas yang sepenuhnya siap pakai dari layanan terpisah yang sudah dapat digunakan. Jadi klien melihat bahwa produk menyelesaikan masalah bisnisnya.

Selama pengembangan, kami memeriksa untuk melihat apakah tujuan proyek telah berubah, dan kami secara teratur berkonsultasi dengan mereka. Kami melakukan analisis tambahan dan mengumpulkan umpan balik dari audiens target. Kami melibatkan perwakilan pelanggan dalam proses pengembangan dan mendukung penilaian prospek proyek dalam keadaan terkini.

Risiko 5. Pelanggan tidak mengalokasikan waktu untuk berpartisipasi dalam proyek.


Karyawan di sisi klien tidak memberikan informasi yang diperlukan, manajer perlahan merespons dan semuanya melambat. Pada saat yang sama, kami tahu pasti bahwa klien membutuhkan proyek, bunga belum hilang, tenggat waktu masih bijaksana.

Sayangnya, ini sering terjadi. Dalam hal ini, pelaksana yang tidak berpengalaman akan mulai tersinggung, menurunkan prioritas tugas klien, dan pada akhirnya mengalihkan seluruh tim pengembangan ke proyek lain. Logika pemain jelas di sini, tidak ada yang menginginkan waktu henti tim karena persetujuan yang terlalu lama. Ini menghasilkan hubungan pelanggan yang terputus. Proyek ini belum selesai.

Metode penghindaran


Kami secara pribadi setuju dengan klien mengenai definisi orang yang bertanggung jawab. Kami membahas status dan tingkat tanggung jawab mereka. Kami memperbaiki fungsi dan tanggung jawab mereka dalam jadwal kerja.

Segera setelah kami menyadari bahwa orang yang bertanggung jawab dihadapkan pada beberapa jenis pembatasan, bersama dengan klien kami mencari solusi bagaimana menghilangkan hambatan ini dan melanjutkan proses pengembangan. Jika orang yang ditunjuk tidak sepenuhnya mematuhi perjanjian, kami sarankan menunjuk karyawan lain di tempat mereka.

Risiko 6. Penyesuaian / peningkatan yang berkepanjangan


Klien tidak selalu cukup kompeten untuk menilai tingkat kesiapan proyek. Ini normal. Jauh lebih buruk ketika kontraktor tidak mengerti apakah proyek sudah siap. Komisioning seringkali tertunda karena perubahan yang tidak masuk akal. Ini mengarah pada fakta bahwa kedua belah pihak kehilangan waktu dan uang.

Situasi ini sering terkait dengan fakta bahwa suntingan ditawarkan oleh orang-orang yang tidak bertanggung jawab atas hasil akhir. Jika Anda tidak berusaha memperbaiki orang yang bertanggung jawab sebelumnya, maka komentar akan datang dari orang yang tidak memiliki keterampilan yang memiliki konteks yang tidak lengkap. Kebetulan mereka terhubung pada tahap akhir, dan karena itu mereka tidak tahu apa-apa tentang keterbatasan dan tujuan proyek.

Seorang kontraktor yang tidak berpengalaman akan membantah pengeditan ini tanpa henti agar tidak membuatnya dengan biaya sendiri atau, sebaliknya, benar-benar mempertimbangkan semua komentar. Semua ini berdampak buruk pada pencapaian tujuan awal proyek.

Metode penghindaran


Jika komentar berasal dari orang yang tidak bertanggung jawab, maka kami memperbaikinya dan mendiskusikannya dengan orang-orang yang bertanggung jawab langsung atas proyek tersebut. Sebelum melakukan pengeditan, kami mencoba memahami bagaimana perubahan ini akan membantu keseluruhan tujuan proyek. Jika hasil edit tidak membantu, tetapi hanya mengganggu, kami menyatakan keprihatinan kami.

Jika pemilik produk meminta perubahan, kami memperingatkan bahwa ini akan menunda peluncuran. Kami menawarkan solusi yang kompeten untuk mengoptimalkan ruang lingkup pekerjaan, dengan mempertimbangkan yang baru pengantar. Bersama dengan klien, kami mencari tahu apa yang akan terjadi jika kami merilis produk dalam bentuk apa adanya. Ketika tidak ada konsekuensi negatif yang jelas, kami menyarankan untuk menunda pengeditan ke tahap berikutnya. Selain itu, pilihan selalu ada di tangan klien.

Risiko 7. Tidak tersedianya infrastruktur untuk peluncuran


Kenyataan bahwa infrastruktur klien tidak siap, nuansa hukum tidak disusun, dan tidak ada perjanjian kemitraan dapat menghambat peluncuran proyek ke dalam operasi.

Misalnya, sistem dirancang untuk bekerja pada SSD, dan infrastruktur saat ini menggunakan HDD, atau bisnis meluncurkan arah baru, tetapi belum menerima izin dari departemen pemerintah.

Kontraktor terkadang terus bekerja dalam situasi seperti itu, mengabaikan masalah di sisi klien. Karena dia merasa nyaman untuk tidak melampaui bidang tanggung jawabnya. Secara formal, kontraktor melakukan hal yang benar, masalahnya ada di pihak pelanggan. Tetapi apa gunanya suatu produk yang tidak mungkin diluncurkan, apa manfaatnya?

Metode penghindaran


Sebelum mulai bekerja, kami mendiskusikan dengan pelanggan sumber daya yang diperlukan untuk meluncurkan proyek. Kami memberikan rekomendasi tentang orang yang akan disewa dan peralatan apa yang akan dibeli. Jika proyek ini tidak standar, silakan berkonsultasi dengan pengacara dan pastikan bahwa tidak akan ada masalah pada bagian dari undang-undang saat diluncurkan.

Pada tahap pembentukan TK, kami memeriksa peluang untuk integrasi dan aspek teknis lainnya dari pengoperasian produk akhir.

Kesimpulan


Semua risiko entah bagaimana saling berhubungan. Satu masalah yang belum diperbaiki dalam waktu dapat menyebabkan efek bola salju.

Tetapi pengalaman menunjukkan bahwa ada tiga cara universal untuk mencegah dan meminimalkan konsekuensi risiko:

  • Memperbaiki potensi risiko;
  • Rencana tindakan untuk menghindarinya;
  • Kesediaan untuk mengubah arah dan mencari solusi alternatif.

Berpikir dengan benar bukan tentang proyek, tetapi tentang pelanggan. Berkomunikasi dan bekerja secara konstan dengan harapan pelanggan. Jangan menyembunyikan apa pun dan membantu melihat kepenuhan situasi.

Di balik setiap risiko yang dijelaskan adalah kasus nyata dari pengalaman Solusi Kerja. Ini tidak selalu cerita dengan akhir yang bahagia, beberapa dari mereka menelan biaya jutaan rubel perusahaan.

Tetapi semua kekuatan yang kita berikan untuk membangun kemitraan yang saling percaya dengan pelanggan sering terbayar, meskipun tidak dengan cepat.

Karena transparansi dalam hubungan, kami memiliki klien yang telah bekerja dengan kami selama lebih dari enam tahun, dan untuk itu kami telah menurunkan puluhan ribu jam kerja. Untuk kerja sama yang begitu lama, berbagai risiko muncul sebelum proyek, tetapi kami selalu mencoba untuk menginformasikannya tepat waktu dan mengusulkan cara untuk menyelesaikannya. Oleh karena itu, kami percaya bahwa manajemen risiko yang kompeten memastikan penyelesaian proyek.

Dalam komentar, saya sarankan berbagi cerita dari pengalaman Anda ketika proyek tidak selesai. Apakah ada dari 7 risiko yang kami uraikan yang bertanggung jawab untuk ini? Atau ada alasan lain?

All Articles