كيف تساعد الاستراتيجيات الصينية في العمل

غالبًا ما يشبه عملنا اليومي سلسلة من المواجهات. نحن "نقاتل" مع العملاء والفرق الأخرى ، مع المختبرين والزملاء والإدارات داخل الشركة تتنافس مع بعضها البعض. نحن نكافح من أجل الرواتب ونتخذ القرارات الفنية المريحة والمواعيد النهائية وآلاف الأشياء الأخرى. في هذه السلسلة من النزاعات ، قائد الفريق هو قائد وحدة قتالية صغيرة ، فريق. إنه يعرف نقاط القوة والضعف لكل "عادي" ، وينسق وينظم عملهم من أجل تحقيق الأهداف بأقل خسائر.

إذا نظرت إلى عمل قائد الفريق من وجهة النظر هذه ، فإن التخطيط الاستراتيجي والعمل الموضعي داخل الفريق وخارجه أمر مهم. في الوقت نفسه ، لا تنس التكتيكات. بشكل غير متوقع ، تساعد المعرفة بالسياقات الصينية القديمة على التخطيط لاستراتيجية والاستجابة التكتيكية.



أليكسي زولوتيك ( زلوتية ) - قائد الفريق في إنفوبيب. يستخدم أليكسي في عمله قواعد الحرب في الصين القديمة. من مقال يستند إلى تقريره عن Saint TeamLead 2019 ، سوف تتعلم كيف تساعد الحيل في حياة قائد الفريق: كيفية صنع السلام مع أحد المطورين داخل الفريق ، وكيفية اكتساب المصداقية بين الزملاء ، وكيفية الدفاع عن رأيك ، ولماذا التضحية برقوق ، وتوبيخ السنط ، والتظاهر بالجنون على العشب.

الحيل

الحيلة هي سلسلة محسوبة من الإجراءات التي تهدف إلى حل مشكلة معينة.

هذه هي القواعد والتحركات الاستراتيجية والتكتيكات لتحقيق أهداف مختلفة. تم استخدام طوابير في القتال. في الأساس ، تم وصفها في كتب "ستة وثلاثون حيلة" و "فن الحرب" ، والتي تنسب إلى صن تزو. هذا الاستراتيجي والمفكر الصيني عاش حوالي 500 قبل الميلاد. لكن مفهوم "الحيلة" ظل يعيش في ثقافة الصين منذ 3000 عام ، لذلك يمكننا أن نفترض أن مؤلف المقالات هو الشعب الصيني بأكمله.

لكن السؤال الذي يطرح نفسه - هل نحن Timlids ، أين نشأت الحرب؟ نحن لا نقاتل ولا نحارب أي شخص ولا نلتقط ، لماذا نحتاج إلى طبقات؟

نظام الضوابط والتوازنات

في كتاب Ray Dalio "Principles" ، هناك فكرة مهمة: أي شركة أو فريق هو نظام من الضوابط والتوازنات. والشركة هي الصراعات والمواجهات المجمدة.

سأشرح مع مثال. شركة "الخلاصة" لها قسمان: المختبرين (QA) والمطورين. هدف المطورين هو الوصول إلى الإنتاج في أسرع وقت ممكن وإطلاق المنتج في الوقت المحدد ، لأن لديهم KPI لهذا الغرض. للمختبرين أولويات مختلفة: من المهم بالنسبة لهم العثور على أكبر عدد ممكن من الأخطاء ، لأن لديهم KPI للجودة. يدخل قسمان تجريديان في شركة مجردة في نزاعات مجردة ومواجهات مع بعضها البعض.

يوجد موقف مماثل بين الموارد البشرية وأصحاب الشركة. ببساطة ، هدف الموارد البشرية هو توظيف أكبر عدد ممكن من الناس. لكن لهذا عليك تضخيم الميزانية ، لأنه الآن الناس في تكنولوجيا المعلومات غاليون. أصحاب الشركات تريد توظيف الناس أرخص. مرة أخرى ، والصراع والمواجهة.

تحدث النزاعات في الشركات بين مختلف الإدارات والموظفين والفرق والإدارة والمرؤوسين بشكل مستمر في شكل تجمعات وحوارات ومناقشات. يمكن اعتبارهم نوعًا من المواجهة العسكرية ، وستكون المشورة بشأن شن الحرب مفيدة فقط.

دعونا نلقي نظرة على تلك الطبقات التي يمكنها استخدام الجداول الزمنية. تتم كتابة الطبقات في اللغة الشعرية ، وهذه ليست مصادفة ، حيث يسهل تذكرها.

الجنرال بطيء لأنه يفكر في النصر

من الضروري الاستعداد لكل تجمع. يظهر Captain Evidence هنا ، لكن لا ، انتظر ...

"ليس الشخص الذي يعرف كيف يلعب بكل القواعد يفوز. الفائز هو الشخص الذي يعرف كيفية التخلي عن جميع القواعد في الوقت المناسب ، وفرض قواعده على اللعبة غير المعروفة للعدو ، وعند الضرورة ، التخلي عنها. " هذا هو تفسير للحيلة من كتاب واحد عنها. إذا تم تطبيقه على تكنولوجيا المعلومات ، فيقول أن الشخص الذي يضع القواعد في بداية المسيرة فيها يفوز .

في عام 2017 ، تحدثت في مؤتمر. كان أحد أهداف عرضي التقديمي "بيع" لغة Dart للجمهور. هذا هو YP غريب إلى حد ما ، وليس التيار الرئيسي ، لكنني أحبه كثيرا. من الواضح أن الجمهور في المؤتمر غير جاهز له ، لذلك توصلت إلى "خدعة عسكرية".

دعوت "هيئة محلفين" من ثلاثة أشخاص إلى المسرح للتعبير عن خصائص معينة من JavaScript و TypeScript و Dart ومقارنة هذه اللغات الثلاث. لكنني شخصياً حددت شكل المسابقة وتوصلت إلى القواعد. كرائدة والرئيسية على المسرح ، قلت:
- وفقًا لتقديراتي ، فإن كتابة TypeScript هي 5 نقاط من أصل 10 ، وفي JavaScript لا تكون على الإطلاق ، أما في Dart فهي 10 من أصل 10.

من ، إلى جانب Chuck Norris ، ما زال سيختار TypeScript باستخدام مثل هذه الوسيطات؟ هذا ليس منطقيا ، لا أحد يريد أن يكون "ليس مثل أي شخص آخر." لذلك ، لم تتح لهيئة المحلفين الفرصة لاختيار فائز بطريقة مختلفة عن التنسيق الذي طلبته. كما هو متوقع في هذه المعركة ، هزم دارت لأني أعددت.

وحده توقع عدو مرهق

حيلة كبيرة يتضح من قصتين.

"دعنا نعيد كتابة كل شيء على ..."

كقائد للفريق ، لدي حرية نسبية في اختيار التقنيات ، لذلك غالبًا ما يأتي إليّ زملائي في الفريق (لا أستخدم كلمة "المرؤوسين" ، وأعتقد أن هذا خطأ). عادة ما يقولون شيئا مثل هذا:
- دعونا رمي TypeScript وإعادة كتابة كل شيء على التدفق!

أو:
- هناك شيء رائع - GraphQL. قمت بتقديم تقرير عنها وأنت تقوم بحملتها. لننفذها!

خرجت من هذا الموقف بكل بساطة:
- أنا حقا أحب GraphQL. ولكن دعنا نكتب خطة تنفيذ لمدة ستة أشهر ، مع الأخذ في الاعتبار الخدمات العشرون التي قمنا بتنفيذها بالفعل ، ثم تقديم تقرير عنها؟

لدينا تنسيق عرض يوم الجمعة. من الغريب أن هذا يحدث يوم الأربعاء ، لأن تحميل الزملاء بشيء جديد يوم الجمعة ليس جيدًا جدًا.

إذا كان الشخص مسؤولاً ومتحمساً وتأكد من أنه على صواب ، فمن المرجح أنه سينهي المشروع. ولكن إذا أراد فقط التحدث والحجج ، فلن ينظر حتى في هذا الاتجاه: سيتعين عليه التواصل مع شخص ما ، والبحث ، وإعداد عرض تقديمي ، والعمل بالإضافة إلى ذلك.

لذلك أقتل عصفورين بحجر واحد:

• أنا لا أغلق شخصًا ، ثم لا أسمع في كل تجمع حول GraphQL كيف سيحل كل مشاكلنا وما إلى ذلك ؛
• إذا أكمل الشخص المشروع ، فسيصبح قائدًا جيدًا للفريق في المستقبل ، وسيكون لدينا شيء جديد ورائع.

"أنا كسول جدا في الكتابة ، هيا بصوت"

قال لي هذا الاختراق الحياة صديقا جيدا. تخيل أنك تتلقى طلب سحب وتحتاج إلى إجراء مراجعة ، والعثور على بعض الأخطاء. عليك أن تدرك أن جذر الشر في هذا الطلب يكمن عميقًا: لا يفهم المطور مطلقًا ما يفعله ، لذلك يتم كتابة كل شيء بشكل غير صحيح ، وتقوم بالإبلاغ عنه. المطور لا يوافق (متوقع) ، ويأتي إليك ويقول: "اسمع ، أنا كسول جدًا في الكتابة ، دعنا نناقشه هكذا".

لا تسوية لذلك! إذا جاء الناس للتحدث إليكم ، فإن "الحديث" مجاني. يمكنك قول ساعة ، ولا يكلفك شيء. لدينا جميع المراسلات باللغة الإنجليزية ، وعندما تضطر إلى الإجابة ، في بعض الأحيان يكون الإعادة أسرع من الذهاب إلى الترجمة من Google. هناك عدد أقل من النزاعات: الشخص متعب بالفعل ، فهو غير مهتم بالقتال.

التضحية برقوق لانقاذ الخوخ

هناك مواقف يمكنك فيها إعطاء شيء صغير مقابل الشيء الرئيسي. لذلك ، قبل البدء في المفاوضات ، من المهم أن نفهم ما هو مهم بالنسبة لنا وما هو ثانوي.

نأتي إلى المفاوضات مع موقف مستعد.

سكروم المخ

هناك رأيان شرطان في Infobip: يقول البعض أن Scrum و Agile رائعان ، بينما اقترح آخرون كتابة المزيد من الأكواد ودردشة أقل. في الاجتماعات ، يتم التعبير عن الموقف الثاني في حقيقة أن الشخص يأخذ جهاز كمبيوتر محمول معه ويصطدم به - لا يمكن الحصول على شيء منه.

في هذه الحالة ، نتواصل مع الموظف:
- دعونا نفعل ذلك بهذه الطريقة: قد لا تأتي إلى مسيرة Scrum على الإطلاق ، ولكن يجب أن تعرف النتائج. ولكن إذا كنت لا تزال تأتي ، فقم بإزالة الكمبيوتر المحمول والعمل معنا.

يفهم الشخص أنه إذا فاته الاجتماع ، فسيتعين عليه اللحاق بالركب ، ولن يعرف أحد رأيه. لقد ضحت بحضور موظف ، وهذا يضر بالفخر ، وفي النهاية يأتي على أي حال. تم حل المشكلة.

مشيرا إلى شجرة التوت ، تأنيب السنط

لدى Grigory Bakunov تقرير جيد اقترح فيه أن أي مطور في عملية إبداعية مميزة للأطفال من 5 إلى 7. ووفقًا له ، أي مطور من 5 إلى 7 سنوات (مشروطًا) ، وتحتاج إلى التحدث معه كطفل .

لديّ ابن ، عمره عام ونصف تقريبًا. قرأت كتباً متخصصة عن الأبوة ورعاية الأطفال. تعلمت في أحد الكتب كيفية "خداع" رجل صغير في تناول العصيدة: أخبر حكاية خرافية أن هناك معدة ، ويشعر بالسوء عندما لا يعطيه فمه عصيدة ، وكل هذا مثال على بعض الصبي .

كيفية تطبيقه على المطورين؟ في السابق ، عندما أردت تقديم تعليقات شخص ما ، قلت ذلك مباشرةً:
- أوليغ ، هنا وهنا أنت مخطئ. لجعل الأمور أفضل غدا ، افعل هذا وذاك.

في معظم الحالات ، يؤدي هذا إلى تقويض احترام الذات: فالشخص يعتذر ويوضح سبب صوابه أو لماذا لا يستطيع فعل ذلك بطريقة أخرى. الآن أذهب إلى الجانب الآخر:
- تخيل أنك قائد فريق ولديك مثل هذا الموقف. ماذا ستفعل؟

لقد وضعته في مكاني وأسأل عما سيفعله في هذه الحالة. فخر المطور أمر جيد ، وهو يعتاد على دور قائد الفريق ويبحث عن طرق لحل المشكلة.

نتظاهر بالجنون ، وحفظ عقلك

أدعي أن يكون أحمق بلدي المفضل اختراق الحياة. المبدأ بسيط: إذا كان لديك سؤال فني ، اسأل. لا أعرف عنك ، لكنني لست أذكى شخص في الفريق وأنا على دراية بذلك.

طرح الأسئلة أمر طبيعي.

في إحدى شركاتي السابقة ، عمل شخص في منصب نائب رئيس الهندسة (CTO). ظل يكرر:
"أنا لا أفهم الأشياء الفنية الخاصة بك ، وشرح ذلك باللغة الروسية."

أو:
- هذا سيؤدي إلى تشويش الكود. وما الذي يهددنا به هذا؟ لماذا؟ كيف؟

CTOs مثلي لديها 30 شخصا آخر. الطريقة الوحيدة لفهم ما يحدث هي أن تسأل مرارًا وتكرارًا.

عندما يجيب شخص على سؤالك "الغبي" بكلمات بسيطة ، فإنك تفهم أين توجد فجوات في منطقه. في هذا الوقت ، تطرح أسئلة توضيحية وتجد أين يحدث خطأ ما: التقليل من شأن الحجج والمشاكل المحتملة التي يمكن أن تطلق النار بعد ذلك. لذلك لا تخف من طرح أسئلة غبية.

إذا كنت تعتقد أنك بهذه الطريقة تفقد "سلطتك" و "وجهك المهني" ، فتذكر ريتشارد فاينمان . هذا حائز على جائزة نوبل ، وهو مؤلف مشارك في نظرية الديناميكا الكهربائية الكمية ، وهو أحد مطوري القنبلة الذرية ، وهو فنان ومكسر خزائن. في الستينيات ، ألقى فاينمان محاضراته في معهد كاليفورنيا للتكنولوجيا ، والتي صدرت لاحقًا في ثلاثة مجلدات من محاضرات فينمان في الفيزياء. حتى الآن ، هذا هو أحد التفسيرات الأكثر شيوعًا ومفهومة للظواهر الفيزيائية من الميكانيكا إلى فيزياء الكم.

وفقًا للتجربة ، يبدو أن هذا شخص محترم وجاد. ولكن على العكس من ذلك ، لم يكن خائفًا من أن يبدو محرجًا. واحدة من ميزات Feynman هي عقل نابض بالحياة والسخرية الذاتية. لقد طرح باستمرار أسئلة غبية ، ولم يحاول أن يبدو "صلبًا" وسعى إلى شرح الأشياء المعقدة بكلمات بسيطة. أحد اقتباساته: "إذا كنت فيزيائيًا كموميًا ولا تستطيع أن تشرح باختصار لطفل في الخامسة من عمره ما تفعله ، فأنت مشعوذ".

إذا كان بإمكان الحائزين على جائزة نوبل أن يبدووا أغبياء ، فإنهم أكثر من ذلك.

إغراء السطح وإزالة السلالم

لقد واجهت مشكلة في الفريق: هناك ميزة كبيرة ستستغرق وقتًا غير محدد. يسألني المديرون باستمرار متى سيتم الانتهاء من هذه الميزة ، ولا يعرف المطورون "متى" لأنهم لا يستطيعون تحديد المتطلبات. في مرحلة ما ، قلت:

- توقف! ماذا تحتاج لفهم التوقيت؟
- هذا ، هذا وذاك.
- ثم سنعقد مسيرة في 1 أكتوبر. دعونا نفهم بحلول هذا الوقت ما إذا كنا في الوقت المناسب أم لا.
"لكن ماذا عن؟" ربما يبدأ الإعصار ، الحافلة لا تأتي ، شخص ما يمرض - كيف نأخذ ذلك في الاعتبار؟
- نعم ، وسوف تهاجم Godzilla ... فلنقم بتبسيط المهمة: قررنا أننا لن نجد أي شيء ، وإذا وجدنا ، فنحن فقط نعلم الإدارة بذلك. ولكن بحلول الأول من أكتوبر ، يجب أن يتم ذلك.

الأهم من ذلك ، سألت الجميع إذا كان يوافق على تاريخ 1 أكتوبر. إذا كنت لا أوافق ، فقد اقترحت الخروج بتاريخ مختلف ، مبررًا ذلك والقول حتى الأعلى. وصفت حيلة بإيجاز في عبارة واحدة.

يسلب طرق الهروب.

إذا كنت تريد التقاط شيء ما ، فليذهب أولاً

إعطاء الفرصة لحفظ الوجه

جئت مع فريق يؤدي إلى فريق المنشأة بالفعل. بطبيعة الحال ، فإن أول شيء قررت القيام به هو "بيع" سلطتي.

في أحد مراجعات الكود ، كانت لدي حجة كبيرة مع أحد مطوري البرامج حول العمارة. قررت أن أعرف من هو على حق ومن ليس كذلك: لقد طلبت من جميع قادة الصناعة رأيًا موضوعيًا حول الكود الذي كنا نتحدث عنه. أكد كل من يهمني التقييم أنني على صواب.

لقد وضعت كل هذه النتائج على "منافسي" على أمل أن يكون على علم بخطئه وأن يستقر كل شيء. ولكن كل شيء تحول بشكل مختلف. أدرك خصمي أنه فقد مصداقيته. الآن لا يهتم بالمنتج وعلى أي حال ، من هو الصحيح ومن غير المهم حفظ ماء الوجه. بعد ذلك ، التقى كل قراري برفض حاد. لم يفكر المطور في المشروع ، فكر في كيفية إظهار أنه أكثر ذكاءً. انتهى كل شيء بنقل مؤلم لشخص إلى فريق آخر (الفصل). كنت على حق ، لكنني لم أدع الشخص ينقذ وجهه. ما زلت أشعر بالأسف لذلك.

امنح العدو الفرصة للخروج من الوضع بكرامة.

حتى لو كنت محقًا تمامًا - يجب على الخصم الحفاظ على كرامته. إذا كنت خطوة على الكالس ، سوف تكسب العدو.

الموقع مثل الطماطم

سمعت مثالا مضحكا آخر في محاضرة لودفيج بيسترونوفسكي ، مدير فني في استوديو ليبيديف. تخيل مصممًا يعرض إنشاء موقع ويب مثل الطماطم. ليس من الواضح كيف سيبدو هذا ، والأهم من ذلك لماذا؟ لكن المصمم يعجبه ويروج لـ "فكرته" فقط لأنه جاء بها.

بالطبع ، لا ينبغي للمرء أن يتفق مع هذه الأفكار. عودة الرجل إلى الأرض:
- أنا أفهم أنك مصمم رائع ، لكن هذه الفكرة ليست لك ، فهي لا تعمل الآن.

هذا هو نفس مبدأ حفظ الوجه ، ولكن في حالة قيام شخص ما بربط قراره بنفسه. هذا يحتاج أيضا إلى أن تؤخذ في الاعتبار والعمل معها.

لسوء الحظ ، يحدث هذا ليس فقط في بيئة إبداعية. لقد رأيت حالات ارتبط فيها المطورون بـ GraphQL أو MongoDB ، على سبيل المثال. حاول فصل الأفكار عن الشخص ، لقد أصبت بالحروق.

فاز على العشب لتخويف الثعبان

عندما تتلقى مشروعًا كبيرًا طويل الأجل ، فإنني أنصحك بتنفيذ مشروع MVP: وهو مشروع بسيط يحتوي على جميع الرقائق والمشاكل والأخطاء التي تساعد على تقييم الجدول الزمني بشكل كاف. إذا كان MVP البسيط يبني مشروطًا لمدة أسبوعين ، فمن الواضح ما سيحدث بعد ذلك.

هذه نصيحة جيدة وهي تعمل في كل مكان. الآن أنا أعارض نهجًا مختلفًا ، لقد حصلت بالفعل على هذا الكالس. اسمح للمطور بعمل MVP بشكل أفضل وشيء محدد في الكود أكثر مما سيعمل على مشروع كبير بطريقة أو بأخرى بطريقة مختلفة.

الهروب هو أفضل حيلة

تجنب الصراع ليس خسارة.

كما قال سون تزو ، هناك ثلاثة خيارات.

• تقديم حل وسط. هذا قرار صعب المنال: الفوز والخسارة.
• تعترف بالهزيمة.
• للمغادرة. لكن هذه ليست خسارة ، لكنها فرصة للعودة وتصحيحها.

لا تتدخل في الصراع! من الأفضل عدم القتال ، ولكن العيش بسلام.

"إن القتال مائة مرة والفوز بمئات المرات ليس أفضل الأفضل. أفضل ما في الأمر هو احتلال جيش أجنبي دون قتال ".

الشمس تزو

كل ما نوقش في المقال إلى آخر حيلة هو التلاعب. لا يريد الجميع الاتصال بهم ، ولكن عليك أن تعرفهم لسببين: في بعض الأحيان لا يزال يتعين عليك استخدام التلاعب في عملك ، لسوء الحظ ، ومن الأفضل دائمًا أن تعرف متى تستخدم بدلاً من أن تعرف.

حاول التقليل من الصراع ولا تسمح للتلاعب بنفسك.

في هذه الملاحظة الإيجابية ، أذكرك بأنه يمكن تقديم طلب لتقديم تقرير إلى المؤتمر القادم لقادة الفرق قبل نهاية الأسبوع ، أي 22 ديسمبر. وبعد أسبوع ، سنخرج من بين المئات (أظن أنه بحلول ذلك الوقت سيكون هناك المزيد) من التطبيقات ، نختار المتحدثين في February TeamLead Conf بحيث لم تعد تشك في الحاجة إلى شراء تذكرة للمؤتمر.