تحليل الأعمال

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

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

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

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

https://www.atlassian.com/agile/project-management/user-stories — كيف تُكتب قصة المستخدم.
https://www.nngroup.com/articles/definition-user-experience/ — مقال مفتوح عن تعريف تجربة الاستخدام. ليس كل مقالات الموقع مفتوحة.
https://www.gov.uk/service-manual — دليل الخدمات الحكومية: بحث، ومتطلب، وتحقق.