Sebagai aturan, di bidang pengembangan web khusus, semua agensi hanya bermimpi tentang pelanggan yang proyeknya akan tumbuh dua kali lipat dalam turnover tahunan, secara teratur mengirimkan kasing yang bisa Anda banggakan, dan mendapatkan penghargaan peringkat profil untuk agensi tersebut. Pelanggan tersebut adalah pemimpin industri. Ini adalah perusahaan yang bisnisnya dibangun di web, atau jaringan offline besar yang, berkat investasi yang mengesankan, masuk ke posisi terdepan di saluran web.
Tampaknya setelah mendapatkan beberapa pelanggan seperti itu, Anda dapat berpuas diri - berhenti menjual dan hanya mengendalikan arus tugas yang terus tumbuh. Namun pada kenyataannya, seiring pertumbuhan proyek, itu akan memberi Anda tantangan baru dan baru untuk mengatasi dan menyelamatkan klien, sementara bekerja dengan biaya yang efektif, itu akan menjadi tugas yang sangat sulit.
Pertumbuhan Proyek dan Tantangan Terkait
Penting untuk mengambil tindakan proaktif dalam waktu dan menanggung biaya tambahan yang terkait dengan penskalaan. Pada awalnya, ini dapat mempengaruhi profitabilitas, tetapi setelah mencapai volume tertentu akan menjadi jelas bahwa investasi awal itu dibenarkan.
Berikut adalah tantangan utama yang mungkin dihadapi lembaga dalam proyek semacam itu:
- Masalah penskalaan adalah restrukturisasi struktur tim dengan pertumbuhan volume.
- Kebutuhan untuk memahami tugas-tugas produk dan bisnis - tanpa analitik produk yang kuat tidak mungkin untuk bekerja secara efektif pada proyek besar.
- Perangkat lunak yang canggih dan arsitektur server - seiring dengan pertumbuhan volume produksi di bawah proyek, ada juga peningkatan lalu lintas, yang mengarah ke arsitektur yang lebih kompleks dan kebutuhan untuk menggunakan solusi beban tinggi.
- Persyaratan kualitas tinggi.
- Kebutuhan untuk memastikan operasi 24 × 7 yang tidak terputus dan kecepatan respons yang tinggi terhadap insiden, termasuk di luar jam kerja.
- Tingkat tanggung jawab yang tinggi untuk menghentikan penjualan.
- Pemantauan dan pengendalian indikator bisnis.
Tidak semua agen di pasar memiliki kompetensi yang diperlukan untuk mengatasi semua tantangan ini. Hari ini kita akan berbicara tentang masalah penskalaan tim - aspek yang paling sulit, menurut saya, bekerja dengan proyek yang sedang berkembang.
Saya mendapat kesempatan untuk mengerjakan beberapa proyek dengan pertumbuhan eksplosif, termasuk toko online terbesar untuk barang-barang anak-anak dan perusahaan asuransi terkemuka.
Saya berpartisipasi dalam proyek-proyek ini pertama sebagai manajer, dan kemudian sebagai kepala tim manajemen, dan saya ingin berbagi pengalaman yang didapat.
Berperan pada proyek kecil dan mengapa Anda perlu mengukur
Skema peran terlihat seperti ini dalam kasus umum:
Di AGIMA, kami menggunakan manajemen tiga tahap, ketika semua masalah taktis diputuskan dalam kerangka interaksi dalam tim proyek, dan isu-isu strategis dibawa ke tingkat direktur akun dan kepala departemen layanan pelanggan. Sebuah hierarki dibangun dalam tim proyek, tergantung pada skala proyek, saya akan membicarakannya di bawah ini.
Ini adalah diagram peran yang khas di dalam tim proyek pada proyek kecil:
Proyek ini memiliki dua peran utama: manajer proyek (RP) dan pemimpin tim.
Perusahaan berkomunikasi dengan klien, meresmikan tugas, menyusun simpanan, menentukan prioritas, membuat rencana dan melakukan kontrol tugas untuk kepatuhan dengan logika bisnis. Juga, RP berkomunikasi pada semua tahap kerja dengan departemen desain, desain, analisis, administrasi sistem.
Timlid melakukan formalisasi tugas teknis, mendefinisikan teknologi / alat yang digunakan, melakukan peninjauan kode, melaksanakan rilis, memantau integritas arsitektur proyek, dan mengoordinasikan tim pengembangan.
Sumber daya yang tersisa dapat dihubungkan ke proyek sesuai kebutuhan dan sangat dapat dipertukarkan.
Tonggak penting dalam pertumbuhan proyek dan perubahan paradigma yang aneh terjadi pada saat tidak mungkin menyimpan semua informasi dalam satu kepala. Satu pimpinan tim secara fisik tidak dapat mengendalikan seluruh arsitektur proyek, karena ia tumbuh terlalu cepat. Seorang manajer tidak punya waktu untuk terjun ke semua tugas dan mengendalikan semua pekerjaan.
Ada kebutuhan untuk pemisahan dan duplikasi tugas karyawan, dan skema peran standar diperluas dan menjadi lebih rumit.
Struktur tim manajemen
Salah satu unit yang paling sulit untuk diukur adalah RP.
Ketika proyek tumbuh, masuk akal untuk mengimplementasikan akun berpasangan klasik - skema manajer proyek, ketika satu RP menangani layanan pelanggan, termasuk masalah produk, dan yang kedua mengatur proses produksi di dalam perusahaan.
Namun, skema tersebut menjadi menemui jalan buntu dengan pertumbuhan berikutnya. Dalam kerangka kerja satu proyek mungkin ada hingga puluhan produk, yang masing-masing membutuhkan perhatian dari sudut pandang proses bisnis. Dalam kasus ini, situasi muncul secara berkala ketika pengembangan paralel dari produk yang berbeda mengarah pada konflik logis dalam kerangka arsitektur aplikasi web atau logika bisnis, yang mengandung risiko sangat tinggi.
Oleh karena itu, skema ideal dari sudut pandang skalabilitas lebih lanjut adalah sebagai berikut:
Group Head (GH) mengelola staf manajerial proyek dan bertanggung jawab untuk mengendalikan anggaran, profitabilitas, pembentukan tim (baik manajerial maupun pelaksana langsung) dan alokasi sumber daya, dan menyelesaikan masalah strategis manajemen proyek. Dia juga melakukan kontrol produk dan memonitor tidak adanya konflik dalam proses paralel. Dia tidak menghabiskan waktu untuk kegiatan operasional dan memantau implementasi setiap tugas tertentu.
Berkat pengenalan peran ini, kasus dihilangkan ketika beberapa tugas besar dilakukan secara paralel dan kontradiksi dan konflik logis terungkap pada tahap akhir, yang dalam kasus yang paling tidak berhasil menghasilkan refactoring lengkap.
Jika perlu, peran pemilik Produk tambahan terhubung, dimana GH mendelegasikan bagian dari tanggung jawab produk. Paling sering, karyawan ini didasarkan pada sisi klien dan menyampaikan semua keinginan bisnis dalam bentuk tugas formal untuk dieksekusi.
Setiap RP dalam tim bertanggung jawab atas “bagian” proyeknya, mengendalikan semua tugas saat ini untuk sejumlah produk (idealnya, ini harus merupakan bidang terkait). Tanggung jawabnya meliputi waktu dan kualitas semua tugas dalam rangka pengembangan produk yang bertanggung jawab.
Skema ini mudah diskalakan dan memiliki ambang masuk yang relatif rendah, karena ketika menghubungkan RP baru, skema tersebut tidak perlu secara bersamaan mencakup seluruh basis pengetahuan proyek, cukup untuk memahami prinsip pengoperasian produk "Anda".
Penting bahwa setiap RP bertanggung jawab tidak hanya untuk proses produksi, tetapi juga berpengalaman dalam logika bisnis produk-produknya. Berkat ini, semua keputusan manajemen tidak hanya benar dari sudut pandang manajemen proyek, tetapi juga berguna untuk bisnis dan diverifikasi secara arsitektur.
Dalam beberapa kasus, peran administrator proyek harus dipilih secara terpisah - karyawan ini tidak membenamkan dirinya dalam komponen produk atau proses produksi, tetapi terlibat dalam menyiapkan laporan, bertanggung jawab untuk manajemen dokumen dan juga memainkan peran "baris pertama", memastikan kesinambungan komunikasi dan jawaban yang cepat untuk semua permintaan pelanggan dan mitra. .
Pada saat yang sama, seluruh tim manajemen termasuk motivasi kolektif, terkait dengan mengelola harapan klien, di tempat pertama - memasuki timing proyek.
- 10 hari kerja sebelum awal bulan, masing-masing RP sendiri mengalokasikan tiga hingga lima tugas utama untuk bulan berikutnya.
- 5 hari kerja sebelum awal bulan, GH memilih dua atau empat dari mereka untuk setiap manajer dan menetapkan tenggat waktu: 1 - istilah pelanggan (50%), istilah 2 - internal (100%) dan memasukkannya dalam tabel.
Ketentuan bonus (sesuai dengan hasil bulan ini):
- Manajer menerima bonus 100% jika semua tugasnya selesai dalam tenggat waktu internal.
- Manajer menerima 50% bonus jika setidaknya salah satu tugasnya meninggalkan masa internal, tetapi diselesaikan dalam masa klien.
- Tidak ada manajer yang menerima bonus jika setidaknya satu tugas dari daftar umum tidak selesai dalam waktu klien.
Skema ini memungkinkan seluruh tim manajemen untuk bekerja secara efektif dan benar mengelola harapan klien.
Menguji Tidak Hanya Kode Final - Perintah QA
Ketika proyek tumbuh, basis pengetahuan yang kuat terakumulasi, jumlah nuansa dan fitur tumbuh, hubungan logis menjadi lebih kompleks dan beragam. Pada titik tertentu, faktor-faktor ini mulai memberikan pengaruh yang begitu kuat sehingga debugging pra-rilis membutuhkan waktu yang sepadan dengan pengembangan dan membutuhkan sumber daya yang sama.
Untuk menghindari situasi ini, kami datang dengan ide untuk membuat tim QA penuh berdasarkan tim pengujian. Perbedaan utama adalah bahwa pengujian dilakukan tidak hanya pada tahap pengembangan-debugging-rilis, tetapi pada semua tahap proyek:
- QA bertanggung jawab atas kualitas produk dan kesesuaian gaya dan logisnya dengan produk lain dan diterima secara umum pada aturan proyek.
- QA melihat semua artefak yang muncul pada proyek: formalisasi awal tugas, prototipe, spesifikasi, desain, dan, tentu saja, menguji kode dan tata letak, menulis kasus uji, mencakup fungsionalitas yang ada dan baru dengan kisi-kisi autotest.
- Tanpa validasi bahan oleh tim QA, RP tidak memiliki hak untuk meluncurkan tahap berikutnya atau mengirim bahan untuk penerimaan kepada pelanggan.
Pendekatan semacam itu dapat sangat mengurangi risiko debugging yang berkepanjangan dan menunda tanggal rilis.
Timlids - efisiensi atau pertukaran?
Segera setelah pemimpin tim kedua diperkenalkan pada proyek, pertanyaan segera muncul - skema distribusi tanggung jawab apa yang harus diterapkan?
Ada beberapa opsi: membagi proyek berdasarkan jenis kegiatan, yaitu, misalnya, tim A berfokus pada arsitektur, tinjauan kode dan formalisasi teknis tugas, sementara tim B mengelola tim pengembangan dan rilis build, bertanggung jawab atas kesinambungan dan keamanan. Opsi kedua adalah pemecahan produk, di mana setiap pemimpin tim bertanggung jawab penuh atas rangkaian produknya di dalam proyek.
Kedua opsi tersebut bagus dalam hal pemanfaatan sumber daya, tetapi memiliki risiko besar dalam hal pertukaran.
Misalnya, apa yang harus saya lakukan jika salah satu pemimpin tim sakit, pergi berlibur atau berhenti? Akan sulit untuk memasukkan pemimpin tim baru ke dalam proses, karena periode pencelupan dalam peran ini sangat panjang.
Oleh karena itu, ada baiknya menggunakan skema hibrida pada proyek, di mana setiap pemimpin tim terlibat dalam tugasnya sendiri, tetapi ada sejumlah kegiatan di mana semua atau setidaknya dua pemimpin tim tim dikhususkan.
Kegiatan tersebut termasuk yang paling berisiko tinggi, misalnya: arsitektur proyek, kontinuitas, keamanan, produk-produk utama yang merupakan penjualan paling aktif, dan yang kinerjanya ditentukan dalam SLA.
Skema ini, tentu saja, mengurangi produktivitas tenaga kerja, tetapi menghilangkan sebagian besar risiko. Penting untuk menemukan keseimbangan antara efisiensi dan pertukaran, menguraikan daftar momen yang paling penting.
Secara terpisah, masuk akal untuk menghubungkan pemimpin tim dengan kegiatan yang teralienasi: produk yang secara arsitektur terpisah dari bagian utama proyek, atau kegiatan yang dapat dilakukan secara paralel. Sebagai contoh, sangat mungkin untuk memilih tata letak tim yang sepenuhnya akan mengendalikan semua operasi lini depan; dibedakan secara terpisah adalah peran QA pemimpin tim, desain, analitik.
Dapat dipertukarkan anggota tim
Semakin banyak orang yang terlibat dalam proyek, semakin aktif Anda perlu menggunakan alat untuk menurunkan ambang masuk bagi karyawan baru, mereka juga menyederhanakan interchangeability anggota tim yang ada dan mengurangi faktor bus.
Berikut adalah sejumlah alat yang bekerja dengan baik di hampir semua proyek.
Sistem desainSistem desain adalah kit desain dan pustaka komponen yang komprehensif dan terkini dalam repositori. Ini mencerminkan set lengkap elemen standar pada proyek dan memungkinkan Anda untuk mengumpulkan halaman baru dari blok ini. Sistem desain tidak hanya berisi sekumpulan elemen, tetapi juga menjelaskan interaksinya, dan juga berisi contoh kode.
Penggunaan sistem desain dapat sangat menyederhanakan pemahaman karyawan baru, baik manajer, desainer, atau programmer, tentang aturan visual proyek, dan menerapkan solusi yang sudah ada alih-alih terus-menerus menemukan yang baru.
Penggunaan alat-alat tersebut membutuhkan pengeluaran sumber daya yang besar untuk pengembangan dan dukungan. Juga, seringkali diperlukan banyak upaya moral untuk menjelaskan kepada klien mengapa perlu mematuhi sistem ini dan untuk alasan apa proposal seperti "Tambahkan tombol hijau di halaman ini, seperti di situs N, yang terlihat sangat indah" akan ditolak.
DokumentasiSemakin besar proyek, semakin hati-hati setiap produk dan setiap fitur harus didokumentasikan, jika tidak, semakin banyak waktu akan dihabiskan oleh para ahli tentang debugging dan mencari tahu bagaimana satu atau beberapa fungsi lainnya harus bekerja.
Dokumentasi proyek masuk akal untuk dibagi menjadi 4 jenis:
- Spesifikasi antarmuka - deskripsi perilaku fungsi yang diimplementasikan (logika kerja, validasi bidang, set layar).
- Uji kasus (deskripsi skenario pengguna dan hasil dari bagian mereka), berdasarkan pada mereka, jika perlu, autotest dikembangkan.
- Spesifikasi layanan (deskripsi interaksi dengan layanan web, data uji, contoh permintaan-respons).
- Dokumentasi kode (deskripsi komponen, kelas dan hierarki, templat).
Semua dokumentasi harus dikumpulkan dalam basis pengetahuan online (Wiki) dan dipertahankan mutakhir.
GitUntuk mempercepat koneksi pengembang baru dari proyek lain perusahaan, pendekatan standar untuk GitFlow sedang diperkenalkan. Di AGIMA kami menggunakan pendekatan "bekerja dengan dua cabang utama".
Alih-alih menggunakan cabang utama, dua cabang utama dari sejarah proyek digunakan: master untuk rilis dan dikembangkan untuk menggabungkan fungsionalitas yang dikembangkan dari cabang fitur.
Alur kerjaAlat lain yang mengatur dan menstandarkan pekerjaan semua anggota tim adalah alur kerja menurut hari dalam seminggu.
Setiap minggu adalah siklus produksi standar: rilis dilakukan secara ketat pada hari Selasa dan Kamis; Rabu - hari evaluasi; Retrospektif dan perencanaan pengiriman baru dilakukan pada akhir minggu - pada hari Kamis dan Jumat. Ini adalah contoh alur kerja dari salah satu proyek, untuk setiap kasus tertentu, pendekatan harus dikembangkan.
Klien juga harus terlibat dalam alur kerja - sistem seperti itu tidak dapat bekerja secara sepihak.
Yang tidak kalah penting adalah alur kerja pada status tugas, yang menyederhanakan transisi karyawan antar proyek. Itu harus identik pada semua proyek perusahaan. Di AGIMA, tampilannya seperti ini:
Menjaga anggota tim mendapat informasi
Bahkan jika dokumentasinya diatur dengan sempurna pada proyek dan semua proses bekerja seperti jarum jam, tidak mungkin untuk meramalkan semua risiko yang terkait dengan kurangnya kesadaran setiap artis tertentu. Untuk ini, acara reguler berbagai format diselenggarakan.
1. Rapat produkPada pertemuan semacam itu, karyawan yang lebih berpengalaman memberi tahu tim tentang produk tertentu. Aspek-aspek logika bisnis, implementasi teknis dan arsitektur disorot. Kesadaran setiap karyawan tentang nuansa utama produk membantu mengedepankan ide-ide berguna dan membuat keputusan yang tepat di semua tahap implementasi.
2. Bagian infrastrukturProyek ini tumbuh secara dinamis, ini memerlukan pengembangan dan perluasan infrastruktur yang konstan. Pada bagian reguler, masalah dan tugas saat ini untuk pengembangan infrastruktur dibahas, dan kemajuan pelaksanaan masing-masing dibahas.
3. Retrospektif dan perencanaan kerjaPenting untuk mengadakan pertemuan mingguan untuk membahas tugas-tugas yang dilaksanakan selama seminggu terakhir, menyoroti kesalahan dan merencanakan pekerjaan untuk periode akuntansi berikutnya.
Kesimpulan
Aplikasi bijaksana dari semua alat dan pendekatan di atas akan membantu membangun tim yang koheren dan tangguh yang akan dengan mudah skala dengan pertumbuhan lebih lanjut dari proyek.
Tidak diragukan lagi, pengorganisasian sistem semacam itu membawa sejumlah kesulitan dan membutuhkan kompetensi yang mendalam di dalam agensi dan kemauan klien untuk berinvestasi dalam keputusan seperti itu, yang bisa sulit di pasar kami yang sedang berkembang, tetapi upaya semacam itu membuahkan hasil dan menghasilkan kerja sama jangka panjang dan berbuah serta memungkinkan penerbitan pasar adalah produk yang benar-benar berkualitas.