Trywishboard: تعاون متعدّد المستخدمين دون قتل التركيز — دراسة حالة
كيف حوّلنا أداة لوحة مزاج أحادية اللاعب إلى مساحة عمل متعدّدة المستخدمين بالوقت الفعلي — ولماذا كان الجزء الأصعب هو قرار أيّ التفاعلات ينبغي ألّا تكون تعاونية أصلاً.

وصل Trywishboard إلينا أداةً محبوبة لكن وحيدة — المصمّمون يحبّونها لكن يستخدمونها منفردين. كان الموجز بسيطاً على الورق: حوّلها إلى مساحة عمل متعدّدة. العمل الحقيقي كان شيئاً مختلفاً تماماً.
ما أطلقنا للتعاون الآنيّ
تحرير مشترك للوحة بالوقت الفعلي، طبقة تعليقات مع منصّات mention مقيّدة، نظام صلاحيات يتوسّع من الاثنين إلى المؤسّسة، وخطّ تصدير يحفظ الدقّة من المتصفّح إلى PDF وPPT. أُطلقت في ١١ أسبوعاً.

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



كيف عمل الفريق خلال ذلك
أحد عشر أسبوعًا، ولوحة واحدة، ونقاش طويل حول ما لا ينبغي أن يكون مشتركًا أصلًا. المقطع أدناه هو الجانب الاستوديوي من القصة.
القرار الأصعب: أيّ التفاعلات لا يجب جعلها تعاونية
لم يكن الصعب CRDT. الصعب هو تقرير أيّ التفاعلات ينبغي أن تكون تعاونية من الأصل. حاولنا أوّلاً جعل كلّ شيء تعاونياً — فانخفضت الإنتاجية الفردية ٣٠٪ لأنّ المستخدمين كانوا يتوقّفون لينظروا من معهم في اللوحة. تراجعنا بحزم واستقرّينا على وضعَين: focus-mode أحادي افتراضياً.


النتائج بعد الإطلاق
الفِرَق النشطة أسبوعياً (لا الأفراد) تضاعفت ثلاثاً في أوّل ربع بعد الإطلاق. صفقات مؤسّسية علقت في القسم القانوني شهوراً أُغلقت خلال ستة أسابيع من GA. المحرّك الأكبر — تقسيم focus/team — خرج من اختبارات قابلية الاستخدام، لا من الاستراتيجية.
مشاريع أخرى من رفّنا.
الفريق نفسه، مهام مختلفة. حالات حديثة في صناعات مجاورة — كلٌّ منها أنجزها نفس كبار المهندسين المسؤولين عن النتيجة.
أخبرونا بما تحتاجون
المشاريع حسب النوع تنمو سنة بعد سنة
MVP وإعادة التصميم والذكاء الاصطناعي والدعم — تراكمياً
ملف الاستوديو عبر المحاور الرئيسية
السرعة والجودة والشفافية والهندسة
البحث والتصميم والتطوير تتداخل
مسارات متوازية — لا شلال

