في 24 أبريل ، حدث تغيير مهم في منصة Wrike: أعلن الفريق عن إصدار عام لميزة جديدة - "Spaces" ، في النسخة الروسية - "Spaces".
الهدف من Spaces هو تحسين عمل الفرق في إدارة المهام وتبسيط التنقل في المنتج ، مما يجعل العمليات أكثر حيوية وشفافية. هل فعلنا ذلك؟ استمر في القراءة وتعلم كيفية طرح تحديثات جادة في شركة كبيرة وعدم تثبيتها ، وكيفية ضمان تفاعل 30 فريق سكروم والدروس المستفادة التي تعلمناها من عملية تطوير المنتج ، والتي
كلفناها في وقت لاحق الكثير من
الدماء وروح الفريق المتميزة.
لماذا تم اختراع Spaces؟
عندما تم إنشاء Wrike ، كان يركز على حل مشاكل فعالية الفرق الصغيرة المكونة من 15-20 شخصًا. من المريح أن تعمل هذه الفرق في مكان واحد حيث يوجد "مساحة" للجميع.
بمرور الوقت ، زاد حجم الحسابات عدة مرات. الآن يتم استخدام المنتج بواسطة فرق موزعة في الحسابات مع الآلاف من الأشخاص ، وفي المستقبل نرى Wrike كأداة ملائمة لعمل العديد من إدارات الشركة: من ناحية ، تعمل في عمليات مختلفة ، من ناحية أخرى - لا تزال بحاجة إلى التفاعل مع بعضها البعض.
نظرًا لوجود فرق في العالم الحقيقي في مكاتب ومكاتب ودول مختلفة ، فكر فريق Wrike في إنشاء مساحة خاصة لهم حتى يتمكنوا من العمل في وقت واحد كجزء من عمليتهم وعدم فقد الاتصال بالإدارات الأخرى.
تتيح المساحات لمجموعات العمل الفردية إعداد سير عمل بكفاءة: امنحهم الأدوات وهيكل البيانات الذي يحتاجون إليه ، والوصول إلى أشكال مختلفة من الاستعلامات حتى يتمكنوا من تنظيم مساحة العمل الخاصة بهم والعمل بشكل أكثر تركيزًا. تتيح لك Spaces أيضًا التحكم بشكل أفضل في توزيع المعلومات في فرق متعددة الوظائف وزيادة مستوى أمان البيانات.
تنتمي فكرة إنشاء Spaces إلى Sasha Plotvinov و Van Saveliev ، مديري منتجات Wrike. أولاً ، لقد أجروا أبحاثًا ، ورسموا نموذجًا أوليًا للحل للفرق الموجودة على السبورة ، وقاموا بتجميع النماذج والتحقق من صحة الفكرة. في وقت لاحق ، تم الانتهاء منه في Wrike Hackathon ، حيث اتخذوا خطوة إلى جانب وجمعوا نموذجًا أوليًا للفضاء الشخصي استكمل هذا المفهوم.
"المسافات" هي ، أولاً وقبل كل شيء ، ميزة للفرق. ومع ذلك ، فإنه يعتمد على مفهوم المساحة الشخصية الحية ، والتي يحتاج الجميع إلى استبعاد المعلومات غير الضرورية والضوضاء الخارجية.
ما هي المشاكل التي تحلها Spaces؟
لتبسيط ، يتكون Wrike من مشاريع وأدوات للعمل معهم. على سبيل المثال ، أثناء العمل على إصدار شامل ، يمكنك إنشاء عدد من المشاريع ، ومراقبة تقدمها من خلال مخطط جانت ، والتحكم في تحميل الفرق باستخدام عبء العمل ، وبناءً على النتائج ، قم بتجميع تقرير لأصحاب المصلحة.
يبدو كل شيء بسيطًا ، ولكن إذا كان لديك الآلاف من الأشخاص الذين يعملون في حساب واحد في عدد كبير من الفرق التي لها عمليات متداخلة ويستخدمون العديد من الأدوات ، تظهر مشكلتان:
يصبح من الصعب إدارة العمليات وتكون
واجهة المستخدم مثقلة بعناصر غير ضرورية .
كان
أصبحتنشأ هذه العوائق التي تحول دون العمل الجماعي الفعال لعدة أسباب: أولاً ، يوجد في نفس شجرة المجلدات العديد من الفرق ؛ يرى المستخدم باستمرار معلومات غير ذات صلة وينتهك عن غير قصد هيكل فريق "الأجنبي". ثانياً ، يمكن للمسؤولين فقط الوصول إلى إدارة العمليات ، وغالبًا ما يتم تشكيل هيكل الحساب من قِبل رؤساء الإداريين.
في عملية تطوير المسافات ، توصلنا إلى مهمتين رئيسيتين:
- يجب أن يرى المستخدم فقط ما هو مناسب له
- يجب أن يأتي التفويض والتنظيم الذاتي إلى مكان الإدارة الرأسية
تعد Wrike واحدة من تلك الشركات التي
تعتقد أن الإدارة الأفقية تتفوق على
المنظمات الرأسية و "الفيروزية"
التي تُظهر نفسها بأكثر الطرق فعالية. سيساعد النهج المطبق في Spaces الفريق على الوصول إلى مستوى جديد من الشفافية والتنظيم الذاتي ، حيث تسود الإدارة الأفقية.
"إذا كان مسؤول الحساب قبل أن يتحمل درجة عالية من المسؤولية عن العمليات ، فسيتمكن الآن من إسناد تنظيم سير عمل الفريق إلى مشرفه المباشر ، الذي غالبًا ما يعرف بشكل أفضل ميزات فريقه."
-
إيفان سافيليف ، مدير منتجات Wrikeما الصعوبات التي واجهناها؟
بطبيعة الحال ، فإن التغييرات المهمة في المنتج تنطوي على مخاطر كبيرة وعدد من الصعوبات. هؤلاء بعض منهم:
الصعوبة 1. تقليل المخاطريعد تكييف الحساب مع طريقة جديدة لتنظيم العمل مهمة تستغرق وقتًا طويلاً. داخل Wrike ، تم اكتشاف المشكلة فورًا تقريبًا: كشركة لها العديد من الفرق والعمليات ، ندخل في فئة العملاء الذين نعتبرهم جمهورنا ونستخدم منتجاتنا يوميًا. داخل حساب الفريق (أكثر من 800 شخص من جميع المكاتب الدولية) ، أطلقنا إصدارات وتلقينا ردود فعل على الفور من الداخل - وقد ساعد ذلك في التحضير لإصدار عام وزيادة المخاطر مسبقًا.
بالنسبة لأولئك الذين لم يستخدموا Wrike أبدًا ، في المراحل الأولية أجرينا سلسلة من المقابلات مع الحلول ،
وبدأنا الاختبار باستخدام خدمة
UserTesting ،
وقمنا أيضًا بإنشاء برنامج وصول مبكر لوظائف Spaces للعملاء المهتمين.
قبل البدء على الجمهور بأكمله ، أجرينا أيضًا اختبار A / B على تجارب جديدة للتأكد من أن نموذج التنقل الجديد سهل الاستخدام للمستخدمين الجدد. من الاختبار ، أصبح من الواضح أن المستخدمين الجدد بدأوا بنجاح في استخدام المنتج. أجرينا أيضًا مقابلات مع مجموعات الاختبار والتحكم ووجدنا أنه من بين المجيبين ، كان المستخدمون أكثر عرضة للتحدث عن مدى قابلية فهم الواجهة وسهولة استخدام Wrike.
الصعوبة 2. تقديم قيمة الحل للعميل
لدى Wrike العديد من العملاء الذين يستخدمون الخدمة بالفعل ويقومون بإعداد عمليات العمل الخاصة بهم ، لذلك كان هناك خطر من أن الوظيفة الجديدة ستكون مترددة.
أطلقنا الإصدار التجريبي الخاص للعملاء الرئيسيين وربطنا قسم
الخدمات الاحترافية بالعملية.
من أجل إيصال المشكلة ، وبالتالي ، حلها للعملاء ، قام مديري نجاح العملاء مع مسؤولي الحسابات بتحديد مشاكل تنظيم العمليات في مرحلة مبكرة وأخبروا العملاء كيف يمكن لـ Spaces حلها. وبالتالي ، أرسلنا أقصى قيمة للمساحات ، والتي تفوقت على حجم تكاليف إعادة الهيكلة. لم نقم بتطبيق الميزة بشكل مفاجئ ، ولكننا أعدنا العملاء بشكل منهجي لمظهرها: أجرى مديرو نجاح العملاء ندوات عبر الإنترنت ، وعلّموا العملاء كيفية التنقل في الميزات الجديدة ، وتدريب الرسائل الإخبارية عبر البريد الإلكتروني ، وتحدثنا عن أفضل الممارسات.
في وقت لاحق ، لم نجر أي مكالمات على الإطلاق: بدأ العملاء في القدوم إلى برنامج الاختبار المبكر بأنفسهم واستخدام ميزة جديدة.
الصعوبة 3. أحد التحسينات يتطلب العديد من التغييرات
يؤثر تحسين النظام الأساسي على الجوانب المختلفة للمنتج ، وقررنا إجراء التحديث حتى لا يقف في مكان واحد. لقد حالفنا الحظ مع فريق التطوير الذي قام بتقييد أكثر العقد الفنية المذهلة وإيجاد الحلول المثلى خلال العمل في المشروع. بالإضافة إلى ذلك ، أدرك الجميع الحاجة لهذه المبادرة ، لذلك كان لدينا دائمًا دعم قوي من نائب الرئيس والمدير التنفيذي.
منذ البداية ، قرر فريق التطوير إنشاء بنية متصلة بأدنى حد ، وتحويل الحل بالكامل إلى مجموعة من مكونات الأعمال والتطبيقات الصغيرة المنفصلة التي تتكامل وتتفاعل فقط بين مساحة العمل (المنتج النهائي الذي يراه مستخدم Wrike).
تم إنشاء مستودع منفصل لهذه المكونات ، بما في ذلك صندوق الحماية. كان من الممكن ليس فقط النظر إلى كل عنصر في العمل وإظهاره ، على سبيل المثال ، في مراجعة الركض ، ولكن أيضًا لإجراء التطوير والاختبار الكاملين. استغرق التجميع ، تشغيل وحدة الاختبار و autotests ترتيب وقت أقل من حجم عندما تتطور في مساحة عمل كاملة. سمح هذا للمطورين بالتكرار بسرعة ، مع عرض النتائج في نهاية كل سباق ، وإذا لزم الأمر ، فعليًا إجراء تغييرات على كل من الوظيفة وواجهة برمجة التطبيقات. بعد مرور بعض الوقت ، اتخذت الخطوة التالية - إنشاء نوع من "الملعب" ، حيث تم إنشاء واجهة مبسطة للغاية للمنتج الرئيسي ، بما في ذلك دمج معظم المكونات. هذا سمح لنا بتصميم وتصحيح تفاعلهم مع بعضهم البعض.
كيف تفاعلت الفرق مع بعضها البعض؟
لدى Wrike حوالي 30 فريقًا من فرق العمل يعملون على جزءهم من المنتج ، وكل منها يتأثر حاليًا بالميزات ، أو سيتم إدراجه في العملية في المستقبل القريب. في بعض الأحيان ، نشأت مشكلة تفاعل الفريق أثناء تطوير Spaces بحدة - بعد كل شيء ، يمتلك كل فريق OKRs منتجًا خاصًا به للربع.
كانت مسألة التواصل أولوية: حيث كان من الممكن مناقشة كل شيء مسبقًا ، والموافقة على الاتفاقيات وإضفاء الطابع الرسمي عليها ، اتضح أن التفاعل كان أفضل من تلك الفرق التي لم تجر مناقشات أولية معها. في الحالة الأخيرة ، كان على فريق التطوير إجراء تغييرات أو تعديل وظائف شخص آخر بأنفسهم.
"كانت هناك حالات استثنائية: بمجرد أن كان من الضروري دمج عنصر كبير ومعقد تم تطويره بواسطة فريق خارجي قبل الانتهاء من هذا الفريق (كنتيجة ، ظهر في جزء من وظيفتنا في وقت أبكر من الأساس). ما يجب القيام به - حاولنا إنهاء العمل كجزء من المواعيد النهائية وكان علينا الخروج. وفي الوقت الذي قضيناه في ترتيب كل شيء بعد الانتهاء من المكون ، اضطررنا لتشويهه بطبقة رقيقة عند العمل على ميزات أخرى - لقد انتهى التكامل وفقًا للخطة! "
-
أليكسي كارتافينكو ، Frontend Teamleadلا ينبغي أن يكون عدد المشاكل التي تنشأ عندما يتفاعل 30 فريقًا مع بعضهم البعض في بيئة سريعة الحركة شديدة الإحباط. بالنسبة إلى أي شركة تقريبًا ، يعد ترتيب عملية scrum إنجازًا بالفعل ، كما أن scrums scrums يعد بمثابة خيال: هنا يجب أن يتعلم المراجعون العاديون والمنتجون العاديون كيفية العمل مع بعضهم البعض.
هذه هي النصائح التي قدمها فريق Spaces لأولئك الذين يستعدون لإنشاء مشروع كبير:- ناقش الخيارات المتوسطة للمشروع مع المشاركين المختلفين في العملية قدر المستطاع ، وجمع التعليقات باستمرار وابحث عن غذاء إضافي للتفكير.
- إذا كان بالإمكان استخدام ما تفعله داخليًا (كنا محظوظين جدًا بهذا في Wrike) ، فابدأ مشروعًا تجريبيًا. قم بلف الجميع ، أبلغ الجميع ، وقم بتشغيل نماذج الملاحظات!
- حدد مستوى الاستعداد الذي يمكنك من خلاله تمكين وظائف العملاء المخلصين: من بينهم دائمًا أولئك الذين يحبون مواكبة العصر وتنشيط جميع أنواع الميزات التجريبية ، وستكون تعليقاتهم ذات قيمة خاصة لأنهم جمهورك المستهدف. جميع آليات الاختبار المبكر تحت تصرفك: تجارب A / B ، ونسخ محدودة ومراقبة من إصدارات ألفا وبيتا ، والوصول المبكر عند الطلب ، إلخ.
- قم بالتوازن بين سرعة التطوير وجودته ، كما هو الحال على لوح التزلج على الأمواج: لا تخف من ترك الدين التقني في السباق الحالي ، ولكن ابدأ على الفور في مهام للقضاء عليه بمجرد أن يصبح الموقف واضحًا. تذكر أن تعطي هذه المهام أولوية قصوى. ليس من قصر النظر القيام بتغطية كاملة للاختبارات الوظيفية والوحدة التي يمكن أن تتغير بعد ردود الفعل في السباق التالي. علاوة على ذلك ، ليس من الغباء فحسب ، بل إجراميًا على المهندس ترك رمز البريد العشوائي في النهاية والسماح له بالوصول إلى الإصدار.
- حاول أن تعد بشكل مناسب لكل سباق قادم: إجراء PBRs (تحسين تراكم المنتجات) ، تأكد من القيام بمهام للبحث عما تخطط للقيام به في السباق التالي ، والتحدث إلى مالك المنتج ومصمم UX بقدر ما تراه مناسبًا: متابعة لهم في المطبخ وفي غرفة التدخين ، مع توضيح التفاصيل. حاول مزامنة الواجهة الخلفية والواجهة الأمامية والاختبار بطريقة تجعل التفاعل "ملفوفًا" ، بحيث لا يكون أحد خاملاً ، في انتظار استعداد زملائه من تخصص آخر ، حتى لا تضطر إلى الجلوس على موك ثم رميهم بعيدًا ، إلخ.
- أقرب إلى تاريخ الإصدار ، عندما يتم تسخين المشاعر ويتم نقل الجزء الأكبر من العمل من المطورين إلى مهندسي ضمان الجودة ، واستبدل كتفك بهم: اختبر الكود بنفسك ، وقم بالتراجع ، والمساعدة في التحليل ، ومحاولة كتابة الاختبارات التلقائية.
- عند التفاعل مع الفرق الأخرى ، ابدأ مناقشات منتظمة مقدمًا حول كيفية القيام بذلك بالضبط. اكتب جميع الاتفاقات والخطط ، وقم بإنشاء الوثائق ، ويمكنك حتى إبرام العقود - ليس لأن شخصًا ما سيحاول خداعك ولن يفعل الكثير ، ولكن لأن كل شخص لديه رغباته الخاصة بالأيام ومشاكلك ليست سوى خمسة بالمائة غريبة. تزامن Sprint مثالي ؛ الهدف منه.
- عند استخدام شيء تم تطويره من قبل فرق أخرى ، كن حذرًا من العبارات التي "كل شيء تقريبًا جاهز ، خذ ودمج". أولاً ، يجب عليك معرفة ما إذا كنت لا ترغب في الدخول في فوضى ، مع أخذ ما يعطونه بشكل عمياء وبناء خططك عليه (خاصةً التقويمات).
- والأهم من ذلك: لا يوجد شيء جاد في عالم تكنولوجيا معلومات معقد يتم بنقرة إصبع ، لذلك ، إذا كان المشروع قيد التطوير لفترة طويلة وبدأوا في "النظر جانبيًا" ، اعتن بأعصابك وتعرف: حتى لو لم يكن اليوم ، ولكن غدًا أو في اليوم التالي غدًا ، تتشابك الخيوط المنزلق إلى ما لا نهاية ، وسيتبدد الضباب وينتظرك النجاح - هل تؤمن بما تفعله ، أليس كذلك؟