Lantas, kenapa tidak ada produksi baru? Dimana kemenangan dalam kompetisi? Apa maksud Anda dua bulan berjalan dan mengumpulkan kertas? Kreativitas apa lagi? Dan mengapa Anda tidak punya waktu untuk itu? Sekretaris lain apa yang harus Anda pekerjakan? Apa maksudmu "Aku pergi"? Apakah Anda benar-benar berpikir Anda bisa mengatasinya tanpa kami? Semoga beruntung.
Sesuatu seperti ini menggambarkan seorang pemimpin yang sangat baik dari kehidupan kelompok tari yang sangat baik "di bawah sayap" sebuah lembaga negara, ketika dia menjelaskan mengapa dia pergi "dari bawah sayap."
Kasusnya tenggelam ke dalam jiwa, tk. Saya baru saja melakukan percobaan (sekali lagi) untuk menyingkirkan orang-orang kreatif lainnya - pemrogram - dari non-inti, tetapi “pekerjaan yang begitu penting, perlu, dan wajib” - tepat waktu.
Apa yang terjadi jika?
Saya telah melakukan percobaan ini beberapa kali, di perusahaan yang berbeda - baik pada proyek, dan pada pengembangan, dan pada pemrogram pabrik, dan pada penyediaan layanan revisi. Percaya atau tidak, hasilnya selalu sama.
Jika programmer berhenti mengkhawatirkan tenggat waktu dan hanya menyelesaikan masalah, satu demi satu, tanpa gangguan, maka produktivitas akan berlipat ganda. Karenanya, jika Anda mengaktifkan kembali mode "menangkap tepat waktu", koefisiennya persis sama - dua kali, hanya produktivitas kali ini yang dibagi dengannya.
Nah, dan yang terpenting: programmer masih belum mencapai tenggat waktu, demi nyawa saya. Dan jika ya, maka hanya kadang-kadang, secara tidak sengaja. Atau dengan biaya produktivitas yang berkurang.
Semuanya sangat sederhana di sini. Saya tidak akan membuktikan aksioma bahwa seorang programmer tidak pernah tahu persis berapa lama waktu yang dibutuhkan untuk menyelesaikan suatu masalah - ada banyak artikel dan buku tentang topik ini. Jika Anda bekerja sebagai programmer, maka bukti tidak diperlukan. Tentu saja ada pengecualian - tugas serupa dan berulang - tetapi ini adalah pengecualian.
Sebagian besar pekerjaan kami berisi begitu banyak hal yang tidak diketahui yang terus berubah, kilas balik terus-menerus dari tugas-tugas lama, kejutan dari subkontraktor dan memperbarui dependensi, kesalahan desain, dll.
Bagaimana Anda berencana melakukan pekerjaan ini? Pada dasarnya ada empat pendekatan - fantasi, cadangan, volume, dan aliran.
Metode "perencanaan"
Fantasi adalah penerapan metode perencanaan produksi batch untuk pekerjaan programmer. Misalnya, Lean atau MRP. Pendekatan ini digunakan oleh semua "manajer klasik", terutama kasta mereka yang terpisah - "manajer". Anda hanya perlu memeras biaya tenaga kerja yang direncanakan dari programmer, mengabaikan semua teriakannya seperti "Sial, saya bahkan tidak tahu apa yang akan saya hadapi di sana," dan menggambar sosis yang indah di diagram Gantt. Dan menggambar ulang setiap hari.
Cadangan adalah pendekatan seperti teori kendala, ketika bagian kuda hanya ditambahkan ke biaya tenaga kerja yang direncanakan, untuk berjaga-jaga. Sosok yang dihasilkan juga digambar sebagai sosis pada bagan Gantt. Ini lebih jarang digambar ulang, tetapi hampir selalu.
Volume adalah ketika bukan kerangka waktu untuk memecahkan masalah yang direncanakan, tetapi produktivitas. Misalnya, pendekatan ini digunakan di Scrum - mengetahui perkiraan kecepatan kerja tim (dalam poin cerita), Anda dapat merencanakan jumlah pekerjaan per sprint (dalam SP yang sama). Karenanya, semua tugas sprint memiliki tanggal jatuh tempo yang sama.
Arus hanya terjadi saat ada kecepatan. Tugas berbaris, programmer duduk dan menyelesaikan satu per satu. Tanggal tidak diketahui, tetapi mereka dapat dihitung - mengetahui kecepatan dan jumlah tugas dalam antrian. Hal utama adalah tidak membingungkan programmer itu sendiri dengan perhitungan istilah.
Pro dan kontra
Tidak ada gunanya mendiskusikan pendekatan fantasi - itu tidak berhasil. Tidak hanya itu - ini juga menciptakan stres yang terus-menerus dan liar dan pekerjaan perencanaan ulang yang konyol. Anda dapat hidup jika orang lain tidak terlibat dalam perencanaan ulang, tetapi ini jarang terjadi. Biasanya pemrogram hanya diminta setiap hari dengan pertanyaan seperti "beri tahu saya tenggat waktunya", "kapan Anda akan menyelesaikan tugas ini?" atau "semua tenggat waktu telah berlalu, apakah Anda akan bekerja atau tidak?" Dengan cara yang alami dan harmonis, programmer memiliki cadangan waktu, bahkan jika dia tidak tahu apa-apa tentang teknik yang modis.
Cadangan waktu menyelamatkan Anda dari kerumitan, tetapi mengurangi produktivitas, karena tindakan hukum Parkinson - pekerjaan membutuhkan waktu yang dialokasikan untuk itu. Dalam beberapa situasi, pendekatan ini cocok untuk semua orang - misalnya, untuk programmer pabrik. Benar, sampai programmer mengundurkan diri, kemudian, sebagai suatu peraturan, dia menyadari bahwa kecepatan kerjanya lebih rendah dari persyaratan pasar.
Tenggat waktu terpenuhi, sejak cadangan waktu bisa ribuan persen dari biaya tenaga kerja riil. Jika bisnis atau prosesnya disusun sedemikian rupa sehingga key indicator tepat waktu, maka metode reservasi waktu sangat cocok.
Metode massal seperti Scrum secara kasar dapat menggandakan produktivitas Anda karena kurangi pengaruh hukum Parkinson dan fokuslah pada produktivitas yang kurang lebih nyata, bukan fantasi dan cadangan waktu. Namun, sprint masih merupakan tenggat waktu, sehingga Hukum Parkinson terus berlaku, begitu pula reservasi waktu dan upaya untuk memanipulasi poin cerita. Orang adalah orang - baik pemrogram maupun manajer. Programmer ingin menjadi karyawan yang baik. Dan para manajer begitu terbiasa menganggap karyawan yang baik hanya mereka yang "memenuhi tenggat waktu" sehingga setidaknya ada perhitungan di kepala mereka. Semua ini hanya akan disebut berbeda - seperti "semua tugas backlog harus dilakukan dalam sprint, dan tidak ada yang perlu difasilitasi di sini." Dan mereka akan memunculkan beberapa KPI lain untuk bisnis ini, karena imajinasinya tidak kaya.
Tidak ada masalah seperti itu di arus, sejak itu tidak ada alasan bagi mereka - perencanaan pekerjaan pemrogram dan upaya, dengan satu atau lain cara, untuk memperkirakan waktu pekerjaan. Aliran melindungi esensi dari pekerjaan programmer - kreativitas. Saya ingin, tentu saja, mengatakan bahwa aliran adalah kreativitas murni, tetapi ini tidak terjadi. Namun, kemurniannya jauh lebih tinggi. Dan produktivitas menjadi dua kali lipat lebih banyak dari Scrum.
Yang menarik: perlindungan pemrogram, atau pelaksana pekerjaan mana pun, tergabung dalam salah satu metode di atas. Tetapi ketika diterapkan pada programmer, perlindungan selalu dilupakan.
Apa dasar dari metode apa pun
Misalnya, Lean, anehnya, juga didasarkan pada gagasan aliran, sejak ditemukan di jalur perakitan. Idenya adalah mengatur pekerjaan serata dan serasi mungkin. Sehingga setiap pemain dalam rangkaian, di satu sisi, selalu ada hubungannya, dan di sisi lain, sehingga tidak ada antrian di depannya. Hanya ruang kepala minimum yang dibutuhkan. Bagi seorang programmer, ini adalah satu tugas. Cobalah untuk memberikan ide ini kepada seorang manajer yang ahli Lean - dia bahkan tidak akan mengerti tentang apa itu, karena Melewati bagian tentang melindungi pemain saat saya membaca artikel Wikipedia tentang Lean Manufacturing.
Dalam Theory of Constraints, yaitu tentang cadangan, proteksi tautan pelaksana umumnya merupakan postulat dasar. Di mana programmer duduk, mereka hampir selalu menjadi hambatan. Apa yang dikatakan CBT tentang kemacetan? Benar - dia harus dilindungi. Hapus semua beban kerja non-inti (termasuk menjadwalkan pekerjaan Anda sendiri), hindari waktu henti, dan jangan membebani otak Anda dengan pertanyaan dan rapat bodoh. Atur aliran pekerjaan dengan kecepatan saat kemacetan bekerja. Nah, para manajer-ahli TOC, akui saja - apakah Anda sudah lama berpikir tentang bagaimana melindungi programmer dari segala macam omong kosong?
Scrum adalah tentang aliran. Di sana, prinsip "jangan mengganggu orang untuk bekerja" diangkat menjadi absolut, dan dinyatakan dalam persyaratan otonomi tim yang maksimal selama sprint. Setelah - silakan datang, lihat apa yang terjadi, pilih tugas untuk balapan berikutnya, lihat-lihat di kamar mandi. Selama sprint, jangan bernapas di dekatnya. Siapa yang bekerja di Scrum - apa yang Anda katakan? Tidak ada yang menyentuh Anda selama sprint, ya?
Total
Di mana pun Anda meludah, di mana pun Anda membutuhkan aliran. Bagi programmer untuk duduk dan memprogram. Saya tidak menghitung tenggat waktu, tidak berfantasi tentang biaya tenaga kerja, tidak mengatur ulang prioritas ratusan kali, tidak menghadiri rapat, tidak berpartisipasi dalam korespondensi dan obrolan konyol.
Namun, kemanapun Anda meludah, tidak ada aliran kemana-mana. Pendekatan mana pun yang digunakan, manajer, atau klien, atau orang bodoh akan menemukan alasan untuk merebut programmer dari aliran kreatif yang harmonis demi beberapa hal yang sangat tidak masuk akal.
Anda selalu dapat kembali ke arus. Atau kembali. Perlu, bagaimanapun, kemauan - dan kembali, dan dukungan. Rasa gatal karena terus memantau pekerjaan programmer tidak berhenti. Terutama mereka yang tidak mengerti apapun dalam pekerjaan seorang programmer.