برمجة تطبيقات الويب والأنظمة المخصصة

هل مشروعك البرمجي في مساره الصحيح؟ خمسة فحوص تجريها بنفسك

شارك المقال
هل مشروعك البرمجي في مساره الصحيح؟ خمسة فحوص تجريها بنفسك

لماذا لا يمنحك أحد إجابة صريحة عن نسبة الإنجاز

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

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

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

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

الدليل الوحيد المعتبر هو برنامج تضغط عليه بنفسك

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

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

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

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

ما الذي يحتويه التحديث الحقيقي، وما الذي يخفيه الغامض

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

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

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

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

خمسة فحوص تجريها هذا الأسبوع دون أي معرفة تقنية

كل فحص هنا يحتاج دقائق معدودة، ومجموعها ساعة واحدة بالضبط، وستخرج منها بصورة أوضح مما يعطيك أي تقرير مكتوب:

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

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

حساب الجدول الزمني الذي يستطيع أي شخص إجراؤه

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

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

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

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

العمل الذي لا تراه، ولماذا الشاشات ثلث المشروع فقط

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

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

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

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

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

أين تضيع الأسابيع فعلاً، ونادراً ما تكون البرمجة السبب

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

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

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

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

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

إشارات لها معنى، وضجيج لا معنى له

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

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

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

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

قراءة المال في مقابل العمل المسلَّم

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

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

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

اكتشفت أنك متأخر. ماذا الآن؟

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

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

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

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

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

حين يكون الخيار الأصغر والأرخص هو الجواب الأمين

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

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

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

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

الكلمات المفتاحية

المزيد من المواضيع المشابهة والمفيدة.

كيف تكتب وثيقة مشروع تجعل عرض السعر البرمجي دقيقاً

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

1 دقائق للقراءة

صيانة البرمجيات المخصصة: من يبقي نظامك حياً بعد التسليم؟

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

1 دقائق للقراءة