إدارة المعرفة: ما هي المستندات المطلوبة وما يجب إصلاحها

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

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

برامج المشاريع الثقافية

ينقسم تاريخ صناعة تكنولوجيا المعلومات إلى مراحل - كل منها له نهجه الخاص في إدارة المشروع: أفكاره الخاصة عن النجاح ، ومعايير الجودة ، وتنظيم العمل. كتب أنتوني لاودر في عام 2008 كتاب "ثقافة مشاريع البرمجيات" (روابط إلى النص الأصلي وترجمة ومراجعة ستاس فومين ) ، والتي حدد فيها أربع فترات:

• علمي
• مصنع
• تصميم
• ثقافة الخدمة.

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



نبذة عن المتحدث: مكسيم تسيبكوف مهندس تكنولوجيا المعلومات ومحلل الأعمال ، الملاح والخبير في عالم Agile ، المنظمات الفيروزية وديناميكية لولبية

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

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


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

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

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

عند تطوير دليل للأسلوب ، يركزون على UX. الوثائق هي نفسها - في دليل نمط Doc للمشروع.

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

الوثائق - للاتصال

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

يتم تطوير شكل المستندات ، وكذلك الواجهات ، من أهداف الاتصال.

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

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

• لصنع القرار
• الاتصالات الحالية.
• الحفاظ على المعرفة في الوقت المناسب ("لي في ستة أشهر") ؛
• نقل المعرفة إلى أشخاص آخرين ؛
• مساعدة في العمل الحالي ، الخ

كل وجهة لها نوع الوصف الخاص بها ، - وجهة نظر - طريقة الوصف الخاصة بها .

معيار جودة الوثائق

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

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

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

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

النقطة المهمة التالية التي يجب تذكرها عند تصميم نظام التوثيق: "لماذا" و "لماذا" أكثر أهمية من "ماذا" . يصف استخدام الحالة ما يجب القيام به في النظام ، وفي قصة المستخدم ، يوجد جزء "لماذا": "بصفتي <> أريد < -> أجل < > ". علاوة على ذلك ، يمكن اعتبار تنسيق قصة المستخدم كقالب ، أي يجب أن تكون جميع الأجزاء. لم يخرجوا على الفور من التجربة ، لكننا نعرف الآن أن "السبب" مهم للغاية. الهدف من قصة المستخدم ، والهدف من أي متطلبات هو التواصل الموزع زمنياً للعميل (المستخدم) مع المطور والمحلل كوسيط.

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

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

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

نقوم بتصميم وثائق المشروع

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

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

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


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


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

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

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


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


نموذج V هو إرث من عصور R&D و RUP. منذ ذلك الحين ، تغيرت الثقافات ، والتصميم الحديث هو أوسع بكثير. بدلاً من المفهوم ، ظهرت أشياء مثل احتياجات المستخدم وفرص العمل. على اليمين ، بدلاً من الصيانة لمرة واحدة ، كان هناك تسليم للإصدار التالي ودعم مستمر في الوقت المناسب.

المتطلبات

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

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

• فكرة المشروع - فرصة للعمل: ماذا ، لمن وكيف؟
• جدوى وجدوى الفكرة ؛
• اهتمامات وتوقعات أصحاب المصلحة الرئيسيين من نتيجة المشروع ؛
• تصميم المنتج والاستخدام المقصود.
• تقييم الموارد اللازمة للمشروع.

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


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

إذا تحدثنا عن رضا المستخدم ، فظهر أيضًا هناك مجموعة من التخصصات: مصمم واجهة المستخدم المسؤول عن رضا المستخدم عن المظهر وسهولة الاستخدام - وعن الاستخدام ومتخصص UX الذي يعمل على إتقان الواجهة البديهية. هذه الحدود تتغير أيضا. في مشروعك المحدد ، قد يكون الأمر مختلفًا ، نظرًا لأن تطوير المشروع هو شيء واحد ، حيث يوجد نظام تدريبي ، ولن يذهب المستخدم إلى أي مكان مثل محاسب 1C ، لأن هذا هو مكان عمله. ومسألة أخرى تماما ، على سبيل المثال ، تطوير الهاتف المحمول. إذا كان معدل دوران موظفي المتجر هو أن يعمل البائع أو أمين المتجر في المتوسط ​​لمدة 3-6 أشهر ، فستكون مسألة تطوير تطبيق الهاتف المحمول للعمل خلال يومين وليس أسبوعين من التدريب ذات صلة.


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

التحف التركيز مخصص

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

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

المخططات ER أو المخطط الطبقي للتطبيق أو المكونات الرئيسية موجودة في الوثائق. لكن الكذب في الوثائق أو معلقة على الحائط في كل وقت هو فرق كبير. عندما يفكر أحد المطورين: "لكن لا تحفر حفرة في واجهة برمجة التطبيقات (API) أعلى النموذج ذو الطبقات بشكل غير مباشر؟" ، لأنه سيؤدي في الواقع إلى تقليل وقت التطوير لميزة معينة (ولكن بعد ذلك يأتي مع مرافقة) ، وفي الوقت نفسه ، يعلق المخطط أمام عينيك ، ومن المرجح أن يرى أنه سيكون حفرة. إذا كان الرسم التخطيطي موجودًا في مكان ما في المستند ، فيمكنك نسيانه مؤقتًا ، وكتابة رمز ينتهك الهيكل بشكل سريع.

مشروع المعرفة الحركة

في عملية Scrum - هناك نقاط خاصة لتوليد المعرفة حول حركة المشروع:

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

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

أوصاف طويلة الأجل

عند إنشاء أوصاف طويلة الأجل ، فإن السؤال الرئيسي هو تحديد الحالات التي سيدعمها الوصف . يمكن أن تكون الخيارات مختلفة تمامًا:

• علم مستخدمًا جديدًا العمل مع النظام.
• تقديم معلومات مرجعية عن الوظائف النادرة للنظام.
• تقديم التصميم النظري للنظام إلى مطور جديد.
• للمساعدة في استدعاء جزء الجهاز للنظام إلى المؤلف لإجراء تحسينات.
• صف نظام وحدة الجهاز للتطوير بواسطة مطور جديد.
• توفير معلومات حول جهاز النظام إلى مهندس الدعم.

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

الوصف الشامل مفصل ومكلف وغير مناسب وغير ضروري أيضًا ، لأنه لا يمكنك العثور على المعلومات اللازمة فيه بسبب تفاصيله.

من الضروري إصلاح الغرض ، وتقييم الامتثال ، وتذكر: كلما كانت الوثيقة أكثر تفصيلاً ، كانت التكلفة أعلى.

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

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

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


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

التواصل ينقل المعاني

دعنا نحفر قليلاً ونناقش أن التواصل يحمل معنى.


كل شيء يبدأ بافتراض عصر RUP ، الذي أنتج النهج الموجه للكائنات (OOP). إذا قمنا بتحليل العالم إلى أشياء واتصالات ، فسنحصل على صورة واضحة بشكل لا لبس فيه للعالم.


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

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


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

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

المصدر المتعامد للمخططات خارج تكنولوجيا المعلومات هو منهجية مصلحة الارصاد الجوية (انظر التقرير "التواصل مع بنية مختلفة من التفكير - التصنيف مقابل علم الفلك" ).

مبادئ إدارة الوثائق

1. المستند ليس له مؤلف.

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

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

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

2. يتم إنشاء المستند تدريجيا.

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

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

3. المحتوى هو أكثر أهمية من النموذج.

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

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

4. نترك آثار.

يتعلق هذا المبدأ المهم الآخر بمحاضر الاجتماعات وملخصات المحادثات. وهذا هو ، تحدثنا مباشرة ، والدردشة وكتابة ملخص الجمل 1-2 في Task Tracker. , , -, , .

. , , , . . , , . - , . , .

— , , .. , - , -, , , , . : , .

:

• Archimate.
• Archimate.
• - , Domain Driven Design.
• OMG Essence.
• viewpoint' ISO 42010.

. , , .

, , . , , , , , , , , : , .

, Wiki — , , , , , .. , - . CUSTIS MediaWiki. , Jira Confluence, OpenSource http://4intra.net. , , wiki- , .

— . Slack, Task Tracker Google Docs, .

. , wiki. wiki git, - wiki- , .

— , .

, , .

, « » . , : « , ?» , . , , « » , British Petroleum. , , , .


. . , .

, , 5–7 , . .

, , , C# , . .

— . — , wiki — , . . , , , . , , .

— , . BBC , , , . , , . , , .

IBM: — .

IBM : , - , . , . IBM , . , , , , , , , « , , ». . — , , .

• .
• .
• , .
• , .
• — .

mtsepkov.org (, , wiki) , agile , .

— . , : , , , , Knowledge Conf .

25 TeamLead Conf . , .