Pertemuan tersebut diadakan sebagai bagian dari rangkaian "Engineer walks to a bar", di mana para insinyur dari berbagai perusahaan IT berbicara tentang topik profesional non-teknik. Serangkaian acara diselenggarakan oleh para insinyur dari perusahaan Miro , dengan dukungan dari biro Dolgushev & Storozhilov DevRel .
Pertemuan kedua dari seri ini akan berlangsung pada 20 Agustus. Topiknya adalah toksisitas dalam tim, perusahaan, dan industri. Pembicara - insinyur dan pimpinan teknis dari Miro, SEMrush, Parma TG, Xsolla. Pendaftaran sudah terbuka .
Daftar Isi:
- Spesifikasi perusahaan dan sistem pengembangan profesional insinyur saat ini
- Tantangan dalam sistem pembangunan saat ini
- Bagaimana menerapkan budaya pengembangan di awal tim baru
- Pertanyaan panas tentang uang
- Bagaimana Anda berpendapat untuk bisnis bahwa karyawan membutuhkan persentase waktu mereka untuk pendidikan dan pengembangan?
- Survei alat pengembangan profesional
Spesifikasi perusahaan dan sistem pengembangan profesional insinyur saat ini
Artyom Susekov, Kepala Rekayasa Perangkat Lunak Produk, Miro. Kami membuat produk untuk kolaborasi tim online, platform papan tulis kolaboratif online. Perusahaan ini mempekerjakan 400 orang, sedikit kurang dari setengahnya adalah insinyur. Kantor pengembangan produk - di Perm dan Amsterdam. Tim tersebut memiliki fungsi lintas fungsi: insinyur, manajer produk, desainer dan, jika perlu, pemasar. Mereka menggunakan scrum, beberapa menggunakan kanban. Untuk perencanaan - OKR di tingkat kampanye dan di tingkat tim individu.
Kita punya nilai, ekspektasi dari masing-masing dirumuskan dalam bentuk contoh tingkah laku yang spesifik (pola tingkah laku). Hal ini dilakukan agar tidak terpaku pada ekspektasi formal saja ("melakukan banyak tugas, dapatkan sertifikat ini dan itu"). Lebih penting bahwa pengetahuan yang diperoleh diterapkan dalam pekerjaan sehari-hari, ini persis seperti yang ditunjukkan dalam contoh spesifik yang dijelaskan untuk setiap kelas.
Nilai standar: Junior, Middle, Senior, ada beberapa langkah dalam setiap kelas. Ada peluang setelah Senior untuk tumbuh menjadi spesialis teknis atau menjadi pemimpin tim dan kemudian manajer arahan.
Ada Performance Review yang kami lakukan dua kali setahun. Selama itu, Anda mendapatkan umpan balik dari rekan tim Anda, pemimpin tim menerima umpan balik dari mereka yang menjadi bawahan langsung untuk mereka. Selain itu, karyawan tersebut menulis ulasan diri, yaitu dia mengevaluasi pekerjaannya secara mandiri.
Hasilnya dirangkum, setelah itu Career Conversation dilakukan: apa yang ternyata bagus, apa yang ternyata bagus, apa yang harus ditekankan di masa depan, apa yang harus dikerjakan. Kemudian manajer membantu merumuskan rencana pengembangan untuk enam bulan atau kuartal ke depan.
Career onversation ( , , ), : , , .Alexander Borisov, Kepala Pusat Kompetensi Teknologi Innopolis, Grup Ritel X5. Mungkin sebagian besar dari semua orang sudah familiar dengan X5. Kami memiliki rantai Perekrestok, Pyaterochka, dan Karusel. Jika tiga tahun lalu kami adalah perusahaan yang menjual tomat, dan sekarang kami sedang berjuang untuk menjadi perusahaan IT yang menjual tomat.
Sebagian besar keuntungan berasal dari layanan TI kami. Bagaimana Pyaterochka bekerja dan berapa harga yang diberikannya, mungkin karena logistik yang dibangun dengan baik dan sistem manajemen untuk proses besar ini. Kami memiliki lebih dari dua ribu spesialis IT di perusahaan, di Innopolis sendiri ada hampir 150 orang.
Selama setahun terakhir, semua ini telah mulai berubah dari format departemen menjadi format tim produk. Kami telah membagi layanan dan produk menjadi layanan mikro dan sub-produk, di mana satu tim dapat bertanggung jawab. Kami sekarang memiliki Pemilik Produk untuk setiap produk, tim lintas fungsi, yang masing-masing memiliki pengembang, penguji, analis, dan bagian dari fungsi tempat orang-orang dapat saling tumpang tindih.
Biasanya, kami memiliki pertemuan satu-ke-satu, OKR, umpan balik 360. Yang menarik adalah fungsi pemilik kumpulan sumber daya. Ini adalah orang-orang yang bertanggung jawab atas kumpulan Java, JS, Python, pengujian, analitik, dll. Setiap insinyur di perusahaan memiliki manajer bisnis (Pemilik Produk) yang memahami seberapa banyak seseorang berinvestasi dalam suatu produk dan berapa banyak keuntungan yang didapat dari pekerjaannya, dan ada seseorang yang bertanggung jawab untuk pengembangan teknis dalam kompetensi spesifiknya.
Kami mengabaikan formalisasi transisi antar kelas seperti "untuk pindah dari SMP plus ke minus Tengah, Anda perlu melakukan ini dan itu". Kami khawatir jika kami memberikan kriteria yang jelas untuk transisi, maka orang akan mulai mendekati ini terlalu formal. Tetapi formalitas berbahaya di sini, karena di setiap tim semuanya bisa sangat individual: satu dan orang yang sama dapat mengambil tanggung jawab lebih dan karena ini berkembang, atau memompa dalam segmen sempit teknologi yang khusus untuk kita, dan karena ini menjadi lebih berharga untuk bisnis.
Untuk posisi senior, difusi pengetahuan merupakan prasyarat penting untuk pertumbuhan. Anda bukan Senior dalam ruang hampa, Anda berbagi pengalaman dengan tim dan menarik orang lain bersama Anda.
Sergey Averyanov, CTO, Funbox. Kami telah mengembangkan perangkat lunak untuk Tiga Besar operator selama lebih dari 10 tahun. Saat ini, kami memiliki sekitar dua ratus pengembang dari berbagai profil dan cukup banyak spesialis teknis dalam dukungan teknis.
Di satu sisi, kami tidak memiliki satu produk pun yang melibatkan seluruh tim, dan di sisi lain, tidak ada aliran besar proyek dan tugas seperti dalam outsourcing. Di sinilah perkembangan profesional khusus insinyur kami tumbuh. Kami sengaja mengabaikan sistem penilaian formal: mungkin inilah yang diinginkan oleh manajemen dan karyawan itu sendiri, tetapi ini adalah sistem yang sangat tidak fleksibel yang mencoba menata semua orang dengan gaya yang sama, yang tidak selalu memungkinkan dalam praktiknya. Alih-alih, kami menggunakan hal-hal yang cukup standar: penilaian berkala atas kemajuan karyawan dan percakapan empat mata. Kami memiliki kesempatan untuk menilai secara obyektif kontribusi dari setiap Pelacak Tugas. Semua ini digabungkan memberi kami pemahaman tentang level masing-masing insinyur.
Di sisi lain, salah satu tujuan utama kami adalah membuat setiap orang memahami bagaimana dan di mana dia bisa berkembang. Kami mencoba mempertimbangkan fakta bahwa semua orang berbeda: seseorang tertarik untuk bekerja sebagai pakar teknis, berkomunikasi minimal dengan orang, dan tidak menyelami hal-hal administratif; seseorang ingin berkomunikasi, bekerja dengan orang, berpartisipasi dalam pengembangan rekan kerja. Semua ini normal, semua opsi pengembangan dimungkinkan.
Kami mencoba membangun sistem yang memungkinkan kami meningkatkan level insinyur dan memberi mereka panduan yang jelas tentang apa yang diinginkan bisnis dari mereka dan ke mana mereka dapat melangkah selanjutnya. Kami juga menaruh perhatian besar pada pertumbuhan internal. Saya dan seluruh tim percaya bahwa spesialis terbaik adalah spesialis yang kami angkat dalam tim. Oleh karena itu, kami secara aktif berinvestasi dalam pengembangan internal, dalam pertemuan, konferensi internal dan eksternal. Ini juga salah satu tujuan utama - pengembangan penuh dan berkualitas tinggi dari semua teknisi kami.
Perkembangan seorang karyawan tidak harus ditangani oleh departemen pengembangan abstrak. Ini adalah salah satu tanggung jawab manajer lini.
Pendekatan ini memberikan nilai tambah bagi kami dan karyawan itu sendiri. Di satu sisi, kami memiliki pertumbuhan organik yang konstan di antara staf. Di sisi lain, kita dapat menjadikan junior senior dan pemimpin tim dari mantan junior, dan karyawan itu sendiri melihat bahwa atasan langsungnya adalah orang yang menjadi junior dalam proyek ini empat tahun lalu, yang berarti bahwa sebelum bekerja sama sekarang memiliki peluang yang sama dan langkah yang dapat dimengerti untuk pertumbuhan.
Mikhail Mazein, Pimpinan Teknik, ManyChat.Kami sedang mengembangkan platform pemasaran SaaS yang memungkinkan Anda mengatur komunikasi antara bisnis dan pelanggan mereka. Perusahaan ini secara aktif berkembang: tiga tahun lalu ada 15 orang di tim, sekarang ada lebih dari 120 orang. Pada tahap pertama, kami bekerja dengan tim fungsional klasik: backend, frontend, pengujian, tim desain. Setiap tim memiliki ketua tim yang bertanggung jawab atas perencanaan sprint dan dekomposisi tugas.
Dalam proses pertumbuhan, kami menyadari bahwa hal ini menghalangi kami untuk bergerak pada kecepatan yang diinginkan dan memformat ulang pekerjaan menjadi tim lintas fungsi. Sekarang kami memiliki sembilan tim lintas fungsi, tidak ada pemimpin tim, karena tim-tim tersebut ternyata terorganisir sendiri dan dapat bertanggung jawab atas cara mereka bekerja.
Untuk mensinkronisasikan hal-hal fungsional, kami mengembangkan pendekatan umum agar pembangunan tidak berubah menjadi anarki. Ini diperlukan, misalnya, saat developer backend didistribusikan ke berbagai tim, tetapi bekerja dengan satu project, dengan satu basis kode, dan komit kode di sana. Kami mengatur komunitas fungsional untuk mengatasi masalah ini. Seiring waktu, pemimpin informal muncul dalam komunitas yang mendorong proses dan komunikasi. Hasilnya adalah struktur datar yang tidak membatasi peran pengembang pada peran seorang insinyur yang hanya menulis kode, tetapi memungkinkan Anda untuk melakukan berbagai hal yang berguna bagi perusahaan dan pada saat yang sama menarik bagi orang itu sendiri.
Karena kami mengabaikan peran sebagai pemimpin tim, kami memerlukan proses yang memungkinkan kami membangun jalur pertumbuhan secara jelas dan transparan bagi para insinyur. Untuk ini, kami menggunakan sistem mentoring: setiap karyawan memiliki mentor yang bertanggung jawab atas pertumbuhan dan perkembangannya di dalam perusahaan.
Anda tidak bisa begitu saja menghampiri orang sembarangan dan berkata, "Biarlah Anda menjadi mentor." Pertama, beberapa faktor harus dikumpulkan: keinginan orang itu sendiri; tingkat kepercayaan yang tinggi dalam tim kepada orang tersebut; kepercayaan dari perusahaan itu sendiri dan dari manajemen. Salah satu tugas mentor adalah melahirkan mentor baru. Ternyata pemula seperti itu, dari mentor menjadi mentor.
Kami membedakan tiga vektor utama pembangunan:
- Jalur besar pertama adalah pekerjaan yang lebih dalam di tim produk untuk pengembangan produk, dengan pemahaman yang lebih dalam tentang nilai bisnis, metrik.
- – , , .
- – , .
Kami juga mencoba membuat sistem penilaian: kami belum bisa mendeskripsikan semua nilai secara formal, sehingga sistem dibangun pada level kontribusi seseorang, level tim, level seluruh perusahaan. Kami menjelaskan ekspektasi di setiap tingkat, area tanggung jawab atau area pengaruh apa yang kami harapkan dari seseorang, dengan contoh yang jelas. Seorang mentor, di sisi lain, dapat memberi tahu seseorang keterampilan apa yang perlu dipompa untuk mencapai titik yang diinginkan.
Anton Grishin, Kepala Pengembangan, MadRobots. Sekilas, perusahaan kami adalah e-commerce yang berhubungan dengan gadget, tetapi secara umum kami bergerak di bidang distribusi di Rusia dan pengembangan merek barang-barang keren.
Tim kami telah berkumpul relatif baru-baru ini, jadi kami belum pusing terkait dengan perkembangan insinyur di dalam perusahaan. Sebelum Madrobots, saya bekerja di outsourcing selama 6 tahun, tiga di antaranya bertanggung jawab langsung atas produksi di agensi, dan saya ingin memberi tahu Anda lebih banyak tentang pengalaman ini.
Dalam outsourcing, rasa sakit kami adalah aliran besar proyek dan pergantian staf, dalam outsourcing ini selalu terjadi. Kami memutuskan bahwa kami perlu mengatasi masalah ini dan mulai berinvestasi dalam pengembangan karyawan.
Ya, kami memiliki sistem penilaian, setiap enam bulan sekali seseorang menerima umpan balik dari manajer teknis, membangun jalurnya sendiri bersamanya selama enam bulan ke depan.
, . , . , , , .
Selanjutnya, kami merasakan sakit lagi. Dalam aliran proyek, yang sering kali cukup banyak, orang kehilangan fokus pada pengembangan pribadi. Ini terjadi bukan karena mereka tidak punya cukup waktu, tetapi karena mereka lelah dengan banyaknya tugas yang harus mereka lewati. Kami memperkenalkan praktik pertemuan satu-ke-satu, sebulan sekali, yang bertujuan untuk berbicara dengan seseorang dan mengingatkan mereka bahwa Anda memiliki rencana pengembangan dan itu benar-benar harus ditaati. Jika Anda memerlukan waktu untuk ini, dan Anda harus dibebaskan dari rutinitas atau terus-menerus di luar situs, mari kita bahas, karena pos pemeriksaan Anda semakin dekat dan Anda perlu melakukan sesuatu. Itu membantu. Biasanya, ini dilakukan oleh PM tim, karena siapa, jika bukan mereka, lebih tahu dalam merencanakan sumber daya untuk masa depan.
Tantangan dalam sistem pembangunan saat ini
Artem Susekov, Miro. Sulit untuk langsung menyeimbangkan sistem penilaian, jadi kami terus melakukan iterasi. Misalnya, versi pertama dari trek pemimpin tim ternyata kelebihan beban: ekspektasi yang terlalu tinggi, seorang prajurit super universal, yang hampir tidak mungkin dilakukan dalam hidup.
Saat ini kami mencoba menyederhanakan ambang batas untuk memasuki peran pemimpin tim sehingga lebih mudah bagi orang untuk beralih dari cabang teknik murni ke cabang manajer. Saya tidak ingin melebih-lebihkan standarnya, kami membutuhkan kesempatan untuk berpindah dengan lancar ke bidang aktivitas baru ini.
Kesulitan lainnya adalah pendekatan proses yang terlalu formal. Misalnya, "Saya melakukan 8 dari 10 poin dalam rencana, yang berarti saya memenuhi ekspektasi dan dapat naik ke level berikutnya." Kami tidak ingin mengubah semua ini menjadi daftar periksa yang hanya perlu Anda tutup untuk naik ke level berikutnya, seperti dalam game.
Saya ingin orang-orang dapat memikirkan prospek berdasarkan rencana, untuk memikirkan sendiri tentang bidang yang mereka minati, yaitu, sehingga mereka bekerja dengan ini sebagai strategi, dan bukan sebagai daftar tugas formal.
Alexander Borisov, Grup Ritel X5. Orang sering kali tidak mengerti persis bagaimana mereka bisa tumbuh di sebuah perusahaan, karena tidak ada algoritma yang jelas. Pada saat yang sama, orang yang benar-benar dapat dipromosikan menemukan hal-hal yang dapat dan harus mereka kembangkan, hal-hal yang dapat diambil alih dan diperbaiki. Tapi kebetulan ada kebutuhan untuk "bertumbuh". Tetapi mungkin tidak mungkin untuk tumbuh di perusahaan begitu saja, karena Anda ingin berkembang.
Anda hanya tumbuh ketika Anda mengambil lebih banyak tanggung jawab, mengambil proyek baru.
Sergey Averyanov, Funbox . Sejak kami bekerja selama bertahun-tahun, kami menghadapi banyak masalah dan tantangan. Salah satu yang pertama adalah memahami dengan siapa kita ingin bekerja, dengan siapa kita ingin berkembang. Akibatnya, kami sampai pada kesimpulan bahwa kami ingin bekerja dengan orang-orang yang tahu bagaimana melakukan sesuatu dengan baik, dan itu tidak terlalu penting tentang apa. Kami bersedia mengambil spesialis dari tumpukan mana pun yang siap menggunakan apa yang kami gunakan. Ini ternyata merupakan praktik yang cukup berhasil: selalu menyenangkan dan nyaman untuk mengembangkan orang-orang yang sudah memiliki kompetensi dalam bidang subjek terkait. Kesenjangan pengetahuan yang mereka miliki bukanlah cacat yang fatal, tetapi motivasi baru bagi seseorang, mempelajari bidang aktivitas baru.
Tantangan kedua adalah memahami bagaimana insinyur di perusahaan dapat berkembang. Untuk pengembangan, Anda perlu menciptakan kondisi kerja yang nyaman: kantor normal, dapat dimengerti, sederhana, tetapi prosedur dan peraturan kerja yang ketat, kepatuhan terhadap Kode Tenaga Kerja, tidak suka bekerja berlebihan. Semua ini memberi seseorang kepercayaan diri bahwa dia dapat meningkatkan levelnya tanpa repot, tanpa terburu-buru. Mereka akan menunjukkan padanya, memberitahunya, membantunya.
Anda bisa berteriak pada kentang sebanyak yang Anda suka: “Kentang, tumbuh! Tomat, ayo! ”- tetapi mereka tidak akan tumbuh dari sini. Mereka membutuhkan tanah dan penyiraman yang baik.
Tantangan terakhir adalah tidak semua orang ingin tumbuh di tempat yang kita inginkan. Kebetulan seorang spesialis yang kuat dalam keadaan apa pun tidak ingin menangani beban administratif dan bekerja dengan kolega yang lebih muda. Di sini pertanyaannya bukan pada hal-hal formal, bukan dalam gaji, tetapi hanya pada apa yang menjadi minat dan kecenderungan seseorang. Itulah sebabnya di semua teknisi kami menghargai semangat, kemampuan untuk mengambil tugas yang kompleks dan melaksanakannya melalui proses multi-langkah dari awal hingga akhir. Biasanya, setiap insinyur yang mampu melakukan ini menarik dan menyenangkan bagi kami. Tapi, seperti yang saya katakan, seiring dengan hal tersebut, kami selalu memberikan kesempatan kepada seseorang untuk menjadi ahli teknis, tanpa terjun ke fungsi administrasi dan manajemen.
Mikhail Mazein, ManyChat... Cukup sulit untuk memformalkan persyaratan untuk nilai, dan kami juga tidak mencoba memformalkannya secara ketat, berfokus pada contoh ekspektasi tentang apa yang ingin kami lihat dari seorang insinyur di berbagai tahap pengembangan. Semua ini dibungkus dalam dampak khusus yang dibawa orang ke proses di tingkat tim atau perusahaan.
Ini menciptakan kesulitan. Di satu sisi, kami tidak membatasi orang yang sedang tumbuh, kanvas kosong muncul di depan mereka, tempat mereka dapat menggambar jalur perkembangan mereka. Tetapi menggambar gambar baru di atas selembar kertas kosong jauh lebih sulit daripada bergerak di sepanjang jalur yang sudah biasa. Kami menyelesaikan masalah ini dengan pendampingan. Mentor membantu membangun jalur berdasarkan keinginan orang dan menyelaraskannya dengan kebutuhan perusahaan. Kami juga mencoba mengembangkan pola pikir pencarian masalah sehingga para insinyur menemukan masalah dalam proses dan mencoba memulai solusi mereka sendiri. Dalam hal ini, sekali lagi, mentor membantu.
Anton Grishin, MadRobots.Ada orang yang pertumbuhan adalah kebutuhannya sendiri, dan ada orang yang tumbuh, karena begitulah adanya dan kondisi diciptakan untuk ini. Tetapi mereka semua secara berkala memiliki pertanyaan - jadi apa? Motivasi pribadi untuk mempelajari hal-hal baru, untuk pengembangan hilang, karena ini mungkin tidak dapat diterapkan dalam kenyataan saat ini atau dengan kolega saat ini.
Sebagai salah satu solusinya, kami mengadakan internal meetup, namun bukan sebagai hobby group, melainkan sebagai konferensi internal, dengan persiapan topik yang baru secara nyata. Sebuah cerita positif muncul dari ini, orang-orang mulai memahami di antara mereka sendiri bahwa jika, misalnya, frontend dapat melakukan sesuatu yang baru, maka kami, desainer dan desainer, dapat memikirkan kembali pendekatan kami dan mencoba alat baru. Ternyata motivasi alamiah masing-masing untuk mencoba melakukan sesuatu yang baru bersama.
Rasa sakit selalu menyebabkan pendekatan pribadi setiap individu pada perkembangannya sendiri.
Bagaimana menerapkan budaya pengembangan di awal tim baru
Sergey Averyanov, FunBox: Fakta pertumbuhan perusahaan sangat membantu kami. Jika tidak banyak insinyur, mereka semua memasak bersama, mereka semua mengenal satu sama lain dan melakukan jenis tugas yang sama. Dan segera setelah berbagai jenis proyek dan peran di dalamnya mulai berbaris, maka semua orang diberkahi dengan kekuatan yang berbeda. Seseorang melakukan tugas, seseorang terlibat dalam penerapan, kelompok, seseorang terlibat dalam desain produk.
Penting bagi kami bahwa setiap anggota tim memahami apa yang dia perlukan untuk meningkatkan untuk beralih dari pengembang ke pengembang tingkat yang lebih tinggi atau pemimpin tim.
, 125 , , , , .
Pertemuan internal sangat berguna. Ketika sebuah perusahaan memiliki banyak tim dan beberapa produk, setiap orang memasak dengan saus mereka sendiri, dan pada pertemuan mereka berbicara, menceritakan hal-hal keren yang mereka lakukan, bertukar pengetahuan. Ini tidak menghasilkan persaingan antar tim, tetapi mengejar keunggulan.
Artem Susekov, Miro: Pada satu tahap pertumbuhan tim, berbagai serikat yang dibentuk di sekitar teknologi membantu dengan baik: backend, frontend, QA. Di guild, pengetahuan dipertukarkan antara tim yang berbeda.
Acara internal juga membantu: pertemuan, Ulasan Sprint publik, tempat tim berbagi konteks yang sama, membicarakan hasil. Penting di sini untuk membantu insinyur mempersiapkan pertunjukan seperti itu.
Alexander Borisov, Grup Ritel X5:Anda tidak dapat berharap bahwa Anda akan mengatakan bahwa pertemuan itu diperlukan, dan orang-orang mulai mengatur diri mereka sendiri. Mereka juga perlu ditangani. Dalam kasus skala kami, masuk akal untuk memilih orang yang bertanggung jawab yang mengaturnya. Tim sering kali memiliki hal-hal keren di dalamnya, tetapi mereka memasak di dalam diri mereka sendiri, mereka tidak punya cukup waktu untuk mengatur pertemuan dan berbagi praktik terbaik mereka. Tampaknya kami akan menghabiskan waktu setengah jam, berkumpul di ruang rapat, dan menghabiskan waktu, tetapi tidak. Ada beberapa nuansa.
Mikhail Mazein, ManyChat: Proses orientasi yang terstruktur dengan baik untuk orang baru memungkinkan kami untuk menyampaikan kepada mereka prinsip dan pendekatan umum, untuk membentuk gambar tim dan proyek dengan benar. Sehingga budaya dengan kedatangan orang baru akan terakumulasi dan diwariskan.
Pertanyaan panas tentang uang
Sebuah pertanyaan dari pemirsa: “Anda tidak menyentuh kesehatan keuangan organisasi. Bagaimana bagian dari pengeluaran perusahaan ditentukan bagi karyawan untuk membaca buku selama jam kerja? Yang kedua adalah contoh, biarkan solusi dari suatu masalah membutuhkan waktu 80 jam untuk pengembang yang telah memecahkan masalah seperti itu, dan 150 jam akan mengambil solusi dari masalah yang sama untuk pengembang yang tidak terbiasa dengan konteksnya, tetapi pada saat yang sama ia akan tumbuh dan berkembang. Pertanyaannya adalah siapa yang akan membayar selisih 70 jam yang dihabiskan untuk pembangunan. "
Alexander Borisov, Grup Ritel X5:Dalam kasus kami, tidak ada pelanggan. Kami mulai secara aktif membangun tim internal alih-alih terus melakukan outsourcing beberapa hal, karena kami memahami bahwa kompetensi sangat mahal bagi kami dan mengakibatkan biaya akhir, dalam meningkatkan marjinalitas bisnis, dari Pyaterochka tertentu di rumah Anda. Ini adalah investasi untuk masa depan.
Tetapi jika seseorang, alih-alih melakukan tugas selama tiga jam selama 150 jam, malah membaca buku, maka pertanyaan yang akan muncul hanya dari pemilik produk atau dari pemilik kumpulan sumber daya. Jika ini adalah investasi yang dapat dimengerti dalam kenyataan bahwa seseorang telah tumbuh, maka, sekali lagi, pada tingkat dua orang ini, ini mudah diselesaikan. Misalnya, rencana untuk sprint, masing-masing, di dalamnya kami meletakkan sesuatu yang perlu dibaca, dan kami menyesuaikannya, ini adalah cerita biasa.
Artem Susekov, Miro:Ada kesepakatan di tingkat perusahaan bahwa kami membantu para insinyur mengembangkan melalui kursus dan lokakarya, yang diadakan dalam jam kerja. Artinya, perusahaan yang membayarnya, itu adalah investasi di setiap anggota tim, karena kami percaya bahwa investasi semacam ini akan membantu seluruh tim bergerak lebih cepat di masa depan.
Waktu khusus yang disediakan untuk insinyur untuk pendidikan sprint dibahas di tingkat tim tertentu. Penting di sini bahwa tidak ada distorsi ke arah lain, bahwa kita hanya belajar sepanjang waktu selama sprint dan tidak melakukan yang lain.
Sergey Averyanov, FunBox:Saya pikir pertanyaan tentang 80 dan 150 jam lebih akut untuk outsourcing, ketika Anda bisa bertanya - mengapa pengembang yang tidak berpengalaman harus melakukan 150 jam untuk saya, sebagai pelanggan, jika pengembang berpengalaman melakukan hal yang sama untuk saya di atas 80? Bagaimana outsourcing memecahkan masalah ini, saya tidak bisa mengatakan, karena kami bukan outsourcing. Dalam kerangka perusahaan produk, ini diselesaikan dengan fakta bahwa anggaran dikonsolidasikan, dan biaya tenaga kerja untuk pengembangan dinyatakan dalam laba karena fakta bahwa seorang anggota tim menaikkan levelnya, mulai bekerja lebih baik, lebih cepat.
Tentang membaca buku selama jam kerja. Kami memiliki praktik bahwa kebutuhan untuk mempelajari sesuatu adalah langkah yang sepenuhnya alami dalam menangani masalah. Kami tidak melemparkan pengembang ke dalam pusaran, menetapkan tugas seperti: "Membaca buku" atau "mempelajari teknologi yang tidak memiliki tujuan akhir." Seharusnya tidak seperti seseorang yang duduk dan berpikir - apakah saya sudah mempelajari teknologi atau apakah saya perlu belajar lebih banyak? Sebuah tugas di luar konteks, di luar tujuan menyebabkan penundaan, pada fakta bahwa seseorang kehilangan kepercayaan diri dan tidak tahu kapan harus melakukan sesuatu.
Meneliti dan membaca literatur, mempelajari apa pun harus menjadi bagian dari tugas, tetapi harus ada tujuan nyata akhir yang studi ini dapat diterapkan.
Anton Grishin, MadRobots: Saya berasal dari dunia di mana setiap jam seseorang menghasilkan, dan seseorang kehilangan uang. Biasanya, pelanggan dengan jujur diberitahu: "Kami tidak akan mengambil uang lagi dari Anda, tetapi kami akan melakukan tugas itu lebih lama." Perusahaan, majikannya, tetap membayar untuk pengembangan seorang insinyur. Pelanggan hanya menunggu sedikit lebih lama, tetapi di masa depan dia memahami bahwa sekarang bukan hanya satu, tetapi dua pengembang terlibat dalam pengembangan produknya, semuanya diselesaikan lebih cepat, skala penerapannya meningkat.
Di studio dan agensi, di mana proses biasanya dibangun, pengembang tidak akan pernah ditempatkan pada proyek yang secara obyektif tidak menariknya, karena dia akan membawa lebih banyak kerugian bagi perusahaan daripada yang akan dia peroleh dari pengembangan.
Alexander Borisov, Grup Ritel X5:Selain pekerjaan saya di X5, saya memiliki studio outsourcing kecil sendiri. Saya memahami ekonominya dengan sangat baik. Kami menetapkan 80 jam berbayar, tetapi kami memahami bahwa itu 150, dan jumlah jam berbayar dan waktu pengembangan, mereka sangat sering berbeda. Kami selalu mengambil beberapa jenis saham, dan kami hanya membayar saham ini dari uang kami sendiri. Jika di suatu tempat ada semacam force majeure, artinya dibayar dari uang sendiri.
Mikhail Mazein, ManyChat: Pengembangan produk, di mana kami tidak memiliki pelanggan eksternal, sangat melepaskan ikatan kami dalam hal ini. Secara umum, kami tidak melacak kinerja masing-masing individu, kami mengukur kinerja tim.
Setiap tim memiliki kapasitas dan kecepatannya masing-masing, mereka dapat sangat bervariasi, tetapi secara umum, kami fokus pada kinerja seluruh tim secara keseluruhan. Berapa banyak waktu luang yang dimiliki engineer tertentu dalam sprint saat ini tidak terlalu penting bagi kami, sebagai perusahaan, waktu ini selalu tersisa untuk pelatihan, dan dari sprint hingga sprint, pada prinsipnya, berbeda untuk setiap engineer. Di suatu tempat di sprint, akan ada lebih banyak beban di frontend, di sprint berikutnya akan ada lebih banyak beban di backend, dan keseluruhan cerita ini akan mendatar dalam jangka panjang.
Jika kita berbicara tentang menilai kinerja masing-masing individu, tim itu sendiri yang bertanggung jawab untuk ini, ini seperti struktur yang mengatur diri sendiri. Ada situasi ketika umpan balik datang, misalnya, dari mentor orang ini, ada sesuatu yang salah dengan kinerjanya, atau dari rekan-rekannya dari komunitas fungsional.
, ?
, Miro: , , . , , … , .
Sergey Averyanov, FunBox: Saya pikir mungkin ada perusahaan yang berfokus pada spesialis tingkat tetap, mereka selalu memiliki pekerjaan yang sama dengan kualifikasi yang sama, mereka tidak ingin membesarkan siapa pun. Ini diselesaikan dengan fakta bahwa ada pergantian yang besar, dan karyawan yang tumbuh besar dapat mencari pekerjaan baru. Entah kita berinvestasi dalam pengembangan karyawan dan perluasan perusahaan, atau kita memiliki omset.
Artem Susekov, Miro: Ini sudah bisa dihitung, kalau bicara omzet, kita akan tetap berpegang pada metrik ini, kalau soal uang ya? Biaya untuk menarik setiap orang baru, berapa banyak waktu yang dihabiskan untuk perekrut, berapa banyak yang kita habiskan untuk onboarding dan berapa banyak kita kemudian, ketika orang itu pergi, kita menutup lowongan lagi. Semua ini bisa dihitung dengan uang.
Sergey Averyanov, FunBox:Selain itu, salah satu indikator menarik yang bahkan berguna untuk dilihat sendiri adalah median masa kerja di perusahaan tersebut. Ini memungkinkan kami untuk memperkirakan omset, yaitu berapa banyak orang yang bekerja di median kami. Ketika Anda melihat bahwa mediannya besar dan di tepi distribusi ini ada orang yang telah bekerja selama delapan hingga sepuluh tahun, belum kelelahan, mereka baik-baik saja dan semua orang bahagia satu sama lain, itu membuat saya bahagia.
Anton Grishin, MadRobots: Bagi saya sekarang bisnis tidak perlu menjelaskan semua ini, jelas bahwa kebutuhan untuk pengembangan diri melekat pada orang yang menciptakan produk intelektual. Oleh karena itu, saya bahkan tidak dapat memikirkan contoh di mana spesialis dengan tingkat yang sama dibutuhkan, karena teknologi yang kita gunakan sangat menentukan bahwa kita perlu mengembangkan.
Mishan Storozhilov, biro DevRel:Menurut saya, ini bukan hanya tentang orang-orang dengan kinerja tetap dan teknologi tetap. Saya pikir cerita ini juga tentang refactoring besar-besaran, hutang teknis yang besar. Kami bekerja dengan perusahaan yang memahami kebutuhan untuk mengembangkan insinyur, tetapi pertanyaan tentang membenarkan biaya pendidikan dan pengembangan selalu muncul.
Sergey Averyanov, FunBox:Di sini kata "refactoring" terdengar, dan sikap terhadapnya bisa jadi menarik. Banyak orang keliru berpikir, terutama spesialis non-teknis, bahwa ini adalah beberapa gerakan aneh pria berkerudung yang tidak melakukan apa-apa dan menghabiskan uang. Di sini masalahnya justru pada komunikasi, yakni pengelola harus memahami bahwa refactoring yang tidak terjadi hari ini adalah bertambahnya waktu pengembangan esok hari. Hari ini kita akan menghemat beberapa jam kerja, dan besok kita akan menghabiskannya.
Kami telah sepakat secara internal bahwa ketua tim berhak untuk mengatakan bahwa syarat yang diperlukan untuk menyelesaikan tugas adalah melakukan refactoring, tanpa dia kami mendapatkan omong kosong sehingga tidak mungkin untuk dikerjakan.
Biasanya, ini pada akhirnya adalah masalah kesepakatan, tetapi kami tidak mempertimbangkan pemfaktoran ulang sebagai aktivitas sampingan dan membuang-buang sumber daya, tetapi sebagai bagian dari alur kerja.
Artem Susekov, Miro: Jika kita berbicara tentang pengembangan produk, kesepakatan itu penting. Misalnya, Manajer Produk menentukan prioritas berdasarkan penilaian, dan tim atau suara tim, pimpinan teknis atau pimpinan tim, menentukan dengan tepat cara melakukannya. Produk mengatakan apa yang paling penting sekarang, insinyur mengatakan bagaimana kami akan melakukannya.
Refactoring adalah proses alami. Refactoring hari ini akan membuat kami jauh lebih murah daripada refactoring dalam seperempat. Ini seperti pinjaman - jika Anda tidak membayar, maka lain kali Anda harus membayar lebih.
Alexander Borisov, Grup Ritel X5: Ada istilah "utang teknis", dan hanya pada tahap komunikasi antara tim dan produk, kami memahami bahwa jika kami tidak melakukan ini sekarang, ini adalah utang teknis. Dengan demikian, melalui sprint, hutang teknis akan lebih besar, dalam enam bulan akan lebih banyak dan Anda harus membayar dengan persentase ini. Faktanya, seperti pinjaman biasa, dengan cara yang persis sama tim melakukan tawar-menawar dengan produk, jika Anda menginginkannya lebih cepat atau secara manusiawi. Jika lebih cepat, suatu hari nanti Anda harus membayar lebih. Seperti pinjaman.
Mishanya Storozhilov, biro DevRel: Entah utang ini hanya berubah menjadi "hipotek teknis".
Kami mengumpulkan lima insinyur, mereka hanya berbicara selama satu setengah jam dan sudah mulai berbicara tentang pemfaktoran ulang.
* * * Pertemuan
kedua seri ini akan berlangsung pada 20 Agustus . Topiknya adalah toksisitas dalam tim, perusahaan, dan industri. Pembicara - insinyur dan pimpinan teknis dari Miro, SEMrush, Parma TG, Xsolla.
Pendaftaran dibuka .