تيم ليستر - مؤلف مشارك للكتب

• "العامل البشري. المشاريع والفرق الناجحة" (الكتاب الأصلي يسمى "Peopleware")
• "رقصة الفالس مع الدببة: إدارة المخاطر في مشاريع البرمجيات"
• "مجنون بالأدرينالين وزومبي بالأنماط. "أنماط سلوك فرق المشروع"

كل هذه الكتب كلاسيكية في مجالها وتم كتابتها بالتعاون مع زملائها نقابة الأنظمة الأطلسية. في روسيا، زملائه الأكثر شهرة - توم دي ماركو и بيتر هروشكاالذي كتب أيضًا العديد من الأعمال الشهيرة.

يتمتع تيم بخبرة 40 عامًا في تطوير البرمجيات؛ في عام 1975 (لم يولد أي من الذين كتبوا هذا المقال هذا العام)، كان تيم بالفعل نائب الرئيس التنفيذي لشركة Yourdon Inc. وهو الآن يقضي وقته في الاستشارة والتدريس والكتابة، مع زيارات عرضية مع التقارير المؤتمرات حول العالم.

لقد أجرينا مقابلة مع تيم ليستر خصيصًا لصحيفة حبر. سيفتتح مؤتمر DevOops 2019، ولدينا الكثير من الأسئلة حول الكتب والمزيد. أجرى المقابلة ميخائيل دروزينين وأوليج شيروخين من لجنة برنامج المؤتمر.

مايكل: هل يمكنك قول بضع كلمات عما تفعله الآن؟

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

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

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

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

مايكل: أي أنك تطلق المشاريع، وتقوم بنوع من الانطلاقة وتتأكد من أن القضبان تسير في الاتجاه الصحيح؟

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

19 عاما من المرونة

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

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

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

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

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

أوليغ: لقد ذكرت بيان Agile. هل نحتاج إلى تحديثها أو مراجعتها بطريقة أو بأخرى مع مراعاة الفهم الحديث للقضية؟

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

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

أدوات الناس: بعد 30 عامًا

أوليغ: هل كانت Peopleware ثورة مثل البيان؟

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

على الرغم من حقيقة أن تيم ألقى عددًا كبيرًا من المحادثات، إلا أنه تم نشر عدد قليل جدًا منها على موقع يوتيوب. يمكنك الاطلاع على تقرير "عودة البرامج الشعبية" من عام 2007. الجودة، بطبيعة الحال، يترك الكثير مما هو مرغوب فيه.

مايكل: هل تغير أي شيء خلال الثلاثين عامًا الماضية منذ نشر الكتاب؟

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

نحن جميعًا نعيش في DevOps

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

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

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

مايكل: الفكرة الكاملة لـdevops هي تقديم تطورات ذات معنى في أقرب وقت ممكن. أرى أن العالم بدأ يتسارع أكثر فأكثر. كيفية التكيف مع مثل هذه التسارع؟ قبل عشر سنوات لم يكن هذا موجودا!

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

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

الأنماط والأنماط المضادة

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

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

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

مايكل: في الواقع، كم مرة سمعنا عن الرصاصة الفضية التالية؟

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

مايكل: نعم "سؤال الحياة والكون وكل شيء" الرئيسي: هل هذه التكنولوجيا أو النهج مناسب لحالتك أم لا؟

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

"مهندس التطوير" الأسطوري

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

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

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

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

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

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

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

""خبراء في كل شيء""

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

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

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

المخاطر وعدم اليقين

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

أوليغ: التحرك بسرعة وكسر الأشياء!

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

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

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

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

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

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

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

التفكير الهندسي للكبار

مايكل: المثال مع الأطفال جيد. إذا كنت مهندسا عاديا، فأنا سعيد بأن أكون طفلا. ولكن كيف يمكنك التحرك نحو المزيد من تفكير البالغين؟

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

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

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

أوليغ: حياتك هي مشروعك الذي تديره.

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

كيفية الدخول في إدارة المخاطر

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

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

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

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

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

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

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

سعر الاتصالات

أوليغ: أليس توظيف هؤلاء الموظفين المنتهية ولايتهم أكثر تكلفة لأسباب مختلفة؟ ففي نهاية المطاف، فهم يتحدثون باستمرار بدلاً من العمل!

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

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

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

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

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

مايكل: اذهب واكتب بعض التعليمات البرمجية!

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

أوليغ: ميشا، أنت تفكر في شيء ما.

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

الحياة بدون رواتب

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

أوليغ: بالمناسبة، في كتابك لديك مجموعة من الملاحظات حول ما هو جيد وما هو سيء. هل تستخدم أيًا منها بنفسك؟ نسبيًا، لديك الآن شركة، وهي شركة منظمة بطريقة غير تقليدية للغاية...

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

أفضل نصيحة

مايكل: بالعودة إلى "أفضل نصيحة"، هل هناك أي شيء تقوله لعملائك مرارًا وتكرارًا؟ هناك فكرة حول 80/20، وربما تتكرر بعض النصائح في كثير من الأحيان.

تيم: اعتقدت ذات مرة أنك إذا كتبت كتابًا مثل Waltzing with Bears، فإنه سيغير مسار التاريخ وسيتوقف الناس، ولكن... حسنًا، انظر، غالبًا ما تتظاهر الشركات بأن كل شيء على ما يرام معهم. بمجرد أن يحدث شيء سيء، فإنه يشكل صدمة ومفاجأة بالنسبة لهم. "انظر، لقد اختبرنا النظام، ولم يجتاز أي اختبارات للنظام، وهذه ثلاثة أشهر أخرى من العمل غير المجدول، كيف يمكن أن يحدث هذا؟ من يعرف؟ ما الخطأ الذي يمكن أن يحدث؟ على محمل الجد، هل تصدق هذا؟

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

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

ممارسة إدارة المخاطر!

مايكل: في رأيك، كم عدد المنظمات التي تعمل في مجال إدارة المخاطر؟

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

مايكل: ومع ذلك، كم عدد هذه الشركات التي تشارك في إدارة المخاطر، خمسة بالمائة؟

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

نعم، كثيرا ما أسمع عبارة "سوف نحل المشاكل عند ظهورها". بالتأكيد سوف نفعل؟ فهل سنقرر حقا؟

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

مايكل: نعم، لقد حدث لي أنه عندما تنشأ المخاطر، يتم ببساطة إعادة تعريف المشروع. لطيف، بينغو، تم حل المشكلة، لا تقلق بعد الآن!

تيم: دعونا نضغط على زر إعادة الضبط! لا، لا يعمل بهذه الطريقة.

الكلمة الرئيسية في DevOops 2019

مايكل: نأتي إلى السؤال الأخير في هذه المقابلة. أنت قادم إلى DevOops القادم بكلمة رئيسية، هل يمكنك رفع ستار السرية عما ستقوله؟

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

مايكل: أنا أيضًا أعمل في مجال الاستشارات منذ سنوات وأفهم جيدًا ما تتحدث عنه.

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

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

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

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

المصدر: www.habr.com