Halo semuanya, jumpa lagi bersama saya Supar Dianto pada mata kuliah Analisis dan Spesifikasi Kebutuhan Perangkat Luna. Di pertemuan kita kali ini kita akan membahas mengenai Vision and Scope. Seperti biasa, capai pembelajaran yang bisa teman-teman dapatkan pada pertemuan kita kali ini adalah Teman-teman diharapkan dapat menjelaskan mengenai apa itu vision, apa itu scope. Lalu outline yang akan kita bahas pada pertemuan kita kali ini adalah mengenai introduksinya dulu, lalu kemudian mendivine arti dari product vision and scope, lalu conflicting business requirement, lalu kemudian vision and scope document.
Lalu, and keeping the scope in focus. Oke, pada pertemuan kita sebelumnya, kita sudah membahas mengenai peran dari seorang bisnis analis. Lalu, tipe-tipe dari requirement. Nah, sekarang kita coba melihat dari sisi...
tujuan visi, serta scope dari suatu produk atau aplikasi tersebut. Nah ini ada suatu hal nih, ada analogi atau penggambaran dulu di slide awal kita. Yang pertama adalah, dia mengatakan bahwa kami menginterview banyak dari pengguna dan kemudian menyusun segala hal fitur berdasarkan...
saran dari mereka. Lalu, saat kita menyadari, saat kita mulai membuat dalam bentuk analisis dan desain, kita menyadari bahwa user yang kami telah wawancarai tadi, banyak user tadi, itu ternyata tidak paham dengan masalah yang terdapat pada tujuan dari pengembangan aplikasi ini. Maka kemudian, dia hanya memberikan saran-saran yang sebenarnya tidak cocok dengan pengembangan aplikasi atau produk ini.
Nah, maka daripada itu, sehingga si analisnya lebih cenderung untuk kemudian bicara dari sisi outside untuk mencari tahu benar-benar apa yang memang dibutuhkan dari produk ini ke depannya. Nah, makanya... Ada istilah atau kiasan di bawahnya adalah A project without a clearly defined vision and scope We build in unfocused and undirectioned project Jadi suatu project yang benar-benar tanpa Tanpa hal yang jelas mengenai visi dan batasan-batasan Yang harus terdapat dalam project ini Benar-benar akan menyebabkan project ini berjalan menjadi tidak fokus Dan tidak bisa ditentukan arahnya Jadi maka benar-benar Kaitan antara vision and scope ini penting dalam menyukseskan proses dari pengembangan aplikasi ini. Suatu proyek yang memiliki kekurangan atau tidak jelas dalam hal tidak mampu mendefinisikan mengenai apa saja yang dia butuhkan, mengenai apa saja ke depannya proyek ini bagaimana, produk ini bagaimana.
ini tentu akan mengundang suatu bencana. Bencana yang paling besar adalah aplikasinya menjadi tidak sesuai dengan goal dan needs-nya yang sudah dibawakan atau dilakukan requirement-nya tadi. Suatu tanda bisnis requirement tidak mampu memenuhi, tidak mampu mencari tahu fitur-fitur apa yang dibutuhkan adalah adalah diawali dengan penambahan fitur yang tidak konsisten.
Artinya ketika dia ditambahkan, lalu kemudian dia dihilangkan. Akhirnya ternyata disadari kalau dia ternyata butuh lagi fitur itu. Artinya bongkar pasang terus.
Nah, bongkar pasang seperti inilah yang kemudian terjadi akibat kurangnya komunikasi yang akan menjadi arah pada saat. aplikasi atau produk itu dibuat. Maka kita perlu menjadari bahwa vision and scope itu harus kemudian dibuat, harus ada sebelum fitur itu kemudian didefinisikan satu per satu.
Jadi sebelum si developer itu nanti buat fitur, dia harus bisa melihat kepada vision and scope-nya. Apa visi dari produk ini dan apa batasan-batasan dari produk ini ke depannya. Lalu kita men-define product vision and scope.
Nah, kita men-define suatu product vision itu kita harus sesuaikan dengan arahan atau arah yang diberikan oleh stakeholder. Jika stakeholder ingin maju, maka kita harus membuat visi dari produk ini adalah ingin memajukan si usaha atau customer atau klien kita. Dan ini diaplikasikan hampir di keseluruhan dari produk yang kita buat.
Dan ini tentu saja tidak boleh berubah dalam waktu yang cukup lama. Jadi harus konsisten. Lalu bagaimana dengan product scope?
Kalau product scope, ini kita harus bisa menentukan porsi dari project yang saat ini akan kita kerjakan. Kita harus bisa menentukan secara spesifik tahapan-tahapan apa saja yang dilakukan pada tahapan atau contohnya. prioritas saat ini. Fitur-fitur apa yang memang harus dan sangat segera untuk kemudian dibuat, diluncurkan, dan mana yang kemudian bisa menyusul di belakang. Agar kita kemudian tidak kehilangan momentum, tidak kehilangan waktu dalam mendeliver produk yang dibutuhkan oleh si customer tadi.
Makanya pada product vision kita juga nanti akan merilis namanya project scope versi 1, ada project scope versi 1 versi 1, lalu ada project scope versi yang tergantung rilisnya keberapa. Mungkin di 1.0 baru 3 fitur, 1.1 4 fitur, nambah 1 fitur lagi, dan seterusnya. Tetapi ini dilasarkan pada kebutuhan bahwa memang fitur itu memang harus segera diusahakan atau segera diusahakan. Buat seperti itu ya.
Atau kita mengenalnya dalam bentuk versioning. Makanya aplikasi kan kalau teman-teman download ada update versionnya. Pada versi sebelumnya belum ada fitur C. Tapi di versi 1.2 sudah ada fitur C.
Nah tapi berarti ini mengartikan bahwa 1 dan 2 dulu yang harus dinaikkan pada perusahaan pengembangan itu. Lalu kemudian dilanjutkan dengan fitur C dan D dan seterusnya. Lalu ini adalah berkaitan dengan scope. Apa kita harus menentukan scope? Memang berdasarkan adanya pengaturan dari segi sistem, dari segi cakupan area kerjaan, datanya.
Nah ini yang kemudian harus kita pikirkan. Seberapa besar produk atau aplikasi yang harus kita buat. Bagaimana cara menghitungnya? Kita bisa menghitung berdasarkan jumlah dari aliran datanya, dari konteks modelnya, kita bisa menghitung dari biaya per alurnya tadi, kita bisa menghitung dari jumlah stakeholders yang akan menggunakan nantinya, atau kita juga bisa menghitung berdasarkan function point-nya.
Setiap fungsi kita tentukan point-nya ada berapa, lalu point mana yang besar mungkin bisa kita buat dulu atau lakukan dulu. Poin yang kecil kita bisa lakukan nanti. Nah ini sama seperti yang saya ceritakan di slide sebelumnya. Lalu ada sebuah pertanyaan nih. Which of the following would constitute a chain in division?
Apakah A, apakah B, apakah C, ataukah D? Kira-kira mana yang jawabannya? Kalau kita lihat dari pilihan-pilihan jawaban ini, mana yang masih tentu atau mulai tidak konsisten dengan...
vision adalah pasti jawabannya yang D. Kenapa? Karena klien memutuskan bahwa produk ini tidak lagi adalah mobile game.
Tapi malah mengalihkan produk ini menjadi suatu project management. Tentu akan berbeda antara game sama suatu aplikasi management. Nah ini tentu akan mempengaruhi visi dan skopnya tadi.
Nah kalau visinya sudah berubah seperti ini, tentu akan mempengaruhi development aplikasi ke depannya. Lalu berkaitan dengan conflicting Business requirement. Ya tentu ada beberapa hal yang menyebabkan konflik pada business requirement.
Business requirement collected from multiple source might conflict. Jadi karena kita di pertemuan sebelumnya kita sudah tahu bahwa business requirement itu bisa didapatkan dari banyaknya dokumen. Nah tentu beberapa dokumen ini memiliki beberapa hal yang saling bertabrakan. Begitu ya mungkin. ketidaksesuaian atau hal-hal yang berhubungan dengan visi dari si produk atau si customer-nya.
Maka kita lalu bisa melakukan validasi kepada project sponsor-nya. Bagaimana Pak dengan fitur A? Kayaknya fitur A bertabrakan dengan business process ini.
Atau bagaimana menyesuaikan antara bisnis A, proses A dengan fitur A. Nah, itu kita harus komunikasikan dengan penyeksponsor, atau bahkan juga dengan bisnis stakeholder, dan seterusnya. Kemudian kita melihat adanya vision and scope document. Di pertemuan kita sebelumnya, kita recall bahwa Setelah kita menentukan business requirement, issue requirement, kita lalu menentukan vision and scope document. Kita meng-collect semua business requirement menjadi suatu dokumen yang kemudian nanti akan menjadi landasan pada pengembangan suatu product-nya.
Dan kemudian biasanya vision and scope document ini akan menjadi pegangan juga bagi si project. sponsornya, untuk kemudian bisa memonitoring bahwa pengembangan aplikasi ini harus sesuai dengan vision and scope-nya. Dimana nanti project sponsor tentu akan bekerjasama dengan analis atau development team dalam menentukan atau membuat dokumen ini.
Ini adalah template dari vision and scope dokumen. Ada empat hal, ada empat bab, ada yang pertama business requirement, Kita menentukan background-nya, business opportunity-nya, objektifnya, customer market needs-nya, bahkan business needs-nya. Berikutnya kita membahas mengenai vision of the solution-nya. Visi ke depan dari solusi yang dicoba menjadi roh dari produk atau aplikasi ini.
Ada vision statement, major feature, asumsi, and dependency. Lalu kita melihat adanya scope and limitation. Kita bisa menentukan skopnya, kira-kira seberapa besar, dibagi dalam beberapa versi, versi apa, fiturnya apa saja, versi berikutnya fiturnya apa saja. Lalu kemudian bab berikutnya kita membahas mengenai bisnis konteksnya.
Berkait dengan siapa saja stakeholdersnya, kemudian priority-nya, environment-nya, dan seterusnya. Dan keseluruhan inilah yang kemudian ketika dia disusun jadi satu, maka dia disebut sebagai Vision and Scope Document. Oke, di dalam proyek scope management, ada beberapa hal yang harus kita lakukan.
Ada collect requirement, ada melakukan mendefinisikan scope-nya, membuat perencanaan dengan melakukan WBS, Work Breakdown Structure, memverifikasi scope yang sudah dibuat tadi, lalu bagaimana supaya kita bisa mengontrol agar pengembangan aplikasinya bisa sesuai dengan scope. seperti itu, jadi ini memang adalah langkah-langkah yang kita bisa lakukan dalam melakukan mengelola scope pada suatu project, lalu bagaimana supaya kita bisa menjaga scope tetap fokus tetap in line dan tetap bisa sejalan dengan pengembangan si produknya nah ini adalah tips yang bisa kita lakukan ketika ada seseorang entah itu user, stakeholder, yang ingin meminta suatu fitur baru, suatu requirement baru, maka kita ketika berposisi sebagai analis, kita harus bertanya, apakah fitur atau requirement ini memang sudah sejalan dengan skopnya Pak, Bu? Kita harus melihat bahwa jika dia memang adalah bagian dari, jika dia memang menarik, ya, itu menarik, tetapi dengan jelas bahwa dia luar dari skop maka kita harus menambahkan untuk nantinya aja ditambahkan di pengembangan berikutnya atau di version berikutnya.
Tapi jika requirement tersebut memang seharusnya adalah bagian dari scope kita, namun terlupa, maka kita bisa masukkan dia ke dalam requirement. Kita bisa tentukan prioritasnya. Nah, tetapi jika dia memang benar-benar di luar dari scope, tapi namun sangat menjanjikan ketika dia nanti diimplementasikan, maka kita kemudian bisa lakukan modifikasi dan coba mengakomodasi perubahan tersebut. Jadi kita harus bisa melihat seberapa besar pengaruhnya requirement baru ini sesuai dengan scope yang sudah kita sepakati di awal.
Kalau ternyata sesuai, kenapa tidak untuk kemudian ditambahkan. Tapi kenapa kalau kemudian tidak sesuai, namun ternyata bisa menjanjikan, ya oke, kita tambahkan saja di versi berikut. kayak begitu.
Kemudian apa yang bisa kita lakukan untuk mencegah kesalahan atau mencegah problem yang berhubungan dengan scope? Maka kita harus bisa memang memastikan bahwa kebutuhan dari klien tadi sudah kita tentukan prioritasnya. Kita bisa harus menentukan ekspektasinya secara jelas apa yang ingin dicapai dan apa yang ingin dibuat dan apa ingin yang...
menjadi output dari produk atau aplikasi ini. Lalu coba kita selalu menanyakan ketika terjadi perubahan, apakah ini memang sesuai skop atau tidak. Dan kemudian berkaitan dengan penjadwalan dari proyeknya, kita bisa tentukan apakah bisa di-extend atau tidak. Dan kita harus bisa, jika terjadinya penambahan requirement, maka kita bisa mencoba. kita tentu harus juga menaikkan dari biaya dari penggambaran si proyek tersebut.
Agar bisa inline lah. Nah ini adalah contoh penggambarannya, gimana jika berhubungan dengan goals, goals itu harus dibicarakan dengan stakeholders, stakeholders itu juga dengan goals tersebut, skopnya seperti apa. Jika memang dia inline, jika dia memang inline dan dia ditentukan as awarded, tentu harus dipahami bahwa harus ada biaya yang cukup untuk melakukannya.
Kemudian kita juga bisa melihat terhadap constraint, constraint-constraint yang ada, batasan-batasan yang ada, apakah memang sudah sesuai atau tidak, supaya mungkin skop tersebut masih bisa dimasukkan. Oke, sampai situ dulu pertemuan kita kali ini. Maka kesimpulan yang bisa kita dapatkan adalah Membuat suatu vision and scope menjadi sangat jelas, maka ini tentu bisa membuat kita menjadi lebih mudah dalam mengambil keputusan ke depannya terhadap adanya pertambahan requirement atau perubahan requirement. Perbedaannya antara vision and scope adalah vision itu sebagai pemandu bahwa produk ini nantinya akan menentukan kepuasan dari pengguna dan scope.
memastikan bahwa produk ini sesuai dengan apa yang ingin memang akan dicapai di akhirnya. Jika terjadi konflik, maka kita bisa meminta proyek sponsor ataupun juga bisnis stakeholder untuk bersama-sama dalam menyelesaikan konflik feature yang mungkin akan terjadi. Selalu tanyakan apakah ini diskub ketika terjadinya penambahan requirement atau perubahan requirement.
Agar kita bisa menjaga... Skop dari pengembangan aplikasi kita bisa inline dengan apa yang sudah disepakati di awal. Oke, itu saja yang bisa dapat saya sampaikan pada pertemuan kita kali ini. Kita jumpa lagi di pertemuan kita berikutnya.
Sampai jumpa.