تنظيم المعلومات لمنظمة تطوير البرمجيات

Question

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

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

المحتوى الذي لدينا اليوم:

1. معلومات التصميم الفني / مستندات الهندسة المعمارية
2. دقائق الاجتماع، عناصر العمل، إلخ
3. خطط المشروع وخريطة الطريق
4. تنظيم الأعمال MGMT Info - السفر، معلومات الميزانية، معلومات headcount، الخ
5. صفحات المشروع مع تحليل الأعمال، متطلبات، إلخ

فيما يلي بعض مشكلاتنا الرئيسية:

أين يجب أن تذهب البيانات - Confluence Wiki مقابل موقع SharePoint مقابل موقع إنترانت - نحن نستخدم التقاء ويكي ل # 1، # 2، # 3، # 5 ولكننا نستخدم أيضا SharePoint ل # 1، # 3، # 4، # 4. نحاول معرفة ما إذا كان ينبغي لنا أن نولي كل عدد إلى مكان محدد لجعل الأمور تتفق. نحن نستخدم SharePoint المزيد من بنية الدليل المستندات، ونحن نستخدم التقاء لمزيد من المحتوى القابل للتغيير ADHOC.

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

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

أيضا، أي قصص أخرى من الطرق الجيدة لتحسين إدارة الاتصالات والمعلومات ORG

Answer 1

السبب الجذري الأساسي لكلية المعلومات هو "لا ملكية".

يتم تعيين الناس للمشاريع. تنتهي المشاريع (أو إلغاؤها)، والمستقل الناس وتبقى الوثائق وراء جمع "الغبار" وتصبح فوضى معلومات.

هذا صعب منعه. لا يتناول Wiki vs. SharePoint الفوضى، فإنه يغير فقط قاعدة التكنولوجيا التي تستخدم لتجميع الفوضى.

دعونا ننظر إلى الفوضى

1. معلومات التصميم الفني / مستندات الهندسة المعمارية. القديمة لا يهم. هناك حالي وهناك غير ذي صلة. ويكي.

   معلومات التصميم القديمة العام الماضي هي - عفا عليها الزمن.

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

3. خطط المشروع وخريطة الطريق. المسائل المتراكمة Sprint - هذا هو ما يطمح إليه "خطة وخارج الطريق". إذا كان عليك استكمال خططك بخريطة الطريق، فربما يجب أن تتخلى عن التخطيط واستخدام Scrum فقط والحفاظ على Trustlog الحالي.

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

4. التنظيم الأعمال MGMT Info - السفر، معلومات الميزانية، معلومات HeadCount، إلخ. هذا مزيج غريب من الأشياء المهيكلة للغاية (الميزانية والتنظيم) والأشياء غير المنظمة ("السفر"؟)

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

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

   التاريخ نادرا ما يهم. مفهوم شخص ما في وقت بداية المشروع لما لا يهم المتطلبات أكثر من ذلك بكثير. ما تطور المتطلبات في شكلها النهائي أكثر من أي تاريخ. هذه مادة ويكي.

كم عمر "قديم جدا"؟لقد عملت مع العملاء الذين لديهم برنامج يبلغ من العمر 30 عاما. البرنامج - من الواضح - هو مناسب لأنه في الإنتاج.

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

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

بمجرد انتهاء الصيانة، تم تخفيض قيمة المواصفات "الأصلية".

كيفية تنظيفه؟إذا قمت بإنشاء صفحة Wiki أو موقع SharePoint، فإنك تملكها إلى الأبد. عندما تغادر، فإن بديلك يملك إلى الأبد.

كل مدير هو 100٪ مسؤول عن كل قطعة من المعلومات يخلق موظفوها. لديهم لحذف الأشياء. الحل الضعيف هو "أرشفة" الأشياء. وهو مجرد طريقة مهذبة لقول "حذف" دون "D-Word".

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

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

تكلفة التخزين منخفضة نسبيا. تظهر تكلفة التنظيف أعلى.

كيفية إيقاف سلسلة البريد الإلكتروني؟
رفض المشاركة. قم بإنشاء حملة "كسر السلسلة" التي تركز على استبدال سلاسل البريد الإلكتروني مع تحديثات Wiki (أو تحديثات SharePoint).

تأكد من توفر Wiki الروابط وهي أسرع لتحريرها من بريد إلكتروني.

لا يمكنك إجبار الناس على التخلي عن حل مناسب حقا (بريد إلكتروني). عليك أن تجعل Wiki أكثر قيمة ومريحة تقريبا كبريد إلكتروني.

منحدر القيمة على الويكي. انخفض سلاسل البريد الإلكتروني. رفض الرد على سلاسل البريد الإلكتروني. رفض قبول "للقيام" بنود العمل من خلال البريد الإلكتروني.

Answer 2

يمكنك استخدام Confluence Wiki لتخزين المستندات كمرفقات وتعمل مسارات Wiki كمسارات ملف في SharePoint.

إعادة: بيانات بعنصر: لديك ملكية البيانات (كل شخص وفريق) وتأكد من أن النواتج للمالكين تشمل صيانة جميع البيانات.

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

تستخدم شركتنا و / أو فريقنا جميع هذه النهج من هذه الأساليب بدرجة من النجاح في الماضي

Answer 3

هل هناك سبب لعدم امتلاك الويكي الملفات؟

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

Answer 4

إدارة المعلومات الفعالة هي بالفعل مشكلة صعبة للغاية. وجدنا أن مبدأ "أبسط أفضل" يمكن أن يجعل المعجزات لحلها.

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

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

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

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