- hai!
- hai!
- Katakan, bagaimana rasanya melakukan dukungan teknis?
- Nah, bayangkan sebuah sepeda ... dan ia terbakar ... dan Anda membakar ... dan jalanan terbakar ... dan secara umum, Anda berada di neraka ...

(c) penulis tidak dikenal

Tidak masalah siapa Anda, seorang pemula atau manajer yang berpengalaman, masing-masing dari kita telah menghadapi situasi di mana ada banyak tugas, mereka berasal dari sumber yang berbeda dan ujungnya tidak terlihat ke tepi. Bahkan sebagai "tembakan kendali" seseorang meminta untuk melakukan semuanya kemarin. Apakah Anda mengenali diri Anda dalam paragraf ini? Maka artikel ini akan membantu Anda.

Saya akan memberi tahu Anda apa masalah utama yang saya temui dalam pekerjaan saya ketika mereka baru saja menyerahkan manajemen dukungan teknis kepada saya, kemana perginya masalah ini dan bagaimana kita hidup sekarang, setelah 3 tahun. Sederhananya, bagaimana beberapa trik dan prinsip Kanban telah membantu saya secara pribadi dan tim secara keseluruhan mengurangi beban pada spesialis.

Apa masalah sebenarnya?

Yang paling umum untuk manajemen proyek di bidang TI (dan tidak hanya):

• Daftar tugas besar
  
• manajer yang cocok;
  
• sejumlah besar sumber dari tugas-tugas ini;
  
• kegagalan untuk memenuhi tenggat waktu;
  
• kebencian sama sekali.
  

Ha, apa yang mengerikan ?! Anda mengambil tugas dan melakukannya - itu semua keajaiban dengan kelinci. Jadi ya, tapi sepertinya "kelinci kami cacat."

Tugas-tugas baru tiba setiap hari, dan masa kerja yang lama meningkat secara eksponensial. Pada setiap spesialis, jumlah tugas diukur dalam lusinan dan tidak ada akhir yang terlihat.

Setiap orang yang terlibat dalam rantai menderita, mulai dari programmer hingga klien, yang, menurut kami, sedang membasahi air mata kami (pada kenyataannya, saya percaya bahwa dia bahkan lebih buruk daripada kami, dan kami dengan tulus melakukan segala yang mungkin terjadi pada waktu itu) )

Solusi apa yang telah diambil

Secara alami, sudah jelas bagi kami bahwa ini tidak dapat lagi berlanjut dan sesuatu perlu diperbaiki. Kami menemukan kekuatan dan mulai mencari solusi.

Di bawah ini saya akan berbicara secara singkat tentang beberapa opsi "paling keren" dan satu opsi yang bagus.

Paket 7-14 hari dengan tanggal jatuh tempo terakhir

Ya, mereka bodoh, tetapi pengalaman itu bermanfaat.

Apa inti dari gagasan itu:

• untuk setiap tugas, kami menemukan berapa banyak waktu yang dibutuhkan dalam jam kerja;
  
• daftar tugas khusus diberikan untuk setiap tanggal selama 2 minggu ke depan;
  
• daftar ini dibentuk berdasarkan total waktu yang seharusnya dihabiskan, dan waktu kerja yang tersedia (kami memiliki 7 jam kerja aktual);
  
• tugas-tugas itu sendiri secara langsung ditugaskan kepada spesialis sedemikian rupa untuk sepenuhnya mengisinya dengan pekerjaan selama 7 jam.
  

Keren! Sekarang kami memiliki rencana yang jelas dan kami tahu tugas apa yang akan dilakukan kapan! Ini dia - keselamatan!

Sehari setelah kata-kata ini datang "BP manajerial".

Sedikit lirik.
Spesifikasi khusus dukungan teknis (setidaknya bersama kami) dengan banyak proyek berbeda sedemikian rupa sehingga Anda tidak pernah memiliki daftar tugas terjadwal (jaminan simpanan) untuk minggu yang akan datang. Bahkan backlog 3 hari adalah sesuatu dari kategori fantasi. Setiap saat tugas dapat terbang yang perlu dilakukan sekarang (kadang-kadang itu dibenarkan, kadang tidak, tapi ini bukan tentang itu).

Dan sekarang, apa sebenarnya yang saya maksud dengan "neraka manajerial".



Tugas yang baru dibuat dari kategori "di sini dan sekarang" benar-benar menghancurkan seluruh rencana. Anda tidak hanya harus memindahkan tugas untuk hari ini , Anda harus mengubah tugas selama 2 minggu . Itu logis, karena jika ini tidak dilakukan, maka spesialis akan mendapatkan daftar yang melebihi 7 orang / jam per hari, tetapi bagi kami dalam kasus ini itu tidak dapat diterima.

Sejumlah besar waktu dan upaya dihabiskan untuk gerakan-gerakan ini, baik mental maupun fisik.

Dari sini, setiap permintaan dari manajer dianggap "dengan permusuhan", dan tugas baru apa pun menjadi bencana.

Mungkin ini adalah keputusan "paling keren" yang kami coba kerjakan.

Membuat daftar tugas untuk spesialis berdasarkan kategori

Semesta secara relatif tepat waktu menjelaskan (bisa saja lebih awal) bahwa untuk tugas-tugas yang terus tiba itu bukan pilihan untuk mengatur waktu eksekusi tertentu dan membangun berdasarkan ini. Diterima, dipahami, ditinggalkan ini.

Tetapi Anda tidak akan menemukan daftar programer yang umum, orang yang miskin akan hilang. Hanya untuk menghindari ini, kami datang dengan sistem kategori untuk tugas (kecil, menengah, besar dan sangat besar) dan mulai mendistribusikan semuanya ke dalam kategori.

Apa inti dari gagasan itu:

• menurut perkiraan awal penilaian, kami menetapkan kategori kami untuk tugas - kecil, sedang, besar dan sangat besar;
  
• setiap kategori memiliki runtime rata-rata konstannya sendiri, sesuatu yang mirip dengan Story Points (atau mungkin memang begitu);
  
• Setiap spesialis memiliki daftar tugas masing-masing berdasarkan kombinasi kategori. Misalnya: 4 kecil + 2 sedang; 3 kecil + 1 besar; 6 kecil; 1 sangat besar, dll.
  
• dan jadi untuk 3 hari ke depan (rencana diperlukan, setidaknya yang paling bengkok).
  

Hore, akhirnya! Kawan-kawan, kita memiliki segalanya untuk-dan-dan ... Di sini, di suatu tempat di sekitar Cosmos mengisi kembali senjatanya dan mulai menembaki kita. Apa yang salah dengan keputusan ini?

1. Terlambat, kami mulai mempertahankan basis tugas-tugas tipikal untuk menyederhanakan penugasan kategori.
   
2. Saya harus mengikuti antrian di masing-masing spesialis individu (meskipun butuh waktu relatif lebih sedikit daripada memindahkan tanggal rilis beberapa kali sehari).
   
3. Masalah dengan tugas-tugas mendesak di luar giliran tidak pergi ke mana pun - mereka masih dipaksa untuk membentuk kembali daftar.
   

Tampaknya menjadi solusi yang bagus. Sedikit lebih baik daripada opsi pertama, tetapi masih juga tidak fleksibel dalam hal tugas-tugas penting dan mendesak yang muncul.

Teknik berbasis sistem ekstraksi (Kanban)

Secara kebetulan, saya mendapat satu jam webinar gratis yang ditujukan untuk Agile dan beberapa metode berdasarkan itu (tentu saja, itu adalah iklan untuk kursus). Jadi, hanya setelah bagian utama seseorang menyebutkan Kanban sebagai teknik yang mapan untuk dukungan teknis dan tidak hanya.

Terinspirasi oleh informasi baru, hari-hari membaca tentang keajaiban manajemen ini dimulai. Kami mendapat informasi, sekarang kami siap bereksperimen dengan metodologi (saat ini) yang disesuaikan untuk kami.

Apa inti dari gagasan itu:

• spesialis JANGAN memiliki antrian sendiri;
  
• semua tugas yang siap bekerja dipindahkan ke Antrian umum;
  
• dari Antrian ini, Rencana saat ini terbentuk. Rencana adalah daftar tugas yang tidak memiliki tanggal pelaksanaan akhir dan relevan pada saat ini, pada detik ini;
  
• tugas masuk ke dalam Rencana saat ini berdasarkan prioritas tersebut. Manajer (kehidupan tugas, urgensi, dll.);
  
• Rencana memiliki batasan jumlah tugas di dalamnya;
  
• semua spesialis unit melihat Rencana saat ini yang sama;
  
• setelah menyelesaikan tugas saat ini, spesialis menggambar yang tertinggi berikutnya dan seterusnya.
  

Bagus! Mereka datang dengan, mereka mengatakan kepada semua orang bagaimana melakukannya, kita lihat. Kawan, benarkah ?!

Apa hasil setelah 1,5 minggu kalender:

1. Kami telah mengurangi jumlah tugas saat ini dalam Pengembangan dari 75 menjadi 25 !!! Dan ini asalkan aliran tugas yang masuk tetap sama
   
2. Kurangi jumlah negativitas tentang waktu
   
3. Fleksibilitas dalam proses
   

Dan inilah yang segera terlihat.

Tetapi bagaimana hal itu terjadi bahwa semuanya bekerja lebih atau kurang? Pikiran saya tentang ini adalah:

• Programmer sendiri tidak lagi memilih tugas yang paling dimengerti . Sekarang manajer mengatur antrian dan memasukkan ke dalam Rencana hanya tugas yang paling penting saat ini (ini adalah poin utama).
  
• Tarikan semacam itu secara langsung mempengaruhi pengurangan negativitas di pihak manajer dan klien. Mengapa Ya, karena tidak ada tugas yang sama mendesaknya dalam satu proyek dan yang negatif kemungkinan besar memicu yang paling berharga saat ini.
  
• Fleksibilitas dan keanggunan kucing, dan terkadang ketangkasan kentang - sistem penarik memungkinkan kami untuk merespons tugas penting dan mendesak tanpa kehilangan atau membuang waktu mengubah antrian. Kami menerjemahkan tugas yang diperlukan ke dalam Rencana dan menghapus yang lebih baru dari itu (ingat pembatasan dalam Rencana?).
  

Ringkasan

Jika Anda dihadapkan dengan aliran tugas yang besar, bahkan dari satu sumber, dan tidak merasa bahwa sepeda terbakar lebih dari yang kita inginkan, maka putar mata Anda ke Kanban. Berdasarkan prinsip-prinsip metodologi ini, dapat diimplementasikan tanpa rasa sakit dalam proses bisnis saat ini.

Saat ini, kami telah menyesuaikan sistem ekstraktif dengan kebutuhan kami, menormalkan pasokan rilis. Tentu saja, "fouling" juga terjadi, tetapi setelah beberapa saat sistem mencapai norma relatif berdasarkan kemampuan saat ini.

Perlu juga dipahami bahwa Kanban tidak hanya merupakan metodologi "kering", tetapi juga sistem nilai dan prinsip yang ditujukan untuk perbaikan dan adaptasi berkelanjutan dari proses saat ini. Tidak ada batasan untuk kesempurnaan, oleh karena itu hanya maju!