🧑🏾‍🤝‍🧑🏼 💏 😆 بدء التشغيل داخل الشركة 🕴🏾 ♟️ 🀄️

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

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

مقدمة

نسيان جميع البيانات الرشيقة وخلق بيئة عمل مريحة إذا كنت ترغب في تحقيق النتائج. في إدارة المشاريع اليائسة ، ليس وجود مكتب PlayStation وطقوس الإلزام الإجبارية التي تبرز في المقدمة ، ولكن طموحات الفريق ودوافعه الشخصية.

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

إذا كان مقدم الخدمة الأمامية لديه رهن عقاري قائم - اعرض عليه خيارًا - إما PS4 ، أو بالإضافة إلى مكافأة في نفس المبلغ. مهمتك ليست أن تكون مربية في المشروع ، ولكن لضمان النتيجة بطريقة ترضي كل من الفريق والعميل. حتى لو كان ذلك غير ممكن.

على علاماتك

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

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

ولكن تم الإعلان عن الموعد النهائي - للإفراج عنه في سبتمبر. وجلسنا للعمل.

محور مزدوج

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

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

على الفور تقريبًا ، نشأت مشكلة التقسيم الطبقي للصورة العامة - لم يكن التسويق يعرف ما نقوم به تقنيًا ، ولم يفهم المطورون كيف كان يجب أن يكون كل شيء. قبل عطلة أيار / مايو ، فتحنا التقاء أولاً وجلسنا لوصف الشاشات.

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

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

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

عن الفريق

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

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

اجتمعت النجوم وتمكنا من العثور على سلسلة من العلاقات التي كان لدى كل شخص فيها دائمًا شيء يتحدثون عنه بخلاف العمل. وعندما تبني التواصل - يمكنك التعامل بهدوء مع توزيع الأدوار.

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

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

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

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

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

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

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

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

في الأول من أغسطس ، قمنا بتجميع نواة النظام ، وتم الانتهاء من جميع الأعمال التحضيرية تقريبًا ، وتم تجميع النسخة التجريبية من OpenAPI ، وتم رسم الواجهة وتكوينها ، وكان لا يزال هناك أسبوع متبقي لتلميع الخوارزميات وانتظار الواجهة الأمامية للعمل ، والتي كانت "فقط" لجمع كل شيء هذا هو أفضل لاعب يعمل.

أشجار الحدث

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

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

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

تستحق تفاصيل هذه القصة مقالة منفصلة ، ولكن المفتاح الذي تم تحقيقه يتكون من عدة نقاط:

. « – – crm– – – – », , ,
- « - », « » .
تضاعف طريقة الاختبار على "التحضير المسبق" لمشاركة المطورين ، مما جعل من الممكن اختبار تجربة المستخدم عمليًا حتى قبل إصدار المنتج للعالم الخارجي ، والأهم من ذلك بالنسبة للمشروع ، لتصحيح التشغيل الصحيح لخوارزميات النظام في السوق الحقيقية وبيانات العميل.

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

ما هي النتيجة

تم تجميع MVP العامل للمشروع في نهاية أغسطس ، بالتوازي ، تم تنفيذ نسخة من المحاكي لاعتماد البرنامج في NAUFOR وتم كتابة مائة وخمسين صفحة من الوثائق الداعمة لتسجيل البرامج. أول معاملات حقيقية على النظام صرخات بهيجة جرت في 31 أغسطس. دخلت التغييرات القانونية على مستندات الشركة ولوائح العملاء حيز التنفيذ في 1 سبتمبر ، وقبل اعتماد النظام ، كان لدينا الوقت لتصحيح الأخطاء ولعق الواجهات.

في MVP ، لم يكن لدينا حسابات عملات ، ولا حسابات مستقبلية ، ولا حتى حساب سمسرة خاص بنا ، ولكن تم الانتهاء من المهمة الرئيسية - تم تنفيذ البنية التحتية ، وأصبح الأمر الأولي همزًا ، وتم تنفيذ الخدمة للعملاء.

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