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