أقدر انفتاح فريق Discourse على اقتراحات الأشخاص الجدد هناك وفي أماكن أخرى أيضًا.
لقد رأيت هذه المشكلة تحدث كثيرًا على Meta على مر السنين، لكن هذا دفعني أيضًا إلى تقديم أفكاري بشكل عام. لقد كان الأمر محبطًا بالنسبة لي لرؤيته، لكنني لم أكن أعرف حقًا كيف أثير المسألة. لذلك سأحاول الكتابة عنه الآن:
السياق
في بعض الأحيان حول Meta، رأيت اتجاهًا لتكديس اقتراحات الأشخاص الجدد لميزات أو تغييرات Discourse. بدلاً من الاستماع وفهم تجربة الأشخاص الجدد على البرنامج - الذين يمكن أن تكون رؤاهم مفيدة حتى لأولئك منا الذين استخدموا Discourse لأكثر من 10 سنوات - يقوم بعض الأشخاص من المجتمع أحيانًا بإسقاط الفكرة بشكل استباقي.
غالبًا ما يتم ذلك إذا تم رفض فكرة في الماضي من قبل فريق Discourse، أو إذا اختار فريق Discourse إعدادًا افتراضيًا معينًا بدلاً من التكوينات الأخرى وما إلى ذلك.
حتى لو كان الأمر كذلك، أود أن أقدم أفكاري حول سبب عدم وجوب استباقنا لرفض الأفكار أو الشكاوى حول البرنامج، حتى لو تمت مناقشتها في الماضي.
فريق Discourse له الكلمة الأخيرة. لقد تغير الكثير. قد لا تنطبق الأشياء من ذلك الوقت الآن.
أولاً، نحن، بصفتنا أعضاء في المجتمع، لسنا مديري منتجات لـ Discourse. إذا سارعنا لإخبار شخص ما بأن فكرته قد تم رفضها في الماضي ولماذا، فقد لا يعكس هذا بالضرورة القرارات الحالية لفريق منتجات Discourse.
في بعض الأحيان، حتى فريق Discourse نفسه يمكن أن يقرر العمل على ميزة تم استبعادها سابقًا في الماضي. لفترة طويلة، كانت الدردشة إحدى هذه الميزات.
لذلك لا يوجد ضمان بنسبة 100٪ بأن القرارات السابقة ستكون هي نفسها القرارات الحالية.
حتى الأشخاص في فريق Discourse يمكن أن يكون لديهم آراء مختلفة مع بعضهم البعض فيما يتعلق بما يجب أن يكون أولوية لـ Discourse.
على سبيل المثال، غالبًا ما كنت أتابع مدونة @erlend_sh وناقش كيف كان لديه رأي مختلف عن بقية الفريق حول كيفية يجب أن تكون الدردشة في Discourse - التركيز الغامق هو لي:
معظم مشاريع المصادر المفتوحة ليس لديها منتدى مخصص، ولكن تلك التي لديها بالتأكيد لديها أيضًا دردشة جماعية. كانت محاولتي الأخيرة في Discourse هي محاولة دمج الوضعين معًا، مع تقديم Discourse Chat.
أنا فخور جدًا بهذا MVP (الذي تخرج منذ ذلك الحين إلى النواة)، ولكن الاتجاه الذي أردت الذهاب إليه من هناك كان غير متوافق بشكل مفهوم مع الحمض النووي لمشروع Discourse كمنتدى تقليدي: اقترحت أن نجعل الدردشة هي الرائدة في تجربتنا المجتمعية. يبدأ المجتمع في غرف الدردشة، كما اعتقدت. لم يفكر Discourse في ذلك، لذلك انفصلنا وديًا.
بعد سنوات، لا يزال موقفي دون تغيير. يجب أن تعني “الدردشة الجماعية” و “المنتدى” نفس الشيء تقريبًا. هذا هو في الواقع الاتجاه الذي يبدو أننا نتجه إليه، منذ أن يدعم Discord، حاكم أراضي مجتمعنا، الآن مجموعة متنوعة من الميزات الخيوط والألواح التي تتناسب بشكل جيد مع نموذج المنتدى.
لذلك ليس من شأننا أن نقرر بشكل استباقي ما لا يجب أن يدخل في Discourse، لأن ذلك يمكن أن يتغير بمرور الوقت أيضًا.
أولئك منا في الأيام الأولى لـ Discourse سيتذكرون عندما كان CDCK أقل من 10 أشخاص وكان غالبًا ما يكون إدارة المنتج مدفوعة جدًا من قبل المؤسسين المشاركين لـ Discourse. ولكن في الوقت الحاضر، يضم CDCK 100 شخصًا ولديه فريق منتجات كامل لـ CDCK!
يحتوي Discourse نفسه على قاعدة مستخدمين أكبر بكثير، وقد نمت احتياجاتهم واستخدامهم للبرنامج إلى ما وراء المتبنين الأوائل الأوائل لـ Discourse. بشكل أوسع، تغير مشهد المنصات الاجتماعية (انتقل الزخم من Facebook إلى Discord والمزيد، وما إلى ذلك)، وتغيرت التوقعات العامة للأشخاص.
نظرًا لأن الفريق أكبر بكثير مما كان عليه في الأيام الأولى لـ Discourse، فإن لديهم قدرة أكبر على العمل على ميزات أخرى قد تكون ذات أولوية أقل بكثير خلال الأيام الأولى لتطوير المنتج، في الماضي.
لذلك، كيف يراجعون طلبات الميزات الآن سيكون مختلفًا على الأرجح عن البداية. سيكون لدى فريق المنتج عمليته الخاصة لاتخاذ القرارات وتحديد ما يتم العمل عليه في النهاية ومتى.
المزيد من نقاط البيانات أفضل
ثانيًا، عادة ما يكون من المفيد لفريق Discourse سماع المزيد من نقاط البيانات بدلاً من أقل.
كان هناك شيء تم تعميمه بشكل فضفاض على Meta كقاعدة الثلاثة (الحد الأدنى لـ 3 أشخاص يقدمون شكوى حول شيء ما قبل النظر في طلب الميزة هذا). حتى مع ذلك، عليك أن تسمح للناس بمشاركة تجاربهم والشكوى، من أجل الاستماع إلى 3 أشخاص مختلفين يجدون مشكلة في شيء ما.
بصرف النظر عن ذلك، كانت هناك فكرة أخرى شائعة وهي التطوير المدفوع بالشكاوى. ومع هذا، عليك أيضًا الاستماع إلى آراء الناس:
الشيء الوحيد الذي رأيته يعمل دائمًا هو النزول بعمق والاتساخ في الخنادق مع المستخدمين، والتواصل معهم وتنمية العلاقات.
بعد إعادة قراءة ذلك، أقدم أيضًا بقوة أن الفرضية الأصلية وراء “قاعدة الثلاثة” هذه ليست في الواقع أن رأيك لا يهم إذا لم يشتكي شخص آخر منه.
كان جوهر الأمر هو (خاصة إذا كنت فريقًا ذا موارد محدودة) أن العثور على الأشياء التي يشتكي منها الناس أكثر هو طريقة فعالة للعثور على المشاكل التي تزعج المستخدمين أكثر - حتى تتمكن من إصلاحها أولاً.
كما يقول ستيف كروغ في لا تجعلني أفكر:
ستجد دائمًا مشاكل أكثر مما لديك موارد لإصلاحها، لذا من المهم جدًا أن تركز على إصلاح أخطر المشاكل أولاً. ومن المحتمل جدًا أن يواجه ثلاثة مستخدمين العديد من المشاكل الأكثر أهمية المتعلقة بالمهام التي تختبرها.
لذلك لمجرد أن الكثير من الأشخاص الآخرين لم يشتكوا من نفس الشيء، لا يعني أنه غير مهم. لا تزال المزيد من نقاط البيانات مفيدة لفريق Discourse عند النظر في نقاط الألم الرئيسية/الصغرى الحالية للمستخدمين.
من الممكن تقدير ملاحظات الأشخاص، حتى لو لم تقم بتنفيذها
ثالثًا، لا يزال من الممكن قول شكرًا لملاحظات الأشخاص، حتى لو لم تتمكن من تنفيذ جميع اقتراحاتهم أو إذا قررت عدم القيام بذلك.
لقد تدربت أكثر على التعامل مع الملاحظات بهذه الطريقة، بعد أن درست تصميم الألعاب حيث كان إعطاء وتلقي الملاحظات جزءًا كبيرًا من العملية. في تكرارات كل مستوى لعبة، أو وثيقة تصميم، أو أي شيء، كنا نقدم ملاحظات حول عمل 3 أشخاص آخرين على الأقل ونتلقى ملاحظات من 3 آخرين على الأقل. كنت أحاول تقديم ملاحظات لـ 4 أو 5 أشخاص للمساعدة في تعويض الآخرين الغائبين / تقديم واجباتهم متأخرة، إلخ.
غالبًا ما تكون ملاحظات الأشخاص ثاقبة ومفيدة للغاية، ولكن هناك أكثر من 10 نقاط مهمة وحاليًا لديك وقت لتنفيذ 1-3 أشياء فقط.
كان هذا هو الحال أيضًا عندما عملت محترفًا كمهندس برمجيات غالبًا ما أتفاعل مع المجتمع، كجزء من شركة ناشئة صغيرة. قد تكون هناك 10+ تقارير أخطاء مهمة، ولكن في التحديث التالي، لديك وقت لإصلاح 1-3 منها.
في أي حال، لا أزال أشعر بأنني ملزم بشدة بشكر الأشخاص على ملاحظاتهم، وشكرهم على مشاركة أفكارهم، وشكرهم على تخصيص الوقت لكتابة خطوات لتكرار خطأ واعتذر عن الإزعاج.
في معظم الأوقات، لا يقول المستخدمون/اللاعبون شيئًا إلا إذا كانوا منزعجين حقًا. لذا فإن معظم الملاحظات المكتوبة / طلبات الميزات / تقارير الأخطاء تأتي من شخص استغرق وقتًا لمشاركة أفكاره حول شيء ما - أشياء قد يكون الكثيرون الآخرون قد فكروا فيها ولكنهم لم يحددوا أو يقولوا شيئًا عنها بعد، أشياء ربما فاتتك، وما إلى ذلك.
لذلك حتى لو لم تتمكن من تنفيذ كل ما يقوله الجميع - والذي قد يكون 90٪ من الوقت - فهذا لا يعني أنه يجب عليك القفز على كل تلك الملاحظات ودفعها للأسفل. لا تزال الملاحظات مهمة، حتى لو لم يكن لديك الموارد للتصرف بناءً عليها الآن أو حتى لو قررت عدم التصرف بناءً عليها.
على أي حال، هذا هو السبب في أنني أعتقد أنه يستحق الأمر، بالنسبة لنا كمجتمع، السماح للأشخاص الجدد الآخرين بمشاركة أفكارهم وعدم القفز فورًا لرفض اقتراحات Discourse. هذا لأن موقف فريق Discourse بشأن الميزات قد يتغير بمرور الوقت، ولا تزال الملاحظات مفيدة كنقاط بيانات لفريق Discourse، حتى لو لم يقوموا بتنفيذها الآن.