Ceritakan masalah sebagaimana terjadi sekarang
Contoh pekerjaan biasa yang baru terjadi lebih berguna daripada spesifikasi sempurna. Jelaskan pemicu, alat yang digunakan, titik tunggu, dan hasil yang baik. Bawa keputusan yang ingin diperjelas: membangun, menyelidiki, atau mengambil alih produk yang ada.
Siapkan contoh aman sebelum pertemuan
Dalam alur layanan pelanggan fiktif, ganti nama, email, dan referensi dengan nilai rekaan. Pertahankan struktur, kondisi gagal, dan langkah manual yang menjelaskan masalah. Periksa tab, notifikasi, dan akun dalam tangkapan layar. Lembar kerja yang disamarkan masih bisa memiliki tab tersembunyi atau komentar; contoh kecil khusus pertemuan sering lebih mudah diperiksa.
Bagikan batasan, bukan kredensial
Kelompok pengguna, perkiraan volume, integrasi, tenggat, dan pemberi persetujuan adalah konteks berguna. Tandai perkiraan. Jangan kirim kata sandi, kunci API, detail kartu, basis data produksi lengkap, atau dokumen rahasia melalui formulir. Jika tinjauan teknis berikutnya memerlukan akses, siapkan proses terpisah yang sah, terbatas, dan bisa dicabut.
Pisahkan fakta yang diamati dari asumsi dalam ringkasan singkat
Catatan persiapan yang berguna dapat cukup satu halaman: keputusan yang diperlukan, orang yang terlibat, urutan kerja saat ini, dan akibat jika dibiarkan tetap sama. Tambahkan satu contoh biasa dan satu pengecualian. Penjelasan yang jelas tentang persetujuan terlambat lebih berguna daripada daftar fitur panjang ketika belum ada yang tahu penyebab keterlambatan itu.
Misalkan tim penjualan fiktif mengirim penawaran dari spreadsheet, sementara manajer menyetujui diskon melalui email. Contoh biasa mengikuti satu penawaran sampai disetujui. Pengecualiannya menunjukkan harga revisi yang dikirim sebelum manajer melihat versi terbaru. Tentukan versi yang disetujui, tempat staf penjualan memeriksa informasi, dan apa yang diterima pelanggan. Jangan menganggap CRM baru pasti jawabannya; masalahnya mungkin aturan revisi yang belum ada atau tanggung jawab yang tidak jelas.
Tandai setiap pernyataan sebagai hasil pengamatan, perkiraan, atau masih perlu diperiksa. Jika seseorang mengatakan revisi sering terjadi, catat siapa yang melaporkan dan sampel apa yang dapat memperjelasnya. Jangan mengubahnya menjadi jumlah bulanan rekaan. Jelaskan hubungan catatan yang dibutuhkan dan saluran komunikasi dengan identitas fiktif. Anda dapat menjelaskan bahwa dua versi berasal dari satu penawaran tanpa membagikan identitas pelanggan asli atau ketentuan komersialnya.
Minta langkah berikutnya yang menyelesaikan ketidakpastian tertentu
Bandingkan pilihan terkecil yang berguna selama percakapan. Mengonfigurasi alat yang ada mungkin cukup jika alat itu dapat menyimpan versi yang disetujui. Prototipe dapat memperjelas cara manajer meninjau perubahan. Pemeriksaan teknis mungkin diperlukan untuk memastikan sistem saat ini menyediakan catatan yang dibutuhkan. Pembangunan aplikasi lengkap menjadi pilihan yang lebih beralasan setelah ketidakpastian tersebut dipahami. Catat alasan memilih suatu opsi dan bukti yang dapat mengubah pilihan itu.
Tetapkan penanggung jawab untuk setiap pertanyaan yang belum terjawab. Pimpinan penjualan dapat menentukan perubahan harga yang memerlukan persetujuan baru; administrator sistem yang berwenang dapat memeriksa ekspor atau akses integrasi yang tersedia. Setiap penyelidikan perlu hasil, batas, dan waktu peninjauan yang disepakati. Penelusuran dengan lingkup terbatas harus meninggalkan sesuatu yang dapat digunakan bisnis meskipun pengembangan tidak berlanjut, seperti alur yang disepakati, batasan yang diuji, atau perbandingan opsi lingkup.
Kirim atau sepakati ringkasan tertulis yang mencakup hasil yang diinginkan, pilihan yang dipertimbangkan, pertanyaan terbuka, dan keputusan berikutnya. Catat usulan biaya atau waktu sebagai proposal dengan lingkup dan asumsi; itu bukan perkiraan terkonfirmasi untuk integrasi yang belum diperiksa. Perbaiki istilah yang disalahpahami sebelum rencana bergantung padanya. Transkrip saja tidak menggantikan catatan keputusan yang disepakati. Hasil yang berguna adalah mengetahui siapa yang akan memastikan fakta berikutnya dan bagaimana fakta itu memengaruhi proyek.
Akhiri dengan keputusan berikutnya yang spesifik
Sampaikan kepada Orvun Labs hasil yang diinginkan dan hambatan utama. Percakapan seharusnya menghasilkan definisi masalah bersama serta bukti berikutnya, tanpa tekanan menyetujui pembangunan yang belum jelas.
- Contoh biasa apa paling menjelaskan masalah?
- Apa yang harus membaik dan boleh tetap sama?
- Siapa menjawab pertanyaan alur dan mengambil keputusan?
- Apakah berkas sudah diperiksa agar bebas rahasia dan data pribadi?
