من يملك المعلومات - يمتلك العالم. كيف يتم تنظيم الاتصال ونشر المعلومات عن المشروع؟

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

من سيستفيد من هذا المقال؟

ستكون المقالة مفيدة للقادة وأعضاء فرق المشاريع الصغيرة المكونة من 5-10-15 شخصًا.

ماذا تستخدم ولماذا؟

نحن شخصياً نستخدم Slack للتواصل ومشاركة المعلومات.



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



أسباب استخدامنا لتطبيق Slack:

1. الراحة في تنظيم المحادثات الجماعية (القنوات)
2. وجود المواضيع - القدرة على إنشاء فروع الحوار
3. التفريق بين حوارات العمل والحوارات غير العاملة. العمل في سلاك. أخرى - في Telegram / watsap / في أي مكان
4. توافر ردود الفعل
5. توافر تذكير
6. القدرة على دمج Slack مع العديد من الأدوات

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

ما هي قواعد الاتصال في الفريق ولماذا؟

1. لا تتواصل في PM

نترك الاتصال في PM فقط في حالتين:

• مناقشة شيء يتطلب الخصوصية.
• Memasiks / النكات والفيضانات الأخرى.

لكل شيء آخر ، نستخدم قنوات اتصال مشتركة.

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



لماذا هذه القاعدة مطلوبة؟



هذه القاعدة ضرورية من أجل:

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

2. ضع علامة على من يذهب إليهم الاستئناف

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



عند الإشارة إلى شخص ما ، يجب عليك وضع علامة عليه.



عند مخاطبة عدة أشخاص ، ضع علامة على الجميع ، وليس كل من في القناة



لماذا هذه القاعدة مطلوبة؟



هذه القاعدة ضرورية من أجل:

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

3. الرد على الرسائل

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



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



لماذا هذه القاعدة مطلوبة؟



هذه القاعدة ضرورية حتى يعرف المرسل أن رسالته "لم تضيع".

4. استخدم الخيوط

يتمتع Slack بميزة مثل الخيوط - القدرة على إنشاء "سلسلة محادثات" وإجراء حوار فيها ، وليس في تدفق الرسائل الرئيسية.



هذه الميزة مناسبة تمامًا لمناقشة قضية واحدة.



لماذا هذه القاعدة مطلوبة؟



هذه القاعدة ضرورية حتى لا تحدث فوضى في التدفق الرئيسي للرسائل ، وبالتالي زيادة بنية المعلومات وسهولة التنقل خلالها.

5. سجل المحادثات التي جرت خارج Slack

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



لماذا هذه القاعدة مطلوبة؟



هذه القاعدة ضرورية من أجل:

1. تأكد مرة أخرى من أن المشاركين في الحوار فهموا بعضهم البعض بشكل صحيح
2. لم ننس ما اتفقنا عليه
3. كن على علم بما يجري من لم يقبل في الحوار ولكن اهتم بموضوع الحوار.
4. كان من الممكن الرجوع إلى نتائج المحادثة
5. ... ونفس الحجج من النقطة الأولى حول قنوات الاتصال المشتركة

يجب أن يكون للبروتوكولات عناوين وتتلقى الردود!



لا يجب أن يوضع كل شخص كمخاطبين ، ولكن يجب وضع أولئك الذين يعنيهم موضوع هذا الحوار.

6. ابدأ مكالمة / اجتماع إذا لم يتم حل المشكلة في 15 دقيقة من المراسلات النشطة

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



وكنتيجة للمكالمة - أرسل البروتوكول إلى الجميع.

7. عقد اجتماعات يومية كتابة

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

• ماذا فعلت البارحة؟
• ماذا سأفعل اليوم؟
• ما هي المشاكل التي لدي في طريقي؟

نعقد اجتماعات يومية من 11:30 صباحًا إلى 11:35 صباحًا في دردشة جماعية مخصصة. يكتب المدير أخيرًا - الساعة 11:36. كل من ألغى اشتراكه بعد أن يعتبر متأخرًا. يجب تنفيذ العمل التعليمي مع المتأخرين. يجب على الجميع أن يعلق رد الفعل تحت رسالة الجميع: العيون:. رد الفعل هذا هو تأكيد أن الجميع قد قرأ كل رسالة يومية.



قالب رسالتنا اليومية:

• ما الذي فعلته؟
  
  1. طريقة API / مرحبا
  
  2. طريقة API / Howareyou
• ماذا سأفعل؟
  
  1. طريقة API / وداعا
• الأسئلة:
  
  1. أليس ، إلى متى تعتقد أن مهمتك ستستغرق؟
• المشاكل:
  
  1. فشل النشر. مساعدة!

عند مناقشة الأسئلة / المشكلات ، لا تنس القاعدة رقم 6 - إذا لم يتم حل السؤال / المشكلة في 15 ، فإننا نضعها في الاعتبار.



بالنسبة للجزء الأكبر ، تستغرق أعمالنا اليومية 15 دقيقة من وقت الجميع ، مع مراعاة الوقت اللازم للاستعداد للرالي.



لماذا هذه القاعدة مطلوبة؟

هذه القاعدة ضرورية لقضاء وقت عمل الفريق بكفاءة. والصبر.



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

8. المكافأة: تناقش الفرق الداخلية بتنسيق نصي كل ما يتعلق بالمنتجات وعملية إنشائها

تجربتي الشخصية هي أن الحياة تتحسن عندما تناقش كتابة:

• حفز
• التصميم
• ادراك
• إجراءات العمل
• اقتراحات ومشاكل

من الناحية العملية ، هذا ليس ممكنًا دائمًا بنسبة 100٪.



بعد ذلك ، عندما تتم مناقشة شيء ما من القائمة أعلاه مباشرة ، يجب تسجيل نتائج المناقشة.



لماذا هذا مطلوب؟



من أجل حل المشكلات التالية في الفرق الداخلية:

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

كيفية إعداد رسول؟

من أجل ترتيب القنوات بشكل ملائم ، نستخدم نظام البادئة.



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



على سبيل المثال ، لدينا مشروعان - GoldFixing و Aurrency. بالنسبة لهذه المشاريع ، نستخدم البادئات التالية: gf لـ GoldFixing و aurm لـ Aurrency. ثم ستبدأ جميع القنوات المرتبطة بـ GoldFixing بالبادئة gf_ ​​وتبدو مثل gf_somechannel. وبالمثل مع Aurrency - ستبدو القنوات مثل aurm_somechannel.



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



يمكن تقسيم القنوات إلى 4 فئات:

1. بقالة

هذه هي القنوات المخصصة للمنتجات التي تم إنشاؤها داخل المشروع.



بادئة: prdct_ تناقش



القنوات في هذه الفئة كل تلك القضايا التي تتعلق بطريقة أو بأخرى بهذا المنتج أو ذاك.



وبالتالي ، إذا تم إنشاء منتجين في إطار مشروع GoldFixing - منصة ومكتب خلفي ، فإننا ننشئ القنوات التالية لهما:

• gf_prdct_platform
• gf_prdct_backoffice

2. المعلومات

القنوات في هذه الفئة ليست مخصصة للتواصل ، ولكن لنشر المعلومات.



البادئة: info_



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



وبالتالي ، إذا استخدمنا JIRA في مشروع GoldFixing ، فسنحصل على قناة gf_info_jira.

3. فريق

هذه قنوات مخصصة للفرق بناءً على مهنهم.



البادئة: team_



في القنوات الموجودة في هذه الفئة ، تتم مناقشة الموضوعات المرتبطة ببعض الانضباط المهني (الواجهة الأمامية / الخلفية / إلخ) ولا تتعلق بالتخصصات الأخرى.



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



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

4. مؤقت

هذه هي القنوات التي تريد أن تناقش فيها شيئًا لا تريد تحميل الأشخاص غير المرتبطين بها.



البادئة: tmp_



على سبيل المثال ، إذا كان من الضروري في مشروع GoldFixing مناقشة شراء الأكواب مع شعار المشروع ، فإننا ننشئ قناة gf_tmp_brand-cups.



إذا كنت بحاجة إلى مناقشة شيء غير مرتبط بمشروع معين ، فإننا نحذف بادئة المشروع.

الإعداد الأساسي لقنوات المعلومات

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

1. gf_info_general - لكل ما يتعلق بالجزء التنظيمي: الإعلانات ، تثبيت الاتفاقيات والعمليات. عادة ما تكون موجهة للجميع وتتطلب استجابة من الجميع.
2. gf_info_daily - هنا يقوم الجميع بإلغاء الاشتراك في رسائلهم اليومية
3. gf_info_changelog — , //wireframes/api , - - , Change Report , , ,
4. gf_info_jira — JIRA
5. gf_info_confluence — Confluence
6. gf_info_deploy — . :
   
   — Instance — Repository —
   
   — Branch —
   
   — Pipeline — gitlab
   
   — Job — gitlab
   
   — Triggered by — Slack ,
   
   — Commit —
7. gf_info_sentry — Sentry
8. team_backend — backend
9. team_dlt — DLT
10. team_frontend — frontend
11. team_qa — QA

Advanced JIRA

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



للقيام بذلك ، قمنا بضبط الإشعارات بدقة ولم ننشئ قنوات واحدة ، بل عدة قنوات لـ JIRA:

1. gf_info_jira_comments - لإشعارات التعليقات في JIRA
2. gf_info_jira_qa - لإخطارات QA حول مظهر المهام جاهزة للاختبار. هذه القناة لديها فقط QA والمدير
3. gf_info_jira_qa_verdict - للإخطارات حول نقل التذاكر من حالة "TEST" إلى حالة "DONE" أو "REWORK"

إعدادات متقدمة للإخطارات من Sentry

في كل مشروع لدينا عدة أمثلة (مدرجات) للمشروع:

• حامل ديف - الوقوف للمطورين
• حامل الاختبار - الوقوف للمختبرين
• الافراج عن الحامل - موقف لخوض مرشحي الإصدار
• جناح الإنتاج - جناح الإنتاج

لكل منهم ، أنشأنا قناة حراسة منفصلة.



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



اتضح:

1. gf_info_sentry_back_dev
2. gf_info_sentry_back_test
3. gf_info_sentry_back_release
4. gf_info_sentry_back_prod
5. gf_info_sentry_front_dev
6. gf_info_sentry_front_test
7. gf_info_sentry_front_release
8. gf_info_sentry_front_prod

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



بالنسبة للأكشاك المختلفة ، هناك حاجة ملحة لاستجابة المطورين.



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

1. gf_info_sentry_back_dev الكتلة
2. gf_info_sentry_back_prod- الكتلة
3. gf_info_sentry_front_dev- الكتلة
4. gf_info_sentry_front_prod- الكتلة

مثال على تنظيم القناة

أسئلة للجمهور

1. ما قواعد الاتصال التي ستضيفها إلى القواعد التي أدرجتها؟
2. ما هي الأشياء المفيدة الأخرى التي يمكنك تخصيصها / استخدامها في برنامج المراسلة على مستوى الفريق؟