Bagaimana strategi Cina membantu dalam pekerjaan

Pekerjaan kita sehari-hari sering seperti serangkaian konfrontasi. Kami “bertarung” dengan pelanggan dan tim lain, dengan penguji dan kolega, dan departemen dalam perusahaan bersaing satu sama lain. Kami berjuang untuk gaji, membuat keputusan teknis yang mudah, tenggat waktu, dan ribuan hal lainnya. Dalam rangkaian konflik ini, pemimpin tim adalah pemimpin unit tempur kecil, tim. Dia tahu kekuatan dan kelemahan masing-masing "biasa", mengoordinasikan dan mengatur pekerjaan mereka untuk mencapai tujuan dengan kerugian minimal.

Jika Anda melihat pekerjaan pemimpin tim dari sudut pandang ini, maka perencanaan strategis dan pekerjaan posisi di dalam tim dan seterusnya adalah penting. Pada saat yang sama, jangan lupakan taktik. Tanpa diduga, pengetahuan tentang strategi Tiongkok kuno membantu merencanakan strategi dan bereaksi secara taktis.



Alexey Zolotykh ( zolotyh ) - pemimpin tim di Infobip. Alexey menggunakan dalam karyanya aturan perang Cina kuno. Dari sebuah artikel berdasarkan laporannya pada Saint TeamLead 2019 , Anda akan belajar bagaimana strategi membantu dalam kehidupan seorang pemimpin tim: bagaimana berdamai dengan pengembang dalam sebuah tim, cara mendapatkan kredibilitas di antara kolega, cara mempertahankan pendapat Anda, mengapa mengorbankan prem, memarahi akasia, berpura-pura gila dan mengalahkan di atas rumput.

Stratagem

Siasat adalah urutan tindakan yang diperhitungkan yang ditujukan untuk memecahkan masalah tertentu.

Ini adalah aturan, langkah strategis, dan taktik untuk mencapai tujuan yang berbeda. Stratagem digunakan dalam permusuhan. Pada dasarnya, mereka dijelaskan dalam buku-buku "Tiga Puluh Enam Stratagem" dan "The Art of War", yang dikaitkan dengan Sun Tzu. Ahli strategi dan pemikir Cina ini hidup sekitar 500 SM. Tetapi konsep "siasat" telah hidup dalam budaya Cina selama 3.000 tahun, sehingga kita dapat berasumsi bahwa penulis risalah itu adalah seluruh rakyat Tiongkok.

Tetapi muncul pertanyaan - apakah kita Timlid, di mana perang terjadi? Kami tidak berkelahi, tidak berkelahi dengan siapa pun dan tidak menangkap, mengapa kami perlu siasat?

Sistem checks and balances

Dalam buku Ray Dalio "Prinsip" ada ide penting: perusahaan atau tim mana pun adalah sistem checks and balances. Perusahaan adalah konflik dan konfrontasi yang membeku.

Saya akan jelaskan dengan sebuah contoh. Perusahaan "Abstrak" memiliki dua departemen: penguji (QA) dan pengembang. Tujuan pengembang adalah untuk mendapatkan produksi secepat mungkin dan merilis produk tepat waktu, karena mereka memiliki KPI untuk ini. Penguji memiliki prioritas yang berbeda: penting bagi mereka untuk menemukan bug sebanyak mungkin, karena mereka memiliki KPI untuk kualitas. Dua departemen abstrak dalam perusahaan abstrak terus-menerus memasuki konflik dan konfrontasi abstrak satu sama lain.

Situasi serupa terjadi antara SDM dan pemilik perusahaan. Sederhananya, tujuan dari HR adalah untuk mempekerjakan orang sebanyak mungkin. Tetapi untuk ini, Anda harus menggembungkan anggaran, karena sekarang orang-orang di IT itu mahal. Pemilik perusahaan ingin mempekerjakan orang lebih murah. Sekali lagi, konflik dan konfrontasi.

Konflik di perusahaan antara berbagai departemen, karyawan, tim, manajemen, dan bawahan terjadi terus-menerus dalam bentuk aksi unjuk rasa, dialog, dan diskusi. Mereka dapat dianggap sebagai semacam konfrontasi militer, dan saran tentang berperang hanya akan berguna.

Mari kita lihat strategi-strategi yang dapat menggunakan timlids. Siasat ditulis dalam bahasa puitis, dan ini bukan kebetulan, karena mudah diingat.

Jenderal itu lambat karena dia mempertimbangkan kemenangan

Penting untuk mempersiapkan setiap reli. Kapten Evidence muncul di sini, tapi tidak, tunggu ...

“Bukan orang yang tahu cara bermain dengan semua aturan yang menang. Pemenangnya adalah orang yang tahu cara meninggalkan semua aturan pada waktu yang tepat, memaksakan aturannya sendiri pada permainan yang tidak diketahui musuh, dan jika perlu, mengabaikannya. ” Ini adalah penjelasan tentang siasat dari satu buku tentang mereka. Jika diterapkan pada IT, maka dikatakan bahwa orang yang menetapkan aturan di awal reli dan menang .

Pada 2017, saya berbicara di sebuah konferensi. Salah satu tujuan dari presentasi saya adalah untuk "menjual" bahasa Dart kepada audiens. Ini adalah YP yang agak aneh, bukan arus utama, tapi saya sangat mencintainya. Jelas bahwa hadirin di konferensi tidak siap untuknya, jadi saya datang dengan "trik militer".

Saya memanggil “juri” dari tiga orang ke atas panggung untuk menyuarakan karakteristik tertentu dari JavaScript, TypeScript dan Dart dan membandingkan ketiga bahasa ini. Tapi saya sendiri yang mengatur format kompetisi dan saya sendiri yang membuat aturan. Sebagai yang memimpin dan yang utama di atas panggung, saya berkata:
- Menurut perkiraan saya, dalam pengetikan TypeScript adalah 5 poin dari 10, dalam JavaScript tidak sama sekali, dan di Dart itu 10 dari 10.

Siapa, selain Chuck Norris, yang masih akan memilih TypeScript dengan argumen seperti itu? Ini tidak logis, tidak ada yang mau menjadi "tidak seperti orang lain." Karena itu, juri sama sekali tidak memiliki kesempatan untuk memilih pemenang secara berbeda dari pada format yang saya tanyakan. Bisa ditebak dalam "pertempuran" Dart ini dikalahkan karena saya siap.

Sendiri mengharapkan musuh yang lelah

Strategi hebat yang diilustrasikan oleh dua cerita.

"Ayo kita tulis ulang semuanya di ..."

Sebagai pemimpin tim, saya memiliki kebebasan relatif dalam memilih teknologi, sehingga rekan tim saya sering mendatangi saya (saya tidak menggunakan kata "bawahan", saya pikir ini salah). Biasanya mereka mengatakan sesuatu seperti ini:
- Mari kita lempar TypeScript dan tulis ulang semuanya di Flow!

Atau:
- Ada hal yang keren - GraphQL. Anda membuat laporan tentang dia dan Anda berkampanye untuknya. Mari kita implementasikan!

Saya keluar dari situasi ini dengan sangat sederhana:
- Saya sangat suka GraphQL. Tetapi mari Anda menulis rencana implementasi selama enam bulan, dengan mempertimbangkan dua lusin layanan yang telah kami terapkan, dan kemudian membuat laporan tentang hal itu?

Kami memiliki format presentasi hari Jumat. Anehnya, itu terjadi pada hari Rabu, karena memuat rekan dengan sesuatu yang baru pada hari Jumat tidak terlalu baik.

Jika seseorang bertanggung jawab, termotivasi dan yakin bahwa dia benar, maka kemungkinan besar dia akan menyelesaikan proyek. Tetapi jika dia hanya ingin berbicara dan berdebat, dia bahkan tidak akan melihat ke arah itu: dia harus berkomunikasi dengan seseorang, mencari, menyiapkan presentasi, dan bekerja tambahan.

Jadi saya membunuh dua burung dengan satu batu:

• Saya tidak membungkam seseorang dan kemudian saya tidak mendengar di setiap rapat umum tentang GraphQL bagaimana dia akan menyelesaikan semua masalah kita dan seterusnya;
• namun jika seseorang menyelesaikan proyek, dia akan menjadi pemimpin tim yang baik di masa depan, dan kita akan memiliki sesuatu yang baru dan keren.

"Aku terlalu malas untuk menulis, ayolah dengan suara"

Peretasan kehidupan ini memberi tahu saya teman yang baik. Bayangkan Anda menerima permintaan tarikan dan Anda perlu melakukan tinjauan, menemukan beberapa kesalahan. Anda mengerti bahwa dalam permintaan ini, akar kejahatan berada dalam-dalam: pengembang sama sekali tidak mengerti apa yang dia lakukan, jadi semuanya ditulis secara tidak benar, dan Anda melaporkannya. Pengembang tidak setuju (diharapkan), mendatangi Anda dan berkata: "Dengar, aku terlalu malas untuk menulis, mari kita bahas seperti itu".

Jangan puas dengan itu! Jika orang-orang datang untuk berbicara dengan Anda, maka "bicara" itu gratis. Anda dapat mengatakan satu jam, dan itu tidak dikenakan biaya apa pun. Kami memiliki semua korespondensi dalam bahasa Inggris, dan ketika Anda harus menjawab, kadang-kadang lebih cepat untuk diulang daripada pergi ke Google Terjemahan. Ada lebih sedikit perselisihan: orang itu sudah lelah, dia tidak tertarik berkelahi.

Korbankan prem untuk menyelamatkan buah persik

Ada situasi ketika Anda dapat memberikan sesuatu yang kecil sebagai imbalan untuk hal utama. Karena itu, sebelum memulai negosiasi, penting untuk memahami apa yang penting bagi kami dan apa yang sekunder.

Kami datang ke negosiasi dengan posisi siap.

Scrum otak

Ada dua pendapat bersyarat di Infobip: beberapa mengatakan bahwa Scrum dan Agile itu keren, sementara yang lain menyarankan untuk menulis lebih banyak kode dan lebih sedikit mengobrol. Pada pertemuan, posisi kedua dinyatakan dalam kenyataan bahwa seseorang membawa laptop dan menabraknya - tidak ada yang bisa diperoleh darinya.

Dalam hal ini, kami berkomunikasi dengan karyawan:
- Mari kita lakukan dengan cara ini: Anda mungkin tidak datang ke rapat umum Scrum, tetapi Anda harus tahu hasilnya. Tetapi jika Anda masih datang, lepaskan laptop dan bekerja bersama kami.

Seseorang mengerti bahwa jika dia melewatkan pertemuan, dia harus mengejar ketinggalan, dan tidak ada yang akan tahu pendapatnya. Saya mengorbankan kehadiran seorang karyawan, dan ini menyakitkan kesombongan, dan pada akhirnya dia tetap datang. Masalahnya teratasi.

Menunjuk ke pohon mulberry, tegur akasia

Grigory Bakunov memiliki laporan yang baik di mana ia menyarankan bahwa setiap pengembang dalam karakteristik proses kreatif anak-anak dari usia 5 hingga 7. Menurutnya, setiap pengembang yang berusia 5 hingga 7 tahun (bersyarat), dan Anda perlu berbicara dengannya seperti anak kecil. .

Saya memiliki seorang putra, dia hampir satu setengah tahun. Saya membaca buku-buku khusus tentang pengasuhan anak dan pengasuhan anak. Dalam salah satu buku saya belajar cara "menipu" seorang pria kecil untuk makan bubur: ceritakan dongeng bahwa ada perut, dan dia merasa tidak enak ketika mulutnya tidak memberinya bubur, dan ini semua adalah contoh dari seorang anak lelaki .

Bagaimana cara menerapkannya pada pengembang? Sebelumnya, ketika saya ingin memberikan umpan balik kepada seseorang, saya mengatakannya secara langsung:
- Oleg, di sini dan di sini kamu salah. Untuk membuat segalanya lebih baik besok, lakukan ini dan itu.

Dalam kebanyakan kasus, ini merusak harga diri: seseorang membuat alasan dan mengatakan mengapa dia benar atau mengapa dia tidak bisa melakukan sebaliknya. Sekarang saya pergi ke sisi lain:
- Bayangkan bahwa Anda adalah pemimpin tim dan Anda memiliki situasi seperti itu. Apa yang akan kamu lakukan

Saya menempatkannya di tempat saya dan bertanya apa yang akan dia lakukan dalam situasi ini. Kebanggaan pengembang dalam rangka, dan dia mulai terbiasa dengan peran pemimpin tim dan mencari cara untuk menyelesaikan masalah.

Berpura-pura menjadi gila, menjaga pikiran Anda

Berpura-pura menjadi orang bodoh. Prinsipnya sederhana: jika Anda memiliki pertanyaan teknis, tanyakan. Saya tidak tahu tentang Anda, tetapi saya bukan orang terpintar di tim dan saya sangat menyadari hal ini.

Mengajukan pertanyaan adalah hal biasa.

Di salah satu perusahaan saya sebelumnya, seseorang bekerja di posisi VP teknik (CTO) yang cukup tinggi. Dia terus mengulangi:
"Saya tidak mengerti hal-hal teknis Anda, jelaskan dalam bahasa Rusia."

Atau:
- Ini akan menyebabkan kebingungan kode. Dan dengan apa ini mengancam kita? Mengapa Bagaimana?

CTO seperti saya memiliki 30 orang lagi. Satu-satunya cara untuk memahami apa yang terjadi adalah bertanya berulang kali.

Ketika seseorang menjawab pertanyaan "bodoh" Anda dengan kata-kata sederhana, maka Anda memahami di mana ada celah dalam logikanya. Pada saat ini, Anda mengajukan pertanyaan klarifikasi dan menemukan di mana ada sesuatu yang salah: pernyataan di antara argumen, potensi masalah yang kemudian bisa dipecat. Jadi jangan takut untuk menanyakan pertanyaan bodoh.

Jika Anda berpikir bahwa dengan cara ini Anda kehilangan "otoritas" dan "wajah profesional" Anda, maka ingatlah Richard Feynman . Ini adalah pemenang Hadiah Nobel, penulis bersama teori kuantum elektrodinamika, salah satu pengembang bom atom, seorang seniman dan cracker brankas. Pada 1960-an, Feynman menyampaikan kuliahnya di Caltech, yang kemudian diterbitkan dalam tiga volume Feynman Lectures on Physics. Sampai sekarang, ini adalah salah satu penjelasan yang paling dimengerti dan populer dari fenomena fisik dari mekanika ke fisika kuantum.

Menurut regalia, tampaknya ini adalah orang yang terhormat dan serius. Tetapi sebaliknya, dia tidak takut untuk terlihat canggung. Salah satu fitur Feynman adalah pikiran yang hidup dan ironi diri. Dia terus-menerus mengajukan pertanyaan bodoh , tidak berusaha terlihat "solid" dan berusaha menjelaskan hal-hal rumit dengan kata-kata sederhana. Salah satu kutipannya: "Jika Anda seorang fisikawan kuantum dan tidak bisa menjelaskan secara singkat kepada anak lima tahun apa yang Anda lakukan, Anda adalah penipu."

Jika para penerima Nobel dapat terlihat bodoh, maka lebih dari itu.

Lure ke atap dan lepaskan tangga

Saya mengalami masalah di tim: ada fitur besar yang akan memakan waktu tidak terbatas. Manajer terus bertanya kepada saya kapan fitur akan selesai, dan pengembang tidak tahu "kapan" karena mereka tidak dapat menentukan persyaratan. Pada titik tertentu, saya berkata:

- Berhenti! Apa yang Anda butuhkan untuk memahami waktunya?
- Ini, ini dan itu.
- Lalu kita akan mengadakan rapat umum pada 1 Oktober. Mari kita pahami saat ini apakah kita tepat waktu atau tidak.
"Tapi bagaimana?" Mungkin badai dimulai, bus tidak datang, seseorang jatuh sakit - bagaimana kita memperhitungkannya?
"Ya, dan Godzilla akan menyerang ... Ayo sederhanakan tugasnya: kita memutuskan bahwa kita tidak akan menemukan apa-apa, dan jika kita menemukannya, kita hanya memberi tahu manajemen tentang hal itu." Tetapi pada 1 Oktober, ini harus dilakukan.

Yang paling penting, saya bertanya kepada semua orang apakah dia setuju dengan tanggal 1 Oktober. Jika saya tidak setuju, saya menyarankan datang dengan tanggal yang berbeda, membenarkannya dan mengatakan begitu ke atas. Strategi singkat dijelaskan dalam satu frasa.

Singkirkan rute pelarian.

Jika Anda ingin menangkap sesuatu, pertama-tama lepaskan

Beri kesempatan untuk menyelamatkan muka

Saya datang dengan pimpinan tim ke tim yang sudah mapan. Secara alami, hal pertama yang saya putuskan untuk lakukan adalah "menjual" otoritas saya.

Dalam salah satu ulasan kode, saya memiliki argumen besar dengan satu pengembang tentang arsitektur. Saya memutuskan untuk mencari tahu siapa yang benar dan siapa yang tidak: Saya meminta semua pemimpin industri untuk memberikan opini objektif tentang kode yang kami perdebatkan. Semua orang yang saya tertarik untuk mengevaluasi memastikan bahwa saya benar.

Saya memberikan semua hasil ini ke "saingan" saya dengan harapan bahwa dia akan menyadari kesalahannya dan bahwa semuanya akan beres. Tetapi semuanya ternyata berbeda. Lawan saya menyadari bahwa dia kehilangan kredibilitas. Sekarang dia tidak tertarik dengan produk itu dan lagi pula, siapa yang benar dan siapa yang tidak penting untuk menyelamatkan muka. Setelah itu, setiap keputusan saya bertemu dengan penolakan tajam. Pengembang tidak memikirkan proyek, dia berpikir tentang bagaimana menunjukkan bahwa dia lebih pintar. Itu semua berakhir dengan transfer menyakitkan dari seseorang ke tim lain (pemecatan). Saya benar, tetapi saya tidak membiarkan orang itu menyelamatkan wajahnya. Saya masih menyesalinya.

Berikan musuh kesempatan untuk keluar dari situasi dengan bermartabat.

Bahkan jika Anda sepenuhnya benar - lawan harus mempertahankan martabatnya. Jika Anda menginjak kalus, Anda akan mendapatkan musuh.

Situs seperti tomat

Saya mendengar contoh lucu lain dalam ceramah oleh Ludwig Bystronovsky, direktur seni Lebedev Studio. Bayangkan seorang desainer yang menawarkan untuk membuat situs web seperti tomat. Tidak jelas bagaimana ini akan terlihat, dan yang paling penting mengapa? Tetapi sang desainer menyukainya dan dia mempromosikan "idenya" hanya karena dia mengemukakannya.

Tentu saja, seseorang seharusnya tidak setuju dengan ide-ide seperti itu. Kembalikan manusia ke bumi:
- Saya mengerti bahwa Anda adalah perancang hebat, tetapi ide ini bukan Anda, itu tidak bekerja sekarang.

Ini adalah prinsip konservasi wajah yang sama, tetapi dalam kasus ketika seseorang mengaitkan keputusannya dengan dirinya sendiri. Ini juga perlu diperhitungkan dan bekerja dengannya.

Sayangnya, ini terjadi tidak hanya di lingkungan kreatif. Saya telah melihat kasus di mana para pengembang menghubungkan diri mereka dengan GraphQL atau dengan MongoDB, misalnya. Cobalah untuk memisahkan ide dari orang tersebut, saya sudah merasa terbakar karenanya.

Kocok rumput untuk menakuti ular

Ketika Anda menerima proyek jangka panjang yang besar, saya menyarankan Anda untuk mengimplementasikan MVP: proyek minimal dengan semua chip, masalah, bug, yang membantu menilai garis waktu secara memadai. Jika MVP sederhana dibangun bersyarat 2 minggu, maka jelas apa yang akan terjadi selanjutnya.

Ini adalah saran yang bagus dan bekerja di mana-mana. Sekarang saya menentang pendekatan yang berbeda, sudah pada ini saya sudah mendapat kalus. Biarkan pengembang lebih baik melakukan MVP dan sesuatu yang spesifik dengan kode daripada akan bekerja pada proyek besar yang entah bagaimana berbeda.

Melarikan diri adalah strategi terbaik

Menghindari konflik bukanlah kerugian.

Seperti kata Sun Tzu, ada tiga opsi.

• Berkompromi. Ini adalah keputusan yang setengah hati: menang dan kalah.
• Kenali kekalahan.
• Untuk pergi. Tapi ini bukan kerugian, tetapi kesempatan untuk kembali dan memperbaiki.

Jangan ikut campur dalam konflik! Lebih baik tidak bertarung, tapi hidup dengan damai.

“Bertarung seratus kali dan menang seratus kali bukanlah yang terbaik dari yang terbaik. Yang terbaik dari yang terbaik adalah menaklukkan tentara asing tanpa pertempuran. "

Sun tzu

Semua yang dibahas dalam artikel hingga siasat terakhir adalah manipulasi. Tidak semua orang ingin menghubungi mereka, tetapi Anda perlu mengetahuinya karena dua alasan: kadang-kadang Anda masih harus menggunakan manipulasi dalam pekerjaan Anda , dan itu selalu lebih baik untuk mengetahui kapan Anda sedang digunakan daripada tidak tahu.

Cobalah untuk mengurangi konflik dan jangan biarkan diri Anda dimanipulasi.

Pada catatan positif ini, saya mengingatkan Anda bahwa aplikasi untuk laporan ke konferensi berikutnya bagi para pemimpin tim dapat diajukan sebelum akhir minggu, yaitu, 22 Desember. Dan seminggu kemudian kita akan keluar dari ratusan (saya menduga bahwa pada saat itu akan ada lebih banyak lagi) dari aplikasi yang kita pilih speaker Februari TeamLead Conf sehingga Anda tidak lagi meragukan perlunya membeli tiket untuk konferensi.