Dalam artikel itu, saya akan berbicara tentang pengalaman saya sebagai pemimpin tim di perusahaan pengembangan situs. Agar lebih bermanfaat dan lebih mudah bagi semua orang untuk membaca, artikel ini dibagi menjadi beberapa bab, yang masing-masing menceritakan tentang satu masalah terpisah dan solusinya. Meskipun, jika mungkin, kronologi peristiwa akan dipertahankan.
Saya berharap bahwa pengalaman yang dijelaskan di bawah ini akan menjadi rake orang lain, dan dalam komentar saya sendiri akan menarik sesuatu dari rekan yang lebih berpengalaman.
Tetapi tidak ada nama, perusahaan, pelanggan, nama kolega. Perjanjian tanpa pengungkapan, semuanya.
Latar belakang Bagaimana dan di mana saya menjadi pemimpin tim
Ini adalah perusahaan pertama di mana saya langsung datang dengan seorang pemimpin tim. Bagi saya itu adalah lompatan kuantum dalam hal pertumbuhan karir. Saya datang ke pekerjaan terakhir (1,5 tahun) sebagai perantara dan dibesarkan di sana untuk senior. Tetapi gradasi pengembang terlalu subjektif dan seringkali hanya bergantung pada perusahaan tempat mereka bekerja. Untuk sementara saya banyak mempelajari pertanyaan tentang mengevaluasi programmer dan pada dasarnya semuanya bermuara pada kenyataan bahwa jika "mereka mengambil menengah / senior / senior, saya menjadi menengah / senior / senior". Ketika saya mulai mencari pekerjaan, saya sudah cukup memiliki posisi senior (dan saya mencarinya), tetapi tawaran timlidisme mengalahkan saya dan sedikit tersanjung.
Sebenarnya, ketika saya sedang mencari lowongan, pada hari kedua saya terpikat ke sebuah perusahaan metropolitan yang mengembangkan situs di Bitrix (jadi semuanya terjadi dengan latar belakang mengembangkan situs di Bitrix). Sebaliknya, saya sudah lama bermimpi untuk meninggalkan Bitrix, tetapi kesempatan untuk memenuhi potensi saya dalam kualitas baru dan gaji yang baik membuat saya tidak punya kesempatan untuk menolak.
Fakta lucu: satu-satunya syarat untuk mempekerjakan saya adalah bahwa saya dapat memilih sendiri tumpukan teknologi, tetapi dalam kasus apa pun saya harus menolak Bitrix jika klien bersikeras melakukannya.
Di tempat baru
Di tempat baru adalah bos teknis yang sangat baik, manajer yang buruk, Juni, Tengah, dan beberapa proyek yang sangat besar di Bitrix. Ini situasi yang agak aneh dan saya masih tidak mengerti bagaimana itu berkembang dan tidak segera runtuh. Tapi mungkin saya diundang hanya untuk menyelesaikan masalah.
Pada hari-hari pertama, banyak masalah "anak-anak" yang mencolok:
- informasi proyek disimpan di kepala satu atau dua orang dan tidak di tempat lain. Juga tidak ada instruksi dan dokumentasi, dan untuk mengetahui bagaimana fungsi ini atau itu berfungsi, perlu untuk menyiksa orang yang membuatnya, jika memang kami yang membuatnya.
- tidak ada sistem dan proses yang mapan, semuanya dilakukan "entah bagaimana", "karena kebiasaan". Karenanya, kesombongan, kebingungan, kegagalan memenuhi tenggat waktu, stres
- tugas dipertimbangkan dengan kata-kata. Pelacak hanya memiliki nama tugas, hanya untuk dapat memesan waktu di suatu tempat (Anda harus mengetik 40 jam seminggu)
- perkembangannya sendiri juga tidak begitu panas:
- di suatu tempat, sesuatu sedang dikembangkan bahkan di luar gita
- di suatu tempat, programmer bergantian mengedit file di satu server
- di suatu tempat ada situs pengujian, tetapi di suatu tempat mereka tidak (tetapi dalam kasus apa pun mereka tidak banyak membantu)
- Selain itu, di mana-mana ada govnokod yang sangat, sangat banyak. Mengantisipasi komentar, Bitrix sendiri, sayangnya, tidak ada hubungannya dengan itu.
- Semua komunikasi terjadi di Skype. Tetapi saya hanya memiliki ketidaksukaan pribadi terhadapnya
Secara umum, semuanya jelas buruk, perbaikan dapat segera dimulai, tanpa melakukan studi pendahuluan. Ini bahkan membuat saya bahagia sampai batas tertentu, karena Anda dapat mempengaruhi indikator dari bulan-bulan pertama. Mereka benar-benar belum dipertimbangkan, tetapi karena Pareto, ini belum penting.
Saya kecewa, prosesnya berjalan agak lambat selama bulan-bulan pertama. Pertama, saya sendiri harus mengerjakan tugas klien selama 8 jam sehari, sebagai programmer, karena saya tidak punya cukup tangan. Kedua, dalam kondisi tekanan waktu seperti itu, cukup berbahaya untuk membuat perubahan besar yang dapat menyebabkan kebingungan dan kehilangan kode atau waktu.
Sekarang kita langsung menuju artikel dan pemecahan masalah. Hal pertama di perusahaan baru itu entah bagaimana berorientasi.
Menarik informasi dari tujuan karyawan
Ketika saya tiba, saya sama sekali tidak tahu tentang proyek atau klien, dan informasi ini tidak disimpan.
tidak ada dalam bentuk teks. Karena itu, hal pertama yang saya mulai menarik informasi dari tujuan rekan-rekan dalam teks.
Pada dasarnya, perusahaan pengembangan memiliki 2 subset besar teks penting dan / atau berguna:
- instruksi, peraturan, artikel, deskripsi fungsional, cerita pengguna, ...
- Tugas dengan nama, deskripsi, komentar, catatan waktu, tanda tangan untuk melakukan, komentar dalam kode, autotests, ...
Pada awalnya, saya hanya meminta kolega baru saya untuk menuliskan untuk saya hal-hal spesifik dari paragraf pertama, tetapi tentu saja semua orang malas, terutama karena instruksi menulis bukan fitur untuk memotong. Tetapi karena pada awalnya saya masih memiliki tampilan yang sepenuhnya bebas-rokok dan saya harus mempelajari proyek-proyek, melihatnya untuk pertama kali, saya baru saja mulai menerjemahkan penelitian saya ke dalam teks, sehingga menciptakan instruksi dan deskripsi fungsi.
Itu juga beruntung bahwa pada saat yang sama, perusahaan mulai secara aktif pindah ke scrum (hanya kebetulan), perangkat lunak yang bekerja berubah (juga kebetulan), masing-masing, proses bisnis diciptakan dari awal. Dan untuk beberapa alasan saya awalnya memiliki otoritas besar di mata rekan-rekan saya. Oleh karena itu, saya baru mulai menulis aturan sendiri (dalam kompetensi) dan membangun kembali orang-orang di atasnya, yaitu, sebenarnya, mendikte aturan dan menjadi contoh penerapannya.
Solusi untuk masalah dengan perumusan dan pengelolaan tugas ditunda selama lebih dari satu bulan. Ini ternyata menjadi hambatan dan dalam bab-bab selanjutnya saya akan mengangkat topik ini lebih dari sekali.
Di awal pekerjaan saya, manajer itu mengatur tugas dengan sangat buruk. Contoh: nama tugas adalah "Perbaiki bug di situs" dan hanya itu: tidak ada deskripsi, tidak ada tangkapan layar, hanya nama dan referensi untuk proyek. Tentu saja, ada upaya untuk menyampaikan prinsip-prinsip SMART dan pentingnya menjelaskan tugas kepada manajer, tetapi semua usaha dibubarkan pada “Saya tidak punya waktu untuk melukis tugas”.
Pada suatu waktu saya mencoba mengambil bagian dari tanggung jawab untuk mengatur tugas, tetapi ironisnya saya juga tidak punya cukup waktu untuk ini, karena saya menulis kode hampir sepanjang waktu.
Tetapi masalah terkait untuk mendapatkan status tugas saat ini setiap saat, kami memutuskan untuk memotong, melalui koordinasi telepon dan rencana untuk hari itu.
Penambahan staf, integrasi tim
Hampir pada awalnya jelas bahwa orang-orang sangat kurang (saya sendiri yang menulis kode waktu penuh, tetapi kami masih tidak punya waktu).
Yang pertama memutuskan untuk mengambil bagian depan, karena kedua proger di perusahaan adalah punggung (dan saya juga mengidentifikasi diri saya lebih banyak dengan backend), dan ada cukup banyak tugas, terutama dalam tata letak, dan tugas pada reaksi dan petunjuk mulai menjulang di cakrawala.
Sangat beruntung bahwa saya memiliki (dan memiliki) seorang teman, yang pada saat yang sama mulai berpikir untuk meninggalkan pekerjaan lepas, jadi kami dapat dengan cepat mengisi lowongan, dan saya menerima bonus karena membawa seorang karyawan (kelebihan lainnya ke pihak berwenang, sebelum itu) dilihat jam-penghargaan).
Hampir segera setelah bagian depan, 2 beck ditemukan. Dan di suatu tempat pada saat yang sama, joon itu pergi (yang kodenya menyodok saya beberapa bulan setelah kepergiannya).
Secara total, situasi berikut berkembang:
- satu "orang tua"
- saya
- tiga pemula absolut
- pekerjaan belum ditetapkan
- beberapa pengetahuan sudah hilang
Wajar jika puluhan pertanyaan dari pendatang baru langsung menghujani saya, sebagai pemimpin tim. Pada dasarnya, ini adalah pertanyaan tentang siklus hidup kode (di mana menulis kode, bagaimana menunjukkan ke mana harus mengirimkannya nanti, bagaimana mengumpulkan rilis), tentang manajemen tugas (bagaimana mengambil tugas ke dalam pekerjaan, bagaimana menunjukkan status, bagaimana menentukan prioritas) dan bagaimana bekerja dengan git . Plus, para lelaki itu masih mencoba untuk mengajukan pertanyaan "Bagaimana cara kerjanya?", "Apakah kita memiliki B di situs kita?", Tetapi hampir semuanya pada saat itu berkurang hanya karena kebutuhan untuk mempelajari kode.
Pertama-tama, penting untuk memberi programmer kesempatan pada dasarnya bekerja dan menulis kode sendiri. Saya melakukan percakapan pengantar dengan mereka, menjawab pertanyaan mereka, lalu tentu saja saya memutuskan untuk mengurangi semua pertanyaan dan skema menjadi sebuah artikel, yang kemudian berubah menjadi kuliah, dan kemudian menjadi skema kerja yang benar-benar baru di perusahaan, yang akan saya bahas di bab berikutnya.
Di sini ada baiknya mengucapkan beberapa patah kata tentang proses perekrutan di perusahaan kami, yang masih berfungsi.
Proses perekrutan
Pertama, kami memiliki bonus untuk menarik seorang karyawan, yang merupakan praktik yang cukup bagus.
Kedua, kami memutuskan untuk tidak mengatur ujian pada saat wawancara, tetapi untuk memberikan tugas yang sangat banyak, dekat dengan tugas kami sehari-hari. Ini nyaman karena waktu yang dihabiskan untuk merekrut dikurangi hanya sampai pencarian resume yang sesuai dan wawancara yang mudah dengan pelamar untuk memeriksa kecukupan dan cerita tentang tugas tes, dan, tentu saja, langsung memeriksa tugas.
Juni benar-benar dapat memecahkan masalah dalam beberapa malam, banyak membuatnya banyak kebebasan dalam implementasi, perbaikan dan chip yang jelas. Fleksibilitas implementasi inilah yang membantu kami mengevaluasi level pelamar. Kami segera mengatakan bahwa hal yang paling penting bagi kami adalah untuk memenuhi tenggat waktu untuk menyelesaikan masalah (pelaksana memanggil dirinya sendiri) dan pada akhirnya menunjukkan kode kerja dalam repositori. Kami tidak menetapkan penggunaan pendekatan dan teknologi apa pun, mereka dipilih oleh pelaku, tetapi untuk memenuhi dan memberikan kiat, kami mencantumkan kemungkinan peningkatan dalam daftar, seperti tugas dengan tanda bintang, misalnya, bekerja melalui Ajax, ext. validasi kembali, perlindungan spam, desain modul, penggunaan D7, ...
Total:
- Menurut ringkasan dan wawancara, kita dapat menilai sifat orang tersebut
- dengan tenggat waktu untuk menyelesaikan tugas, fakta bahwa kodenya berfungsi dan penggunaan gita, kami membuat keputusan untuk mempekerjakan
- berdasarkan kualitas kinerja, kami menentukan level dan, karenanya, gaji yang dapat kami tawarkan
- ditambah sudah pada tugas tes kami menunjukkan tugas apa yang harus diselesaikan di tempat baru
Menetapkan pengembangan kode dan sistem pengiriman
Pada saat itu, kami memiliki beberapa proyek yang dikembangkan secara acak:
- di suatu tempat dalam pertempuran ada master, di tempat lain cabang
- di suatu tempat ada situs pengujian, di suatu tempat tidak
- dan jika ada, maka alamat setiap orang berbeda
- git, pada prinsipnya, digunakan dengan lemah dan dengan derit
- perubahan basis data manual
- ...
Pada awalnya, saya mencoba untuk memperbaiki situasi dalam porsi kecil, sehingga programmer membutuhkan lebih sedikit untuk belajar kembali, dan, karenanya, menjadi bingung. Sebagai contoh, saya mengeluarkan folder bitrix dari bawah gita, mengganti nama cabang utama kembali menjadi master.
Tetapi ketika pengisian besar datang kepada kami, situasinya menjadi kritis. Saya harus menjelaskan banyak hal, mengingatkan dan menulis instruksi yang tidak masuk akal, karena struktur pengembangan saat ini sama sekali tidak sangat intuitif.
Saya bukan penggemar instruksi seperti itu, saya percaya bahwa kehadiran mereka adalah indikator dari masalah itu sendiri, jadi diputuskan untuk membuat sistem bersama untuk semua proyek yang perlu dipahami sekali dan yang, dengan strukturnya sendiri, menghilangkan banyak masalah dan pertanyaan.
Sistemnya adalah sebagai berikut:
- setiap pengembang memiliki platform kerja pribadi jarak jauh di mana ia bekerja
- ada platform di mana fungsionalitas diakumulasikan untuk rilis berikutnya
- jika perlu, ada platform demonstrasi untuk mendemonstrasikan semua permulaan fungsi
- semua kode untuk satu tugas disimpan di satu cabang terpisah, di mana nama cabang sama dengan nama tugas di pelacak
- untuk mengisi kode pada platform umum, Anda hanya perlu memegang cabang di suatu tempat dan mendorong
- perubahan pada basis data disimpan sebagai file migrasi di cabang tugas
Saya memberikan kuliah besar tentang masalah sistem ini, dan kami memulai transisi percontohan untuknya pada satu proyek, di mana kami baru saja melempar senior yang baru diakuisisi.
Proses mentransfer semua proyek ke sistem ini, tentu saja, tertunda (misalnya, pada satu proyek kami tidak bisa secara mistis pindah ke master pertama kali), dan itu masih berlanjut, tetapi sebagai hasilnya kami mendapat setidaknya:
- kemampuan untuk melepaskan hanya tugas-tugas yang diperlukan, dan tidak melepaskan fungsionalitas yang belum selesai bersama dengan kode yang berguna
- melakukan rilis tugas tanpa melibatkan pembuat kode
- bekerja paralel pada proyek antara pemain
- jangan kehilangan kode
- uji fungsionalitas yang diisolasi dari yang lain dan jangan menghentikan pekerjaan program
Semua ini sama sekali tidak ada sebelumnya. Selain itu, Anda tidak perlu menjelaskan detail tambahan tentang bekerja dengan git atau menguji situs sekarang, karena semuanya universal dan intuitif.
Scrum, komunikasi, peraturan
Tentu saja, dalam artikel saya bermaksud berbicara tentang bagaimana saya membantu dalam pengembangan perusahaan sebagai pemimpin tim, tetapi Anda tidak dapat berbicara tentang pengembangan perusahaan kami tanpa menyebutkan bos kami dan inisiatifnya, jika tidak maka tidak akan sepenuhnya jujur.
Pertama, dia memperkenalkan scrum, dan pada saat kedatangan saya, proses di perusahaan mulai aktif dibuat kembali. Juga pada saat itu memindahkannya dari Bitrix24 ke Jira.
Scrum tentu saja membawa lebih banyak ritme ke perusahaan dan mengurangi kekacauan. Pelatihan ulang manajer, pelaksanaan panggilan koordinasi mereka, pembukaan / penutupan / perencanaan sprint dimonitor oleh kepala sendiri, sebagai senior dalam tautan ini.
Dia juga banyak bekerja pada manajer sendiri, terutama pada bagaimana mereka berkomunikasi dengan klien dan programmer, karena sebagian besar pekerjaan mereka (tetapi, tentu saja, tidak terbatas pada) terdiri dalam berkomunikasi: mengisolasi programmer dari klien, mentransmisikan keinginan klien untuk tugas di backlog dan sprint, temukan dan menceritakan kembali kisah pengguna. Semua ini menghasilkan banyak peraturan: tentang komunikasi dengan klien, tentang pengaturan tugas, bekerja dengan jaminan, tentang penerimaan bug dalam pekerjaan. Penekanan kuat diberikan pada komunikasi dan tautan manajemen benar-benar menunjukkan kemajuan.
Transisi ke scrum itu sendiri, tentu saja, sangat sulit dan pada saat menulis artikel ini, kita belum menjadi profesionalnya, meskipun ini semua mengarah ke sana. Dan saya sangat senang bahwa saya menerima banyak pengetahuan baru tentang metodologi dan produk yang fleksibel dari Atlassian.
Manajer baru. Teks, pengaturan tugas, backlog
Pada titik tertentu, orang lain datang untuk membantu kami membuat lompatan kuantum - manajer baru (sebelum itu kami memilikinya).
Saya tidak berharap saat ini, karena kami tidak memiliki begitu banyak proyek dan programer dan secara teori hanya satu manajer yang cukup. Tautan ini merupakan titik lemah di perusahaan, tetapi kami mencoba menyelesaikan masalah ini dengan mengembangkan staf yang ada. Kebetulan seorang manajer yang sangat baik, yang saya kenal dengan baik, memutuskan untuk berganti pekerjaan, bos saya mengetahui hal ini, ketika dia tiba-tiba mewawancarai kontraktor kami dan saya menyebutkan kejadian lucu ini, dan kami memanggilnya untuk diri kami sendiri. Penghargaan lain)
Pada awalnya, manajer baru mengulangi bagian dari jalan saya, karena dia menghadapi masalah yang sama (dia tidak tahu apa-apa dan tidak bisa membaca) dan mulai lagi dari awal, tetapi dengan perbedaan bahwa dia tidak menyentuh kode, infrastruktur pengembangan dan keterampilan program, tetapi bekerja dengan menetapkan tujuan, berkomunikasi dengan pelanggan, membersihkan simpanan, dan juga dengan rajin menarik informasi dari kepala manajer lama. Secara khusus, hal pertama yang saya tarik adalah daftar kontak pelanggan dan kontraktor.
Tim sudah mengenalnya, karena kami pernah mengundangnya sebagai dosen untuk memberi tahu kami tentang manajemen waktu. Ditambah lagi, tugas-tugas baja mulai diajukan secara lebih rinci, dia tidak menambahkan negativitas dan tidak mentransmisikannya dari klien, status tugas menjadi lebih relevan setiap saat. Karena itu, kami segera menaruh harapan besar padanya.
Untuk minggu-minggu pertama, ia dan bosnya membersihkan tumpukan di satu proyek, khususnya, mereka menemukan periode 2 bulan yang terlambat dan epik yang belum dimulai. Selain itu, pada prinsipnya, banyak tugas muncul yang perlu dilakukan sebulan yang lalu. Baik, tentu saja, bahwa tumpukan simpanan sudah dibersihkan, tetapi sudah terlambat.
Dia sendiri benar-benar "menutup telepon" dari kekacauan dan berulang kali mencoba untuk pergi, tetapi kami memperbaiki hubungan manajerial dengan satu atau lain cara. Tugas cenderung hilang di backlog, programmer cenderung bertanya lagi.
Moral dari cerita ini adalah pada akhirnya.
Krisis
Hampir setengah tahun setelah mulai bekerja, saya harus pergi berlibur. Ngomong-ngomong, saya menyetujui liburan bahkan ketika melamar pekerjaan, seperti yang direncanakan sebagai bulan madu, sehingga periode ketidakhadiran saya diketahui jauh sebelumnya. Tapi bagaimanapun, tentu saja, saya gugup sampai akhir, karena kami baru saja berhenti bekerja "untuk dipakai".
Pada minggu sebelum liburan, saya menyelesaikan tugas-tugas pendelegasian, mengajar orang-orang terpilih untuk melakukan tugas-tugas khusus di luar kode, menugaskan masing-masing tanggung jawab programmer untuk proyek tertentu, menyelesaikan atau mentransfer semua tugas saya saat ini (saya masih pemrograman hampir sepanjang hari). Tidak ada bencana yang terjadi pada pertengahan Juli.
Dan di hari-hari pertama liburan juga, tidak ada yang berarti masalah.
Dan kemudian ada krisis.
Pada satu proyek, klien kehabisan kesabaran karena kenyataan bahwa ekspektasinya terhadap tugas (tenggat waktu, daftar, prioritas) tidak sesuai dengan kasus tersebut. Kami sendiri memperhatikan hal ini belum lama ini dengan pemrosesan lengkap dari simpanan dan komunikasi aktif dengan klien (bab tentang manajer baru), tetapi sudah terlambat.
Dan pada proyek kedua, mereka akhirnya menerima tugas yang sangat besar dan sudah lama dinantikan, menyelesaikan pengujian dan merilisnya. Tetapi fungsionalitas baru tiba-tiba merobohkan situs pertempuran di bawah beban berat, dan tengah dan depan tengah tidak bisa berbuat apa-apa selama seminggu. .
, . , . , , .
vue, ( , ).
— , , , - , “ / / / ”.
, , , , .
, , , , , .
, . , - . , - .
. ( ), - :
- , - , - , . .
, . , , , .
. , , , . , , .
, vue, .
, - 5. -, . , .
, : , , , .
, - , - . , , , , , .
.
. , , , - , , .
, , , 1 , - , , , , , . , .
,
. .
, , 3-4 “ 3 ”, 40.
, , .
/ — ( ). , . , . , , -, 8 .
. :
- :
( ), :
— . :
:
, . , .
, . .
—
, , , , , “ ” , .
, , “” - .
, , , , , 2 . , , .
, , / , . , , .
, . , , / - , , - .
(, )
- . , , , , , , , .
, , . , , .
: , , , , . , .
, - , . , .
:
, , , .
, , , ( ), , , .
, ( , 2 , ).
, , . “ ”, :
, .
Bagian 2
Artikel ini mencakup sekitar enam bulan pekerjaan saya di posisi baru. Pada bagian kedua, saya ingin berbicara tentang bagaimana kita bergerak menuju sasaran dengan bantuan:
- Autotests yang baru kami mulai implementasikan. Aneh, tetapi untuk beberapa alasan tidak ada contoh yang layak tentang Bitrix.
- menyingkirkan warisan dalam kode
- lebih lanjut mempercepat dan menyederhanakan pengembangan
- apa yang akan saya pelajari dari komentar
- banyak hal rahasia lainnya (tiba-tiba teman-teman saya membacakan saya)
Terima kasih sudah membaca. Saya akan sangat senang berkomentar, terutama jika Anda tahu cara yang lebih optimal untuk menyelesaikan masalah yang kami temui.
Semoga beruntung dan gembira untuk semua dalam pekerjaan dan kehidupan!