البحث في الموقع

هذه الاكتشافات السيكولوجية الثّلاثة ستساعد فريقك على التّعاون في إيجاد نتائج مبتكرة. أوبر، وAirbnb، والسّيارات الكهربائية، والسيّارات ذاتيّة القيادة والحافلات الّتي تعبر فوق الزّحام، وكلّ شيء صنعه ستيف جوبز في آبل منذ الآيبود: هذه اختراعات زمننا الحاضر. وهي لم تأتِ فقط بالابتكار، بل بالقفزات النّوعية في التخيّل والتّعاون الإبداعي. إنّها من الاختراعات الّتي تدفعنا للتساؤل: كيف وصلوا إلى هناك؟ والأهم، كيف يمكن لفريق عملي الوصول إلى هناك؟ قد تبدو النّتائج النّهائية أنيقة ومرتّبة، لكن يمكنك المراهنة على أنّها لم تبدُ هكذا في أوّل الأمر. التّعاون أمر فوضوي، إذ يأتي الإبداع على نوبات مع بدايات خطأ كثيرة. فلا يوجد مسارٌ خطّي من المشكلة إلى حلّها، ولا صيغةُ سحريّةٌ للابتكار. لكنّ ثمّة طرقًا يمكن للقادة من خلالها تهيئةُ بيئةٍ تشجّعُ الفضول والاستعداد للمساهمة بأفكار جديدة وتقصّي إلى أين تقود. وفيما يلي ثلاث استراتيجيات رئيسية لتعزيز مزيد من التعاون الإبداعي في فريقك. خلق القيود في عام 1974، ترقّى توشيو أوكونو إلى مدير مصنع في الشّركة المحدودة Higashimaru Shoyu Co، وهو مركز تصنيع في اليابان أنتج أكثر من 200 منتج، منها العديد من أنواع صلصة الصويا. في ذلك الوقت، كانت الشركة تصارع للبقاء. وقد أدى وجود سوق مزدحم، وارتفاع التكاليف، وركود الأسعار إلى انخفاض في الأرباح سنةً تلو الأخرى. قبل أوكونو منصبه الجديد بشرط واحد: أن يتمتع بحرية بعث النّشاط في الشّركة. وقد كانت إحدى الطّرق المبتكرة التي استخدمها تسمى لعبة التّنصيف (The Hagen game). فعمِد إلى إزالة نصف أعضاء الفريق وتحدي الّذين أبقاهم لمحاولة القيام بعمل الفريق كاملاً. يقول أوكونو أنّ استبعاد نصف الفريق "يدفع بالمجموعة الباقية إلى إعادة التّفكير في كلّ مهمة يؤدونها والتّساؤل عمّا إذا كانت ضروريّة." بدلاً من إيجاد طرق صغيرة لزيادة الفعالية زيادةً هامشيّةً، حدّد أعضاء الفريق الباقون طرقًا أساسية لإعادة تقييم سير عملهم. يقول أوكونو: "لقد جرّبت قوّة هذا النهج شخصيًا، إذ استمعتُ إلى العمّال وهم يمحّصون عملهم ويخرجون بحلول فريدة قلّلت عنهم عبء العمل. وقد أسميتُها لعبةً لأنّني أردتُ لهم الاستمتاع بالعملية الإبداعية. وبهذا برهنّا أنّ بإمكان النّاس أن يصبحوا أكثر إبداعًا حينما يُحصرون في زاوية ضيّقة. وعلى نفس القدر من الأهميّة، أثبتنا أنّ الإبداع يمكن أن يكون ممتعًا." في النهاية، توصّل الفريق إلى نظامٍ جديدٍ حافظ على سير العمل بسلاسة مع 16 عاملاً فقط من أصل 25 من أعضاء الفريق. ما سمح لأوكونو بعد ذلك بإعادة تعيين أعضاء الفريق التسعة الإضافيين إلى في وظائف أخرى الشركة. وهكذا فالضّغط النّاتج عن إزالة نصف الفريق مكّن الموظفين من التفكير بإبداعٍ أكبر في مهامّهم. لماذا كانت لعبة التّنصيف فعّالة جدًا في تعزيز العمل الجماعي الإبداعي؟ قد تلقي الضّوء على المسألة مراجعة ستّة دراسات متفرّقة نُشرت سنة 2011 في مجلّة الشّخصية وعلم النّفس الاجتماعي في إحدى الدراسات، طُلب من المشاركين التنقل في متاهةٍ، أين وُضع لنصف المشاركين عائق أثناء التنقل في المتاهة. أمّا النّصف الآخر فسُمح له بإكمالها دون مواجهة العائق. ثمّ طُلبَ منهم جميعًا حلّ مجموعةٍ من الجناسات التّصحيفية، فجاءت المجموعة التي تغلّبت على العقبة بإجابات أكثر إبداعًا، على الرّغم من أن المهمّة لم تكن مرتبطةً بالتنقل في المتاهة. افترض الباحثون أنّ الألى واجهوا العائق في المتاهة اضطرّوا إلى التّراجع ذهنيا خطوةً إلى الوراء، وإعادة تقييم الموقف. ولذا عندما واجهوا الجناسات التّصحيفية أخذوا في الحسبان مجموعةَ اختياراتٍ أكبر من تلك الّتي أتى بها الّذين لم يواجهوا العقبة في المتاهة. وهذا شبيه بديناميكية الفريق الّتي لاحظها أوكونو في لعبة التّنصيف. هذه العقلية الأكثر تفتّحًا سمحت لهم بالتّفكير بإبداعٍ أكبر في المهمّة اللاّحقة. وبعبارة أخرى، فإن العقبات تضعنا في إطارٍ ذهني أكثر إبداعًا لحلّ المشكلات. غالبًا ما يأتي الفنانون بأعمالٍ إبداعية باستخدام موارد محدودةٍ للغاية. يمكن للمديرين أيضًا رعايةُ حلول أكثر إبداعًا في فرقهم من خلال خلقِ وهم محدوديّة الموارد. وفي هذا يقول سوهراب فوسوغي -مؤسّس شركة الاستشارات للتّصميم والابتكار Ziba-: "النّدرة تقوّي التّركيز" يمكننا أن نرى مبدأ النّدرة قيد التّنفيذ في فرقٍ إبداعية، فحسب فوسوغي: "كلّ هذا قد يفسّر خاصيّةً مشترَكةً للمنظّمات دائمة الابتكار، إنّها تعملُ بعقليّةِ النّدرةِ حتّى في أوقات الوفرة". قد تُغريك -كقائد فريقٍ- فكرة تخصيص المزيد من الموارد لحلّ مشكلة ما: تمديد الآجال، وإضافة أعضاء للفريق، وتخصيص ميزانية أكبر، أو التخلّص من بعض الشّروط. ولكن، إذا كان هدفك الحلول الإبداعية، فربّما يكون من الأفضل لك القيام بالعكس. حدّد أجلاً طموحًا للمشروع. سمّ المشكلة تحدّيًا يختبر التصوّرات الحالية عمّا يُعتبر ممكنا. قلّل الموارد بتخصيص أرقام ثابتةٍ لكلّ من ميزانية المشروع، وعدد أعضاء الفريق المعنيّين، وكميّة أو أنواع المواد المستخدمة. ضع فريقك أمام تحدّيات توسّع تفكيرهم وتدفعهم لأخذ عدد أكبر من الحلول الممكنة في الحسبان. فالفِرق عادةَ تنجح بفضل توتّر العمل ضمن حدود التحدّي وليس على الرّغم منها. تشجيع النقاش في عام 1948، كان أليكس أوزبورن شريكًا في وكالة الإعلان B.B.D.O -الشركة المُعتبرة الأكثر ابتكارًا في ماديسون أفينيو-، وفي ذلك العام نشر كتابًا بعنوان Your Creative Power (قوّتك الإبداعية)، الّذي حمل أفضل نصيحة له بشأن الإبداع. انتشرت قواعده حول العصف الذهني بالأخصّ، وأصرّ أوزبورن على نهج "لا توجد فكرة سيّئة": ولكن في عام 1958 قرّرت مجموعةٌ من الباحثين في جامعة يايل اختبار قَناعات أوزبورن في تجربة مضبوطة. فجاءوا بمجموعةٍ من الطلاب وقدّموا إليهم أنواعًا مختلفةً من الألغاز الإبداعية لحلّها. قسّموا نصف الطلّاب إلى مجموعاتٍ وطلبوا منهم اتّباع تعليمات أوزبورن. فيما عمل النّصف الآخر من دون تعليمات. خلافًا لطريقة أوزبورن في العصف الذّهني، تفوّق الطلاّب المنفردون كمّا ونوعيّةً. إذ جاءوا بحلول للألغاز الإبداعية أكثر من تلك الّتي أتى بها طلاّب المجموعات. بل وأكثر من هذا، كانت حلولهم أجدى وأكثر فاعلية. أظهرت الدراسات اللاّحقة نتائجَ مماثلةً. وفقًا لعالم النفس كيث سوير: في عام 2003، اكتشفت الباحثة في علم النّفس تشارلان نيميث، أن سرّ العصف الذّهني الإبداعي قد يكون في الواقع النّقيض التّام لنصيحة أوزبورن. إذ أعطت مجموعات من خمسة طلاب مشكلةً واحدةً لحلّها: "كيف يمكن الحدّ من الازدحام المروري في منطقة خليج سان فرانسيسكو؟" ثم أعطت المجموعات 20 دقيقة للتوصّل إلى أكبر عددٍ ممكنٍ من الحلول. وأعطتْ كلّ مجموعةٍ شرطًا من الشّروط التّالية: تعليمات العصف الذّهني، بما فيها قاعدة "لا للنّقد" تعليمات نقاش، بما في ذلك تقديم الاقتراحات للمناقشة وحتّى انتقاد أفكار أعضاء مجموعتك. مجموعةُ مراقَبةٍ بدون تعليمات. تفوّقت مجموعات العصف الذّهني على مجموعات المراقبَة، ولكن بفارقٍ طفيف. فيما حَلّت مجموعات النّقاش أوّلا. توصّلت مجموعات النّقاش إلى حلول أكثر بنسبة عشرين بالمئة (20%) في المتوسّط. والأعجب أنّ التّاثير تواصل إلى ما بعد العصف الذّهني الأوّلي. فبعد أن تفرّقت المجموعات، سأل الباحثون كلّ طالبٍ مشاركٍ إن كانوا يمتلكون أفكارًا أخرى. فقدّم أعضاء العصف الذّهني ومجموعاتِ المراقبة ثلاثة أفكار، فيما جاء المناقشون بسبعة أفكار. علّقت نيميث على البحث بقولها: تقترح نيميث أنّ المعارضة تساعد على الإتيان بأفكار جديد لأنّها تشجّع على إعادة تقييم وجهة نظرنا بعد التّفاعل مع أفكار الآخرين. ومع أنّ نبذ فكرة "لا توجد أفكار خاطئة" أمرٌ أقلّ إيجابية، غير أنّه مفيد: "قد يكون النّقاش أقلّ إرضاءً، لكنّه بالتّأكيد أكثر إنتاجًا. والإبداع الحقّ يحتاج بعض المقايضات." لذا فلتتخلّص من القواعد القديمة الّتي حرّمت الانتقاد، وساعد أفراد فريقك على وضع "الأنا" جانبا، وطرح الأسئلة، والتّفاعل مع أفكار بعضهم البعض بطريقة بنّاءة. أعد تصوير النّقاش على أنّه جزء حيوي إيجابي من كلّ عمليّة إبداعية أو حلّ مشكلة. تعزيز الإيجابية قد تنعكس نتائج الإستراتيجيّات المذكورة آنفا من دون فريق عمل إيجابي ذي ثقافةٍ داعمةٍ لها. فالفرق قد تتخبّط تحت طائلة ضغوط تحقيق توقّعاتٍ تبدو مستحيلة، والنّقاشاتُ قد تنقلب إلى نزاعات وخلافات ونقاط مسدودة. تؤتي هذه الإستراتيجيّات أُكلَها حين تُدعمُ بجوٍّ من الثّقة والإيجابية يسمح للأفراد بالتصرّف بانفتاح وصراحة فيما بينهم، ويتيح تقبّل النّقد كعامل إيجابي، والإخفاق كجزء من العملية الإبداعية. يُظهر البحث أنّ المزاجات الإيجابية تجعلنا أكثر قبولا لتعلّم أشياء جديدةٍ وأخذ اختياراتٍ أكثر في الحسبان. وتجعلنا أكثر تقبّلا للنّقد ووجهات النّظر المخالفة. وعلى النّقيض فإنّ المزاجات السّلبية تضيّق طرق تفكيرنا، مركّزين على المشاكل بدل الاحتمالات. تقترح الخبيرة في دراسة تأثير الحالات العاطفية على العمل تيريسا أمابيلي أنّ الإبداع والمشاعر الإيجابيّة يمكن أن يشكّلا حلقةً مُغلقةً. فالمهامّ الإبداعية تُشعرك بإيجابيّة أكبر، فيما تُشعرك الإيجابيّة بطاقةٍ إبداعية أكبر. بالإضافة إلى أنّ المشاعر الإيجابية تساعدنا على اكتساب موارد سيكولوجيّة واجتماعية تفوقُ سعادتنا المؤقّتة. ما يتيح لنا أن نكون أكثر إبداعًا في المستقبل بفضل مزاجٍ إيجابي نعيشه الآن. وبالمثل، آظهر بحث عالم النّفس باربرا فريدريكسن الفوائد الجمّة للمشاعر الإيجابية على عمل الأفراد، وإبداعهم، وصحّتهم بشكلٍ عام: تعاونت فريدريكسن مع عالم النّفس ومستشار الأعمال مارسيل لوسادا لمعرفة كيفيّة انتقال تأثير الإيجابية على الأفراد إلى ديناميكيّات الفريق. درس لوسادا ستّين فريقًا أثناء عقدهم لقاءات تخطيط إستراتيجي سنويّةً. وهي عمليّة تتطلّب الكثير من الإبداع التّعاوني لكي تنجح. لاحظ فريقهُ وسجّل اللّقاءات من خلف زجاجٍ أحاديّ الجهة، وصنّفوا كلّ عبارة إمّا على أنّها "إيجابية"، أو "سلبية"، أو "محايدة". كما اعتمدوا في التّصنيف معيارين آخرين: هل كان المتحدّث مركّزًا داخليا على المجموعة نفسها، أم خارجيًّا، مراعيًا السّياق الأوسع المحيط بالشّركة؟ هل كان المتحدّث مركّزًا على الدّفاع عن وجهة نظره، أم طارحًا الأسئلة وجامعًا معلومات جديدة؟ رتّب الباحثون أداء كلّ فريقٍ بناءً على مقاييس أعمال مستقلّة. وكان للفرق عالية الأداء نسبة 6 عبارات إيجابية مقابل كلّ عبارة سلبية. في المقابل، كان أكثر من نصف عبارات الفرق متدنّية الأداء سلبيًّا. بالإضافة إلى ذلك، وازنَ الأفراد في الفرق عالية الأداء في عباراتهم بين طرح الأسئلة والدّفاع عن وجهات نظرهم، وبين تركيز داخلي على المجموعة وخارجيّ إلى السّياق الأوسع الّذي تنشط الشّركة خلاله. أمّا الأفراد في الفرق منخفضة الأداء ففعلوا العكس تماما: مالوا إلى التّركيز داخليًّا على الفريق، لم يطرحوا أيّة أسئلة تقريبا، وطوّروا وجهة نظرهم الخاصّة بشكل شبه حصري. تقول فريدريكسن: "لم يستمع أيٌّ منهم إلى الآخرين، لقد كانوا جميعًا في انتظار دورهم للتحدّث." هذا لا يعني أنّ الفريق ينبغي أن يكون إيجابيًّا طوال الوقت ليحقّق النّجاح. فالمشاعر السّلبية لها مكانُها في العملية الإبداعية. إذ أظهرت بعض الدّراسات أنّ "المزاج المحايد أو شبه السّلبي قد يكون أكثر فاعليَّةً في بعض المهام كالتّحليل المنهجي، لأنّه يجعلنا أقلّ عرضةً لأخطاء في التّقدير، أدقّ في تذكّر الأحداث، وأفضل في صياغة حجج أفضل مستوى وإقناعًا." ولكن حين تصبح السّلبية هي المزاج السّائد تتخبّطُ الفِرَق في دوّامة من السّلبية، والتّفكير الضيّق، والدّفاع عن النّفس. للاطّلاع على حلولٍ إبداعية، يقوم المديرون الفاعلون بخلق ثقافاتٍ إيجابية لفرقهم تعزّز انفتاحًا على الأفكار الجديدة، وتشجّع الأسئلة، وتساعدُ الموظّفين على التّفكير في التحدّي الحالي تفكيرًا أوسع. تميل قصص الفرق المبدعة وطرق الابتكار المتعرّجة إلى تكون أجزاءً متساويةً من العلم والفنّ والحظّ. ولكن، ثمّة أشياء يمكنك القيام بها كمدير لخلق ثقافةِ تفاعل نشيط، ونقاش، وتساؤل، وعقليّات منفتحة تُخرج للعلن تلك الأفكار الإبداعية المراوِغة الّتي تميّز الشّركات عن غيرها. تقول ماريسا ماير المديرة التّنفيذية لشركة !Yahoo: ترجمة -وبتصرّف- لمقال: Three Ways to Get Your Team to Think Creatively and Produce the Next Great Idea لكاتبته: Belle Beth Cooper

هل لديك فريق من المبرمجين المميزين والمتحمسين؟ بالطبع قد اخترتهم بعناية من بين مئات المرشحين، هل هم متحمسون للمنتج؟ بالتأكيد، إنهم يستخدمون أحدث التقنيات، ولا ينامون أبدًا، ويكادون لا يأكلون أو يشربون أي شيء باستثناء القهوة، هل يؤمنون بنجاح عملك؟ لا شك في ذلك. إنهم يعيشون ويتنفسون كل هذه الميزات، الإصدارات، والتسليم المستمر (continuous delivery)، تجربة المستخدم، وغيرها. هل أنت متأكد من أنهم يطورون المنتج بشكل صحيح؟ حسنًا، نعم، أنت متأكد تمامًا؛ لم لا؟ هل يبدو هذا الصوت مألوفًا؟ لا يمكنني حساب عدد المرات التي سمعت فيها هذه القصص من قِبَل مؤسِسي الشركات الناشئة. معظمهم يفضلون فرقهم حتى يأتي ذلك اليوم الذي يلجؤون فيه لتوظيف فريق جديد. قد يكون هناك العديد من الأسباب المحتملة لمثل هذا الفشل التام، ولكن أحد هذه الأسباب هو الافتقار إلى التنظيم والمنهجية والمراجعات التقنية المستقلة. لا شيء يمكنه أن يحد من تطور الفريق أكثر من عدم الاهتمام بإنجازاته. ومن ناحية أخرى، يُعَد التنسيق المنتظم لنتائجه التي توصل لها وتوقعات الجودة الخاصة بك أحد العوامل الرئيسية التي ستضمن النجاح التقني لشركتك الناشئة. سأُلخِّص فيما يلي تجربتي في تنظيم مثل هذه المراجعات التقنية. تتم المراجعة المستقلة عندما تطلب من شخص خارج فريقك الاطلاع على شيفرتك المصدرية والمصادر التقنية الأخرى وإعطائك رأيًا موضوعيًا بشأنها. ينبغي على كل فريق برمجيات حديث أيضًا استخدام مراجعات للشيفرات الداخلية (internal code reviews)، وهذا شيء مختلف تمامًا. تحدث المراجعة الداخلية عندما يعرض أحد المبرمجين الشيفرة الخاصة به على أعضاء الفريق الآخرين ويسألهم عن رأيهم. يعتبر هذا نشاطًا يوميًا ولا علاقة له بالمراجعات المستقلة. يتم إجراء مراجعة مستقلة بواسطة مبرمج لا يعرف شيئًا عن فريقك. ينضم إلى الفريق، ويتحقق من الشيفرة في مستودعك، ويقضي بضعة ساعات (أو أيام) في النظر إليها والتفكير بها ويحاول فهم ما الذي تفعله. ثمَّ، يخبرك ما هو الخطأ وأين. يشرح كيف يمكنه تحسينه بشكل أفضل، وأين سيجري التغيير، وما الذي سيفعله بدلًا من ذلك. ثمَّ تدفع له ويغادر. قد لا تشاهده أبدًا مرةً أخرى، لكن استنتاجاته واقتراحاته تساعدك على التحقق من صحة الشيفرة الخاصة بك وتقييم أداء فريقك بشكل صحيح. في Zerocracy، نقوم بمراجعات مستقلة لكل مشروع من مشاريعنا، وهذه قائمة بالمبادئ التي نستخدمها: اجعل المراجعات المستقلة منهجية هذه هي القاعدة الأولى والأكثر أهمية - نظّم المراجعات التقنية باستمرار. بالإضافة لذلك، أبلغ فريقك بالجدول الزمني، واجعله مستعدًا للمراجعات. وفقًا لتجربتي، تعدّ مرة واحدة في الشهر ممارسة جيدة. يجب أن تستغرق المراجعة الكاملة من ساعتين إلى ثماني ساعات وفقًا لحجم شيفرتك المصدرية. لا تقضِ أكثر من ثماني ساعات في مراجعة الشيفرة؛ ليس هناك فائدة من التعمق في الشيفرة خلال المراجعات المستقلة. ادفع لإيجاد الأخطاء نحن دائمًا ندفع ثمنًا للأخطاء، وليس للوقت الذي نقضيه في العثور عليها. نطلب من مراجعينا الاطلاع على الشيفرة والإبلاغ عن أكبر عدد من الأخطاء التي نظن أننا بحاجتها. لكل خطأ، ندفع ثمن 15 دقيقة لوقتهم. بمعنى آخر، نفترض أن المراجع الجيد يمكنه العثور على ما يقارب أربع مشكلات ويبلغ عنها في ساعة واحدة. على سبيل المثال، مراجع يقبض 150 دولارًا في الساعة (قد يختلف الأجر في البلاد العربية). نوظفه ونطلب منه أن يجد أخطر 20 مشكلة حرجة يمكنه أن يكتشفها ويبلغ عنها. تقديرنا هو أنه ينبغي أن يقضي خمس ساعات في هذا العمل. وبالتالي، سوف يحصل على 750 دولارًا عندما يكون لدينا 20 خطأ في نظام التتبع الخاص بنا والذي أبلغنا عنه. إذا وجد عددًا أقل، فسيحصل على أموال أقل نسبيًا. سيساعدك جدول الدفع هذا في جعل المراجع يركز على الهدف الرئيسي لعملية المراجعة – وهو العثور على المشكلات والإبلاغ عنها. لا توجد أهداف أخرى. الشيء الوحيد الذي تهتم أنت به هو معرفة ما هي المشاكل المتعلقة بحلك التقني الحالي. هذا هو ما تدفع مقابله. وظّف الأفضل وادفع أكثر تخبرني تجربتي أن وظيفة المُرَاجع المستقل مهمة للغاية. إنّه ليس مجرد مبرمج بل هو أكثر من ذلك، إنّه مهندس قادر على النظر إلى الحل من مستوى تجريدي عالٍ للغاية، وفي نفس الوقت يهتم بالتفاصيل كثيرًا؛ يجب أن يكون بارعًا في تصميم الأنظمة المماثلة؛ و يعرف كيفية كشف الخطأ والإبلاغ عنه وتزويدك بتفاصيل كافية؛ يجب أن يفهم مجال عملك وما إلى ذلك؛ إلى جانب كل ذلك، ينبغي أن يكون متحمسًا لمساعدتك. أنت لا توظفه للعمل بدوام كامل وإنّما فقط عمل لبضع ساعات. نصيحتي هي محاولة الحصول على أفضل الأشخاص، ودفع أجورهم بقدر ما يطلبون، وعادةً ما يكون أكثر من 100 دولار في الساعة. لا تتفاوض، فقط ادفع. إنّها مجرد بضعة مئات من الدولارات، لكن تأثير مساهمتهم هذه سيكون هائلًا. ملاحظة: قد تختلف الأسعار في الوطن العربي ويمكن أن تكون أقل مما ذُكِر آنفًا. اسأل وتوقع النقد إنّه خطأ شائع أن تسأل مراجعًا، "هل تعجبك الشيفرة الخاصة بنا؟" لا تتوقع منه أن يخبرك كم أن الشيفرة الخاصة بك ممتازة. ليس هذا ما تدفع مقابله، فأنت لديك فعليًا فريق كامل من المبرمجين لتشجيعك. يمكنهم إخبارك الكثير عن الشيفرة التي يكتبونها ومدى روعتها. لا تريد سماع ذلك مرة أخرى من المراجع. بدلًا من ذلك، أنت تريد أن تعرف ما هو الخطأ وماذا تحتاج لإصلاحه. وفقًا لما سبق، يجب أن تكون أسئلتك مثل، "ما هي المشكلات التي تعتقد أنه يتعين علينا حلّها أولًا؟" سيحاول بعض المراجعين إقناعك بتعليقات إيجابية لكن تجاهل هذا الإطراء وأَعِدهُم إلى الهدف الرئيسي - وهو الأخطاء. الجدول الزمني للدفع الموضح أعلاه يجب أن يساعدك بذلك. غيّر المراجعين باستمرار حاول ألا تستخدم المراجع نفسه أكثر من مرة في نفس المشروع (أعني في الشيفرة الأساسية نفسها). أعتقد أنَّ السبب هنا واضح، لكن دعني أعيد التأكيد: لا تحتاج أن يكون مراجعك لطيفًا معك وأن يخبرك بمدى جودة الشيفرة. إنما تريده أن يكون موضوعيًا ويركز على المشكلات، وليس على الجوانب الجيدة. إذا وظّفت نفس الشخص مرارًا وتكرارًا، فسوف تجعله مرتبط نفسيًا بالشيفرة المصدرية. لقد شاهدها مرة واحدة؛ والآن سيراها مرة أخرى. لقد أخبرك بالفعل عن بعض المشاكل، والآن عليه أن يعيدها مرة أخرى. لن يشعر بالراحة عند القيام بذلك. بدلًا من ذلك، سيبدأ بالشعور كأنه عضو في الفريق وسيشعر بالمسؤولية تجاه الشيفرة المصدرية وأخطائها. سيبدأ مثله مثل أي عضو آخر في الفريق، في إخفاء المشكلات بدلًا من الكشف عنها. إذن، استشر شخصًا جديدًا لكل مراجعة تقنية مستقلة جديدة. كن لطيفًا وصادقًا مع فريقك يمكن أن تكون المراجعات المستقلة مزعجة بالنسبة للمبرمجين لديك. قد يعتقدون بأنك لا تثق بهم. قد يشعرون أنك لا تحترمهم كأخصائيين تقنيين. ربما يقررون أنك تستعد لطردهم جميعًا وأنّك تبحث حاليًا عن أشخاص جدد. هذا الأمر ممكن جدًا ويعطي تأثيرًا جانبيًا مدمرًا للغاية في المراجعة المستقلة. كيف يمكن تجنب ذلك؟ لا أستطيع أن أقدم لك نصيحة شاملة، لكن أَفضل اقتراح يمكنني تقديمه هو: أن نكون صادقين معهم. أخبرهم أن جودة المنتج أمر خطير بالنسبة لك ولعملك. اشرح لهم أنَّ الشركة تدفع لهم مقابل عملهم وأنّه من أجل الحفاظ على استمرارية الرواتب، عليك التشديد على مراقبة الجودة بشكل منتظم، موضوعي، مستقل وصادق. في النهاية، إذا تمكنت من تنظيم المراجعات كما توضح هذه المقالة، فسيكون الفريق ممتنًا جدًا لك. سيحصلون على الكثير من الآراء والأفكار الجديدة من كل مراجعة وسيطلبون منك تكرارها باستمرار. راجع من اليوم الأول لا تنتظر حتى نهاية المشروع، لقد رأيت هذا الخطأ عدة مرات. كثيرًا ما يعتقد مؤسسو الشركات الناشئة أنّه يجب ألا يشتتوا انتباه فريقهم حتى يتم الانتهاء من المنتج ويصبح جاهزًا للسوق. يعتقدون أنّه يجب عليهم أن يسمحوا للفريق بالعمل على تحقيق مراحل المشروع والاعتناء بالجودة لاحقًا، "عندما يكون لدينا مليون زائر يوميًا" لن يأتي هذا اليوم أبدًا إذا سمحت لفريقك بالاستمرار بدون إدارة. ابدأ في إجراء مراجعات مستقلة من اللحظة التي يُرفع فيها الملف الأول على مستودع Git. وحتى يصبح المستودع كبيرًا بدرجة كافية، ربما تنفق 300 دولار مرة واحدة شهريًا لتلقي رأي موضوعي ومستقل بشأن جودته. هل سيدمر هذا ميزانيتك؟ امنع النقاشات، واطلب تقاريرًا رسمية لا تدع المراجعين يتحدثون إلى الفريق. إذا قمت بذلك، فإن فكرة المراجعة المستقلة ستنهار بالكامل. إذا كان المُراجع قادرًا على طرح أسئلته بطريقة غير رسمية ومناقشة تصميم النظام الخاص بك مع المبرمجين لديك، فستعجبه إجاباتهم ويمضي قدمًا. لكن باعتبارك مالكًا للشركة ستبقى بالمستوى نفسه الذي كنت به قبل المراجعة. الهدف من المراجعة ليس إسعاد المراجع وإنما العكس تمامًا. أنت تريد إرباكه، فإذا كان في حيرةٍ حيال وجود خطأ في التصميم، سيشعر بضرورة الإبلاغ عن الخطأ الموجود. يجب أن تعبّر الشيفرة المصدرية عن نفسها، ويجب أن يفهم أي شخص غريب (المراجع) كيف تعمل هذه الشيفرة بسهولة. إذا لم يكن الأمر كذلك، فهناك شيء خاطئ يجب إصلاحه. التعامل مع أي سؤال كأنه خطأ لا تتوقع أن ينتج المراجع أي أخطاء في الوظائف، مثل "أنقر على هذا الزر فيتوقف النظام". نادرًا ما يحدث هذا، إن حدث. فريقك جيد جدًا في اكتشاف هذه المشكلات وحلها. والمراجعات المستقلة ليست حول هذا النوع من الأخطاء. الهدف الرئيسي من المراجعة المستقلة هو اكتشاف الأخطاء في الهيكلية والتصميم. قد يعمل المنتج الخاص بك، ولكن قد يكون هناك عيوب خطيرة في هيكلية التصميم تُعيقك، مثلًا، من التعامل مع النمو الهائل في حركة البيانات على شبكة الويب. سيساعدك مراجع مستقل في العثور على هذه العيوب ومعالجتها في وقت أقرب. من أجل الحصول على هذا النوع من الأخطاء من المراجع، يجب عليك تشجيعه على الإبلاغ عن أي شيء لا يعجبه - استخدام التكنولوجيا بدون دافع، والافتقار إلى التوثيق، والهدف غير الواضح لملف، وعدم وجود وحدة اختبار، وغير ذلك. تذكر، المراجع ليس عضوًا في فريقك ولديه أفكاره الخاصة حول التقنيات التي تستخدمها والتطوير البرمجي بشكل عام. عليك أن تهتم بمطابقة وجهة نظره مع فريقك. بعد ذلك، عليك الاهتمام بإصلاح جميع حالات عدم التطابق الضرورية. راجع كل شيء، وليس فقط الشيفرة المصدرية دع المراجع الخاص بك ينظر إلى جميع المصادر التقنية التي لديك، وليس فقط ملفات شيفرة المصدر (‎.java ، .rb ، .php، وما إلى ذلك)؛ امنحه حق الوصول إلى مخطط قاعدة البيانات، ولوحة التكامل المستمر، وبناء البيئة، نظام تتبع المشكلات، الخطط والجداول الزمنية، وجداول الأعمال، وتقارير التشغيل، وخط النشر، وسجلات الإنتاج، وتقارير أخطاء العملاء، والإحصاءات، وغيرها. كل شيء يمكن أن يساعده في فهم كيفية عمل نظامك، والأهم من ذلك، أين وكيف ينهار، إنه أمر مفيد للغاية. لا تجعل معرفة المراجع تقتصر على الشيفرة المصدرية فقط - فهذا ببساطة لا يكفي، دعه يطّلع على المشروع بالكامل، وسوف تحصل على تقرير أكثر تفصيلًا واحترافيةً. تابع كيفية حل التناقضات بمجرد حصولك على تقرير من المُراجع، تأكد من أنَّ أكثر المشاكل أهمية ستدخل مباشرًة إلى عمل فريقك. تأكد من عنونتها وإنهائها. هذا لا يعني أنه يجب عليك إصلاحها جميعًا والاستماع إلى كل ما يقوله المراجع. بالطبع لا، المهندس هو الذي يدير العمل، وليس المراجع. يجب أن يقرر المهندس الخاص بك ما هو الصحيح وما هو الخطأ في التنفيذ التقني للمنتج. ولكن من المهم أن تجعله يحل جميع المخاطر التي طرحها المراجع. ستحصل في كثير من الأحيان منه على إجابات مثل هذه الإجابة: "نحن لا نهتم بذلك الآن"، "لن نصلحه حتى الإصدار التالي،" أو "إنه مخطئ! نحن نفعلها بشكل أفضل." هذه الإجابات صالحة تمامًا، ويمكن أن تحصل عليها (المراجعون أشخاص ويخطئون أيضًا). ستساعدك الإجابات التي تم إيجادها على فهم ما يفعله فريقك ومدى فهمهم لعملهم. إذا كان بإمكانك تزويدنا بالمزيد من الاقتراحات، بناءً على تجربتك فيرجى نشرها في التعليقات وسأضيفها إلى القائمة. ترجمة -وبتصرف- للمقال You Do Need Independent Technical Reviews!‎ لصاحبه Yegor Bugayenko