Menetapkan Skop Versi Pertama Aplikasi dalam Empat Minggu: Elak Binaan Pertama yang Terlalu Besar

Kebanyakan binaan tersuai pertama tidak gagal kerana pembina tidak mampu membina. Ia gagal kerana versi pertama senyap-senyap menjadi versi akhir: setiap idea yang pernah terlintas, setiap laporan yang mungkin diminta akauntan, setiap peranan, setiap integrasi dan setiap skrin yang dikemas, semuanya dijanjikan untuk hari pelancaran. Hasilnya projek yang panjang, sebut harga yang besar dan pelancaran yang terus tertunda sementara mereka yang memerlukan alat mudah terus menunggu.

Panduan ini untuk pemilik bukan teknikal yang menempah aplikasi atau sistem perniagaan pertama dan mahukan versi pertama yang kecil dan boleh dilancarkan. Ia menunjukkan cara mengecilkan idea kepada sesuatu yang boleh beroperasi dan digunakan, melalui langkah mudah yang boleh anda lakukan di atas kertas sebelum bercakap dengan mana-mana pembina. Ia menggunakan kotak masa empat minggu sebagai contoh latihan perancangan, bukan janji daripada mana-mana pembekal. Ini panduan umum; tempoh projek sebenar bergantung pada saiznya, dan satu-satunya angka yang boleh dipercayai ialah yang tertera dalam sebut harga bertulis. Untuk faktor yang menentukan tempoh, lihat berapa lama sistem perniagaan tersuai mengambil masa.

Mengapa binaan pertama menjadi terlalu besar

Beberapa perkara yang sama berlaku berulang kali, dan bukan salah sesiapa. Mengenalinya membantu anda menyedarinya awal.

• Setiap orang menambah satu perkara. Setiap orang yang ditanya apa yang sistem patut buat menambah ciri kegemarannya. Tiada siapa membuang apa-apa, jadi senarai hanya bertambah.
• Pemikiran "sementara kita di sini". Jika sesuatu skrin sudah ada, menambah satu butang nampak murah. Setiap butang perlu direka, dibina, diuji dan dijelaskan, jadi jarang yang murah.
• Takut tiada pusingan kedua. Pemilik bimbang hanya ada satu peluang, lalu meminta semuanya sekarang. Versi pertama yang kecil tetapi berfungsi ialah cara paling pasti untuk mendapat pusingan kedua.
• Perkataan kabur. "Mudah digunakan", "lengkap" dan "fleksibel" tidak boleh diuji, jadi tidak pernah siap. Tugas konkrit boleh disiapkan.
• Meneka dan bukan memerhati. Ciri yang dipilih sebelum sesiapa menggunakan sistem hanyalah tekaan. Penggunaan sebenar menunjukkan yang mana penting.
• Tambahan tersembunyi. Ciri yang kedengaran kecil, seperti beberapa bahasa, banyak jenis pengguna, sambungan ke perisian lain atau aplikasi mudah alih di samping aplikasi web, masing-masing boleh membawa kerja tersembunyi yang besar.

Langkah satu: tulis masalah dalam satu ayat

Sebelum menyenaraikan ciri, tulis satu ayat dalam bentuk: "[Siapa] menghadapi masalah dengan [apa], yang menyebabkan kami [kerugian apa], dan kami tahu ia selesai apabila [perubahan yang boleh diperhatikan]." Jika anda tidak dapat menyebutnya dalam satu ayat, projek itu sebenarnya masih beberapa projek.

Bandingkan dua versi. "Kami mahu aplikasi untuk menguruskan perniagaan" ialah hasrat; tiada siapa tahu bila ia siap. "Pelanggan asyik menelefon bertanya sama ada baik pulih mereka sudah siap, dan kakitangan membuang masa mencari tiket kertas, dan kami tahu ia selesai apabila kakitangan boleh mencari mana-mana kerja dalam beberapa saat dan memberitahu pelanggan statusnya" ialah masalah yang boleh dibina dan diuji.

Letakkan ayat ini di bahagian atas setiap dokumen dan setiap mesyuarat. Apabila idea baharu tidak membantu menyelesaikannya, idea itu masuk senarai kemudian.

Langkah dua: pemotongan "satu pengguna, satu tugas"

Kebanyakan idea perniagaan melibatkan beberapa jenis orang: pemilik, pengurus, kakitangan, pelanggan, pembekal. Versi pertama yang cuba melayan kesemuanya ialah tempat saiz meletup, kerana setiap jenis orang memerlukan skrin, peraturan dan ujian tersendiri.

Sebaliknya, pilih satu pengguna dan satu tugas:

• Satu pengguna: orang yang paling kerap menyentuh sistem, atau yang paling merasai masalahnya. Jika sistem berfungsi untuknya, anda ada bukti nilai.
• Satu tugas: satu kerja yang pengguna itu mesti dapat siapkan dari awal hingga akhir, seperti menerima kerja baik pulih dan mencarinya semula kemudian.
• Satu garis penamat: hasil yang boleh anda lihat seseorang capai, dengan maklumat sebenar, tanpa bantuan.

Semua yang lain, termasuk gambaran keseluruhan pemilik, paparan pelanggan sendiri dan laporan, sah tetapi datang kemudian. Meninggalkan pengguna lain tidak bermakna melupakan mereka. Ia bermakna meminta pembina mengelak pilihan yang akan menghalang mereka kelak, kemudian membinanya apabila tugas pertama berjaya. Siapa boleh melihat dan mengubah apa ialah topik tersendiri: peranan dan kebenaran pengguna dalam sistem perniagaan tersuai.

Langkah tiga: asingkan idea kepada mesti, patut dan kemudian

Sekarang tulis setiap idea, daripada semua orang, tanpa menilai. Kemudian asingkan satu persatu. Ini versi bahasa mudah bagi kaedah pengurusan projek yang biasa dikenali sebagai MoSCoW (must, should, could, won't). Empat kumpulan lebih daripada keperluan versi pertama, jadi di sini ada tiga.

Bersikap tegas dengan kumpulan mesti. Sumber mengenai kaedah ini menyatakan bahawa "mesti" dan "kemudian" mudah dipersetujui, manakala "patut" ialah tempat orang berbalah. Jika senarai mesti anda melebihi beberapa item sahaja untuk satu pengguna dan satu tugas, tanya soalan yang lebih sukar sekali lagi: bolehkah mereka menyiapkan tugas itu tanpa ini? Jika ya, ia patut.

Minta juga pembina menandakan item yang nampak kecil tetapi tidak, seperti sambungan ke sistem lain atau bahasa kedua. Kejutan paling murah apabila ia muncul sebelum sebut harga diterima.

Contoh kerja (rekaan): aplikasi penjejakan kerja sebuah kedai baik pulih

Contoh ini direka untuk menunjukkan kaedah. Ia bukan pelanggan sebenar, projek sebenar atau harga sebenar. Bayangkan sebuah kedai baik pulih kecil dengan satu kaunter dan dua juruteknik yang membaiki telefon dan peralatan kecil. Kerja ditulis pada tiket kertas dan pelanggan bertanya perkembangan melalui telefon dan WhatsApp.

• Ayat masalah: pelanggan asyik bertanya sama ada baik pulih mereka siap, dan kakitangan membuang masa mencari tiket; ia selesai apabila mana-mana kerja boleh dicari dan statusnya dimaklumkan dalam beberapa saat.
• Satu pengguna: kakitangan kaunter.
• Satu tugas: menerima kerja baik pulih dan, kemudian, mencarinya dan memberitahu pelanggan di mana kedudukannya.

Versi pertama ialah lima item mesti. Ia tidak mengagumkan, dan itulah maksudnya: ia boleh diuji pada kaunter sebenar dalam beberapa hari selepas dibina, dan kedai itu akan tahu item kemudian yang mana benar-benar dirindui.

Contoh kotak masa empat minggu

Ini contoh latihan perancangan, bukan janji Gotka dan bukan tempoh lazim. Kotak masa bermaksud anda menetapkan masa dahulu kemudian mengecilkan skop supaya muat, dan bukan menetapkan skop lalu berharap masa mengikut. Anda boleh meminta mana-mana pembina menilai senarai mesti anda terhadap kotak masa seperti ini, kemudian bandingkan jawapannya dengan sebut harga bertulis. Jika pembina berkata item mesti anda memerlukan masa lebih lama, tanya item mana yang menyebabkannya, dan kurangkan senarai sebelum anda menekan jadual.

Perhatikan apa yang dilindungi contoh ini. Minggu ujian tidak dihimpit apabila pembinaan lewat; sebaliknya, senarai mesti dikecilkan. Jawapan anda sendiri juga penting: keputusan yang lambat pada minggu kedua meregangkan mana-mana jadual. Untuk cara menjalankan minggu ketiga dengan betul, lihat cara menyemak dan menguji sistem perniagaan tersuai sebelum anda menerimanya.

Apa yang ditangguhkan, dan mengapa

Empat kumpulan ciri paling kerap diminta pada hari pertama dan paling kerap lebih baik datang kemudian.

• Laporan dan papan pemuka. Laporan memerlukan data sebenar untuk berguna, dan anda belum tahu angka mana yang anda mahu. Eksport senarai ke hamparan pada mulanya. Apabila soalan menjadi jelas, lihat papan pemuka dan pelaporan perniagaan.
• Sambungan ke sistem lain. Setiap sambungan ke perakaunan, e-dagang, pemesejan atau e-invois menambah kerja di kedua-dua pihak dan perkara baharu yang boleh rosak. Kekalkan langkah manual dahulu dan automasikan apabila proses sudah stabil.
• Peranan dan kelulusan tambahan. Mulakan dengan pemilik dan satu jenis kakitangan. Tambah pengurus, had cawangan dan langkah kelulusan apabila penggunaan sebenar menunjukkan ia perlu. Jika perniagaan anda sudah memerlukan pengasingan ketat, nyatakan dalam taklimat.
• Kemasan. Warna tersuai, animasi, orientasi yang menarik dan bahasa tambahan menjadikan sistem selesa, tetapi tidak membuktikan ia berfungsi. Sasarkan jelas dan kemas buat masa ini. Kemaskan apa yang dikeluhkan pengguna sebenar kemudian.

Dua keputusan wajar difikirkan sebelum dipotong: sama ada ia aplikasi web atau aplikasi mudah alih (lihat aplikasi web lawan aplikasi mudah alih) dan sama ada ia mesti berfungsi tanpa internet (lihat penggunaan luar talian). Kedua-duanya mengubah saiz binaan, jadi putuskan pada minggu pertama, bukan minggu ketiga. Asas keselamatan juga bukan kemasan; lihat asas keselamatan sistem perniagaan tersuai dan kekalkannya dalam senarai mesti jika berkaitan.

Cara menolak penambahan skop

Penambahan skop (scope creep) ialah penambahan perlahan permintaan "kecil" selepas skop dipersetujui. Ia jarang datang sebagai tuntutan. Ia datang sebagai "boleh tak kita sekadar..." dalam mesej sembang. Menolak lebih mudah apabila anda ada ayat sedia dan tempat untuk meletakkan idea itu.

• "Ya, dan ia masuk senarai kemudian." Idea dihormati, tidak hilang, dan tidak dibina sekarang.
• "Apa yang kita keluarkan untuk memuatkannya?" Jika sesuatu yang baharu masuk, sesuatu yang sama besar keluar, atau tarikh berubah. Katakan ini kepada diri sendiri juga, bukan hanya kepada pasukan.
• "Masalah apa yang diselesaikannya untuk satu pengguna kita?" Lihat semula ayat masalah. Jika jawapannya tidak jelas, ia menunggu.
• "Bolehkah kita buat secara manual selama sebulan?" Cara sementara manual tidak berkos dan menunjukkan sama ada ciri itu benar-benar perlu.
• "Kita lihat selepas pelancaran." Penggunaan sebenar memberi jawapan lebih baik daripada tekaan dalam bilik mesyuarat.

Minta seorang, biasanya anda, memiliki skop. Jika lima orang boleh meluluskan tambahan dalam sembang, tiada siapa mengawal.

Tabiat permintaan perubahan

Bukan semua perubahan buruk. Pembelajaran sebenar semasa pembinaan ialah sebab yang baik untuk mengubah pelan. Tabiatnya ialah mengubah dengan sengaja dan di atas kertas. Permintaan perubahan ialah nota bertulis pendek, dan boleh muat setengah halaman:

• Apa: perubahan itu, dalam satu atau dua ayat.
• Siapa meminta dan mengapa: masalah yang diselesaikannya untuk satu pengguna.
• Apa berlaku jika tidak dibuat: kos jujur menunggu.
• Kesan pada harga dan tarikh: diisi oleh pembina sebelum apa-apa bermula.
• Keputusan dan tarikh: diluluskan, ditukar dengan item lain, atau dialihkan ke kemudian, dengan nama orang yang memutuskan.

Adakan semakan mingguan ringkas bagi permintaan yang terbuka dan bukan bertindak balas kepada setiap satu. Simpan senarai kemudian di tempat yang sama supaya jawapan kepada "ke mana idea saya pergi?" sentiasa kelihatan. Cara perubahan dikendalikan selepas pelancaran dibincangkan dalam pepijat lawan perubahan selepas pelancaran, dan cara model harga berbeza melayan perubahan ada dalam harga tetap lawan kadar sejam.

Tulis kriteria penerimaan sebelum pembinaan

Kriteria penerimaan menukar "siap" kepada kenyataan yang boleh diuji sesiapa. Tulis satu atau lebih untuk setiap item mesti, dalam bahasa mudah, dengan tugas sebenar dan tanpa kata sifat. Bagi contoh kedai baik pulih:

• Kakitangan kaunter boleh mencipta kerja dengan nama, telefon, barang dan kerosakan, dan sistem memberikan nombor kerja.
• Kakitangan boleh mencari semula kerja itu melalui nombor telefon atau nombor kerja.
• Juruteknik boleh menukar status daripada diterima kepada dalam pembaikan kepada siap, dan kaunter melihat status baharu.
• Setiap tiga kakitangan log masuk dengan akaun sendiri, dan kerja menunjukkan siapa terakhir mengubah statusnya.
• Selepas menutup dan membuka semula sistem, semua kerja yang dimasukkan tadi masih ada.

Elakkan kriteria seperti "pantas", "mudah" atau "mesra pengguna" melainkan anda lampirkan tugas dan orang: "kakitangan baharu mencipta kerja tanpa bantuan selepas penerangan lima minit" boleh diuji; "mudah digunakan" tidak. Terima versi pertama apabila item mesti lulus, bukan apabila setiap hasrat dihantar. Seluruh rutin ada dalam panduan ujian penerimaan.

Soalan untuk ditanya kepada pembina anda

Bawa senarai ini ke mesyuarat pertama. Pembina yang baik mengalu-alukannya; jawapan mengelak juga maklumat yang berguna.

• Bolehkah anda menilai senarai mesti saya terhadap kotak masa yang saya pilih, dan beritahu apa yang tidak muat?
• Item mesti saya yang mana lebih besar daripada rupanya, dan mengapa?
• Apa yang anda tinggalkan untuk versi kedua, dan adakah anda akan mengelak pilihan yang menghalangnya?
• Bagaimana perubahan diminta, dinilai harga dan diluluskan? Bolehkah saya lihat contoh permintaan perubahan?
• Apa yang sebut harga nyatakan sebagai di luar skop?
• Apa yang akan dapat saya lihat dan uji, dan bila, sebelum tarikh akhir?
• Berapa pusingan ujian dan pembaikan disertakan, dan apa yang dikira pembaikan dan bukan perubahan?
• Apa yang anda perlukan daripada saya, dan secepat mana, untuk mengekalkan jadual?
• Apa jadi kepada senarai kemudian: adakah anda menyimpannya, dan bolehkah saya menggunakannya untuk sebut harga kedua?
• Siapa memiliki kod dan data pada akhirnya? Lihat pemilikan kod sumber.

Apabila sebut harga tiba, bandingkan skop dahulu; cara membandingkan sebut harga perisian tersuai menunjukkan caranya, dan apa yang perlu disediakan sebelum perbualan pertama merangkumi maklumat yang perlu dibawa.

Kesilapan lazim

• Menamakan semuanya mesti. Jika semuanya mesti, tiada yang mesti. Gunakan soalan ujian.
• Memilih masa dahulu dan tidak pernah skop. Kotak masa hanya berkesan jika skop mengecil untuk muat.
• Menghimpit ujian. Melangkau ujian pengguna sebenar untuk jimat masa memindahkan masalah ke hari pelancaran.
• Menguji dengan pemilik seorang. Orang yang paling memahami sistem ialah penguji terburuknya.
• Bersetuju dengan perubahan dalam sembang. Tambahan "kecil" secara lisan ialah cara bajet dan tarikh tersasar.
• Tidak pernah menulis senarai kemudian. Idea yang dibuang kembali sebagai rungutan; idea yang ditulis boleh menunggu.
• Menganggap pelancaran sebagai pengakhiran. Versi pertama ialah permulaan pembelajaran; tempah semakan beberapa minggu selepas pelancaran.

Kedudukan Gotka Technologies

Perkhidmatan Pembangunan Aplikasi & Sistem Gotka membina aplikasi mudah alih, aplikasi web dan sistem perniagaan, dengan harga permulaan petunjuk RM8,000 untuk aplikasi web dan papan pemuka, RM12,000 untuk sistem perniagaan dan integrasi serta RM15,000 untuk aplikasi mudah alih, masing-masing disahkan melalui sebut harga bertulis selepas keperluan anda dinilai. Panduan ini nasihat umum dan tidak menerangkan sebarang masa penghantaran Gotka. Pelan empat minggu di atas ialah contoh yang boleh digunakan dengan mana-mana pembina; garis masa sebenar hanya datang daripada sebut harga bertulis. Jika anda mahu berbincang tentang senarai mesti anda, hubungi kami.

Bacaan berkaitan tentang kos dan kesesuaian: apa yang menentukan kos aplikasi mudah alih dan tanda anda memerlukan aplikasi mudah alih.

Istilah utama dalam panduan ini

• Versi pertama: keluaran terkecil yang membolehkan satu pengguna menyiapkan satu tugas sebenar.
• Skop: senarai bertulis apa yang akan dan tidak akan dibina.
• Penambahan skop (scope creep): pertumbuhan perlahan skop melalui tambahan kecil yang tidak direkod.
• Mesti, patut, kemudian: pengasingan idea dalam bahasa mudah, berdasarkan kaedah MoSCoW (must, should, could, won't).
• Kotak masa: tempoh tetap di mana skop dikecilkan untuk muat, dan bukan sebaliknya.
• Permintaan perubahan: cadangan bertulis untuk menambah atau mengubah sesuatu selepas skop dipersetujui, bersama kesannya pada harga dan tarikh.
• Kriteria penerimaan: kenyataan ringkas yang boleh diuji yang menentukan bila setiap item mesti siap.
• Senarai masalah (punch list): senarai masalah yang ditemui semasa ujian, diasingkan kepada baiki sekarang dan boleh tunggu.