Tantangan untuk pendekatan Agile pada proyek-proyek pemerintah

Diskusi Agile sebelumnya di sini memiliki jawaban yang baik yang menentukan apa yang penting untuk keberhasilan penerapan metodologi Agile dalam pengembangan perangkat lunak. Sebagian besar poin adalah tantangan khas organisasi dan manajemen, tetapi satu poin membuat saya khawatir dan itu adalah bahwa klien harus terlibat di seluruh proses.

Klien adalah satu hal yang tidak dapat Anda kontrol secara realistis, mungkin model bisnis Anda mengarahkan Anda ke pekerjaan yang dikontrak pemerintah, misalnya ketika kontrak yang sangat ketat mengharuskan perusahaan untuk:

• Berikan fitur X persis seperti yang diminta

• Permintaan fitur akan dilemparkan ke dinding, jangan ganggu kami, kami tidak ingin mendengarnya.

• Tidak ada konsep prioritas fitur dalam pikiran pelanggan, semuanya penting atau kami tidak akan meminta mereka.

• Proyek ini akan menelan biaya tidak lebih dan tidak kurang dari Y terlepas dari kelebihan atau tenggat waktu.

• Batas waktu absolut, ketat, final, dan tidak dapat dinegosiasikan untuk penyerahan lengkap semua pekerjaan.

Kami belum pernah bekerja dengan klien seperti itu sebelumnya tetapi uang pada proyek terlalu bagus untuk dilewatkan. Kami membutuhkan pekerjaan ini.

Saya datang ke sini dan bekerja KERAS untuk mengubah proses di dalam untuk bergerak ke arah pengembangan Agile dan di sini saya tidak tahu bagaimana merekonsiliasi di mana proyek ini cocok dengan proses baru kami. Saya belum pernah memiliki kemewahan manajemen hands-off yang berpikiran terbuka yang memercayai saya untuk memimpin tim pengembangan dan proses di jalan ini dan sekarang kita di sini saya tidak bisa jujur ​​mengatakan pada diri sendiri bahwa proyek ini benar-benar akan dilakukan dalam Cara tangkas. Saya merasa seperti manajemen memercayai saya untuk memimpin jalan ini dan saya mengecewakan mereka karena situasi kita sekarang dengan sangat jelas menyerukan Air Terjun. Saya takut bahwa saya akan kehilangan kepercayaan mereka jika saya mundur sekarang.

Jawaban lain seperti yang di sini mengatakan Agile tidak mungkin dengan klien semacam ini, apakah Anda setuju? Apakah ada di antara Anda yang pernah berada dalam situasi yang sama dan berhasil? Strategi apa yang Anda terapkan untuk membuat Agile berhasil?

Saya pikir hal pertama yang harus disadari adalah bahwa ada perbedaan antara menjadi gesit dan gesit. Perlahan-lahan meluncurkan teknik dan karakteristik lincah - tim lintas-fungsional, perencanaan adaptif, pengiriman evolusi / tambahan, iterasi kotak waktu, dan bahkan memperkenalkan konsep-konsep dari Lean sangat berbeda dari memperkenalkan Pemrograman Ekstrim, Scrum, atau Crystal.

Anda secara eksplisit menyebutkan keterlibatan pelanggan. Ya, banyak metodologi Agile meminta keterlibatan pelanggan, tetapi itu tidak dituntut untuk gesit. Di setiap program terkait pemerintah / pertahanan, saya selalu memiliki manajer program atau proyek yang merupakan titik kontak dengan pelanggan. Orang ini menjadi "suara pelanggan". Mungkin diperlambat ketika mereka melakukan teleconference atau mengirim email atau menelepon dan mengklarifikasi, tetapi Anda dapat memiliki satu orang (atau satu kelompok, jika Anda juga memiliki wakil PM) yang merupakan perwakilan pelanggan dari tim Anda. Memang, itu tidak persis sama. Tetapi bukankah menjadi gesit tentang menjadi fleksibel dan menanggapi perubahan?

Anda juga menyebutkan beberapa konsep utama: persyaratan yang telah ditentukan, memiliki permintaan fitur "terlempar ke tembok", kurangnya prioritas karena "mereka semua penting", dan proyek dengan biaya tetap dan / atau jadwal tetap. Masing-masing dapat diatasi dengan cara yang berbeda.

Jika Anda merasa memiliki semua persyaratan di muka, kemungkinan besar tidak. Persyaratan memang berubah. Hanya karena Anda memiliki spesifikasi "selesai dan ditandatangani", tidak berarti bahwa spesifikasi tersebut telah ditetapkan. Dengan dokumen persyaratan apa pun yang Anda miliki, tangkap mereka bagaimana Anda merasa nyaman dan / atau dengan cara yang ditentukan oleh kontrak dan berikan persyaratan, desain, dan arsitekturnya. Selain itu, lihat apakah Anda dapat memperlakukan ini dokumen hidup (dokumen desain yang saya lihat hari ini di tempat kerja dilabeli sebagai Revisi G, yang berarti sedang dalam pembaruan ke-8). Tanyakan tentang berapa banyak Anda dapat meninggalkan TBD dalam setiap iterasi yang diberikan dan berapa banyak yang perlu dikukuhkan sekarang - mungkin ada beberapa memberi dan menerima.

Cekatan dengan dokumentasi Anda. Jangan menduplikasi upaya antara "apa yang diinginkan tim Anda" dan "apa yang diinginkan pelanggan". Misalnya, jika pelanggan Anda menginginkan spesifikasi persyaratan perangkat lunak tradisional dan tim Anda ingin menggunakan cerita pengguna, cobalah untuk beradaptasi dengan SRS tradisional dan menggunakan item tindakan dan daftar item tindakan bergulir alih-alih cerita pengguna sehingga Anda tidak menghabiskan waktu merumuskan "sistem harus ..." dan "harus mampu karena". Namun, hal ini membutuhkan disiplin tim untuk beradaptasi dengan perbedaan di antara berbagai proyek. Tangkap masalah dalam refleksi.

Setelah Anda mengembangkan, Anda dapat menjalankan 5 atau 6 iterasi, dan kemudian mengundang pelanggan Anda ke fasilitas Anda untuk melihat subset dari implementasi Anda. Bilas dan ulangi proses ini. Ini bukan keterlibatan konstan yang diminta oleh beberapa metodologi, tetapi Anda memang memiliki keuntungan visibilitas tinggi. Jika pelanggan Anda mengatakan tidak, setidaknya Anda sudah mencoba. Jika mereka menjawab ya, Anda bisa memberi tahu mereka tentang kelincahan. Pada satu proyek saya, pelanggan mengunjungi situs setiap beberapa bulan (3-5 bulan, biasanya). Mereka akan mengawasi kita melalui pengujian QA, mereka akan membahas masalah dengan para insinyur, dan bisnis dengan kantor program / proyek. Itu adalah kesempatan bagi semua orang untuk masuk ke halaman yang sama.

Pengujian dan pemeliharaan terjadi sama seperti pada proyek tangkas lainnya. Buat prosedur pengujian dan kerusakan dokumen dengan cara yang sesuai, lacak metrik per kewajiban kontrak, dan dokumentasikan hasil pengujian. Jika Anda ingin mengikuti TDD, lakukan. Integrasi berkelanjutan adalah ide bagus lainnya. Selama pertemuan status proyek, manajer proyek Anda dapat menggunakan informasi ini untuk mengatakan "kami menerapkan persyaratan N, melakukan tes M, lulus tes X" dan memperbarui kesehatan proyek dan status kepada orang-orang yang memiliki uang.

Berbicara tentang uang, kita memiliki masalah biaya tetap dan / atau jadwal tetap.

Berurusan dengan jadwal tetap cukup mudah. Dengan persyaratan Anda, Anda tahu berapa banyak iterasi yang dapat Anda selesaikan. Beban kerja Anda untuk setiap iterasi diatur cukup banyak dalam hal fitur untuk mengimplementasikan, menguji, dan mengintegrasikan. Mungkin sulit, tetapi bukan tidak mungkin untuk memecah fitur dan menetapkannya ke iterasi terlebih dahulu. Ini kembali ke poin saya tentang mengundang pelanggan - jika Anda memiliki satu tahun dan menggunakan iterasi 2 minggu, mungkin mengundang pelanggan setiap tiga bulan (dan mengundang mereka setiap tiga bulan) dan menunjukkan kepada mereka hasil pekerjaan sebelumnya. Biarkan mereka melihat prioritas kebutuhan Anda, rencana masa depan Anda, dan bagaimana Anda akan menjadwalkan.

Berurusan dengan anggaran tetap serupa. Anda tahu berapa banyak waktu yang Anda miliki, berapa banyak sumber daya yang Anda miliki untuk proyek, berapa biayanya, dan oleh karena itu berapa jam setiap orang dapat bekerja per iterasi. Ini hanya masalah memastikan bahwa semua orang melacak hal ini dengan cermat. Jika perusahaan Anda dapat memakan biaya lembur, lakukan saja. Jika tidak, pastikan semua orang bekerja dalam jangka waktu yang sesuai dan gunakan keterampilan manajemen waktu yang baik dan tinju waktu untuk membuat semua orang produktif. Lebih banyak jam produktif adalah apa yang Anda butuhkan untuk menekan biaya - serahkan lebih banyak dokumen dan perangkat lunak bernilai tambah tanpa biaya pertemuan dan biaya overhead.

Pada akhirnya, ini bukan tentang selalu gesit, tetapi menerapkan hal-hal yang membuat tangkas baik dan tangkas. Mampu menanggapi perubahan dalam persyaratan, dapat memberikan perangkat lunak yang sering bahkan jika pelanggan tidak menginginkannya, hanya menghasilkan dokumentasi nilai tambah (bersama dengan apa pun yang secara kontrak Anda wajib untuk menghasilkan), dan sebagainya.

Ya, lincah tidak cocok untuk proyek seperti itu, karena sepertinya persyaratan sudah dilakukan dan diperbaiki, mungkin hasil analisis bertahun-tahun oleh konsultan mahal, rapat komite, dan kompromi politik. Air terjun berfungsi dengan baik jika pelanggan begitu disiplin sehingga mereka dapat memberi tahu Anda secara tertulis apa yang mereka inginkan. Mereka mungkin salah, tetapi setidaknya Anda memilikinya secara tertulis, dan Anda akan dibayar jika Anda mengirimkannya. (Ini tidak mengatakan apa pun tentang kepuasan pelanggan, tentu saja. Kemungkinannya adalah Anda akan memberikan sesuatu yang sebenarnya tidak mereka butuhkan.)

Agile diciptakan untuk memecahkan masalah yang tidak Anda miliki: risiko karena ketidakpastian dalam persyaratan.

Memang benar bahwa pelanggan mungkin meminta permintaan perubahan, tetapi Anda juga mengikuti salah satu dari dua jalur:

1. Uang itu sangat bagus sehingga Anda tahu Anda bisa menyerap sejumlah fitur X baru di berbagai tahap proyek dan masih keluar tanpa kehilangan baju Anda, atau
2. Anda menjelaskan kepada pelanggan pada awalnya bahwa karena mereka menegosiasikan harga yang ketat, bahwa setiap permintaan fitur baru akan menghasilkan perubahan pesanan dengan harga yang harus disetujui oleh mereka, dengan pesanan pembelian yang menyertainya (atau perubahan terhadap pesanan pembelian asli) agar Anda dapat menerapkannya. Urutan perubahan akan menguraikan dampak apa pun pada fungsionalitas atau jadwal. Jika mereka mengatakan tenggat waktu tidak dapat dipindahkan, maka mengubah pesanan hanya menjadi lebih mahal secara eksponensial seiring proyek berlangsung karena lebih mahal untuk mengubah barang di kemudian hari.

Hubungannya terasa jauh lebih bersahabat dalam situasi nomor 1, tetapi faktanya sangat jarang menemukan departemen pembelian yang tidak akan menekan harga Anda, jadi sebagian besar waktu Anda berada dalam situasi nomor 2. Itu berarti hubungan itu konfrontatif, tetapi jika Anda ingin bertahan dalam bisnis, Anda harus pandai mengelola hubungan sambil memegang tanah Anda. Ini adalah sebagian besar pekerjaan manajer proyek.

Sepertinya Anda berada dalam situasi # 1, yang bagus. Saya membayangkan bahwa kontrak-kontrak pemerintah adalah satu-satunya tempat di mana mereka tidak peduli tentang uang, karena, setelah semua, mereka tidak menghabiskan mereka uang, mereka menghabiskan Anda uang.

... pemerintah yang dikontrak pemerintah misalnya ketika kontrak yang sangat ketat mengharuskan perusahaan untuk:

Pertama. Sangat ketat. Tapi itu tidak fleksibel. Ini hanya membutuhkan perhatian terhadap detail dan serangkaian perintah perubahan yang panjang.

Instansi pemerintah sebenarnya gesit dengan cara lambat, tidak efisien. Anda harus menulis (dan bernegosiasi) secara resmi, perintah perubahan terperinci sepanjang waktu.

Berikan fitur X persis seperti yang diminta

Hingga dimodifikasi oleh perintah perubahan.

Permintaan fitur akan dilemparkan ke dinding, jangan ganggu kami, kami tidak ingin mendengarnya.

Saluran komunikasi adalah urutan perubahan. Dampak Anggaran dan Jadwal.

Tidak ada konsep prioritas fitur dalam pikiran pelanggan, semuanya penting atau kami tidak akan meminta mereka.

Ini sulit untuk diselesaikan. Bahkan bisnis non-pemerintah yang menghabiskan banyak uang untuk "analisis kebutuhan" tidak ingin diberi tahu bahwa tumpukan besar, datar, dan banyak persyaratan yang tidak terbebani oleh prioritas dan informasi tradeoff tidak lengkap. Mereka membayar banyak uang untuk mendapatkan semua persyaratan. Bagaimana Anda menginginkan informasi lebih lanjut?

Ini masalah yang sulit.

Proyek ini akan menelan biaya tidak lebih dan tidak kurang dari Y terlepas dari kelebihan atau tenggat waktu.

Kecuali untuk perubahan pesanan. Yang memodifikasi Y dan Tenggat.

Batas waktu absolut, ketat, final, dan tidak dapat dinegosiasikan untuk penyerahan lengkap semua pekerjaan.

"tidak dapat dinegosiasikan" umumnya tidak benar. Itu bisa dinegosiasikan. Cukup menyakitkan untuk dinegosiasikan.

Bagian penting dari negosiasi dengan lembaga pemerintah adalah kenyataan bahwa Anda memerlukan "bukti tingkat pengacara" untuk perubahan biaya dan jadwal Anda. Beberapa presentasi teknis yang cermat dengan slide power-point yang bagus bukanlah "bukti". Anda perlu banyak dokumentasi untuk menyelesaikan kasus Anda.

Orang-orang pemerintah perlu memberikan bukti yang tidak dapat disangkal bahwa mereka telah melakukan segala daya mereka untuk membuat ini semurah dan seefektif mungkin. Mereka tahu bahwa setiap keputusan diputar ulang di pers publik dan diteliti dengan cermat.

Kompleksitas pengembangan perangkat lunak, dan aspek "pemerintah Senin pagi" dari pekerjaan pemerintah membuat mereka enggan untuk membuat perubahan pada kontrak tanpa banyak bukti.

Itu membuat pendekatan Agile benar sulit.

"Individu dan interaksi atas proses dan alat" itu sulit. Anda tidak bekerja dengan seorang individu, tetapi seorang wakil dari pemerintah yang pekerjaannya dibatasi oleh proses.

Dalam proyek seperti ini, mereka mengikat tangan Anda pada ruang lingkup, sumber daya, dan waktu. Satu-satunya hal yang tersisa untuk Anda kelola adalah kualitas. Begitu...

Anda tidak akan mendapatkan sebagian besar manfaat dari pendekatan gesit yang Anda mungkin sebaliknya, tetapi Anda bisa melakukan yang terbaik untuk mengurangi risiko kualitas dan dapat memberi tahu klien tentang masalah lebih awal daripada nanti.

Jadi gesit yang Anda bisa:

1. Pergi melalui persyaratan dan memprioritaskan mereka dengan risiko teknis. Tetapkan persyaratan yang diprioritaskan sebagai jaminan Anda.
2. Bekerja melalui backlog dalam sprint - desain, uji, dan kode fitur untuk sprint. Anda melewatkan interaksi klien, jadi dokumen persyaratan harus mewakili klien untuk aktivitas ini.
3. Undang klien ke setiap ulasan sprint - mereka dapat mengatakan tidak, tetapi mereka mungkin mengatakan ya. Dan Anda akan mendapatkan umpan balik lebih cepat daripada nanti.

Jika Anda mulai berlari melawan tenggat waktu, Anda akan dapat menunjukkan apa yang sudah dilakukan, dan mungkin pada saat itu klien, mengetahui dia tidak akan mendapatkan segalanya, akan memprioritaskan cukup untuk memberi tahu Anda apa yang dia inginkan. Anda juga harus menyelesaikan pekerjaan paling berisiko, artinya tugas pada tenggat waktu paling mudah dijejali dengan bekerja dalam jam tambahan.

Saya pikir klien jenis ini bukan norma. Anda berurusan dengan grup yang telah meminta proyek serupa sebelumnya, sehingga mereka tahu persis apa yang mereka inginkan. Anda tidak pernah menyebutkan bahwa spesifikasinya akan berubah.

Berikan fitur X persis seperti yang diminta

Saya beruntung jika saya memberikan fitur X secara samar seperti yang disarankan dan siap untuk mengubahnya pada saat pemberitahuan.

Permintaan fitur akan dilemparkan ke dinding, jangan ganggu kami, kami tidak ingin mendengarnya.

Jika Anda tahu apa yang mereka inginkan, pergi dan bangun.

Tidak ada konsep prioritas fitur dalam pikiran pelanggan, semuanya penting atau kami tidak akan meminta mereka.

Anda tidak bisa kalah dalam hal ini. Bangun mereka sesuai keinginan Anda.

Proyek ini akan menelan biaya tidak lebih dan tidak kurang dari Y terlepas dari kelebihan atau tenggat waktu. Batas waktu absolut, ketat, final, dan tidak dapat dinegosiasikan untuk penyerahan lengkap semua pekerjaan.

Itu yang sulit jika Anda belum pernah membangun proyek untuk pemerintah. Jika Anda memiliki riwayat, Anda mungkin dapat menentukan apakah Anda dapat mengirimkannya. Ini tidak berarti mereka tidak membayar dengan baik (mereka terkenal karena membayar $ 50 dengan palu $ 10) atau memiliki harapan yang tidak masuk akal. Dengan spesifikasi ini, seseorang di tim Anda harus bertindak sebagai pelanggan dan menyetujui pekerjaan dibandingkan dengan spesifikasi. Bahkan jika Anda menemukan cacat dan memohon mereka untuk mengubah persyaratan, mereka mungkin tidak akan melakukannya.

Sayangnya apa yang telah Anda gambarkan adalah pandangan khas pelanggan tentang bagaimana proyek perangkat lunak harus ditangani. Ini bukan untuk mengatakan bahwa pelanggan tidak masuk akal; setelah semua - bukankah ini bagaimana orang akan melaksanakan pembangunan hal lain (rumah, misalnya?). Meski begitu, saya tidak menawarkan apa pun lebih dari apa yang kita semua sudah tahu. Yang Anda tanyakan adalah ... apakah penerapan praktik tangkas layak dalam situasi ini?

Saya mendapat manfaat karena baru saja menyelesaikan proyek yang serupa dalam banyak hal dengan situasi yang Anda gambarkan, yaitu,

1. Batas waktu tetap (di batu, datang neraka atau air tinggi).
2. Dokumen Persyaratan Fungsional ("Alkitab"). Tidak mengejutkan tidak memadai.
3. Peran tradisional: Manajer Proyek, Analis Bisnis.
4. Pengguna bisnis yang lemah terlibat (dapatkah Anda mengatakan "tidak ada sponsor produk"?).

... dan tentu saja, tim pengembangan yang berpikiran maju berusaha untuk bekerja dengan gesit, terlepas dari yang di atas:

1. Iterasi 2 minggu;
2. Stand-up;
3. Retrospektif;
4. Pemrograman pasangan;
5. TDD;
6. Integrasi berkelanjutan.

Apakah semua ini dari jauh bermakna bagi Bisnis? Tidak. Dua bulan sebelum tenggat waktu, iterasi yang sampai saat itu diamati dengan saksama dan rapat perencanaan ditinggalkan dalam hiruk-pikuk ayam tanpa kepala.

Jawaban yang diberikan orang lain di atas adalah tingkat kompromi yang lebih besar atau lebih kecil. Menurut pendapat saya, gesit (apakah "gesit" atau "gesit") "dilakukan" dengan cara yang merusak ketika kita berkompromi. Menurutku:

Tidak ada kompromi, atau tidak ada gesit.

Sangat semangat tangkas adalah tentang pemotongan untuk mengejar, menghapus sampah, menjadi brutal jujur dengan diri sendiri. Ini adalah fakta yang sekarang terdokumentasi dengan baik dan tidak dapat disangkal bahwa estimasi perangkat lunak pada proyek-proyek besar adalah pertaruhan terbaik. Bukankah tugas kita sebagai profesional perangkat lunak untuk mendidik calon klien ini? Jika klien tidak mau menerima bahwa kami adalah ahlinya, maka bukankah tugas profesional kami untuk pergi?

Ketika saya mulai bekerja di tempat saya sekarang, saya mendapati diri saya mengajukan pertanyaan yang sama dengan yang Anda tanyakan cukup banyak. Ada sesuatu yang bisa dikatakan untuk air terjun dengan kontrak pemerintah. Ironisnya, lincah sekarang telah menjadi kata kunci dengan pelanggan pemerintah (yang secara realistis bekerja dengan cara terjun), jadi sekarang kita dibiarkan berusaha lebih keras untuk menerapkan proses gesit dengan pelanggan yang pada dasarnya tidak fleksibel.

Kami memiliki sistem yang digambarkan sebagai "Scrummerfall" "Agilefall" atau "A berantakan", tetapi dalam banyak hal kami perlahan-lahan dapat mengadopsi proses yang lebih gesit karena proyek (raksasa) ini telah bergerak maju selama bertahun-tahun. . Salah satu cara yang kami lakukan pada dasarnya adalah menemukan kembali saluran komunikasi dengan PENGGUNA sistem kami, sebagai lawan dari PELANGGAN kami. Pelanggan kami adalah departemen pengap yang dipimpin oleh pejabat yang ditunjuk yang tidak akan pernah menyentuh perangkat lunak kami dalam kehidupan kerja mereka dan tidak ingin memahaminya. Pengguna kami adalah personil pemerintah reguler di bidang yang berusaha menyelesaikan tugas penting. Bagi kami, kunci untuk membuat lingkaran umpan balik komunikasi yang memungkinkan kami menjadi gesit seperti kami adalah keharusan bagi UAT (Pengujian Penerimaan Pengguna).

Pada titik awal dalam proyek kami, diputuskan bahwa sekelompok perwakilan PENGGUNA AKTUAL dari berbagai kantor pelanggan besar pemerintah kami akan dikumpulkan di lokasi DI SINI dan kami akan memiliki beberapa minggu facetime dengan mereka ketika mereka menjalankan serangkaian skrip uji untuk menguji perangkat lunak kami. Sangat sebagai hal yang informal, tim persyaratan mengubah waktu ini menjadi cara yang sangat berharga untuk mendapatkan umpan balik dari pengguna akhir yang sebenarnya. Sementara itu, tim uji UAT dalam pemerintah bekerja melalui birokrasi mereka untuk memiliki lebih banyak dan lebih banyak pengaruh terhadap proses persyaratan formal pada akhirnya termasuk perubahan pesanan. Hasil akhirnya adalah bahwa BA seperti saya bertindak sebagai pemilik produk mandiri yang tertanam dalam tim scrum dan bisa mendapatkan waktu yang sangat berharga dengan pelanggan nyata yang memungkinkan kami berfungsi dengan cara yang sangat gesit.

Jelas, ada banyak masalah, dan kami masih belum benar - benar gesit, tetapi kami cukup gesit untuk dianggap sebagai contoh dari proyek tangkas besar yang benar-benar menggunakan metodologi itu di sektor kontraktor pemerintah.

Singkatnya: gunakan pengalaman Anda sebagai penginjil lincah dalam organisasi Anda sendiri untuk menyusup ke pelanggan Anda. Lalui proses pembelajaran bersama mereka, jalin kemitraan berdasarkan kepercayaan dengan orang-orang penting di pihak mereka, dan kerjakan SELURUH proses Persyaratan resmi yang telah mereka lakukan. Anda akan berterima kasih kepada orang-orang di lapangan yang harus benar-benar menggunakan apa yang Anda kembangkan!

Anda mengasumsikan persyaratan ditulis dengan baik dan Anda pikir itu berarti apa yang mereka pikirkan. Bolak-balik dari proses tangkas akan membantu memastikan mereka mendapatkan apa yang mereka maksud selain apa yang mereka minta.