Siapa yang coba Anda buat terkesan dengan tenggat waktu Anda?

Petunjuk: jelas bukan pengguna Anda.

Angkat tangan Anda kepada mereka yang perusahaannya telah menyatakan "Orientasi Pelanggan" sebagai salah satu nilai perusahaannya. Bagi Anda yang membaca teks ini tentang Habré dan tidak melihat audiens: hampir seluruh ruangan mengangkat tangan, kecuali beberapa orang dari belakang.

Mereka bekerja di Oracle.

Kepuasan pelanggan adalah salah satu nilai perusahaan Oracle. Tetapi nilai-nilai perusahaan - mereka seperti keanggotaan gym - tidak cukup hanya memilikinya.

Obsesi pelanggan adalah hal yang bermanfaat, tetapi ada satu hal lagi yang terobsesi oleh banyak perusahaan adalah pengaturan waktu. Tenggat waktu baik. “Ini akan siap ketika saya selesai” dapat menjadi strategi yang hebat (atau bahkan direkomendasikan) untuk dua orang yang bekerja pada aplikasi yang sama. Tetapi ketika Anda bekerja di perusahaan dengan lebih dari dua ratus karyawan, Anda perlu pemahaman tentang apa yang terjadi; sebuah gagasan kasar tentang kapan pengguna Anda akan dapat menggunakan peluit dan kentut baru Anda.

Saya berani mengatakan bahwa tenggat waktu yang ditetapkan adalah tenggat waktu yang buruk, dan jika perusahaan Anda memilikinya, Anda mungkin harus melangkah lebih jauh dan menghapus item “fokus pelanggan” dari daftar nilai-nilai perusahaan. Karena, percaya atau tidak, pengguna tidak peduli dengan sprint yang berserakan.

Tenggat waktu terutama dibutuhkan bukan oleh klien, tetapi oleh manajemen.

Tujuan utamanya adalah tujuannya

Atau mengapa pembekuan persyaratan sprint adalah praktik yang mengerikan

Waktu yang baik, mereka menciptakan rasa urgensi, memastikan diprediksi proses Anda, dan karena itu Anda harus memilikinya.

Tapi ada istilah baik dan buruk. Dan ada perusahaan di mana tenggat waktu ditetapkan, dan mereka yang memenuhi tenggat waktu satu langkah sejak pemecatan. Dan kemudian masalahnya dimulai.

Saya berbicara tentang budaya pembangunan di mana biasanya membekukan tujuan selama sprint: ketika semua orang berkumpul di awal, mereka mengevaluasi tugas, tentu saja hanya menggunakan angka Fibonacci, dan apa pun yang akan diputuskan pada pertemuan ini, semua ini harus dilakukan sebelum penyelesaian sprint - tidak ada yang berubah dan tidak ditoleransi. Secara teori, ini kedengarannya luar biasa, tetapi saya pikir taktik seperti itu hilang dalam skenario apa pun:

Situasi A. Misalkan pengembang mengatasi hukum Parkinson dan menutup tugas terlebih dahulu. Dalam hal ini, pengembang tidak melaporkan hal ini pada keesokan paginya, karena hei, well, dia tidak bisa mengatakan bahwa dia tidak ada hubungannya. Atau manajernya menugaskannya lebih banyak tugas dengan membekukan sprint, karena well, dia tidak bisa memiliki pengembang yang melakukannya, well, tidak ada .

Situasi B. Pengembang, menjadi pengembang, terlambat. Masalah dengan pengaturan lingkungan memakan waktu lebih lama dari yang diharapkan, dan dia tidak lagi yakin bahwa dia akan memiliki waktu untuk melakukan segalanya sebelum akhir minggu.

Apa yang dia laporkan pada pertemuan berikutnya, yang dijawab oleh manajer proyek: “Oke, aku mendengarmu. Tapi kami membuat komitmen, jadi bisakah Anda mencoba menyelesaikan semuanya tepat waktu? " Pada saat yang sama, kepala manajer memindai gambar bagaimana ia harus menjelaskan keterlambatan rilis di sinkronisasi mingguan kepada Wakil Presiden Perusahaan Pengembangan, yang, pada gilirannya, memberinya nasihat instruktif "Lakukan saja" , jadi lebih baik hanya saring dan coba lakukan.

Jadi pengembang, menjadi pengembang, pergi selama beberapa malam, atau mungkin akhir pekan, dan menyelesaikan pekerjaan tepat waktu. Dan manajernya menghargai upayanya di reli berikutnya. Sesuatu bisnis.

Atau tidak mulus? Tenggat waktu dipenuhi, dan pekerjaan itu berhasil dilakukan, tetapi preseden yang salah telah dibuat. Seorang siswa yang baru-baru ini direkrut dengan mata melotot menerima sinyal bahwa pemrosesan pada akhir pekan adalah benar .

Dan kami bahkan tidak akan membahas skenario menyedihkan ketika tenggat waktu tidak terpenuhi, tugas berjalan ke sprint berikutnya, dan manajer harus membenarkan keterlambatan pada sinkronisasi mingguan berikutnya di hadapan Wakil Presiden Pembangunan dan mendengarkan nasihat moral.

Apakah Anda melihat masalah? Tidak ada titik waktu siapa pun mengajukan pertanyaan: "Dengar, apa yang terjadi jika kita memindahkannya ke sprint berikutnya dan tidak membuat alasan untuk siapa pun? Bagaimana ini akan mempengaruhi pengguna? "

Jauh lebih sering daripada yang seharusnya, tenggat waktu adalah self-hypnosis. Dan bagaimana cara menghadapinya - juga.

Solusi yang ideal adalah dengan hanya berbicara dengan pihak yang berkepentingan - tim produk atau tim penjualan, mencari tahu dari mereka jika penundaan tersebut dapat menyebabkan hilangnya pelanggan. Dan jika ini masalahnya, maka pasti mengalokasikan jam tambahan, dan dimungkinkan untuk bekerja di akhir pekan. Dalam hal ini, siswa muda akan menerima sinyal bahwa perusahaan benar-benar peduli dengan pelanggannya, dan bukan tentang sprintnya.

Ada masalah lain dengan sprint yang membeku. Misalkan Anda menerima permintaan dari klien - untuk memperbaiki bug yang berpotensi sepele dan prioritas rendah. Pengembang akan mengatasinya dalam sehari. Tetapi Anda mengikuti proses ^TM , yang berarti tugas ditambahkan ke tumpukan tim Anda dan mungkin itu akan diingat setelah beberapa bulan. Tetapi Anda telah kehilangan kesempatan untuk menyenangkan pengguna! Anda dapat menangani hal ini dalam beberapa hari, dan memberi tahu pengguna melalui email bahwa masalahnya telah teratasi. Orang-orang mengingat momen seperti itu, dan hal-hal seperti itulah yang membuat mereka merekomendasikan produk Anda kepada teman-teman mereka.

Jangan terlalu terbawa oleh proses - karena mereka Anda dapat kehilangan tujuan Anda. ¹

Saya juga percaya bahwa pembekuan sprint atau praktik pembatasan lainnya merupakan tanda ketidakpercayaan timbal balik yang melekat dalam perusahaan, sebagai akibat dari masalah yang lebih mendasar pada tingkat budaya komunikasi, tetapi lebih banyak tentang hal itu di waktu berikutnya.

Mengapa tenggat waktu mengerikan

1. Mereka menciptakan harapan palsu, bertentangan dengan apa yang tertulis dalam nilai perusahaan Anda. Karena nilai-nilai perusahaan Anda bukan nilai - nilai Anda , nilai - nilai Anda yang sebenarnya adalah harapan dan prasangka yang tidak tertulis (baik dan buruk).
2. Orang akan mengambil jalan pintas jika Anda menempatkan mereka dalam kondisi yang sulit. Seseorang akan mendapat skor untuk ujian, seseorang tidak akan memperbarui dokumentasi. Anda mengirimkan rilis tepat waktu, tetapi berapa biayanya?
3. Tidak ada yang setuju untuk menghabiskan waktu mencari solusi baru sementara manajer berdoa untuk menyelesaikan tugas tepat waktu. Semua orang akan menulis front-end pada kerangka kerja MVC sampai seseorang di Facebook melewati batas waktu.

Jadi, bekerja tanpa tenggat waktu?

Tentu saja tidak. Tetapkan tenggat waktu, tetapi buatlah fleksibel. Seberapa fleksibel tenggat waktu Anda bisa menjadi tujuan Anda. Jika kegagalan memenuhi tenggat waktu bisa mengakibatkan hilangnya satu juta dolar, fleksibilitas Anda harus nol. Tetapi jika ini adalah fitur lain, selalu ada ruang untuk bermanuver. Anda juga dapat bereksperimen dengan metode probabilistik yang lebih kompleks untuk memperkirakan tanggal, alih-alih memainkan angka Fibonacci dengan jari Anda di langit. ²

Tapi pembekuan sprint adalah keputusan biasa.

^1. Jeff Bezos berbicara dengan baik tentang topik ini dalam sebuah surat kepada pemegang saham pada tahun 2016 . Dia menyarankan "menolak proksi antara orang-orang di dalam perusahaan."

^2. Joel Spolsky berbicara tentang metode canggih untuk memperkirakan tenggat waktu dalam artikelnya “Penjadwalan Berbasis Bukti” ( terjemahan dalam Habré ).