7 أخطاء ترتكبها الشركات الصغيرة عند شراء برمجيات مخصصة

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

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

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

الخطأ 1: شراء حل قبل فهم المشكلة

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

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

الخطأ 2: محاولة بناء كل شيء دفعة واحدة

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

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

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

الخطأ 3: الاختيار على أساس السعر وحده

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

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

الخطأ 4: نسيان أن البرمجيات ليست شراءً لمرة واحدة

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

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

الخطأ 5: ترك المتطلبات غامضة ودون مسؤول

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

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

الخطأ 6: عدم السؤال عمن يملك الشيفرة والبيانات

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

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

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

الخطأ 7: معاملة الإطلاق كخط النهاية

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

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

1. 1
   أطلِق لمجموعة صغيرة أولًا

   انشر الأداة لبضعة أشخاص راغبين قبل الفريق كله. سيكتشفون الزوايا الخشنة ويصبحون أنصارك الداخليين.
2. 2
   أظهِر المكسب الشخصي لا مكسب الشركة

   «هذا يوفر مالًا للشركة» لا يحفّز أحدًا. أما «هذا يعني أنك تتوقف عن كتابة العناوين مرتين» فيكسب الناس إلى جانبك.
3. 3
   عيّن شخصًا مرجعيًا للأسئلة

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

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

نجمعها معًا: عقلية المشتري

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

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

أسئلة شائعة