Get best of the week

Kami menetapkan tujuan pengembangan (dalam perusahaan berdarah dan tidak hanya)

Seorang pria muda bergegas ke rumah sakit:
- Dokter, mengebiri saya, segera!
- ???
- Mendesak, dokter, tidak ada waktu untuk menjelaskan!
Dokter melakukan pengebirian. Keesokan paginya, pria itu datang untuk dirinya sendiri dari anestesi, dia ditanya ada apa, sebenarnya?
- Anda tahu, saya akan menikahi seorang Yahudi, mereka memiliki agama seperti itu.
- Jadi mungkin Anda perlu disunat?
- Apa yang aku bilang? !!!
Sebagian besar masalah timbul karena kesalahpahaman. Anda mengatur tugas untuk bawahan atau sekutu, dan kemudian bersumpah, karena orang melakukan kesalahan, salah, karena mereka salah paham dengan Anda. Menghadapi ini? Jika Anda seorang manajer dan menyelesaikan masalah adalah bagian dari tanggung jawab Anda, maka Anda mungkin tahu bahwa eksekusi yang salah adalah kesalahan Anda, bukan kesalahan pelaksana.

Catatan itu berisi kerangka pertanyaan, jawaban yang harus ditulis dalam tugas jika Anda seorang pengambil masalah. Jika Anda seorang pemain, maka jawaban untuk pertanyaan ini akan membantu Anda lebih memahami tugas. Untuk sebagian besar pertanyaan, contoh-contoh praktis telah dikumpulkan, negatif dan positif.


Seringkali alasan untuk masalah adalah bahwa tugas ditetapkan dalam hal "apa yang perlu dilakukan", dan bukan "hasil seperti apa yang perlu Anda dapatkan" dan "mengapa hasil ini diperlukan".

Untuk memahami kemungkinan, biaya tenaga kerja, dan tenggat waktu, pelaku akan mengajukan banyak pertanyaan berbeda kepada Anda (terutama jika ia tidak berada dalam subjek). Korespondensi akan memakan waktu, dan karena itu uang. Anda dapat mempercepat tugas jika Anda merumuskan apa yang perlu dilakukan secara lebih rinci. Tapi apa sebenarnya yang perlu dikerahkan? Tidak semua manajer tugas memahami hal ini.

Ada berbagai jenis tugas.

Tugas untuk memperbaiki cacat yang diketahui bagaimana kesalahan seharusnya dan apa yang dimanifestasikan tidak dipertimbangkan dalam artikel ini.

Dalam artikel kami akan menganalisis tugas untuk perubahan, termasuk pekerjaan dalam kerangka proyek, peningkatan sistem, organisasi dan tugas-tugas non-standar lainnya (tugas-tugas seperti "memecahkan masalah" akan tetap berada di luar ruang lingkup, mereka akan dibahas dalam artikel berikutnya), mempertimbangkan kerangka kerja pernyataan masalah dan memberikan contoh. Kerangka kerja ini disintesis dari berbagai metodologi dan kerangka kerja.

Kontraktor dapat melakukan tugas sendiri, tetapi dapat mengelola tim artis (misalnya, pengembang).

Tugas mungkin spesifik.

Tantangan pengembangan perangkat lunak membutuhkan jawaban atas sejumlah pertanyaan tambahan. Kami tidak akan fokus pada tugas tertentu dan akan mempertimbangkan masalah umum yang terkait dengan proses perubahan.

Mengapa artikel untuk penulis?
, , , .

Kerangka pernyataan masalah


Tidak semua poin perlu dijelaskan, tidak untuk setiap tugas, tidak untuk setiap pemain. Sejumlah poin bisa diperbaiki dalam regulasi

Isi tugas


  1. Istilah dan singkatan
  2. Apa yang harus dilakukan
  3. Untuk apa

    1. Tingkat Tugas (Root / Subtask)
    2. (Untuk subtugas) Sebagai bagian dari proyek. Apa subtugas (Tugas apa yang Anda selesaikan, dalam kerangka yang Anda tetapkan subtugas ini)
    3. (Untuk tugas root) Efek bisnis
    4. (Untuk tugas root) Akan dicapai dengan cara ini
    5. (Untuk tugas root), efek bisnis akan diukur dengan cara ini
    6. Alasan untuk keyakinan bahwa tugas ini akan memungkinkan Anda untuk mendapatkan efek bisnis
    7. Jika tugas tidak dilakukan, maka (perusahaan akan kehilangan / tidak menerima ini, dalam kasus ini dan itu timbul maka ...)
    8. . () / … ( ). -
    9. ( ). .



    1. - (),
    2. ( )
    3. ,
    4. , . , ( ). , . /
    5. , , ( )
    6. ,
    7. … ..



    1. , -. . - …



  1. ,
  2. ( ),
  3. ( -).
  4. /
  5. /

    1. ( )
    2. , / , ,
    3. - - ( )
    4. -, ( )
    5. , -
    6. / ()
    7. /


    1. / / .
    2. / ( )
    3. , , , .
    4. ( )

  7. ( )

  8. (, ) ( ),
  9. ( ) ( )
  10. , ( )

    2. ?
    3. ?
    4. Apa yang harus dilakukan dalam kasus ini untuk yang tidak kritis?

  11. Bagaimana rollback akan dibuat (untuk perubahan)

Persyaratan pelanggan (sumber daya, informasi, kredensial)


Itu diisi oleh kontraktor saat memproses tugas.

Latar Belakang


Gambaran singkat dari beberapa konsep
?

SMART , , , .

megaplan.ru/letters/how-to-set-tasks , (, ).

“ ” (https://habr.com/ru/post/475284/) .

TOTE ( habr.com/ru/post/339556) , .

Agile ([5]) — “” “ ”, , ( ).

INVEST SMART, - .

, , , .

, . ( [7])

  • Independent (). , .
  • Negotiable (). , . , .
  • Valuable (, ). . , , .
  • Estimable ( ). “ , ” .
  • Small (). 1-2 , . .
  • Testable ( ). .

agile[6]:

  1. , , . , , , , , .
  2. , . , , - , , .
  3. , , , ( ).

user story, : product owner, , . .

- , , , . , . , user story?

, ( ).

Deskripsi bingkai utama


Isi tugas


Apa yang harus dilakukan


Apa yang perlu dilakukan = daftar pekerjaan yang perlu dilakukan sebagai bagian dari tugas. Jika Anda menambahkan artis dan tenggat waktu, Anda mendapatkan rencana untuk menyelesaikan masalah. Seringkali ini mengakhiri produksi.

"Lakukan," tulis manajer itu. Berdasarkan pengalaman pribadi, ini adalah hal pertama yang terlintas dalam pikiran ketika ada keinginan untuk menetapkan tugas. Kami menuliskan apa yang perlu dilakukan, dan nanti kami akan kembali ke titik ini untuk mengklarifikasi atau menulis ulang, jika perlu.

"Buat aku dikebiri."

Mungkin daftar lengkap dari apa yang perlu dilakukan tidak jelas dan kemudian hanya langkah-langkah pertama untuk solusi yang ditunjukkan. Tetapi dalam hal ini, sehingga tidak ada kesalahpahaman, ada baiknya membuat catatan tambahan “mengidentifikasi dan mengambil langkah selanjutnya ini dan itu”.

Deskripsi harus didasarkan pada istilah dan singkatan yang umum digunakan. Kalau tidak, ada baiknya membuat ayat "Ketentuan dan konsep".

Untuk apa


Pertama-tama, poin "Mengapa" diperlukan untuk menjelaskan kepada pemain pengaturan tujuan Anda, sehingga, memulai tugas, ia dapat menganalisis daftar karya dari "Apa yang harus dilakukan" dan memeriksa mereka untuk kecukupan dan kelengkapan serta dapat lebih memahami tujuan apa yang ingin Anda capai.

Tugas "Membuat saya dikebiri, karena saya akan menikahi seorang Yahudi, dan mereka memiliki kebiasaan seperti itu", seorang dokter yang kompeten akan mengajukan pertanyaan tentang kecukupan kata-kata dan mencegah bencana.

Kedua, deskripsi harus memberikan pemahaman tentang prioritas tugas khusus ini.
Bayangkan diri Anda dalam peran seorang seniman yang “banyak tugas.” Tugas apa yang harus dia ambil pertama, bagaimana memprioritaskan tugas? Jika Anda pemimpinnya, Anda dapat menunjukkan prioritas secara langsung, tetapi bagaimana jika tidak?

Kontraktor mungkin memiliki hak untuk memutuskan apa yang harus dilakukan di tempat pertama dan apa yang akan pergi nanti. Dalam hal ini, ia bertanggung jawab atas kebenaran pilihan semacam itu.

Dalam kerangka usaha berdarah, terjadi prioritas yang dilakukan atas dasar "situasi operasional" atau apa yang dibutuhkan saat ini, yang berteriak lebih keras. Hal ini juga dapat berubah menjadi "Aku adalah kamu, kamu adalah aku" atau "mari kita berteman dengan itu," tetapi dalam menghadapi CEO lebih baik menggunakan metode prioritas lain.

Opsi untuk menentukan antrian run
. .

, , , (, , , , ).

. -.

, , , , , , (. [3]), - ( , , ).

.

— . .

Tingkat Tugas (Root / Subtask)

Tugas adalah peristiwa khusus yang memiliki tujuan SMART dan batas-batas apa yang perlu dilakukan.

Contoh tugas dengan sasaran tidak jelas: Meningkatkan penjualan di kuartal pertama (meningkat sebesar 1 gosokan = menyelesaikan masalah?).

Tugas root ditujukan untuk secara langsung mendapatkan efek akhir (dengan cara lain - tugas tingkat pertama). Efeknya mungkin atau mungkin tidak diungkapkan dalam metrik bisnis.

Contoh tugas root

  • “”.
  • ( - ).
  • .
  • .
  • .
  • .


Jika hasil tugas secara langsung mempengaruhi indikator bisnis, maka Anda perlu menentukan tingkat tugas "tugas root" .

Seringkali, menyelesaikan akar permasalahan membutuhkan bantuan karyawan lain. Dalam hal ini, untuk menyelesaikan masalah, hierarki subtugas dibentuk.
Jika hasil tugas diperlukan untuk menyelesaikan beberapa masalah root, maka Anda perlu menentukan level "subtugas" .

Tugas / proyek dan mengapa Anda perlu tugas ini (untuk subtugas)

Jika Anda mengatur subtugas dalam kerangka masalah tingkat pertama yang Anda selesaikan, maka Anda perlu menunjukkan tugas mana yang Anda selesaikan ini.

Jika tugas dilakukan dalam kerangka kerja proyek dan ada prioritas lintas sektor untuk proyek, maka menentukan proyek memungkinkan pusat kerja untuk menyelesaikan tugas dalam urutan yang benar.

Jika Anda seorang pemain dan menggunakan kerangka kerja formulasi untuk mengetahui parameter tugas, Anda dapat bertanya kepada Anda: "Mengapa kita membutuhkan tugas ini, bagaimana Anda akan menggunakan hasilnya? Saya perlu tahu ini untuk lebih memahami bagaimana melakukan tugas itu. "

Setelah menerima jawabannya, teknisi 5Why merekomendasikan untuk masuk lebih dalam dan lebih dalam ke penetapan tujuan: "Dan mengapa Anda membutuhkan ini" dan seterusnya 5 kali.

Bayangkan sebuah percakapan di toko barang olahraga
: ” ”
: “ ?” (1 why)
: “ ”
: “ ?” (2 why)
: “ ”
: “ ?” (3 why)
: “ ”
: “ ?” (4 why)
: “ , , ”

Pada kenyataannya, setelah yang kedua mengapa, task manager mulai menjadi sangat gugup.

Pertanyaan yang dapat ditanyakan: “Saya mengerti mengapa Anda membutuhkannya, (Anda dapat mengulangi pengertian Anda mengapa). Pilih apa yang akan kita lakukan selanjutnya: beralih untuk membahas detail tugas ini, atau saya dapat membantu menemukan alternatif yang lebih sederhana untuk menyelesaikan tugas. "

Toko perlengkapan olahraga, dobel 2
1
: ” ”
: “ ?” (1 why)
: “ ”
: “ , , . ”
: “ ”
: “, : , ?”
….

2

: ” ”
: “ ?” (1 why)
: “ ”
: “ , , . ”
: “ ”
: “ , : , ?” (2 why)
: “ , ”
: “ . ( ). , . , , .”
: “ ”

Jadikan aku pengebirian, aku akan menikah dengan seorang Yahudi.

Efek bisnis (untuk tugas root)

Apa pengaruh bisnis dari tugas itu, akankah kita mengukurnya dan bagaimana.

Contoh indikator bisnis
-

  • :
  • ( - ):
  • :

-
  • :
  • :
  • :
  • : HR


Jika dampak tugas pada indikator bisnis sulit untuk dievaluasi (misalnya, ini merupakan peningkatan dalam kegunaan antarmuka operator yang tidak mengarah pada pemrosesan pesanan yang lebih cepat), maka ada baiknya menunjukkan mengapa tugas itu penting bagi konsumennya.

Dekomposisi solusi untuk masalah atau bagaimana Anda berencana untuk menggunakan hasil tugas

Tugas yang sulit (misalnya, tugas integrasi aplikasi) perlu didiskusikan dengan pemain - untuk mengembangkan dekomposisi tugas (tugas) Anda menjadi tugas pemain.

Tetapi kebetulan pemain tersebut diberikan tugas tanpa menjelaskan bagaimana Anda berencana menggunakan hasil karyanya untuk menyelesaikan masalah Anda.

Seringkali ini mengarah pada masalah: hasil tugas tidak dapat digunakan di masa depan, yang menyebabkan hilangnya waktu atau "tongkat" yang harus diulang.

Contoh
— .
— . ?
— .
— , .
— , .
— . . ?
— .
— + , , — . ?
— .


Mengapa ini untuk klien (konsumen)

Siapa konsumen tugas itu? Mengapa ini untuk konsumen?
Mengapa suami yang disunat penting bagi pengantin wanita dari lelucon?

Jika tugas menyangkut klien, maka Anda harus menunjukkan mengapa ini untuk klien.

Itu terjadi bahwa perubahan sistem memperburuk pengalaman klien berinteraksi dengan Anda. Ini disebabkan oleh keinginan beberapa manajer untuk optimalisasi lokal, terutama jika para pemimpin ini tidak berinteraksi dengan klien secara langsung.
Contoh 1. Tugas dari ahli logistik (menjual elektronik).
“ , ”.

, - - . , .

Contoh 2. Tugas dari manajer pemasaran.

“ -, , .”

, .

Contoh 3. Tugas dari direktur keuangan.

“ , ”.

. , 6, ( ), . .

, .
, ? ?

Kasus penggunaan di masa depan

Sebagai karakter utama akan menggunakan hasil tugas yang diselesaikan. Untuk apa use case di masa depan?

Sangat penting untuk menunjukkan apakah aktor utama dalam skenario adalah klien Anda.

Contoh. Pembayaran melalui kode QR
: QR- . - - -.

: QR-.

: QR- , -.

. ? .

1 (20% ). , .

2 (80% ). , (!!!), , , , - .

? , ( - ), ?

, QR-? (, . deeplink). , -?(, ).

Jika tidak dilakukan

Tunjukkan apa yang akan terjadi (atau apa yang tidak, lihat “Decartes Square Decision Making”) jika tugas tidak selesai. Ini diperlukan agar kontraktor lebih memahami tugas apa yang terbaik untuk dilakukan.

Pertanyaan tidak nyaman ini sering memberikan jawaban yang paling bisa dimengerti untuk pertanyaan "Mengapa."

Bandingkan contoh:

  • Perusahaan tidak akan menerima 0,1% dari laba, yaitu X juta rubel. per bulan.
  • Seorang karyawan (operator) akan menghabiskan rata-rata 15 menit sehari untuk input manual data pembayaran, yang biayanya 3.000 rubel perusahaan. per bulan.
  • Kegagalan untuk memperkenalkan peningkatan dalam pendaftaran fiskal elektronik cek berdasarkan FZ-54 akan menghasilkan denda perusahaan dalam jumlah pergantian ganda perusahaan.

Jika saya tidak dikebiri, saya akan menipu pengantin wanita saya yang setia dan ayahnya dan tidak akan menerima mahar yang kaya.

Kriteria kesiapan (hasil)


Ini adalah deskripsi dari hasil yang diharapkan.

Secara keseluruhan,
“ Anda perlu ini untuk mengambil keuntungan dari ini dan ini. Seharusnya, sejak ... Cara untuk memeriksa ini dan itu. "

Perlu

Hasil apa yang ingin Anda dapatkan? (Sama seperti definisi kriteria penerimaan yang dilakukan +).
Kapan Anda akan menganggap bahwa tugasnya 100% siap?

Peraturan
, , : , .

, , , , , .

Untuk

Agar kontraktor setuju dengan kriteria kesiapan atau menawarkan opsi (terbaik) yang berbeda untuk mengevaluasi pekerjaan, ia harus memahami mengapa pelanggan membutuhkan kriteria ini.

Tanpa pemahaman tentang mengapa kriteria ini atau itu sangat penting, kemungkinan pelaku akan mengabaikannya (atau mengaktifkan mode mogok Italia). Oleh karena itu, lebih baik menggambarkan kriteria berdasarkan frasa "ke".

Yg dibutuhkan

Tidak semua kriteria sama pentingnya, beberapa diperlukan = harus ada, beberapa diinginkan = nice2have (terutama untuk tugas dengan tenggat waktu). Semakin Anda membatasi para pemain dalam memilih metode implementasi, semakin besar risiko tidak terpenuhinya dan pengurangan inisiatif karyawan (atau skenario mungkin terjadi di mana pemain akan menarik Anda lebih banyak, memaksa Anda untuk memecahkan masalah, karena Anda telah membatasi itu). Untuk kriteria wajib, ada baiknya menunjukkan mengapa mereka wajib.

Contoh. Temukan pengembang 1C
HR-.

: hh.ru 1.

: 01 . , , . .

:

: 01 2 1 Middle+, . 1 .

: — 120 000 .

, 100 . , — 140 . ? ? , . : — 240 . . , .

?

: , , . ? , , , .

? , , ( ) — , . ? ? . – .

: «, , , - »
: “”.

4. . 6 ( 10-00 19-00 ), , - . Must have, .

— acceptance criteria. definition of done ( , , ):

  1. ( ).
  2. ( ).
  3. ( ).
  4. .
  5. ..

( , ? ? — ).

, HR , , , . , , . , , — . , .

, “ ” , :

: ( )

: 01 . , , . .

:

  • 01 2 1 Middle+, . 1 , .
  • — 240 . . , .
  • , , , - .
  • 6 ( 10-00 19-00 ), . Must have, , .


Metode Verifikasi


Perlu ditunjukkan jika ini tidak jelas.

Tugas mengatur pesta perusahaan Tahun Baru.
, ? ? ? ? , , , , .

, – . , , , ( ), : / ?

“, , . — . — 90% 8 ”.

Penting untuk menunjukkan kriteria kesiapan hasil, dan bukan cara untuk menyelesaikan masalah. Seringkali ini yang paling sulit, karena sangat tidak biasa untuk masuk ke sistem supersistem.

Dianjurkan untuk menunjukkan bukan negatif (sehingga sesuatu tidak terjadi), tetapi positif "begitu". Dalam kondisi sempurna.

Contoh. Paku di dinding
: .

: , , , .

: , . , .

: .

. . ? ? ? : , . . . .

:

  • — , . , .
  • , . .


Kriteria kesiapan harus dicoba dirumuskan dalam hal hasil akhir, tanpa menunjukkan bagaimana hasil ini harus diperoleh.

Contoh. Bayar di situs menggunakan kode QR
QR , QR , .

, . .

, .

, . — deeplink, QR .

Konteks


Konteks adalah beberapa deskripsi situasi seperti sekarang (Seperti apa adanya).

Jika kontraktor tidak mengetahui proses Anda saat ini, maka dia sering tidak akan mengerti apa yang sebenarnya Anda butuhkan.

  • bisnis apa
  • Bagaimana kegiatan tersebut sedang dilakukan sekarang
  • Bagaimana kegiatan yang ditinjau dilakukan oleh referensi
  • Apa yang buruk dalam situasi saat ini

Memahami Contoh
, ? , .

Contoh konteks yang kurang jelas
Wildberries, OZON, .. , ?

? ? ? ? ? . .

, , , : .

? ? ? ? . .

Jenis bisnis apa (untuk kontraktor eksternal)

Menetapkan tugas ke pelaksana eksternal, ada baiknya memberikan informasi dasar tentang apa bisnis Anda.

Kebetulan cukup menulis "Toko Pyaterochka", dan akan menjadi jelas bagi kontraktor tentang masalahnya (jika area di mana proses yang dipertimbangkan dalam tugas berlangsung dekat dengan pengalaman kontraktor).

Jika tidak, maka Anda harus menentukan kanvas bisnis (kanvas) [lihat 8]:

  1. Jenis bisnis
  2. Apa produk Anda, (produk), apa jenis produknya (pinjaman, CTP, asuransi, ...)
  3. apa spesialisasi bisnis, apa yang menjadi sorotan (UTP), apa nilainya (kami mengirimkan barang-barang berkualitas dalam waktu singkat)
  4. Siapa konsumen Anda (pelanggan ritel, distributor, toko, ...)
  5. ( , -, , , ...)
  6. (, , , , ..)
  7. ( , , ...)
  8. (, , ...) ()

, CRM
: CRM.

: .

, ? .

? :

1.

— :
— :
— : , (30%), (10%), email/ (30%), (30%)
— :
— : , -,
— :
— : ,

2

— :
— :
— :
— :
— : ,
— : ,
— : ,

1 “B2B” CRM , , , , , , .

2 “” CRM , , email, sms, web-push, , .

,

Indikasi keadaan As Is akan menunjukkan kepada pelaku apa yang perlu dilakukan, “celah” macam apa yang harus diatasi. Tergantung pada kondisi saat ini, operasi dapat sangat bervariasi.

Secara kasar: tugas mencapai omset 1 juta rubel untuk perusahaan yang memiliki omset 900 ribu rubel atau memiliki omset 100 ribu rubel adalah tugas yang sama sekali berbeda.

Indikasi siapa yang memecahkan masalah sekarang akan segera menunjukkan pelaksana utama yang memiliki informasi terbanyak mengenai tugas tersebut.

Jika analog masalah telah dipecahkan di unit tetangga atau di perusahaan referensi, ini juga layak disebut.

Contoh. Buat perhitungan waktu pengiriman
:
: -.

:
1. ERP .

2. , . , . .

.

, ( , ). . - . 10-50 .

Apa yang diatur oleh kegiatan dan dokumen apa yang menyertai kegiatan tersebut

Contohnya. Saat mengotomatiskan pemrosesan pesanan, informasi yang diperlukan seringkali dapat ditemukan dalam instruksi manajer, yang dikeluarkan saat perekrutan.

Apa yang mencegah tercapainya tujuan sekarang

Mengapa metode yang ada, dengan mempertimbangkan parameter kualitas yang diperlukan, tidak dapat mencapai tujuan yang sama.

Contoh. Buat perhitungan waktu pengiriman
: .
: -.

:

.
ERP .

1. : , .

: .

2. , , , .
: .
2-3 , .

Sebelumnya dilakukan pada tugas ..., lihat di sini

Apa yang telah dilakukan pada tugas tersebut telah dilakukan dan apakah mungkin untuk melihat hasil yang diformalkan.

Nama tugas


Setelah membuat blok "Mengapa" dan "Kriteria Kesiapan", Anda juga dapat menulis nama tugas. Itu harus pendek, luas dan standar.

Bagian organisasi dari tugas


Dalam kondisi (Hak dan pembatasan)


Paradigma dasar harus diadopsi atau diindikasikan (salah satu dari dua):
"Semua yang tidak dilarang diijinkan" atau "Semua yang tidak diizinkan dilarang".
Peraturan
. .
— “, ”.

?

—
—
—
— /.

:

— ,
— ,
—
—
— “”,

, :

  • , , , . , .
  • , , , ( ).
  • .
  • — .
  • , , — 15 /. , . , — ( — ).
  • , , /, , . , , . /, ( — ).
  • 15 , , /.
  • / , , .
  • ..


Seberapa mendesak?


Jika tugas memiliki urgensi tinggi, tunjukkan ini dan jelaskan mengapa tugas tersebut memiliki urgensi seperti itu. Misalnya, jika tugas diperlukan untuk organisasi "Black Friday", maka tunjukkan ini dan waktu ketika Black Friday datang.

Ada tenggat waktu khusus, setelah itu tugas secara objektif tidak diperlukan. Misalnya, istilah pidato di konferensi. Misalnya, jika Anda memerlukan halaman arahan untuk perusahaan periklanan, maka batas waktu untuk itu adalah waktu iklan berbayar yang tidak dapat digeser.

Untuk tugas-tugas seperti pengembangan perangkat lunak, mengapa penting untuk menentukan batas waktu hanya di mana itu sebenarnya, dan bagaimana manajemen tugas-tugas tersebut berbeda
— . , . = 90% .

.

deadline = , , . , , .

deadline, . , . , .

“ ”:

  • , — 2-3
  • “ ” =
  • (scope), must have nice2have (. “ ”)

, “ ”. , — must have nice2have. Must have . , . : must have , , , - nice2have.

Tugas yang sangat penting


Jika pelaksanaan tugas dikirim ke conveyor oleh kontraktor, maka mungkin perlu mendorong beberapa tugas lebih cepat dari biasanya.

Sorot tugas-tugas tersebut dengan label "Kontrol Khusus", yang akan memungkinkan kontraktor untuk mengatur manajemen tugas dengan cara yang berbeda, dan manajer tugas akan secara terpisah memantau tugas-tugas tersebut. Untuk setiap tugas tersebut, hubungi kontraktor dan katakan pentingnya sehingga kontraktor menunda itu. Tapi ingat - seharusnya tidak ada banyak tugas seperti itu.

Mengapa ini diperlukan dan dari mana keterlambatan dalam melakukan tugas-tugas umum berasal?
: , , , . . .

, . , , .
, , .

:

  • ,
  • ,
  • ,
  • ,
  • “ ” — , .

, , . , , .

Batas uang


Untuk tugas dengan batas pengeluaran, tentukan batas ini. Batas dapat berarti kedua tugas yang tidak perlu jika pengeluaran melampaui batas (membeli bahan lebih mahal daripada menjual produk jadi), serta alasan lainnya.

Kehadiran batas mempengaruhi ruang lingkup atau waktu.

Contohnya:

  • Anda perlu membeli hadiah ulang tahun untuk jumlah yang dikumpulkan.
  • Perbaikan ke situs Anda sendiri dapat dilakukan di antara proyek (gratis, karena daftar gaji telah dibayar).
  • Implementasi portal perusahaan dapat ditunda jika tidak ada kontraktor yang mau melakukan ini minimal.
  • Laptop cadangan dapat dibeli dengan harga terendah yang bisa Anda tunggu sebentar.
  • , ( , KPI ).

/ ( )


Jika kontraktor mungkin perlu menarik karyawan tambahan untuk menyelesaikan masalah, dan mereka kelebihan beban, ini bisa menjadi masalah.

Dalam hal ini, Anda harus menunjukkan "Putuskan sendiri" atau "Jangan mengalihkan perhatian karyawan ini dan itu".

Situasi sebaliknya: beberapa tugas harus diselesaikan dengan cemerlang, dan Anda harus menarik seorang ahli. Kemudian kami mengindikasikan "Menarik karyawan ini dan itu".

Misalnya, "Tulis artikel untuk Internet untuk situs ini dan itu, ambil informasi dari pakar ini dan itu tentang kasus ini dan itu."

Jika perusahaan dilarang menarik ahli dari luar, tetapi ini diperlukan untuk menyelesaikan tugas ini, perlu disebutkan.

Misalnya, “Temukan pengembang senior Java dengan pengalaman Hybris untuk merekrut agen perekrutan.”

Koordinasi metode pelaksanaan


Pilih satu dari tiga:

  1. Menyetujui rencana sebelum implementasi.
  2. Katakan setelah selesai.
  3. Tidak tertarik.

Mengapa ini penting? Jika Anda tidak mempercayai pelaksana, dan Anda harus menyelesaikan tugas pertama kali, maka Anda harus mencoba mencari tahu bagaimana penyelesaiannya sebelum pekerjaan dimulai. Ini akan memakan waktu, tetapi sebagai hasilnya Anda akan mendapatkan kualitas pekerjaan yang dapat diterima.

Kapan koordinasi metode eksekusi diperlukan? Dalam kasus di mana risiko kegagalan sangat besar sehingga mengancam dengan kerugian serius (misalnya, pemecatan Anda atau hilangnya kepercayaan pada kepemimpinan Anda). Anda juga perlu memikirkan untuk menentukan item ini untuk beberapa tugas kompleks yang ditugaskan kepada karyawan yang melakukannya untuk Anda untuk pertama kalinya.
(Dalam [4] item ini disebut asuransi).

“ ”
, , .

. .
? !

“ ”.
“ . , - ”.

“ ”?
“ . , ”.

“ . ? ”.


“ ”


— “ ”.
— ( “ ”). , , - .
— ?
— -.
— % , . . ? , .



— “ ”. .
— ( ). , . , ( ..) ….
— ?
— , .
— , , , , . . .
. ?
— , , .
— ?
— , .
— , “ ” , . — .

( )


Proses melakukan tugas yang panjang perlu dikontrol.

Jika tugas diajukan kepada pemain, maka seringkali di tempat pertama perlu untuk mengontrol ketersediaan kompetensi untuk menyelesaikan tugas (lihat [10]).

Jika dimungkinkan untuk memantau pelaksanaan tugas melalui pelaporan yang tersedia, ini baik-baik saja, buat catatan di kalender dan periksa (atau minta kepala departemen pelaporan untuk menyiapkan laporan dengan catatan analitik saat ini). Tetapi paling sering tidak ada pelaporan siap pakai.

Metode pengendalian pekerjaan tergantung pada metode pengorganisasian pekerjaan kontraktor dan harus diperbaiki dalam peraturan.

Cara termudah adalah mendefinisikan setidaknya satu titik kontrol berikutnya (bekerja untuk satu tugas dengan prioritas tertinggi).

Secara singkat tentang kontrol dalam berbagai opsi untuk mengelola orang dan tim
, , . , - , .

? “ ” [5] [9]. ( 100% , , . — ).

, . .

— .

:

  • ( ) kanban = . , - ( , , …), .
  • Kanban = . , “ ” . , , , ( , , ). () ( ) ( ). , .
  • (scrum, scrum ....) = . + ( ).

— - , :

  • . , . – (-).

, — , .

, , - , , . , : , , .

Ngomong-ngomong, mengapa kita perlu kontrol?

Sebuah kisah tentang bagaimana tidak perlu dari perusahaan berdarah.
- . «», . « ?», . , , , . , . , - , .

Pemantauan harus diatur sebagai bantuan dalam masalah yang tidak dapat diatasi oleh karyawan untuk menyelesaikan masalah.

Titik kontrol adalah waktu, tempat dan metode kontrol.

Tempat adalah bagaimana komunikasi akan terjadi.

  • Pergi ke kantor dan tunjukkan
  • Telepon dan laporkan
  • Obrolan dan laporkan

Peraturan tentang tempat kontrol
, . , ( / / ), .

Metode kontrol - penentuan apa yang perlu dikontrol. Paling sering itu adalah implementasi item dari rencana, jika intinya ditetapkan sebagai kontrol dari implementasi mereka. Tetapi jika tugas itu mendesak, maka dimungkinkan untuk mengontrol komposisi hasil antara untuk tugas pada waktu yang ditentukan, sehingga Anda mengerti ke mana ia bergerak. Ini lebih lama, tetapi pertama kali.

Contoh. Peluncuran promosi.
. ( ).

– . , . , .

: , ( , , ).

Bagaimana cara menentukan poin selanjutnya? Tergantung pada pilihan jenis koordinasi rencana implementasi dan metode manajemen.

Untuk tugas yang sangat penting, dikelola secara individual:

  • Jika Anda menyetujui rencana implementasi sebelum implementasi, maka pada saat kontraktor akan mempresentasikan rencana ini dan metode implementasi, Anda dapat menentukan titik kontrol.
  • Jika Anda tidak berencana untuk memeriksa metode eksekusi, maka biarkan kontraktor menunjukkan waktu dan tempat kontrol berikutnya dan tunjukkan ini.

Untuk tugas lain - ditentukan oleh peraturan.

Siapa yang memeriksa kualitas


Biasanya hal pertama yang dibakukan di perusahaan adalah kontrol kualitas.

Contohnya. Kualitas kode yang dihasilkan diperiksa oleh tester dan kadang-kadang manajer pengembangan. Kemurnian hukum dan kepatuhan perjanjian dengan perjanjian yang dicapai diperiksa oleh seorang pengacara. Ketika menyimpulkan kontrak, Anda meminta kontraktor untuk memverifikasi kontrak dengan pengacara dan pada titik kontrol berikutnya lihat komentar dari pengacara.

Anda tidak mengontrol kualitas diri Anda sendiri, tetapi dengan bantuan karyawan lain. Pusat kontrol yang khas harus dicatat dalam peraturan.

Contoh regulasi.
  • ,
  • ,
  • – .


Tetapi jika prosesnya belum ditetapkan sama sekali, atau jika tugasnya tidak khas, maka ada baiknya menunjukkan siapa yang akan mengendalikan apa.

Contoh masalah atipikal.
, .

Bagaimana jika itu salah


Contoh. Beli hadiah yang sama untuk tahun baru, jumlahnya - 2000 rubel. per anak. Dan jika 2050 rubel - apakah kita membeli?

Perlu dipertimbangkan dan ditunjukkan:

  • Berapa banyak Anda bisa mengeluarkan uang lebih
  • Berapa banyak yang bisa Anda tunda
  • Apa minimum yang bisa dilakukan (ini adalah alasan untuk rincian kriteria kesiapan yang harus dimiliki, nice2have).

Jika Anda tidak dapat mengeluarkan uang terlalu banyak, pastikan untuk melakukan semuanya dan tepat waktu dengan kualitas tinggi, maka seringkali tugas yang lebih atau kurang sulit akan gagal. Mengapa? Bias kognitif "Kesalahan perencanaan" mendorong Anda dan pelaku untuk memikirkan skenario sukses yang optimis untuk menyelesaikan tugas tanpa memikirkan kemungkinan masalah. Tetapi masalah bisa terjadi. Jika Anda memikirkannya terlebih dahulu, Anda dapat, pertama, lebih bijaksana menilai waktu dan sumber daya yang diperlukan.

Kedua, ini memungkinkan untuk merespons lebih cepat jika terjadi masalah ini. Mengapa ini mungkin?

Contohnya. Jika Anda tidak menentukan penyimpangan yang diizinkan, maka secara default, kontraktor akan lari ke Anda untuk setiap kasus ketika ada sesuatu yang melampaui batas yang ditentukan. Setiap kasus menyebabkan penundaan setidaknya karena komunikasi (Anda tidak menganggur), yang melanggar tenggat waktu.

Apa yang salah dan bagaimana bereaksi terhadapnya (dan apakah akan bereaksi)? Sebagian besar risiko adalah standar dan harus dijelaskan dalam peraturan.

Peraturan
  • ( ) . ? ? ? ? ? ? ?
  • , . ? ? ? ?
  • . . , , ? , ( , , ).
  • . ? , .. - ,


Mengapa penulis tidak menyebutkan risiko item ini
, — . , . , . .

Grup Penciptaan Solusi (Paket Solusi)


Saat mencari solusi untuk beberapa masalah, minat seseorang harus diperhitungkan. Jika demikian, maka tunjukkan daftar yang bertanggung jawab (disebut pemangku kepentingan). Jika ini tidak diketahui secara umum, tunjukkan mana dari mereka yang memiliki keahlian paling banyak.

Untuk sejumlah tugas, orang-orang ini dapat ditentukan oleh kontraktor secara independen berdasarkan proses kerja.

Tetapi kadang-kadang individu-individu ini tidak diidentifikasi secara eksplisit. Untuk menghindari situasi ketika seseorang lupa untuk meminta pendapat seseorang, Anda perlu menentukan daftar.

Contoh tugas di mana pemangku kepentingan tidak jelas
  • ,
  • ,
  • ,
  • , , .


Keinginan Penerapan


Beberapa perubahan tidak dapat dimasukkan kapan saja. Jika tidak ada peraturan, maka pembatasan ini harus ditunjukkan.

Misalnya, perubahan pada kode situs harus dilakukan ketika situs memiliki minimum pengguna untuk meminimalkan kehilangan pesanan.

Siapa dan bagaimana memberi tahu tentang keputusan tersebut


Jika peraturan tersebut tidak didefinisikan, maka ada baiknya menunjukkan kapan hasilnya.

Kebetulan orang tidak tahu, meskipun solusi untuk masalah itu menyangkut mereka. Jika ini terjadi, maka perlu disebutkan secara eksplisit.

Misalnya, perubahan peraturan tentang bekerja dengan tugas-tugas Jira menyangkut karyawan dari semua departemen yang mengatur pekerjaan mereka melalui Jira. Pada saat yang sama, karyawan harus menandatangani perubahan terhadap peraturan ini.

Pelaksana


Kontraktor adalah karyawan yang melakukan tugas. Mungkin tidak diketahui selama pernyataan masalah dan ditentukan kemudian, misalnya, jika beberapa orang dari kelompok yang sama melakukan tugas jenis ini.

Penyelenggara Penerimaan Tugas


Tugas yang diselesaikan diterima oleh karyawan, orang yang mengatur tugas. Pengambil mendapatkan apa yang diinginkannya?

Tapi di pihak siapa tanggung jawab untuk tugas itu? Kontraktor melakukan pekerjaan (menyerahkan bola?), Manajer tugas mengambil tugas untuk verifikasi (apakah dia benar-benar mengambilnya?).

Jika tugas diatur melalui pelacak tugas, yaitu bidang yang bertanggung jawab saat ini, yang menentukan di sisi mana bola berada.

Tetapi jika tidak, maka tugas itu membeku dalam waktu yang lama, terutama jika tidak ada aturan dan peraturan (yang berguna bahkan jika ada pelacak tugas).

Peraturan untuk penerimaan tugas.
— ( ), , ( “” , “”).

— ( ), , (, ), . (“” , ).

: , () .

, — ( ).

, .

Daur ulang diizinkan


Memproses karyawan harus dibayar jika majikan meminta mereka (berdasarkan undang-undang). Pada saat yang sama, karyawan dapat tetap bekerja sesuai keinginannya, tetapi apakah pemrosesan tersebut akan dibayar tergantung pada organisasi.

Proses pengolahan perlu dikelola = untuk mengalokasikan tugas yang perlu dilakukan tepat waktu, termasuk melalui pemrosesan tugas-tugas biasa yang dilakukan selama jam kerja.

Kebutuhan pelanggan


Kontraktor dapat menunjukkan apa yang dia butuhkan dari pelanggan untuk menyelesaikan tugas dengan sukses.

Singkatnya, ini membutuhkan:

  • Informasi
  • Sumber daya
  • Kredensial.

Contohnya. Untuk meluncurkan situs web toko online, pelanggan harus mempersiapkan perusahaan IT yang membuat informasi situs pada kartu produk dengan harga.

Kami tidak melukis bagian ini secara rinci.

Deskripsi proses pementasan


Bagaimana cara manajer menugaskan kontraktor?

Manajer menyelesaikan tugas atau masalah yang ditetapkan sebelumnya dengan membangun model solusi di kepalanya, menguraikan tugas menjadi sub-tugas atau menentukan sub-tugas berikutnya. Setelah itu ia memberikan tugas kepada para pelaku, mengumpulkan hasilnya, kembali mengatur tugas dan seterusnya sampai ia menyelesaikan masalah / tugas yang menjadi tanggung jawabnya. Hasil pelaksanaan tugasnya baik secara langsung mempengaruhi indikator bisnis, atau seseorang perlu meningkatkan indikator bisnis, atau dia berpikir bahwa tugas itu diperlukan, tetapi dia tidak bertanya pada dirinya sendiri mengapa.

Katakanlah manajernya adalah Anda.

Hal terpenting dalam tugas adalah memberikan bagian deskriptif kualitatif dari tugas tersebut.

  1. , . ( ). , . ( – ).
  2. . , . . . . ( – ).
  3. . , . , , ? – . , – , . ( ).
  4. « ». /.
  5. .

Tidak semua item dalam deskripsi tugas diperlukan. Kewajiban tergantung pada tugas itu sendiri dan tingkat pemain (yang kurang berpengalaman perlu menulis pernyataan yang lebih rinci). Poin yang paling penting adalah "Mengapa" dan "Kriteria kesiapan". Tapi pertama-tama, lihat daftar item untuk setiap tugas.

Apa yang harus diuraikan tergantung pada tingkat artis.

Jika pemainnya adalah Juni / pemula, maka kemungkinan besar dia tidak tahu apa dan bagaimana yang harus dilakukan untuk mencapai hasil. Bagi orang-orang seperti itu, blok Apa yang Harus Dilakukan lebih penting.

Jika kontraktor memiliki pengalaman yang cukup dan tugas dapat didelegasikan kepadanya, maka cukup baginya untuk menulis "Kriteria penerimaan" (sebagai gambar dari hasil) dan ia akan mencari cara untuk mencapai ini.

Dan untuk keduanya, blok "Mengapa" itu penting, yang memberikan penetapan tujuan dan motivasi.

Kontraktor, setelah menerima tugas, menunjukkan apa yang dia butuhkan dari pelanggan untuk menyelesaikan tugas dan ada tawar-menawar antara pelanggan dan kontraktor.

Contohnya


Di bawah ini adalah beberapa contoh. Beberapa contoh sama sekali tidak enak dilihat, tetapi semuanya didasarkan pada peristiwa nyata yang terjadi beberapa waktu lalu di perusahaan yang berbeda dengan tugas dan kinerja yang berbeda.

Kami akan menunjuk Z - pemberi tugas, dan - pelaku.

Contoh. Isi data skala untuk pemukiman


Apa yang harus dilakukan : Isi server pertempuran dengan semua nilai parameter YZOOM untuk pemukiman = 11. Untuk Moskow dan St. Petersburg, atur 9.

Mengapa: Untuk pengguna memiliki peta dengan ketersediaan barang di toko yang ditampilkan pada skala normal.
Dalam kerangka proyek Implementasi pengiriman sendiri dari toko
Jika tugas tidak dilakukan, klien melihat peta dalam pendekatan minimal (seluruh dunia), yang membuatnya sulit untuk menavigasi di ponsel dengan satu jari dan mengarah pada penurunan konversi
Kriteria penerimaan: Buka situs di kota secara default, pada “ Ketersediaan di toko ”untuk satu produk, yang hanya tersedia di satu toko, kartu terbuka sehingga pusat kota terlihat.
Tanggal untuk tugas:ganti dengan nomor X, karena saat ini semua fungsi pengiriman mandiri di situs pertempuran akan diaktifkan

Contoh 1. Transfer bug dari program Google.Docs ke Jira


Z: Ada tabel Google Documents tempat penguji memperbaiki tugas untuk memperbaiki kerusakan pada situs. Transfer tugas ini dari Google Documents ke Jira (sistem manajemen tugas baru).
Dan: Pindah. Dan apa yang harus dilakukan dengan mereka selanjutnya? Penguji mengatakan bahwa mereka tidak relevan.
Z: Maka tidak perlu untuk mentransfer
Dan: Anda mengatakan untuk mentransfer, dan saya pindah.
Z: Saya harus berpikir "mengapa saya melakukan ini". Jika Anda tidak tahu mengapa Anda melakukan sesuatu, jangan lakukan.

Moralitas. Dalam tugas ini, Anda bisa menebak kriteria kesiapan: semua tugas dari tabel didaftar sebagai tugas dalam sistem manajemen tugas yang baru. Untuk apa? Item ini tidak diindikasikan, yang menyebabkan hilangnya energi dan waktu.

Cara mengatur tugas dengan benar

Apa yang harus dilakukan:Ada tabel Google Documents tempat penguji memperbaiki tugas untuk memperbaiki cacat pada situs. Transfer tugas ini dari Google Documents ke Jira (sistem manajemen tugas baru).

Mengapa: Jira harus memiliki semua tugas mendesak untuk memperbaiki cacat yang ditemukan sebelumnya.

Kriteria penerimaan:

  • Jira telah memulai tugas koreksi cacat sesuai dengan aturan penulisan cacat baru sehingga cacat dapat diperbaiki dalam prioritas yang tepat.
  • Jira tidak memiliki cacat duplikat, sehingga tidak menciptakan konflik untuk memperbaiki cacat ..
  • Tugas baru harus relevan sehingga pengembang tidak membuang waktu.

Contoh 3. Pengembang ke pengembang


Z: Pegang tugas.

Apa yang harus dilakukan: Analisis dan perbaiki sepotong kode.

Mengapa: Menurut hasil pemantauan, sepotong kode bermasalah ditemukan. Ini sangat memperlambat pemuatan situs, membuatnya tidak stabil.

Kriteria kesiapan: Dalam sepotong kode, satu query harus dibuat ke database, yang hasilnya harus di-cache.

Dan: Saya tidak tahu harus berbuat apa. Anda dapat memperbaiki bagian kode ini dengan cara yang berbeda, mana yang harus dipilih?
Z: Pikirkan sendiri
dan saya pergi ke pimpinan U. Kami
mengumpulkan diskusi.
Dan: Masalahnya dapat diselesaikan dengan cara yang berbeda, misalnya, metode 1, metode 2, metode 3 (metode dalam bahasa pemrograman dijelaskan di bawah).
Z: Kita harus menyelesaikan masalah secepat mungkin, dengan sebuah tambalan, agar tepat waktu untuk Black Friday.
T: Baiklah, ini adalah metode 1.
Z: Dan apa pengaruh metode ini terhadap bisnis?
Dan: Ketika harga berubah, data di situs dengan harga tidak akan diperbarui dalam satu jam.
Z: Karena harga berubah pada malam hari, selama periode aktivitas pelanggan minimal, metode ini dapat diterima.

Apa yang salah: Masalahnya diidentifikasi, tetapi tidak diindikasikan apa yang harus dilakukan dengannya, bagaimana cara menyelesaikannya, pelaku diberi pilihan bagaimana melakukan tugas itu sendiri. Pada saat yang sama, tujuannya tidak cukup ditandai - untuk melakukan secepat mungkin untuk menangkap Black Friday (PE), pemain tidak dapat memilih.
Juga, solusi untuk tugas "menangkap darurat" bukanlah jenis masalah, harga kesalahan (keberhasilan seluruh perusahaan), itu terlalu tinggi. Oleh karena itu, sangat penting untuk menambahkan langkah ke kriteria penerimaan: "Setuju dengan rencana keputusan sebelum implementasi."

Black Friday datang dalam dua minggu. Tugas harus tetap di bawah kendali khusus, karena tidak ada hak untuk terlambat. Kami menambahkan "Pada kontrol khusus".

Optimalisasi sebagian besar merupakan tugas penelitian dengan jumlah pekerjaan yang tidak jelas. Penelitian perlu dibatasi dalam waktu, jadi kami menambahkan "besok jam 9:20 Anda menghubungi dan memeriksa status solusinya."

Contoh 4. Pengembang ke pengembang


Z. Tingkatkan potongan kode ini. Inilah diagnosis dari profiler
I. Peningkatan. Alih-alih 32 permintaan, 17 selesai.
Z. Seharusnya ada 0 permintaan, data harus diambil sepenuhnya dari cache

Morale. Tidak disebutkan mengapa tugas itu diperlukan, tetapi dalam konteksnya, karena tugas utama seluruh tim adalah mempercepat situs, tetapi ini tidak diperlukan. Tetapi kriteria kesiapan tidak ditunjukkan.

Kami menulis ulang

Apa yang harus dilakukan : Perbaiki kode diagnostik ini dari profiler
Mengapa : Mempercepat situs
Kriteria penerimaan : Semua permintaan harus bekerja pada cache, jika ada data dalam cache

Contoh 5. Kepala pengembang - pengembang


Z. Memahami cara kerja kode bagian ini
.
Z. Satu jam telah berlalu, di mana hasilnya?
I. Saya memecahkan masalah lain

Apa yang salah: Tanpa menunjukkan pentingnya tugas, pelaku tidak mengerti tugas mana yang lebih penting.
Ada segitiga manajemen yang terkenal: Sumber Daya - Lingkup - Waktu.

Sumber daya. Kontraktor (jika ini bukan manajer yang dapat menarik orang lain selain dirinya untuk melakukan) hanya dapat bergantung pada dirinya sendiri, sumber daya ditetapkan.

Pilihannya tetap - ruang lingkup atau waktu.

Tugas penelitian (misalnya, memahami apa yang terjadi) biasanya sulit untuk dievaluasi dengan biaya tenaga kerja, dan penelitian optimasi dapat memakan waktu berminggu-minggu (termasuk mempelajari dan menguji perpustakaan dan teknologi baru), oleh karena itu tugas penelitian perlu dikelola dengan bantuan waktu.

Karena itu tugas ini penting. Lempar semuanya dan lakukan itu, setelah kontrol satu jam.

Kami merumuskan kembali masalah:

Apa yang harus dilakukan . Memahami cara kerja sepotong kode.
Mengapa . Menurut profiler, bagian ini memperlambat pemuatan halaman oleh 7 detik, yang menghalangi peluncuran situs ke
kriteria penerimaan pertempuran . Beri tahu logika kode ini dan berikan komentar tentang cara memperbaikinya.
Prioritas (bos dapat menentukan prioritas) - Anda membatalkan semua tugas lain, karena ini adalah satu-satunya tugas yang memblokir peluncuran situs, tugas
Kontrol - Anda akan menelepon dan melaporkan apa yang Anda pelajari dalam satu jam.

Contoh 6. Menghubungkan layanan pemasaran ulang di situs


Pemilik produk menetapkan tugas.
Apa yang harus dilakukan : Hubungkan layanan pemasaran ulang untuk situs tersebut.
Mengapa : Rekomendasi akan meningkatkan penjualan melalui iklan di Internet.
Kriteria kesiapan : Di situs pertempuran di semua halaman situs ada penghitung yang membuat acara ketika semua klien membuka halaman (yang tidak memiliki pemblokir iklan).
Pelanggan : Spesialis Pemasaran Internet Langsung.

Apa yang kamu lupakan kali ini? Karena tugasnya terlihat sederhana, pengembang baru, yang tidak terlalu berpengalaman membawanya untuk bekerja dan memasukkan skrip ini ke dalam eksekusi sinkron sebelum membuka halaman situs di browser klien. Akibatnya, halaman situs mulai memuat lebih lambat selama 1,5 detik, dan ketika skrip penghitung mulai menghasilkan kesalahan, halaman berhenti dibuka sama sekali. Direktur e-commerce sangat marah.

Pemilik produk, seperti halnya pelanggan bisnis lainnya, tidak berpikir (jika bisnis memikirkannya, itu akan berfungsi buruk sebagai bisnis) tentang kecepatan dan toleransi kesalahan. Kriteria ini tidak dijabarkan dalam persyaratan, dan tidak ada persyaratan yang terdokumentasi untuk situs tersebut, dan tidak seorang pun dalam kata-kata menginstruksikan pengembang tentang hal ini.

Cara keluar dari situasi seperti itu: memformalkan persyaratan non-fungsional, dan saat proses formalisasi sedang berlangsung, adakan diskusi tentang masalah dengan pengembang dan penguji, di mana pengembang memberi tahu bagaimana ia akan melakukan tugas, dan penguji tidak lupa bertanya bagaimana metode implementasi yang diusulkan akan memengaruhi atribut kualitas ( kinerja, kecepatan, toleransi kesalahan, keamanan, dll.).

Contoh 7. Koreksi kesalahan dalam mekanisme kode promosi


Tugas: "Ada kesalahan di situs sekarang, diskon untuk kode promosi untuk berlangganan disimpulkan dengan diskon untuk penawaran khusus, perbaiki."

Masalahnya dijelaskan, tetapi apa yang perlu dilakukan tidak dijelaskan.

Setelah mengetahui dari pelanggan apa tugas itu dimaksudkan, itu ditulis ulang sebagai berikut:

Apa yang harus dilakukan:

- Untuk membuat mekanisme untuk menentukan bagaimana situs harus menerapkan promosi jika ada beberapa promosi berbeda dalam satu keranjang.
- Pertimbangkan kemungkinan untuk meringkas diskon serta kemungkinan menerapkan diskon dengan prioritas yang lebih tinggi.
- Melakukan pengujian A / B bahwa perusahaan lebih menguntungkan - untuk meringkas diskon (omset lebih tinggi, tetapi margin lebih rendah) atau meninggalkan satu diskon.

Untuk apa

Kampanye terakhir, yang berlangsung dari 1 September hingga 1 Oktober, memiliki 1.100 pesanan di mana kode promosi untuk berlangganan diterapkan dan barang dengan penawaran khusus dibeli, yang seharusnya tidak, yang mengakibatkan hilangnya X juta rubel yang bisa dicegah. Pada saat yang sama, tidak akan ada kerugian omset, karena signifikansi diskon pada penawaran khusus sudah cukup sehingga klien tidak memerlukan motivasi tambahan (ini adalah hipotesis).

Jika ini tidak dilakukan, maka perusahaan berikut (dilakukan untuk menambah jumlah pelanggan) yang direncanakan pada bulan Februari dan Juni akan memberikan kerugian yang diperkirakan sebesar XX rubel.

Kriteria penerimaan

Kemampuan untuk mengontrol bagaimana kode promosi dan promosi berinteraksi satu sama lain tanpa partisipasi programmer.

Mekanisme A / B untuk menguji opsi interaksi.

Setelah pernyataan seperti itu, menjadi jelas bagi kontraktor bahwa masalahnya tidak perlu diselesaikan, karena pada bulan April direncanakan untuk mentransfer fungsionalitas menghitung promosi ke solusi perangkat lunak yang terpusat, yang akan menurunkan nilai solusi untuk masalah ini.

Contoh tugas dari dan ke. Optimalkan ruang gudang sebesar 15%


Kami memberikan contoh deskripsi lengkap formulasi (di tempat-tempat yang berlebihan).

Konteks


Kanvas bisnis (di luar produksi, untuk pembaca)


- Distributor B2B,
- menjual aksesoris furnitur (engsel, pantograf, laci dan rak, sistem penyimpanan (dibongkar))
- merek berkualitas dari Jerman dengan mark
- up rendah - ke pelanggan grosir (distributor lokal, toko furnitur, pengrajin wiraswasta),
- melalui pesanan di situs dan melalui kontak langsung dengan manajer
- dengan pembayaran pada penjualan atau dengan angsuran (B2B)
- memiliki diskon tergantung pada jumlah transaksi dan kondisi kontrak dengan klien;
- dengan membeli dari pabrik, mengangkut dan mengimpor oleh perusahaan transportasi eksternal, bea cukai oleh pasukan eksternal, menyimpan di gudang Moskow Anda, pengiriman di Moskow dengan transportasi Anda sendiri dan ke Moskow dengan transportasi terdaftar.

Deskripsi situasi


Cara kerjanya sekarang : Ada gudang tempat barang yang berbeda disimpan di rak yang berbeda. Gudang tidak termasuk ABC.
Volume dan frekuensi operasi : 10 pengiriman per hari, satu pengiriman - dari tumit ke gazelle.
Cara kerjanya untuk referensi : gudang mereka dioptimalkan untuk berbagai jenis pergantian barang.
Apa yang diatur oleh kegiatan : (peraturan karyawan gudang dilampirkan).
Apa yang mencegah untuk mencapai tujuan sekarang : belum ada pekerjaan pada pergantian barang. Semua barang disimpan dengan setara.
Pada tugas yang dilakukan : negosiasi diadakan dengan tuan tanah, kesepakatan dicapai untuk mengurangi biaya. Analisis ABS dilakukan, yang mengungkapkan 30% barang turnover rendah.
Di mana harus melihat hasil yang diformalkan: protokol negosiasi adalah percakapan dalam aplikasi. Analisis ABS diterapkan pada tugas, artikel demi artikel.

Apa yang harus dilakukan


Dengan menyegel penyimpanan segmen C, kosongkan ruang dan siapkan mereka untuk dipindahkan ke penyewa.

Untuk apa


- Subtugas tugas adalah "Untuk mengurangi biaya dengan mengoptimalkan gudang karena analisis ABC".
- Efek bisnis akan dicapai oleh 100.000 rubel per bulan, karena pengurangan area sewa gudang.
- Justifikasi perhitungan : Analisis ABC menunjukkan adanya 30% barang dengan omset rendah. Mari kita kurangi area yang ditempati oleh barang-barang ini menjadi setengahnya karena pemadatan penyimpanan.
- Hasil diperlukan untuk mentransfer ruang yang dirilis ke lessor.
- Jika tugas tidak dilakukan, maka perusahaan akan membayar 100.000 rubel / bulan lebih, yang membuat perusahaan kurang menguntungkan
- Skenario kerja di masa depan: Pekerja gudang lebih padat menyimpan barang dengan omset paling sedikit.

Kriteria kesiapan


- Area untuk transfer dari pihak kami dikosongkan dan siap untuk dipindahkan ke lessor.
- Akta transfer yang ditandatangani dan dopnik yang ditandatangani dengan penyewa diterima sehingga kondisi baru dicatat secara hukum.
- Penurunan tarif sewa gudang tercatat 15% sehingga kami akan membayar lebih sedikit. Pengurangan persentase dihitung kira-kira, jadi dengan mengasumsikan kompaksi ganda barang segmen C. Ketika dikurangi 5%, pekerjaan itu tidak masuk akal.
- Rencana reorganisasi telah dikerjakan dan disepakati dengan mempertimbangkan rekomendasi dari ahli Semyon Semenovich, untuk memeriksa pelepasan maksimum area tersebut, asalkan produktivitas gudang tetap terjaga.

Bagian organisasi dari tugas


Pelanggan : pemilik perusahaan.
Di bawah pembatasan / dalam kondisi :
- Pembatasan moneter : biaya reorganisasi tidak boleh melebihi laba dari penurunan tarif sewa selama enam bulan.
- Batasan waktu : periode reorganisasi adalah 2 bulan, karena waktu ini harus cukup (disepakati dengan lessor untuk periode ini).
- Atraksi ext. sumber daya dapat diterima sesuai anggaran.
Koordinasi rencana
- Sebelum implementasi, koordinasikan rencana reorganisasi dengan pemilik.
- Rencanakan grup pembuatan(yang harus disepakati dengan siapa untuk memberi tahu): manajer gudang, kepala penjualan, direktur keuangan.
- Kontak grup (dikirimkan).
- Komunikasi : melalui apa yang terjadi, grup dibuat.
- Ubah status persetujuan: disetujui dengan semua.

Keinginan untuk ditempatkan : dihabiskan selama jam kerja agar tidak membayar untuk pemrosesan.
Titik kontrol berikutnya : pada pertemuan berikutnya seminggu sekali.
- Apa yang harus siap untuk titik kontrol berikutnya : barang dari kelompok C dibagi menjadi kelompok sesuai dengan ukuran dan kerapuhan, perhitungan kemungkinan pemadatan dibuat.
Cek kualitas: manajer keselamatan kebakaran, manajer perlindungan tenaga kerja.
Bagaimana kembalikan dilakukan jika ini tidak berhasil : kami akan mengembalikan semuanya. Untuk melakukan ini, rencana harus mengambil kesempatan ini.

Apa yang harus dilakukan jika salah


Apa yang bisa salah
- Durasi. Tidak penting untuk hasilnya. Apa yang akan kami lakukan: kami akan bernegosiasi dengan pemiliknya.
- Barang mungkin rusak saat bergerak. Tidak penting untuk hasilnya. Cara mencegah: menginstruksikan orang tentang merawat produk yang berharga.
- Organisasi penyimpanan yang baru dapat memblokir pengoperasian gudang. Untuk hasilnya, sangat penting, untuk mencegah hal ini, bahwa rencana reorganisasi harus disetujui dengan manajer gudang dan ahli organisasi penyimpanan yang ditemukan oleh pemilik.

Penambahan


Kriteria Ketersediaan Standar


Beberapa kriteria kesiapan dapat dilewati jika perusahaan telah mengembangkan standar untuk kriteria kesiapan untuk berbagai jenis tugas.

Contoh standar untuk kriteria ketersediaan, tergantung pada jenis tugas:

Jenis Tugas - Tugas Apa Saja


- Hasil eksekusi disepakati dengan pelanggan tugas
- Jika tenggat waktu dijanjikan untuk tugas tersebut, maka perubahan waktu disepakati dengan pelanggan tugas
- Jika tenggat waktu yang dijanjikan tidak terjawab untuk tugas tersebut, kontraktor memberi tahu pelanggan tentang tugas tersebut dan menyarankan langkah-langkah berikut untuk mencapai tujuan yang dinyatakan (Mengapa) sebanyak mungkin. lebih awal tetapi tidak lebih dari akhir hari kerja berikutnya

Jenis tugas - pengembangan perangkat lunak


- Kode program yang dimodifikasi dikerahkan (diinstal) pada server pertempuran dan tersedia untuk digunakan
- Di server pertempuran semua pengaturan yang diperlukan dibuat untuk memastikan proses bekerja dengan baik
- Penyempurnaan tidak memperburuk persyaratan sistem (non-fungsional) yang sebelumnya dibentuk (itu terungkap sedikit di bawah)
- Sebelum penyebaran dokumentasi server pendukung telah diperbarui pada server tempur
- Deskripsi singkat telah dilampirkan pada perubahan perangkat lunak yang telah berubah dan item dokumentasi dukungan yang ditunjukkan
- Dokumentasi Hari Pertama Analis dan Pengembang Hari Pertama telah diperbarui
- Perubahan integrasi disetujui dengan arsitek TI

Item tentang persyaratan non-fungsional dapat diungkapkan:

- Perangkat lunak harus nyaman (UX guideline berjalan),
- Antarmuka kerja untuk klien harus dikoordinasikan dengan pemilik produk, perancang, analis sistem,
- Antarmuka kerja untuk karyawan perusahaan (bukan ritel) harus dikoordinasikan dengan kepala karyawan,
- Antarmuka kerja untuk karyawan toko ritel perusahaan harus dikoordinasikan dengan orang yang bertanggung jawab atas pengembangan teknologi ritel,
- sistem TI harus memiliki parameter kinerja ini dan itu dan tidak melampaui batasan pada prosesor, memori, I / O dan jumlah dan volume permintaan eksternal di bawah beban seperti itu, volume data ini dan itu, persyaratan ini dan itu untuk relevansi data
- sistem TI harus dapat skala dalam kondisi ini dan itu
Seharusnya dimungkinkan untuk mentransfer data sistem TI yang tidak relevan ke arsip secara teratur, data yang telah tersedia untuk sistem pelaporan selama beberapa waktu
- sistem TI tidak boleh melanggar hukum
- sistem TI harus dilindungi dari model serangan ini dan itu
- Sistem TI tidak boleh menjadi konstanta hardcoated. Mereka harus dibuat dan tersedia untuk konfigurasi dalam bentuk file konfigurasi yang disimpan dalam pengaturan repositori atau sistem
- Toleransi kesalahan sistem TI harus 99% (bisnis menyukai bahasa sembilan), meskipun kriteria ini lebih baik dijelaskan dalam bentuk yang lebih dimengerti untuk digunakan (lihat di bawah).

Kriteria toleransi kesalahan dalam bentuk TI yang dapat dipahami:

- Dalam hal terjadi kegagalan salah satu elemen dari konfigurasi server (server, subsistem disk, router jaringan), sistem TI harus terus menyediakan skenario yang diperlukan,
- Jika terjadi kegagalan layanan sistem CRM eksternal, sistem mungkin membuat tidak mungkin untuk mendaftar, melihat bonus, menghitung dan menghabiskan poin saat pembelian, tetapi harus mendukung jalan utama utama - memungkinkan melakukan pemesanan dengan pesan "Maaf, program bonus tidak tersedia untuk sementara, manajer akan menghubungi Anda dan mengklarifikasi jumlah poin pendebitan dan kredit

Namun, itu tidak cukup untuk merumuskan daftar yang luas, perlu untuk membuat proses kontrol (walaupun seringkali dalam kenyataannya kita melakukan hal itu: mereka memperkenalkan standar, tetapi mereka tidak dapat mengatur proses) Misalnya, untuk memenuhi persyaratan untuk parameter kinerja, Anda perlu membuat bangku tes, memuat skrip, alat beban dan mengukur parameter kinerja.

Tindakan Respons Risiko Standar


- Jika seorang karyawan sakit, maka ia memperingatkan di saluran komunikasi umum terlebih dahulu atau yang terburuk, dalam waktu satu jam ketidakhadiran di tempat kerja, menunjukkan perasaan mulai bekerja, sehingga anggota tim lainnya dapat mengatur pekerjaan di mana ia berpartisipasi, juga dengan mempertimbangkan periode ketidakhadiran ( menunggu atau meneruskan ke yang lain).
- Jika seorang karyawan jatuh sakit dan tidak memberi tahu dalam satu jam, manajer proyek akan belajar darinya (dalam waktu satu jam) dan memberi tahu saluran umum tentang penyakit tersebut sehingga tim dapat mengatur pekerjaan, dengan mempertimbangkan periode ketidakhadiran yang direncanakan (tunggu atau pindahkan). Jika dia tidak menjawab, maka RP menulis ke saluran umum “Karyawan itu telah menghilang, tidak berhubungan” sehingga tim dapat memindahkan pekerjaannya ke karyawan lain.
- Jika tugas tergantung pada karyawan yang diberhentikan, maka RP harus mendistribusikannya kembali ke karyawan lain atau memindahkannya ke buffer beberapa pusat kerja atau membatalkan tugas sehingga manajemen tugas tidak hilang dan sistem manajemen tugas tidak berubah menjadi sampah.

Bibliografi


  1. Artikel tentang persyaratan non-fungsional habr.com/en/post/231961
  2. Artikel tentang metode TOTE habr.com/en/post/339556
  3. E. Goldratt, Target. Proses peningkatan berkelanjutan. www.ozon.ru/context/detail/id/141279570
  4. Blanchard, Onken, Burroughs. Manajer dan monyet satu menit www.labirint.ru/books/682838
  5. Eliezer Yudkovsky. Harry Potter dan metode berpikir rasional.
  6. Patton Jeff. Cerita pengguna. Seni pengembangan perangkat lunak tangkas. Secara singkat di sini: habr.com/en/post/459872
  7. INVEST habr.com/ru/company/luxoft/blog/84030
  8. -. | , . : smartarchitects.ru/business-model-canvas, — : , . -. |
  9. « . »
  10. . , . .
  11. . . ? medium.com/it-analyst/client-quiestions-30cf76275ad3


Terima kasih banyak kepada anggota klub KiFB, terima kasih khusus kepada Ivan Kopylov untuk umpan balik yang bijaksana dan bermanfaat, serta Ulyana Leonova, Danila Golubtsova, Maxim Sinksas, Kseniia Meshkova, Denis Beskov, Serg, Mikhail Sorokin, Step_By_Step, Sergey Titkov dan istri Natal persiapan artikel, serta Olga Levina yang hebat untuk pengoreksian yang kompeten (jika Anda menemukan kesalahan, maka ini adalah kesalahan saya karena koreksi pada teks akhir).

Dan terima kasih khusus kepada Andrei Prudovsky, yang terus-menerus memilih saya membuat saya berpikir tentang perlunya berpikir dalam hal hasil dan tugas sebelum menetapkan tugas, yang bertahun-tahun kemudian menyebabkan penulisan artikel ini.

More articles:


All Articles