استوديو برمجيات يدعو إلى الأقل
نبني تطبيقات ويب وهواتف لشركات تحتاج أن يناسب البرنامج العمل، لا العكس. وغالبًا يعني ذلك إقناعك بالتخلّي عن نصف ما جئت تطلبه.
استوديو قام على فكرة واحدة عنيدة
معظم مشاريع البرمجيات لا تفشل في الكود. تفشل في الفراغ بين ما طلبه أحدهم وما كان يحتاجه فعلًا — وهذا الفراغ لا يظهر عادة إلا بعد الفاتورة.
سمادي موجودة لإغلاق هذا الفراغ مبكرًا. نصرف المحادثة الأولى على المشكلة لا على التقنية، ونكتب ما اتُّفق عليه حتى لا يعتمد أحد الطرفين على ذاكرته بعد ثلاثة أشهر.
ولهذا نقدّم طريقين لا طريقًا واحدًا. بعض المشكلات شائعة بما يكفي ليغطّيها تطبيق بنيناه وأثبت نجاحه بعد تهيئته لك. وبعضها خاص بما يكفي ليكلّفك أي حل جاهز في الحلول الملتوية أكثر مما يوفّره. أما دفع العميل نحو المشروع الأكبر لأجل الفاتورة الأكبر فهي لعبة قصيرة.
ما لا يتغيّر في الحالتين: النطاق يُتفق عليه قبل بدء العمل، ويمكنك فتح التطبيق واستخدامه في كل مرحلة، والكود والبيانات لك في النهاية.
إن كان حلٌّ أصغر يحلّ مشكلتك، نفضّل أن نقولها ونحتفظ بالعلاقة.
- طريقتان للبداية
- 2
- جاهز ومهيّأ، أو مبني من الصفر. وكلاهما ينتهي بتطبيق تملكه.
- مراحل حتى التسليم
- 4
- استشارة، عرض، تنفيذ، تسليم — نفسها في كل مشروع.
- تكلفة الحديث أولًا
- 0
- الاستشارة مجانية، ولا يُحصَّل شيء قبل وجود اتفاق.
- لك في النهاية
- 100%
- الكود والحسابات والبيانات تُنقل إليك. والبقاء معنا اختياري.
ستة أمور لا نتنازل عنها
ليست ملصقًا على حائط. هذه هي القرارات التي نتخذها حين يصبح المشروع غير مريح.
نفهم العمل أولًا
نتعلّم كيف يعمل فريقك فعلًا قبل أن نقترح أي شيء يغيّره.
نقول ما لا يُحبّ سماعه
إن كان حلٌّ أصغر يكفي — أو لم يكن التطبيق هو الجواب — فهذا ما تسمعه، لا عرضًا أكبر.
نبني ليُسلَّم
منظّم وموثّق بحيث يستطيع فريق آخر إكماله. حبس العميل ليس نموذج عمل.
نقدّر متأخرًا ثم نلتزم
الأرقام تأتي بعد الفهم. وإن تبيّن خطؤها، تسمع ذلك وما تزال الخيارات متاحة.
مملّون حيث يهم
أدوات مجرَّبة للأجزاء التي لا يجوز أن تفشل. الجدّة ليست شيئًا طلبته.
نُكمل ما نبدأه
مُطلَق ومستخدم يوميًا أفضل من مبهر وغير منشور. النطاق يُقلّص قبل الجودة.
ما نقوم به، وما لا نقوم به
كل استوديو يقول إنه شفاف. الحكم أسهل من القائمة المقابلة.
ما نقوم به
- نخبرك إن كان طريق أرخص يحلّ مشكلتك
- نكتب النطاق والمدة والتكلفة قبل البدء
- نصمّم الشاشات قبل كتابة أي كود
- نعطيك شيئًا تفتحه وتستخدمه في كل مرحلة
- نسلّم الكود والحسابات والتوثيق
- نخبرك مبكرًا إن تبيّن خطأ التقدير
ما لا نقوم به
- نعطي رقمًا قبل أن نفهم العمل
- نوعد بقائمة ميزات ثابتة مقابل تاريخ ثابت
- نحتجز استضافتك أو حساباتك لتبقى معنا
- نحاسبك على إصلاح عيوب ما سلّمناه
- نضيف نطاقًا بصمت وندع الفاتورة تشرح
- نختفي بعد أسبوع من الإطلاق
فريق صغير، وبلا تسليم وتسلّم
من يجلس معك في الاستشارة الأولى يبقى في المشروع. لا شيء يُرمى لفريق لم تلتقِ به.
- 01
المنتج والنطاق
يحوّل الطلب إلى شيء قابل للبناء، ويقرّر معك ما ينتظر.
- تأطير المشكلة
- نطاق وعرض مكتوبان
- قرارات الأولوية أثناء البناء
- 02
تصميم الواجهات
يثبّت الشاشات والمسار بينما تغييرهما لا يكلّف شيئًا.
- تصميم الشاشات والمسار
- جولات مراجعة مع فريقك
- أصول تبقى لك
- 03
الهندسة
يبنيه — ويب أو أندرويد أو iOS — ويحفظ كل مرحلة قابلة للفتح والاختبار.
- تطوير التطبيق
- التكاملات والبيانات
- الاختبار قبل تسليم أي مرحلة
- 04
الدعم والصيانة
يبقى متاحًا بعد الإطلاق، بشروط اتُّفق عليها قبله.
- الإصلاحات والتصحيحات
- التحديثات والمكتبات
- الجولة التالية من الميزات
الجزء الذي لا يمكننا ادّعاؤه بأنفسنا
الحكم على ما إذا كانت طريقتنا تعمل فعلًا ليس من حقّنا.
“حدّدوا أولًا ما نحتاجه فعلًا قبل بناء أي شيء، فلم يُهدر شيء. والتقدير كان مكشوفًا من البداية.”
“بدأنا بأبسط نسخة ثم أضفنا حسب الأولوية. هذه الطريقة تناسب فريقًا صغيرًا مثل فريقنا.”
“تطبيقنا القديم استُكمل بدلًا من هدمه وإعادة بنائه. التواصل كان سهلًا وكنا نعرف دائمًا أين وصلنا.”
أخبرنا بما لا يعمل
لا تحتاج مواصفات ولا ميزانية للبدء. وصف المشكلة يكفي لمحادثة أولى.