Panduan Prompt
Cara Menulis Proposal Proyek dengan Claude
Proposal yang disetujui itu spesifik. Proposal yang diabaikan itu samar.
Claude dari Anthropic pandai mengubah ide proyek kasar menjadi proposal terstruktur dengan pernyataan masalah, cakupan, jadwal, dan jenis detail spesifik yang benar-benar membuat pemangku kepentingan berkata ya. Yang Claude tidak tahu adalah anggaran Anda, kapasitas nyata tim Anda, atau politik organisasi Anda, kecuali Anda memberitahunya, itulah sebabnya "tulis proposal proyek untuk X" cenderung menghasilkan sesuatu yang cukup umum untuk dimiliki oleh perusahaan apa pun. Solusinya adalah memberi Claude batasan nyata: untuk siapa proposal ini, apa yang sebenarnya Anda miliki untuk dikerjakan, dan keputusan apa yang Anda butuhkan dari orang itu.
Untuk meminta Claude menulis proposal proyek, berikan masalah yang Anda selesaikan, untuk siapa proposal ini dan keputusan apa yang Anda butuhkan darinya, batasan nyata Anda (ukuran tim, jadwal kasar, kisaran anggaran), dan instruksi untuk menyusun draf sebagai pernyataan masalah, pendekatan yang diusulkan, cakupan, jadwal, dan metrik keberhasilan. Tempelkan materi latar belakang, proposal sebelumnya, atau catatan yang sudah Anda miliki, dan minta Claude menandai apa pun yang terlalu samar untuk menjadi rencana konkret.
Diterbitkan
Pelajaran gratis · tanpa akunKenalan dengan ClaudeMengapa Claude?6 mntMulai pelajaran gratisPoin Penting
- Katakan untuk siapa proposal ini dan keputusan apa yang Anda butuhkan agar mereka ambil. Proposal untuk tim Anda sendiri merencanakan terbaca berbeda dari yang meminta eksekutif menyetujui anggaran.
- Berikan Claude batasan nyata Anda: ukuran tim, jadwal kasar, kisaran anggaran. Rencana yang dibangun di atas batasan rekaan harus ditulis ulang begitu seseorang dengan angka nyata membacanya.
- Minta metrik keberhasilan secara spesifik, bukan hanya deskripsi pekerjaan. Proposal yang tidak mengatakan bagaimana Anda akan tahu itu berhasil lebih sulit disetujui dan lebih sulit ditindaklanjuti nanti.
- Tempelkan materi latar belakang yang sudah Anda miliki: proposal sebelumnya, catatan rapat, kerangka kasar. Claude mengorganisir dan mempertajam apa yang Anda berikan; ia tidak bisa mengarang konteks di balik proyek spesifik Anda.
- Baca bagian cakupan dengan sangat teliti sebelum mengirim. Cakupan yang lebih samar atau lebih luas dari maksud Anda sebenarnya adalah alasan paling umum mengapa proposal menyebabkan masalah nanti.
Salin dan tempel
Prompt yang bisa Anda pakai hari ini
Draf lengkap pertama dari ide kasar
Saya ingin mengusulkan [jelaskan ide proyek Anda dalam satu atau dua kalimat]. Ini untuk [untuk siapa proposal ini dan keputusan apa yang Anda butuhkan dari mereka]. Ini yang sebenarnya saya miliki untuk dikerjakan: tim [ukuran], jadwal sekitar [jangka waktu], anggaran sekitar [kisaran, atau 'belum ditentukan']. Tulis draf proposal dengan pernyataan masalah, pendekatan yang diusulkan, cakupan (termasuk apa yang secara eksplisit di luar cakupan), jadwal kasar, dan metrik keberhasilan. Tandai apa pun yang harus Anda tebak karena saya tidak memberikan detail yang cukup.
Jujur tentang apa yang belum Anda ketahui, seperti anggaran, menghasilkan draf yang lebih berguna daripada mengarang angka untuk mengisi kekosongan.
Mengubah brainstorming berantakan menjadi pernyataan masalah
Ini catatan kasar dan tidak terorganisir saya tentang masalah yang ingin saya selesaikan: [tempel catatan Anda]. Ubah ini menjadi pernyataan masalah yang padat, dua hingga tiga kalimat, yang menjelaskan mengapa ini penting dan siapa yang terpengaruh, tanpa menjelaskan solusinya dulu. Saya ingin masalahnya dibingkai dengan jelas sebelum saya mengusulkan perbaikannya.
Pisahkan pernyataan masalah dari solusi; proposal yang langsung melompat ke perbaikan sering kehilangan pembaca yang belum yakin ada masalah yang layak diselesaikan.
Mendefinisikan cakupan, termasuk apa yang di luar
Ini proyek yang saya usulkan: [jelaskan]. Tulis bagian cakupan yang menyatakan dengan jelas apa yang akan dan tidak akan disertakan proyek ini, dengan setidaknya tiga hal spesifik yang secara eksplisit disebut di luar cakupan. Saya ingin menghindari proposal dibaca lebih luas dari yang saya maksudkan.
Daftar eksplisit tentang apa yang di luar cakupan sering menjadi bagian proposal yang paling mencegah kebingungan nanti.
Menguji ketahanan proposal sebelum mengirimnya
Baca draf proposal ini seolah Anda adalah pemangku kepentingan yang memutuskan apakah menyetujuinya: [tempel draf Anda]. Pertanyaan apa yang akan Anda miliki sebelum menyetujui ini? Di mana jadwal, cakupan, atau metrik keberhasilan terasa tidak realistis atau tidak jelas? Spesifiklah tentang apa yang hilang, bukan hanya apa yang salah.
Ini bekerja paling baik tepat sebelum mengirim proposal, sebagai pemeriksaan akhir daripada langkah draf awal.
Menyesuaikan nada proposal untuk audiens berbeda
Ini proposal proyek yang saya tulis untuk tim saya sendiri: [tempel draf Anda]. Tulis ulang untuk audiens eksekutif yang perlu menyetujui anggaran: mulai dengan kasus bisnis dan biaya, buat detail teknis singkat, dan pindahkan detail implementasi apa pun ke bagian lampiran di akhir.
Proyek yang sama sering membutuhkan dua versi berbeda tergantung siapa yang membaca dan apa yang perlu diputuskan orang itu.
Struktur
Lima bagian yang dibutuhkan prompt proposal
Lima elemen ini mengubah ide samar menjadi sesuatu yang bisa benar-benar ditindaklanjuti pemangku kepentingan.
Pernyataan masalah, sebelum solusi
Nyatakan masalah dan mengapa itu penting sebelum menjelaskan perbaikannya. Pembaca yang belum yakin ada masalah tidak akan menanggapi serius solusi yang diusulkan untuknya.
Cakupan, termasuk apa yang secara eksplisit di luar
Katakan apa yang akan dilakukan proyek dan, sama pentingnya, apa yang tidak akan dilakukan. Proposal tanpa cakupan yang ditentukan cenderung membesar di kepala setiap orang menjadi apa yang mereka asumsikan maksudnya.
Batasan nyata, bukan rekaan
Berikan Claude ukuran tim nyata, jadwal kasar, dan kisaran anggaran Anda, meskipun sebagian masih belum pasti. Rencana yang dibangun di atas angka rekaan harus dibuat ulang begitu angka nyata muncul.
Metrik keberhasilan, dinyatakan jelas
Katakan bagaimana Anda akan tahu proyek itu berhasil. Proposal tanpa metrik keberhasilan lebih sulit disetujui dan, jika disetujui juga, lebih sulit ditindaklanjuti enam bulan kemudian.
Kenali Pembaca Anda
Proyek yang sama membutuhkan proposal berbeda untuk audiens berbeda
Proposal yang ditulis agar tim Anda sendiri merencanakan dan proposal yang ditulis untuk mendapatkan persetujuan anggaran dari eksekutif melakukan pekerjaan berbeda, meskipun menjelaskan proyek yang sama. Versi tim bisa mendalami detail implementasi karena pembaca sudah peduli dengan itu. Versi eksekutif perlu dimulai dengan kasus bisnis dan biaya, karena itulah keputusan nyata yang harus diambil pembaca tersebut, dan detail yang tidak perlu hanya menunda keputusan yang Anda minta.
Beri tahu Claude secara eksplisit siapa yang membaca dan keputusan apa yang Anda butuhkan dari orang itu. "Ini untuk tim saya merencanakan kuartal depan" dan "ini perlu persetujuan anggaran dari VP yang tidak tahu detail teknis" mengarahkan Claude ke dua draf berbeda, bahkan untuk proyek yang sama, dan menyebutkan audiens sejak awal menghindarkan Anda menulis satu versi dan menemukan kemudian bahwa itu salah untuk pembaca nyata.
Jika Anda benar-benar membutuhkan kedua versi, biasanya lebih cepat menulis versi detail tim dulu lalu meminta Claude menyesuaikannya untuk audiens eksekutif, daripada menulis keduanya dari awal. Fakta yang mendasarinya tidak berubah; hanya yang ditekankan dan yang pindah ke lampiran yang berubah.
Kesalahan Umum
Apa yang membuat proposal tersendat daripada disetujui
Inilah kesenjangan yang mengubah ide yang masuk akal menjadi proposal yang tidak terjawab.
Cakupan yang lebih luas dari maksud Anda sebenarnya
Jika Anda tidak menyatakan apa yang di luar cakupan, pembaca akan mengisi kekosongan dengan asumsi mereka sendiri, yang sering lebih besar dari yang Anda maksudkan untuk diusulkan. Nyatakan secara eksplisit apa yang tidak akan disertakan proyek ini.
Tidak ada keputusan yang dinyatakan untuk pembaca
Proposal yang tidak mengatakan apa yang sebenarnya Anda minta, persetujuan, anggaran, staf, lampu hijau untuk mulai, membuat pembaca tidak yakin respons apa yang Anda butuhkan darinya.
Angka rekaan menggantikan batasan nyata
Jadwal atau anggaran yang ditebak Claude karena Anda tidak memberikannya akan terdengar percaya diri meski fiktif, dan seseorang dengan angka nyata akan menyadari proposal tidak sesuai dengan realita.
Tidak ada cara mengetahui nanti apakah itu berhasil
Proposal tanpa metrik keberhasilan sulit disetujui dengan percaya diri, dan jika tetap disetujui, tidak ada cara yang disepakati untuk memeriksa enam bulan kemudian apakah proyek itu memberikan hasil.
Menggunakan Apa Yang Sudah Anda Miliki
Tempelkan materi latar belakang Anda daripada mulai dari nol
Jika Anda memiliki proposal sebelumnya untuk sesuatu yang serupa, catatan rapat kasar tentang masalah, atau bahkan kerangka yang setengah selesai, tempelkan itu daripada menjelaskan proyek dari memori sejak awal. Claude bisa mengorganisir dan mempertajam materi yang sudah Anda miliki jauh lebih andal daripada mengarang konteks spesifik, sejarah, dan batasan proyek nyata Anda dari deskripsi satu kalimat.
Ini penting terutama untuk pernyataan masalah. Jika masalah muncul dalam rapat, dalam keluhan pelanggan, atau dalam upaya sebelumnya yang gagal terhadap sesuatu yang serupa, konteks itu termasuk dalam prompt. Pernyataan masalah yang dibangun hanya dari ringkasan Anda saat ini tentang masalah tersebut sering kehilangan detail spesifik yang membuat masalah itu nyata dan layak diselesaikan.
Hal yang sama berlaku untuk batasan. Jika organisasi Anda sudah memiliki template proposal standar, kisaran anggaran khas untuk jenis proyek ini, atau konvensi jadwal yang biasa, berikan itu langsung ke Claude daripada membiarkannya kembali ke struktur umum. Proposal yang sudah cocok dengan bagaimana organisasi Anda mengharapkan melihat jenis dokumen ini dibaca lebih serius daripada yang terasa seperti template dari tempat lain.
Ada baiknya Anda menyimpan folder berisi proposal yang pernah disetujui di organisasi Anda, meski secara informal, dan menempelkan salah satu yang berhasil di samping draf Anda sendiri saat bisa. Claude bisa mengenali pola dari apa yang biasanya diterima, entah itu tingkat formalitas tertentu, preferensi paragraf pendek dibanding panjang, atau kebiasaan memulai dengan mitigasi risiko, lalu menerapkan pola yang sama pada draf Anda saat ini daripada memakai struktur umum yang tidak sesuai dengan apa yang sebenarnya berhasil di tempat kerja Anda.
Sebelum Mengirimnya
Apa yang harus diperiksa sebelum proposal sampai ke pembaca
Baca bagian cakupan dulu dan tanyakan pada diri sendiri apakah itu menjelaskan secara tepat apa yang Anda maksudkan untuk dilakukan, tidak lebih tidak kurang. Ini adalah bagian yang paling mungkin menyebabkan masalah nanti jika lebih samar atau lebih luas dari maksud Anda sebenarnya, karena itu menjadi hal yang semua orang tunjuk kembali begitu proyek berjalan.
Periksa setiap angka terhadap realita: jadwal, ukuran tim, anggaran. Rencana yang terdengar percaya diri tetapi dibangun di atas angka yang ditebak lebih buruk daripada "jadwal belum final" yang jujur, karena yang pertama diperlakukan sebagai komitmen begitu seseorang membacanya.
Struktur di sini memberi Anda draf yang kuat dengan cepat; penilaian tentang apa yang organisasi dan pembaca Anda sebenarnya butuhkan untuk proposal spesifik ini tetap milik Anda sebelum itu dikirim.
Proposal yang jelas dibaca. Proposal yang samar diabaikan.
Struktur ini dapat digunakan kembali untuk setiap proposal setelah ini. Pelajaran gratis Nightschool AI membahas tugas menulis kerja nyata dengan Claude, termasuk penilaian tentang cakupan dan audiens.
Pertanyaan yang Sering Diajukan
Apa hal paling penting untuk diberitahukan kepada Claude sebelum menyusun proposal?
Untuk siapa proposal ini dan keputusan apa yang Anda butuhkan agar mereka ambil. Proposal untuk tim Anda sendiri merencanakan dan yang meminta eksekutif menyetujui anggaran membutuhkan pembingkaian berbeda, bahkan untuk proyek yang sama.
Haruskah saya memberi Claude angka anggaran jika saya belum memilikinya?
Tidak. Katakan anggaran belum final daripada membiarkan Claude menebak angka. Angka rekaan yang terdengar percaya diri akan diperlakukan sebagai komitmen begitu seseorang dengan angka nyata melihatnya.
Mengapa proposal membutuhkan bagian eksplisit tentang apa yang di luar cakupan?
Tanpanya, pembaca akan mengisi kekosongan dengan asumsi mereka sendiri tentang apa yang disertakan proyek, yang sering lebih luas dari maksud Anda sebenarnya. Menyatakan secara eksplisit apa yang dikecualikan mencegah pergeseran itu.
Bagaimana saya menulis proposal yang bekerja untuk tim saya dan eksekutif?
Tulis dulu versi detail untuk tim Anda, lalu minta Claude menyesuaikannya untuk pembaca eksekutif: mulai dengan kasus bisnis dan biaya, kurangi detail teknis, dan pindahkan hal spesifik implementasi ke lampiran.
Bisakah saya menggunakan catatan dari proposal atau rapat sebelumnya daripada mulai dari nol?
Ya, dan Anda sebaiknya melakukannya. Tempelkan materi latar belakang yang sudah Anda miliki. Claude mengorganisir dan mempertajam materi nyata jauh lebih baik daripada mengarang konteks spesifik proyek Anda dari nol.
Mengapa proposal membutuhkan metrik keberhasilan?
Tanpa cara yang dinyatakan untuk mengukur keberhasilan, proposal lebih sulit disetujui dengan percaya diri, dan tidak ada cara yang disepakati untuk memeriksa nanti apakah proyek benar-benar memberikan apa yang dijanjikan.
Bagaimana saya harus memeriksa draf sebelum mengirimnya ke pemangku kepentingan?
Minta Claude membacanya seperti yang akan dilakukan pemangku kepentingan dan mendaftar pertanyaan yang akan mereka miliki sebelum menyetujuinya. Lalu periksa secara terpisah setiap angka dalam draf terhadap batasan nyata Anda sebelum dikirim.
Bagaimana jika organisasi saya sudah memiliki template proposal standar?
Berikan itu langsung ke Claude daripada membiarkan draf kembali ke struktur umum. Proposal yang sudah cocok dengan format yang diharapkan organisasi Anda dibaca lebih serius daripada yang tidak.
Proposal yang disetujui dimulai dengan batasan nyata
Struktur ini dapat digunakan kembali setiap kali. Memberinya angka yang jujur daripada tebakan adalah bagian yang layak dilakukan dengan benar.