Yang paling penting adalah programmer tidak mengerti bagaimana berkomunikasi dengan pelanggan dan satu sama lain. Bagaimana membangun proses pengembangan produk berkualitas berkelanjutan. Bagaimana merencanakan hari kerja dan sprint Anda.
Dan semua ini pada akhirnya diterjemahkan ke dalam tenggat waktu yang terganggu, lembur, pertikaian terus-menerus tentang siapa yang harus disalahkan, dan ketidakpuasan pelanggan - di mana dan bagaimana semuanya bergerak. Cukup sering, semua ini mengarah pada perubahan programmer, atau bahkan seluruh tim. Kehilangan pelanggan, kemerosotan reputasi, dan sebagainya.
Pada suatu waktu, saya baru saja mengerjakan proyek seperti itu, di mana semua pesona ini berada.
Tidak ada yang mau bertanggung jawab atas proyek (pasar layanan besar), omsetnya buruk, pelanggan hanya merobek dan meronta-ronta. CEO pernah mendatangi saya dan mengatakan bahwa Anda memiliki pengalaman yang diperlukan, jadi inilah kartu di tangan Anda. Ambil proyek itu sendiri. Anda gagal, kami akan menutup proyek dan mengeluarkan semua orang. Ini akan berubah, itu akan menjadi keren, kemudian memimpin dan mengembangkannya sesuai keinginan Anda. Akibatnya, saya menjadi pemimpin tim dalam proyek tersebut dan semuanya jatuh ke pundak saya.
Hal pertama yang saya lakukan adalah merancang alur kerja dari awal yang sesuai dengan visi saya pada saat itu dan menulis deskripsi pekerjaan untuk tim. Tidak mudah untuk diterapkan. Tetapi di suatu tempat dalam waktu sebulan semuanya beres, pengembang dan klien terbiasa, dan semuanya berjalan dengan tenang dan nyaman. Untuk menunjukkan kepada tim bahwa ini bukan hanya "badai dalam gelas", tetapi jalan keluar nyata dari situasi tersebut, saya mengambil tanggung jawab maksimum, menghilangkan rutinitas yang tidak menyenangkan dari tim.
Satu setengah tahun telah berlalu, dan proyek ini berkembang tanpa lembur, tanpa "perlombaan tikus" dan segala macam stres. Seseorang di tim lama tidak ingin bekerja seperti itu dan pergi, sebaliknya, seseorang sangat ingin aturan transparan muncul. Tetapi sebagai hasilnya, semua orang yang ada di tim sangat termotivasi dan mengetahui proyek besar ini secara penuh, dengan front-end dan back-end. Termasuk basis kode dan semua logika bisnis. Bahkan telah sampai pada titik bahwa kita bukan hanya "pendayung", tetapi kita sendiri yang menghasilkan banyak proses bisnis dan fitur baru yang menurut bisnis disukai.
Berkat pendekatan kami ini, pelanggan memutuskan untuk memesan pasar lain dari perusahaan kami, yang merupakan kabar baik.
Karena ini berfungsi pada proyek saya, mungkin itu juga dapat membantu seseorang. Jadi, proses itu sendiri yang membantu kami menyelamatkan proyek:
Proses kerja tim pada proyek "Proyek favorit saya"
a) Proses tim internal (antar pengembang)
- Semua tugas dibuat di sistem Jira
- Setiap tugas harus dijelaskan sebanyak mungkin, dan melakukan satu tindakan dengan ketat
- Fitur apa pun, jika cukup kompleks, dipecah menjadi banyak swap kecil
- Tim mengerjakan fitur seperti satu tugas. Pertama, kita melakukan semuanya bersama-sama satu fitur, mengirimkannya untuk pengujian, lalu mengambil fitur berikutnya.
- Setiap tugas ditandai, untuk backend atau frontend-nya
- Ada jenis taring dan serangga. Anda perlu menunjukkannya dengan benar.
- Setelah menyelesaikan tugas, itu ditransfer ke status peninjauan kode (ini membuat permintaan tarik untuk kolega Anda)
- Siapa pun yang menyelesaikan tugas segera melacak waktu mereka untuk tugas ini.
- , , , , , .
- , , ( ), , - . —
- ,
- ,
- , , . ,
- : To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- , . , , .
- . , .
- .
- , .
- , , , , .
- , , , , . ( ) . , /.
- ( 12.00)
- , , , . . , . , , .
- , . .
- , , , , .
- . .
- . , , . . , , , .
- , . . .
- , , . .
- Setiap hari, pengembang harus menulis di obrolan klien tentang tugas apa yang dia kerjakan kemarin dan tugas apa yang akan dia kerjakan hari ini
- Alur kerja didasarkan pada Scrum. Semuanya dipecah menjadi sprint. Setiap sprint berlangsung selama dua minggu.
- Sprint membuat, mengisi, dan menutup pemimpin tim.
- Jika proyek memiliki tenggat waktu yang ketat, maka kami mencoba memperkirakan perkiraan semua tugas. Dan kami mengumpulkan sprint dari mereka. Jika pelanggan mencoba menambahkan lebih banyak tugas ke sprint, maka kami menetapkan prioritas, dan mentransfer beberapa tugas lain ke sprint berikutnya.
b) Proses bekerja dengan pelanggan
- Setiap pengembang dapat dan harus berkomunikasi dengan pelanggan
- Pelanggan tidak boleh diizinkan untuk memaksakan aturan mainnya sendiri. Hal ini diperlukan dengan sopan dan ramah untuk menjelaskan kepada pelanggan bahwa kami adalah spesialis di bidang kami, dan hanya kami yang harus membangun proses kerja dan melibatkan pelanggan di dalamnya
- , , - , - (). . , , , .. , , , , , , .
- /-/ .. /, .
- . , , -, /.
- , . , , . .
- , . . , .
- , , . , . , . , . .
- , , . , . , .
- Jika pelanggan mulai datang dengan tugas yang berbeda dari kepalanya, mulai berfantasi dan menjelaskan dengan jari, maka kami memintanya untuk memberi kami tata letak halaman dan alur dengan logika yang harus sepenuhnya menggambarkan perilaku seluruh tata letak dan elemennya.
- Sebelum kami melakukan tugas apa pun, kami harus memastikan bahwa fitur ini termasuk dalam ketentuan perjanjian / kontrak kami. Jika ini adalah fitur baru yang melampaui perjanjian awal kami, maka kami harus mengevaluasi fitur ini ((perkiraan waktu tunggu + 30%) x 2) dan menunjukkan kepada pelanggan bahwa kami membutuhkan banyak waktu untuk itu, ditambah tenggat waktu yang diubah dengan dua kali perkiraan. Mari kita buat tugas lebih cepat - bagus, semua orang akan mendapat manfaat dari ini. Jika tidak, maka kita diasuransikan.
c) Apa yang tidak kami terima di tim:
- Opsionalitas, kurangnya pertemuan, kelupaan
- „ “. , , , .
- , . , , :)
- . , , . , , — . -, .
- .
- ! - - , .
Dan sejumlah pertanyaan / tesis lain yang terkadang saya minta pelanggan saya untuk menghilangkan semua kesalahpahaman:
- Apa kriteria kualitas Anda?
- Bagaimana Anda menentukan apakah suatu proyek memiliki masalah atau tidak?
- Melanggar semua rekomendasi dan saran kami untuk mengubah / meningkatkan sistem, semua risiko hanya ditanggung oleh Anda
- Setiap perubahan besar pada proyek (misalnya, semua jenis aliran tambahan) akan mengarah pada kemungkinan munculnya bug (yang tentu saja akan kami perbaiki)
- Tidak mungkin selama beberapa menit untuk memahami jenis masalah yang terjadi pada proyek, dan terlebih lagi untuk segera memperbaikinya
- Kami mengerjakan produk aliran tertentu (Tugas dalam Lemak - Pengembangan - Pengujian - Terapkan). Ini berarti kami tidak dapat menanggapi seluruh aliran permintaan dan keluhan dalam obrolan
- Pemrogram hanyalah pemrogram, bukan penguji profesional, dan tidak dapat memastikan kualitas pengujian proyek yang tepat
- , , ( )
- ( ), ,
- — ,
- , , , ,
- , , , ,
- .
- , ( ),
Biasanya, pelanggan segera menyadari bahwa segala sesuatu tidak sesederhana itu dalam pengembangan perangkat lunak, dan keinginan saja jelas tidak cukup.
Secara umum, itu saja. Saya meninggalkan banyak negosiasi dan debugging awal dari semua proses, tetapi sebagai hasilnya semuanya berjalan lancar. Saya dapat mengatakan bahwa proses ini telah menjadi semacam "Silver Bullet" bagi kami. Orang-orang baru yang datang ke proyek bisa langsung membiasakan diri bekerja sejak hari pertama, karena semua proses sudah dijelaskan, dan dokumentasi serta arsitektur dalam bentuk diagram langsung memberi gambaran tentang apa yang kami lakukan di sini.
PS Saya ingin mengklarifikasi bahwa tidak ada manajer proyek di pihak kami. Itu ada di sisi pelanggan. Sama sekali bukan teknisi. Proyeknya Eropa. Semua komunikasi hanya dalam bahasa Inggris.
Semoga sukses untuk semua orang di proyek. Jangan kelelahan dan coba tingkatkan proses Anda.
Sumbernya ada di blog saya .