Pada 23-24 September,
Saint TeamLead Conf 2019 diadakan di St. Petersburg. Flant berperan aktif di dalamnya: Igor Tsupko (direktur kami untuk yang tidak diketahui) mengadakan pertemuan di mana para peserta memahami bagaimana menemukan dan mengungkapkan pengetahuan rahasia di dalam organisasi, dan Sergey Goncharuk (manajer proyek) membuat presentasi “Mengelola tim yang didistribusikan di multi-proyeksi. " Secara tradisi, kami menerbitkan ulasan laporan dan
videonya (~ 37 menit).
“Tim terdistribusi” dan “multi proyek”
Di bawah tim terdistribusi, perusahaan-perusahaan yang berbeda memahami hal-hal yang sangat berbeda - misalnya, jaringan cabang atau kantor dan pekerja jarak jauh ... Tetapi dalam kasus kami tidak ada kantor dalam arti "nyata".
Sekarang kami memiliki lebih dari 80 karyawan yang tinggal di lebih dari 20 kota di Rusia dan sekitarnya. Sebagian besar dari kita melihat satu sama lain "hidup" hanya 2 hari setahun, pada hari ulang tahun "Flanta".
Sisa waktu kami tinggal di Moskow, Samara, Tyumen, Nizhny Novgorod atau kota lain mana pun, kami bekerja dengan kicau burung atau aroma kopi. Alih-alih menyewa tempat, kami menginvestasikan uang dalam sesuatu yang sangat berguna. Dan karena semua orang bekerja dari jarak jauh, kami tidak memiliki divisi menjadi "cabang" atau "kasta".
Dan yang paling penting - kami mempekerjakan yang terbaik, terlepas dari batasan apa pun! Itulah arti "distribusi" dalam pengertian kita.
Sekarang mari kita berurusan dengan multi-desain, tetapi untuk permulaan penting untuk sedikit menyelam ke perangkat Flanta.
Kami adalah perusahaan teknik, kami memiliki banyak insinyur. Lima hingga tujuh insinyur di bawah bimbingan pemimpin tim dan manajer membentuk tim. Ada beberapa tim seperti itu, dan masing-masing tim memiliki serangkaian proyek sendiri.
Bagi kami, proyek adalah infrastruktur klien untuk satu produk atau satu tim pengembangan. Artinya, proyek ini memiliki batas yang jelas, tetapi tidak ada batasan pertumbuhan dan pembangunan!
Setiap proyek memiliki kebutuhannya sendiri, yang entah bagaimana harus disampaikan kepada tim.
Ini dilakukan oleh manajer. Ini adalah dasar-dasar "multi-desain."
Sekarang kita memiliki pemahaman yang sama tentang istilah-istilah dari judul laporan, pertanyaannya adalah: apa yang diperlukan untuk memastikan bahwa dalam kondisi seperti itu semuanya tidak hanya berfungsi, tetapi berfungsi dengan baik?
Manajer tim bertanggung jawab untuk menyelesaikan masalah ini. Menjadi "penerjemah" dari klien ke teknik adalah salah satu kompetensi kuncinya. Yang kedua adalah organisasi komunikasi yang konstruktif dalam tim dan dengan pelanggan. Dan kompetensi inti ketiga adalah menemukan keseimbangan antara aliran pekerjaan dan kemampuan nyata para insinyur:
Kami akan menganalisis setiap kompetensi secara lebih rinci.
1. Siaran harapan
Bahkan klien yang sama mungkin memiliki harapan yang bertentangan. Misalnya, bisnis klien mensyaratkan bahwa produksi penghasil uang stabil. Dan di samping itu, terus-menerus diisi ulang dengan fitur-fitur baru yang membantu meningkatkan pendapatan.
Nah, jika ada kecelakaan terjadi (bisnis siap untuk kecelakaan terjadi), itu akan dihilangkan sesegera mungkin. Kedengarannya sangat mudah ditebak, bukan?
Tetapi klien ini juga memiliki pengembang. Dan ternyata harapan mereka benar-benar berbeda! Untuk pengembang dev, produksi lebih penting (setelah semua, bisnis juga menekan mereka), dan mereka juga berharap bahwa setiap permintaan mereka akan didengar dan dibuat sekarang (biasanya ini dijelaskan dengan frasa "setelah semua, ada 5 menit kerja").
Satu-satunya hal yang menyatukan bisnis dan pengembang dalam persyaratan adalah bahwa keduanya mengharapkan tugas yang direncanakan dilakukan secara akurat dan tepat waktu.
Mari kita lihat gambar secara keseluruhan ... Ya, itu langsung penuh dengan paragraf yang saling eksklusif!
- Menambahkan fitur baru selalu menambah titik kegagalan baru. Babah! Dan produksi tidak stabil setelah rilis Jumat.
- Teknisi kami melakukan secepat mungkin pada siang hari semua yang diminta pengembang, dan tugas yang direncanakan tetap tidak tersentuh karena ini.
- Atau begini ceritanya: lingkungan stabilitas apa yang lebih diperhatikan? Kami menstabilkan dev dengan mengalokasikan sumber daya untuk ini, tetapi setelah peluncuran lain, produksi mulai turun!
- Kasus yang sering terjadi: produksi mogok dan seluruh tim pergi untuk memperbaikinya. Pada saat yang sama, tentu saja, tidak ada kemajuan pada tugas yang direncanakan, dan bahkan pengembang dari India sudah beralih ke obrolan bahasa Rusia di obrolan, karena mereka tidak bisa menunggu jawaban.
Dan kami memahami bahwa persyaratan itu sendiri bertentangan, yang berarti bahwa tidak mungkin untuk secara langsung mengirimkannya.
2. Komunikasi
Benar-benar ada masalah dalam harapan penyiaran. Yah, mungkin setidaknya dengan komunikasi semuanya lebih mudah?
Untuk berkomunikasi satu sama lain dan dengan pelanggan, kami menggunakan Slack untuk teks dan Google Meet untuk rapat dan acara yang lebih mudah diucapkan daripada ditulis. Tetapi dalam obrolan kita sering menerima pesan yang tidak membawa makna yang berguna atau mengandung begitu banyak kesalahan sehingga sulit untuk mengenali artinya!
Mengapa kita memperhatikan ini? Faktanya adalah bahwa, misalnya, hanya pada bulan Juli 2019 kami menerima permintaan 1993 dari pelanggan di Slack, yang membutuhkan respons wajib. Dan, tentu saja, dengan pertumbuhan jumlah pelanggan, ada tren stabil dalam pertumbuhan jumlah permintaan tersebut. Pada bulan Juli, kami menghabiskan sekitar 165 jam rekayasa untuk menanggapi panggilan semacam itu. Tetapi untuk setiap banding, itu juga perlu untuk melakukan sesuatu!
Kami sangat menyesal ketika waktu insinyur, yang dapat diinvestasikan dalam tugas yang direncanakan, reaksi terhadap panggilan lain atau bahkan untuk memperbaiki kecelakaan, terbuang sia-sia.
Masalah dengan ruang obrolan sudah jelas, tetapi konferensi video mungkin tidak memiliki masalah?
Kami mengatakan di atas bahwa kami menggunakan Google Meet untuk aksi tim harian, dan sisa waktu kami melakukan tugas yang kami selesaikan di rapat umum. Setiap hari kami menghabiskan waktu sekitar satu jam untuk unjuk rasa. Kami mencoba menghabiskan setidaknya tujuh jam sehari untuk pekerjaan langsung, yaitu, 6 jam tersisa untuk menyelesaikan tugas. Tetapi tugas kami sangat berbeda dalam durasinya.
Jadi ternyata dalam satu jam rapat umum kami dapat menyelesaikan beberapa tugas kecil, tetapi mungkin penting untuk klien kami. Dan kita perlu memahami apakah pertemuan menonton benar-benar diperlukan atau lebih baik pergi dan bekerja saat ini?
Jika Anda mencoba menyatukan masalah komunikasi, kami melihat bahwa obrolan menghasilkan interupsi yang tidak berguna dan demonstrasi rutin "menghabiskan waktu" kerja.
Komunikasi yang efektif tidak berbaris sendiri.
3. Perencanaan
Kita perlu menyelesaikan masalah dalam harapan komunikasi dan penyiaran, tetapi dalam perencanaan, mungkin, tidak ada jebakan? Mari kita cari tahu.
Setiap hari banyak tugas baru dibuat. Saya ingin kita menutup tugas secepat mereka tumbuh. Namun dalam hidup, cita-cita jarang bisa dicapai. Pertama, terkadang ada sesuatu yang rusak dalam infrastruktur. Kedua, selalu ada beberapa hal kecil yang lebih mudah dilakukan segera. Ketiga, ada tugas yang kami setujui untuk selesaikan di rapat umum tim:
Dan terkadang itu terjadi karena kecelakaan dan menarik hal-hal sepele, tidak mungkin untuk mencapai yang direncanakan sama sekali! Pada saat yang sama, tugas baru tidak berhenti tiba - semua tenggat waktu yang dijanjikan rusak.
Resep kami
Tetapi untuk semua masalah dengan terjemahan harapan, dengan komunikasi dan perencanaan, metode isian kerucut, kami berhasil mendapatkan, sepertinya bagi kami, jawaban yang benar.
Salah satu proses bisnis utama yang mempengaruhi ketiga kompetensi inti adalah pertemuan tim. Dan kami memiliki asumsi bahwa jika kami membuat pertemuan tim efektif, kami dapat mencapai 80% dari hasil dengan dua puluh persen dari upaya? Kami menguji teori ini.
Seperti yang Anda ingat, kami memiliki tim yang melayani serangkaian proyek kami. Dan dia memiliki daftar persyaratan tertentu dari proyek-proyek ini. Tetapi setiap persyaratan, sebagai suatu peraturan, hanya satu dalam rantai tugas yang saling terkait. Demikian juga dalam setiap proyek! Dan sebelum mengambil tugas baru, kita perlu memahami apakah kita telah menyelesaikan tahap sebelumnya?
Kemarin, tugas A-1 dilakukan oleh Egor, tugas B-1 - Semyon, dan tugas B-1 - Jeanne. Tapi bagaimana kita bisa membenamkan semua insinyur dalam semua proyek begitu dalam sehingga Yegor berhasil mengatasi tugas B, dan Semyon dengan dua tugas kecil A dan B. "Mengapa semua kesulitan ini?" - kamu bertanya. Ya, faktanya adalah Zhanna tidak akan memenuhi tugas yang direncanakan untuk liburan hari ini!
Fokus kami adalah banyak tugas serupa. Rata-rata, kami menerima sekitar 25 tugas baru untuk setiap tim setiap hari kerja. Dan karena ada banyak tugas, koneksi di antara mereka bingung dan tidak ada pemahaman apakah semua tugas pada hari sebelumnya selesai. Untuk mengungkap semua ini, kita perlu reli tim, dan setiap hari kerja, kalau tidak kita tidak akan bisa mengelola aliran ini.
Mengingat volume aliran, ada baiknya bersiap untuk reli terlebih dahulu. Di pelatihan, tanpa insinyur, kami tidak akan dapat memahami tugas mana yang telah selesai dan yang belum. Dan, tentu saja, kita tidak akan dapat mentransfer pengetahuan dari insinyur ke insinyur. Tapi kami benar-benar dapat menentukan prioritas untuk mengambil tugas baru untuk bekerja.
Prioritas tugas
Apa yang kita berdasarkan ketika memprioritaskan tugas? Pertama, kami memiliki perjanjian strategis dengan klien tentang tujuan yang perlu dicapai. Kedua, seminggu sekali kami memperbarui rencana taktis untuk pertemuan online dengan pelanggan. Kebutuhan klien dalam persiapan ditegakkan oleh manajer, dan kebutuhan teknis dan prosedur untuk menyelesaikan satu atau tugas lain adalah pemimpin tim. Itu benar, berdasarkan
kesamaan pendapat pemimpin tim dan manajer , daftar tugas untuk hari itu terbentuk.
Budaya pertemuan tim
Segera setelah kami menentukan daftar tugas untuk hari itu untuk mengklarifikasi apa yang telah dilakukan dan membenamkan rekan-rekan kami dalam detail, kami memulai pertemuan tim di mana setiap insinyur harus memberi tahu secara terperinci apa yang dia lakukan kemarin, dan seluruh tim harus mendengar dan, yang paling penting, memahami perubahan yang telah terjadi. Tapi ini lebih mudah diucapkan daripada dilakukan.
Kami memperkenalkan sejumlah fitur budaya reli, yang memungkinkan kami untuk mencapai hasil yang diinginkan:
Di awal rapat umum, ketika semua orang berkumpul, kami menghabiskan 10-15 menit untuk berbicara tentang kehidupan. Tentang berita dan acara yang tidak terkait dengan pekerjaan, tentang hobi kolega. Jadi insinyur yang berada di kota yang berbeda dan hampir tidak pernah melihat satu sama lain menjadi teman atau bahkan teman. Dan
ini 10-15 menit sehari membantu tim untuk lebih bersatu .
Setelah selesai membangun pembicaraan, kami melanjutkan ke bagian substantif. Mari kita kembali sedikit.
Ingat ilustrasi ini? Faktanya adalah bahwa baik Semyon maupun Yegor tidak tahu tugas dan proyek apa yang akan mereka laksanakan hari ini sebelum rapat umum dimulai. Karena sejumlah alasan: liburan, perjalanan bisnis, sakit, tugas, dll. - tugas dapat mengubah pemain setiap hari sampai benar-benar diselesaikan. Dan setiap insinyur memahami bahwa hari ini tugas dapat ditugaskan kepadanya, yaitu, semua insinyur pada awalnya
tertarik untuk menggali rincian setiap tugas .
Di rapat umum, kami menganalisis hambatan yang muncul oleh seluruh tim. Kami mendesak agar seluruh tim ikut serta dalam memecahkan masalah pembicara. Jadi kami
memotivasi untuk terjun ke dalam tugas dan menyelesaikannya bersama .
Jika tim bekerja di kantor, komunikasi informal sering terjadi "di pendingin". Tetapi dalam tim terdistribusi, kebutuhan akan komunikasi semacam itu ada. Itu sebabnya, selama diskusi tugas, percakapan sering bocor di suatu tempat ke arah yang salah. Tapi kami menghentikan gangguan. Bagaimana tepatnya? Kami berhasil melakukan ini dengan mudah: setelah semua, ada waktu yang diberikan khusus untuk percakapan abstrak, dan sekarang saatnya bekerja. Oleh karena itu, bahkan lisan biasa "mari kita langsung ke titik" sudah cukup bagi semua orang untuk kembali ke agenda bisnis. Dengan menghentikan gangguan dalam proses
pengerjaan tugas, kami
mengatur tim untuk bekerja .
Kami mencoba mengendalikan waktu laporan masing-masing insinyur. Terkadang untuk menyelami rinciannya, kita perlu cerita panjang dan mendetail tentang tugas itu. Namun, dalam kebanyakan kasus, kami
berusaha untuk tidak memperpanjang reli .
Demonstrasi yang efektif - peluru perak?
Berkat persiapan untuk reli atas dasar kesamaan pendapat dari pemimpin tim dan manajer dan karakteristik budaya kami dari reli, kami benar-benar membuatnya efektif. Tetapi apakah Anda berhasil menutup 80% dari semua kompetensi? Tidak juga.
Kami melakukan pekerjaan dengan baik dengan harapan penyiaran, tetapi masih ada masalah dengan pesan obrolan yang tidak informatif dalam komunikasi, dan ada gangguan dalam perencanaan yang mencegah kami melakukan tugas yang dijadwalkan secara efektif.
Ya, tetapi pesan obrolan yang tidak informatif juga merupakan gangguan. Dan kita perlu menemukan mekanisme yang akan membantu kita secara efisien menangani semua jenis interupsi.
Gangguan Pertempuran
Kami berpikir, bagaimana jika kami memiliki orang yang terpisah yang akan "menutupi" dengan diri kami sendiri sebuah tim yang mengerjakan tugas yang direncanakan dari aliran interupsi?
Idenya bukanlah hal baru dan umumnya baik, tetapi siapa sebenarnya yang akan melakukannya? Kami mempertimbangkan dua opsi: menemukan dan merekrut layanan seperti itu atau menggunakan insinyur yang ada. Pencarian untuk orang-orang baru membutuhkan waktu dan sumber daya keuangan, dan insinyur yang ada sudah "diuji dalam pertempuran" dan tenggelam dalam semua proyek tim. Karena itu, opsi untuk mempekerjakan orang baru ditolak.
Masih harus memutuskan pertanyaan tentang bagaimana mengatur layanan seperti itu dari para insinyur saat ini. Di sini solusinya ada di permukaan: mereka hanya menerapkan tugas pada jadwal, dengan rotasi insinyur dari tim. Kami menjaga jadwal tugas di Kalender Google, ditambah mengatur pemberitahuan di Slack tentang siapa yang bertugas hari ini.
Tampaknya semuanya akan baik-baik saja sekarang? Hore? Tidak, sebenarnya masalahnya tetap ada. Ingat, sedikit sebelumnya kami mengatakan bahwa di Slack saja kami mendapatkan hampir 2.000 hit sebulan, yaitu sekitar 16 hit sehari untuk setiap tim. Namun selain Slack, petugas harus memproses pesan dari sistem pemantauan, dan pada hari itu:
- 112 - dari Prometheus;
- 16 - dari okmeter;
- 25 - dari sistem pemantauan blackbox eksternal;
- 14 - dari berbagai skrip khusus;
- dan bahkan 2 panggilan telepon dari pelanggan.
Ini 198 gangguan setiap hari dari berbagai sumber! Tetapi faktanya, ada lebih banyak lagi sumber:
- Hampir setiap klien memiliki Prometheus;
- dan Okmeter diinstal pada setiap klien;
- tetapi skrip khusus, bahkan satu klien dapat memiliki sebanyak yang Anda inginkan ...
Agar setiap insinyur dari tim dapat mengatasi hal ini tanpa sihir dan kekuatan super, kami mengumpulkan peringatan dari semua sumber interupsi di satu tempat. Kami menyebut alat ini Madison, dan setiap pesan di dalamnya adalah Insiden.
Tetapi Madison hanya mengumpulkan insiden dan menyimpan banyak uang tentang mereka. Tetapi kita perlu memahami insiden apa yang harus diambil pertama, yaitu melakukan triase, memiliki urutan pemrosesan dan eskalasi yang jelas, sehingga dapat dengan mudah dilakukan dalam situasi yang penuh tekanan.
Kami juga menciptakan instrumen seperti itu - menyebutnya Polk:
Polk adalah tempat kerja insinyur tugas. Hal ini memungkinkan petugas untuk fokus hanya pada insiden, tanpa terganggu oleh tugas yang direncanakan, menerima insiden dari semua sumber di satu tempat, membantu dengan menentukan kekritisan insiden menurut Severity yang telah ditentukan, memiliki serangkaian status yang ditentukan dengan jelas dan algoritma pemrosesan yang menentukan pergerakan status ini.
Fitur teknis dan budaya mengobrol
Luar biasa: sekarang petugas, yang dilengkapi dengan alat yang sangat kuat, benar-benar menutup tim dari gangguan. Tetapi bahkan dengan alat seperti itu arloji itu melelahkan, dan interupsi yang tidak berguna hanya menambah bahan bakar ke api.
Untuk mengatasi gangguan obrolan yang tidak berguna, kita dapat menggunakan satu set kecil alat teknis, tetapi solusi utama untuk masalah ini pasti terletak pada bidang budaya.
Dari sudut pandang teknis, di Slack kami berbagi informasi tentang proyek, membuat saluran terpisah untuk komunikasi dengan perwakilan pelanggan, dan untuk setiap proyek, saluran untuk insinyur untuk membahas pekerjaan di dalamnya. Kami juga menulis bot
@flant , ketika diakses oleh Polk, sebuah insiden secara otomatis dibuat yang diproses oleh petugas jaga.
Selain itu, kami merekomendasikan klien untuk menggunakan
@flant , dan
@channel (acara yang memberi tahu semua anggota saluran) dan
@here (acara yang memberi tahu semua anggota saluran secara online) untuk digunakan hanya dalam kasus-kasus langka dan luar biasa ketika Anda benar-benar tidak dapat melakukannya tanpa mereka (misalnya, ketika bot
@flant tidak tersedia).
Pada hari pertama kerja sama kami dengan klien, kami memposting instruksi terperinci tentang interaksi di saluran. Dan pada pertemuan reguler pertama, kita pasti akan membahas interaksi, termasuk perbedaan antara
@channel ,
@here dan
@flant .
Secara khusus, kami fokus pada fakta bahwa panggilan ke
@flant untuk kami, pertama-tama, adalah tindakan dengan reaksi wajib, dan
@channel dan
@here untuk sebagian besar tim hanyalah gangguan, yang juga tanpa alamat dan dapat diabaikan sambil mengalihkan perhatian seluruh tim dari menyelesaikan tugas yang direncanakan, termasuk untuk proyek ini.
Tetapi kolega baru datang ke obrolan dari pelanggan yang tidak mengetahui bot. Yang lain hanya lupa. Jika ini terjadi, kita dengan lembut mengingat keberadaannya.
Untuk komunikasi antara insinyur, kami menggunakan aturan yang sama untuk
@channeldan
@here : jangan menggunakannya kecuali benar-benar diperlukan. Namun, kami bersikeras untuk mematuhi aturan "Jangan hanya mengatakan" halo "dalam obrolan - segera merumuskan pemikiran". Aturan ini wajib dibaca untuk semua pemula. Mereka yang lupa akan diingatkan tentang hal ini - jika perlu, dikerahkan.
Total: dengan diperkenalkannya perubahan dan koreksi masalah komunikasi dalam obrolan, kami mengatasi sebagian besar gangguan yang tidak berguna dan dengan pengaruh gangguan pada kinerja tugas yang direncanakan.
Penundaan dan pemblokiran
Kami memeriksa bagaimana indikator kami membaik setelah itu: memang, mereka menjadi jelas lebih baik, tetapi masih ada masalah dalam perencanaan.
Ketika reli tim berakhir, saatnya untuk bekerja. Namun seringkali, insinyur, terutama yang bekerja dari jarak jauh, cenderung menunda-nunda. Atau, selama bekerja, mengalami masalah dan berjalan berputar-putar dalam upaya untuk menyelesaikannya.
Mari kita coba untuk menunda-nunda. Bagaimana cara mengatasinya? Ada terlalu banyak tugas di Redmine (pelacak tugas kami) - Anda perlu fokus pada yang akan bekerja hari ini. Dan bahkan di antara mereka, Anda perlu memahami tugas apa yang harus dilakukan terlebih dahulu, yaitu menentukan prioritas. Dan idealnya, jika Anda secara kasar merencanakan waktu yang siap kami habiskan untuk setiap tugas ...
Kami menciptakan alat yang membantu menyelesaikan semua ini, dan menamainya Ford:
Di sinilah insinyur menerima tugas untuk hari kerja dalam bentuk kartu yang diatur dalam urutan prioritas. Untuk semua tugas yang direncanakan, kami meletakkan perkiraan waktu yang harus dipatuhi insinyur saat menyelesaikannya. Insinyur memperhitungkan waktu yang dihabiskannya untuk menyelesaikan masalah. Dan jika waktunya hampir sama, tetapi masalahnya tidak terpecahkan, ini adalah penanda bahwa insinyur telah menemui jalan buntu.
Apa yang bisa dilakukan dengan ini? Selain prioritas di mana kartu berada,
kami juga memperkenalkan kategori prioritas, menyorotinya dengan warna:
- Kotak abu-abu digunakan untuk tugas biasa dan terjadwal;
- Bidang hijau - untuk tugas yang harus dimulai pada hari ini hanya jika tugas di semua bidang lainnya selesai;
- Bidang kuning untuk tugas-tugas yang tiba-tiba terjadi tanpa direncanakan pada siang hari;
- Bidang merah - untuk tugas yang perlu diselesaikan sebelum akhir hari kerja saat ini.
Jika seorang insinyur diblokir oleh tugas di bidang abu-abu dan hijau, maka dia hanya harus memulai tugas berikutnya, dan membongkar kunci pada pertemuan tim berikutnya.
Tetapi jelas bahwa jika seorang insinyur diblokir oleh tugas-tugas di zona kuning atau merah, maka Anda tidak harus menunggu untuk pertemuan berikutnya: Anda perlu meminta bantuan dari tim di saluran yang sesuai untuk insinyur untuk berkomunikasi pada proyek di mana tugas ditetapkan. Dan, sesuai dengan budaya kita, insinyur tim atau pemimpin tim pasti akan datang untuk menyelamatkan.
Perlu disebutkan bahwa kemampuan Ford jauh lebih luas dan kami hanya menyentuh "ujung gunung es", yang dapat Anda terapkan menggunakan alat terbuka lainnya.
Ringkasan
Ternyata untuk mengatasi penundaan dan pemblokiran, kami menggunakan Ford sebagai solusi teknis dan aturan sederhana dalam budaya tim.
Apakah alat ini membantu kami? Ya! Tetapi untuk beberapa alasan, bukan 100%?
Faktanya adalah bahwa dunia sedang berubah dan bergerak maju. Dan kami juga berubah dalam kondisi ini, berjuang untuk yang ideal, tetapi, seperti yang Anda tahu, itu tidak mungkin tercapai.
Tentang mencapai cita-cita dan peran manajer
Semua hal besar yang umat manusia telah ciptakan selama seluruh periode keberadaannya telah dilakukan oleh tim profesional yang memiliki manajer keren.
Kami, Flant, juga merupakan tim profesional. Dan akan keren jika ada lebih banyak manajer keren di tim kami. Datang kepada kami untuk bekerja dan membantu membuat proses kami lebih baik:
Video dan slide
Video dari kinerja (~ 38 menit):
Penyajian laporan:
PS
Baca juga di blog kami: