10 huruf untuk 30 tim. Apakah kamu gila

Halo semuanya! Nama saya Kostya, dan saya memimpin departemen tata letak di Wrike .
Ada 10 orang yang bekerja di departemen kami sekarang, dan semua orang ini datang ke perusahaan pada waktu yang berbeda, mereka memiliki pengalaman dan tugas yang berbeda di tim yang berbeda. Pada saat yang sama, semua karyawan adalah spesialis luar biasa, yang bersama-sama dengan sepuluh berhasil memenuhi kebutuhan tata letak seluruh produk.

Dalam artikel ini saya ingin berbicara tentang praktik apa yang membantu kami menyelaraskan tingkat teknis tim secara keseluruhan, mengikuti pendekatan yang sama dalam pekerjaan, dan memberikan peluang pengembangan kepada mereka sehingga mereka dapat menjadi lebih baik dan meningkatkan antarmuka produk kami.

Bagi yang punya banyak surat, ada videonya .



Dan sekarang sedikit konteks. Kami adalah perusahaan produk Wrike yang didedikasikan untuk mengembangkan satu produk. Ini adalah Aplikasi Halaman Tunggal (SPA) untuk berkolaborasi dalam tugas dan proyek. Secara total, perusahaan ini memiliki lebih dari 700 orang, dan lebih dari 300 insinyur sedang mengerjakan pengembangan. Semua karyawan dibagi menjadi 30 tim produk - masing-masing bekerja sesuai dengan metodologi Scrum dan terdiri dari spesialis yang berbeda: back-end, front-end, penguji, perancang tata letak, perancang UX, dll. Setiap tim mengerjakan produknya sendiri. Semua bagian ini kemudian dirakit menjadi satu produk besar, yang digunakan oleh lebih dari 16 ribu perusahaan di seluruh dunia.

Produk ini sangat besar dan kompleks sehingga penting bagi kami untuk secara jelas membedakan antara pengembang Frontend yang membuat logika bisnis pada klien dan pengembang UI, pada dasarnya, coders yang hanya berurusan dengan tata letak antarmuka, tetapi melakukannya dengan perendaman maksimum dan, sesuai dengan itu , dengan kualitas maksimal.

Pada saat yang sama, kami tidak percaya bahwa perancang tata letak adalah tahap menengah pengembangan di pengembang Frontend. Bagi kami, ini adalah cabang pengembangan yang terpisah dengan tumpukan teknologi dan kompleksitasnya sendiri. Tidak semua perancang tata letak harus dapat memprogram, tetapi tidak semua pengembang Frontend harus dapat mengeset.

Terlepas dari kenyataan bahwa hanya 30 tim yang bekerja di Wrike, coders dari sepuluh mencakup kebutuhan hanya 20. Faktanya adalah bahwa tidak semua tim mengerjakan tugas untuk mengubah antarmuka, jadi hanya 20 dari mereka yang “dipersenjatai” dengan perancang tata letak permanen mereka.

Tim Wrike didistribusikan, kami memiliki beberapa kantor di seluruh dunia: dari San Diego ke Voronezh. Pusat pengembangan utama terletak di St. Petersburg, bagian dari pengembangan adalah di Voronezh, dan sekarang kantor dibuka di Praha, di mana beberapa tim produk akan bergerak.

Ketika sejumlah besar orang mengerjakan suatu produk dalam tim, kota dan negara yang berbeda, akan sulit untuk mempertahankan pendekatan yang seragam, para insinyur memiliki tingkat yang sama dan, konsekuensinya, konsistensi dan kode kualitas yang sama-sama tinggi. Jika Anda tidak memberikan perhatian khusus pada ini, berbagai masalah dapat muncul.

Bayangkan Anda adalah seorang penata huruf dan bekerja di tim produk Anda. Suatu hari di bulan Mei, orang-orang dari tim lain mendatangi Anda dan segera meminta bantuan: perancang tata letak mereka sakit beberapa hari sebelum rilis penting dan ia harus segera diganti, setelah menyelesaikan semua yang tidak ia miliki di jalan. Anda tidak terlalu sibuk saat ini dan setuju untuk membantu: hanya perlu beberapa hari. Selanjutnya, Anda mengunduh repositori yang digunakan rekan kerja Anda dan ... tenggelam di dalamnya selama seminggu, hanya untuk mencari tahu apa yang sedang terjadi di sana. Malam tanpa tidur, tenggat waktu yang terkoyak, dan tanda gugup diberikan kepada Anda sebagai bonus.

Atau bahkan lebih buruk lagi - Anda adalah pembuat kode sakit yang sama. Dan, meninggalkan daftar sakit, Anda memperbarui repositori Anda dan mendapatkan 28 komit dari kolega Anda, yang sepenuhnya menghancurkan arsitektur ramping yang diletakkan sejak awal. Kenapa begitu Karena kolega Anda bekerja keras di malam hari tanpa mengetahui ide-ide Anda dan kemampuan untuk melakukan sinkronisasi dengan penulis. Dan, tampaknya, tugas saat ini entah bagaimana dilakukan, tetapi mengembangkan kode ini lebih jauh akan menjadi mimpi buruk. Semuanya perlu diperbaiki, dan itu bagus jika Anda bisa menjelaskannya kepada tim dan memberikan satu minggu lagi pekerjaan pada apa yang tampaknya telah dilakukan.

Saya telah dalam pengembangan web untuk beberapa waktu: Saya bekerja sebagai pengembang dan manajer. Dia bekerja di studio web, agensi, produksi outsourcing, dan sekarang saya bekerja di tim produk. Saya telah melihat segalanya, saya telah melihat situasi yang sama dengan terburu-buru dan di perusahaan yang jauh lebih kecil daripada Wrike. Dan oleh karena itu, saya sangat senang bahwa di Wrike, setidaknya dalam hal pengembangan UI, tidak ada situasi seperti itu dan tidak bisa, dan saya siap untuk berbagi praktik yang membantu kami menghindari ini.

Secara umum, jika Anda memikirkannya, jelas bahwa semuanya ada di orang dan proses. Orang yang menulis kode, merekalah yang membangun proses dan berinteraksi. Orang adalah sumber solusi dan sumber masalah. Dan jika kita berbicara tentang insinyur, maka semuanya tampak sederhana. Agar tidak memiliki masalah, beberapa kondisi harus diperhatikan:

1. Semua pria harus sama-sama level tinggi. Setiap orang menggunakan seluruh rangkaian teknologi yang diperlukan, tahu semua kekuatan dan keterbatasan, berpengalaman dalam proses dan mematuhi pendekatan yang sama. Maka, memang, Anda dapat memberikan tugas kepada insinyur mana pun, dan dia akan menyelesaikannya serta kolega lainnya;
2. Semua orang menulis kode dengan baik. Ya, atau setidaknya sama saja. Kemudian, memang, ketika dikombinasikan dengan paragraf pertama, kita akan mendapatkan kode yang konsisten dan terawat baik yang dapat digunakan oleh anggota tim mana pun;
3. Semua orang tahu siapa melakukan apa. Ini menurunkan ambang entri ketika beralih di antara tugas dan kemudian, memang, bahkan jika seseorang sakit atau "jatuh" dari alur kerja karena alasan lain, salah satu kolega akan berada di tangan: ini mengurangi kemungkinan yang disebut Bus Factor;
4. Anggota tim "berbagi pemula". Jumlah tim terus bertambah, begitu pula kebutuhan akan insinyur. Sudah sulit untuk mempekerjakan orang-orang seperti yang sesuai dengan tiga poin pertama, jadi alangkah baiknya jika orang yang ada dapat berbagi pemula atau kloning, sambil mempertahankan pengetahuan saat ini. Maka ya, tidak akan ada masalah dengan penskalaan;
5. Ajari semua orang untuk terbang. Untuk perusahaan dengan beberapa kantor di negara yang berbeda, perlu untuk dapat mengumpulkan orang-orang dari kantor yang berbeda di satu tempat, karena nilai komunikasi non-verbal untuk membangun komunikasi sulit ditaksir terlalu tinggi. Dan alangkah baiknya jika para pria, ketika mereka perlu melakukan sinkronisasi dengan seseorang, bisa saja "terbang" ke kantor lain, seperti di komik. Maka, mungkin, tidak akan ada masalah dengan distribusi tim di seluruh dunia.

Dan jika entah bagaimana semua ini diimplementasikan dalam satu insinyur, maka menyebutnya "perancang tata letak" entah bagaimana salah, dan judul seperti "perancang tata letak universal dalam ruang hampa" lebih baik.

Tampaknya tidak mungkin untuk memenuhi semua poin ini, terutama dua yang terakhir. Tapi kami, di departemen tata letak di Wrike, dekat dengan itu. Dan sekarang saya akan memberi tahu Anda tentang 7 praktik yang membantu kami sedekat mungkin dengan cita-cita yang kami perjuangkan.

1. Daftar kompetensi saat ini

Jika kita tahu tugas apa yang harus diselesaikan, kita harus memahami kompetensi apa yang dibutuhkan untuk menyelesaikannya. Tentu saja, akan baik bagi semua orang untuk mengetahui segala sesuatu di dunia, tetapi secara objektif ini tidak mungkin dan perlu menyoroti daftar minimum pengetahuan yang setidaknya dimiliki seseorang di departemen, dan lebih disukai semua orang.

Apa yang diberikannya? Persyaratan yang jelas untuk kandidat - semakin dekat ilmunya sesuai dengan daftar kompetensi yang disyaratkan, semakin baik.

Bagaimana cara menebusnya? Di beberapa titik, kami berkumpul di seluruh departemen dan dalam beberapa pertemuan menulis di atas kertas semua teknologi yang sudah kami gunakan atau ingin belajar dan mulai menggunakan di masa depan. Dan dengan bantuan fasilitasi, kami sampai pada daftar kompetensi yang sepenuhnya disepakati semua orang.

Sebagai hasilnya, daftar kompetensi kami berisi hal-hal yang sangat abstrak, misalnya, kemampuan untuk dengan cepat menemukan informasi, dan teknologi yang sangat spesifik, hingga perintah spesifik dari utilitas konsol git, yang kami pikir harus dapat digunakan.
Pada saat yang sama, sangat normal bahwa pada satu titik hanya satu atau dua orang di suatu departemen memiliki satu kompetensi - pada tahap ini, hal utama adalah bahwa setidaknya seseorang memiliki pengetahuan ini, jika tidak ternyata departemen tersebut menghadapi tugas-tugas yang tidak seorang pun tidak bisa menyelesaikan.

Setelah selesai dengan daftar kompetensi lengkap, kami dengan mudah mengelompokkannya menjadi 13 arah. Inilah mereka:

• Kemampuan untuk google;
• Lingkungan (alat, git, servis, dll.);
• HTML
• CSS
• Pendekatan umum (HTML / CSS);
• UI-kit;
• Scrum;
• Angular + Dart;
• Ulasan kode;
• JS;
• Dasar-dasar pemrograman;
• UI / Antarmuka;
• Tombol cepat

Dan jika HTML / CSS yang sama adalah standar industri yang umum, dan kita dapat mengharapkan para kandidat untuk mengenal mereka, maka ada hal-hal yang sangat spesifik. Misalnya, pustaka Kit UI internal kami. Atau alat khusus internal kami, fitur lingkungan, fitur pendekatan untuk menyelesaikan masalah tertentu, dll. Sudut Dart yang sama (kami menulis ujung depan produk pada Dart) adalah hal yang agak langka, hanya sedikit orang yang bekerja dengannya dan mengharapkan setidaknya satu dari standar ini untuk dikenal oleh kandidat potensial - setidaknya secara naif. Ternyata bahkan jika kita menyewa spesialis berpengalaman, dia masih tidak akan tahu setengah dari apa yang kita anggap perlu untuk menyelesaikan tugas kita dengan sukses. Ternyata mempekerjakan dan mengadaptasi orang baru ke tim selalu sedikit pelatihan. Dan semakin banyak pengetahuan yang terkumpul, pelatihannya menjadi lebih kompleks dan panjang.

Ternyata tidak mungkin menemukan seseorang yang 100% memenuhi persyaratan kami untuk keahlian teknis, dan kami perlu mempelajarinya. Jadi, seorang pemula harus memiliki keterampilan belajar tertentu. Dan ini adalah fitur pribadi, yang disebut Soft Skill.

Ketika departemen dan produk kecil, dan akumulasi pengetahuan kecil, menguntungkan untuk mempekerjakan orang dengan keahlian tinggi untuk membagikannya dalam sebuah tim. Dan di sini sudah Keterampilan Keras keluar di atas.

Ketika departemen tumbuh, dan pada saat yang sama jumlah akumulasi pengetahuan tentang produk meningkat, menjadi tidak menguntungkan untuk mempekerjakan anak-anak dengan pengalaman yang luas, karena akan lebih sulit bagi mereka untuk beradaptasi dengan kenyataan baru yang sulit untuk dengan cepat berubah. Dan di sini berguna untuk merekrut orang-orang yang, meskipun mereka tidak memiliki banyak keahlian teknis, tetapi yang dapat dengan cepat beradaptasi dan mempelajari teknologi yang diperlukan. Dan Soft Skill datang ke depan - yaitu, kemampuan belajar tinggi, keterampilan komunikasi yang baik. Dan penting bahwa seseorang berbagi nilai yang sudah mapan dan memperkuat tim, dan tidak mulai bertarung dengannya. Ini tentang Fit Budaya.

Adalah penting bahwa, setelah bergabung dengan tim, seseorang sesegera mungkin memiliki pemahaman tentang teknologi dan proses dan mulai membawa manfaat. Dan ini membawa kita ke praktik penting kedua:

2. Onboarding dengan pelatihan terintegrasi

Kami telah memutuskan bahwa mempekerjakan orang yang berpengalaman saja tidak cukup dan kami, segera setelah seseorang pergi bekerja, perlu dengan cepat dan efektif mengajarinya apa yang tidak ia ketahui saat ini. Dan tidak masalah apakah ini sesuatu yang biasa, seperti flex atau grid, atau alat tertentu yang mustahil untuk bertemu dengan di luar Wrike.

Untuk melakukan ini, kami menggunakan Onboarding - dari bahasa Inggris "on-board" - proses mengadaptasi orang baru ke tim. Tapi di Wrike, ini bukan hanya cerita tentang di mana pendatang baru memiliki pekerjaan, dan ke mana harus melihat tugasnya. Kami menyadari bahwa bagi kami orientasi adalah seperti kursus pendidikan berkelanjutan - semacam pelatihan selama beberapa bulan: dengan penilaian tingkat saat ini, rencana pelatihan, mentor-mentor, beberapa pelatihan tentang produk, teknologi, dan proses. Menurut hasil orientasi, kami berharap bahwa seseorang akan mempelajari segala sesuatu yang diperlukan untuk menyelesaikan tugas mereka dan menjadi sedekat mungkin dalam keterampilan mereka bahkan dengan orang yang paling berpengalaman dari departemen.

Secara umum, proses orientasi kami adalah topik untuk artikel yang terpisah, tetapi untuk sekarang saya ingin memikirkan satu hal utama: mawar kompetensi.

Berdasarkan pada kelompok kompetensi yang telah kami rumuskan sebelumnya, kami dapat mengevaluasi setiap karyawan atau bahkan seorang kandidat di setiap arah dan membuat diagram radial seperti itu:



Setiap sinar adalah kelompok keterampilan tertentu. Intinya adalah persentase teknologi yang dikuasai dan pendekatan yang melekat dalam kelompok ini. Semakin banyak orang tahu dan tahu caranya, semakin dekat diagramnya dengan lingkaran ideal. Orang yang benar-benar memiliki semua keahlian dari daftar kompetensi kami adalah perancang tata ruang yang sangat bulat dalam ruang hampa yang kami butuhkan.

Penting untuk dipahami bahwa bagan seperti itu (alias mawar kompetensi) tidak digunakan untuk tinjauan kinerja, yaitu, kami tidak menggunakannya untuk memahami siapa perancang tata letak yang baik dan siapa yang buruk. Tidak ada level minimum di setiap area di bawah ini yang tidak mungkin jatuh. Bagan ini memberikan pemahaman tentang di mana seseorang memiliki kekuatan dan di mana poin untuk pertumbuhan. Kami siap menghadapi kenyataan bahwa semua orang di departemen tidak mengetahui sesuatu, terutama jika itu adalah pemula. Tetapi, melihat mawar kompetensi, cukup mudah untuk memahami hal-hal apa yang harus ditarik di tempat pertama.

Ketika seorang pendatang baru datang kepada kami, mawar seperti itu dibangun untuknya, dan mereka, bersama dengan mentor mereka, menyusun rencana pelatihan selama 2-3 bulan, bergerak di mana seseorang dipompa dan mendekati cita-cita yang diinginkan.

Dan, menurut hasil, setelah melalui pelatihan ini, mawar sedang dibangun kembali, dan kemajuan menjadi jelas.



Kami tidak mengharapkan hasil 100% di setiap arah, penting bagi kami bahwa ada kemajuan yang signifikan. Dan, pada kenyataannya, diagram ini dapat digunakan bahkan setelah selesainya onboarding, agar tidak diam dan berkembang lebih jauh. Seseorang dapat memompa arah minat mereka sendiri hingga 100% dan bahkan lebih jauh, dan seseorang dapat menambahkan arah baru dan berkembang dari sebuah penyetel ke beberapa area yang berdekatan. Kami juga memiliki contoh dan praktik seperti itu.

Apa yang diberikannya? Rencana pengembangan yang jelas untuk pemula. Dengan demikian, kita semua membawa ke tingkat tunggal, meminimalkan kesenjangan antara "oldies" dan "pendatang baru".

Plus, ini mengurangi persyaratan untuk kandidat: jika Anda masih berlatih, bukankah semuanya sama dengan apa? Akibatnya, kami tidak memiliki persyaratan wajib untuk Keterampilan Keras bagi kandidat. Jelas bahwa kita tidak dapat merekrut orang tanpa pengetahuan dasar sama sekali, tetapi banyak yang dapat dipelajari pada tahap awal. Yang utama adalah bahwa seseorang mampu, dan sisanya adalah bisnis.

Jadi, kita tahu siapa yang kita cari, keterampilan apa yang dibutuhkan dan bagaimana melatihnya, tetapi pengetahuan ini relevan saat ini. Dan kereta front-end melaju dengan kecepatan penuh, mengolesi semua yang tersandung dan mengikuti kereta. Dan kita perlu semacam proses pengenalan pengetahuan baru sehingga seluruh departemen tidak ketinggalan persyaratan modern. Dan itu membawa kita ke praktik baik ketiga:

3. Kegiatan pelatihan reguler

Untuk mengimbangi dunia modern, penting untuk memantau apa yang terjadi di dalamnya. Pergi ke konferensi, baca artikel khusus, coba teknologi baru dan terapkan dalam pekerjaan Anda.

Akan aneh untuk menyeret semua orang ke semua konferensi dan kursus yang tersedia, ini tidak efektif. Tetapi salah satu dari mereka, dengan satu atau lain cara, sedang mempelajari sesuatu sendiri atau dengan dukungan Wrike - kami kirim ke konferensi, membayar untuk kursus khusus dan umumnya mendukung dalam setiap cara mereka yang ingin memompa. Dan jika dalam seluruh aliran informasi dimungkinkan untuk menemukan sesuatu yang berguna untuk dirinya sendiri, maka akan menyenangkan untuk membawanya ke departemen dan berbagi pengetahuan dengan semua orang. Untuk ini, acara pelatihan internal reguler membantu kami. Tetapi bagaimana memahami siapa dan apa yang bisa diajarkan oleh seluruh departemen? Mawar kompetensi yang sama membantu kita dalam hal ini. Tetapi tidak dalam konteks masing-masing karyawan, tetapi dalam konteks seluruh departemen.



Melihat grafik seperti itu, mudah untuk memilih seorang ahli di beberapa bidang dan meminta untuk berbagi pengetahuan Anda dengan orang lain.

Anda juga dapat melihat bahwa, terlepas dari kenyataan bahwa kami sendiri telah menentukan tingkat pengetahuan tertentu di salah satu bidang, tidak seorang pun di departemen ini yang memiliki 100% pengetahuan. Dan ini adalah kesempatan untuk menarik pakar eksternal yang akan mengadakan lokakarya atau kuliah untuk kami dan meningkatkan tingkat pengetahuan umum di seluruh departemen. Misalnya, karena kebutuhan untuk mempelajari dasar-dasar bahasa Dart, kami menemukan seorang mentor di perusahaan - pengembang yang kuat yang melakukan kursus kuliah tentang Dart untuk seluruh departemen tata letak. Ini tidak membuat kami pengembang, karena tidak ada tugas seperti itu, tapi setidaknya sekarang kami lebih memahami front-end. Atau mungkin seseorang, setelah merasakan teknologi baru, akan berpikir tentang bagaimana melatih kembali di FE, yang juga bagus.

Yang tersisa bagi kita adalah meninjau daftar kompetensi kita secara teratur, melengkapi dengan teknologi baru yang relevan. Kemudian mawar akan dibangun kembali, dan kita akan melihat tingkat umum departemen, kita akan dapat mengelolanya dan kita tidak akan pernah ketinggalan di belakang mesin front-end.

Jadi, kami memiliki sekumpulan spesialis keren yang kekuatannya kurang lebih sama dan tidak ketinggalan tren saat ini. Dan kita bahkan tahu cara mengisi ulang peringkat mereka. Bagaimana sekarang untuk menyinkronkan pekerjaan mereka? Praktik penting keempat membantu kita dengan ini:

4. Tinjauan silang wajib

Biarkan saya mengingatkan Anda bahwa semua pekerjaan kami dilakukan dalam tim produk. Dan setiap tim yang tugasnya terkait dengan mengubah antarmuka memiliki pengeset permanen sendiri. Sebuah typesetter dapat memiliki beberapa perintah, tetapi hanya jika seseorang tidak memuatnya 100%. Dan jika Anda meninggalkan spesialis sendirian dengan dirinya sendiri, maka, cepat atau lambat, ia merancang cara mengatur huruf sendiri, yang sisanya tidak akan pernah tahu.

Agar ini tidak terjadi dan tugas yang sama diselesaikan oleh semua yang kira-kira sama, setiap tugas dan Permintaan Gabung melewati kode review wajib.

Penting untuk melihat ulasan kode tidak hanya sebagai fungsi kontrol sehingga tidak ada yang menempatkan sesuatu yang buruk pada master, tetapi lebih pada tahap di mana dua insinyur dari tim yang berbeda, dengan latar belakang dan tugas yang berbeda, sepakat tentang bagaimana menyelesaikannya satu atau masalah lain.

Apa yang memberi ulasan silang?

Pada tahap peninjauan, Anda bisa mendapatkan tampilan luar - bagaimana tugas dapat dilakukan dengan lebih baik, yang mengurangi jumlah kesalahan dan membuat kode konsisten. Dan itu juga merupakan proses pembelajaran timbal balik - tidak hanya pembuat kode yang lolos “validasi” dari pengulas, tetapi pengulas juga dapat melihat bagaimana masalah itu dipecahkan dan membawanya ke layanan. Maka, melalui proses tinjauan ulang, perjalanan umum dikembangkan dan didistribusikan ke seluruh perusahaan.

Setelah mengembangkan pendekatan umum, alangkah baiknya untuk menyelamatkan mereka di suatu tempat, sehingga pemula bisa mendapatkan pengetahuan ini tidak hanya dari rekan kerja, tetapi juga secara mandiri. Ini membawa kita ke praktik penting berikut:

5. Gaya kode dan linting otomatis

Kode ini konsisten dan konsisten dengan aturan umum yang dikembangkan di departemen. Yang paling mendasar adalah Codestyle yang umum untuk semua. Penting bahwa aturan-aturan ini jelas ditetapkan dan tersedia untuk umum bagi siapa saja di perusahaan. Karena Anda tidak akan pernah menebak sebelumnya siapa yang harus bekerja dengan kode Anda.

Lebih baik lagi, pastikan bahwa kode cocok dengan aturan yang diberikan secara otomatis diperiksa oleh linter: mesin harus menderita, bukan orang. Sebagai contoh, kami telah mengembangkan dan mengimplementasikan linting untuk templat markup dan linting file yang lebih sedikit.

Apa yang diberikan linting otomatis?

Yah, pertama, itu biasa untuk menulis kode - semua kesalahan disorot langsung dalam kode, saat Anda masih dalam konteks. Dan tidak perlu terganggu dengan memeriksa gaya kode: ini akan dilakukan oleh plugin untuk IDE.

Kedua, lebih mudah untuk melakukan dan lulus ulasan kode - di MR tidak ada kesalahan dan tidak ada kesalahan gaya kode dan Anda dapat berkonsentrasi tepat pada esensi tugas.

Ketiga, linting otomatis dalam proses penulisan kode juga merupakan cara untuk mempelajari gaya kode. Tidak masalah apakah Anda terbiasa dengan gaya kode atau tidak, sudah pada saat menulis kode, dan terlebih lagi ketika Anda mencoba melakukan kode, linter akan menampilkan daftar kesalahan dan tautan ke aturan bahwa mereka melanggar persis jumlah yang Anda butuhkan di sini dan sekarang . Jadi, Anda pasti akan belajar gaya kode dengan coba-coba.

Tampaknya terlepas dari kenyataan bahwa setiap orang bekerja di tim yang berbeda dan pada tugas yang berbeda, ada banyak kesamaan. Dan mereka harus mampu mengoordinasikan: siapa, apa, dan kapan harus meninjau, siapa, kapan, apa, aturan apa yang harus dimasukkan ke dalam gaya kode, dan mana yang tidak, dll. Semua kegiatan ini harus dapat disinkronkan. Praktik penting lain membantu kita dengan ini:

6. Stand-up harian

Departemen tidak memiliki sprint dan perencanaan sendiri (hanya tim produk yang memiliki desainer tata letak yang bekerja untuk mereka), namun kami mempelajari beberapa praktik dari Scrum. Yaitu, stand-up harian adalah pertemuan di mana kami mengumpulkan dan membahas masalah-masalah mendesak: kami membahas tugas-tugas yang sudah selesai dan saat ini, dan membahas yang akan datang. Ini penting jika hanya dalam konteks urutan tugas untuk peninjauan, dan sebagai bonus Anda dapat mendiskusikan masalah yang muncul, mintalah saran rekan kerja, atau bagikan berita dari tim Anda.

Penting agar stand-up berlalu dengan cepat, tidak lebih dari 15 menit sehari. Karena bahkan 15 menit sehari, dikalikan dengan 10 orang memberikan biaya 40-50 jam kerja per bulan. Ini seperti satu minggu penuh dari pekerjaan satu orang. Karena itu, reli itu sendiri harus sesingkat dan seefektif mungkin. Dan hanya jika ada masalah yang memerlukan diskusi terpisah, mereka berada di luar kerangka kerja Harian dan dibahas secara terpisah oleh orang-orang yang tertarik, tanpa membuang waktu orang lain.

Kami menggunakan papan tulis interaktif dengan tugas-tugas yang dapat digunakan oleh setiap desainer tata letak kapan saja dari kota mana saja. Di Daily, setiap orang yang berkumpul di St. Petersburg di kantor yang sama oleh TV, tempat papan ini ditampilkan, dan mereka yang bekerja di kota-kota lain, terhubung melalui Zoom. Selain kamera web, ini memberikan efek masalah kehadiran dan distribusi yang tidak kami alami.

Pendirian harian memberi kita ruang informasi umum tertentu di mana setiap pertanyaan mengenai tata letak dapat diselesaikan - tanyakan saja dengan keras dan pikiran kolektif mensintesiskan jawabannya, karena seseorang telah menemukan ini. Atau sekelompok orang yang tertarik dapat membantu menemukan solusi untuk tugas aneh baru.

Jadi, kami tahu cara menyewa dan melatih spesialis keren, kami tahu cara mengoordinasikan tindakan mereka untuk mempertahankan kode berkualitas tinggi. Tetapi ada satu penyergapan - jika seseorang ingin berkembang sebagai spesialis dan melakukan pekerjaannya dengan baik, maka dia akan melakukannya apa pun yang terjadi. Bahkan jika semua proses ini tidak ada. Mereka hanya membantu. Dan jika dia tidak mau, maka proses dan pelatihan super yang ideal pun tidak akan membuat seseorang bergerak. Setiap orang harus benar-benar terlibat dan tertarik pada nasib masa depan mereka sendiri, dan perusahaan, dan produk. Dan ini yang terakhir dalam daftar, tetapi sebenarnya praktik yang paling penting:

7. Keterlibatan setiap orang dalam proyek departemen

Idealnya, setiap karyawan harus memiliki rencana yang dapat dimengerti untuk pengembangan dirinya dan departemen setidaknya untuk kuartal berikutnya. Dan bagus jika semua orang memilikinya di kepalanya. Tetapi aliran tugas saat ini tidak selalu punya waktu untuk memikirkannya.

Agar tidak ada yang bertahan pada level saat ini dan tidak "masam" di timnya, kami telah memperkenalkan praktik pertemuan "satu lawan satu" secara teratur dengan pemimpin atau pemimpin tim Anda. Ini adalah pertemuan di mana Anda dapat berbicara tentang perkembangan Anda, pengembangan tim, departemen, dan perusahaan, dan apa yang dapat Anda lakukan untuk ini sekarang. Pada pertemuan tersebut, Anda dapat memperoleh umpan balik tentang diri Anda dan mengoordinasikan tindakan, atau Anda dapat memberikan umpan balik tentang tugas-tugas Anda, tentang proses-proses dalam tim atau departemen dan, dengan demikian, memengaruhi mereka.

Selain 1: 1 biasa, "proyek" berjalan baik dengan kami. Dengan satu atau lain cara, proses dan teknologi di departemen perlu dipompa, sesuatu yang baru harus diperkenalkan, dan yang lama dan tidak relevan harus dibuang. Setiap orang di departemen memiliki kesempatan untuk mengusulkan perubahan seperti itu, misalnya, memperkenalkan teknologi baru. Atau hentikan beberapa pendekatan Legacy yang mengganggu kehidupan.

Dan, jika perubahan semacam itu benar-benar bermanfaat, siapa pun dapat mengambil proyek untuk implementasinya. Ini berarti bahwa Anda secara independen melakukan beberapa penelitian atau pekerjaan, atau mengumpulkan tim proyek dan mengelola kegiatannya untuk mencapai tujuan proyek. Seringkali ini membutuhkan studi mendalam tentang teknologi baru atau pencarian jawaban atas pertanyaan yang sebelumnya tidak dapat diselesaikan.

Setiap orang dapat memilih sendiri proyek yang menarik baginya. Dengan demikian, seseorang mengembangkan dirinya dalam bidang yang menarik baginya, dan memompa seluruh departemen.

Dan sebulan sekali, agar pekerjaan pada proyek transparan untuk semua orang, kami berkumpul di seluruh departemen pada "retro" dan berbagi kesuksesan atau menawarkan proyek baru.

Ketujuh praktik ini memungkinkan kami untuk merekrut dan mengintegrasikan 6 desainer tata letak ke dalam departemen dan tim dalam setahun. Saat ini, ini hampir ⅔ dari seluruh departemen. Hasil yang bagus

Dan bagaimana dengan penerbangannya?

Itu tidak bisa dilakukan tanpa sihir - semua berkat keajaiban otomatisasi dan peri perjalanan kami Ane.
Jika karena alasan kerja Anda perlu berada di kantor lain, misalnya, mengobrol dengan seseorang secara langsung, maka yang diperlukan hanyalah mengisi formulir khusus langsung di Wrike, tunjukkan tanggal dan tujuan perjalanan. Dan pada saat yang tepat dalam surat akan ada tiket pesawat. Yang tersisa hanyalah mengambil laptop, paspor dan tidak terlambat untuk penerbangan. Jadi pengetik huruf kami terbang tanpa masalah :)

Tetapi bagaimana jika perusahaan Anda belum memiliki praktik seperti itu?

Jika Anda adalah pemimpin tim atau pemimpin, maka sarannya sangat sederhana: "Ini daftar periksa, ambil dan implementasikan." Saya pikir setiap pemimpin tertarik pada pertumbuhan karyawan mereka dan kualitas kode.

Dan jika Anda seorang pembuat huruf sederhana atau bahkan seorang freelancer, Anda tidak harus bergantung pada dukungan "dari udara"? Anehnya, sarannya persis sama.

Kuncinya adalah bahwa penerapan semua praktik ini tidak memerlukan investasi besar atau biaya tenaga kerja, dapat dipromosikan "dari bawah ke atas" atas inisiatif karyawan biasa. Hal utama adalah bahwa ada keinginan untuk memompa diri dan meningkatkan dunia di sekitar Anda.