Tenggat Waktu Pembakaran: Bagaimana Manajer Proyek Tidak Bisa Tersesat

gambar

Semua orang tahu apa batas waktu itu, tetapi tidak semua orang tahu cara mengaturnya dengan benar. Untuk berbicara tentang melanggar batas waktu proyek, Anda dapat mengambil banyak metafora yang indah. Yubitsume adalah salah satunya. Ini adalah pemotongan ritual jari phalanx di Jepang. Secara khusus, mereka menggunakan yubitsume untuk meminta maaf kepada pemimpin atau pemilik atas kesalahan. Jika Anda menonton film tentang yakuza, maka Anda mengerti tentang apa itu.

Ritual itu pergi dari kalangan komunitas perjudian Bakuto, dan dipandang sebagai pengganti yang memadai untuk membayar utang. Si debitur membiarkan phalanx kecil itu dikonsumsi, dan ini memperumit kehidupannya di masa depan: ia tidak bisa lagi memegang pedangnya dengan aman dan dalam pertempuran lebih tergantung pada teman-temannya, termasuk pemiliknya.

Tidak masalah waktu dan tempat Anda tinggal dan apa yang Anda lakukan - hubungan tim harus kuat, dan tenggat waktu harus dihormati. Manajer Live Typing Studio, meskipun mereka tidak memotong jari mereka, masih bertanggung jawab atas kata yang diberikan kepada klien. Pengalaman telah memungkinkan saya untuk merumuskan enam kesalahan, yang membuat, Anda pasti berisiko kehilangan pekerjaan tepat waktu, dan apa yang harus dilakukan untuk mematuhi tenggat waktu. Setelah berhenti melakukan kesalahan ini, Anda akan melihat bagaimana kualitas proyek Anda akan meningkat, berapa banyak waktu akan dibebaskan untuk istirahat dan bagaimana hubungan antara anggota tim dan dengan klien akan meningkat.

Anda tidak tahu dengan siapa Anda bekerja


Setiap anggota tim pengembangan seperti karakter dalam permainan peran: seseorang memiliki banyak kemampuan untuk terlibat dalam proyek, tetapi tidak memiliki ketekunan dan konsentrasi, dan seseorang menghargai waktu yang dibutuhkan untuk menyelesaikan tugas. Dari yang terakhir, timlids diperoleh, yang biasanya bagus dalam segala hal.

Dengan semua ini, sangat berbeda, orang perlu bekerja dengan gaya yang berbeda. Beberapa membutuhkan insentif, apakah itu kontrol ketat atau kata-kata yang membesarkan hati; yang lain mengharapkan Anda untuk memberi tahu mereka tentang latar belakang klien, cita-cita dan pandangannya tentang kehidupan, apa yang ia harapkan dari tim dan bagaimana ia bergantung padanya; yang lain hanya bekerja. Jika Anda tidak membuat kelonggaran untuk karakter anggota tim Anda, ia akan dibiarkan sendiri dan kebiasaan terburuknya, dan batas waktu mungkin akan terganggu.

Yang tidak kalah penting adalah pengalaman seorang spesialis. Mendistribusikan tugas sesuai dengan kemampuan dan koefisien produktivitas mereka, jika tidak Juni atau Pertengahan akan gagal dalam tugas yang pada awalnya tidak dapat mereka lakukan.

Anda tidak memahami tujuan proyek


Pengerjaan situs web atau aplikasi dimulai dengan tahap desain . Ini adalah tahap yang serius: masih harus dilihat siapa yang akan menggunakan produk, tujuan apa yang ingin dicapai, dan bagaimana ia akan membawa uang kepada pemiliknya. Hasil dari tahap ini dicatat dalam tugas fungsional, dan tugas fungsional berfungsi sebagai dasar untuk merumuskan tugas untuk desainer dan pengembang.

Fungsi aplikasi harus memiliki tujuan yang jelas. Jika manajer tidak memahaminya, ini berarti bahwa desainnya buruk, dan tugas tidak akan ditetapkan dengan benar untuk kontraktor. Hasilnya tidak dapat diprediksi, karena pengembang dapat mulai memikirkan peran fungsionalitas, mengembangkannya, dan pada akhirnya menghabiskan banyak waktu untuk menulis dan menulis ulang kode.

Untuk menghindari ini, kami melakukan tinjauan desain: seluruh tim dengan hati-hati dan iteratif melihat prototipe atau desain yang dihasilkan dan menemukan sebanyak mungkin ruang, kesalahan, dan layar yang hilang. Eksekusi berkualitas tinggi dari tinjauan desain sangat memengaruhi waktu.

Dokumentasi yang lebih akurat dan lengkap adalah, semakin sedikit pengembang akan memiliki kesalahpahaman dan bug selama pengembangan, yang memastikan kepatuhan dengan tenggat waktu.

Anggota tim Anda memberi peringkat tugas yang salah


Peringkat yang salah adalah penyebab tenggat waktu paling banyak terbakar. Setiap kasus penilaian yang salah harus didiskusikan dalam retrospeksi, temukan alasannya dan kembangkan taktik untuk mengatasinya di masa depan.

Beberapa junior dan middle cenderung melebih-lebihkan kekuatan mereka. Dengan pengalaman, manajer yang baik mulai memahami hal ini dan membuat penyesuaian: misalnya, setelah mendengar perkiraan 10 jam, ia menggandakannya dengan 2 dan mendapatkan hasil yang kemudian ternyata lebih benar.

Pengembang senior bukanlah orang yang lebih tua dari yang lain, tetapi siapa tahu bahwa mungkin dibutuhkan lebih banyak waktu untuk menyelesaikan tugas dari yang diharapkan, dan dengan berani mengakui hal ini kepada dirinya sendiri dan manajer. Pengembang senior mengetahui risiko, dan Anda harus melakukannya. Kesalahan berikut dikhususkan untuk ini.

Anda dan klien Anda tidak mengetahui risikonya


Risiko adalah semua yang tidak Anda rencanakan dan yang akan memperlambat pekerjaan pada tugas. Mereka eksternal dan internal. Terputusnya Internet, badai atau banjir, perubahan persyaratan untuk suatu produk - ini adalah alasan eksternal yang tidak dapat dipengaruhi oleh seniman dengan cara apa pun. Pencarian panjang untuk solusi masalah, gangguan saraf pada pengembang - ini adalah penyebab internal dan mereka dapat dikontrol.

Anda dapat mengurangi kemungkinan risiko karena penguraian, atau membagi tugas besar menjadi kecil. 40 jam tidak selalu empat tugas masing-masing 10 jam; selama dekomposisi, mungkin ternyata bahwa untuk integrasi sistem pembayaran yang sangat akrab dengan proyek yang tidak dikenal, solusi kotak siap pakai tidak akan cukup, dan Anda harus menulis sendiri. Dekomposisi akan membantu mengevaluasi tenggat waktu dengan benar dan menyederhanakan kendali atas ketaatan mereka.

Beberapa penyebab eksternal juga dapat dipengaruhi, terutama ketika mereka berada di klien. Semakin cepat klien memberikan akses ke teks, logo, dokumentasi, API (jika pihak server melakukan perintah di sisi klien), semakin baik. Dan akan lebih baik lagi jika Anda mengumpulkan risiko yang terkait dengan klien bersama dan memasukkannya ke dalam kontrak. Ini akan menjadi pengingat bagi klien bahwa ia juga bagian dari proyek.

Jika klien dalam kondisi baik, maka proyek akan berjalan dengan mudah. Beritahukan kepadanya tentang status tugas, bicaralah tentang segala hal yang bisa salah dan itu akan menyebabkan penundaan, bicarakan apa yang Anda coba selesaikan masalah. Pertama, Anda mungkin terkejut dengan bagaimana hal itu membuat Anda lebih dekat dan mendorong Anda untuk terlibat dalam dialog yang paling konstruktif mungkin. Kedua, kemungkinan keluar untuk jangka waktu dan penugasan kembali tidak akan lagi menjadi kejutan bagi klien. Komunikasi yang baik adalah kunci kesuksesan .

Anda tidak punya rencana B


Manajer yang baik, seperti pemain catur, menghitung opsi untuk acara sebelumnya. Tetapi jika seorang pemain catur melihat ke masa depan hanya beberapa menit, maka manajer - untuk beberapa bulan sebelum batas waktu pasti. Selama ini, semua risiko harus keluar.

Dalam kasus seperti itu, untuk sejumlah tugas yang sangat kompleks, perlu untuk memilih versi yang lebih murah dari solusi mereka, yang tidak akan mempengaruhi pengalaman pengguna, dan hasil keseluruhan akan tetap memadai. Ini disebut flex. Opsi fleksibel - mengabaikan desain khusus . Namun tetap menggunakan pedoman Apple dan Google. Hanya saja, jangan lupa untuk menjelaskan kepada klien bahwa sekarang ini adalah pilihan terbaik untuk memenuhi tenggat waktu.

Anda tidak dapat menambahkan nilai ke klien di mata klien.


Tetap saja, dimulai dengan permintaan maaf adalah hal yang normal, ini adalah kesopanan dasar. Hal lain adalah bahwa permintaan maaf perlu didukung oleh sesuatu yang diterapkan. Akan lebih bagus jika Anda:

  • menganalisis masalah pada pertemuan dengan tim, menarik kesimpulan dan berjanji kepada klien bahwa ini tidak akan terjadi lagi;
  • membenarkan bahwa tenggat waktu masuk akal untuk proyek di masa depan. Selama 16 jam tambahan ini, Anda mungkin dengan saksama menguji aplikasi dan memperbaiki bug yang akan merusak produk dan citra klien secara tidak dapat diperbaiki jika jatuh ke tangan pengguna.

Jika Anda tidak ingin merasa bersalah dan membuat kesalahan dalam kecepatan hidup Anda, jangan lakukan kesalahan ini. Saya telah membuat daftar yang paling mendasar dan kami berpikir bahwa spesifik pekerjaan Anda mengarah ke kesalahan lain. Akan sangat bagus jika Anda membicarakannya di komentar.

Source: https://habr.com/ru/post/id443556/


All Articles