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

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

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

متى يحين للاعتماد على التعهيد الخارجي في مدونتك؟

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

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

• كتابة ونشر منشورات المدونة.
• إدارة حسابات التواصل الاجتماعي.
• التأكد من أن الموقع الإلكتروني يعمل بشكل جيد والاهتمام بالمشاكل التقنية
• إدارة التعليقات في منشورات المدونة والرد على رسائل البريد الإلكتروني

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

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

هل تستطيع الاعتماد على التعهيد الخارجي في كتابة محتوى لمدونتك؟

الإجابة باختصار هي نعم. ولكن غالبًا تكون المبالغ التي يجب أن يتقاضاها الكتاب المستقلين مبالغ كبيرة. لنقل على سبيل المثال، أنك تريد منشورًا جديدًا لمدونتك كل أسبوع. تجد كاتبًا لديه خبرة، تخبره بالمواضيع التي تريده أن يعمل عليها وتجعله يبدأ العمل. وكحد أدنى، قد تكلفك 4 مقالات مكونة من 1000 كلمة لكل منها 100$ شهريًا على أقل تقدير وقد تصل حتى 240$.

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

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

أين تبحث عن كتّاب مستقلين على الإنترنت؟

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

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

إليك صيغة عنوان مشروع لتوظيف مستقل لكتابة مدونة:

إذا كان مشروعك قليل التكلفة، ستبتعد عن الكتّاب الموهوبين.

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

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

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

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

الخاتمة

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

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

هل لديك أي سؤال حول عملية التعهيد الخارجي لمحتوى مدونتك؟ ضعها في قسم التعليقات أدناه!

ترجمة وبتصرف للمقال How to Outsource Work for Your Blog لكاتبه Alexander Cordova

إنّ ما ترغب فيه عندما تحتاج إلى إنشاء منتج برمجي ولكن خبرتك في هندسة البرمجيات محدودة هو التعهيد الخارجي للبرمجيات. إنها ممارسة تجارية ذكية يستخدمها الجميع بدءًا من أصحاب الألف دولار الذين يملكون مواقع الويب الشخصية وانتهاء بأصحاب الثروات الكبيرة؛ وكلهم يفشلون إلى حد ما. في الواقع، من الصعب جدًا أن لا تفشل. لذا أعددت فيما يلي قائمة من التلميحات البسيطة لكل من يقرّر التعهيد الخارجي لتطوير البرمجيات (يوجد أهمها في الأسفل). ولكم تمنيت لو أن شخصًا ما قد أعطاها لي منذ 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

نحتاج جميعًا إلى التعهيد الخارجي للبرمجيات، بدءًا من أصحاب أصغر المواقع الإلكترونية وانتهاء بأغنى مئة رجل في العالم، لا سيما عندما نرغب بتصميم منتج برمجي لا يكون مهندس البرمجيات لدينا مؤهلًا لإنجازه، إلا أن النتيجة النهائية نادرًا ما تكون سارة، وفي الحقيقة فمن الصعب جدًا ألا تفشل هذه العملية؛ لذا أعددت هنا قائمة تلميحات بسيطة لكل من يقرر الاستعانة بمصادر خارجية لتطوير البرمجيات (مرتّبة من الأقل فالأكثر أهمية)، ولكم كنت أتمنى لو أُعطيت لي قبل 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

بناء شركات ناشئة ناجحة يتطلّب الكثير من الوقت والجهد. في حين أن هناك العديد من الجوانب في بناء ونمو مشروعك التّجاري، إلّا أن أحد أعقد هذه الجوانب هو بناء علامتك التّجارية.

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

لقد كنّا عازمين بشدّة على إيجاد وكالة التّسويق Marketing agency الأمثل، تلك التي يكون نجاحُنا هو أوّل اهتماماتها. كشركةٍ متخصّصةٍ في حلول إدارة المبيعات، انتابنا الفضول حول استراتيجية المبيعات الخاصّة بوكالات التّسويق: هل يهتمّون بكلّ عميلٍ محتمَل بنفس قدر اهتمامنا؟ كيف يقومون ببيع خدماتهم؟

كان الأكثر أهمّيةً بالنّسبة لنا هو أن نجد الشريك الذي يُقدّر نفس الهدف الذي نسعى إليه: العمل الدّقيق مع العملاء المحتملين من البداية وحتّى النهاية. فهذا هو النّهج الذي نتبعه وأردنا أن يتحلّى شريكنا التّسويقي بنفس تلك المبادئ التّوجيهية.

كيف تختار الوكالة التسويقية

لقد بدأنا باختيار 20 وكالةٍ تسويقيةٍ رائعة وجدناها من خلال إعلانات جوجل. ثم قمنا بتضييق نطاق اختيارنا إلى 5 وكالات كي نجد أخيرًا ضالتنا التي نبحث عنها "الماسة وسط باقي الأحجار."

الوكالات التي تُنفق ميزانيتها التّسويقية على إعلانات جوجل سوف تكون أكثر مثابرةً مع كلّ عميلٍ محتمل وكان هدفنا أن نؤخَذ على محمل الجد. فنحن أدركنا أن افتقار بعض الشركات لبرمجيات تتبّع العملاء المحتملين يُقلّل من فرص تكوينهم لعلاقاتٍ جديدةٍ ناجحة.

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

ثلاثون بالمئة من الوكالات التي قمنا باختيارها لم تقُمْ بالرّد على استفساراتنا. لا نعلم إن كنّا شركةً صغيرةً جدًّا على حجم تعاملاتهم أو أنّهم ببساطةٍ لم يمتلكوا تطبيق CRM (إدارة العلاقات مع العملاء Customer relationship management) لتتبّع عملائهم المحتملين. وكالةٌ واحدة كان لديها نموذج ويب غير مُفعَّل على موقعها الإلكتروني وإيجاد عنوان البريد الإلكتروني الخاص بهم تحوّل إلى عملية بحثٍ مضنية والتي تخلّينا عنها في النهاية. قررنا بعد ذلك أن نُضيّق نطاق قائمة شركائنا المحتملين.

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

من خلال استخدامهم لأسلوبٍ تعاملٍ احترافي، أرادت الوكالات أن تعرفنا بشكلٍ افضل وأن تستمع أكثر لأهدافنا، تخوفاتنا وحتّى أدّق التّفاصيل في مشروعنا التّجاري.

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

لسوء الحظ، فشلت 4 وكالات في الخطوة التّالية لعميلة متابعة عميلها المحتمل (نحن). فإمّا أنّهم لم يستطيعوا تتبّعنا أو أنّهم تناسوا الأمر، فلم يتواصلوا معنا مرةً أخرى. وهنا ضاق نطاق بحثنا مرةً أخرى.

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

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

تضييق نطاق قائمة الوكالات التسويقية المختارة

بعد العديد من الاتّصالات الهاتفية، المقابلات، الأسئلة والقرارات الصّعبة، تسلّمنا عروضًا من 6 وكالات، والتي تُمثّل 30 بالمئة فقط من القائمة الأولية التي قمنا باختيارها. عرضت هذه الشركات خُططًا تسويقيةً رائعة، الأمر الذي هيأ لنا أن نتخذ قرارًا مستنيرًا.

قامت ثلاث شركات من الستّة بالتّواصل معنا من جديد خلال أسبوعٍ واحد، مُحافظةً على المستوى العالي للتفاني والاحترافية. قامت كلّ شركةٍ بعملٍ رائع فيما يخصُّ التّواصل معنا، الاستماع لما أردنا قوله، قمنا باقتراحه، نصحنا به وتابعناه. لقد كنّا حقًّا مندهشين لرؤيتنا تفاني هاتين الوكالتين اللتين قامتا بالتّواصل معنا أكثر من مرتين بعد أن أرسلتا لنا عروضهما.

مثلُ هذا العمل الدّقيق مع عميلٍ محتمل لا يُمكن أن يمُرّ دون أن نلاحظه وأن يأسر قلبنا.

لقد حظينا بتجربةٍ مليئةٍ بالتّحدي ولكن رائعة في رحلتنا لاختيار شريكنا الأمثل وأردنا أن نُبرز بعض أهم الجوانب في عملية اختيار الوكالة التّسويقية المناسبة:

هل تشعر بوجود علاقة بينك وبين شريكك التسويقي؟

يكمن مفتاح أي شراكةٍ في الاتّصال المتبادل. فعلى كلٍّ منكما أن يفهم ويستوعب الآخر. كما هو الحال في أي علاقةٍ جيّدة، بنبغي أن يحب كلٍّ منكما الآخر بإخلاص وأن يسعى بجِدٍ لإنجاح العلاقة.

كيف تبدو النتائج السابقة لتلك الوكالات التسويقية؟

لا ينبغي أن يكون سرًّا ما يُمكن لوكالتك التّسويقية أن تفعله من أجلك أو كيف كانت نتائجها السابقة قبل العمل معك. أسأل عن دراسات الحالات، المعايير، التّحليلات، التّقارير وألقِ نظرةً على نتائجها القابلة للقياس. فهذا الأمر سوف يساعدك على تحديد كيف كانت نتائجها السّابقة بشكلٍ كامل وسوف يُعطيك أيضًا نظرةً عامّة حول ما تهتم به هذه الوكالة دون غيره.

كن أمينا فيما يخص ميزانيتك

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

استعد لسيل من المكالمات الهاتفية الطويلة والعديد من رسائل البريد الإلكتروني

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

قم بتقييم أداء وكالة التسويق أثناء مرحلة المبيعات

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

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

ترجمة -وبتصرّف- للمقال Marketing Bonanza: How to Find a Marketing Agency That Fits لصاحبته Jen Anders.

حقوق الصورة البارزة: Designed by Freepik.

جميعنا نعلم أن التعهيد الخارجي للبرمجيات هو عبارة عن كارثة منتظرة في أية لحظة.

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

نعم؛ من الممكن القيام بذلك بطريقة صحيحة وخالية من المتاعب كليًا، ولكن عليك أن تكون مستعدًا لتعديل فلسفة الإدارة الخاصة بك.

المبادئ الرئيسية هنا هي كالتالي:

1. عليك أن تصارح فريق التعهيد بهواجسك بشكل مستمر ومنفتح.
2. عليهم أن يبوحوا لك بالمخاطر والمشكلات التي تقابلهم بشكل مستمر ومنفتح أيضًا.

هذان العاملان أساسيان لنجاح التعهيد الخارجي للبرمجيات؛ ولكن للأسف غالبًا ما يتم تجاهلهما.

تعلّمت هذين المبدئين من المعلم وي لياو زي، إذ قال بما يتعلق بالاستراتيجية العسكرية في الصين القديمة عام 239 ق.م:

اقتباس

"عندما تصل المعلومات من الأسفل إلى الأعلى؛ وتصل المخاوف من الأعلى للأسفل؛ فإننا نحصل على أكثر الحالات مثالية".

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

أطول من الوقت المتوقع؛ أكثر من الميزانية المتاحة

دائمًا ما يخبرك أفراد الفريق بأن المنتج جاهز بنسبة 95%، لكن هناك مع ذلك بعض المزايا غير المنفّذة أو المعطّلة. لقد قاموا بالكثير من العمل؛ ولقد دفعتَ الكثير من المال، لكن المنتج القابل للتسويق غير جاهز بعد؛ إنه يتطلب أسبوعًا إثر أسبوع؛ وشهرًا بعد شهر، دائمًا هناك تراكم، ولا يمكننا ببساطة أن ننتهي من ذلك، لقد بدأتَ ترى المشروع في كوابيسك، ولم يعد للأدوية المهدئة تأثير مساعد، هل يبدو لك هذا كله مألوفًا؟

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

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

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

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

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

• الوقت والميزانية والمجال المحدد لعملك.
• عواقب تجاوزهم هذه الحدود.

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

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

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

إليك كيف يمكن أن يكون تحديد الزمن والتكلفة بشكله الصحيح:

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

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

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

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

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

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

المنتج غير متقن تماما

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

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

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

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

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

لا يمكنني الاعتماد على وعودهم

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

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

البعض يسمي هذا بـ "التطوير المدفوع بالخوف" أو "fear-driven development". الفريق خائف منك؛ وهو مضطر للكذب عليك حتى تستمر بالعمل معه -والدفع له-.

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

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

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

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

ما أود نصحك به عمليًا هو كالتالي:

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

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

جرّب هذا النهج وسوف تفاجأ بما ستحتويه قائمة المخاطر من أشياء مثيرة للاهتمام.

ترجمة -وبتصرف- للمقال How to Avoid a Software Outsourcing Disaster لكاتبه Yegor Bugayenko.

حقوق الصورة البارزة: Designed by Freepik.

لم تكن شركتنا النّاشئة Groove لتُبنى أبداً بدون مطور، وإليك كيف اتخذت الخطوة الأولى لتحويل فكرتي إلى مشروع تجاري.

في البداية لم أكن أملك شيء، لا نموذج أولي، ولا عملاء، وبالتأكيد لا تمويل.

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

حاليًا، يختلف في الرأي بشدة الكثير من الأشخاص الأذكياء فيما إذا كانت تحتاج الشركات الناشئة إلى شريك مؤسس تقني في مرحلة مبكرة من العمل. حيث يعتقد Mark Suster أنه " إذا لم يكن لديك شخص ما داخل مؤسستك يُحدّد الاتجاه التقني فأنا واثق أنك لن تصل للعظمة أبداً." بينما يعترف Drew Houston بمدى صعوبة إيجاد شريك مؤسس تقني. ويقترح تعلم البرمجة أو التعهيد. (التعهيد Outsourcing هو استخدام واستئجار كفاءات وقوى وأفراد ووسائل وخدمات من مؤسسات أو شركات أو جهات ثالثة أجنبية أو محلية.)

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

وبصراحة أعتقد أن Mark على حق، لو أنني وجدت شريك مؤسس تقني مناسب، مع المهارات المُناسبة وبالسّعر /حصّة الشّركة الأنسب كنت لأخبركم الآن قصة مختلفة. لكنني لم أجد الشريك، ولن أخبركم عن تلك القصة.

يتوجب عليّ أن أكون مبدعاً إذا أردت البدء في تنفيذ Groove بسرعة. لذا قررت البدء في البحث عن شركة تطوير لبناء الإصدار الأول من Groove.

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

إجراء المكالمة

بقيت لأيام أقلّب الأفكار برأسي لأحدّد ماهي الخطوة التالية؟ فكرّت ملياً بالإيجابيات والسلبيات المحتملة.

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

وبالنسبة لشركة التطوير التي ستعتمد على ما أدفعه لها لمواصلة نشاطنا، هل ستتماشى مصالحنا؟ هل سيكونون متحمسون للعمل بسرعة مثلي؟ يعني تمامًا مثلما سيفعله الشّريك المُؤسس التقني الذي طال البحث عنه.

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

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

ومن جهة أخرى، هذا يعني أيضًا أن جميع القرارات تتوقف علي. ولن يكون هناك قيود تأتي مع وجود شريك لديه منظور مختلف (وأكثر أهمية في العديد من الحالات).

في النهاية كان هناك سببان رئيسيان دفعاني للتوقيع مع MojoTech.

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

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

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

العمل معا

في الأشهر التالية، عملت عن كثب مع فريق من 4 أشخاص مكرسين لـ Groove. خلال ذلك الوقت، كنت أتواصل مع الفريق يومياً عبر هيب شات (HipChat خدمة ويب للدردشة الداخلية الخاصة).

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

كان الوصول إلى هذه النقطة كل ما أحتاجه لاختبار افتراضي بأن هناك طلباً على بديل بسيط لـ Zendesk (برنامج يتميز بقدرته على الاندماج مع العشرات من أنظمة إدارة المحتوى وأدوات إدارة علاقات العملاء customer relationship management).

أطلقنا النسخة التجريبية، وأسرع موقع the Next Web لكتابة مقال عنا، وكان لدينا بعد أسبوع أكثر من ألف مشترك في النسخة التجريبية من البرنامج.

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

عملت مع MojoTech على بضعة تطويرات إضافية لتطبيق Groove وتسويق الموقع حتى بدأت بتوظيف أول موظفي Groove. ثم توقفت عن العمل مع MojoTech وافترقنا بشكل وديّ، بعد تعاقدي مع مطورين اثنين لحسابي.

تأملت في العمل الذي قمنا به سويةً، كان هناك عدد من الملاحظات (الإيجابية والسلبية) التي تدفع بقوة أي مؤسس في وضع مشابه للتفكير مليًا:

الجوانب الإيجابية

لدي تطبيق

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

قاموا بالكثير من العمل نيابة عني

لم أحتج للتوظيف. لم أحتج لتدريب أي موظف. وبينما كنت أعمل بقرب مع فريق mojo. لم أحتج إلى إدارة أي شيء بشكل مباشر. تمكنت من التركيز على ما كان أكثر أهمية بالنسبة لي: المساهمة بشكل مباشر في إنشاء المنتج.

لدي تأثير

مع بناء التطبيق، قام المستخدمون بالتسجيل ونشر موقع The Next Web قصتنا، كان لديّ ما أحتاجه ليس فقط للبدء ببناء فريق، وإنما أيضاً للبحث عن مستثمرين لمساعدتي على مواصلة بناء الشركة، حيث كنت أملك أكثر من مجرد فكرة أعرضها عليهم. في حين أن الحصول على تمويل ليس بالأمر السهل، إلا أن التحقق من فعالية فكرتي أعطتني بعض التأثير الذي ساعدني على إقناع الممولين بأن Groove سيكون رهانًا مناسبًا. وبعد فترة وجيزة من إطلاق الإصدار التجريبي، حصلت على تمويل بقيمة $700,000 من مجموعة صغيرة من الممولين. وهذا أعطانا الدفعة التي نحتاجها للبدء في بناء الفريق.

لدي مسؤولية

قبل استثمار $300,000 على العمل مع MojoTech، كان Groove يعيش في رأسي وبضعة مستندات في حاسوبي، واستعرضته للشركاء المحتملين في المقاهي، لكن لم أحرز أبداً أي تقدم ملموس.

إن الالتزام بالحصول على تطبيق مبني ألقى على عاتقي مسؤولية، ولم يعد التأجيل أمرًا مُمكنًا، أنفقت الأموال وقضي الأمر. وكان يتوجب عليّ البدء بالعمل.

الجوانب السلبية

لم يكن رخيصا

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

لا زلت أتمنى لو كان لدي شريك مؤسس منذ البداية

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

لم أحب دائما "طريقة عمل شركة التطوير"

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

تحدي بناء الفريق لم ينجز بعد

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

هل عليك التعاقد مع شركة تطوير لبناء تطبيقك؟

كتبت هذا المقال لعشرات المؤسسيين ومن يحاولون أن يصبحوا مؤسسين الذي راسلوني يطلبون النصيحة حول إطلاق منتجاتهم.

هل التعاقد مع شركة تطوير سينجح معك؟

بصراحة، لا أعرف.

لقد نجح الأمر معي. أنا تعاقدت مع MojoTech. لقد بنوا الإصدار الأولي من Groove. ووصلنا إلى ما نحن عليه الآن عن طريق العمل بنشاط بالغ، وتحقيق انتصارات تطلبت جهدًا جهيدًا، كما مررنا بتجارب قاسية للغاية. لم نصل بعد إلى ما نطمح إليه، ولكننا ههنا.

هل كنا لنصل إلى هنا لو استمريت في البحث عن شريك تقني مؤسس؟

افترض أنني لن أعرف أبداً.

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

ترجمة -وبتصرف- للمقال What I Did When I Couldn't Find a Technical Co-Founder لصاحبه Alex Turnbull.

حقوق الصورة البارزة: Designed by Freepik.

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

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

التفكير بالتّعهيد الخارجي لبناء لشركتك الناشئة (outsourcing)

من الطبيعي للغاية إذا لم تكن لديك خلفية تقنية وإذا لم تكن قادرًا على البرمجة أن تفكّر بعدم استطاعتك في بناء شركتك الناشئة دون مساعدة؛ وغالبا ما ستراودك فكرة تتمثل بأحد احتمالين: إمّا إيجاد شريك تقنيّ technical co-founder، أو التعهيد ببناء المنتج الفعّال القاعدي MVP لمستقلّ أو شركة خارجية.

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

وإليكم الأسباب التي لأجلها أرى أنه لا يجدر بكم الاستعانة بمصادر خارجية لبناء شركاتكم الناشئة:

1. عدم وجود تطابق بين أهدافك وأهداف المستقلّ

إذا كنتَ تفكّر أن تستعين بمساعدة خارجيّة؛ فيجدر بك أن تعلم أنّ هدف الأشخاص المستقلين أو وكالات التطوير هو خدمة أكبر عدد من العملاء؛ وكسب المزيد من المال في نهاية الأمر، بينما يكون هدفك عندما تبدأ بشركة ناشئة هو الوصول إلى مُنتج مُلائم للسّوق Product-Market Fit وصنع شيء يمكن أن يجذب الناس traction.

المشكلة الأبرز مع هذين الهدفين المختلفين؛ هو أنّ الطريق الناجح ليصل المستقل لهدفه مختلفٌ كُليّةً عن الطريق الناجح لمؤسسي الشركات الناشئة ليصلوا إلى منتج قابل للتسويق.

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

بينما تهدف أنت كمؤسّس لشركة ناشئة الوصول لمنتج مناسب للتسويق، ثمّة لمحات عظيمة في قول لـِ مات مولينويج (مُؤسس Wordpress/automattic) حول الأسباب التي يجدر بالمؤسسين لأجلها إطلاق شركاتهم الناشئة في أبكر مرحلة ممكنة؛ إذ يقول:

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

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

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

2. الصورة الذهنية الخاطئة حول "ما تحتاجه لتحصل على منتج من الصفر"

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

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

ما يلزمُك بدايةً لإنشاء منتجٍ ناجح هو استبعاد كل الأفكار التي لم تتحقَّقْ من رغبة الناس بها؛ إيجاد فكرة لشيء يحتاجُه المستخدمون أو الزبائن بشدّة، ما يجعله منتجًا مناسبًا للتسويق وقابلًا للجذب، الأمر المهم في هذه الخطوة أنك لن تحتاج البرمجة لتحقيقها.

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

ثق تمامًا أنه في وسعك الحصول على منتج أوّلي -غير قريب من المثالية- دون أية برمجة، بل قد يبدأ حصد بعض التفاعل traction إذا تابعت العمل عليه وبدأت بحل الجوانب التي لم يتم التّحقق منها بعد فيه. حالما تبدأ فكرتك بجذب تفاعل الناس؛ ستفتح لك أبوابًا كثيرة لمساعدتك في برمجة منتجك وجعله أجمل.

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

3. يجب على فريق التأسيس أن يكون ملمًّا بكل شيء

أمر آخر يجعلني أؤمن بضرورة الانطلاق دون دعم خارجي لشركتك الناشئة: يجب على فريق المؤسسين أن يتعلّموا القيام بكل المهام في المشروع؛ وإليكم الأسباب:

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

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

ما الذي نفعله عوضًا عن التّعهيد الخارجي؟

حسب اعتقادي الشخصي؛ فإنّ بناءك لمنتج بنفسك هو الطريق الأمثل؛ بل لعلّه في الحقيقة الطريق الأسرع لإنشاء شركتك الناشئة بنجاح.

قد يبدو الأمر معاكسًا للبديهة، فكيف يكون بناء المنتج بنفسك أسرع طريقة للنجاح في حين أنك لا تمتلك أية معرفة برمجية؟ الفكرة أنني لا أتحدث عن البرمجة، بل عن بناء المنتج بأية وسيلة يمكنك البناء بها. قد يعني هذا بناؤه من دون أية برمجة، ومن الممكن أن يعني التقاط المهارات وتعلّمها من هنا وهناك، وهو أمر عظيم في رأيي.

السبب الذي يجعلني أعتبر بناء مُنتجك بنفسك هو الطريق الأقصر والأمثل؛ هو أنّه في حال كان ما تمتلكه هو الفكرة فقط؛ فإنّك ستجد عواقب كثيرة للحصول على شريك ذي خلفية تقنية ليشارك في بنائها؛ أو تُعهد بالأمر لمستقل أو وكالة، لكن قيامك بهذ الخطوة وعدم وجود علاقات عمل مع من يبني لك المنتج قد يحرمك من كونك جزءًا من أهم حلقة في إنشائه؛ وهي حلقة البناء-القياس-التعلم، والتي يؤدي تكرارها عادة لوصولك إلى منتجك مُتناسب مع السّوق product/market fit.

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

تُرجم بتصرّف للمقال: 3reasons you shouldn't outsource your startup, and what to do instead لصاحبه جويل غاسكوين (مؤسس Buffer).

"بإمكانك القيام بأيّ شيء، لكن ليس بكل شيء" – ديفيد آلان

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

أنا أحد شريكين في شركة تختص في تطوير شبكة الإنترنت، ونُطوّر نظام إدارة المُحتوى Perch. كما أنني كاتبة ومتحدثة في مجالات مُختلفة تبدأ بـ CSS و تنتهي عند الدعم الفني، وبالفعل استمتع بالقيام بهذه الأمور جميعها.

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

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

بدايةً، إن أكثر الأمور أهمية هو تحديد ما يجب أن يتمّ فعله. شخصيًا، أنا معجبة بفكرة Getting Things Done وأقوم دوريًّا بمراجعة أعمالنا جنبًا إلى جنب مع أهدافي الشخصيّة. عندما يكون لدي مجموعة من المهام فإنني أقوم بتصنيفها وفقًا لهذه المعايير:

• هل أنا الشخص الوحيد القادر على القيام بهذا العمل؟

• هل سأقدم منفعة لهذا العمل أو المنتج إذا قمت به بشكل شخصيّ؟

• هل سأستمتع بهذه المهام؟

• هل سأتعلم شيئًا جديدًا إن قمت بهذا العمل؟

• ما هي الأشياء التي لن أقوم بها إن اخترت هذه المهمة؟

هل أنا الشخص الوحيد القادر على القيام بهذا العمل؟

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

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

هل سأقدم منفعة لهذا العمل أو المنتج إذا قمت به بشكل شخصي؟

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

هل سأستمتع بهذه المهام؟

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

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

هل سأتعلم شيئًا جديدًا إن قمت بهذا العمل؟

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

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

ما هي الأشياء التي لن أقوم بها إن اخترت هذه المهمة؟

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

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

ترجمة -وبتصرّف- للمقال You Can’t Do Everything لصاحبته Rachel Andrew

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

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

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

السر ليس في أن تكون الأول في التنفيذ (إلا نادرا). بل السر أن تكون الأفضل في التنفيذ. ولتكون الأفضل في التنفيذ تحتاج أن تتوفر على المهارات الأفضل.

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

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

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

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

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

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

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