اسمي ألكسندرا كامزيفا ، أعمل كمحلل أنظمة لمدة 9 سنوات ، منها 3.5 سنوات في لامودا. لقد قرأت كثيرًا ، وحلل الوثائق الحالية وأنشئ واحدة جديدة. في عملي ، أقوم دائمًا ببناء المعلومات وجعلها مريحة قدر الإمكان.
مزايا الوصف الجيد للنظام هي:
- تساعدك في العثور على المعلومات التي تحتاجها بشكل أسرع وأسهل من الوصف غير المنظم ؛
- يقلل من مخاطر فشل المشروع ؛
- يسهل على الموظفين الانضمام.
لقد صنعنا نموذجًا لمثل هذا الوصف يمكن لأي فريق استخدامه. في هذه المقالة ، سأخبرك بأمثلة ما دفعنا إلى إنشاء قالب وصف النظام ، وتاريخ إنشائه وكيف يتم استخدامه الآن في Lamoda.
ما هو القالب ولماذا هو مطلوب
بادئ ذي بدء ، سأصف فهمي للنمط. لنتخيل أنني بحاجة لإيجاد سيارة صغيرة في غرفة غير مرتبة. إنها ليست حقيقة أنني أستطيع التعامل معها. لكن يمكنني أن أخطو بالخطأ على جزء الليغو.
تخيل الآن أن جميع الألعاب مرتبة في أماكنها وفرزها. أستطيع أن أرى مقدمًا أي صندوق توجد فيه جميع السيارات ، وسوف أجد الصندوق الذي أحتاج إليه بشكل أسرع وأسهل ولن أضيع أعصابي عليه.
وبالمثل مع الوثائق. القالب هو مثل هذا الطلب. لقد وضعنا إطار عمل لوصف نظام يمكن لأي فريق استخدامه.
في أي ظروف نعمل مع التوثيق
تمتلك Lamoda أكثر من 100 نظام أتمتة تسليم الطلبات ، ومركز الاتصال ، والمستودعات ، واستوديو الصور ، وغيرها من العمليات التشغيلية والتجارية. يشارك أكثر من 300 مهندس في التطوير والدعم. قد يحتاج أي منهم إلى وصف لأي من هذه الأنظمة المائة.
يصف كل فريق نظامهم بشكل مستقل في مساحة منفصلة في منطقة التقاء. يشارك القائد التقني بالضرورة في التوثيق ، لأنه ملزم بتسجيل المعلومات. أيضًا ، يتم وصف النظام من قبل المختبرين والمطورين النشطين الذين يشعرون بالأسف لمجرد فقدهم لمعرفتهم وبالطبع المحللين ، لأن التوثيق هو أحد أدواتنا الرئيسية.
قد يبدو أن هذه الحرية تؤدي إلى الفوضى. لكن الأمر ليس كذلك ، لأن لدينا ثقافة الشركة: موقف مسؤول تجاه التوثيق ، مشاركة مفتوحة للمعرفة ، عادة تسجيل أعمال المشروع والنظام. تطور هذا التقليد جزئيًا بسبب المشاريع غير الناجحة. أثبتت الحوادث لفرق التطوير مدى أهمية توثيق عمليات ووظائف النظام.
فيما يلي سوف أسلط الضوء على بعض الحالات التي أدى فيها التوثيق المربك أو عدم وجودها إلى مشاكل.
فقط أضف زرين
المشكلة الأولى التي دفعتنا إلى إنشاء قالب - لم يكن لدينا وصف لبعض الأنظمة ، مما أدى إلى إخفاقات وتحسينات.
كان لدينا مشروع إدارة الطلبات الذاتية (SOM). قررنا إضافة زرين لحساب العميل الشخصي: "تاريخ التحويل للتسليم" و "إلغاء الطلب". قبل ذلك ، يمكن للعميل فقط إلغاء أو إعادة جدولة الطلب عن طريق الاتصال بمركز الاتصال. من الواضح أن بعض المشترين لم يكن لديهم الوقت أو الرغبة في التواصل مع المشغل. نتيجة لذلك ، يمكن لمندوب المبيعات إحضار طلب غير ضروري أو عدم العثور على العميل في المنزل. في مثل هذه الحالات ، تتحمل لامودا التكاليف. كان المشروع ضروريًا وهامًا.
يبدو أن إضافة زرين! في الواقع ، كان هناك الكثير من المنطق وراءهم في الأنظمة الأربعة. يمر تغيير الترتيب عبر نظام المعالجة - وحدة ضخمة ضخمة حيث يمكنك لمس شيء ما في مكان والتصوير في مكان آخر. لسوء الحظ ، لم يتم وصف التفاصيل الدقيقة لعملها في الوثائق ، ولم ينتبهوا لذلك أثناء تصميم المشروع. بعد الإصدار ، لم تعمل الأزرار كما هو متوقع وتم التراجع عنها. ونتيجة لذلك ، استغرق هذا المشروع ستة أشهر بدلاً من شهرين.
بالطبع ، حصلنا على هذه النتيجة ليس فقط بسبب نقص الوثائق. ولكن إذا كان لدينا وصف واضح لعمليات إلغاء ونقل أمر ما ، فربما تكون النتيجة مختلفة.
الصعود المعقد
المشكلة الثانية التي دفعتنا إلى إنشاء نموذج هي تعقيد الإعداد. جئت للعمل في فريق نظام معالجة الطلبات. للانغماس ، قرأت الوثائق في مساحة النظام وفي ثلاثة أقسام وجدت ثلاثة أوصاف مختلفة للجوهر الرئيسي لنظامنا - حالة الطلب.
في هذه الحالة ، لم ينجح الأمر في تسهيل عملية الإعداد. لم تساعد هذه الوثائق في نقل المعرفة إلى الزملاء الذين لم يسبق لهم التعرف على نظامنا.
مشكلة قائمة فارغة
الشرط الثالث لإنشاء النموذج هو مشكلة اللوح الفارغ. لكل نظام جديد ، يجب على القائد التقني توفير المساحة المناسبة من البداية. يفكر القائد الفني في الأقسام التي يجب إنشاؤها. قبل إنشاء النموذج ، قام الموظف بدراسة المساحات الأخرى والنظر في الأقسام المستخدمة والتي ستكون مفيدة لنظامه. كان هذا يستغرق وقتًا طويلاً.
كيف أنشأنا القالب وماذا حدث
كل أسبوع ، يعقد محللو النظام وقفة ويناقشون القضايا التي تتم مواجهتها في المشاريع وليس فقط. واشتكى الزملاء أكثر من مرة من صعوبة العثور على المعلومات وفهم مساحات الأنظمة المختلفة. نظرًا لأننا نحرق باستمرار بسبب هذا ، فقد قررنا أن نأخذ بأيدينا وصف الأنظمة التي نعلق عليها. وبعد ذلك سيكون من الواضح ما يجب القيام به.
أولاً ، حددنا سمات النموذج الجيد:
- .
- . , , . , . .
- . , , , .
- .
بعد ذلك ، قمنا بتحليل الوصف الحالي للأنظمة المختلفة وحددنا الأقسام المشتركة:
في قسم المشاريع والميزات ، كانت هناك مواصفات لتطوير المشاريع. يحتوي قسم التطوير وضمان الجودة على معلومات محددة للتطوير والاختبار. في قسم الحوادث تم وصف الحوادث التي وقعت في النظام وحلولها.
شاركنا فكرة النموذج مع زملاء آخرين في اجتماعات غير رسمية (وجبات غداء في المطبخ ، وقفات ، وفرق مجاورة تتحدث معها بشكل دوري) وقمنا بإنشاء مجموعة عمل من المتطوعين. كانوا ممثلين عن كفاءات مختلفة: مديرين ، ثلاثة عملاء تقنيين واثنين من المختبرين. أضافوا الأقسام التالية إلى النموذج:
بعد ذلك ، اختبرنا قالب وصف النظام مع زملاء يتمتعون بكفاءات واسعة: رؤساء أقسام تكنولوجيا المعلومات ، وخبراء تقنيون ذوو خبرة ، وقواد اختبار لمشاريع التكامل الكبيرة. انتهى بهم الأمر بإضافة بعض الأقسام المفيدة:
التحقق من جودة النموذج
قمنا بفحص المستند الناتج مقابل تعريفنا للقالب الجيد في Lamoda:
- يساعدك في العثور على المعلومات التي تحتاجها بشكل أسرع وأسهل. لدينا هيكل مناسب: أتحرك على طول الشجرة وأفهم ما يقع وأين. إذا كنت بحاجة إلى معلومات حول عمليات النظام (على سبيل المثال ، إلغاء طلب) ، فانتقل إلى "وصف العمليات الرئيسية".
- لا يتم تكرار معلومات النظام بسبب ذرية الأقسام. على سبيل المثال ، يمكنك وصف المواد القابلة للطباعة في قسم واحد ، ثم الرجوع إليها من قسم "وصف العمليات الرئيسية" حتى لا تكرر المعلومات نفسها.
- . Lamoda, . , -. — .
- . .
لقد صنعنا نموذجًا لطيفًا لوصف أنظمة Lamoda. آمل أن تجده الشركات الأخرى مفيدًا أيضًا. أريد تحديد الأقسام الثلاثة التالية:
وصف العمليات الرئيسية للنظام . نعم ، يبدو واضحًا أن هذا القسم ضروري. ولكن لسبب ما لا يكون موجودًا دائمًا ، كما كان الحال معنا مع أزرار إلغاء ونقل أمر. إذا وصفنا عمليات الإلغاء وإعادة الجدولة مسبقًا ، فسيتم تقليل مخاطر فشل المشروع.
قوائم المراجعة- قسم يذكر بالأهم في العملية المنتظمة. على سبيل المثال ، لدينا "قائمة تحقق لربط طريقة دفع جديدة" في وصف نظام إدارة طرق الدفع. تنص على أنه يجب علينا تنسيق إضافة أو تغيير طريقة الدفع مع قسم المحاسبة ومع مركز الاتصال والتسليم ومع وحدات الأعمال الأخرى.
بمجرد أن نسينا إبلاغ مركز الاتصال بالتغيير في طريقة الدفع. وعندما اتصل العميل بمركز الاتصال الخاص بنا وسأل عنه ، لم يستطع المشغل قول أي شيء. أدى ذلك إلى تضارب بين مركز الاتصال وفريق التطوير المسؤول عن طرق الدفع. بعد هذه الحادثة ، نقوم بإنشاء قوائم مراجعة لإطلاق المشاريع الرئيسية ، وربط شركاء جدد ، إلخ.
صفحة الفضاء الرئيسية- قسم يحتوي على معلومات حول سبب الحاجة إلى هذا النظام ، وعن تكوين الفريق وأصحاب المصلحة. يجب علينا تنسيق تغييرات النظام وموارد التطوير مع أصحاب المصلحة. لذلك من الرائع أن تتمكن من الحصول على هذه المعلومات بمجرد النظر إلى Confluence.
هناك ، نشير إلى معلومات حول تكوين الفريق من أجل فهم من يجب الاتصال به بخصوص أسئلة حول النظام. كما أنه يساعد المبتدئين الذين يعانون من تورم الرأس. إنه لأمر رائع أن يتمكن الموظف الجديد من التجسس على من تحدث للتو ، ومن يكون هذا الشخص ، وما هو دوره وما هو اسمه.
كيف بدأت في استخدام النموذج على نظامي
- بادئ ذي بدء ، قمت بإنشاء الأقسام المطلوبة من النموذج دون ملء. كان الأمر سهلاً ولم يستغرق أكثر من 30 دقيقة.
- ثم كان الأمر الأكثر صعوبة هو: عقدنا اجتماعات منتظمة مع المسؤول التقني ، حيث بدأنا في تحليل توثيق نظامنا. في الاجتماع الأول ، قسمنا الصفحات الحالية إلى ثلاثة أكوام.
لقد أرسلنا كل شيء غير ذي صلة وغير ضروري إلى الكومة الأولى. حذفنا هذه الصفحات أو أرسلناها إلى الأرشيف.
الكومة الثانية ضرورية ، لكنها غير ذات صلة. لقد وضعنا علامة على الصفحات على أنها غير ذات صلة ، وأنشأنا مهمة في Jira ثم حدّثنا هذه المعلومات وفقًا لتراكمنا.
الكومة الثالثة هي الأبسط. عندما يكون كل شيء واضحًا ، تكون الأقسام ذات صلة - لقد نقلناها إلى المكان الصحيح.
قبل هذه الاجتماعات ، كانت أوصاف العمليات والهندسة المعمارية ، وملاحظات المختبرين والمطورين ، مبعثرة في جميع أنحاء المكان. لم يكن هناك أيضا صفحة رئيسية.
لمدة 6 ساعات من الاجتماعات ، حصلنا على نتيجة ممتازة. من الفوضى ، قمنا بتشكيل الهيكل والنظام. يمكنك الآن معرفة مكان العثور على أوصاف للعمليات ومعلومات حول البنية وعن الحوادث. والأهم من ذلك ، لدينا الآن صفحة رئيسية. هنا تمت كتابة سبب الحاجة إلى نظام معالجة الطلبات ومن هو صاحب المصلحة.
يشارك نظامنا الكبير في جميع خطوط الأعمال تقريبًا. لكن لم يكن لدينا أصحاب مصلحة من قبل. أثناء قيامنا بالصفحة الرئيسية ، ناقشنا مع CTO مع من يجب تنسيق تغييرات النظام. وبالتالي ، تم تحديد الزميل الذي أعطى الأولوية للتحسينات. يبدو الآن أنها حقيقة ممتعة أن إنشاء الصفحة الرئيسية أدى إلى ظهور صاحب المصلحة.
كيف وزعنا النموذج
تم تلقي نتائج مماثلة حول استخدام النموذج من قبل محللين آخرين قاموا بتطبيقه في اتجاهاتهم الخاصة. وبالتالي ، قمنا بتغطية معظم الأنظمة التي شاركت بنشاط في العديد من مشاريع التكامل.
كان لدينا فرق كانت أنظمتها غالبًا ما تشارك في مشاريع التكامل ، لكن لم يكن هناك وصف كافٍ عنها. عادة ما تكون هناك حاجة إلى التوثيق ، لذلك لم تكن هناك حاجة لبيع الفكرة.
أظهرنا التجربة الناجحة لتطبيق القوالب على العملاء المحتملين التقنيين ومديري هذه الفرق. قامت بعض الفرق ، بناءً على مثالنا ، بترتيب وثائقها بنفسها ، بينما طلب البعض الآخر مساعدة المحللين.
ملاحظات حول النموذج
نموذجنا ليس وصفًا إلزاميًا أو إلزاميًا للنظام. يتخذ الزملاء النموذج كأساس ، إذا كانوا بحاجة إليه ، ويقومون بتحريره ليناسب احتياجاتهم. على سبيل المثال ، يقومون بنقل التبادلات من قسم فرعي إلى قسم إذا كان النظام يتكون منها بشكل أساسي.
تختلف جميع أنظمتنا في الوصف ، لكن الهيكل العام والمنطق العام لا يزالان محفوظين. يمكننا الآن العثور بسهولة على معلومات حول العمليات التي يتكون منها النظام ، وبنية النظام ، وما إلى ذلك.
في لامودا ، نحب مشاركة المعرفة. لدينا مشاريع تكامل كبيرة تحفز ذلك. نرسل روابط لأوصاف محدثة للأنظمة ، ويتلقى الزملاء المعلومات الضرورية دون أسئلة إضافية إلى العملاء المتوقعين التقنيين الذين تم تحميلهم بالفعل.
بعد عامين من إنشاء النموذج ، أجريت مقابلات مع الزملاء وتلقيت تعليقات جيدة من الأغلبية. يستخدمون القالب وتحرير الهيكل كما يحلو لهم.
ولكن هناك أيضًا أشخاص يعتقدون أننا لسنا بحاجة إلى وثائق ونموذج. في الأساس ، تعتقد الآن فرق تلك الأنظمة التي لا توجد فيها حاجة ملحة لتوثيق شيء ما.
إنهم يعملون على أنظمة بالكاد تتغير: لا توجد مشاريع تكامل ، وليست هناك حاجة لإخبار الزملاء الآخرين عن هذه الأنظمة ، وبالتالي ، لا توجد رغبة في التوثيق.
أعتقد ، قبل البدء في مشروع كبير ، ستذكرك ثقافتنا والمطبات الكبيرة بتوثيق العمليات الرئيسية ، وسوف يغيرون رأيهم.
نصيحة لنفسك ولأولئك الذين يريدون تكرار طريقنا
- , , , , . , .
- . , . , .
- , , . : , , . . , .