حنين

نحتاج جميعًا إلى التعهيد الخارجي للبرمجيات، بدءًا من أصحاب أصغر المواقع الإلكترونية وانتهاء بأغنى مئة رجل في العالم، لا سيما عندما نرغب بتصميم منتج برمجي لا يكون مهندس البرمجيات لدينا مؤهلًا لإنجازه، إلا أن النتيجة النهائية نادرًا ما تكون سارة، وفي الحقيقة فمن الصعب جدًا ألا تفشل هذه العملية؛ لذا أعددت هنا قائمة تلميحات بسيطة لكل من يقرر الاستعانة بمصادر خارجية لتطوير البرمجيات (مرتّبة من الأقل فالأكثر أهمية)، ولكم كنت أتمنى لو أُعطيت لي قبل 15 عامًا. حدّد في العقد من يملك حقوق المُنتج تأكد من احتواء العقد بينك وبين فريق التعهيد على عبارة مشابهة لـ: "يقر الطّرفان بأن كل ما سيتم تطويره هو خاضع للملكية الفكرية لصاحب المشروع"، وهو أبسط وأقصر تعريف لعبارة "كل ما تصممه لأجلي هو ملك لي"، عند تضمين العقد بهذه العبارة لن تتمكّن شركة التعهيد الخارجي من الادعاء بأن البرمجيات المصممة ملك لها، كما يحدث دومًا هنا وهناك. احصل على مستودع الشيفرة المصدرية تأكد من تحكّمك التام بالشيفرة المصدرية. الطريقة المثلى لذلك هي إنشاء مستودع GitHub خاص لقاء 7$ شهريًا، بحيث يكون قابلًا للوصول ومرئيًا من قبلك ومن قبل فريق التعهيد فقط. علاوة على ذلك؛ احرص على أن تكون الأذونات الممنوحة للفريق "للقراءة فقط"، وأنهم لا يستطيعون تعديل الشيفرة المصدرية بشكل مباشر إلا عبر تقديم طلب "pull requests"، لأن Git يتيح إمكانية تدمير كامل التأريخ الحالي بنقرة دفع -push- واحدة للفرع الرئيسي master branch، لذا فمن الأفضل أن تمتلك وحدك أذونات الكتابة. لتسهيل إدارة الأمور وتبسيطها، أنصحك بأداة Rultor والتي تمكنك من دمج طلبات Pull requests بشكل شبه أوتوماتيكي. اجمع الإحصائيات “Metrics” بانتظام : اطلب من أعضاء فريق التعهيد أن يجمعوا لك الإحصائيات/المقاييس الخاصّة بالبرنامج قيد الإنشاء ويرسلوها لك بانتظام بطريقة ما (كالبريد الإلكتروني ربما) وأنصح هنا باستخدام Hits-of-Code، النسبة التي تغطيها اختبارات الوحدة Unit tests (أو العدد الكلي لاختبارات فحسب)، التذاكر Tickets المغلقة والمفتوحة، ومدة البناء. أتحدث هنا عن مقاييس تعطيك صورة أوضح عن أداء الفريق، وهو ما لا يمكنك الحصول عليه بشكل مباشر من لدى استخدامك لأدوات التّحليل والمُتابعة كـ NewRelic. هذه المقاييس ستكون معيارًا لأداء الفريق، وليس المنتج قيد التطوير. لا أقول أنك يجب أن تدير الفريق من خلال هذه المقاييس، ولكن أبقِ عينيك مفتوحة على هذه الأرقام وعلى الأداء. إجراء مراجعات تقنية مستقلة: تكمن أهمية هذه المراجعات لصعوبة التحايل عليها. في الحقيقة فهذه الطريقة هي المثلى -ولعلها الوحيدة- لجمع آراء موضوعية عن البرنامج قيد الإنشاء وهو أمر ضروريّ جدًا بالنسبة لك. لا تعوّل على الوعود؛ التقارير، الضمانات أو التوثيق الشامل التي يقدّمها لك فريق التّعهيد، عوضًا عن ذلك؛ تعاقد مع شخص واطلب منه مراجعة ما يطوره لك فريق التعهيد الخارجي. قم بهذه المراجعات بشكل دوري ومنتظم، لا تخش من التّواصل مع فريق البرمجة، واشرح لهم بصراحة ما تحتويه المراجعات من نقاط تستوجب التعديل، إذا كانوا محترفين في عملهم فإنهم سيفهمون ويقدرون غرضك من هذا التصرف بالتأكيد. أتمتة النشر Deployment والتحكم به: اطلب من فريق التعهيد أتمتة آلية نشر التّطبيق deployment pipeline ووضعه تحت تحكمك، أنصحك أن تقوم بذلك خلال الأيام الأولى للمشروع، ما يعني أن المنتج سيُبنى؛ يُختبر؛ يُحزّم، يُركّب، وينشر في مستودع الإنتاج (أو على الخادوم) بنقرة واحدة. بالطبع أنت بحاجة لبعض السكربتات لأتمتة هذه السلسلة من العمليات، وينبغي على فريق التعهيد كتابتها لك. ومن ثم؛ عندما تبدأ عملية التطوير، سيُنفّذ السكربت نفسه عند إجراء أي تعديل على المستودع الذي سينشر للإنتاج. المهم هنا هو معرفتك كيفية عمل السكربت وآلية تشغيله، بحيث تكون قادرًا على بناء ونشر منتجك بنفسك. المطالبة بإصدارات أسبوعية: لا تنتظر النسخة النهائية من المنتج؛ واطلب من فريق التعهيد أن يصدروا نسخة أسبوعية منه، لا يهم مدى كثافة التطوير أو عدد الميزات الجاري تنفيذها، من الممكن دائمًا تحزيم نسخة جديدة وإطلاقها. إذا كان التطوير مكثفًا، اطلب من الفريق استخدام GitFlow مثلًا لعزل فرع مستقر من أفرع التطوير، لكن احذر من الانتظار. احرص على رؤية البرنامج مُحزّمًا ومنشورًا بشكل أسبوعي، دون استثناءات أو أعذار، إذا لم يكن فريق التعهيد قادرًا على إعطائك ذلك فذلك مدعاة للقلق، وقد تحتاج حينها إلى إجراء تغيير ما. وظّف CTO مستقل: أقدّم هذه النصيحة في المقام الأول للشركات الصغيرة أو الأفراد الذين يرغبون بتطوير منتج برمجي خاص بهم ويعتمدون على خبرتهم الشخصية أثناء مراقبة فريق التعهيد الخارجي. ففي كثير من الأحيان يحاول أصحاب المشاريع إبداء حذاقتهم في عالم البرمجيات ويتحكمون بفريق التعهيد بشكل مباشر، عبر تعلم لغة البرمجة المُستخدمة في المشروع، أو تعلّمهم لمبادئ DevOps، لكنهم لا يعلمون أن ذلك كله يقودهم للفشل. لذا كن ذكيًا واعتمد على الشخص المناسب: فالتعاقد مع مدير تقني تنفيذي chief technical officer (CTO) أمر لا بد منه في هذه الحالات، ليرسل لك تقارير مستمرة ويوجه عمل فريق التعهيد الخارجي. سيكون تعاملك المباشر مع مدير التقنية CTO ويتولى هو توجيه فريق التعهيد ومراقبته؛ بحيث يرسل CTO لك التقارير عن سير العمل، ويرسل له فريق التعهيد التقارير التقنية بدورهم. تحديد المكافآت والعقوبات: هذان العنصران أساسيان في عالم الإدارة والقيادة؛ ولست أعني هنا إدارتك للمبرمجين كأفراد كل واحد منهم على حدة، بل أن يكون الفريق تحت تحكمك كوحدة واحدة. الدوافع مهمة للغاية في هذا المجال؛ إذ يجب أن يعلم الفريق بوضوح ما الذي سيجنوه إن نجحوا؛ وما الثمن الذي سيدفعوه بالمقابل إن هم فشلوا، وإذا لم تكن صريحًا بهذه الآلية فستكون فرصتك بالنجاح ضئيلة بالفعل. يفترض معظم الناس أن أفضل دافع لفريق البرمجة هو استمرار العمل بالمشروع، والدفعات المالية التي تقدمها لهم؛ أليس كذلك؟ لكن في الحقيقة هذا خاطئ تمامًا، لا يمكن أن تكون الإدارة ناجحة عبر المكافأة من خلال تحويلات مصرفية شهرية أو المعاقبة بالحرمان منها، وسبب فشل هذا الأسلوب كليًا هو قسوته وغلظته، ابحث عن آلية أفضل وأكثر دماثة وفعالية في أسلوب المكافأة والعقوبة ترجمة -وبتصرّف- للمقال Software Outsourcing Survival Guide لصاحبه Yegor Bugayenko حقوق الصورة البارزة محفوظة لـ freepik

تحدّثنا مؤخرًا عن آراء العملاء التي لا يجب أن تستمع إليها، لكن بعد أن تتخلص من الملاحظات الطموحة، الافتراضات، وتكهنات الطرف الثالث، ما هي التغذيات الراجعة التي ينبغي أن تستمع لها؟ وكيف تستخرج منها معنىً يساعدك على التطوير؟ من المهم بدايةً إدراك أنه حتى بعد التخلّص من الملاحظات الطموحة، الافتراضات، وتكهنات الطرف الثالث، فإن ما يتبقى من ملاحظات ليست متساوية القيمة بالتأكيد، فيما يلي سنستعرض بعض المُرشّحات الإضافية الهامة لمساعدتك على تحديد أيّ التغذيات الراجعة أكثرُ أهميةً من غيرها: 1. من الذي يقدم لك النصيحة؟ هل تُعطي اهتمامًا متساويًا لجميع النصائح التي تتلقاها من مختلف أنواع الأشخاص المحطيين بك؟ لا أظن ذلك. إذ غالبًا ما تميل للثقة في آراء الأصدقاء الذين تعرفهم منذ فترة طويلة، بينما لن تبالي كثيرًا تجاه نصيحة قد يُلقيها عليك شخصٌ غريب التقيته صدفةً في حافلة نقل عام. في عالم الأعمال التجارية فإنّ مستوى علاقة العميل مع مُنتجتك تؤثّر في مقدار الوزن الذي ستُعطيه لملاحظاته، فالزبائن الأوفياء لديهم من الخبرة مع المنتج الخاص بك ما يمكن اعتباره ثروة لا ينبغي التفريط بها. هل لديك بعض العملاء الذين بدؤوا باستخدام منتجك منذ ستّة أشهر فقط إلا أنهم يستخدمونه بشكل مُكثّف؟ هؤلاء تحمل آرائهم إذن قيمةً مُضافة. هل لديك عملاء يدفعون أكثر بكثير من الآخرين؟ عليك أن تأخذ هذا العامل بعين الحسبان أيضًا. 2. كيف حصلت على التغذية الراجعة؟ التغذية الراجعة العفوية (أي تلك التي تأتي بدون طلبٍ منك) تستحق اهتمامًا خاصًا، فالنصائح التي لم تنتبه لها من قبل قد تحمل أهم الأشياء التي يجب أن تسمعها. ينبغي أن تُرخي السمع إلى الزبائن الذين يُرسلون إليك تغذيةً راجعة من دون أن تطلب منهم ذلك، وأن تجري استطلاعات رأي مفتوحة بدلًا من نماذج الاختيار من عدّة إجابات. غالبًا ما يسأل الأطباء مرضاهم في نهاية الجلسة عمّا إذا كان هناك شيءٌ آخر يودّون الحديث عنه، ففي كثيرٍ من الأحيان يبوح المريض وقتئذ بالأشياء الأكثر أهمية حول مشكلته تلك. 3. ابحث وراء الدوافع عادةً ما يندفع الناس إلى إبداء آرائهم فيما إذا كانوا يملكون تجربة حدّية (في أحد النّقيضين)؛ ولهذا السبب فإنك تلاحظ أن معظم مراجعات المطاعم على سبيل المثال تتوزع ما بين صيحات "مذهل" أو "مُروّع"، فالناس تشعر أنّه من المهم إخبار الآخرين عن مطاعم رائعة للارتياد أو تحذيرهم الوقوع في تجارب سيئة مع أخرى، لكن ماذا لو كانت تجربة العشاء الخاصة بك عادية ومتوسطة التقييم بالفعل؟ في الغالب لن تشعر بدافع لأن تكتب حول تجربتك تلك، فما هي النقطة التي ستُشير إليها تحديدًا؟ إنها ليست قصة مثيرة للاهتمام، أليس كذلك؟ غالبًا ما يمكن تمثيل توزّع هذا النوع من مراجعات المطاعم على منحني بالشكل "J"، فبينما يسقط المُنحني "J" إلى الأسفل بدايةً إلا أنه سُرعان ما يعود للارتفاع إلى أعلى نقطة على الإطلاق. بالعودة إلى ملاحظات العملاء يجب أن تتوقع شيئًا مشابهًا، فالزبائن الأكثر حماسًا للتواصل معك إما أن يخبروك أنهم سعداء للغاية مع مُنتجك أو العكس تمامًا. وبكل الأحوال هذا لا يعني أن زبائنك على نوعين فقط (المنبهرون والساخطون)، فمن المُرجّح أن هناك فئة ثالثةً في الوسط؛ أقصد أولئك الذين يعتقدون بأنّ مُنتجك "جيد". ورغم أنّ هذه الفئة تبقى صامتة عادةً، إلا أنها بالتأكيد تملك ملاحظات مفيدة بالنسبة لك، ومهارتك تكمن في إيجاد الوسيلة المناسبة لاستخلاص آرائهم. 4. دلالة الكمية تحمل كمية الآراء التي تستقبلها حول مسألة معينة دلالةً مُهمّة. فإذا كانت 80% من التغذيات الراجعة للشهر الماضي تشتكي من آخر عملية تعديل قمتَ بها على منتجك، فهذا يتطلب منك التوقف والتفكير، فالحجم الكليّ للتغذية الراجعة من المؤشرات التي تُرجّح أهمية ما يُقال. 5. دلالة التكرار كثيرًا ما تُرفض ملاحظات المستخدمين بحجّة "لقد سمعنا ذلك لسنوات عديدة". رُبما تخطط للتعامل مع هذه المشكلة ضمن إعادة التصميم الجديدة في العام المقبل، لكنك على الأرجح سترى أن هذا الطلب قد تكّرر بشكل كبير. بكل الأحوال يُفترض بك أن تستمع لهذا النوع من المراجعات لا سيما عندما يتعلق الأمر بجودة المنتج الخاص بك، مشاكله، أو وجود صعوبة في إنجاز المهمة الأساسية المرجوة منه، فهذا يعطيك مؤشرًا بأنّك لم تتقن بناء أساسيات المنتج، وهو ما يستحق منك الأولوية المطلقة بدلًا من تجاهله ببساطة. 6. إشعارات الخطر بعض التغذيات الراجعة تتطلب منك الإصغاء إليها تمامًا؛ بسبب خطورة المشكلة التي يمرّ بها العميل، وهذا من أهم أنواع الملاحظات على الإطلاق، فربما قد يحوي التحديث الأخير لمنتجك على ثغرة أمنية، أو أنّك عرّضت خصوصية الزبون للخطر عن طريق الخطأ. عليك أن تدعم أسلوب تقديم التغذيات الراجعة بآلية لتنبيهك على أن ملاحظة ما ذات خطورة عالية لتتمكّن من تدارك الخطأ واتخاذ الإجراءات اللازمة على الفور. إذن، كيف يمكنك تحليل المعلومات الواردة في مراجعات المستخدمين المفتوحة؟ إليكم إحدى أكثر الطرق فاعلية لتحليل مجموعة من المراجعات المفتوحة الخاصة بمنتجك، للأسف لا يوجد طريقة آلية ومثالية يمكن أن تؤدي هذه المهمة عنك، فتحليل المراجعات المفتوحة غالبًا ما يكون أصعب من تلك التي تحتوي عدّة إجابات للاختيار منها ويحتاج لوقت أطول، لكن إن تتبعت الخطوات التالية الذكر ستحصل على قائمة بأولويات رؤى الزبائن والتي يمكن أن تعمل وفقها بكل ثقة. أولا: اجمع البيانات في البداية عليك أن تجمع كل الملاحظات المفتوحة التي ترغب بتحليلها، بالإضافة إلى بيانات وصفية للزبون صاحب الملاحظة في جدول، إذا كان الأمر لديك مثاليًا فستتضمن البيانات الوصفية عن المستخدم بعض السمات المساعدة مثل تاريخ بدئه باستخدام منتجك، كم ينفق، تاريخ تقديم ملاحظته هذه، مصدر الملاحظة (الطريقة التي أدخل فيها المراجعة المفتوحة، الموقع الإلكتروني مثلًا)، ستكون عناوين الأعمدة في جدولك شبيهة بالجدول التالي: ثانيا: احصل على لمحة عامة يجب أن تكوّن انطباعًا عامًا بالمعلومات والبيانات قبل البدء بتصنيفها، امسح المراجعات ببصرك لتحصل على إحساس بمدى تنوع الملاحظات وردات الفعل، كلما قرأتها أكثر ستشعر أن بعض المراجعات تبرز بشكل أوضح. ثالثا: أنشئ قائمة بـ "أنواع الملاحظات" ستقوم الآن بتجزئة الملاحظات ووضع كل جزء من ملاحظة الزبون في مجموعة خاصة، وستحتوي القائمة على مجموعات من هذا القبيل: مشكلة استخدام . طلب ميزة جديدة . تراجع المنتج (أمثلة لمواضع معيّنة بدأ المنتج فيها بالانحدار) . خلل برمجي (أو احتمال خلل) إيجابية عامة ( مثلًا: أحب منتجكم) سلبية عامة (أكره منتجكم) غير هام (ملاحظات لا تعطي انطباعًا معينًا ككلام غير مفهوم) غير ذلك (ملاحظات مفيدة لكن من الصعب تصنيفها، يمكنكم إعادة تصنيفها لاحقًا مع ظهور أنماط أخرى من المراجعات) رابعا: اكتب مسودة لقائمة من التصنيفات التحليلية استنادًا على انطباعك تجاه المراجعات التي قرأتَها حتى الآن، اكتب مسوّدة لقائمة من التصنيفات التي يمكنك استخدامها لتصنف المراجعات إلى حزم قابلة للمعالجة، الأمثلة ستكون مخصصة جدًا حسب منتجك لكن إليك بعض التصنيفات التحليلية لطلبات ميزة جديدة لتفهم المقصد: القدرة على تخصيص رسالة ما لعدد من العملاء . القدرة على إضافة نص HTML للرسائل . القدرة على إضافة أو حذف أعضاء الفريق من أي جهاز . القدرة على إرسال الرموز التعبيرية للعملاء . خامسا: صنف الملاحظات حان الوقت للتركيز والتشمير عن سواعد الجد، اجلس في مكان لا يقاطعك فيه أحد واقرأ كل المراجعات، اقرأ كل سطر بعناية، وصّف مراجعة الزبون في عمود خاص بتصنيفٍ مناسب لمحتواها، أو بمجموعة تصنيفات عند الضرورة (في بعض الأحيان يقدم العميل العديد من الأجزاء المفيدة والمختلفة في مراجعة واحدة)، حاول الاختصار في عدد التصنيفات التي تستخدمها في عموم الملاحظات. سادسا: البدء بالتصنيفات ذات المستوى الأعلى لا مشكلة من البدء بالتصنيف ذو المستوى الأعلى وتجزئته لاحقًا، أولِ اهتمامك التام للغة الدقيقة التي استخدمها الناس في مراجعتهم، قد تبدو العديد من المشكلات متشابهة أثناء القراءة الأولى لكنها تكون في الواقع خلاف ذلك، على سبيل المثال لنقل أنك قرأت العديد من المراجعات المتصلة بـ "مشكلات البريد الإلكتروني"، لكنك عند تمعّنك بالملاحظات وجدت أنها تتفرع إلى عدة مواضيع: "خلل في إرسال الرسائل"و "خلل في استقبال الرسائل" وهما كما ترى موضوعان مختلفان تمامًا. أحيانًا ومع قراءة المزيد من المراجعات تكتشف أنك بحاجة لتجزيء تصنيف أساسي إلى اثنين أو أكثر من التصانيف المخصصة، هذا جيد، استمر بالعمل قدمًا وقسمه إلى تصنيفات فرعية، على سبيل المثال: "المزيد من التحكم بالتصاميم المرئية" يمكن تجزئتها إلى "القدرة على إضافة خطوط" و "القدرة على التحكم في محاذاة الصور"، تذكّر عقب إعادة التصنيف أن تعود للسطور السابقة وتعيد كتابتها وفقًا للتصنيف الجديد. سابعا: احسب مدى شعبية كل تصنيف حالما تصنّف كل المراجعات، أحصِ كل التصنيفات، في حال كان عدد البيانات لديك قليلًا يمكنك الحساب ذهنيًا، أما إن كانت المراجعات كثيرة (أي أكثر من مئة ملاحظة) انسخ العمود الخاص بـ"تصنيفات التحليلات" لصفحة جديدة، أحصِ عدد المرات التي تكرر فيها كل تصنيف في الملاحظات، ثمة طريقة للقيام بذلك وهي الفرز حسب الترتيب الأبجدي لتجميع العناصر التي تحتوي على ذات التصنيف ومن ثم حدّد الخلايا التي لها نفس التصنيف ليظهر عددها في زاوية متصفحك، أنشئ جدولًا لتلخيص عدد التصنيفات الكلي. ثامنا: رتب مشكلات عملائك يمكنك الآن إنشاء ملخص لأعلى المراجعات أهمية بالاستناد لشعبية كل مشكلة وتكرارها وناقش تلك المراجعة مع فريقك، هل تريد ترتيبًا أكثر تخصّصًا؟ يمكنك أيضًا أن تفرز البيانات وفقًا للمتغيرات التي ناقشناها في بداية المقال، على سبيل المثال: صنّف المراجعات بناء على طلبات الميزات الجديدة، مشكلات الاستخدام، تراجع المنتج، المشكلات البرمجية، إلخ ، وناقش الخطوات التالية مع أعضاء الفريق ذوي الصلة بكل مشكلة. استخرج المراجعات الأكثر إلحاحًا بحيث يمكنك التعامل معها كأولوية. استخدم مراجعات العملاء لصنع القرارات الخاصة باستراتيجية منتجك: كن واضحًا حول الأمور التي تقع خارج نطاق منتجك بقدر وضوحك بالأمور التي تقع داخله. أعط الأولوية في معالجة المراجعة تبعًا لنوع الزبون. قارن أنماط المراجعات بين أنواع العملاء المختلفة. ابدأ بتتبع المشاكل الملحّة على مر الوقت لترى فيما إذا تم إهمال أي جزء أساسي منها. التنقيب عن الرؤى القيمة إذن في حين يمكنك تجاهل بعض ملاحظات العملاء، هناك مجموعة واسعة منها يمكنك أن تجد فيها رؤى مهمّة. أتمنى أن يكون هذا المقال قد ساعدك في فهم بعض التقنيات التي يمكنك استخدامها لتأخذ الانطباع من عدد كبير من المراجعات المفتوحة، وتحويلها إلى قائمة من الموضوعات العملية التي يمكن لفريقك معالجتها. ترجمة -وبتصرّف- للمقال Making sense of customer feedback.

يضطر معظمنا على اختلاف أنواع الوظائف إلى حضور الكثير من اجتماعات العمل الفاشلة مقارنة بعدد قليل من الجيد منها، ولا أعتقد أنك ستسرّ إن أحصيت عدد الساعات المهدرة في هذه اللقاءات. ورغم أن انطباعي تجاه الاجتماعات تحسّن نسبيًا منذ انضمامي لفريق Help Scout، إلا أن نظرتي السابقة لم تتغير كليًا، وكما الحال بالنسبة لك فقد بتّ على دراية بالعلامات الدالة على فشل اجتماع ما؛ أكثر مما أعلم عن مؤشرات نجاحه، ما أكسبني -على الأقل- خبرة كافية للانتباه فور بدء أي اجتماع بالانحراف عن مساره، وإليكم في ما يلي قائمة من الأخطاء -المكللة بالنوايا الحسنة- التي قد تُخرج اجتماعاتكم القادمة عن مقاصدها: 1. دعوة أكثر مما يلزم من الأشخاص في البداية دعونا نتفق على أن حشر عدد كبير من الزملاء في قاعة الاجتماعات أو في محادثة Google Hangout هو اختيارك أنت. وهذا الخطأ -كحال جميع الأمثلة المطروحة تاليًا- ناجم عن نية حسنة، فمن الأفكار الشائعة لدينا أن "رأسين أفضل من رأس واحد"، وبالتالي يُفترض أن يعني وجود المزيد من الأدمغة في الاجتماع الحصول على نتائج أفضل، المزيد من العصف الذهني وتبادل أفكار أكثر تنوعًا! قد تكون الفكرة صحيحة نسبيًا لكن دون أن تتجاوز سقفًا معينًا، وهو ما يحدده جيف بيزيوس بقاعدة "بيتزاتان اثنتان two-pizza" -والتي وضعها لتحديد حجم الاجتماعات في أمازون- وتتفق هذه القاعدة مع كثير من المؤلفات التي تؤكد على أن فعالية اتخاذ القرارات تنحدر بشدة عندما يزداد تعداد الحضور ويبلغ عددًا مكونًا من خانتين، وحقيقة فإنني لم أتواجد في اجتماع ناجح خرج عن هذه القاعدة! يمكنني طرح ثلاثة أسباب لذلك: وجود عدد كبير من الآراء سيؤدي في النهاية لمناقشة أمور عديمة الأهمية بشكل محموم، وبشكل عام فإن زيادة حجم مجموعة ما يؤدي لخفض معدل الخبرة فيها. المزيد من الحركة يتطلب المزيد من التنظيم، ما يولد بدوره المزيد من البيروقراطية، فوجود العديد من الأيدي على سفينة ما سيتطلب عملية موازنة دقيقة للثقل للحفاظ على بقائها طافية على سطح الماء. الفائدة الناتجة عن هذا "التخبط الجماعي" لا تعوّض الخسارات الحاصلة ضمنه. السبب الأكثر شيوعًا لزيادة عدد الحضور في أي اجتماع هو عدم الرغبة بإرسال مندوب عوضًا عن مجموعة كاملة، رغم أن انتداب أحد من الفريق سيوفر الكثير من الوقت دون أن يفوّت على البقية أيّة فائدة، وذلك من خلال نقله للنقاشات التي دارت في الاجتماع لأولئك الذين لم يحضروا. 2. تخصيص الاجتماع لإبداع/لإنتاج شيء ما تفيد الاجتماعات -بالتأكيد- لصنع القرارات ورسم الخطط للمشاريع وليس للتّنفيذ. فالمجموعات تُبلي بشكل أفضل في تجميع الأشياء مع بعضها البعض وليس في تنفيذ/إنشاء تلك الأشياء. وعلى الرغم من ذلك؛ فقد ارتكبتُ هذا الخطأ العديد من المرات، إذ طالما كان نتائج "اتخاذ القرارات" الجماعية مشجعة، فقد حسبتُ أنه من الطبيعي أن يكون "إنشاء" الأمور والقيام بها بشكل جماعي جيدًا أيضًا. تعلمتُ الدرس بصعوبة بعد الكثير من التجارب، واستخلصتُ أنه وفي حين تكون الاجتماعات مفيدة لتحديد ما يمكنك القيام به، ستكون سيئة بشكل رهيب للقيام بذلك الأمر. ما أود قوله هنا أن لكل شيء حدود؛ بما في ذلك التعاون، استخدم الاجتماعات لرسم خطّة، للحصول على حوافز دائمة ومستمرة، والوصول إلى الهدف. لكن لا تستخدم الاجتماعات للإنتاج والتّنفيذ. أبدع بمفردك، اتخذوا القرارات معًا. 3. عدم سن القواعد الضابطة للاجتماع لا أحد يحب أن يسن القواعد، قد تشعر بأنك شخص مناهض للتعاون، أو أنك أشبه بمربية وظيفتها مراقبة الأطفال المشاكسين والإشراف عليهم. بالإضافة إلى ذلك، نستمتع عادة بقضاء الوقت مع زملاء العمل، لذا سيكون من السهل أن يتحول الاجتماع إلى جلسة ودودة غير مقيّدة بالبروتوكولات الرسمية، وسريعًا ما يتحول هذا الود إلى "أريحية"، والتي قد تتحول بدورها إلى "لامبالاة"، وهنا مكمن المشكلة؛ فعندما لا تقترن الاجتماعات بالاهتمام لدى الحضور، ستبدأ سلسلة كاملة من العقبات بالظهور: لا يوجد هيكل للجلسة، لذا سيتحول الاجتماع فجأة إلى ما يشبه تبادل الأحاديث في الاستراحة مع مدرس بديل. سيُنظر لتوقيت بدء الاجتماع على أنه اختياري لا إلزامي، الأمر الذي سيكون بمثابة مكافئة للمهملين، وعقوبة للملتزمين. ليس ثمة ما يُكتب في محضر للجلسة ولا توجد أية آجال مُحدّدة لتنفيذ ما اتّفق عليه، ما يؤدي بدوره إلى "دُوار الاجتماعات"، ستدركون لاحقًا أن كل النقاشات لم تكتمل وأنها تحتاج لعصا سحرية لإتمامها، لكن مع الأسف؛ لا يوجد علاج فوري! عدم مراعاة قيمة الوقت، لذا لا يوجد بين الحضور من يركّز أفكاره ويهيّئها ليطرحها بشكل واضح ومدروس، ما يفضي لمزيد من هدر الوقت كالأسئلة الجدلية والمعممة، لحظات الصمت المطبق من الجميع، أو انتظار أحدهم ليتحقق "من شيء ما". كل النقاط الواردة أعلاه تؤدي لاجتماعات محبِطة لا تتبع جدول أعمال محدد، ونادرًا ما تحقق أيًا من النتائج المرجوة منها. وعلى النقيض من ذلك، عندما يتم التعامل بجدية كبيرة في اللقاءات، سيحاول كل فرد من المجتمعين إبداء أكبر قدر منها، وللحرص على إدلاء كل منهم بدلوه يمكن سؤال الحضور عن آرائهم الختامية بفقرة "إغلاق الجلسة"، ليعلقوا باختصار ودون مقاطعة على الطّريقة التي سار بها النّقاش. 4. الإصرار على التوصل لاتفاق تبدو كنصيحة غريبة عند الحديث عن الاجتماعات، لكنها صحيحة؛ فالاجتماعات ليست مخصصة للتوصل لاتفاق، ولكنها تفيد في الوصول إلى أرضية مشتركة / تفاهم أوّلي، وثمة فرق كبير بينهما. الوصول إلى أرضية مشتركة أو إلى تفاهم أوّلي يعني احتمال وجود تحفظات بل وحتى شكوك، لكن يمكن الاعتماد عليه لتبسيط اتخاذ القرار النهائي، وهو ضروري جدًا دائمًا، خلافًا للاتفاق. هنا يغدو وجود مسيرين للاجتماع في غاية الأهمية، فيتأكدون من سماع جميع الآراء، ويصرحون بجدية باهتمامهم بكل النقاط والمخاوف المثارة، ومن ثم يتخذون القرار النهائي ويعلمون الجميع به. في منتصف الطريق يمكننا تشبيه الاجتماعات بكيس الملاكمة الخاص بالعمل، فنحن نلجأ إليها عندما نشعر بالإحباط من تكدس المهام والتقويم المليء بالمشاغل. لنكن أكثر جدية، فالاجتماعات هي ضريبة صغيرة ندفعها لاستمرار العمل بوتيرة أفضل، يمكننا التقليل منها لكن بالتأكيد لا يمكن الاستغناء عنها كليًا. وما لم نخترع أداة للتخاطر؛ فسنحتاج جميعًا -وبصورة دائمة- إلى لقاءات لنتواصل، نتعاون، نتبادل الأفكار، نعبر عن تواجدنا، نتناقش، ونخرج بنتائج مبنيّة على آرائنا مجتمعة. الاجتماعات جيدة لأجل كل هذا، وسنحصل على أفضل النتائج منها عندما نستخدمها لغرضها الصحيح. ترجمة -وبتصرف- للمقال How to Sabotage Any Meeting لكاتبه Gregory Ciotti. حقوق الصورة البارزة: Designed by Freepik.

بدأنا في الدرس السابق الحديث عن برنامج إدارة المشاريع Trello، انطلاقًا من إنشاء حساب جديد مرورًا بالخطوات الأولى في إضافة وإدارة كلًا من الألواح، القوائم، والبطاقات. كما عرضنا نموذجًا بسيطًا لإدارة العمل بين فريق صغير مكوّن من مترجمين، مدققين، وناشرين في موقع إلكتروني. نتناول في هذا الدرس خصائص البطاقات في البرنامج وكيفية التعامل معها. يُمثَّل المشروع في Trello بشكل رئيسي من خلال البطاقات والتي تُعتبر "وحدة العمل" الأساسية. تُفصل البطاقات من نفس النوع إلى "قوائم" داخل اللوح الخاص بمشروعك. فإذا كنتَ تدير موقعًا لنشر الدروس، فإنّ البطاقة ستمثّل أشياءً مثل: فكرة للكتابة، مادة للترجمة، مناسبة قادمة إلخ.. بينما ستكون القوائم التي تتضمنها: أفكار للكتابة، مواد للترجمة، مناسبات قادمة لتغطيتها. الهيكل العام للبطاقة لنلقي نظرة على مكونات البطاقة ضمن Trello: في الأعلى يوجد لدينا أولًا "عنوان البطاقة" أو اسمها؛ والذي ينبغي أن يكون واضحًا ومعبرًا بحيث يسهل معرفة ما تتضمنه البطاقة بمجرد قراءة عنوانها. أسفل العنوان نجد رابطًا باسم "Edit the description" وهو يتيح إمكانية إدراج وصف للبطاقة يشرح وظيفتها، أو محتواها، وأيّة تفاصيل أخرى من المهم أن تكون حاضرة دومًا عند التعامل معها. تعرض البطاقة بعد ذلك الملفات المُرفقة بها "Attachments" مرتبة تنازليًا (من الأحدث إلى الأقدم). يُتيح Trello إمكانية استعراض محتويات بعض أنواع المرفقات مباشرة ضمن المتصفح دون الحاجة إلى تحميلها (كالصور، الملفات النصيّة، وملفات مايكروسوفت أوفيس). وأخيرًا هناك صندوق إضافة التعليقات "Add Comment" والذي يتيح لأعضاء الفريق التفاعل مع البطاقة وإمكانية إدراج مرفقات جديدة، تضمين بطاقات أخرى، أو حتى إضافة إشارة Mention لشخص برسم رمز @ متبوعًا باسمه. بعد إضافة تعليق جديد على البطاقة يظهر أسفله رابط يشير للتاريخ والوقت الذي أُضيف فيه التعليق: يمكن نسخ هذا الرابط لمشاركة التعليق بشكل مُباشر. تُرتّب جميع التعليقات والتفاعلات على البطاقة تنازليًا (حسب التاريخ) في القسم الأخير منها تحت اسم "Activity". خيارات الإضافة في القسم الأيمن من البطاقة لدينا مجموعتان من الأوامر، أولها خيارات الإضافة Add وهي على خمسة أنواع: الأعضاء Members أولًا إضافة أعضاء Members إلى البطاقة بهدف الإشارة إلى صلتهم بها أو وظيفتهم ضمنها. عند إضافة عضو جديد إلى البطاقة فإنه يشترك بها تلقائيًا، وهذا يعني تلقيه إشعارات عند: إضافة تعليق، إضافة أو تعديل تاريخ الاستحقاق الخاص بالبطاقة، نقلها أو أرشفتها. يُضاف شخص جديد من خلال النقر على زر Members وكتابة الأحرف الأولى من اسمه، ثم الضغط على صورة معرّفه. هناك طريقة أخرى تتمثل بفتح القائمة الرئيسية للوح (بالنقر على زر Show Menu في الجانب الأيمن من المنصة وإلى الأعلى) حيث ستظهر الصور الشخصية لأعضاء الفريق، ومن هنا يمكن سحب وإفلات صورة عضو ما إلى إحدى البطاقات لإضافته إليها مباشرةً. كذلك يمكن أثناء مرور مؤشر الفأرة فوق البطاقة، الضغط من لوحة المفاتيح على الزر a لإظهار قائمة إضافة أعضاء إلى البطاقة. الملصقات Labels ثانيًا إضافة ملصقات labels، والتي تُستخدم لتصنيف البطاقات لونيًا بدلالة يحددها المستخدم، ما يُسهّل عملية فرزها والتعامل معها بصريًا. يتيح تريلو عشرة ألوان للاختيار وإمكانية تحديد دلالة لكلٍ منها. يُمكن للبطاقة الواحدة أن تحمل عدّة ملصقات معًا. كما يُمكن استخدام اختصار لوحة المفاتيح "l" (الحرف الصغير من L) أثناء مرور مؤشر الفأرة فوق البطاقة لإظهار قائمة إضافة الملصقات. لحذف مُلصق ما يكفي النقر عليه مُجددًا. قوائم الفحص Checklist ثالثًا إضافة قائمة فحص checklist، وهي طريقة فعّالة لتجزئة وتفصيل المهام الثانوية المطلوب إنجازها لتحقيق المهمة الأساسية التي تُمثلها البطاقة. بعد الضغط على زر checklist سيظهر مربع عائم لتسمية القائمة الجديدة، أدخل اسمًا أو أبقِ الاسم الافتراضي واضغط Enter، ستلاحظ ظهور قسم جديد ضمن مكونات البطاقة بذات الاسم مع مربع يُتيح إضافة العناصر إلى قائمة checklist. عند إنجاز أحد العناصر اضغط بزر الفأرة الأيمن على المربع المجاور له كي يتم احتسابه، وسيُعبّر عن ذلك بتقدّم مؤشر أزرق يُمثّل النسبة المئوية المُنجزة من إجمالي الهدف. إذا كنت ترغب باستيراد قائمة مكتوبة سابقًا من ملف نصيّ أو من جدول بيانات spreadsheet فيمكنك فعل ذلك ببساطة، عن طريق نسخ القائمة ثم لصقها في مربع إدخال العنصر والضغط على الزر Enter، سيعمل Trello على فصل كل سطر كعنصر مستقل بشكل تلقائي. من خلال السحب والإفلات يمكن إعادة ترتيب القائمة في أي وقت. كما يمكن بالنقر على أحد العناصر ثم الضغط على الرابط Convert to Card تحويله إلى بطاقة منفصلة ضمن نفس القائمة. تاريخ الاستحقاق Due date رابعًا إضافة تاريخ الاستحقاق due date وهو اليوم والوقت الذي تُصبح فيه المهمة مُستحقة للتسليم. إذا كان التاريخ المُحدد أبعد من 24 ساعة فإنه يظهر على البطاقة بلون رمادي فاتح، وإذا كان خلال الـ 24 ساعة القادمة فإنه يظهر بلون أصفر، بينما يظهر بلون أحمر عندما يحين موعد الاستحقاق ويظل التنبيه لمدّة 24 ساعة. كما يمكن تعيين تاريخ الاستحقاق عن طريق الضغط على زر لوحة المفاتيح "d" أثناء مرور مؤشر الفأرة فوق البطاقة المطلوبة. المرفقات Attachments خامسًا إضافة مرفقات Attachments إلى البطاقة، والذي يستقبل الملفات من ثلاثة مصادر رئيسية: جهازك الحاسوب ( لا يمكن رفع الملفات من الهاتف في حال كنتَ تتصفح موقع Trello من خلاله). حساباتك في مواقع التخزين السحابي (مثل Dropbox، Google Drive، Box وغيرها). إضافة رابط لملف على الشبكة. مع ملاحظة أن رفع ملف من جهازك يعني إنشاء نسخة ثانية عنه ضمن Trello، بينما إرفاق ملف من خدمة سحابية يقتصر على مشاركة رابط الملف الأصلي. يدعم كلًا من متصفحي Chrome وَ Safari إمكانية سحب وإفلات المرفقات من مدير الملفات إلى البطاقة لتُرفع مباشرةً إليها. الحسابات المجانية في Trello محدودة بحجم 10 ميغابايت للملف الواحد، بينما يُسمح بـ 250 ميغابايت للحسابات المدفوعة. لكن لا يوجد قيود على عدد الملفات التي يُمكن رفعها. خيارات الإجراء أسفل خيارات الإضافة السابقة يوجد لدينا خيارات الإجراء Actions وهي على أربعة أنواع: أولًا نقل البطاقة Move إلى لوح آخر أو إلى قائمة أخرى ضمن نفس اللوح، أو حتى تعديل موضعها ضمن نفس القائمة. للقيام بذلك ما عليك سوى تحديد الخيارات المطلوبة من القوائم المنسدلة التي يتيحها هذا الخيار ثم الضغط على الزر الأخضر Move. ثانيًا نسخ البطاقة Copy وهو يشبه الخيار السابق إلا أنه يُنشئ نسخة أخرى من البطاقة في الموضع الجديد محافظًا على وجودها ضمن موقعها الأصلي. ثالثًا الاشتراك بالبطاقة Subscribe لتلقي الإشعارات كما سبق شرحه. رابعًا أرشفة البطاقة Archive وذلك عندما يُنتهى منها. لا يجب حذف البطاقات في Trello (إلا في حالات نادرة) لإتاحة إمكانية العودة لأية تفاصيل لازمة عند حدوث مشاكل أو ما شابه. يمكن استخدام خاصيّة البحث في Trello للعثور على البطاقات المؤرشفة (أو غير المؤرشفة، حيث يتم البحث في جميع الألواح الخاصة بك). كما يمكن من القائمة الرئيسية للوح Show Menu الضغط على More ثم Archived Items لمشاهدة البطاقات المؤرشفة مع إمكانية إعادتها إلى اللوح عبر زر Send to Board.