Cara melingkupi build AI

Pekerjaan AI punya lebih banyak ketidakpastian bawaan daripada perangkat lunak biasa, jadi ruang lingkup longgar berlipat lebih cepat. Saat 'bangun asisten AI' menjadi ruang lingkupnya, tiap pihak mengisi celah dengan asumsi berbeda, dan celah itu menjadi sengketa begitu tagihan tiba.

Ruang lingkup yang baik tidak menghapus ketidakpastian; ia melokalisasinya. Ia menyatakan persis apa yang dibangun, bagaimana sukses diukur, dan apa yang secara eksplisit di luar batas — agar ketidakpastian yang tersisa kecil dan bernama.

1) Target alur kerja — operasi spesifik yang diubah, bukan kapabilitas. 2) Metrik sukses — definisi 'selesai' yang terukur. 3) Inventaris data — data apa yang ada, di mana, dan dalam keadaan apa. 4) Titik integrasi — sistem persis yang dihubungkan. 5) Batasan — residensi data, latensi, anggaran, hal yang tak bisa ditawar. 6) Jangkar jadwal — tanggal tetap yang menjadi irama kerja.

Masing-masing memetakan ke sesuatu yang konkret: metrik sukses menjadi suite eval; inventaris data menentukan kelayakan; titik integrasi adalah tempat sebagian besar biaya tersembunyi berada.

Buruk: 'Gunakan AI untuk meningkatkan dukungan pelanggan.' Baik: 'Draf balasan pertama untuk tiket penagihan, dinilai terhadap golden set 200 tiket, terintegrasi dengan help desk kami, tanpa data pelanggan keluar cloud kami, tayang dalam delapan minggu.' Yang kedua dapat dibangun dan dihargai; yang pertama undangan untuk menagih per jam.

Uji untuk tiap baris ruang lingkup: apakah dua vendor akan menghargainya sama. Jika tidak, barisnya terlalu kabur untuk dikomitmenkan.

Kesalahan pelingkupan yang fatal: mendefinisikan kapabilitas alih-alih alur kerja; membiarkan sukses tak terdefinisi; menemukan data tak terpakai setelah tanda tangan; dan menganggap integrasi sebagai detail. Masing-masing mengubah proyek tetap menjadi terbuka.

Diagnostic ada untuk menghasilkan persis ruang lingkup ini — tetapi Anda bisa mengerjakan sebagian besarnya sendiri dulu, dan tiba di percakapan dengan ketidakpastian sudah dipersempit.

Ruang lingkup bukan formalitas pengadaan yang terjadi sebelum rekayasa sebenarnya; ia adalah tindakan rekayasa pertama, dan masing-masing dari enam komponennya mengalir langsung ke salah satu dari empat prinsip metodologi. Metrik sukses menjadi suite eval — eval sebelum fitur hanya berhasil jika ruang lingkup sudah menamai seperti apa 'berfungsi' dalam angka. Inventaris data dan titik integrasi menentukan di mana telemetri harus diinstrumentasi, karena Anda tak bisa merekam mutu pada jalur yang tak pernah dilacak ruang lingkup. Batasan — residensi data, latensi, anggaran — menentukan bentuk infrastruktur yang dimiliki, sebab merekalah yang menetapkan cloud mana, akun model mana, dan penyimpanan mana yang harus dijalankan sistem.

Jangkar jadwal adalah yang membuat pod ramping pada jam tetap sama sekali memungkinkan. Pod dua hingga tiga orang yang bekerja pada jam delapan minggu hanya bisa berkomitmen pada sebuah tanggal jika ruang lingkup telah membatasi apa yang dikomitmenkannya. Dibaca sebaliknya, ini uji yang berguna untuk ruang lingkup Anda sendiri: ambil tiap baris dan tanyakan prinsip mana yang dilayaninya. Jika sebuah baris tak memetakan ke satu pun darinya — jika ia tak mendefinisikan selesai, tak menamai di mana mengukur, tak membentuk apa yang Anda miliki, dan tak mengatur irama jam — ia mungkin sekadar hiasan, dan hiasan dalam ruang lingkup adalah tempat biaya menumpuk diam-diam.

Inilah juga mengapa metodologi vendor dan ruang lingkup Anda tak bisa dinilai terpisah. Ruang lingkup yang ditulis untuk vendor tanpa disiplin eval tetap akan menyimpang, karena tak ada apa pun di hilir untuk meminta pertanggungjawaban metrik sukses. Ruang lingkup terkuat di dunia tak bisa menyelamatkan model pengiriman yang untung dari pekerjaan yang terus berlanjut — dan pod paling ramping dan paling disiplin tak bisa menyelamatkan ruang lingkup yang tak pernah menyatakan arti selesai.

Ruang lingkup diuji dalam percakapan yang mengikutinya, dan pertanyaan yang diajukan balik oleh vendor mengatakan lebih banyak daripada proposal yang mereka kirim. Hal pertama yang harus disusupi adalah metrik sukses: tanyakan bagaimana mereka berniat mengubah definisi selesai Anda menjadi sesuatu yang otomatis dan dapat diulang. Vendor serius akan bicara tentang golden dataset, rubrik penilaian, dan ambang batas; yang lebih lemah akan meyakinkan Anda bahwa mereka 'akan tahu begitu melihatnya', yang justru keterbukaan tanpa batas yang ruang lingkup baik ada untuk mencegahnya. Tanyakan pula apa yang akan mereka tolak untuk dihargai sampai mereka melihat data Anda — vendor yang menghargai ruang lingkup apa pun tanpa melihat entah melebihkan banyak atau berencana menagih selisihnya nanti.

Rangkaian pertanyaan kedua adalah tentang variansi dan apa yang terjadi saat build ternyata lebih sulit dari perkiraan. Tanyakan langsung: di bawah model Anda, apakah Anda untung lebih banyak dengan menyelesaikan atau dengan melanjutkan? Tanyakan apa yang dihasilkan langkah pelingkupan, apakah harga dipatok terhadapnya, dan terhadap apa garansi diukur. Jawaban jujur di sini spesifik — harga tetap yang dihargai hanya setelah Diagnostic, garansi yang diukur terhadap ambang eval yang disepakati, pernyataan jelas tentang apa yang di luar ruang lingkup. Kekaburan dalam jawaban adalah ramalan kekaburan dalam tagihan.

Terakhir, tanyakan apa yang akan Anda pegang saat keterlibatan berakhir. Di mana kode akan tinggal, akun cloud siapa yang menjalankannya, siapa yang memiliki kunci model dan penyimpanan telemetri. Jawabannya memisahkan pembangun dari tuan tanah — dan perbedaannya paling penting justru saat hubungan berjalan baik, karena saat itulah pembeli paling enggan memeriksa. Lingkupi pintu keluar sebelum Anda melingkupi build; jauh lebih murah menegosiasikan kepemilikan saat masuk daripada menemukan ketiadaannya saat keluar.

Enam komponen itu tidak sama mendesaknya, dan mencoba menyempurnakan semuanya secara paralel itu sendiri kesalahan pelingkupan. Ada urutan yang mengurangi risiko pekerjaan paling cepat. Tetapkan inventaris data lebih dulu, karena ia komponen yang paling mungkin keliru dengan cara yang menggugurkan segala sesuatu di hilir — target alur kerja dan metrik sukses yang dibangun di atas data yang ternyata tak lengkap, tak terakses, atau terbebani secara hukum adalah jawaban canggih untuk pertanyaan yang salah. Pastikan data itu ada, bahwa Anda bisa menggunakannya secara sah, dan bahwa ia representatif terhadap produksi sebelum Anda menanam usaha di tempat lain.

Dengan data terkonfirmasi, tetapkan target alur kerja dan metrik sukses bersama-sama, karena keduanya saling membatasi: metrik hanya bermakna terhadap operasi spesifik, dan operasi hanya layak diubah jika suksesnya bisa diukur. Lalu petakan titik integrasi, di mana biaya tak teranggarkan terbesar biasanya bersembunyi — pekerjaan tak gemerlap menghubungkan ke sistem yang berperilaku sama sekali tak seperti dokumentasinya. Batasan dan jangkar jadwal datang terakhir bukan karena paling tak penting tetapi karena paling mudah dinyatakan begitu substansinya beres; sebuah tanggal dan aturan residensi cepat ditulis dan cepat diverifikasi.

Batas jujur dari mengerjakan ini sendiri adalah pekerjaan data dan integrasi. Anda bisa menulis target alur kerja yang kuat, metrik sukses yang dapat diuji, dan seperangkat batasan yang jelas tanpa vendor di ruangan. Yang biasanya tak bisa Anda tuntaskan sendiri adalah apakah data benar-benar akan mendukung metrik dan apakah integrasinya sebersih tampaknya — dan ketidakpastian itulah yang justru dirancang untuk dikurangi harganya oleh Diagnostic dua minggu sebelum Build dihargai.

Kesalahpahaman paling membandel adalah bahwa ruang lingkup terperinci memperlambat proyek — bahwa mematok segalanya sebelum build adalah beban birokrasi yang menunda pekerjaan menarik. Yang sebaliknya benar khusus untuk AI, karena ketidakpastian yang dibiarkan tak terselesaikan oleh ruang lingkup longgar tak hilang; ia hanya ditunda ke saat ketika jauh lebih mahal untuk dihadapi. Metrik sukses yang dibiarkan kabur saat tanda tangan menjadi sengketa saat pengiriman. Integrasi yang diasumsikan saat pelingkupan menjadi dua pekan pekerjaan tak terencana saat build. Perincian bukanlah biayanya; ia hal yang mencegah biaya itu.

Kesalahpahaman kedua adalah bahwa ruang lingkup lebih panjang adalah ruang lingkup lebih baik. Panjang bukanlah sinyalnya — keterujian-lah sinyalnya. Satu halaman baris yang dapat dibangun dan dihargai mengalahkan sepuluh halaman aspirasi, dan menjejali ruang lingkup dengan kapabilitas yang tak dibutuhkan proyek adalah cara andal untuk menggelembungkan baik penawaran maupun permukaan risiko. Disiplinnya bersifat mengurangi: ruang lingkup yang baik sama-sama merupakan catatan apa yang secara eksplisit di luar batas dan apa yang di dalam. Menamai pengecualian secara jelas adalah yang menjaga jam delapan minggu tetap jujur.

Kesalahpahaman ketiga adalah bahwa ruang lingkup tetap begitu ditandatangani. Dalam praktik ruang lingkup adalah batasan hidup yang dijaga jujur oleh telemetri dan eval — metrik sukses yang disepakati di awal adalah tolok ukur yang nanti dipakai untuk mengukur data produksi, dan regresi di bawahnya adalah perkara garansi alih-alih negosiasi ulang. Yang tak boleh bergeser adalah definisi selesai; yang bisa dipelajari adalah bagaimana realitas dibandingkan dengannya. Memperlakukan ruang lingkup sebagai dokumen sekali jadi alih-alih komitmen terukur adalah cara keterlibatan yang mulai baik tetap menyimpang di paruh keduanya.