Halo semuanya! Nama saya Alexander Afenov. Saya adalah pemimpin tim dari tim Pemrosesan Pesanan Lamoda. Tahun lalu saya berbicara di TeamLead Conf 2018. Rekaman kinerja tersedia di sini .

Dalam laporan saya, saya akan menceritakan tentang bagaimana saya menjadi seorang pemimpin tim, masalah apa yang saya temui, dan saya akan berbagi berbagai strategi yang mungkin tampak akrab bagi Anda secara individual. Namun, saya fokus pada keuntungan apa yang mereka berikan di kompleks.



Laporan akan dibagi menjadi 3 bagian:

1. Pada bagian pertama, kita akan berbicara sedikit tentang perusahaan dan fitur-fitur IT kita. Ini diperlukan untuk memahami konteks di mana segala sesuatu terjadi.
2. Di detik saya akan berbicara tentang jalan saya di perusahaan.
3. Yang ketiga - tentang metode yang digunakan, pro dan kontra mereka.

Lamoda sebagai perusahaan IT

Lamoda terutama dikenal sebagai pengecer besar pakaian modis, sepatu dan aksesoris di Rusia dan CIS. Namun, hanya sedikit orang yang tahu bahwa untuk persentase atau jumlah tertentu, kami menyediakan layanan untuk berbagai bisnis / badan hukum.

Biarkan saya memberi Anda contoh yang baik. Katakanlah Anda memiliki ruang bawah tanah untuk menjahit dompet. Anda telah membuat situs web untuk produk Anda dan berhasil mempromosikannya. Sekarang banyak orang tahu tentang Anda, tetapi meskipun demikian, Anda memiliki masalah dengan pengiriman, penyimpanan, dan komunikasi dengan pelanggan.

Lamoda dapat memecahkan masalah ini dengan cara berikut:

1. Berikan layanan layanan pengiriman Anda.
   
   LM Express adalah layanan pengiriman kami sendiri, yang telah kami kembangkan dan otomatisasi untuk waktu yang lama.
2. Berikan komunikasi dengan klien. Untuk melakukan ini, kami memiliki pusat panggilan kami sendiri.
3. Simpan barang di rumah atau bahkan jual untuk Anda (komisi).
4. Pasar Produk Mitra dapat ditampilkan di aplikasi seluler kami, di situs atau versi selulernya, dan mitra mengerjakan sisanya sendiri.

Timbul pertanyaan: "Bagaimana Anda mengelola untuk memecahkan masalah Anda dan memenuhi kebutuhan mitra?" Kami memiliki bisnis yang berubah dan berkembang dengan kebutuhan kami sendiri. Kami entah bagaimana meningkatkan, mengembangkan, dan bergerak maju. Pada saat yang sama, Anda masih harus mencocokkan Daftar Keinginan yang datang dari luar. Tampaknya ini membutuhkan IT sendiri, dan bukan yang kecil.

Kita berbicara tentang pengembangan in-house di semua konferensi sejak 2016. Kami mengotomatiskan semua proses sendiri. Ini adalah sekitar seratus layanan berbeda: dari memproses pesanan dan pembayaran hingga bekerja dengan objek alamat dan sertifikat Hadiah. Dukungan untuk semua ini adalah tim yang terdiri dari sekitar 300 orang.

Mengapa saya berbicara tentang TI dan ruang lingkupnya? Karena 300 orang banyak tim. Saat beberapa tim mengerjakan tumpukan teknologi tunggal, kami mencoba menggunakan kembali semua perkembangan ini. Ini bisa berupa bundel, perpustakaan, praktik di bidang teknis. Tetapi kami juga mencoba meraba-raba praktik proses yang sukses antara para pemimpin tim, dan saya akan membicarakannya nanti.

Masalah utama

Saya bergabung dengan perusahaan pada tahun 2015. Tiga hari setelah pekerjaan saya, sebuah pesta perusahaan Tahun Baru dijadwalkan, dan saya memutuskan untuk tidak pergi. Prioritas saya adalah tetap dan memikirkan tugas-tugas saya selama masa percobaan.

Acara perusahaan di Lamoda adalah hari libur bertema yang semua orang suka mempersiapkannya. Karena itu, pada hari X, arsitek departemen saya datang untuk bekerja di pawai, dengan jas berekor. Pada saat itu, tim kami terlibat dalam layanan pemrosesan pesanan. Itu adalah monolit pada kerangka Zend1 lama. Apa yang saya amati? Orang-orang menyiapkan pembebasan paksa dan ingin memperbaiki sesuatu. Setelah memastikan semuanya baik-baik saja, kami berkemas dan pergi untuk liburan.

Dan di sini saya duduk. Rilis ini mulai diproduksi dengan perbaikan terbaru, dan di depan saya ada TV 50 inci yang indah dengan semacam dashboard di atasnya. Di dasbor adalah grafik yang bertuliskan "masalah Kelinci MQ". Tampaknya jika ada data di dalamnya, maka ada sesuatu yang rusak. Tetapi saya tidak tahu ke mana harus mencari untuk menguji hipotesis ini.

Anda mungkin dapat melihat beberapa jenis log. Namun, saya hanya hari ketiga di tempat kerja dan tidak tahu di mana mereka berada. Saya kira saya dapat menemukan tautan ke papan grafana. Mungkin ada baiknya mencari sumber metrik dan menggali di sana? Ya, tapi terlalu bergelombang. Saya ingin ini didokumentasikan entah bagaimana. Dan lagi, ada pertanyaan: siapakah semua orang yang duduk-duduk ini? Dua atau tiga lantai tempat IT didistribusikan. Semua orang melakukan sesuatu, dan saya tidak tahu dengan siapa harus berkomunikasi dengan saya jika ada sesuatu yang salah. Tidak ada tabel pivot yang jelas siapa yang bisa saya hubungi jika saya menyadari bahwa rilisnya rusak. Atau mungkin ada orang yang bertugas, tapi saya tidak tahu?
* (tentu saja dia) *

Ada pertanyaan lain. Yang pertama dan paling konyol, yang akan kami ulangi berulang kali: "Di mana dokumentasinya?". Jawabannya sederhana: serentak di mana pun, di mana pun, dan di benak karyawan berpengalaman. Karena semua orang pergi ke pesta perusahaan, tetapi saya tidak tahu di mana dermaga berada, jawabannya terdengar "tidak ada" bagi saya. Saya memiliki readme di mana saya meluncurkan proyek di laptop saya. Tapi itu tidak cukup. Saya ingin mendapatkan jawaban untuk banyak pertanyaan lain. Misalnya, apa aturan "perilaku" dasar untuk pengembang?

Biarkan saya jelaskan: Saya memutuskan untuk meminta akses ke sistem pertempuran untuk memasuki antarmuka pengguna. Ini akan sangat berguna bagi saya, karena tugas saya untuk masa percobaan adalah mengerjakan ulang sistem otorisasi, dan saya ingin menyodok tombol, masuk ke kios produksi. Saya mengajukan permintaan ke dinas keamanan, yang saya dengan cepat menerima jawaban singkat: "Tidak, kami tidak akan memberikan akses." Ternyata hanya pengguna sungguhan yang mendapatkan akses ke sistem tempur: pekerja gudang, call center, dan sebagainya. Karena saya sebelumnya bekerja di telekomunikasi, saya terbiasa dengan kenyataan bahwa saya telah membaca dan menulis akses ke basis produksi berbagai operator seluler. Dan di sini, ternyata, itu tidak mungkin. Ada sebuah protokol.

Selain itu, saya menemukan banyak syarat dan batasan lain yang dikatakan oleh ketua tim kepada saya. Pada hari-hari awal, dia mendedikasikan saya untuk banyak momen menarik yang berbeda. Ada begitu banyak informasi ini sehingga tidak semuanya dapat diingat dan ditulis.

Pertanyaan-pertanyaan berikut yang menarik minat saya menyangkut perspektif jangka panjang. Misalnya, bagaimana dan di mana harus tumbuh?

Mengapa ini penting? Karena sejak awal aku harus bersikap. Saya datang ke posisi pengembang php tengah. Apa yang harus saya lakukan selanjutnya untuk melebihi harapan, dan di masa depan untuk mendapatkan peringkat yang lebih tinggi, misalnya Senior? Dan satu pertanyaan lagi: "Apa yang diharapkan dari saya di kelas saya saat ini?" Artinya, berapa banyak saya harus terlibat dalam proses seperti review kode, rilis, tugas?

Semua pertanyaan yang saya daftarkan sekarang dijawab oleh ketua tim kami. Dua yang terakhir, yang lebih strategis, dijawab melalui sistem tinjauan kinerja. Saya akan memberi tahu Anda lebih banyak tentang hal itu.

Ulasan kinerja

Setiap 6 bulan seseorang melakukan tinjauan diri sendiri. Dia berbicara tentang hal-hal keren yang berhasil dia lakukan dalam waktu yang ditentukan. Namun, ada jebakan. Hal ini terkait dengan fakta bahwa orang biasanya menunjukkan pencapaian-pencapaian tersebut pada tinjauan-diri, yang cenderung mereka pertimbangkan secara subjektif. Berpikir dalam hal bisnis adalah tidak biasa, dan bahkan jika proyek rutin memungkinkan perusahaan untuk menghasilkan banyak uang, maka bagi pengembang ia mungkin tidak menjadi tantangan atau minat. Ada bahaya bahwa dalam tinjauan seperti itu proyek ini tidak akan diindikasikan.

Langkah selanjutnya adalah peer review. Ini diikuti oleh serangkaian komisi di mana ada komunikasi antara pemimpin tim, manajer departemen, stasiun layanan, dan, jika perlu, direktur SDM. Lalu pesan tentang hasil.

Apa hasil yang mungkin?

Opsi pertama: seseorang berhasil menjadi lebih buruk dalam enam bulan daripada sebelum mulai bekerja. Sepertinya sudah waktunya untuk mengucapkan selamat tinggal. Ini jarang terjadi, tetapi kami akan realistis - itu terjadi.

Opsi lain adalah deuce. Sesuatu sepertinya hilang. Mungkin ada kecepatan, prediktabilitas, ketekunan. Sesuatu perlu diperbaiki.

Tiga - apa yang mereka harapkan, mereka mendapatkannya. Seseorang bekerja dengan kecepatan yang memadai dan dalam semua hal sesuai dengan nilainya.

Empat - melakukan lebih dari yang disepakati. Calon untuk promosi / gaji.

Serigala lima wol. Sepertinya sudah waktunya untuk meningkatkan, memberikan bonus dan sebagainya.

Saya telah melalui beberapa iterasi review semacam itu sendiri. Sebelumnya, diadakan setiap kuartal, yang tidak terlalu nyaman, karena selama 3 bulan kesempatan untuk membuktikan diri tidak selalu terjadi. Sekarang tinjauan terjadi setiap enam bulan.

Jadi, pada awalnya saya tumbuh dari pengembang senior di senior. Kemudian pemimpin tim saya memutuskan bahwa sekarang dia ingin bekerja lebih banyak dengan teknologi dan pindah ke posisi tim teknis (arsitek), dan saya menjadi pemimpin tim.

Jadi apa selanjutnya? Saya perlu melakukan sesuatu, untuk entah bagaimana menguasai.

Hal pertama yang Anda temui adalah pertanyaan yang sama yang kami bicarakan sebelumnya, hanya sekarang pada tingkat yang sedikit berbeda. Artinya, masih belum jelas: di mana dokumentasi itu? Sekarang saya perlu entah bagaimana berkomunikasi dengan departemen lain, berkomunikasi dengan prospek lain, arsitek dan orang lain, berpikir pada tingkat yang lebih tinggi. Tetapi pada tingkat dokumentasi ini, mungkin juga tidak.

Poin lainnya adalah “aturan dasar” yang sama. Apa yang bisa saya lakukan

Saya kira saya bisa menindaklanjuti tugas, melakukan review kode. Mungkin sekarang saya memiliki kekuatan untuk mengubah proses, entah bagaimana berkomunikasi dengan orang-orang.

Bagaimana dan di mana harus tumbuh? Pertanyaan ini tidak hilang, karena Anda mungkin ingin menjadi kepala departemen (pimpinan kelompok).

Nah, pertanyaannya - apa yang diharapkan dari saya, juga menurut saya cukup bisa dimengerti.

Dan sekarang Anda harus dapat menjawab semua pertanyaan ini tidak hanya untuk diri Anda sendiri, tetapi untuk seluruh tim. Dalam kasus saya, tim direkrut hampir dari awal. Ternyata untuk lima atau tujuh orang saya harus mengatakan segalanya, menjelaskan, menetapkan tujuan. Butuh waktu dan usaha. Hal-hal seperti itu perlu direncanakan dan dipikirkan. Jadi, apa tanggung jawab pemimpin tim?

Apa yang harus memimpin tim?

Pertama-tama, ini bekerja dengan tugas-tugas : perumusan, penyesuaian, deskripsi orang yang menerima tugas di bawah kelas. Sebagai contoh, untuk seorang junior saya lebih suka melakukan deskripsi yang sangat rinci dan berharap dia untuk menulis kode dan tes yang benar. Sebagai senior, saya akan mengomunikasikan tujuan teknis atau bisnis, dan dia akan bebas memutuskan sendiri bagaimana mencapainya. Bagaimanapun, semua ini membutuhkan waktu.

Tentu saja, Anda perlu mengeluarkan ulasan kode ketika konflik muncul selama itu. Pantau apa yang terjadi, pindahkan tugas berdasarkan status. Saya juga melakukan tugas seorang insinyur rilis secara teratur. Anda harus sering memikirkan tentang bagaimana penempatan kami memengaruhi orang lain. Layanan yang saya lakukan adalah pemrosesan pesanan. Itu terkait dengan hampir semua sistem Lamoda dan, karenanya, mampu mempengaruhi banyak proses bisnis selama rilisnya.

Poin lainnya adalah pemantauan, peringatan, dan perubahan yang terkait dengan hal ini. Jika fitur bisnis telah muncul, perlu untuk memantaunya, memperkenalkan metrik baru, menutup notifikasi, menginformasikan layanan dukungan, dan sebagainya. Ini semua adalah masalah arsitektur. Saya tidak punya arsitek khusus di departemen saya saat ini. Saya melaksanakan tugasnya dalam kasus-kasus tersebut ketika Anda membutuhkan solusi spesifik dalam kerangka tugas / proyek tertentu.

Masih perlu memperhatikan komunikasi . Ini termasuk pertemuan pribadi yang berlangsung kira-kira setiap dua minggu dengan masing-masing pengembang; retrospektif, perencanaan, komunikasi dengan manajer dan departemen lain. Tapi tetap saja menyenangkan tidak melakukan pelanggaran.

Banyak yang mengatakan bahwa akan luar biasa setelah 10 tahun pembangunan untuk mendapatkan rasio "manajemen untuk pengembangan" sekitar 80 hingga 20. Bahkan ini tidak selalu dapat dicapai. Akibatnya, Anda pasti akan kehilangan keahlian dan keluar dari tren saat ini. Perlu untuk terus tumbuh lebih jauh.

Ada beberapa strategi yang memungkinkan untuk bagaimana Anda dapat tumbuh dalam hal posisi Anda. Di bagian selanjutnya, kita akan berbicara tentang bagaimana rotasi peran dalam tim membantu meningkatkan faktor-bus.

Rotasi peran

Saya akan memberi tahu mereka yang belum tahu dan memberi tahu Anda apa faktor busnya.

Faktor bus adalah angka yang menunjukkan bahwa jika sejumlah pengembang "mengetuk bus", maka pekerjaan pada proyek akan berhenti. Itu dapat memanifestasikan dirinya pada berbagai tingkatan. Sebagai contoh, ini mungkin merupakan faktor bus untuk beberapa elemen sistem kompleks spesifik.

Misalkan kita memiliki kasus di mana kita perlu memilah sistem pelaporan tertentu. Pengembang menghabiskan 5 hari untuk melakukan ini. Bugnya rumit, tapi sudah diperbaiki, dan semuanya baik-baik saja. Kemudian masalah lain muncul dalam modul yang sama, dan pengembang yang sama menemukan dirinya cuti sakit. Ini berarti bahwa orang berikutnya harus menghabiskan waktu yang sama untuk menyelesaikan masalah. Anda harus memikirkannya dari awal, karena tidak ada dokumentasi (haha).

Apa yang akan dibahas lebih lanjut adalah strategi untuk meningkatkan faktor bus. Dan mereka akan datang bersama dalam satu gambar, yang agak menyenangkan dengan semua tugas pemimpin tim sebelumnya, tentang yang saya bicarakan.

Selain dokumentasi, pengalaman nyata diperlukan. Artinya, Anda memerlukan tim yang telah berhasil menyentuh berbagai bagian sistem, dan sekarang siap untuk menghadapi tugas apa pun. Tetapi jika tim baru saja berkumpul, maka semua ini tidak akan datang dari mana pun dari awal. Tujuan utama saya adalah memberi tahu bagaimana mungkin untuk menggabungkan beberapa pendekatan berbeda yang akan memungkinkan penyelesaian masalah dengan dokumentasi dan pengalaman.

Insinyur Pendukung

Setiap orang telah mendengar tentang pengembang virtual. Tapi kami tidak akan berbicara tentang VR-kit dan bukan tentang orang-orang di situs terpencil, tetapi tentang peran insinyur pendukung.

Siapa insinyur pendukung?

Kami memiliki seorang pria yang mem-parsing backlog dukungan. Dia datang untuk bekerja, dia tidak punya tugas tunggal. Dia membuka jaminan untuk dukungan dalam pelacak tugas (Jira), dan ada tugas diurutkan berdasarkan kekritisan. Dia mengambil yang paling penting dan mulai memperbaiki. Setelah semua masalah diselesaikan, ia menuliskan mengapa itu pecah dan bagaimana menghindarinya di masa depan. Jika dia tidak memiliki dukungan lain (ini lucu, karena dukungan itu tidak pernah berakhir), maka dia melihat tumpukan teknis, yang sudah cukup besar.

Sedikit gangguan: kita berbicara tentang sistem satu setengah ratus ribu baris pada kerangka Zend 1 lama. Arsitek tim sebelumnya pernah mengatakan bahwa menurut sistem kami, kami memiliki hutang sebesar ini - ini bukan hutang teknis, melainkan hipotek teknis. Karena itulah judul laporan.

Jika tidak ada yang dilakukan, insinyur pendukung dapat mengambil beberapa tugas non-prioritas dari sana, yang tidak sayang untuk berhenti dan kembali ke dukungan yang baru muncul. Ini biasanya terjadi. Dan dia tidak melakukan ini selama lebih dari seminggu, karena itu akan menjadi jalan langsung menuju frustrasi. Jika selama dua minggu iterasi keseluruhan Anda hanya terlibat dalam dukungan menyapu, ini akan sangat menurunkan motivasi Anda. Anda memperbaiki, memperbaiki, memperbaiki, dan tidak ada akhirnya. Karena alasan ini, setiap minggu kami mentransfer peran insinyur pendukung ke orang berikutnya.

Insinyur rilis

Ada posisi virtual lain yang sangat nyaman untuk membongkar tim pemimpin - ini adalah seorang insinyur rilis. Dia menyiapkan rilis untuk versi perbaikan yang sudah direncanakan sebelumnya, mengumpulkan cabang, menyiapkan build, menjalankan semua tes. Jika tes berjalan secara otomatis, maka itu hanya mengontrol hasilnya. Dalam bidang tanggung jawabnya, pilih betapa indahnya bergulir tanpa downtime dan efek khusus untuk sistem yang bergantung pada kita.

Itu terjadi bahwa kita perlu komunikasi dengan tim lain sebelum penyebaran untuk memperingatkan mereka tentang perubahan. Akibatnya, insinyur rilis mengeluarkan semuanya dan melihat apakah ada sesuatu yang pecah. Kami menggunakan ini, Sentry , Prometheus , Icinga , lihat Elastic, menggunakan Kibana . Insinyur rilis memutuskan apa yang harus dilakukan jika terjadi kesalahan. Artinya, adalah tanggung jawabnya untuk memutuskan apakah semacam perbaikan terbaru diperlukan, atau kita semua bangkrut, kehilangan uang dan perlu melakukan kemunduran. Keputusan untuk mundur hanya dilakukan sebagai upaya terakhir, tetapi ini juga terjadi.

Dia (insinyur rilis) mencatat masalah yang muncul. Jika ada yang robek, akan bagus untuk belajar dari kesalahan Anda. Untuk melakukan ini, ia menunjukkan tanggal rilis dan kesalahan yang menyebabkan masalah. Ini memungkinkan insinyur rilis berikutnya untuk melihat masalah umum dan menghindarinya. Ya, dia tidak melakukan ini selama lebih dari satu minggu berturut-turut, karena mengumpulkan rilis itu mahal.

Jika rilisnya besar, maka setengah hari terbang dengan mudah dan sangat sulit untuk memutuskan waktu untuk beralih ke tugas Anda. Misalnya, Anda memulai beberapa perakitan yang membutuhkan waktu 20 menit. Saat pertemuan sedang berlangsung, Anda dapat merokok atau memikirkan kehidupan. Tetapi jika Anda kembali ke tugas, dan perakitan berhasil, Anda perlu beralih lagi. Secara umum, ini adalah proses yang agak suram, menarik diri dari perkembangan normal dan tidak memungkinkan untuk memasuki aliran. Untuk alasan ini, minggu berikutnya insinyur rilis adalah orang yang berbeda.

Tekhlid

Posisi virtual lain yang lebih menarik adalah pemimpin teknis.

Seorang arsitek (kadang-kadang disebut dengan cara ini) memasuki kehebohan ketika ada tugas penting besar atau proyek baru diluncurkan. Ini berarti bahwa ia bertanggung jawab atas desain, pengembangan, dan peluncuran. Dia diberi hak untuk berkomunikasi dengan pemimpin tim dan manajer tim, membuat keputusan teknis dan kewajiban untuk mendokumentasikannya ditransfer. Jika ada sampah yang terjadi di awal, ia mencatat semua masalah yang terjadi dan penyebabnya dengan cara yang sama seperti yang dilakukan oleh seorang insinyur pelepasliaran atau insinyur pendukung.

Kesimpulan

Apa yang kita dapatkan sebagai hasilnya?

Rotasi peran dalam tim untuk waktu yang lama (setidaknya enam bulan) memungkinkan bahkan bagi seorang junior yang belum berpengalaman untuk mendapatkan keterampilan untuk bekerja dengan berbagai bagian sistem dan jenis tugas.

Pada awalnya, saya berbicara tentang fakta bahwa dokumentasi dan pengalaman nyata dapat membantu menyelesaikan masalah yang khas. Setelah menerapkan praktik yang dijelaskan, bukan fakta bahwa Anda akan menyelesaikan masalah dokumentasi, tetapi pengalaman berkualitas tinggi dan beragam akan diperoleh oleh semua peserta tim pengembangan. Dengan rotasi panjang peran virtual, seseorang dapat menyentuh berbagai bagian sistem sebagai teknisi pendukung. Sebagai seorang insinyur pelepasliaran, ia belajar untuk menggunakan, berkomunikasi, mengamati, membuat keputusan dengan cepat. Jika dia mendapat peran ahli teknis, maka dia sedang bersiap untuk secara mandiri menggerakkan proyek-proyek yang lebih besar dan lebih penting.

Mulai saat ini, pemimpin tim dapat dan harus mendelegasikan tugasnya kepada bawahan, karena, jika Anda ingat, pemimpin tim memiliki tugas untuk tidak mengeluarkan dirinya sendiri dan tumbuh di suatu tempat.

Berkat praktik semacam itu, menjadi mungkin untuk akhirnya memberi seseorang bagian dari pekerjaan mereka. Misalnya, rilis. Ini adalah 4-8 jam seminggu, yang tiba-tiba dilepaskan dari waktu ke waktu. Sekarang Anda dapat menggunakannya untuk pengembangan, membaca artikel, menyelesaikan masalah lain. Kesalahan besar adalah tidak membunyikannya di kalender dan membelanjakannya pada pertemuan yang tidak terlalu berguna. Meskipun, sebagai suatu peraturan, ini terjadi :) Sekarang pemimpin tim dapat bersukacita, karena ia memiliki kesempatan untuk tidak terlalu gugup dan mempercayai bagian dari pekerjaannya kepada karyawannya. Jika sesuatu terjadi padanya, proyek tidak akan bangun.

Sebagai hasilnya, kami meningkatkan faktor bus dari pimpinan tim. Tim, pada gilirannya, dapat memastikan bahwa jika ada yang tidak beres dengan pemimpin tim, maka salah satu dari mereka akan siap untuk mengambil pekerjaan dan menanganinya.

Tentu saja ada batasannya. Pendekatan ini tidak mungkin jika Anda melakukan semuanya sendiri (orang-departemen).Jika pasangan lebih rendah dari seseorang, maka sudah ada kesempatan untuk memutar jam tangan dan melepaskan. Tiga mitra dan lebih banyak bahkan lebih baik.

Dalam kasus saya, ada 5 pengembang, tiga di antaranya berbagi peran virtual di antara mereka sendiri. Dua lainnya hanya terlibat dalam pengembangan, fitur-fitur baru. Mereka tidak terlibat dalam rilis, dukungan, dan sebagainya.

– . , , , . , . . , - “” , - . , , , , . , . , .

, : « , , , ” . , , , . . , . - .