- Modernisasi perangkat lunak legacy sulit memastikan seluruh cakupan hanya dari informasi yang terlihat sebelum pekerjaan dimulai, sehingga estimasi awal harus diperlakukan bukan sebagai tenggat, melainkan sebagai acuan yang bisa disesuaikan
- Seperti perbaikan mobil, pada awalnya mungkin bisa dibuat perkiraan seperti $18,000·30 hari, tetapi setelah dibongkar dan diperiksa, kerusakan tersembunyi bisa terungkap sehingga diperlukan estimasi tambahan dan persetujuan ulang
- Dalam proyek modernisasi juga muncul kompleksitas tersembunyi, seperti kegagalan integrasi atau perilaku tak terduga; jika dipaksa tetap sesuai estimasi awal, hasilnya akan berbenturan dengan kenyataan
- Kepemimpinan yang sehat tidak bertanya “mengapa ini tidak terlihat sebelumnya”, melainkan menilai kompleksitas, solusi, trade-off, dan jalan memutar yang tersedia untuk memutuskan apakah proyek dilanjutkan atau dihentikan
- Dalam konteks yang kompleks, yang dibutuhkan bukan buku aturan tetap melainkan pengulangan coba·eksperimen·penemuan, dan pemimpin perlu menciptakan lingkungan tempat pola bisa muncul alih-alih kontrol berlebihan
Estimasi bukan tenggat, melainkan acuan pelaksanaan
- Dalam modernisasi perangkat lunak yang kompleks, memperlakukan estimasi seperti tenggat yang pasti akan berbenturan dengan realitas yang muncul saat pekerjaan benar-benar berjalan
- Estimasi awal dibuat berdasarkan informasi yang terlihat dari luar dan pengalaman, tetapi setelah pekerjaan dimulai, kompleksitas baru dapat terungkap
- “Estimasi” adalah nilai pendekatan terhadap nilai aktual, dan dalam modernisasi yang kompleks, sulit memprediksi semua hasil secara sempurna sebelum memulai
Analogi perbaikan mobil: kerusakan tak terlihat dan estimasi tambahan
- Dalam perbaikan mobil, penilai asuransi lebih dulu menyerahkan estimasi kerusakan ke bengkel, dan bengkel juga mengirimkan estimasinya sendiri ke perusahaan asuransi
- Sebagai contoh, penilai asuransi memperkirakan kerusakan sebesar $15,000
- Bengkel memperkirakan kerusakan sebesar $18,000 dan waktu perbaikan 30 hari
- Penilai asuransi dan ahli bengkel bersama-sama mengevaluasi kerusakan, lalu perbaikan dimulai setelah perusahaan asuransi menyetujui estimasi baru
- Selama perbaikan, kerusakan yang sebelumnya tidak terlihat bisa ditemukan
- Saat komponen dibongkar, kerusakan tambahan bisa muncul
- Kerusakan pada unibody frame dapat diperiksa dengan frame machine
- Perlu dicek juga apakah dampak tabrakan tidak hanya di titik benturan, tetapi merambat ke bagian belakang rangka
- Jika kerusakan tambahan memerlukan biaya $20,000 lagi, bengkel akan mengirim permintaan perbaikan tambahan ke perusahaan asuransi, dan perusahaan asuransi akan memutuskan apakah perbaikan dilanjutkan atau kendaraan dinyatakan total loss
- Menolak tambahan biaya $20,000 hanya karena estimasi awalnya $18,000 bukanlah prosedur perbaikan yang realistis
Kompleksitas tersembunyi juga muncul dalam modernisasi legacy
- Modernisasi perangkat lunak legacy termasuk dalam ranah perangkat lunak kompleks
- Estimasi awal dapat dibuat berdasarkan masalah yang tampak jelas dari luar, tetapi saat pekerjaan berjalan, lebih banyak kompleksitas akan muncul
- Seperti ditemukannya kerusakan tersembunyi atau kerusakan rangka dalam perbaikan mobil, dalam modernisasi pun bisa muncul masalah yang tidak ada dalam estimasi awal
- Dalam situasi seperti ini, langkah berikutnya perlu ditentukan melalui persetujuan tambahan dan penilaian ulang, bukan dengan terikat pada estimasi semula
Pertanyaan yang diajukan pemimpin yang baik
- Dalam lingkungan pengembangan perangkat lunak yang sehat, ketika masalah muncul, yang dilakukan bukan menyalahkan, melainkan mengajukan pertanyaan yang dibutuhkan untuk mengambil keputusan
- Seberapa kompleks masalah ini
- Opsi penyelesaiannya apa saja
- Apa trade-off dari masing-masing opsi
- Apakah ada jalan memutar atau solusi alternatif
- Sebaliknya, jika arahnya menjadi “mengapa kompleksitas ini tidak terlihat”, “mengapa butuh waktu selama ini”, atau “mengapa estimasi awal tidak terpenuhi”, tim akan terikat pada estimasi awal tersebut
- Dalam proyek modernisasi, ada yang berlanjut dan ada yang dihentikan
- Jika biaya tambahan disetujui, proyek bergerak ke tahap berikutnya, dan proses ini diulang hingga mendekati selesai
- Jika biaya melebihi nilainya, proyek bisa dihentikan
- Keputusan yang memisahkan lanjut atau berhenti tidaklah mudah, dan dapat menggunakan kerangka kerja maupun lokakarya pengambilan keputusan untuk menentukan arah
Perbedaan konteks rumit dan konteks kompleks
- Dalam Cynefin framework dari A Leader’s Framework for Decision Making, perbaikan mobil atau servis motor bisa lebih dekat ke konteks rumit (complicated context)
- Dalam perbaikan mobil, ahli mendengar situasi kecelakaan, lalu menganalisis dan menguji berbagai faktor seperti kerusakan yang tidak terlihat atau kerusakan rangka untuk menentukan tindakan terbaik
- Dalam konteks kompleks (complex context), benar atau salahnya baru dapat dinilai setelah dicoba
- Integrasi yang diperkirakan akan berhasil bisa saja gagal
- Bisa ditemukan perilaku baru yang sebelumnya tidak diketahui dan harus diakomodasi
- Modernisasi sistem legacy yang kompleks tidak memiliki jalur tetap atau buku aturan yang harus diikuti
- Modernisasi berlangsung lewat pengulangan: mencoba, bereksperimen, menemukan, menyelesaikan, lalu berpindah ke bagian berikutnya
Bola-bola sulit bukan pengecualian, melainkan kenyataan
- Jika modernisasi aplikasi berada di antara complex dan complicated, maka dibutuhkan dashboard yang tepat untuk menilai progres dan keberhasilan
- Menerapkan proses estimasi yang sederhana pada konteks kompleks sama seperti mencoba menyelesaikan semua sekrup dan mur roda dengan palu
- Perubahan tak terduga dalam proyek modernisasi adalah kenyataan
- Tidak semua hasil bisa diprediksi sebelumnya
- Seberapa pun banyak analisis awal dilakukan, model data yang sempurna tidak akan tercapai
- Hampir di setiap tahap akan muncul pembelajaran baru
- Model data perlu berubah sesuai kompleksitas yang ditemukan
- Saat estimasi berubah, yang dibutuhkan bukan kemarahan, saling menyalahkan, atau analisis yang memaksa jadwal tetap sama, melainkan mencari cara untuk terus maju
Cara budaya organisasi menangani perubahan tak terduga
- Model budaya organisasi Ron Westrum membedakan bagaimana organisasi menangani pembawa kabar perubahan tak terduga dan kegagalan
- Organisasi Power-Oriented menembak pembawa pesan, dan kegagalan berujung pada pencarian kambing hitam
- Organisasi Rule-Oriented mengabaikan pembawa kabar perubahan tak terduga, dan memperlakukan kegagalan sebagai masalah implementasi definisi
- Organisasi Performance-Oriented melatih pembawa kabar perubahan tak terduga, dan menjadikan kegagalan sebagai bahan eksplorasi
- Jika masalah yang ingin diselesaikan masih relevan dan tetap memenuhi kebutuhan bisnis, maka proyek harus dijalankan selangkah demi selangkah
- Sasaran akhir dari perangkat lunak yang dimodernisasi adalah pengguna
Ranah kompleks memerlukan pengelolaan eksperimental
- Pemimpin yang gagal mengenali ranah kompleks bisa menjadi tidak sabar ketika hasil yang dituju tidak cepat muncul
- Dalam ranah kompleks, kemampuan menoleransi kegagalan itu penting, dan kegagalan adalah unsur esensial untuk pemahaman eksperimental
- Mengendalikan organisasi secara berlebihan akan menghalangi munculnya pola yang berguna
- Pemimpin yang mencoba memaksakan keteraturan pada konteks kompleks akan gagal
- Pemimpin yang menyiapkan panggung, mundur selangkah, membiarkan pola muncul, lalu menilai pola yang diinginkan, justru bisa berhasil
1 komentar
Pendapat di Hacker News
Saya pernah mengalami masa ketika manajemen memperlakukan estimasi seperti tenggat waktu, terus mengubah spesifikasi, tetapi sama sekali tidak mau mendengar mengapa estimasi bisa berubah
Saat itu, untuk setiap hal yang tidak sepele, saya memilih reaksi seperti “rusa di depan lampu mobil”. Kalau saya berkata, “Ini sepertinya bisa jadi pekerjaan yang cukup besar. Sepertinya seseorang di tim perlu meluangkan sekitar satu jam untuk melihat apa yang sebenarnya dibutuhkan,” manajer seperti biasa akan meminta “angka kasarnya saja”. Lalu saya memberi angka yang cukup besar sampai membuat orang terlonjak dari kursinya, dan angka itu akan diingat. Setelah itu, bahkan setelah melakukan due diligence satu jam, sebisa mungkin saya tidak memberi angka lain selain angka kasar itu, lalu pada akhirnya menyelesaikannya “lebih cepat dari jadwal” sehingga terlihat bagus
Dengan manajer yang baik, strategi seperti ini sama sekali tidak diperlukan dan itu sangat menyenangkan, tetapi terhadap orang-orang yang tidak berniat mempelajari kompetensi pekerjaannya sendiri, saya jadi menanggapinya dengan cara seperti ini. Rapat juga jadi jauh lebih menyenangkan
Tim desain, tim frontend, tim backend, dan tim QA masing-masing membengkakkan estimasinya seperti itu, lalu manajer proyek menaikkan totalnya lagi 150–200%, dan account manager serta tim sales juga menambahkan 150–200% lagi sebelum menghitung biaya
Hasilnya, pemeliharaan situs web yang seharusnya cukup ditangani oleh tim khusus berisi 8–10 developer web/full-stack yang cukup baik menelan biaya hampir 1 juta dolar per bulan. Kalau tidak termasuk dukungan 24 jam, rasanya beberapa developer Rails atau Django yang hebat, atau bahkan satu orang ditambah desainer grafis paruh waktu, juga bisa melakukannya
Beberapa tahun kemudian pelanggan menyadari situasinya, dan manajemen perusahaan benar-benar mengacaukannya sehingga sekitar 100 orang kehilangan pekerjaan dan hak yang belum dibayarkan. Hari itu saya sendiri kehilangan sekitar 26 ribu dolar
Total kapasitas misalnya 40 poin, dan berubah sedikit ketika anggota tim keluar atau bergabung. Velocity adalah throughput rata-rata dilihat dari poin per orang-hari kerja
Volatility adalah seberapa banyak sprint berubah. Mengeluarkan satu tiket 5 poin lalu memasukkan tiket 3 poin dan 2 poin mungkin masih bisa diterima, tetapi kalau hal seperti itu terjadi 12 kali dalam sprint 2 minggu, sprint tidak akan selesai meskipun totalnya tetap 40 poin atau kurang
Kami mengambil snapshot sprint setiap hari untuk melihat jumlah tiket yang ditambahkan dan dihapus, dan bisa menunjukkan kepada manajer bahwa ketika volatilitas rendah kami hampir selalu selesai, tetapi ketika tinggi kami gagal terlepas dari apakah Velocity terlampaui atau tidak. Sebabnya, tidak ada waktu untuk merencanakan dengan benar dan memperjelas kebutuhan. Membuat tim produk melihat lebih jauh dari 2 minggu ke depan cukup membantu sampai batas tertentu
Engineer yang memberi estimasi terlalu dibesar-besarkan untuk pekerjaan sederhana juga lebih mungkin merupakan performer rendah. Ini mungkin berhasil terhadap orang yang tidak menilai pengiriman yang lambat atau manajer yang tidak memahami situasinya, tetapi manajer yang paham akan cepat mengetahuinya
Alih-alih satu nilai tetap, berikan juga rentang galat, seperti “3 bulan, ±4 minggu”. Kebanyakan engineer tahu bahwa estimasi mereka punya rentang galat, tetapi entah bagaimana mereka sudah terkondisikan untuk lupa mengatakannya
Dari sisi manajemen juga, besarnya rentang galat langsung menunjukkan tingkat keyakinan terhadap estimasi dan membuka diskusi tentang risiko. Percakapan seperti “Saat ini ada galat 30% ke kedua arah; penyebab terbesarnya apa, dan bisakah kita menguranginya satu per satu dengan investigasi beberapa hari?” menjadi mungkin
Sulit dipahami bahwa profesi engineering tidak bisa membicarakan risiko, probabilitas, dan interval kepercayaan dengan benar. Ini juga bukan semata-mata tanggung jawab manajer
Manajer yang belum berpengalaman, atau orang yang sementara mengisi posisi orang lain, bisa dimaklumi karena belum terbiasa dengan ketidakpastian, tetapi di luar situasi itu tidak ada alasan
Tulisan ini membahas proyek modernisasi, dan proyek seperti ini memiliki tenggat waktu yang longgar karena perangkat lunak lama tetap berjalan selama pengganti sedang dikembangkan
Ada tekanan anggaran, komitmen, dan ekspektasi pengguna terhadap fitur baru, tetapi tidak akan menjadi bencana besar jika penggantinya terlambat sehari
Sebaliknya, jika Anda meluncurkan wahana antariksa dan posisi planet sudah tidak cocok untuk gravity assist, pesawat itu tidak akan sampai ke tujuan. Jika sebuah pembuat perkakas kecil berpendapatan tahunan 100 juta dolar mendapat kontrak dari Ford untuk mengirim cetakan bagi lini produksi F150 2026 paling lambat Maret, dengan denda 20 ribu dolar per menit jika terlambat, mereka tidak bisa berkata pada Februari, “Ada kejutan, jadi kami tidak bisa.” Mereka seharusnya menandatangani hanya ketika yakin bisa melakukannya
Ford atau NASA tidak akan terkejut meskipun biaya untuk membuat perkiraan mencapai puluhan ribu dolar. Mereka memberi ECO, dan sekalipun sebuah komponen yang tampaknya bisa dibuat dengan tangan dalam 30 menit membutuhkan 3 minggu dan 8 ribu dolar, mereka tahu bahwa di dalamnya termasuk risiko tenggat waktu, tahap penerimaan, tahap inspeksi, rencana darurat, dan sebagainya
Namun di grup modernisasi OP, jika seseorang berkata, “Karena informasinya tidak lengkap, pekerjaan 30 menit untuk mengubah teks tombol bisa memakan waktu sampai 3 minggu dan 8 ribu dolar,” mereka akan langsung diusir. Estimasi optimistis diberi imbalan, estimasi pesimistis ditekan, dan estimasi yang akurat menjadi tidak penting. Akhirnya jadwal selalu tertinggal dan tidak ada yang terlalu terkejut
Ini bisa mencakup pemeliharaan seperti perubahan hardware, upgrade sistem operasi, dan penyesuaian terhadap fitur baru. Saya pernah melihat proyek yang berjalan paralel seperti ini selama lebih dari 10 tahun
Pada tahun 1505, Michelangelo memperkirakan bahwa menyelesaikan makam Pope Julius II akan memakan waktu 5 tahun
Kenyataannya memakan waktu sekitar 40 tahun karena pekerjaan sampingan kecil seperti melukis langit-langit Sistine Chapel
Karena tenggat waktu yang didasarkan pada estimasi tidak terpenuhi, cakupan proyek dipangkas besar-besaran. Sebab Pope Julius II meninggal sebelum selesai, ada permintaan perubahan dari klien Julius dan para ahli warisnya, masalah rantai pasok, negosiasi ulang kontrak, perselisihan tenaga kerja, kekurangan pekerja terampil, serta dana yang habis karena durasi yang panjang
Jadi setidaknya sejak tahun 1505, hal seperti ini sudah terjadi. Yang lucu, Paus itu bahkan tidak dimakamkan di makam tersebut
Saya belajar hal penting di awal karier. Angka yang pertama kali disampaikan akan melekat di ingatan
Sayangnya, dalam praktiknya ini sering terjadi, dan orang akan terus berkata, “Bukankah awalnya bilang X?” “Benar, tapi kita mendapat informasi baru” tidak selalu berhasil
Efek sampingnya, orang yang tahu hal ini jadi menghindari memberikan angka
Scotty: “Tentu saja, Kapten. Dengan begitu saya bisa mempertahankan reputasi sebagai pembuat keajaiban”
Misalnya hari→minggu, minggu→bulan, bulan→kuartal. Kalau suatu pekerjaan butuh sehari, saya bilang 3 minggu. Kelihatannya banyak, tapi pada akhirnya birokrasi, prosedur, dan utang teknis biasanya membuatnya selesai kira-kira selama itu
Ada bagian yang berbunyi, “Bisakah Anda membayangkan perusahaan asuransi berdebat dengan bengkel bahwa estimasi awalnya 18.000 dolar, jadi mereka tidak mau membayar tambahan 20.000 dolar? Tidak masuk akal, kan? Saya juga begitu. Untungnya dunia nyata tidak bekerja seperti itu,” tetapi di dunia asuransi hal seperti itu terjadi sepanjang waktu
Bukan hanya asuransi mobil dan rumah, asuransi kesehatan juga sama. Sering kali memang dinegosiasikan ke titik yang masuk akal, tetapi tidak selalu; nada percaya diri “dunia nyata tidak bekerja seperti itu” cukup mengejutkan
Total loss bisa saja lebih mahal, tetapi batas atasnya jelas dan klaim bisa ditutup. Perusahaan asuransi tidak suka klaim yang masih terbuka
Yang terakhir, dalam asuransi mobil juga disebut “preferred rate”, adalah kontrak payung untuk menagih jenis pekerjaan tertentu dengan tarif negosiasi tetap
Ini sangat berbeda dari estimasi yang mengikat. Estimasi yang mengikat biasanya merupakan estimasi satu kali untuk pekerjaan tertentu, di mana estimator menanggung risiko dan berjanji menyelesaikannya dengan tarif tersebut meski ternyata jauh lebih kompleks dari perkiraan
Jika memungkinkan, satu kiatnya adalah selalu mengestimasi hanya untuk cakupan tetap, dan mengecualikan unsur-unsur tak diketahui yang belum bisa diketahui
Jangan mengestimasi “implementasi fitur X”, melainkan “engine fitur X”. Jika menemukan pekerjaan tambahan, tambahkan sebagai milestone yang ditemukan, seperti “refactoring kode lama” atau “integrasi fitur X+Y”
Namun penamaan dan pemahaman ini harus naik ke level atas agar efektif. Kalau seseorang mengubah milestone “engine fitur X” menjadi “fitur X selesai” dengan estimasi yang sama, semuanya berantakan
Saya juga pernah melihat masalah terkait. Yaitu ketika leadership menganggap deadline sebagai “motivasi”. Sama seperti orang yang ingin memanaskan rumah ke 72F tetapi menyetel termostat ke 80F “supaya lebih cepat”
Suatu kali, peserta lain lupa bahwa saya, seorang engineer level rendah, diundang ke rapat leadership. Ketika seseorang mengakui bahwa sangat sulit memenuhi deadline X dan bertanya apakah perlu mengubahnya ke tanggal yang lebih realistis, seorang senior PM menjawab, “Kita tidak pernah menggeser deadline! Engineering akan menghabiskan semua waktu yang diberikan!”
Dalam kasus itu, engineering mengembalikan waktunya ketika saya meninggalkan tim tersebut
Memang benar juga bahwa banyak tim engineering menghabiskan semua waktu yang diberikan
Namun manajer seharusnya membuat organisasi siap menghadapi kelebihan waktu, bukan mengubah estimasi dan rencana menjadi deadline kaku di depan engineer. Jika menjelang waktu selesai yang diperkirakan developer bisa menjelaskan bagian mana yang memakan waktu lebih lama dan mengapa, itu seharusnya dipahami secara masuk akal
Manajer juga harus memastikan pelanggan, sales, dan manajer di atasnya tidak memperlakukan waktu selesai yang direncanakan sebagai deadline. Jika harus membuat komitmen, deadline yang berhadapan dengan pelanggan harus berada cukup jauh setelah waktu selesai yang diperkirakan
Radiator listrik pun dalam praktiknya bisa efektif. Karena tidak akan langsung mati hanya karena udara di dekat radiator sudah hangat
Setelah terlalu sering mengalami “estimasi asal tebak” berubah menjadi deadline keras, saya mendorong pendekatan No Estimates kepada para pemangku kepentingan
Awalnya tentu ada resistensi. Untuk meredakan kekhawatiran, membantu jika dijelaskan bahwa estimasi yang cukup akurat untuk dipakai secara sah dalam perencanaan sebenarnya hanya mungkin dalam dua kasus
A) Ketika pekerjaan yang tersisa hampir merupakan duplikasi dari pekerjaan sebelumnya. Misalnya memprovisioning data center kedua untuk sistem yang sama
B) Ketika tim menilai bahwa pekerjaan fitur baru yang tersisa sudah masuk kuartil terakhir, dan sudah terdefinisi dengan baik termasuk risiko tersisa yang bisa menghalangi keberhasilan
Estimasi mikro memungkinkan manajemen mikro. Tim yang sehat mencari pekerjaan dengan prioritas tertinggi berdasarkan risiko keberhasilan proyek, lalu mengerjakannya dari urutan tertinggi
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
Saya tertarik pada rumus lucu yang pernah saya lihat di HN dulu. Terlihat mewah dan keren, tetapi seperti metode estimasi lain, tidak punya validitas formal dan hanya rumus arbitrer berdasarkan pengalaman pribadi
https://news.ycombinator.com/item?id=37965582
Matematika estimasi saya: R = t × [1.1^ln(n+p) + 1.3^X]
R adalah waktu aktual yang dibutuhkan, t adalah waktu tercepat yang mungkin jika tidak perlu komunikasi, n adalah jumlah orang yang terlibat dalam proses termasuk pelanggan dan organisasi pengembangan, p adalah jarak komunikasi terpanjang dalam proyek, X adalah jumlah alat, library, atau teknik baru yang digunakan dalam proses
Misalnya proyek yang dikerjakan satu developer butuh 2 minggu (t=2), total 5 orang terlibat (n=5), ada 1 alat baru (X=1), dan jarak komunikasi terpanjang 4, maka 2×(1.1^ln(5+4) + 1.3^1) = 4,5 minggu
Jumlah X harus ditambahkan bukan hanya untuk unknown knowns, tetapi juga untuk unknown unknowns
Sayangnya, estimasi adalah negosiasi. Orang yang mengeluarkan angka lebih dulu biasanya kalah karena “muka masam”
“Berapa estimasinya?” “Saya belum tahu.” “Kira-kira saja.”
“Kalau begitu, kapan Anda menginginkannya selesai?”
Ini jebakan yang selalu menjerat manajer baru. Begitu Anda memberi jawaban, bingo. Saat itulah mereka menunjukkan “muka masam”. Mereka menarik napas lewat sela itu, memasang wajah masam, lalu berkata, “Ah, itu sama sekali tidak realistis. Dari mana angka itu berasal?” kemudian mengajukan angka beberapa kali lebih tinggi atau menyarankan pengurangan cakupan pekerjaan. Semacam, “Waduh, dalam waktu segitu, kalau beruntung dan kita memotong fitur Y dari proyek lain, yang mungkin hanya fitur X”
Apa pun yang terjadi, yang penting jangan memberikan angka lebih dulu. Seperti poker atau membeli mobil, butuh sedikit waktu untuk mendapatkan feeling-nya. Waktu adalah uang bahkan di perusahaan besar, dan harus diperlakukan begitu. Ini permainan zero-sum
Di tempat saya bekerja, atas nama efisiensi, estimasi terus diturunkan, dan pekerjaan yang dibawa ke periode berikutnya juga tidak diperbolehkan
Saya menjalani kondisi yang hampir seperti crunch selama lebih dari setahun tanpa waktu pemulihan. Saya terus berharap keadaan membaik, tetapi rasanya malah semakin buruk. Selain itu, semua orang terus dirotasi ke area produk yang berbeda, tanpa pilihan. Saya masih terus berjalan, tetapi secara mental rasanya benar-benar habis terkuras