Dalam dunia teknologi TI modern, ketika banyak aplikasi dari Google Play dan Appstore setiap hari menginformasikan tentang pembaruan, mendengar dari tim proyek untuk implementasi sistem ERP "proyek akan memakan waktu dari 9 (optimis) hingga 12 bulan (realistis)" cukup umum. Selain itu, ada proyek yang lebih kompleks. Di salah satu perusahaan tempat teman saya bekerja, hanya tahap membuat dan menandatangani desain proses berlangsung 6 bulan. Volume dokumen desain ternyata sangat mengesankan dan, dalam bentuk cetak, bisa menyelamatkan nyawa seorang pejuang dari Cina kuno (mereka mengatakan bahwa mereka menggunakan kertas sebagai bahan untuk baju besi mereka). Masa-masa Cina kuno telah berlalu, tetapi hari ini tumpukan kertas ini terus menyelamatkan, jika tidak hidup, maka setidaknya sistem saraf konsultan pada tahap menempatkan sistem ke dalam operasi. Tetapi apa yang tidak diselamatkan oleh dokumen desain adalah perubahan dalam waktu peluncuran proyek dan masalah dengan kualitas sistem pada saat operasi komersial. Mari kita coba mencari tahu mengapa ini terjadi dan apakah itu mungkin entah bagaimana berbeda.
Bayangkan Anda memesan perbaikan apartemen baru Anda. Sebelum mulai bekerja, tim kontraktor meminta Anda menandatangani dokumen teks, biasanya tanpa ilustrasi, tentang bagaimana apartemen Anda akan diperbaiki, termasuk semua perincian: soket, sakelar, furnitur, dll. Ketua tim memperingatkan bahwa perubahan selama fase penerimaan lebih mungkin terjadi Total akan menyebabkan biaya tambahan. Untuk alasan ini, Anda secara bertanggung jawab mendekati tugas, menghabiskan banyak waktu dan pada akhirnya menandatangani dokumen. Nah, misalkan Anda pergi selama enam bulan dari negara itu. Dan percayalah sepenuhnya pada tim pelaksana untuk melakukan perbaikan sendiri tanpa kontrol dan pemantauan dari pihak Anda. Setelah enam bulan, kembali, pergi ke apartemen dan melihat bahwa apartemen yang sudah selesai tidak sepenuhnya memenuhi harapan Anda. Kemudian Anda meminta tim proyek untuk mengulangi beberapa perincian, misalnya, pindahkan soket lebih dekat ke kulkas. Tim proyek mengatakan bahwa akan sangat mahal untuk memindahkan soket dan mengambil banyak waktu, karena Anda harus melubangi dinding, dan ada ubin, dll. Anda masuk ke kamar tidur, nyalakan AC yang sudah terpasang, dan pahami bahwa itu akan meledak tepat di malam hari pada Anda . Minta tim untuk memindahkannya, tetapi Anda mendapatkan jawaban yang sama dengan soketnya. Namun demikian, ini adalah masalah prinsip bagi Anda dan Anda mengatakan bahwa Anda tidak akan mulai tinggal di apartemen sampai AC di mana Anda membutuhkannya, karena di apartemen Anda saat ini tepat di mana Anda membutuhkannya, dan Anda tidak melihat gunanya bergerak, jika akan memperburuk kenyamanan kehidupan sehari-hari Anda. Akibatnya, Anda menelepon apartemen 3 bulan lebih lambat dari paket semula dengan kelebihan anggaran 20%.
Masalah utama, menurut pendapat saya, adalah kami mencoba untuk melihat dan memperbaiki semua detail pada tahap desain sebelum mulai bekerja. Fase desain tertunda, karena pengguna bisnis jarang dapat sepenuhnya mengabdikan diri pada proyek, mereka harus berurusan dengan proses bisnis sehari-hari mereka. Pada saat desain ditandatangani, mereka telah mengumpulkan tumpukan tugas yang tertunda yang cukup luas dan mereka tidak lagi siap untuk terlibat dalam proyek sampai tahap pengujian. Mereka telah menghabiskan banyak waktu merencanakan semua detail dan ingin melihat sistem yang sudah selesai dan disetel. Namun, hasil akhir tidak memenuhi harapan. Salah satu alasan untuk ini diilustrasikan di bawah ini:
Di perusahaan kami, kami berhasil mengujicobakan pendekatan baru ke proyek-proyek untuk implementasi dan replikasi sistem ERP. Selain itu, pada proyek replikasi, pendekatan ini memungkinkan Anda untuk menyelesaikan proyek lebih cepat daripada rencana biasanya dengan fase desain, pengembangan, dan pengujian berturut-turut (alias Waterfall).
Kami pindah dari ini:
Untuk ini:
Kami menyebut pendekatan ini campuran (Air Terjun - Agile) karena kami menggunakan elemen Agile (pekerjaan sprint) dan Air Terjun (operasi komersial dimulai hanya setelah selesainya seluruh proyek). Akselerasi ini disebabkan oleh fakta bahwa, pertama, kami bekerja dengan pengguna bisnis secara paralel (bekerja pada desain sprint masa depan dan kustomisasi, pengembangan yang saat ini), dan kedua, kami "memindahkan soket" lebih dekat ke kulkas masa depan sebelum ubin diletakkan dan kitchen set dirakit. Semakin besar volume proyek, semakin besar waktu dan perolehan kualitas dibandingkan dengan pendekatan Waterfall klasik.
Contoh proyek di Mars menggunakan pendekatan campuran
Karakteristik utama dari proyek:
- 5½ periode (22 minggu) dari Mulai hingga Peluncuran
- Tim proyek penuh - 40 orang (pengguna bisnis dan konsultan IT, pengembang)
- 4 tim fungsional dalam tim proyek - Keuangan, Pembelian, Logistik dan Penjualan, Departemen Kontrol Kualitas
- 4 siklus pengujian bisnis dengan 93% dari skrip yang berhasil pada percobaan pertama. 5 lokakarya penuh waktu
Pada tahap pra-proyek, kami memperkirakan bahwa kami akan melakukan proyek dalam 30 minggu. Bahkan, menggunakan pendekatan Agile, kami melakukan segalanya dalam 22 minggu. Selama 4 bulan beroperasi setelah diluncurkan, kami menerima 1 permintaan perubahan dari bisnis.
Faktor Sukses Utama
Tim TI internal. Secepat mungkin, mengatur dengan tim TI utama yang akan terlibat dalam implementasi. Mintalah dukungan manajemen untuk terlibat dalam dialog dengan kontraktor eksternal.
Kontraktor eksternal. Tim proyek dari kontraktor harus mencakup para profesional yang sangat memahami sistem itu sendiri dan prinsip-prinsip implementasi Agile. Pemula seharusnya tidak. Lakukan wawancara selektif dengan tim sebelum menandatangani kontrak.
Tim bisnis harus memiliki kesempatan dan keinginan untuk secara teratur terlibat dalam proyek selama semua fase pengembangan. Ini tidak berarti bahwa bisnis harus bekerja lebih banyak. Kami mendistribusikan ulang waktu mereka dari tahap desain dan pengujian yang biasa ke setiap segmen pengembangan.
Beberapa pertanyaan yang sering diajukan
Pertanyaan 1: Departemen komersial meminta untuk menandatangani kontrak dengan kontraktor bernilai tetap sebelum memulai pengembangan. Tetapi bagaimana cara mengevaluasi biaya jika tidak ada desain yang lengkap dan ditandatangani?
Jawaban 1: Kami menandatangani kontrak Tim Tetap dengan kontraktor - kami memperbaiki tim dan waktu pelaksanaan proyek, misalnya, 8 bulan. Ini tidak sama dengan Time-Material, seperti kami mencatat durasi dan jumlah total pekerjaan. Pada saat yang sama, kami tetap fleksibel dalam mengubah / menambah persyaratan bisnis jika durasi proyek dan tim tidak bertambah.
Pertanyaan 2: Bagaimana jika pengguna bisnis terus-menerus menambahkan persyaratan baru selama peninjauan dan perencanaan setiap sprint?
Jawaban 2: Dalam hal ini, kami meminta Anda untuk memprioritaskan persyaratan dan menghapus yang memiliki prioritas terendah dan tidak sesuai dengan tenggat waktu proyek. Yaitu tambahkan yang baru, bukan sesuatu yang sudah ada. Semua perubahan / persyaratan baru ini akan menunggu kami dalam hal apa pun pada tahap penerimaan, terlepas dari pendekatannya. Tetapi dalam kasus penerimaan perantara pada akhir setiap sprint, kami memiliki lebih banyak peluang untuk mengelola persyaratan ini, sementara ketika menerima segera sebelum peluncuran, kami mengambil risiko waktu peluncuran dan kualitas sistem (kualitas menurut definisi adalah korespondensi hasil akhir dengan harapan pengguna, bukan desain teks).
Jika Anda tertarik pada artikel ini, Anda memiliki pertanyaan, atau Anda hanya ingin berbagi pendapat tentang hal di atas, maka saya akan berterima kasih jika Anda berbagi umpan balik di bawah publikasi atau dalam pesan pribadi. Ilustrasi dan konten ideologis artikel dengan partisipasi Angelina Abdullaeva
angelina .abdullayeva.