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

بدأنا في الدرس السابق الحديث عن برنامج إدارة المشاريع 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.

يُعتبر Trello أحد تطبيقات الوِب الشهيرة لإدارة المشاريع، بدأتها شركة Fog Creek Software عام 2011 (وهي ذاتها الشركة التي أطلقت Stack Overflow) قبل أن يتحوّل الموقع إلى شركة مستقلّة عام 2014، يتضمن التطبيق حزمتين للاشتراك، الأولى مجانية وتتضمن المميزات الأساسية لاستخدام الموقع، والثانية مدفوعة لفرق العمل. يستخدم Trello نموذجًا يُدعى kanban لإدارة المشاريع، والذي أشاعت شركة تويتا استخدامه في الثمانينيات. تُمثَّل المشاريع وفق هذا النموذج على شكل ألواح boards والتي تتضمن قوائم lists (مُشابهة لقوائم المهام task lists)، تتضمن القوائم بدورها بطاقات cards (تُمثّل المهام). ويُفترض بهذه البطاقات أن تنتقل من قائمة إلى أخرى (عبر السحب والإفلات) مُعبّرة عن سير العمل قُدمًا إلى الأمام. يُمكن استخدام Trello بأشكال كثيرة ومتنوعة، بما في ذلك إدارة المشاريع البرمجية، التخطيط للتدوين، العمل على كتاب، إدارة مكاتب المحاماة، العمل على مجلات الحائط المدرسية إلخ، كما يتكامل مع عدد من الخدمات الشائعة مثل البريد الإلكتروني، IFTTT، Slack وغيرها من وسائل التواصل والتنظيم، مما يجعل Trello مكانًا ملائمًا لربط كل شيء مع بعضه ومتابعة سير العمل. نبدأ في درس اليوم الخطوات الأولى مع البرنامج من قبيل إنشاء حساب، تصميم اللوح الأول والتعرف على المزايا الرئيسية وسنتطرق في دروس لاحقة إلى تفاصيل ومواضيع متقدّمة في العمل على Trello. إنشاء حساب يمكن إنشاء حساب في Trello بسهولة عبر التوجّه إلى الصفحة الرئيسية للموقع ثم الضغط على SingUP، الخانات المطلوبة ثلاثة فقط: اسمك، البريد الإلكتروني، وكلمة المرور: بعد ذلك ستنتقل إلى الصفحة الرئيسية في Trello والتي تعرض الألواح boards الخاصّة بمشاريعك، مبدئيًا لن تتضمن هذه الصفحة سوى لوح واحد ترحيبي يُدعى Welcome Board والذي يشمل الكثير من الأمثلة والخصائص التي يمكن تنفيذها باستخدام Trello. إنشاء لوح جديد New Board لنُنشئ لوحًا جديد باسم "أكاديمية حسوب" عبر الضغط على المربع الرمادي Create new board، ثمة خياران مُتاحان عند الإنشاء، الأول هو اسم اللوح، والثاني هو مجموعة العمل التي سنشارك اللوح معها، ولأننا لم ننشئ مجموعات عمل فسنترك هذا الخيار none ونضغط على Create: إنشاء القوائم بعد إنشاء اللوح ينقلنا Trello إلى داخله، وتظهر قائمة جانبية باسم Menu لنغلقها الآن ونُركّز على الزاوية اليُسرى حيث ينتظرنا إنشاء القائمة الأولى، سوف أكتب "مواد للترجمة" وأضغط على Enter، سأنشئ قائمتين إضافيتين "مواد للتدقيق" و "مواد جاهزة للنشر"، الآن يفترض أن يبدو اللوح على الشكل التالي: تُمثّل هذه القوائم سير عملي في أكاديمية حسوب. لنبدأ مع قائمة "مواد للترجمة"؛ تحتوي هذه القائمة على المقالات التي أنوي ترجمتها، هذا يشابه قائمة To Do والتي تتضمن الأعمال التي يتوجّب عليّ تنفيذها. إضافة مهام إلى القوائم لنبدأ بإضافة بطاقة/مهمة إلى القائمة عن الطريق النقر على زر Add a card، سيظهر مربع نصيّ صغير قابل للكتابة، سأضع هنا عنوان إحدى المقالات التي يتوجب عليّ ترجمتها، ثم أضغط على Enter لأرى المهمة قد أضيفت إلى القائمة. بعد ذلك سأضغط عليها بزر الفأرة الأيمن لتُفتح نافذة تفاصيل البطاقة والتي سنتطرق لاحقًا لإدارتها بالتفصيل. ما يهمني الآن في البطاقة هو إرفاقها مع رابط المقال كي يسهل عليّ الوصول للأصل الإنكليزي عندما أبدأ بالعمل، لذا أنسخ الرابط وأضعه في خانة Add Comment ثم أضغط Enter. سيُضاف في الأعلى مربع جديد باسم Attachments والعنصر الأول (والوحيد حاليًا) في المرفقات هو رابط المادة الأصل. انتهيت الآن من إضافة المهمة الأولى، أغلق البطاقة بالضغط على Esc من لوحة المفاتيح أو الضغط على رمز الإغلاق أعلى يمين نافذة إدارة البطاقة. سأتابع بالطريقة عينها مع باقي المقالات التي يجب عليّ ترجمتها، ليصبح اللوح مشابهًا لما يلي: بهذا الأسلوب تكون لديّ صورة دقيقة عن كمية المواد التي عليّ تنفيذها، وسيكون سهلًا متابعة سير عمل العديد من الأعضاء في فريق واحد. في البداية ستكون المقالات ضمن قائمة "مواد للترجمة" مع رابط الأصل لكل منها، لنفترض أنني أنهيت ترجمة المقال الأول، أعود الآن إلى Trello وأضغط على البطاقة الخاصّة به، ومن مربع Add Comment أختار رمز المشبك (الأول من اليسار) لإرفاق النصّ المترجم مع البطاقة، كما في الصورة التالية: الخطوة التالية هي سحب البطاقة من قائمة "مواد للترجمة" وإفلاتها ضمن قائمة "مواد للتدقيق"، سأضغط عليها مُجددًا ومن صندوق إضافة تعليق أختار رمز الإشارة (الثاني من اليسار) لإضافة إشارة mention إلى المُدقّق، كي يصله إشعار بوجود مادة جديدة تحتاج إلى تدقيق، كما هو موضح في الصورة: المُدقق بدوره سيحصل على نسخة من الترجمة مع رابط الأصل، وبعد التنقيح سيرفع نسخة جديدة من الملف، وسينقل بطاقة المقال من قائمة "مواد للتدقيق" إلى قائمة "مواد للنشر"، وعبر الضغط على البطاقة هناك يمكنه إضافة إشارة mention إلى مسؤول النشر في الموقع كي يستلم المادة ويجدولها للنشر. هذه صورة مختصرة ومُبسطة عن أسلوب Trello لإدارة سير العمل وتتبعه، وتسهيل التعاون بين فريق العمل. كيف تنشئ مجموعة عمل؟ حتّى تستطيع إدارة العمل مع الفريق الخاص بك أنت بحاجة إلى إنشاء مجموعة عمل أولًا؛ ثم إنشاء لوح مشترك جديد خاص بالمجموعة. للقيام بذلك اضغط على إشارة الإضافة + أعلى ويسار الموقع، لتظهر لدينا ثلاثة خيارات: الأول لإنشاء لوح جديد، الثاني لإنشاء مجموعة عمل شخصية، أما الخيار الثالث فهو لإنشاء مجموعة عمل تجارية وهذا الخيار يحتاج إلى اشتراك في الخطة المدفوعة لدى الموقع. لذا سننتقي الخيار الثاني ثم نكتب اسمًا للفريق ونضغط على Create: سينقلنا الموقع بعدها إلى المساحة الخاصة بمجموعة العمل والتي تتضمن أربع علامات تبويب: الأولى Boards لإنشاء وإدارة ألواح العمل الخاصة بهذه المجموعة. الثانية الأعضاء Members من هنا يمكنك البحث عن الآخرين عبر أسمائهم على Trello أو عبر عنوان بريدهم الإلكتروني، في حال لم يكن الشخص مُسجلًا لدى الموقع فسيظهر أسفل اسمه زر Send بدلًا من Add لإرسال دعوة بريدية له للاشتراك. علامة التبويب الثالثة Settings تتضمن عدّة خيارات، يمكننا تعديل واحد منها فقط والباقي تحتاج إلى الاشتراك المدفوع، الخيار هو Visibility ويُعبّر عن مستوى خصوصيّة مجموعة العمل، حيث لدينا خيارين: الأوّل خاص Private، وهنا تكون رؤية المجموعة وإمكانية العمل ضمنها محصورة بمن تدعوه لها. الثاني عام Public، حيث يمكن لأي شخص لديه رابط المجموعة تصفح جميع تفاصيلها، كما يمكن لمحركات البحث مثل Google فهرسة محتواها، لكن فقط الأعضاء المدعوون يمكنهم العمل ضمنها. أما ثالث الخيارات Business class فهو مخصص بمزايا إضافية للخطة المدفوعة. نصائح عامة استخدم عناوين واضحة وكاملة لوصف البطاقات. أول ما تقوم به بعد إنشاء البطاقة هو كتابة المزيد من التفاصيل بداخلها، وإرفاق الروابط والملفات اللازمة للعمل. تابع سير العمل بنقل البطاقة من قائمة إلى أخرى كما هو مخطط له، الالتزام بهذا النظام سيجلب فوائد تنظيمية عديدة تظهر مع الوقت. لا تحذف البطاقات بعد انتهاء العمل بل أنشئ قائمة باسم «أرشيف» واحفظ فيها جميع الأعمال المنتهية، قد تلزم هذه البطاقات لاحقًا في حال حدوث خلل أو ما شابه. يمكنك استخدام Trello كلوح لإدارة المهام الشخصية حتى لو لم يكن لديك فريق عمل. ادخل صباحًا إلى Trello وراجع جميع المهام التي يتوجّب عليك تنفيذها وتفحّص إلى أين وصل سير العمل. سنتابع في دروس قادمة شرح المزيد من التفاصيل والاستخدامات عن تطبيق Trello.

كلنا نعلم أنّ الاستعانة بفريق خارجي لتطوير البرمجيات هو كارثة على وشك الحدوث. أولًا، تجد شركة تعدك بكل ما ترغب به للمنتج من تسليم في الوقت المحدد، وكلفة ضمن الميزانية، وجودة عالية، وواجهة مستخدم جميلة، وتقنيات متطورة، ودعم طويل الأمد خالٍ من المتاعب، لذا ترسل الدفعة الأولى وتبدأ رحلتك. بالكاد يفهم الفريق احتياجاتك، والجودة سيئة، وتُنتهك كل توقعاتك حول الزمن والميزانية بشدّة، ويرتفع مستوى الإحباط. والجزء "الأفضل" هو أنّه لا يمكنك الابتعاد وإلا ستخسر كل الأموال التي أنفقتها وستضطر أن تبدأ من الصفر. يجب أن تبقى "متزوجًا" من هذا الفريق لأنّه لا يمكنك تحمّل "الطلاق". هل هناك طريقة للاستعانة بفريق خارجي لتطوير البرمجيات بشكلٍ صحيح؟ نعم، من الممكن القيام بذلك بشكلٍ صحيح وخالٍ من المتاعب، ولكن يجب أن تكون مستعدًا لتغيّر فلسفة إدارتك. المبدأ الأساسي هنا هو: يجب عليك أن تناقش مخاوفك مع الفريق الخارجي الذي تستعين به بشكلٍ علني ومتكرر، و يجب أن يناقشوا معك المشاكل والمخاطر بشكلٍ علني ومتكرر. هذان عاملان أساسيان للنجاح في الاستعانة بفريق خارجي لتطوير البرمجيات يتم إهمالهما في كثير من الأحيان. لقد تعلّمت هذا المبدأ من Wei Liao Zi. قال في كتاب كلاسيكيات الإستراتيجية العسكرية للصين القديمة الصفحة 239: دعني أوضّح بعض الأمثلة العملية لكوارث الاستعانة بفريق خارجي لتطوير البرمجيات وشرح كيف يمكن تجنبها باتّباع مبدأ عمره 2500 سنة. يستغرق الأمر إلى الأبد وأنا تجاوزت الميزانية دائمًا يكون المنتج جاهزًا بنسبة 95%، ولديك دائمًا شيء ما غير منفَّذ أو معطوب. لقد أنجزوا الكثير من العمل، ودفعت الكثير من المال، ولكن المنتج الجاهز للسوق لم يصل بعد. يستغرق أسبوعًا بعد أسبوع وشهرًا بعد شهر؛ دائمًا هناك أعمال متأخرة، وأنت لا يمكنك إنهاء ذلك ببساطة. لقد بدأت برؤية هذا المشروع في كوابيسك، والفريق لم يعد يساعد بعد ذلك. كيف يبدو هذا؟ مألوفًا؟ أرجو أن تدرك أنّه بغض النظر عن نوع العقد الذي وقّعت عليه مع الفريق الخارجي لتطوير البرمجيات، وعدد الجداول الزمنية التي حددتها، وعدد الوعود التي قطعت لك، يريدون الاحتفاظ بك كعميل إلى الأبد. بالطبع طالما لديك شيء في حسابك المصرفي. تريد أن ينجح عملك ويزدهر، صحيح؟ إنّهم يريدون نفس ذلك لعملهم. نجاحك يعني منتجًا تم إنهاؤه وإطلاقه للمستخدمين النهائيين. نجاحهم يعني عمليةً لا نهائية من كتابة البرامج لك. هناك القليل جدًا من القواسم المشتركة بين هذين الهدفين. أودّ حتى أن أقول أنّهم متناقضين مع بعضهم بعضًا - عندما تنجح، يفشلون. سيخبرونك بالطبع أّنهم يريدون إنهاء هذا المنتج لك والحصول على عقود جديدة في المستقبل. سيقولون أنّ الدافع الأساسي هو جعلك سعيدًا والحصول على توصية جيّدة. سيؤكدون لك أنّ رضا العميل أهم من المال، لكن أقترح عليك أن تكون قويّا بما يكفي لتواجه الواقع، كل هذه أكاذيب. أغلب المشاريع المستعان بها بفريق خارجي لتطوير البرمجيات تفشل. الغالبية العظمى (انظر تقرير شاوس الأخير). يدرك مطورو البرمجيات هذا أفضل منك، لأنّهم في معظم الأحيان يشاهدون كيف يحصل هذا كل يوم. ومشروعك ليس استثناءً. لذلك، دعنا ننسى هذه الوعود الجميلة ونركز على الواقع القبيح - اعتمد على نفسك. بأخذ المبدأ الذي ذكرته في الأعلى بالحسبان، إليك نصيحتي: تأكّد من أنّ الفريق يتفهّم وقتك الفعلي، وميزانيتك، ومجالك، وقيود مجالك عواقب انتهاكها. يتعلّق هذا بالجزء الأول من المبدأ - يجب عليك أن تناقش مخاوفك بشكلٍ علني ومتكرر -. الذي يحدث عادةً أنّ فريق الخارجي المستعان به يبقى غير مدركًا لوضع العمل الحقيقي ويسمع فقط عبارة "أحتاج إلى هذا في أسرع وقت ممكن" مرّةً كل يومين. "أسرع وقت ممكن" هو ليس موعدًا نهائيًا. علاوةً على ذلك، إنّه فقط بديل مثبّط للغاية لمرحلة رئيسية حقيقية. عندما لا يعرف الفريق متى تحتاج المنتج بالضبط، ما الذي يجب أن يكون جاهزًا بحلول ذلك التاريخ، ولماذا، فيبدأ العمل ضدك. التركيز هنا على "لماذا". بالنسبة لمعظم أصحاب الأعمال، من الصعب الإجابة على هذا السؤال. لماذا تحتاج أن يكون المنتج جاهزًا بحلول الأول من حزيران؟ لأنّك سئمت من الانتظار فقط؟ هذه ليست إجابة معقولة. أنت سئمت من ذلك ولكن لا يزال لديك أموالًا في حسابك المصرفي. سيستمرون في إصدار الفواتير لك، ولن يحترمونك. لن يعاملوك كرجل أعمال قوي وموجّه نحو تحقيق الأهداف. إمّا أنّك لست ذكيًا بما يكفي لتحديد القيود الزمنية أو أنّك تخفيها عن الفريق. في كلتا الحالتين لن يقدّروا هذا السلوك. فيما يلي تحديد قيود الوقت والتكاليف بشكلٍ صحيح: يجب أن تكون الميزات A و B و D جاهزة قبل الأول من حزيران، لأنّ حملتنا التسويقية تبدأ في الخامس من حزيران. إذا لم يكونوا جاهزين، سأخسر 25000$ من تكاليف التسويق. إذا حدث هذا سأضطر إلى تخفيض ميزانية التطوير الشهرية إلى النصف. عندما تسمع شركة الاستعانة بفريق خارجي لتطوير البرمجيات، شريكتك، هذا التعريف للموعد النهائي، تصبح شريكًا حقيقيًا لك الآن. الآن أهدافها تتماشى مع أهدافك. إذا تمّ تأخير المرحلة الرئيسية، ستعاني وسيفهمون لماذا بالضبط. إلى جانب ذلك، يرون كيف ستُنقل معاناتك إليهم أيضًا. توقف عن مطالبتهم بإنهاء كل شيء بأسرع وقت ممكن. توقف عن الاتصال بهم مرتين في اليوم والصراخ لساعة بسبب أدائهم الضعيف. توقف عن استخدام اللغة في رسائل البريد الإلكتروني للعمل. توقف عن القيام بكل هذا الضجيج. إنّه لا يساعدك على أيّ حال. علاوةً على ذلك، لا يؤدي هذا إلا إلى جعل الوضع يزداد سوءًا، لأنّك تفقد احترامك وقد بدأوا في معاملتك كبقرةٍ حلوب - بل بالأحرى شخص غبي وعاطفي. بدلًا من ذلك، قم بأداء واجبك وحدد مراحلك الرئيسية الواقعية. فكّر بوقتك الحقيقي، ومجالك، وحدود ميزانيتك. دوّنهم بجمل قصيرة ومختصرة جدًا. تأكّد من أنّ قيودك واقعية ووصفها يجيب على السؤال الرئيسي - لماذا -. لماذا تحتاج هذا بحلول الأول من حزيران؟ لماذا تريد أن تنفق أقل من 50000$؟ لماذا تحتاج أن تكون كل الميزات الخمسة موجودة في النسخة 1.0؟ لماذا تريد لتطبيق الويب الخاص بك أن يكون جاهزًا لمعالجة 1000 جلسة متزامنة؟ لماذا تحتاج إلى تطبيق للهاتف في الإصدار الأول؟ أجب نفسك وتأكّد من أنّ أجوبتك مفهومة من قبل شركة الاستعانة بفريق خارجي. لا تخفي هذه المعلومات. المنتج سيء جدًا تريد أن يبدو تطبيق الويب الخاص بك مثل Pinterest، يتفاعل سريعًا، ويكون سهل الاستخدام، ويجعلك فخورًا عندما تعرضه على أصدقاءك. لكن المنتج الذي بنوه لك سيء، وبطيء، ولأكون صريحًا، قبيح. تطلب منهم أن يفعلوا شيئًا ما بشأنه، ويستمروا في إعطائك الوعود. يستمر المشروع في استهلاك أموالك وتنمو ميزانيته، لكن المظهر والإحساس لا يتحسّن. إنّه بعيد جدًا عن Pinterest. ينمو الإحباط ولا تشاهد أي طريقة معقولة للخروج من هذا. النصيحة الوحيدة التي تتلقاها من أصدقائك هي أن تعيد تنفيذ كل المشروع من الصفر مع فريق تطوير ويب جديد. كيف يبدو هذا؟ أراهن أنّه مألوفًا. أعتقد أنّ السبب الرئيسي للطريق المسدود في هذا الموقف هو الخوف من الصراع. تحاول في المراحل الأولى من المشروع أن تفعل كل ما تستطيع للحفاظ على علاقة جيدة مع شركة الاستعانة بفريق خارجي وعدم الإساءة إلى أيّ شخص. لا تريد أن تتحكم في عمل أي شخص لأنّهم قد يعدونها إهانة. لا تريد أن تعبّر عن مخاوفك بشأن الجودة لأنّها قد تثبّط همّة الفريق. أنت فقط تأمل أنّهم سيحسّنون المنتج في المستقبل، لكن عندما يأتي المستقبل، يكون متأخرًا جدًا. مجددًا، مع أخذ المبدأ القديم بعين الاعتبار، أنصحك بأن تقوم بإجراء روتيني من اليوم الأول للمشروع للتحقق من نتائجهم والتعبير عن مخاوفك. في مشاريعنا في Zerocracy نطلب من عملاءنا أن يكونوا موجودين في GitHub، ويراجعوا إصداراتنا بشكلٍ متكرر، ويبلغونا عن أيّة تناقضات موجودة كمشكلات (issues) في GitHub. نشجّع رعاة المشروع أن يكونوا متشائمين وسلبيين بشأن جودتنا منذ بداية المشروع. نحن ندرك أن هذه الطريقة يمكننا بها تقليل خطر "الإحباط المتراكم". حاول أن تفعل الشيء ذاته في مشروعك الذي تمّ به الاستعانة بفريق خارجي. لا تخف من الإساءة إليهم. النقد التكراري والتدريجي منهجية أكثر صحةً من السلام الخالي من ردود الفعل والذي ينتهي بالحرب. ابحث عن طريقة ليبقى الفريق المستعان على درايةٍ برأيك حول نتائجه بشكلٍ منتظم. لا تحاول أن تكون لطيفًا لتحافظ على مشروعك.أنت تقدّم لنفسك معروفًا سيئًا. بدلًا من ذلك، كن منفتحًا بشأن مخاوفك. تذكر الجزء الأول من المبدأ أعلاه - يجب عليك أن تناقش مخاوفك بشكلٍ علني ومتكرر. هذه هي الطريقة التي سيستقر بها المشروع وتقلّ بها المخاطر. أيضًا، هناك ممارسة جيّدة جدًا، من وقت لآخر، وهي دعوة المراجعين التقنيين ليعطوا آراءً مستقلة حول المنتج قيد التطوير. اقرأ مشاركتي الأخرى حول هذا الموضوع: هل تحتاج لمراجعات تقنية مستقلة؟. لا يمكنني الاعتماد على وعودهم تتصل بهم، وتضعون الخطط، وتوضّحون المراحل الرئيسية، وتعرّفون الميزات، وتحددون الأولويات، وتتفقون على الجودة، ثمّ تنهي الاتصال. خلال أيّام قليلة، تدرك أنّه كان مضيعة للوقت. إنّهم لا يحافظون على وعودهم لأنّ هناك دائمًا شيء ما جديد يحدث. شخصٌ ما مريض، خادمٌ معطل، بعض أجزاء البرنامج غير صالحة للعمل، بعض الشيفرة لم تعد تعمل، وما إلى ذلك. تتصل مجددًا، تعبّر عن إحباطك، وتوجّه اتهامات قوية، وتعيد هيكلة المراحل، وتعيد تعريف الميزات، وتعيد تحديد الأولويات، وخلال عدّة أيّام تبدأ من جديد. كنت هناك، وقمت بذلك؟ هل يبدو هذا مألوفًا؟ من خلال تجربتي، فإنّ سبب عدم القدرة على التنبؤ وعدم موثوقية الفريق الخارجي في معظم الحالات هو راعي المشروع. يحدث هذا عندما لا تستمع إليهم أو يخشون أن يقولوا لك الحقيقة، والذي هو عادةً نفس الشيء. يطلق البعض على هذا "التطوير المُقاد بالخوف". يخاف الفريق منك، ولكي يحتفظ الفريق بك كعميل يدفع له المال، يضطر أن يكذب عليك. في الأساس، يخبرونك بما تريد أن تسمعه - أنّ نهاية المشروع قريبة، والأخطاء الموجودة حاليًا سهلة الإصلاح، وأنّ مشاكل الأداء بسيطة، وأنّ جودة المعمارية رائعة، وأنّ الفريق متحمس جدًا للعمل معك. عندما تسمع أي مما سبق، اسأل نفسك - هل تشجعهم على قول الحقيقة؟ هل تكافؤهم على إعطائك أخبارًا سيئة لكن صادقة؟ بالإشارة إلى المبدأ الأساسي المذكور أعلاه، مجددًا، أنصحك بالتأكد من أنّ منطقك في المكافآت والعقوبات شفاف لشريكك، الفريق الخارجي، ويستند إلى أهداف المشروع، وفقًا للمبدأ الأساسي وليس لمشاعرك الشخصية. في إحدى منشوراتي السابقة، كتبت أنّ العميل السعيد هو هدف خاطئ لفريق تطوير البرمجيات. العميل الذي يدعم هذا الهدف هو عميل رهيب محكوم عليه بفشل المشروع. إذا كافأت فريقك عندما يُشعرك بالسعادة بالأخبار الجيّدة، فأنت تدرّبهم على الكذب عليك. إذا كنت تتوقع منهم أخبارًا جيّدة، فأنت لا تشجعهم على إخبارك بالحقيقة وعلى القيام بما هو جيّد للمشروع، ليس لك شخصيًّا. أنت لا تشجعهم على الجدال معك. بكلماتٍ أخرى، أنت تخنق قناة المعلومات التي من المفترض أن تأتي إليك من الأشخاص الذين يعملون معك. أنت تعزل نفسك، والفريق بدأ بالعمل ضدك، ليس معك. إليك نصيحةً عمليّةً. أولًا، أعلن عن أهدافك وقيودك المعقولة بانتظام، كما شرحت أعلاه. تأكّد من فهم الفريق لخطط عملك و"لماذا" الأسباب الكامنة وراءها. ثانيًا، اسأل أعضاء الفريق بانتظام عن المخاطر والمشاكل. اسألهم لماذا يعتقدون أن أهداف المشروع قد تتعرض للخطر. ومن الأفضل أن تدعهم يوثّقوا المخاطر بانتظام ويبلغوك بها. كافئهم على صدقهم في قائمة المخاطر هذه. جرّب ذلك وستُفاجأ بعدد الأشياء المثيرة للاهتمام التي ستتضمنها قائمة المخاطر. ترجمة -وبتصرف- للمقال How to Avoid a Software Outsourcing Disaster لصاحبه Yegor Bugayenko

إنّ ما ترغب فيه عندما تحتاج إلى إنشاء منتج برمجي ولكن خبرتك في هندسة البرمجيات محدودة هو التعهيد الخارجي للبرمجيات. إنها ممارسة تجارية ذكية يستخدمها الجميع بدءًا من أصحاب الألف دولار الذين يملكون مواقع الويب الشخصية وانتهاء بأصحاب الثروات الكبيرة؛ وكلهم يفشلون إلى حد ما. في الواقع، من الصعب جدًا أن لا تفشل. لذا أعددت فيما يلي قائمة من التلميحات البسيطة لكل من يقرّر التعهيد الخارجي لتطوير البرمجيات (يوجد أهمها في الأسفل). ولكم تمنيت لو أن شخصًا ما قد أعطاها لي منذ 15 عامًا. لتكن لديك اتفاقية "العمل مقابل أجر" تأكد من أن العقد الذي أبرمته مع الفريق المُتعهِّد لإنشاء البرامج يشتمل على شيء من هذا القبيل: "يجب على الأطراف اعتبار جميع التسليمات التي أنشأها المطور بمثابة أعمال أُنجِزت للتأجير كما هو محدد بموجب قوانين حقوق الطبع والنشر". هذا هو التعريف المختصر والسهل لعبارة "كل ما تنجزه لي هو ملكي". ضع هذا في العقد ولن تستطيع شركة التعهيد الخارجي ادعاء أن البرنامج الذي أنشأته مِلكها، وهو ما يحدث هنا وهناك. احرص على امتلاك مستودعٍ خاصٍّ بك للشيفرة المصدرية تأكد من أن مستودع الشيفرة المصدرية تحت سيطرتك. وأفضل طريقة للقيام بذلك هي إنشاء مستودع GitHub خاصٍّ. سيكون المخزون مرئيًا ولا يمكن الوصول إليه إلّا من خلالك أنت وفريق التعهيد الخارجي. علاوة على ذلك، تأكد من أن الفريق لديه صلاحية القراءة فقط ولا يمكنه تغيير الشيفرة مباشرة إلا من خلال طلبات السحب (pull requests)، لأن Git يتيح إمكانية تدمير السجل بأكمله بضغطة واحدة "قسرية" على الفرع الرئيسي (master branch). لذلك سيكون من الأفضل لك أن تكون الشخص الوحيد الذي لديه صلاحية الكتابة. لجعل الأمور أكثر بساطة، أنصحك باستخدام Rultor كأداة لدمج طلبات السحب هذه بشكل شبه تلقائي. اجمع الإحصائيات بانتظام اطلب من أعضاء فريق التعهيد الخارجي جمع الاحصائيات بانتظام من البرنامج الذي يقومون بإنشائه وإرسالها إليك بطريقة أو بأخرى (عبر البريد الإلكتروني ربما). أنصح باستخدام Hits-of-Code ومدى تغطية اختبارات الوحدة (أو فقط إجمالي عدد اختبارات الوحدة) والتذاكر المفتوحة والمغلقة ومدة الإنشاء. أنا أتحدث هنا عن مقاييس عملية. وهو ما لن تحصل عليه فعليًا باستخدام أدوات أخرى مثل NewRelic. ستحدّد هذه المقاييس أداء الفريق، وليس المنتج قيد التطوير. لا أقول أنه يجب عليك إدارة الفريق من خلال المقاييس، ولكن عليك أن تراقب هذه الأرقام وديناميكيتها. إجراء مراجعات فنية مستقلة تتجلى أهمية هذه المراجعات في صعوبة تضخيمها أو التحايل فيها. إنها حاسمة بشكل استثنائي عندما يتعلق الأمر بالتعهيد الخارجي للبرمجيات. في الواقع، هذه هي الطريقة الأفضل لجمع المعلومات الموضوعية عن البرنامج الذي تحصل عليه من جهة خارجية. لا تعتمد على التقارير والوعود والضمانات والتوثيقات الشاملة. بدلاً من ذلك، استأجر شخصًا آخر بنظام الساعة واطلب منه مراجعة ما يطوّره شريك الخارجي. قم بهذ المراجعات بانتظام وبشكل منهجي. لا تخف من الإساءة إلى المبرمجين، واشرح لهم بصراحة أهمية المراجعة بالنسبة لك. إذا كانوا مهنيين، فسوف يفهمون ويحترمون أهداف عملك. يمكنك أيضا أن تريهم هذه المقالة :-). أتمتة النشر والتحكم فيه اطلب من الفريق المُتعهِّد أتمتة آلية النشر بالكامل وإبقاءها تحت سيطرتك. وأنصح بأن تفعل هذا خلال الأيام الأولى للمشروع. هذا يعني أنه ينبغي تجميع المنتج واختباره وتعبئته وتثبيته ونشره في مستودع الإنتاج (أو على الخادم/الخوادم) بنقرة واحدة. ستحتاج بالطبع إلى إنشاء سكريبت لأتمتة سلسلة العمليات هذه ويجب على شريكك الخارجي أن يكتبه لك. ثم، عند بدء عملية التطوير، يُنفّذ السكريبت تلقائيًا في كل مرة يجري فيها تعديل جديد على المستودع الذي ينشر الإنتاج. المهم هنا هو أن تعرف كيفية عمل هذا السكريبت وكيفية تشغيله حتى تكون قادرًا على بناء منتجك ونشره بنفسك. اطلب إصدارات أسبوعية لبرنامجك لا تنتظر الإصدار النهائي؛ بل اطلب من الفريق المُتعهِّد إصدار نسخة جديدة كل أسبوع. بغض النظر عن مدى كثافة التطوير وعدد الميزات الجاري تنفيذها، من الممكن دائمًا تجميع نسخة جديدة وإصدارها. إذا كان التطوير مكثفًا فعلاً، فاطلب من فريقك استخدام GitFlow أو شيء مشابه لعزل فرع الإنتاج المستقر عن باقي الفروع. لكن احذر من طول الانتظار! احرص على رؤية برنامجك مجمّعًا ومنشورًا كل أسبوع، بدون استثناءات ولا أعذار. إذا لم يتمكن الفريق المُتعهِّد من تقديم ذلك لك، فهذا يدعوك للقلق وإلى تغيير شيء ما. وظِّف مديرًا تقنيًا تنفيذيًا (CTO) مستقلًا تُقدّم هذه النصيحة في الغالب للشركات الصغيرة أو الأفراد الذين يستعينون بفريق خارجي لتطوير البرمجيات ويعتمدون على خبراتهم مع الاستمرار في التركيز على تطوير أعمالهم. هذا ليس من الحكمة في شيء؛ يجب أن يكون لديك مدير تقني تنفيذي مستقل (CTO) يقوم بإبلاغك ويتحكم في كيفية عمل الفريق المُتعهِّد. ينبغي التعاقد مع هذا الشخص وفقًا لجدول دفع مختلف مع أهداف وشروط وأهداف مختلفة. في كثير من الأحيان، يحاول أصحاب الأعمال التذاكي في البرمجيات والتحكم في فريق البرنامج مباشرةً، ويتعلمون أساسيات لغة المصطلحات البرمجية ومبادئ DevOps، لكن هذا يقود حتمًا إلى الفشل. كن ذكيا، فأنت تقوم بتطوير الأعمال، سيكون تعاملك المباشر مع مدير التقنية CTO ويتولى هو توجيه الفريق المُتعهِّد ومراقبته؛ بحيث يرسل CTO لك التقارير عن سير العمل، ويرسل له أعضاء الفريق التقارير التقنية بدورهم. حدّد آليةً للمكافآت والعقوبات لا توجد إدارة بدون هذين المكونين الرئيسيين. ليس من المفترض أن تدير جميع المبرمجين في الفريق المُتعهِّد، بل عليك إدارة الفريق بأكمله كوحدة تحكم واحدة. عليك أن تمنحهم نوعًا من التحفيز. ينبغي أن يعرفوا ماذا سينالون إذا نجحوا وكم سيعانون إذا فشلوا. إذا لم توضح هذه الآلية، فستُضطر للتعامل معها ضمنيًا، إذ أن فرص الرّبح تكون منخفضة جدًا. يفترض معظم الناس أن أفضل حافز والحافز الوحيد لفريق البرمجيات هو استمراره في العمل على المشروع. أنت تدفع لهم وهذا يكفي، أليس كذلك؟ هذا خطأ. لا يمكن أن تكون الإدارة فعالة عندما يكون التحويل المصرفي الشهري بمثابة مكافأة وغيابها يعد عقابًا. إنه أسلوب فجّ، وهذا ما يجعله عديم الفعالية إطلاقًا. ابحث عن آلية أفضل وأكثر لباقة وبالتالي أكثر فعالية. لا تقض أكثر من شهر في المشروع يقول بعض الناس 12 أسبوعًا، وأنا أقول شهرًا، ولست وحدي من يقول ذلك. هل تعلم أن الإصدار الأول من Minecraft (الذي بِيعَ لاحقًا إلى Microsoft مقابل 2.5 مليار دولار) تم إصداره في غضون ستة أيام فقط؟ هناك العديد من الأمثلة الأخرى، بما في ذلك Uber و Dropbox و Buffer وغيرها. لقد عبّر إريك ريس في كتابه Lean Startup عن هذا المفهوم بعبارة "منتج الحد الأدنى القابل للتطبيق" (Minimum Viable Product وتختصر إلى MVP)، وأنا متأكد من أنك سمعت هذا الاختصار من قبل. إذا كان المطورون يعدون بتسليم المنتج في غضون بضعة أشهر، فهناك شيء ليس على ما يرام. ينبغي حتمًا أن تحصل على بعض البرامج العاملة في أقل من شهر وينبغي أن تكون جاهزًا للمستخدمين الذين يدفعون رسومًا حقيقية. لقد أنشأت معظم مشاريعي اللطيفة في أقل من أسبوع لكل منها. لا تدفع الرواتب سيريدون منك بطبيعة الحال أن تدفع شهريًا، بالإضافة إلى التأمين الصحي، وأجهزة الحاسوب، والإجازات، ومكتب مشمس لطيف. وهذا هو ما يمكن أن تضيع فيه مخططاتك، إذ أنك تجعلهم سعداء بينما تخسر أنت. عليك إيجاد طريقة لملاءمة أهدافك (تسليم MVP في أقرب وقت ممكن والبدء في جني الأموال) مع أهدافهم (شراء سيارة جديدة وقضاء الإجازة التالية على الشاطئ). هل تستطيع فعل ذلك؟ إنه أمر صعب. لهذا السبب أنشأنا Zerocracy، مما يجعل الفواتير التدريجية والدفع بالنتائج أمرًا ممكنًا. يمكنك إما نقل مشروعك إلى هذه المنصة وإدارة مطوريك هناك، أو ابتكار شيء ما بمفردك. ولكن تذكر، ليست هناك رواتب شهرية! تدفع فقط مقابل النتائج المقدمة. لا تدعهم يجربون يريد كل مبرمج ذكي استخدام مشروعك الجديد كإجراء اختبار لبعض التقنيات الجديدة. لا يحب الناس أن يكرّروا نفس الشيء الذي كانوا يفعلونه بالأمس، إلا إذا كانوا أغبياء ومملين. ولهذا، سيَنصح أعضاء فريقك غالبا باستخدام شيء جديد، قد يكون إطار عمل جديدًا أو قاعدة بيانات جديدة أو حلّ استضافة سحابية جديدًا أو أدوات نشر جديدة. إنهم يفعلون ذلك لأغراضهم الخاصة، وليس لمساعدة المشروع. لا تسقط في هذا الفخ وكن مصرًّا على استخدام ما لديهم من خبرة، على الأقل في مرحلة MVP. يمكنك أن تعدهم بحرية التجربة، ولكن في وقت لاحق عندما يتم إطلاق النسخة MVP. ترجمة -وبتصرف- للمقال Software Outsourcing Survival Guide لصاحبه Yegor Bugayenko

عندما تصون مستودعًا لمشروع مفتوح المصدر، فأنت تأخذ راية القائد، فلو كنتَ مؤسس أحد المشاريع التي أطلقتها للعموم ليستخدموها ويشاركوا فيها، أو كنت تعمل في فريقٍ وكنت تصون جانبًا من جوانب المشروع، فأنت تقدم خدمةً مهمةً إلى مجتمع التطوير. وعلى الرغم من أنَّ المساهمات في المشاريع مفتوحة المصدر تكون عادةً عبر طلبيات pull وهي أمرٌ بالغ الأهمية للحفاظ على جودة البرمجيات وفائدتها للمستخدمين النهائيين، لكن المساهمين في المشروع ليس لهم نفس تأثير من يقوم بصيانته ويبلور الشكل العام للمشروع؛ فالصائنون يشاركون في صلب تطوير المشاريع مفتوحة المصدر، إذ يديرون المشروع وينظموه يوميًا ويطوروه، ويتفاعلون مع المستخدمين ويوفرون المعلومات اللازمة للمساهمين. سنستعرض في هذا المقال بعض التلميحات عن صيانة المستودعات العامة للمشاريع مفتوحة المصدر. فالمسؤولون عن المشاريع مفتوحة المصدر عليهم مسؤوليات كبيرة تقنية وغير تقنية، والعمل كصائن للمشروع يعطي الفرصة للتعلم من الآخرين، وأخذ خبرة في إدارة المشاريع، ويسمح بمراقبة مراحل نمو المشروع وكيف أصبح المستخدمون العاديون مساهمين فعالين فيه. اكتب توثيقًا مفيدًا سيزيد التوثيق سهل الفهم (والذي سيؤدي إلى جعل البرنامج سهل الاستخدام) من قاعدة مستخدميك، ويساعد في تحويل المستخدمين إلى مساهمين في مشروعك. عندما تفكر بالشيفرات التي تكتبها أثناء تطويرك للمشروع، وتكتب بعض الملاحظات الجانبية لتساعدك في دمج مختلف أجزاء مشروعك مع بعضها بعضًا، فسيسهل عليك البدء بكتابة التوثيق أثناء عملية التطوير؛ أو ربما تقرر أن تكتب التوثيق قبل برمجة التطبيق، متبعًا بذلك منهجية «التطوير الموجه بالتوثيق» (documentation-driven development) التي تقول أنَّ عليك كتابة توثيق ميزات المشروع أولًا ثم برمجة تلك الميزات اعتمادًا على توثيقها. هنالك بضعة ملفات عليك وضعها في المجلد الرئيسي لمشروعك بجانب الشيفرات وهي: - ملف README.md الذي يوفر ملخصًا عن المشروع وأهدافه. - ملف CONTRIBUTING.md الذي يحتوي على تعليمات المساهمة في المشروع. - رخصة مشروعك، والتي ستشجِّع الناس على المساهمة في موقعك، أرجو أن تراجع مقالة كيف تختار رخصة مفتوحة المصدر لبرامجك. قد يأخذ التوثيق أشكالًا عدِّة، لذا عليك أن تضع نوعية المستخدمين المحتملين ومجال المشروع في الحسبان، فمن الممكن أن يأتي التوثيق بمختلف الأشكال ويكون موجهًا نحو فئات مختلفة من مستخدمي المشروع. قد تقرر استخدام شكل أو أكثر من الأشكال الآتية اعتمادًا على مجال عملك: دليل عام لتعريف المستخدمين بالمشروع الدروس التعليمية لعرض مختلف حالات الاستخدام الأسئلة الشائعة (FAQ) للإجابة عن أكثر التساؤلات شيوعًا بين المستخدمين مقالات عن استكشاف الأخطاء التي قد يواجهها المستخدمون وكيفية إصلاحها مرجع للواجهة البرمجية (API) للتطبيق تسمح للمستخدمين معرفة معلومات عن الواجهة البرمجية بسرعة ملاحظات الإصدار (release notes) التي تُذكَر فيها العلل المعروفة والتغييرات التي حدثت في كل إصدار الميزات المستقبلية لتتبع وشرح ما هي الميزات التي ستأتي في إصدارات مستقبلية. تسجيل مقطع فيديو لتعريف المستخدمين بمشروعك عبر الوسائط المتعددة. قد تلائم بعض أشكال التوثيق السابقة مشروعك أكثر من غيرها، لكن توفير أكثر من شكل للتوثيق سيساعد مستخدمي مشروعك أن يفهموا كيف يتفاعلون معك فهمًا أعمق. عليك عند كتابة التوثيق أو تسجيل مقطع فيديو أن تكون واضحًا قدر الإمكان، ومن الأفضل ألّا تكون عندك افتراضات مسبقة عن القدرات التقنية لمستخدمي مشروعك، ومن الأفضل أن تتبع منهجية Top-Down عند تأليف التوثيق، أي أن تشرح بداية الأمر ما الذي تفعله البرمجية بشكل عام (مثلًا: أتمتة أمور إدارة النظام، أو بناء موقع إلكتروني …إلخ.) قبل التعمق في التفاصيل. وصحيحٌ أنَّ اللغة الإنكليزية هي اللغة الرائدة في عالم التقنية، لكن أبقِ في ذهنك مَن هم المستخدمون المتوقعون وما هي لغتهم الأم؛ فاللغة الإنكليزية هي خيارٌ جيدٌ إذا كانت لديك قاعدة مستخدمين واسعة ومن مختلف البلدان، لكن ضع في بالك أنَّ عدد كبيرًا ممن سيقرؤون توثيقك لا تكون اللغة الإنكليزية هي لغتهم الأم، لذا حاول استخدام لغة سهلة لا تُسبِّب لبسًا عند القراء، وإذا كان مشروعك موجّه لمنطقة أو لغة معيّنة مثل برنامج للتعرف على الكلام العربي فأنصحك حينئذٍ أن توفر التوثيق باللغة العربية. حاول أن تكتب التوثيق كما لو كنتَ تكتب لأحد المساهمين الجدد الذين يريدون أن يطلعوا على حالة المشروع، فلا تنسَ أنَّك تريد أن يتحول المستخدمون العاديون إلى مساهمين. تنظيم «القضايا» القضايا (issues) هي طريقةٌ تستعمل لتتبع أو التبليغ عن العلل، أو لطلب ميزات جديدة لتضاف إلى البرنامج. توفِّر خدمات استضافة مستودعات المشاريع مفتوحة المصدر مثل GitHub و GitLab و Bitbucket طرائق لتتبع القضايا التي تُنشِئها وتسمح للمستخدمين بإنشائها. فمن المتوقع عند إطلاق مشروعك مفتوح المصدر أن تُفتَح عدِّة قضايا من قِبل مجتمع المستخدمين، لذا سيمثِّل تنظيم ووضع أولويات لهذه القضايا أمرًا مهمًا لتبيان خارطة الطريق لما عليك فعله للمشروع مستقبلًا. ولأنَّ أي مستخدم يستطيع أن يفتح قضية، فلن تكون جميع القضايا لتبليغ العلل أو لطلب الميزات، فقد تأتيك أسئلة عبرها، أو قد تأتي طلبات لتحسينات صغيرة على واجهة المستخدم مثلًا. فمن الأفضل تنظيم هذه القضايا في أفضل شكل ممكن ومحاولة التواصل مع المستخدمين الذين أنشؤوها. يجب أن تمثِّل القضايا مهامًا محددة عليك تنفيذها برمجيًا، لذا عليك تنظيمها حسب أهميتها. يجب أن يكون هنالك حدود للوقت والعمل الذي تنفقه أنت أو المساهمون في المشروع للقضايا المفتوحة فيه، ويمكنكم التعاون على اتخاذ القرارات والخروج بخطة قابلة للتنفيذ، وعندما تعلم أنَّك غير قادر على حل مشكلة معيّنة في الإطار الزمني المتاح لك، فيمكنك التعليق عليها وإخبار المستخدم أنَّك قرأت المشكلة وستفعل ما بوسعك تجاهها، وقد تستطيع أن تخبره بالوقت المتوقع للنظر في أمر هذه المشكلة مرةً أخرى. أما لطلبات الميزات أو التحسينات، فيمكنك أن تسأل الشخص الذي أنشأ القضية إن كان يستطيع المساهمة في الشيفرة لتطبيق هذه الميزة، يمكنك توجيه المستخدمين إلى ملف CONTRIBUTORS.md أو إلى أيّة صفحات أخرى من التوثيق. ولأن الأسئلة لا تمثِّل عادةً مهامًا محدَّدة، فالتعليق على السؤال لتوجيه المستخدم بلباقة إلى صفحة التوثيق هو خيارٌ ممتاز لإبقاء تفاعلك مع المستخدم احترافيًا ولطيفًا؛ وإذا لم يحتوي التوثيق على جوابٍ لهذا السؤال فحان الوقت لإضافة التوثيق الملائم، وتعبِّر عن شكرك للمستخدم لأنه دلّك على موضع النقص في التوثيق. إذا كنتَ تستقبل عددًا كبيرًا من الأسئلة عبر القضايا، فربما تفكر بإنشاء صفحة الأسئلة الشائعة (FAQ) في التوثيق، أو صفحات ويكي أو منتدى لتتيح للآخرين المساعدة والمشاركة في الإجابة عن الأسئلة. وفي كل مرة يبلِّغ فيها أحد المستخدمين عن مشكلة، فحاول أن تكون لطيفًا معه قدر الإمكان، فتفاعل المستخدمين معك يعني أنَّ المشروع قد أعجبهم ويريدون جعله أفضل. محاولة تنظيم القضايا ستجعل مشروعك محدثًا دومًا وسيشعر المستخدمون أنهم يأثرون فيه، لذا احذف القضايا التي تقع خارج نطاق مشروعك أو القضايا القديمة، وضع أولويات للبقية لكي يكون تقدمك في المشروع مستمرًا. حفِّز المساهمين كلما رحّبتَ بالمساهمين الجدد وكافأتهم على جهودهم لوجدت أنَّك تحفِّز مساهمين جدد ليشاركوا في مشروعك، ولكي تجذب المساهمين إلى المشروع فاحرص على تضمين ملف CONTRIBUTING.md في المجلد الرئيسي لمستودعك، وإشارة إلى ذاك الملف في README.md. إذا أردتَ كتابة ملف جيد للمساهمين الجدد فيجب أن يتضمن كيفية بدء العمل على المشروع كمطوِّر، فقد تكتب دليلًا يوضح ذلك خطوةً بخطوة، أو قائمةً من الأمور التي يجب على المطورين اتباعها وتنفيذها، شارحًا كيف يمكن أن يدمجوا الشيفرة التي كتبوها بشيفرة المشروع عبر طلبية pull. إضافةً إلى توثيق كيفية المساهمة في المشروع، فلا تنسَ أن تبقي شيفرات المشروع منظمة وسهلة القراءة، فإذا كانت الشيفرة سهلة الفهم وفيها تعليقات كثيرة تشرح ما تفعله وطريقة استخدامها موحدة ومتناسقة مع بعضها بعضًا فسيساهم ذلك في تحفيز المساهمين المحتملين على المشاركة في المشروع. أقترح أيضًا أن تبقي على قائمة بالمساهمين، فيمكنك أن تجذب المساهمين عبر إضافتهم إلى القائمة بغض النظر عن حجم مشاركتهم (حتى تصحيح الأخطاء اللغوية هو مشاركة ومساهمة فعالة في المشروع، ويمكن أن تؤدي إلى مزيدٍ من المساهمات مستقبلًا). وهذا يعني أنَّك تقدِّر عمل المساهمين في المشروع وتشير إليهم أمام جميع مستخدمي مشروعك، مما يحمِّس بقية المستخدمين على المشاركة. ابنِ مجتمعًا حول مشروعك بتمكين مستخدميك عبر التوثيق وبالتجاوب مع القضايا وبتحفيزهم للمشاركة، فأنت في طريقك لبناء مجتمع حول مشروعك المفتوح المصدر، فالمستخدمون السعيدون بتجاوبك معهم والذين تعدُّهم على أنهم مساهمون سيحاولون الترويج مشروعك ما استطاعوا. إضافةً إلى ما سبق، يمكنك الترويج لمشروعك بمختلف السبل: التدوين تسجيل ونشر فيديوهات تعريفية إنشاء قائمة بريدية النشاط على مواقع التواصل الاجتماعي التعاون مع المشاريع الشبيهة أو المتعلقة بمشروعك والترويج لها. عليك أن تُناسِب ترويجك للمشروع مع مجاله وعدد أعضاء الفريق الفعالين والمساهمين الذين يعملون معك. فعندما ينمو المجتمع حول مشروعك، فيمكنك أن توفِّر مساحة أكبر للمساهمين والمستخدمين والقائمين على المشروع ليتفاعلوا، بعض تلك الخيارات تتضمن: برمجيات الويكي التي توفِّر توثيقًا مصانًا من المجتمع المنتديات لمناقشة الميزات المحتملة وللإجابة على الأسئلة قائمة بريدية للتفاعل مع المجتمع عبر البريد الإلكتروني ضع ببالك قاعدة مستخدمي مشروعك ومجاله بما في ذلك عدد الأشخاص القائمين عليه والموارد المتاحة لك قبل أن تتوسّع في المجالات السابقة، واستشر مجتمعك عن الخيار الأفضل قبل الإقدام عليه. وأهم من ذلك كله أن تكون لطيفًا معهم وتريهم أنَّك تهتم بهم عبر تفاعلك معهم، أعلمُ أنَّ الاتسام بصفة اللباقة طوال الوقت ليس أمرًا سهلًا، لكن ستؤتي أُكلها على المدى البعيد. الخلاصة يلعب صائن المستودع دورًا مهمًا في مجتمع البرمجيات مفتوحة المصدر الكبير. وصحيحٌ أنَّ هذا الدور يأخذ وقتًا وعملًا كبيرًا، لكن الخبرة التي تكتسبها خلال هذا العمل ستفيدك كمطوِّر وكمساهم، ولا تنسَ أنَّ الصائن اللطيف واللبق سيساعد في دفع عجلة تطوير المشروع الذي يهتم لأجله. ترجمة –وبتصرّف– للمقال Maintaining Open-Source Software Projects لصاحبته Lisa Tagliaferri. حقوق الصورة البارزة محفوظة لـ Freepik

كما سبق ذكره فإن أحد أهم الاختلافات ما بين Git وأنظمة إدارة النُسخ هو الطريقة التي ينظر ويتعامل فيها Git مع البيانات. مبدئيا تقوم أغلب أنظمة إدارة النُسخ بحفظ البيانات على شكل قائمة من التغيرات التي طرأت على الملفات. هذه الأنظمة (CVS, Subversion، Perforce، Bazaar وهلم جرا) تنظر إلى البيانات التي تقوم بإدارتها على أساس أنها ملفات إضافة إلى التغييرات الحاصلة في كل ملف مع مرور الوقت، مثلما هو مُوضح في الشكل 1. الشكل 1: تقوم مُعظم الأنظمة بحفظ البيانات على هيئة الاختلافات الطارئة عليها مُقارنة بنسخة أولية من الملف. لا يتعامل Git مع البيانات على هذا النحو، بل يعتبر البيانات مجموعة من اللقطات Snapshots لنظام ملفات مُصغر. كل مرة تقوم فيها بإيداع البيانات (commit) أو تحفظ حالة مشروعك باستخدام Git، فإن ما يقوم به النظام هو التقاط صورة لما هي عليه الملفات في تلك اللحظة ويحفظها. ولجعل هذه الآلية فعالة فإنه لا يتم حفظ صور أخرى لنفس الملف ما إذا لم يتم إحداث تغييرات على الملف، بل يتم فقط الربط على الصورة السابقة. ينظر Git إلى البيانات التي يحفظها مثلما هو مُبين في الشكل 2. الشكل 2: يلتقط Git صورا على المشروع مع مرور الوقت. يُعتبر هذه الاختلاف في مبدأ العمل جوهريا، حيث يُعيد Git بشكل جذري تعريف كامل المفاهيم المُتعلقة بإدارة النُسخ التي توارثتها باقي الأنظمة عن الأنظمة التي سبقتها. هذا الاختلاف في مبدأ العمل يجعل Git أقرب ما يكون من نظام ملفات مُصغر منه إلى أنظمة إدارة النُسخ التقليدية، وهو ما مكّن من بناء أدوات في غاية القوة اعتمادا عليه. سنقوم باستعراض الفوائد المُترتبة عن مبدأ عمل Git المُختلف عن باقي الأنظمة لدى الحديث عن تفريعات Git في مقال لاحق. أغلب العمليات تتم بشكل محلي أغلب العمليات التي يقوم بها Git تحتاج فقط إلى ملفات محلية ليتم تنفيذها وذلك من دون الحاجة إلى أية بيانات من خواديم بعيدة. هذه الخاصية تُعطي الانطباع بأن Git سريع جدا مُقارنة بغيره من أنظمة إدارة النُسخ نظرا لكون كامل ملفات وتاريخ المشروع الذي تعمل عليه مُتوفرة بشكل محلي على خلاف باقي الأنظمة التي تحتاج إلى الاتصال بأجهزة وخواديم أخرى. فعلى سبيل المثال فحتى ولو احتجت إلى إلقاء نظرة على تاريخ المشروع أو مقارنة نسخ قديمة منه فإنك لن تحتاج إلى الاتصال بخادوم بعيد للقيام بذلك حيث يقوم Git بقراءته والاحتفاظ به كاملا على جهازك المحلي. هذه الخاصية تسمح لك أيضا بمواصلة العمل على مشروعك حتى ولو لم يكن لديك اتصال إنترنت، حيث يُمكنك إيداع البيانات commit في انتظار أن يكون بمقدورك الاتصال بالإنترنت من جديد. على باقي أنظمة إدارة الإصدارات، مواصلة العمل لدى انقطاع الإنترنت هو إما أمر مُستحيل أو معقد جدا. على نظام Perforce لا يُمكن القيام بأي شيء ما لم تكن مُتصلا بالخادوم الذي يدار عليه المشروع، أما Subversion وCVS فيسمحان لك بتحرير الملفات لكن لا يُمكن إدراج التغييرات ما لم تكن متصلا بخادوم مشروعك. قد لا تبدو هذه الخاصية مُهمة جدا لكن تأثيرها كبير. المحافظة على سلامة الملفات يتم التحقق من الملفات عبر عمليات checksum قبل حفظها، ومن ثم يتم استخدام ناتج هذه العملية (Cheksum) كمُعرف للملفات، يعني ذلك بأنه يستحيل تغيير مُحتوى ملف أو مُجلد من دون أن يعلم Git بذلك. هذه الخاصية هي إحدى الخواص التي بُني عليها Git والتي يعتمد عليها في الطبقات السُفلى من النظام، كما أنها جزء لا يتجزأ من المبادئ الأساسية التي بُني عليها. بفضل هذه الخاصية فإنه من غير المُمكن أن تفقد أية بيانات لدى نقلها أو أن يُصاب ملف ما بالعطب من دون أن يكون هناك لدى Git علم مُسبق بالأمر. يُطلق على الآلية التي يعتمد عليها Git للتحقق من الملفات اسم SHA-1 hash، تنتج عنها سلسلة نصية مُتكونة من 40 محرف ستعشري (الأرقام من 0 إلى 9 والحروف من a إلى f) ويتم حسابها اعتمادا على مُحتوى الملف أو المُجلد. سلاسل SHA-1 hash تكون مُشابهة للسلسلة التالية: 24b9da6552252987aa493b52f8696cd6d3b00373 لدى استخدامك لنظام Git ستشاهد هذه السلاسل في كل مكان بحكم أنه يتم استخدامها كثيرا حيث أن Git يحفظ كل شيء اعتمادًا على Hash مُحتوى كل ملف وليس اعتمادًا على أسمائها. لا يقوم Git عادة سوى بإضافة بيانات أغلب العمليات التي تقوم بها على Git تقوم بإضافة بيانات إضافية إلى قاعدة بيانات Git. من الصعب جدا أن تجعل النظام يقوم بعمليات لا يُمكن التراجع عنها أو حذف بيانات لا يُمكن استرجاعها. لدى استخدام باقي أنظمة إدارة النسخ فإنه من المُمكن أن تخسر أو تعبث ببيانات لم تقم بإدراجها بعد، لكن لدى القيام بعملية إدراج فإنه من الصعب جدا أن تفقدها خاصة ما إذا كنت تقوم بدفع البيانات إلى مستودع موجود على خادوم بعيد. هذا الأمر يجعل استخدام Git مُمتعا في حد ذاته، حيث أنه بإمكاننا القيام بأية تجارب نودها على مشاريعنا دون أن نعرض بياناتها للخطر. الحالات الثلاث للبيانات على Git إن قرأت ما سبق ذكره على عجل، فيجب أن تركز جيدا في هذه الفقرة حيث أننا سنناقش المبدأ الأساسي الذي لا يُمكن لك استخدام Git ما لم تستوعبه جيدا. لدى استخدام Git فإن الملفات تملك إحدى الحالات الثلاث التالية: مرحلة الإيداع (ملفات تم إيداعها committed)، مرحلة التعديل (ملفات أجريت تعديلات عليها modified) ومرحلة الإدراج (ملفات تم إدراجها staged). المقصود بالإيداع commit هو أن حفظ البيانات بشكل آمن في قاعدة البيانات المحلية. الملفات التي تم تعديلها هي التي تم إدخال تغييرات عليها لكنه لم يتم حفظ تلك التغييرات إلى قاعدة البيانات المحلية بعد. أما الإدراج فهو تعليم الملفات التي تم تعديلها في حالتها الحالية ليتم تضمينها في الإيداع القادم. هذه الحالات الثلاث تُقسم مشاريع Git إلى 3 أقسام: مُجلد Git، مُجلد العمل، ومنطقة الإدراج. الشكل 3: مُجلد Git، مُجلد العمل ومنطقة الإدراج مُجلد Git هو المكان الذي يقوم النظام فيه بتخزين البيانات الوصفية metadata وقاعدة بيانات مشروعك، ويُعتبر الجزء الأهم من Git حيث أنه المُجلد الذي يتم نسخه لدى القيام بعملية استنساخ المُستودعات الموجودة على أجهزة أخرى. مُجلد العمل عبارة عن إصدار المشروع الحالي والذي يحتوي ملفات تم استخراجها من قاعدة بيانات Git ووضعها تحت تصرفك لإدخال التعديلات التي ترغب فيها عليها. منطقة الإدراج عبارة عن ملف واحد يتم الاحتفاظ به عادة داخل مُجلد Git والذي يحفظ معلومات حول المُحتوى الذي سيتم إرساله في الإيداع القادم. عادة ما تتم الإشارة إليه باسم الفهرس index لكن استخدام مُصطلح “منطقة الإدراج” staging area أصبح الأكثر شيوعا. سير عمل مشاريع Git يتم عادة على النحو التالي: التعديل على الملفات الموجودة في مُجلد العمل. إضافة الملفات إلى منطقة الإدراج إيداع الملفات commit، أي التقاط صورة عن الملفات الموجودة في منطقة الإيداع وحفظها بشكل دائم داخل مُجلد Git. لتلخيص الأمر: إذا كان الملف موجودا داخل مُجلد Git فهذا يعني بأنه تم إيداعه committed. إذا تم إدخال تغييرات عليه وتم وضعه في منطقة الإيداع فهذا ملف مُدرج staged. أما إذا تم إحداث تغييرات عليه ولم يتم نقله إلى منطقة الإدراج فيُعتبر مُعدّلا. في مقال قادم سنتحدث بشكل أوسع حول الحالات الثلاث هذه وكيفية الاستفادة منها بشكل جيد، إضافة إلى كيفية تجاوز منطقة الإدراج بشكل كامل. ترجمة -وبتصرف- لـ Git Basics من كتاب Pro Git لصاحبه Scott Chacon.

هل سبق لك وأن اتّصلت بإحدى الشّركات الكبيرة ( كمزوّد خدمة الإنترنت الخاص بك، أحد شركات بطاقات الائتمان، أو paypal) لتطلب المساعدة في حلّ مشكلةٍ ما ؟ في البداية تسمع صوتًا لطيفًا آليًّا يخبرك أنّك عميلُ الشركة العزيز الذي يهمّهم رضاه. ثم يسألك ذلك الصّوت عن المشكلة التي تواجهها, فتقول مثلًا "أواجه مشكلة في الاتصال بالإنترنت". فيرد عليك "عذرًا. 'وجه شكل الإنترنت' خيار خير صحيح". تضغط على الرقم 0 لعدّة مرّات، ثمّ تجرّب الضغط على (*) لعدّة مرّات لكنّ الصوت الآليّ الوَدود يخبرك مجددًا أنّها خياراتٌ غير صالحة. تقول الآن بصوتٍ مرهق "أرغب في الحديث إلى الدعم الفني". فيرد عليك الصوتُ الآلي "'راغب الحدث الفني' خيار غير صحيح". تفكّر في ترك التعامل مع هذه الشركة، لكنّك تخشى أن تتعرّض لتجربةٍ أسوأ من هذه مع شركةٍ أخرى فتتراجع عن هذا القرار. وبعد أن تفقد الأمل، تقوم بالبحث حلٍ لمشكلتك في جوجل، أو تطلب المساعدة على أحد مواقع التواصل الاجتماعي. هذا النوع من التجارب هو ما يخطر ببال روّاد الأعمال عندما يفكّرون في أَتمتَة (automate) شيءٍ من أعمالهم/مهامّهم: التواصل مع العملاء بطريقةٍ آليّةٌ مصطنعةٌ لا تُرضيهم أو تساعدهم. لكن المثال الذي ذُكر أعلاه مثالٌ على القيام بالأتمتَة (automation) بطريقةٍ خاطئةٍ بالكامل (إلا إذا كان هدفُك هو إغاظة العميل وخسارة رضاه، في هذه الحالة أقترح عليك أن تحاكي هذا المثال بالضّبط). في الواقع، أقوم بأتمتة معظم مهام مشاريعي التّجارية. ليس لديّ خيارٌ آخر، فأنا أُدير أعمالي كمستقل، إضافة إلى 4 كورسات، مدوّنتين صوتيّتين، بعض قوائم البريد الإلكتروني وأكثر- في الوقت نفسه، بنفسي وبدون مساعدةٍ من أحد. لكن على عكس المثال السّابق، أؤتمت أعمالي بشكل لا يسبب إزعاجًا لأي من زبائني. عندما تسجّل في القائمة البريديّة على سبيل المثال، سيتم الترحيب بك برسالةٍ تعبّر لك عن امتناني في قالبٍ جاهز فيه اسمُك. ستعرفُ أنّني لم أكتب هذه الرسالة خصيصًا لك أنت، لكنك لن تنزعج أيضًا من ذلك – كما أتمنى- لأنني قمتُ بأتمتَة تلك الرسالة. وفقًا للدراسات فإنّ 75% من الناس يتوقّعون تلقّي رسالةً ترحيبية عندما يشتركون في نشرةٍ (newsletter) عبر البريد الإلكتروني. ومن وجهة نظر تسويقيّة، تزيد الرسائل الترحيبية العائدات بنسبة 320% أكثر من الرسائل الدعائيّة الأخرى. يقوم أغلب النّاس بأتمتة رسائل الترحيب بمشتركي قوائمهم البريدية الجدد دونَ أي يعوا أنهم في طور عمليّة الأتمتة بالفعل. إذا قمت بأتمتة تلك الرسائل الترحيبيّة بشكلٍ صحيحٍ يتّسق مع هويّتك وهويّة شركتك وبطريقةٍ تُرضي العميل، فسيعود ذلك عليك وعلى نشاطك التّجاري بعائدٍ إيجابي. تعمل الأتمتة بصفتها امتدادًا لهويّتك وهويّة شركتك. ولذلك، فإنها يجب أن تكون بطريقتك الخاصّة وبنبرتك المميّزة، وليس كما تقوم به بعض الشّركات الكبيرة: " عميلُنا العزيز، من فضلك انتظر لمئتين دقيقة حتى تتلقّى ردًا جاهزًا مقَولبًا وغير مفيد". يمكنك أيضًا -بجانب الرسائل الترحيبية- أن تقوم بأتمتة رسائل ذات محتوى مسلٍّ كقصصٍ ممتعة أو شيء من هذا القبيل. قمت بأتمتة معظم مهام عملية تهيئة المستخدمين الجدد للعملاء الجدد في موقعي الخاص بتصميم مواقع الويب. وقد وفّر ذلك عليّ ساعاتٍ من العمل أسبوعيًّا ولم يؤثّر سلبًا -ولو بنسبةٍ بسيطة- على نسبة العملاء المُحتملين الذين قاموا بتوظيفي. باستخدام أدواتٍ مثل Zapier، تستطيع أن تقوم بالأتمتة بذكاءٍ وسهولة، ومن دون الحاجة لكتابة أي سطر برمجي. أستخدمُ Zapier مثلًا لإرسال رسالة أوتوماتيكيًّا كلما فشلت عملية الدّفع مُقابل أحد الكورسات التي أبيعها. هذا يحدث لعدّة مرّات في الأسبوع، لكنّني إن لم أفعل شيئًا حيال فشل تلك التحويلات، سأقوم بخسارة الكثير من أرباحي. ولذلك بدلًا من عدم فعل شيء حيال فشل الحوالات البنكيّة وتمنّي أن يحاول العميل الدفع مرّةً أخرى، أستخدمُ Zapier لأرسل له رسالةً مفادُها أنّه لم يكن الخطأ خطأه، مع بعض التعليمات التي تشرح كيفية الدفع باستخدام وسائل أخرى. تُرسل الرسالة في غضون ثواني من فشل التحويل. تُرسَل من عنوان بريدي الإلكتروني وتُكتب بنفس الطريقة التي أكتب بها الرسائل الشخصية (بدون أحرف كبيرة، بأسلوبي، وبتوقيعي الاعتيادي). ليس عليهم أن يتواصلوا معي مباشرةً لطلب المساعدة، وليس عليهم أن ينتظروني حتى أستيقظ (إذا كانوا يحاولون الدّفع الساعة الثالثة بعد منتصف الليل). يتم التواصل معهم على الفور برسالةٍ لطيفة مع بعض الخطوات البسيطة لحل المشكلة. ربّما تتفاجأ عندما تعلم أنّ هذه الرّسالة لها معدّل نجاح يبلغ 96%. أستخدمُ أيضًا قائمتي البريديّة لأتمتة كل ما يتعلّق بالكورسات التي أقدّمها. قيامي بذلك يسمح لي بإدارة عدد من الكورسات المختلفة مع العديد من الطّلاب في الوقت نفسه. أقدّم خيار فترة التجربة المجّانيّة في معظم كورساتي. فإذا كنت مهتمًا، يمكنك الحصول على بعض الدروس المجّانية عن طريق تسجيل بريدك الإلكتروني. أبدأ عن طريق الأتمتة بواسطة MailChimp في إرسال الرسائل أو الدروس مباشرةً - فينال العميل ما سجّل للحصول عليه على الفور وأرسله له المزيد من العيّنات المجّانيّة والمعلومات بشكلٍ يومي. أستخدم MailChimp أيضًا لاستثناء الطلّاب الذين قاموا بالتسجيل في الكورس والدّفع من الرسائل المؤتمتة التي تحتوي دروسًا مجّانية. مما يعني أنه إذا اشتريت الكورس في فترة التجربة المجّانية (التي تُرسل فيها رسائل مؤتمَتة) سوف تتوقف عن تلقّي تلك الرسائل على الفور. لقد قمتٓ للتوّ بشراء محتوى الكورس على كل حال، لذلك لست بحاجةٍ لتكدّس صندوق بريدك الإلكتروني بالرسائل التي تقدّم لك المحتوى المجّاني. ثم أقوم بإضافة العملاء الذين قاموا بشراء محتوى الكورس لقائمة بريدية أخرى (قائمة ما بعد الشراء). وهذا له عدّة فوائد: أن أريهم كيفية استعمال أدوات الكورس. أن أعلّمهم كيفية الوصول لكل المميزات والدروس التي يحتويها. أن أخبرهم عن كيفية الوصول لأقصى استفادة من محتويات الكورس عدد المشتركين في دوراتي 4000 طالب نٓشِط تقريبًا، وتأتيني رسالةٌ واحدةٌ فقط أسبوعيًا لطلب الدعم/المساعدة، وذلك لأنني أقوم بأتمتَة رسائل البريد الإلكتروني التي تشرح هذه الأمور. معظم الرسائل المؤتمتة التي أرسلها للعملاء بعد الشّراء تحتوي على آلية للتغذية الراجعة ، وذلك لأعرف ما هو رأي العملاء بالكورس الذي اشتروه، للتأكد من أنهم يستفيدون من الكورس بشكلٍ كامل ولأرى ما هي العوائد الإيجابيّة التي حصلوا عليها منه ( وهذه طريقةٌ رائعةٌ للحصول على شهادات التوصية testimonials وقصص النجاح ). يمكنك أيضًا أن تقوم بأتمتة ما يتعلّق بالتغذية الراجعة Feedback بشكلٍ مستقل باستخدام أدوات مثل Typeform لطرح الأسئلة وجمع الإجابات. الإمكانيّات والفوائد التي يمكنك الحصول عليها من أتمتة قائمتك البريدية والشؤون الأخرى في شركتك كثيرةٌ جدًا. وإذا استعملتَ الأتمتة بطريقةٍ صحيحة، فسيسعدُ عملاؤك لعنايتك بهم وباهتمامك الذي يحمل صٓبغةً شخصيّة، حتى وإن كان ذلك بطريقةٍ مؤتمتة. لا تنهج نَهج الشركات الكبيرة -التي تفشل غابًا في العناية بعملائها- في الأتمتة. يمكنك أن تستعمل الأتمتة لتكون امتدادًا لأسلوبك الشخصي المتفرّد ولكي تفيد وتساعد العملاء الذين يريدون ويحتاجون أن يتواصلوا معك ( حتى إن أرادوا ذلك في الساعة الثالثة صباحًا). ترجمة -وبتصرف- للمقال Make automation great again لصاحبه PAUL JARVIS. حقوق الصورة البارزة: Designed by Freepik.

وأخيرا اقتنعت بفلسفة المصادر المفتوحة، أو أنك أخيرا وجدت الوقت للمُساهمة في أحدها، وربما ما دفعك إلى الأمر هو استفادتك من مشروع مفتوح المصدر وأردت أن ترد الجميل بالمساهمة فيه بدورك، لكن لا تدري كيف تقوم بذلك؟ الأمر بسيط، كل ما تحتاجه هو جهاز محلي يكون Git مُنصبا عليه، حساب على Github وبعض الوقت، ومن ثم اتباع بضع خُطوات بسيطة. تجدر الإشارة إلى أنك لا تحتاج إلى أن تكون مُبرمجا للمُساهمة في المشاريع مفتوحة المصدر، يُمكنك المُساهمة في إنشاء أو تحسين توثيق المشروع، حيث يُعتبر التوثيق الجيد أحد أهم عوامل نجاح المشاريع مفتوحة المصدر، وانتشار بعضها على حساب الآخر. لنفرض أن المشروع الذي تود المُساهمة فيه هو "git – الدّليل البسيط". 1. قم باستنساخ المشروع إلى حسابك الخاص وذلك بالنقر على زر Fork الموجود في الزاوية العُلوية اليُمنى لصفحة المشروع. هذه العملية من شأنها أن تُنشئ نُسخة مُطابقة للمُستودع الأصلي على حسابك على Github. 2. بعد ذلك قم باستنساخ هذا المُستودع الجديد على جهازك المحلي. ادخل إلى المجلد الذي تود استنساخ المُجلد فيه (cd path/to/folder) وقم بتنفيذ الأمر git clone متبوعا بعُنوان المُستودع. ستجد العُنوان أسفل القائمة اليُمنى في صفحة المُستودع. بالنسبة لي سيكون الأمر على النحو التالي: git clone https://github.com/djug/simple-guide.git 3. الآن وبعد أن حصلت على هذه النُسخة، قم بإدخال التعديلات التي ترغب فيها واحفظ تلك التعديلات. قبل أن نقوم بإيداع تلك التعديلات، يُنصح دائما التحقق من حالة المُستودع، وإن تم أخذ التعديلات بالحسبان أو إن قمنا بتعديل ملف لم نكن نرغب في تعديله، حيث يكفي أن ننفذ الأمر git status لمعرفة حالة المُستودع (النسخة المحلية): git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: index.ar.html4. تبدو الأمور طبيعية. لنقم بإرسال التغييرات إلى منطقة الإدراج: git add .ومن ثم إيداعها (commit): git commit -m "Your commit Message Here"بطبيعة الحال ستحتاج إلى وضع وصف مُناسب للتغييرات التي قمت بها. بإمكانك أيضا تنفيذ الأمر commit لوحده من دون أية رسائل: git commitوسيقوم git بفتح مُحرر النصوص المُفضل لديك لكتابة الوصف (في حال ما إذا قمت بتحديد اسم هذا المُحرر في إعدادات git). سنحتاج الآن إلى إرسال هذه التغييرات إلى المُستودع (الشخصي وليس مُستودع المشروع الذي نشارك فيه) على Github عبر تنفيذ الأمر: git push origin masterسيطلب منك Git اسم المُستخدم الخاص بك على Github وكلمة السر، وبمُجرد أن يتم التحقق منهما سيتم دفع التغييرات إلى مُستودعك الخاص. 5. الآن لو عدنا إلى صفحة المُستودع الشخصي على Github سيظهر لنا تاريخ آخر تحديث للملفات المُعدلة ووصف له. وكل ما نحتاج إلى فعله الآن هو إرسال "طلب سحب" pull request -أي سحب التغيرات- إلى المُستودع الأصلي للمشروع وذلك بالنقر على الزر الأخضر الذي يظهر في الزاوية العُلوية اليُمنى للمُستودع ستظهر لك صفحة لتلخص من جديد التغييرات التي تمت 6. الخطوة الأخيرة هي النقر على زر Create Pull request، إضافة أية تعليقات ترغب فيها على الطلب، ومن ثم النقر على زر Send pull request: ستصل صاحب المشروع رسالة بخصوص التغييرات التي قمت بها، وفي حال قبولها سيصلك إشعار بها وستظهر تغييراتك على المستودع الأصلي: هذا كل ما في الأمر. أنت الآن بطريق… أقصد مُشارك في مشاريع مفتوحة المصدر بشكل رسمي. نصائح عامة لدى المساهمة في المشاريعاجعل نص الإيداع commit معبّرا أو ملخصا للتغيرات التي قمت بها، لا تجعله مبهما أو عاما.افصل طلبات السحب "pull request" حسب الغرض، أو اجعل لكل تغير تقترحه في branch لوحده حسب الغرض، مثال: لا ترسل طلب سحب يحتوي تغيرات مرئية في الـ html و css وفيه أيضا ترجمة النصوص إلى العربية، هكذا تصعب المهمة على من يقوم بعملية الدمج في حال كان يريد قبول الترجمة لكنه غير راض عن التغيرات التي طرأت في الـ html/css. في هذه الحالة سيكون من الأنسب:طلب سحب للتغيرات المرئية لوحده.طلب سحب آخر للملفات الترجمة إلى العربية.في حال كانت مساهمتك تحل علة ما تم التبليغ عنها في قسم الـ issues في مستودع المشروع على github، أو لها علاقة به، فإنه يمكنك الإشارة إلى تلك العلة في نص الإيداع فقط بوضع رقم العلة مسبوقا بعلامة #، مثال:git commit -m "fix for some bug (issue #23)"ستلاحظ عند زيارة واجهة Github أن الرقم 23# في نص الإيداع، قد أصبح رابطا يحول مباشرة إلى صفحة تلك العلة. في حال قمت بعمل Fork وساهمت في المشروع، وأردت مرة أخرى أن تساهم في ذاك المشروع مجددا، فلا تنس أن تجعل مستودعك الشخصي من ذاك المشروع محدّثا، يعني اجلب التغيرات الجديدة التي طرأت على المستودع الأصلي، قبل المساهمة مجددا وعمل أي commit أو pull request، هذا يخفض من نسبة التعارض conflicts، ويسهّل عليك وعلى القائمين على المشروع عمليات الدمج، قد تكون التغيرات التي قمت بها، قد قام بها آخر، أو ربما تم حذف الملف الذي تعمل عليه أصلا من المشروع الأصلي، فيضيع جهدك هباءا منثورا.من المحبذ أيضا، استعمال صيغة الأمر في نص الإيداع، مثال، استعمل "add something to file x" عوض "adding|added something to file x".