Get best of the week

Kesalahan apa yang dilakukan manajer di situs jarak jauh

Halo, Habr! Saya bukan pengembang, tetapi manajer. Untuk beberapa waktu saya diajarkan untuk mengelola orang, dan kemudian saya terjun ke dunia pembangunan yang suram, di mana semuanya berjalan salah, seperti yang mereka katakan di universitas. Sekarang saya memimpin praktik mengelola siklus hidup perangkat lunak dan saya ingin memberi tahu Anda beberapa hal yang mungkin penting bagi pemimpin tim dan PM yang terkait dengan beralih ke situs jarak jauh. Karena di tim kami orang sudah mulai menyipit. Dan kemudian saya akan menunjukkan dan memberi tahu tentang tumpukan otomatisasi kami untuk jarak jauh, dan bagaimana kami akan merilis rilis dari obrolan di telepon dengan satu tombol, daripada menaikkan VPN ke batas aman, dan ini mempercepat koordinasi, dan ini membantu mengoordinasikan hari ke hari.

Saran pertama sudah cukup untuk mendapatkan orang-orang Anda!



Saya tahu kedengarannya sangat bodoh, tetapi banyak manajer, tidak melihat orang-orang di sekitarnya, mulai entah bagaimana mengimbangi keinginan mereka untuk memastikan bahwa mereka bekerja. Inilah obrolannya:


Pelatuk dalam bentuknya yang murni.

Jika ada tugas untuk meningkatkan efektivitas tim sekarang dan di masa depan, biarkan orang-orang sendirian. Dan atur 15 menit setiap hari di pagi hari. Saya sudah berhasil melihat sinkronisasi proyek umum setiap empat jam, dan setiap hari selama dua jam, dan para manajer yang merasa frustrasi, yang terbiasa bernegosiasi tatap muka dengan seseorang.

Apa yang terjadi pada pengembangan jarak jauh di CROC


Kami beralih sangat sederhana karena kami sudah memiliki struktur kantor pengembangan yang terdistribusi secara geografis. Dalam beberapa tahun terakhir, mereka terbiasa dengan fakta bahwa hari kerja salah satu pengembang dapat dimulai dari jam 11 malam waktu Moskow. Dengan demikian, hampir tidak ada masalah manajemen untuk tim dengan peserta seperti itu, tetapi bagi mereka yang bekerja di zona waktu yang sama, kesulitan dapat muncul. Misalnya, salah satu tim saya membutuhkan janji temu baru di Zoom untuk sinkronisasi, dan mulai memilih waktu yang optimal. Pada awalnya mereka melakukannya pada hari Senin dan Rabu, dan kemudian pada hari Rabu dan Jumat, karena beberapa pengembang memilih untuk bekerja pada akhir pekan dan bersantai pada hari Senin-Selasa. Ini sebagian disebabkan oleh fakta bahwa mereka kurang tersedia di ruang obrolan hari ini.

Hal penting kedua adalah bahwa kita sudah memiliki alat untuk menghubungkan obrolan, pelacak, jaringan sosial perusahaan dan seluruh tumpukan devoop CI / CD, dan semua ini sebagian dihubungkan kembali sehingga data dari satu sistem secara otomatis ditransfer ke yang lain. Misalnya, kami menyetujui sesuatu dalam obrolan, Anda dapat memberi tahu bot untuk membawanya ke Jira. Dan dia akan tergelincir. Jika Anda melakukannya sendiri, maka Anda harus masuk, menembus semua bidang dan seterusnya, yah, dan entah bagaimana terhubung ke perimeter yang dilindungi. Bot lebih mudah. Yang paling sulit adalah sistem otorisasi. Kami memikirkannya, mengacaukannya dan membuatnya lebih dari setahun yang lalu.

Bagaimana semua ini dimulai.Pertama, semua orang beralih ke situs jarak jauh dan terbiasa selama seminggu. Seseorang memiliki kursi yang buruk dan punggung mereka sakit, anak-anak seseorang menggigit kaki mereka di rumah, istri seseorang senang suaminya menghabiskan lebih banyak waktu bersama keluarganya, dan meminta setiap lima menit untuk membuka kaleng. Seminggu menetap alat. Kemudian tiba-tiba para pengembang menyadari bahwa mereka senang bahwa mereka sedang duduk di rumah. Dan Anda tidak harus pergi ke mana pun, pergi ke mana pun, tetapi pada pertemuan itu segera jelas siapa yang dibutuhkan dan siapa yang ditunjuk untuk kepentingan ritual. Ya, rapat mulai tepat waktu, karena tidak ada alasan untuk terlambat. Kemudian para manajer mulai menderita, karena komunikasi dengan pelanggan berubah menjadi neraka. Kami mulai menjadwalkan pertemuan tiga jam reguler dalam kalender (tiga hingga empat hari berturut-turut), hanya untuk pergi melalui kontrak dengan seorang pengacara, kalau tidak semua akan hangus selama berbulan-bulan. Sementara itu berhasil.

Langkah selanjutnya- pertanyaannya adalah pengembang di situs jarak jauh perlu motivasi. Tidak seperti di kantor. Sangat penting untuk tidak mendorong, sangat penting untuk mengajukan tugas yang menarik dan memberikan gambar hasil target. Kalau tidak, akan ada penundaan, dan pemimpin sendiri akan memproyeksikannya. Bangun dari tempat tidur untuk melakukan sesuatu yang membosankan memang sulit secara fisik. Para pemimpin dalam proyek harus diberi ruang lingkup yang sama untuk pengambilan keputusan. Situasi kami adalah bahwa TK biasanya tidak berubah, tetapi kekuatan dalam sprint adalah milik tim, dan bukan milik manajer proyek.

Secara alami, dalam perjalanan lebih jauh Anda dapat merusak kayu bakar yang sangat lucu.

Apa yang bisa salah?


Yah, pertama-tama Anda harus ingat bahwa, terlepas dari keadaan darurat (dan dia memiliki banyak orang setelah beralih ke situs terpencil), lebih baik mengikuti prosesnya. Kepada salah satu pelanggan kami, kami mengirimkan rilis dari pengembang kami ke pengembangnya. Sinhro setelah menarik mereka. Kami mengirim rilis, mereka harus melakukan tes integrasi dan regresi. Dan simpan di makanan saya. Dan hari berikutnya mereka menulis dan meminta kami untuk meluncurkan rilis ini kepada mereka di lingkungan pengujian. Karena mereka segera meletakkannya di atas dorongan, dan kemudian ingat bahwa akan menyenangkan untuk menyinkronkan lingkungan kita. Untungnya, rilis itu tidak gagal, tetapi, dari sudut pandang saya, sepertinya, tidak aman atau apa.

Untuk pelanggan lain, kami memulihkan salah satu proyek pihak ketiga setelah mentransfer pekerjaan ke situs jarak jauh. Segalanya jauh lebih sederhana di sana: para ahli pelanggan mengeluarkan basis data, pada saat yang sama karena alasan tertentu mengatur teks biasa dengan kata sandi, juga di luar. Beberapa kulhacker muda meretas semuanya, secara alami.

Anda mungkin tahu tentang intisari harian dengan kerentanan Zoom dan akhir cerita dengan kebocoran catatan. Tidak semua eksekutif (seringkali dari bisnis yang menetapkan tujuan TI) memahami apa itu Zoom, cara kerjanya tepatnya, dan bahwa beberapa hal rahasia tidak layak untuk dibicarakan secara tertulis. Kami membuat memo untuk pelanggan cara menggunakan saluran mana. Tampaknya telah membantu. Setidaknya banyak insinyur industri yang lebih tua menghela nafas sedikit lebih longgar. Dan mereka berhenti menambahkan "mydomain.ru" ke konferensi umum, tanpa menentukan apakah mereka mengenal karyawan ini.

Pelanggan kami yang lain lupa bahwa ada bunga yang tersisa di kantor yang perlu disiram. Ini kami tidak sengaja temukan ketika menganalisis ancaman. Bunga diselamatkan.

Pertemuan dengan pelanggan terbagi menjadi beberapa di mana orang-orang masih memakai dasi di rumah dan mereka yang bisa Anda pakai untuk mengenakan piyama. Pada salah satu pertemuan kami, pengembang utama keluar dari kamar mandi, tepat di busa. Tidak ada yang keberatan.



Para spesialis Agile yang terbiasa berbicara, menempelkan stiker di dinding telah mengalami kehancuran kreatif, karena sekarang menjadi mustahil untuk melakukannya. Dalam banyak kasus, Trello atau Miro memecahkan masalah. Setiap orang menjadi lebih mudah. Saya menikmati menonton rekan-rekan saya belajar berkomunikasi di lingkungan baru dari awal, dan sosialitas mereka tidak memberi mereka bonus seperti sebelumnya.

Pendekatan yang baik adalah merekam di suatu tempat dekat mode masing-masing pengembang. Kami akrab dengan ini karena geografi, tetapi penambahan seperti "dari 16:00 hingga 19:00 hanya melalui telepon dalam kasus mendesak" sangat membantu. Di sinilah permintaan untuk permintaan file dok dan hasil pemeriksaan bekerja sangat keren: Anda bahkan dapat melakukannya dari tempat tidur, jika diinginkan. Karena kalau tidak, Anda harus menunggu pagi kerja berikutnya delapan hingga sembilan jam. Kami mencoba menyampaikan tumpukan sederhana yang sama kepada para pelanggan yang bekerja sama dengan kami, karena jika kita terbiasa dengan fakta bahwa dokumen berpindah dari satu sistem ke sistem lainnya, maka tumpukan atlasian pelanggan mungkin tidak tersedia, dan akan diperlukan untuk mengirim file * .docx dengan laporan sementara.

Di sejumlah tim, ada masalah dengan fakta bahwa rapat dikirim ke kalender tanpa melihat kalender yang sama ini. Tiga undangan dapat dibuat per slot, dan slot itu sendiri sudah terisi. Ini juga diselesaikan secara organisasi dan sederhana.

Inilah yang dikatakan pengembang kami:

Mereka membuat bot untuk demo - plus untuk siapa semua orang plus. Dan baik-baik saja dengan anak-anak yang duduk.
— - . , . , , : 10 000 10 , , . , -, , . , , ! , , . : , , , - . . … , .
Tidak ada perbedaan dengan pengembangan konvensional di situs terpencil. Yah, Anda masih bekerja dengan layanan. Sudah lama terjadi ketika kolega saya secara tidak sengaja memakukan server VPN melalui mana ia terhubung untuk memelihara server VPN ini ... Dengan jendela lima menit untuk memperbarui sistem, beban jatuh dengan tajam di bawah beban setelah aplikasi dihentikan dan sebelum versi baru diluncurkan (di era pembaruan semi-manual) ... Atau ketika Anda menjalankan perintah rm -rf / data, dan kemudian Anda menyadari bahwa Anda memilikinya produktif, dan lebih cepat, lebih cepat ctrl-c.
Chatop perokok:



Mereka membuat rilis ulang ke seorang rekan yang sudah dibebaskan. Mencabut pekerjaannya. Kebahagiaan.

Apakah ada contoh tumpukan?


Ya, ini dia:

Minta Tautan


Gitlab + timcity

Bot membantu

Gitlab +



jira gitlab + timcity

Diagram perakitan

Contoh Pipa Pengembangan

Ini adalah contoh obrolan teknologi



Perangkat devop dan CI / CD dari tim normal telah lama dikerjakan. Dari sudut pandang kontrol proses, penting bahwa pada setiap langkah perlu untuk mengurangi jumlah tindakan tidak nyaman, hanya menyisakan yang berguna. Misalnya, di atas Anda melihat bot yang melaporkan status rilis - dorongan seperti itu jauh lebih nyaman daripada masuk dan menonton bagaimana bot itu ada. Tetapi nilai sebenarnya muncul ketika semua ini memungkinkan Anda untuk membuat proses yang berkelanjutan dari "mendiskusikan masalah dalam obrolan" hingga "mengatur semua tugas dengan tautan ke diskusi", "menyambungkan TK dan menyapu semua sistem" ke build, ditambah semua metrik yang diperlukan dihapus sepanjang jalan seperti tanda harga diri. Bagi pengembang, proyek ini adalah sebuah tantangan, karena biasanya mereka menulis kode, daripada menggambar arsitektur, menulis konsep, dll. Dan jika pengembangan diotomatiskan sebanyak mungkin,maka bagi banyak tim otomasi pertukaran dokumen atau dokumen tidak dilaksanakan dengan sangat baik.

Berikut ini sebuah contoh. Tugas dianggap selesai ketika setiap baris dalam ToR akan menjadi tautan yang berfungsi ke tab silang.

Langkah-langkahnya adalah
:



, . - .

() «»:



. , . - .

- -:



( ) «» ( ). Jira . . «» , . — . . «».

Saya seorang manajer, apa yang harus saya fokuskan sekarang?





Prioritas penting bukanlah berbagi dengan cepat, tetapi untuk berkomunikasi secara normal. Dunia telah berubah, dan sekarang ada dua ancaman penting bagi perusahaan: pemadaman tenaga profesional (jika Anda terlibat dalam manajemen pelatuk dan menekan orang) dan masalah restrukturisasi lengkap struktur manajemen, ketika tim memahami bahwa mereka dapat melakukan segalanya secara mandiri dan dengan pemimpin informal baru . Hal ini dapat mengakibatkan fakta bahwa pada saat akhir krisis seluruh tim, yang sangat sulit ditemukan dan dilatih, akan berdiri dan pergi sekaligus untuk proyek mereka sendiri. Oleh karena itu, saya ulangi sekali lagi - bahkan jika produktivitas Anda telah jatuh, jangan dapatkan karyawan Anda. Itu untuk kepentingan Anda sendiri.

Jika menarik untuk membahas proses kepemimpinan murni secara terpisah, maka kami melakukan webinar pada tanggal 27 pukul 16:00, di sini Anda dapat mendaftar. Ini akan tentang bagaimana Anda dapat membangun proses, berbagai kesalahan dan kasus manajemen, pemisahan tanggung jawab (terutama dengan keamanan informasi), tentang aliran dokumen antara pengembang, analis, penguji, sedikit tentang CI / CD. Ya, meskipun Anda merasa sudah tahu segalanya, Anda bisa melakukannya seperti Jedi sungguhan - mendaftar untuk webinar, matikan suaranya dan duduk di sana untuk melakukan pekerjaan Anda!

More articles:


All Articles