👨🏼‍🔬 🧗🏾 🛀🏽 محلل أعمال وأنظمة. ما تحتاج إلى معرفته 🔖 💫 👶🏿

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

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

لمن ستكون المقالة مفيدة في رأيي:

بداية محللي الأعمال / النظام ؛
المحللون الذين يريدون الاستمرار في ضخ أستاذهم. مهارات
ربما مديري التوظيف.

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

ومع ذلك ، فإن كل هذه المهارات على الأقل لن تكون غير ضرورية وستجعل المحلل أكثر كفاءة في أسئلته. بالطبع ، عليك أن تفهم أنني لم أذكر جميع مهارات وقدرات المحلل (نفس الرموز ، ومهارات العمل ، و sql ، وما إلى ذلك).

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

تخلص من المتطلبات الغامضة في المراحل المبكرة

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

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

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

لا تخف من مراجعة العميل لمتطلبات المتطلبات

لقد التقيت بالحالات التي عملت فيها عندما تم وصف بيان التطوير دون تحديد هدف العمل: ما الذي سيساعده هذا الإنجاز على وجه التحديد في العمل؟ ما الألم الذي سيخففه هذا التحسين من العمل؟

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

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

اطلب حضور عميلك في اجتماعات العمل

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

, — UX- — « », , . : , , windows-, . , .

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

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

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

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

كما اتضح فيما بعد ، لم يفهم رئيس القسم على الإطلاق لماذا كل هذه التحسينات وكيف ستساعد في تحسين العمليات في مجال مسؤوليته.

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

أعرض مجال الموضوع للمطورين

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

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

علم العميل الإجابة على السؤال "ماذا؟" بدلاً من صياغة المتطلبات بتنسيق "كيف"

يجب على العميل عدم صياغة متطلبات العمل / المستخدم من موقف "كيف": نحن بحاجة إلى زر على هذه الشاشة لإنشاء تقرير ؛ نحتاج إلى رابط لنظام خارجي في هذا القسم ؛ إلخ

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

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

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

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

تأكد من تقسيم المستخدمين إلى فئات

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

قم بتقسيم مستخدمي النظام إلى أدوار ، والوظيفة التي تم تحسينها لدور واحد ، لا "تلطخ" تحت دور آخر.

مرة واحدة ، في إطار النظام ، قمنا بتنفيذ عرض قائمة المعاملات مع العملاء.

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

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

تطبيق أفضل الممارسات من UX: حل المشكلات - نماذج المستخدم. إقناع العميل بفصل متطلبات كل حرف.

بنشاط استخدام العصف الذهني التحليلي

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

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

إذا كنت عالقًا في Waterfall ، فلا تيأس وتحرك نحو Scrum

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

لا تشوه العميل أبدًا.

نعم ، هناك جميع أنواع العملاء. هناك من هم غاضبون حرفيا. ومع ذلك ، يجب على محلل الأعمال حل هذه المشكلة إما بمفرده أو بمشاركة مدير ، ولا ينبغي بأي حال من الأحوال أن يخرج "شجارًا من الكوخ" - في الفريق.

يجب أن يكون الفريق متحمسًا جيدًا للعمل ، ودور محلل الأعمال في عملية تكوين الحافز هو المفتاح.

لا تقم بالمقاطعة

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

حاول واستمع إلى المحاور ، واستمع إليه.

تخلص من الكلمات الطفيلية

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

 :
-   "    ".
-   ", :    ".

تحليلات النظام

عند تعيين المهمة على الأمام والخلف ، حاول وصف مخطط التسلسل

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

من أجل "رسم" سلسلة من المخططات بسرعة ، استخدم المكوّن الإضافي PlantUML من أجل Confluence. بدا لي أنه من الأسرع كتابة الرمز من ضبط موقع الكتل والسهام ذات الأقلام. لكن كل شخص في هذا الجزء لديه تجربته الخاصة وتفضيلاته الخاصة.

تعلم محرر Swagger

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

استخدم أداة المطور بنشاط في المتصفح المستهدف لتحليل طلبات العملاء وردودهم من الخادم

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

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

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

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

 :
-   " JavaScript".   JSON, , HTML, http / https,   .
- . , .  " . , , ".      ,  ,   ,   .

بالاضافة

انغمس في تجربة المستخدم

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

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

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

 :
-   "  ".
-   "   ".
-   ".   ".
-   ".   ".

***

شكرا لقراءة المقال! سأكون ممتنًا أولاً للتعليقات. ثانياً ، للحصول على توصيات حول الأدبيات والمصادر وأفضل الممارسات والخبرة الشخصية والتوصيات.

محلل أعمال وأنظمة. ما تحتاج إلى معرفته

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

تحليلات النظام

بالاضافة

More articles: