🚅 👈🏼 ⛏️ Bisakah Scrum digunakan dalam outsourcing? 👭 👨‍🔬 🧕🏼

Pertanyaannya sangat kontroversial, dan saya pribadi tidak menemukan jawaban yang sederhana dan jelas untuk itu, meskipun saya sudah lama mencari dan masih mencarinya (saya masih percaya bahwa saya akan menemukan cara untuk menggunakan esensi murni scrum dan tidak ada yang lain pada proyek outsourcing). Namun demikian, kerangka itu sendiri menyediakan banyak nishtyaks, yang manfaatnya sulit untuk disangkal, jika bukan tidak mungkin. Namun, dalam pertanyaan yang menjadi hak artikel tersebut, masalah sesungguhnya terbaca di antara keduanya. Izinkan untuk bersuara.

Masalah

Scrum adalah kerangka kerja tangkas, ini melibatkan pengembangan tangkas. Pengembangan tangkas membutuhkan tenggat waktu yang fleksibel dan anggaran yang serupa. Pengembangan outsourcing, pada gilirannya, pada 95% kasus (kecuali untuk jalan buntu) melibatkan tenggat waktu yang ketat dan anggaran yang ketat. Persyaratan: “buat saya portal perusahaan dalam 3 bulan, anggarannya 3 juta. Saya membayar Anda untuk hasilnya. " Dan pelanggan benar, dia ingin melihat hasilnya. Dan manajer harus memimpin tim ke hasil ini. Tapi di sini bagaimana melakukannya dengan menggunakan scrum?

Kerangka kerja ini mengasumsikan ketidakpastian dalam waktu dan anggaran. Artinya, sudah pada tahap awal proyek, scrum itu sendiri memberi tahu Anda: "Tunggu, saya tidak bisa datang ke sini, ada tenggat waktu yang jelas dan anggaran yang nyata, Anda perlu mencari jalur kritis, merencanakan segalanya terlebih dahulu, mencari sesuatu air terjun."

Solusi untuk masalah tersebut

Langkah 1. Mulai dengan sesuatu air terjun untuk menjual layanan Anda.

Sejak kecil, ayah saya mengajari saya: "Tidak ada hitam dan putih, cari pro dan kontra di mana-mana." Ya, air terjun sudah usang, ya itu tidak terlalu cocok untuk pengembangan tangkas, tetapi memberikan pemahaman dan memungkinkan Anda untuk menghitung jalur kritis dengan mempertimbangkan semua risiko. Kemungkinan besar, jalur kritis akan tidak akurat dan bahkan penilaian pesimistis akan sangat optimis (jika Anda mengerti apa yang saya maksud), tetapi langkah ini akan memberikan pemahaman perkiraan jumlah pekerjaan untuk Anda dan pelanggan Anda.

Anda harus menghabiskan banyak waktu mengevaluasi proyek dengan pengembang. Untuk pembahasan fitur. Dan ini adalah waktu yang sangat disayangkan untuk dihabiskan, karena fitur-fiturnya masih harus dievaluasi kembali nanti, tetapi sejauh ini tanpanya, tidak ada tempat lain: jika tidak proyek tidak akan dijual dan anjing pemburu outsourcing tidak akan memutus rantai, dalam mengejar tulang berikutnya - tidak akan ada tulang.

(!) Langkah ini tidak berarti penjualan langsung, ini hanya tentang menentukan syarat "dari" dan "ke" dalam uang dan dalam istilah.

Langkah 2. Hore! Kami mengambil proyek, kami mulai mengerjakan scrum (dalam gambar dan rupa)

Proyek ini diambil. Tampaknya semua tenggat waktu ada di sana. Tugasnya jelas, baik, harus dilakukan. Waspada! Jangan terlalu cepat. Kemungkinan besar banyak hal telah berubah sejak pertama kali Anda mengevaluasi proyek. Misalnya, dapat muncul desain atau menerbangkan Wishlist baru dari pelanggan.

Saya punya saran. Coba scrum. Dari backlog produk, pilih backlog sprint, pengantin pria. Rencanakan sprint Anda dengan hati-hati dan lihat bagaimana tim menanganinya. Lakukan memo harian dalam format "Apa yang dilakukan pengembang kemarin / Apa yang dia lakukan hari ini". Dan retro di akhir sprint, untuk merangkum keberhasilan masing-masing dan keberhasilan tim secara keseluruhan. Anda akan dengan cepat melihat bagaimana KPI masing-masing pengembang tumbuh dari sprint ke sprint, bagaimana jumlah pengembalian dari QA berkurang dan bagaimana jaminan simpanan produk berkurang.

PS Jangan terburu-buru menolak keinginan pelanggan baru. Mungkin mereka masuk akal dan mereka dapat dengan aman dimasukkan ke dalam simpanan produk alih-alih beberapa fungsi lain yang ternyata tidak lagi dibutuhkan oleh bisnis pelanggan Anda (dan, oleh karena itu, pelanggan itu sendiri).

Langkah 2.1 Perkenalkan pemilik produk ke proyek

Lebih sering daripada tidak, perusahaan outsourcing hanya memiliki satu manajer proyek. Tanpa membagi menjadi scrum master dan pemilik produk, tetapi ini bukan masalah besar seperti yang terlihat pada pandangan pertama.

Misalnya, saya memiliki tester keren pada proyek, kepada siapa saya mendelegasikan 90% tanggung jawab pemilik produk (10% sisanya adalah apa yang berasal dari pelanggan, dan saya sudah memberikannya kepada kolega saya). Selain fakta bahwa ia terlibat dalam pengujian (dan ia melakukannya dengan sempurna), ia juga memelihara dan mengisi kembali simpanan, menulis dermaga, membuat aliran dan tabel entitas: ia melakukan pekerjaan yang hebat (tidak merusak inti), yang saya tidak punya waktu, karena pekerjaan di proyek lain.

Dalam pendekatan ini, ada nilai tambah besar lainnya. Untuk penguji yang berpengalaman (dan hanya ini yang bisa dipercayakan dengan kepemilikan produk) ini adalah kesempatan besar untuk tidak bosan dan bersenang-senang dengan tugas baru + untuk merasakan nilai Anda. Jangan lupa untuk menunjukkan kepercayaan pada anggota tim Anda, setidaknya karena ini adalah bagaimana Anda meningkatkan otoritas Anda juga.

PS Sekarang saya bekerja pada model seperti itu tidak pada semua proyek saya. Di suatu tempat, scrum sama sekali tidak diperlukan, karena rumit. Ini adalah proyek-proyek kecil terutama untuk jangka waktu satu bulan atau kurang.

Langkah 2.2 Ubah peringkat jam menjadi poin cerita

Bukan langkah yang paling penting, Anda bisa bekerja tanpanya, tetapi lebih sulit. Faktanya adalah ketika Anda mengevaluasi tugas dalam jam, jamnya berbeda untuk semua orang, untuk seseorang itu akan membutuhkan 6 jam untuk membuat entitas domain (tugas bersyarat), untuk seseorang 7, untuk seseorang 8. Dalam poin cerita setiap orang akan memiliki nilai yang sama = 8.

Menurut poin cerita, akan lebih mudah untuk menghitung KPI masing-masing pengembang, menyusun tinjauan kinerja, dan melacak keberhasilan proyek secara keseluruhan.

Atur dengan pengembang untuk 8 (MB 5 Juni) poin cerita per hari, rencanakan berdasarkan ini dan lihat bagaimana tugas ditutup dan proyek sedang dilaksanakan.

Jika seorang pengembang tiba-tiba menutup 8 poin cerita dalam 4 jam (5 poin cerita, menurut angka Fibonacci), jangan memuatnya dengan pegangan baru. Hargai kesepakatan Anda, hargai pekerjaannya. Sebagian dari sisa waktu "bebas" nya masih akan dihabiskan untuk mempelajari fitur berikutnya, dan mempersiapkan diri untuk besok, dan sebagian lagi untuk pengembangan diri, atau bahkan rekreasi. Kesenangan yang baik juga memotivasi bekerja dengan baik.

Langkah 3. Bekerja dengan Keren

Jangan melakukan semuanya seperti yang tertulis dalam panduan scrum atau dalam pm-standardisator lainnya. Buat keputusan secara fleksibel, dan bangun situasi. Pilih dengan hati-hati alat yang ditawarkan oleh kerangka kerja yang berbeda dan jangan ragu untuk mencoba yang baru.

Tidak perlu mengerjakan air terjun atau scrum untuk mengelola proyek dengan sukses. Perlu bekerja dengan dingin. Itu saja.

Kesimpulan

Scrum dapat digunakan, dan itu akan sangat berguna: kerangka kerja luar biasa yang menawarkan banyak alat keren untuk terus-menerus diketahui, untuk mengembangkan diri Anda dan memberikan dasar untuk pertumbuhan bagi tim, memantau kemajuan proyek dan mempertimbangkan KPI anggota tim Anda.

Namun demikian, scrum bukanlah obat mujarab, dan untuk mengatakan, misalnya, kepada pelanggan bahwa pada awalnya kami tidak tahu berapa banyak proyek yang akan Anda dapatkan dan berapa banyak waktu yang dibutuhkan dalam hal pengembangan outsourcing, kemungkinan besar tidak akan berhasil. Semuanya sama tanpa elemen air terjun.

Merasa bebas untuk menggabungkan kerangka kerja dan menggunakan alat yang Anda dan tim Anda suka, bahkan jika mereka tidak seharusnya scrum. Buat itu bekerja dengan nyaman, karena ini adalah tujuan utama dari setiap kerangka kerja. Dan bagaimana memanggilnya terserah Anda.

PS I memilikinya HMS - scrum yang dimodifikasi secara genetik.

Bisakah Scrum digunakan dalam outsourcing?