تخطَّ إلى المحتوى
مهند بكار
المدونة

ملاحظات

دقيقتان قراءة

بناء الأشياء الصغيرة عن قصد

معظم المشاريع الجانبية تفشل لأن نطاقها يُحدَّد كما لو كانت شركات. دفاع عن أعمال أصغر قابلة للإنجاز.

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

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

النمط

التسلسل المعتاد يبدو هكذا:

  1. مشكلة ما مثيرة للاهتمام.
  2. تُعرَّف النسخة الأولى بسخاء، لأن تخيّل الشيء الكامل سهل.
  3. يمر أسبوعان. الجزء المثير للاهتمام أُنجز، والعمل المتبقي هو الحسابات والتهيئة الأولى والإعدادات والحالات الحدّية.
  4. تهبط الدافعية. يصبح المشروع مجرد مجلد آخر.

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

تعريف أصغر للإنجاز

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

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

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

القيود جزء من التصميم

تشغيل الخدمات على Raspberry Pi تمرين مفيد للسبب نفسه. العتاد بطيء، والذاكرة محدودة، وكل ما تضيفه له تكلفة ظاهرة. لا يمكنك إضافة اعتمادية باستخفاف.

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

القيد لا يجعل البرمجيات أفضل بحد ذاته. إنه يجعل المقايضات مرئية، وهذا هو الجزء المفيد.

الإنجاز مهارة

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

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

ما أحتفظ به

ثلاث قواعد أحاول تطبيقها الآن:

  • عرّف النسخة الأولى على أساس شخص واحد يستخدمها مرة واحدة.
  • اكتب ما هو مستبعد صراحةً، والتزم به.
  • أجّل الهيكل الداعم (الحسابات، والفوترة، والإعدادات) حتى يوجد دليل على الحاجة إليه.

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

بقلم

مهند بكار

متخصص تقني ومفكّر أنظمة وبانٍ يعمل بيديه عبر البرمجيات والتكاملات والتسليم التقني.

تواصل معي
https://mohannadbakkar.com