Dalam praktiknya, kita sering menghadapi kenyataan bahwa manajer proyek ingin mempercepat proses pengembangan - dia tidak puas dengan kecepatan pengiriman fungsionalitas baru. Biasanya, klien tersebut membutuhkan produk yang kompleks seperti sistem manajemen rumah sakit, sistem perdagangan pertukaran, sistem perbankan, dan layanan perbankan.
Dalam kasus seperti itu, Anda dapat menghubungkan tim spesialis baru, membuat proses dalam yang sudah ada, atau menggabungkan keduanya. Pertimbangkan pro dan kontra dari setiap pendekatan. Segera buat reservasi bahwa artikel tersebut membahas pengembangan proyek besar dan kompleks (lebih dari 10.000 jam).
Mengapa Anda tidak dapat langsung menghubungkan spesialis baru
Seringkali pilihan termudah dan paling jelas untuk meningkatkan kecepatan pengembangan adalah menghubungkan spesialis baru atau tim. Tampaknya bagi manajer proyek bahwa ini dapat mempercepat kecepatan memberikan nilai bisnis kepada pengguna akhir. Dalam praktiknya, ini tidak selalu terjadi, terutama ketika proses dalam proyek membutuhkan pemrosesan. Kami memberikan satu contoh dari latihan kami.
Itu perlu untuk menghubungkan dua tim ke proyek pengembangan yang ada. Proyek ini telah dikembangkan selama lebih dari 4 tahun dan berisi sejumlah besar subsistem (lebih dari 20) dengan mekanisme dan layanan yang sama. Regresi lengkap membutuhkan partisipasi 5-7 insinyur QA dan sekitar 4-6 hari kerja. Ketika memasuki proyek dan meninggalkan tim ke tingkat penyelesaian masalah yang diperlukan, mereka menghadapi kesulitan berikut:
- Salah satu bagian dari kode sumber sistem berada di bawah kendali sistem kontrol versi svn, yang lain git. SVN sebelumnya sangat populer, namun untuk proyek tim besar dan perubahan serentak yang sering, itu tidak cocok. Oleh karena itu, sebelum beralih ke git, sebagian waktu dihabiskan untuk menggabungkan, mengedit konflik, dan operasi lain yang terkait dengan percabangan di svn.
- Ada instruksi yang sudah ketinggalan zaman untuk menyebarkan lingkungan, sehingga tim mengumpulkan semua jenis perangkap sistem ini, dan hanya bisa memulai tugas pertama setelah 3-4 hari.
- Analis kunci, pakar teknis sibuk mempersiapkan rilis, sehingga tidak mungkin untuk dengan cepat mendapatkan informasi klarifikasi tentang tugas-tugas baru. Pengaturan tugas sangat tingkat atas. Ini secara signifikan memperlambat implementasi tugas.
- Alur kerja tugas sulit, pada awalnya tim "tersandung" tentang bagaimana menangani tugas sepanjang siklus hidupnya.
- Pada awalnya, klien ingin bertahan hanya dengan upaya insinyur QA mereka, tetapi mereka tidak berhasil sepenuhnya dan segera memeriksa fungsi baru dari tim pengembangan yang terhubung, karena beban yang berat. Karena itu, saya harus bekerja lembur.
- Tinjauan kode dilakukan sesuai dengan prinsip dan kriteria yang ditetapkan oleh proyek. Kriteria belum didokumentasikan. Karena itu, waktu ekstra dihabiskan untuk mengoreksi komentar.
Hasil nuansa di atas adalah:
- biaya waktu tambahan yang dapat dihabiskan untuk menyelesaikan masalah bisnis
- pengembangan yang lambat dari keseluruhan sistem
- atau lembur.
Pertimbangkan cara menghindari situasi ini.
Analisis proses
Sebelum menghubungkan spesialis baru, ada baiknya mencari tahu bagaimana kerja tim diatur - perlu untuk menemukan dan menghilangkan hambatan. Biasanya, PM menangani masalah ini, karena ia bertanggung jawab atas proyek, dan ia ingin menghabiskan lebih sedikit energi untuk proses pelacakan.
Menghilangkan kemacetan memajukan proyek. Misalnya, waktu yang diperlukan untuk memasuki spesialis baru atau tim spesialis berkurang, keterlibatan tim dalam proyek meningkat, biaya satu jam berkurang karena pelaksanaan tugas yang benar pertama kali. Jika semua hambatan dihilangkan, manajer proyek akan menerima peningkatan kecepatan pengembangan yang cepat seperti yang dimungkinkan oleh praktik saat ini dan konteks proyek. Secara umum, ini baik untuk semua orang.
Analisis kemacetan dimungkinkan dari dua sisi: dari manajemen puncak / pakar dan dari tim. Kami akan menganalisis setiap opsi secara terpisah.
Pakar luar. Dalam pendekatan ini, proses kerja dianalisis baik oleh tim eksternal dari pakar eksternal, atau oleh manajer proyek bersama dengan pemimpin tim. Dengan yang terakhir, itu bukan fakta bahwa itu akan berubah - penting bahwa mereka dapat membuang semua nuansa proyek, jika analisis tidak akan berarti.
Kondisi penting adalah dukungan untuk manajemen proyek dan kesiapan untuk perubahan.
Dengan demikian, ahli terjun ke dalam proyek dan menganalisis secara rinci dokumentasi, kode sumber, struktur basis data, proses produksi (dari analitik hingga rilis). Pekerjaan bertahap terlihat seperti ini:
- Seluruh rantai kerja pada proyek dipertimbangkan dari awal hingga akhir. Waktu setiap proses diukur.
- Bagan gantt dibangun. Pakar melihat proses apa yang berjalan secara paralel, yang satu demi satu.
- Seorang ahli berpikir bagaimana membuat setiap proses lebih produktif dan lebih murah. Sebagai aturan, seorang ahli secara intuitif memahami di mana timbul kesulitan terbesar dan mulai memutarnya untuk kemungkinan modernisasi.
Keuntungan dari pendekatan ini:
- Pekerjaan dianalisis oleh orang yang tidak terlibat dalam proyek. Dia memiliki pandangan langsung tentang proses, oleh karena itu, dia dapat menemukan masalah-masalah yang tidak terlihat oleh anggota tim.
- Seorang ahli, sebagai otoritas, mampu meyakinkan tim untuk menerima perubahan dalam proses. Tim yang telah mengerjakan proyek untuk waktu yang lama tidak mencari inovasi. Bagi mereka, ini banyak tekanan, karena mereka harus belajar lagi. Terlebih lagi, reaksi seperti itu bahkan terjadi pada perubahan yang akan membantu bekerja lebih efisien.
- Implementasi solusi yang cepat - mulai 2-15 hari. Itu semua tergantung pada perubahan global dan birokrasi dalam organisasi.
- Tim proyek mengambil pengalaman dari ahli pihak ketiga. Di masa depan, ini akan membantu untuk mengkonfigurasi proses secara mandiri.
Cons:
- Para ahli perlu menghabiskan banyak waktu untuk memahami seluk-beluknya. Tim dapat mempelajari sejarah proyek dalam satu hari, sementara ahli membutuhkan setidaknya satu setengah minggu.
Apa yang harus dilakukan tentang hal itu : tetapkan tujuan analisis bersama dengan manajer proyek / pimpinan tim. Berikan ahli semua proyek "pengantar", jangan menyembunyikan detailnya.
Jika klien sangat setia sehingga dia siap untuk menganalisa proyek secara iteratif, Anda perlu menggunakan kesempatan dan menyetujui persyaratan tersebut. Selanjutnya, akan dimungkinkan untuk menyesuaikan arah analisis setelah setiap iterasi, dengan fokus hanya pada yang diinginkan. - Beberapa anggota tim mungkin tidak setuju dengan keputusan tersebut. Selanjutnya, mereka dapat menyabot proyek, mengimplementasikan perjanjian dengan buruk, dan ini mempengaruhi suasana hati tim secara keseluruhan.
Apa yang harus dilakukan tentang hal itu : diskusikan setiap keputusan dengan tim, dan jangan menempatkan mereka sebelum fakta.
Pilihan ideal: ahli menganalisis proses secara mandiri, dan kemudian mendiskusikannya dengan orang-orang kunci dalam proyek. Jika ada kontradiksi, mereka mendiskusikannya. Ini akan mengumpulkan banyak orang yang setia pada perubahan yang akan memengaruhi anggota tim lainnya. Adalah mungkin untuk meyakinkan skeptis yang paling bersemangat.
Dari tim . Pendekatan ini dapat disebut retrospektif, yang merupakan bagian integral dari scrum. Prosesnya terlihat seperti ini:
- Seluruh tim proyek berjalan
- Salah satu peserta mengasumsikan peran fasilitator (scrum-master). Dia memastikan bahwa percakapan berjalan dengan cara yang konstruktif.
- Tim membahas pendekatan mereka untuk bekerja. Semua aspek dipertimbangkan: proses, pengkodean, menetapkan tujuan, dll. Kemudian pro dan kontra disorot.
- Pada pemungutan suara umum, mereka menyetujui perubahan: nilai tambah perlu diperbaiki, minus dihapus.
- Setelah 3-4 minggu, proses ini berulang. Tim melihat hasilnya, dan jika semua orang senang dengan semuanya, maka pekerjaan terus berlanjut.
Ketentuan Penting:
- Dukungan manajemen untuk setiap perubahan dan inovasi.
- Kohesi tim dan fokus pada peningkatan.
Jika budaya perusahaan tidak mendorong inisiatif, inovasi, maka retrospektif bukanlah cara terbaik untuk mendesain ulang proses. Anggota tim tidak akan melampaui "rawa" mereka.
Keuntungan dari pendekatan:
- Keterlibatan masing-masing peserta dalam diskusi proyek.
- Kemampuan untuk mengidentifikasi semua aspek positif dari proyek dan, jika perlu, membentuknya menjadi model tertentu (praktik terbaik).
- Anggota tim saling berbagi pengalaman.
- Penyelesaian masalah secara bertahap, mulai dari yang paling memperlambat tim dan proyek, berakhir dengan perbaikan kecil.
Cons:
- Ada risiko bahwa hanya masalah kecil yang akan diselesaikan, dan semua masalah utama akan tetap tak tersentuh.
Apa yang harus dilakukan tentang hal itu : PM, ketua tim dan fasilitator harus memengaruhi pendapat mereka tentang tim melalui otoritas. Tugas mereka adalah untuk menarik perhatian pada masalah-masalah penting pada tahap diskusi. - Untuk perubahan besar yang membutuhkan banyak pekerjaan, waktu tambahan diperlukan untuk koordinasi dengan manajemen. Namun, bukan fakta bahwa manajemen akan setuju dengan inovasi.
Apa yang harus dilakukan tentang hal itu : untuk mempertahankan sudut pandang Anda sebelum kepemimpinan adalah satu-satunya solusi. - Jika tim tidak memiliki pelatihan berkelanjutan (konferensi, pertukaran pengalaman, pelatihan), maka kemungkinan besar keputusan yang diambil akan ketinggalan jaman dan tidak begitu efektif.
Apa yang harus dilakukan dengan itu : terus bertukar pengalaman. Berpartisipasilah dalam konferensi, pertemuan, pelatihan internal yang relevan. Jika kita berbicara tentang perusahaan besar, maka pilihan yang bagus adalah hari demo. Pada acara semacam itu, tim menunjukkan hasil apa yang mereka capai dalam pekerjaan mereka.
Dalam kebanyakan kasus, Anda bisa mendapatkannya dengan mengadaptasi dan meningkatkan proses yang dijelaskan di atas. Walaupun pada awalnya jelas bahwa sangat mungkin untuk menyelesaikan proyek tepat waktu hanya dengan menarik spesialis / tim baru, kami sangat menyarankan Anda mencoba langkah-langkah di atas.
Jika, setelah menghilangkan hambatan, manajer proyek percaya bahwa kapasitas belum mencapai tingkat yang diinginkan, maka Anda dapat menghubungkan tim baru.
Mempersiapkan infrastruktur untuk tim baru
Pada tahap ini, ada baiknya untuk melakukan pekerjaan persiapan yang akan mengurangi durasi dan biaya pengembangan, membantu menyelamatkan sel-sel saraf pengembang. Mari pertimbangkan kondisi apa yang seharusnya:
- Tugas-tugas untuk tim baru harus dirinci secara terperinci. Anda dapat memulai masing-masing tanpa menunggu - tidak ada ketergantungan pada tugas saat ini atau masa depan. Area tanggung jawab masing-masing tim diuraikan.
Jika ini bukan masalahnya , maka sebagian besar tim baru akan diam atau terlibat dalam tugas-tugas sekunder yang memiliki dampak paling kecil pada nilai produk. - Arsitektur proyek ini "benar", yaitu dipecah menjadi modul, subsistem, komponen umum.
Jika ini tidak terjadi , maka menghubungkan perintah baru akan gagal. Pengembang akan bekerja di bawah kendali pimpinan tim saat ini, tetapi seseorang dapat secara efektif mengelola tidak lebih dari 7-9 orang. Timlid akan dicabik, dan beberapa anggota tim akan menunggu sampai mereka diberikan tugas.
Jika tidak mungkin untuk mengisolasi bagian-bagian terisolasi dari kode proyek, tetapi Anda harus bergerak maju, maka Anda dapat mencoba untuk melewati batasan ini. Perlu membagi proyek menjadi beberapa bagian melalui refactoring.
Pilihan lain - setelah mencelupkan dua atau tiga orang dalam proyek, untuk memberi kepada tim baru semakin banyak fungsi bisnis yang besar. Jadi tim akan mengembangkan proyek secara terpisah satu sama lain, dan karena pemimpin tim baru (orang yang terbenam dalam seluk-beluk) akan mengurangi beban pada pemimpin tim utama. - Proses kerja dalam proyek dijelaskan secara rinci. Misalnya, ada tugas alur kerja, tugas ditampilkan untuk dieksekusi dalam sistem kontrol versi (praktik menunjukkan bahwa tidak semua orang memiliki GitFlow standar), interaksi antara peserta proyek dijelaskan.
Jika ini tidak terjadi , maka kekacauan akan terjadi pada proyek. Dalam hal ini, manajer proyek hanya akan berurusan dengan "manual", manajemen darurat. - Komponen dan modul umum memiliki dokumentasi yang relevan dan dapat dipahami. Ada tes unit dan integrasi bagian utama. Ada deskripsi yang jelas tentang arsitektur seluruh proyek, mekanisme umum, serta instruksi tentang cara menerapkannya. Jika hal di atas belum ada, maka perlu menambahkan tugas serupa ke kumpulan utang teknis untuk memperbaiki situasi.
Jika ini tidak terjadi , maka risiko melakukan pekerjaan ganda meningkat. Kode sumber yang buruk atau digandakan akan ditulis. Di masa depan, ini akan mengarah pada dukungan proyek yang lebih mahal. Sebagai aturan, menghubungkan tim baru menyiratkan kemungkinan koneksi beberapa tim lagi. Dengan demikian, biaya waktu akan diskalakan oleh kelipatan jumlah tim. - Ada aturan baku untuk menulis kode - kode konvensi, skrip untuk memperbarui struktur basis data - migrasi, prinsip umum tinjauan kode wajib. Meskipun memiliki kesamaan yang kuat, pastinya setiap proyek memiliki karakteristiknya sendiri.
Jika ini tidak terjadi , maka kompleksitas dan biaya untuk mendukung proyek lebih lanjut akan meningkat berkali-kali lipat.
Kondisi di atas memungkinkan Anda untuk menghubungkan tim baru dengan paling efektif. Waktu yang dibutuhkan tim untuk memasuki suatu proyek sangat berkurang. Hal yang sama terjadi dengan biaya tenaga kerja untuk mendukung dan mengembangkan proyek.
Bagaimana kami menghubungkan tim tambahan ke proyek
Kami memiliki kasus ketika proyek sangat dibutuhkan untuk mempercepat proses pengembangan. 2-3 bulan tersisa sampai versi utama berikutnya dimasukkan ke dalam operasi komersial. Proyek itu sendiri adalah sistem kompleks yang dikembangkan oleh satu tim selama 3-4 tahun.
Pertama-tama, kami terjun ke dalam konteks proyek itu sendiri. Hasilnya adalah gambar berikut dari kemacetan proyek:
- Tidak ada informasi akurat tentang bagaimana fitur harus diimplementasikan. Daftar tugas, bug, perbaikan sudah ketinggalan zaman.
- Tidak ada integrasi berkelanjutan, dan pengembangan dilakukan di dua cabang.
- Proses pengujian produk tidak di-debug. Misalnya, insinyur QA dapat menemukan bug yang sudah diperbaiki, yang mengarah pada biaya tenaga kerja tambahan.
- Basis kasus uji masih dalam masa pertumbuhan. Insinyur QA individu mulai menulis kasus untuk diri mereka sendiri. Karena itu, tidak ada yang bisa memberikan penilaian tertentu terhadap kualitas produk dan risiko yang mungkin terjadi ketika merilis versi baru.
- Proses kerja, dari produksi hingga persetujuan oleh pelanggan, tidak didokumentasikan. Itu tidak mungkin untuk memprediksi komposisi yang tepat dari fungsi rilis, serta poin yang kurang signifikan lainnya.
Setelah analisis, kami membuat rencana untuk menghilangkan poin-poin di atas. Tentu saja, tim tidak langsung setuju dengan perubahan, tetapi dengan dukungan kepemimpinan dan pengembangan tenggat waktu yang jelas, kami dapat membujuk setiap anggota tim.
Kami mengoordinasikan tindakan kami dengan orang-orang kunci proyek: PM, ketua tim, analis terkemuka. Bersama-sama, ketiga orang ini membentuk pusat tim manajemen pelanggan tunggal. Mereka selanjutnya mempromosikan solusi dan memantau implementasi mereka dalam praktik. Tanpa tim manajemen seperti itu, mustahil untuk mengoordinasikan tindakan lebih dari tiga tim.
Akibatnya, proses berikut diimplementasikan \ dioptimalkan:
- Kami membangun komunikasi antara semua anggota tim produk - pengembang, analis, dan spesialis pengujian.
- Mereka mendokumentasikan fungsi kritis dan kompleks untuk pengujian yang lebih transparan, menghilangkan cacat, menyelesaikan perselisihan, dan perencanaan kerja selanjutnya.
- Proses pengembangan yang dioptimalkan. Diadopsi oleh proyek WorkFlow dan GitFlow. Mereka membantu mengkonfigurasi Integrasi Berkelanjutan dan menjalankan tes otomatis dalam mode otomatis.
- Kami menggandakan kecepatan perakitan bangku tes.
- Mengatur proses pengujian yang tepat. Pengujian regresi dilaksanakan pada akhir setiap iterasi.
- Memperkenalkan proses perencanaan iterasi.
- Melakukan pengujian beban.
Berdasarkan hasil iterasi pertama, kami menyiapkan infrastruktur untuk menghubungkan tim baru. Sejalan dengan ini, dua pengembang kami bergabung dengan tim saat ini untuk terjun ke basis kode. Kemudian salah satu dari mereka menjadi pemimpin tim tim baru. Pada iterasi kedua, kedua tim mencapai hasil berikut:
- Komisioning setelah 3 bulan.
- Memperbaiki 70% bug
- Empat fitur serius diimplementasikan
- Dioptimalkan dan meningkat 8 kali kecepatan memuat beberapa halaman
- Menerima informasi yang akurat tentang kualitas seluruh produk
- Iterasi RoadMap yang dibangun
Saya percaya bahwa salah satu pencapaian terpenting dari proyek ini adalah kegembiraan klien. Dia secara transparan mewakili status proyek setiap saat, dan kewajiban terhadap bisnis dipenuhi secara penuh dan tepat waktu.
Kesimpulan
Ada dua cara utama untuk meningkatkan kecepatan pengembangan proyek: menghilangkan hambatan dan meningkatkan kapasitas produksi. Dalam kasus pertama, Anda bisa mendapatkan peningkatan 30-40% dalam kecepatan pengembangan, di 70-80% kedua. Perintah tambahan tidak memberikan peningkatan ganda dalam produktivitas, karena lebih banyak waktu dihabiskan untuk interaksi antara beberapa tim.
Faktor kunci keberhasilan untuk memperluas tim pengembangan adalah:
- pekerjaan persiapan
- proses yang mapan
- seorang pemimpin atau anggota tim proyek yang akan mempromosikan dan mengawasi kegiatan tim,
- pusat kendali perintah tunggal.
Tiga tim sedang mengerjakan proyek yang kami jelaskan sebelumnya (satu lama dan dua baru). Jumlah tugas yang dilakukan meningkat
1,9 kali .