نحن النموذج الأولي عن طريق الرمز. محاضرة فرونتالتكس

أعيادا سعيدة ، أصدقاء! استعدادًا لبداية عام العمل الجديد ، نستكمل سلسلة من المواد من مؤتمر FrontTalks 2018. هذه محاضرة لـ Andrei Salomatin filipovskii_off - مطور من Polychops. يقدم أندريه مقاربة متوازنة للنماذج الأولية: التحول من الحرفيين الذين ينفذون الأوامر إلى الباحثين - لمعرفة كيفية العمل مع عدم اليقين ، وربما ، للحفاظ على العقل حتى بدون خطة واضحة.

التغذية الراجعة الكمية هي اختبار AV ، والنتائج الثنائية ، عندما يفوز الخيار A أو الخيار B. هذا هو كل ما يمكننا الحصول عليه من الدورات الكمية. يبدو الأمر كما لو أننا في غرفة مظلمة ولا يوجد شيء مرئي ، لكن لدينا مؤشر ليزر. من وقت لآخر ، نلقي الضوء عليها في الزوايا ونلقي الضوء على بعض النقاط ونفهم ما يوجد فيها.

ماذا نود بدلا من ذلك؟ المستخدم الذي سيصف هذه الغرفة المظلمة ، الذي يعرفها أفضل من أنفسنا.

- مرحبا بالجميع! أود أن أتحدث عن النماذج الأولية: لماذا نصنع النماذج الأولية ، وما الذي نحصل عليه من هذا وكيفية صنعه ، باستخدام الأمثلة.





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

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



فعلت أيضا بعض هذه المشاريع. كنت محظوظًا بما فيه الكفاية للعمل في MoscowJS و Frontend Union Conf و RadioJS. ربما عبرنا معك في مكان ما. أنا الآن أعمل Code Podcast ، وهو بودكاست باللغة الإنجليزية عن المفاهيم الشائعة في البرمجة ، و Polychops ، وهو مشروع للموسيقيين الذي يعمل في المتصفح ويساعدك على ممارسة الصك ، والحصول على المزيد من الوقت والممارسة.

ماذا حدث ل HeyMoose؟ كان لدى الشركة أشخاص أذكياء جدًا يعملون الآن كمطورين كبار في شركة Microsoft أو أصبحوا STOs. لقد فعلنا أفضل ما فعلناه: لقد حللنا المشكلات الفنية المعقدة بسرعة وبشكل مثير للاهتمام. ولكن حدث خطأ ما.



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

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

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



من هو متأكد بنسبة 100 ٪ أنه يمكننا القيام بذلك باستخدام المتصفح وواجهة برمجة التطبيقات للمستعرض؟ ليس شخص واحد. من هو متأكد بنسبة 80 ٪ أنه يمكننا القيام بذلك على الأرجح؟ 3-4 اليدين. من المؤكد 50 إلى 50؟ الأغلبية. من هو متأكد من أننا لا نستطيع القيام بذلك على الإطلاق؟ بصراحة

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



والمثال الأخير. نحن تقديم خدمة سحابة ، افتح شركتنا. ستقوم الخدمة السحابية بجمع سجلات من المشاريع ، من الواجهة الأمامية والخلفية في الشركات الصغيرة والمتوسطة ، وتجميعها ، والتعلم الآلي ، ومنظمة العفو الدولية ، وكل ذلك. سوف نبيعه. من هو متأكد من أن هذا هو النجاح بنسبة 100 ٪ أو خسارة 100 ٪؟ زوجين من الناس.



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

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

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

وهناك قضايا التنفيذ. مثال مع المسرع. نحن لا نعرف 100 ٪ ما إذا كان هذا ممكن من الناحية النظرية أم لا.

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

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

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

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

كيف نتعامل مع عدم اليقين؟ ما هي أساليب الصراع لدينا؟ الطريقة الأولى هي الأكثر أهمية - وضع جميع البطاقات على الطاولة ، للاعتراف بأننا لسنا متأكدين من أي مشكلة. قد نكون متأكدين بنسبة 50٪ ، ولكن لاختبار الفرضية ، نحتاج إلى يومين. إذن لماذا لا نذهب ونختبر الفرضية؟ قد نكون متأكدين بنسبة 90٪ من أن المنتج سينطلق ، لكننا نحتاج إلى ثمانية أشهر لتنفيذ هذا المنتج واختبار الفرضية. هل سنذهب ونفحص؟ أو ربما سنفكر في كيفية الحد من عدم اليقين إلى 90 أو 100 ٪؟

هذه هي الطريقة الأولى. من الضروري تعليق علامة على عدم اليقين هذا ، لتحديد حجمها أو صغرها ، ومقدار العمل المطلوب لحلها ، إلخ.

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



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

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

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



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

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



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

مثال من الحياة الشخصية. Productive Mobile هي الشركة التي عملت بها مؤخرًا ، وهي شركة ناشئة ، فقد توصلوا إلى منصة تتيح لك إنشاء تطبيق للهاتف المحمول من موقع ويب بطريقة السحب والإفلات. لقد بعناها لشركات كبيرة نظرًا لوجود منتجات مثل SharePoint أو SAP لا يمكن استخدامها على هاتف محمول أو تكبير / تصغير ، هذا كل شيء. لقد قدمنا ​​لهم خيارًا: يمكنك إنشاء تطبيق للهاتف المحمول استنادًا إلى موقع حقيقي ، على سبيل المثال ، خلال أسبوع. المشكلة هي أنه كان لدينا فريق تطوير قوي جدًا ودورة مبيعات طويلة جدًا. عند بيع منتج لشركة بحجم Daimler أو BMW ، تكون دورة المبيعات على الأقل 8 أشهر. خلال هذه الفترة ، يمكن لفريق من المطورين الموهوبين تقديم الكثير.

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

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

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



ما هو الفرق؟ التغذية الراجعة الكمية هي اختبار AV ، والنتائج الثنائية ، عندما يفوز الخيار A أو الخيار B. هذا هو كل ما يمكننا الحصول عليه من الدورات الكمية. يبدو الأمر كما لو أننا في غرفة مظلمة ولا يوجد شيء مرئي ، لكن لدينا مؤشر ليزر. من وقت لآخر ، نلقي الضوء عليها في الزوايا ونلقي الضوء على بعض النقاط ونفهم ما يوجد فيها.

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



مثال على شركة تعتمد اعتمادًا كبيرًا على التعليقات الكمية هي Booking.com. في رأيي ، هناك شيء للعمل على موقعهم.

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

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



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

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

أخذوا ورقة أخرى ، فحصوا كل شيء عليها. بدون تنفيذ. لم يعمل API في هذه المرحلة. لذلك قمنا بتكرار 5-10 قبل أن ندرك الشكل الذي يجب أن تكون عليه واجهة برمجة التطبيقات. لقد وفرنا قدرا كبيرا من الوقت للتنفيذ. بعد أن فهمنا النموذج ، قمنا بتوثيق المواصفات ، وقمنا بتنفيذها. كل شيء أصبح رائعا.



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



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


ولكن استغرق الأمر حوالي شهر ونصف ، واستغرق النموذج الأولي السابق 20 دقيقة.

التركيز على الواجهة.



لتوفير الوقت ، استخدم نظام التصميم. مثال سريع من Polychops.



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



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



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

. , . .



: , . , , .



, , . , , . , , , , , . .



— . , , . , .



, , — . . , React . React, React. , , , Redux Apollo, . . .



— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .



, , . . , . — , , .

, . , . . , . . . — , . , .

? « ?» — , . ?



. , . . 10% , , 10%, , — .

. , 90% , . , , 10%. — , . .

, . Productive Mobile , . , , - , .

. React, — React Native. , , — React, React Native. - : «, React Native, , ». .

? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .

, , … ?

Polychops - , . , , , , , . - , , . . .

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

إذا نجحت وأنتجت منتجًا رائعًا ، فأرجو أن أكون في وقت ما أحد المستخدمين سعداء للغاية. شكرا لك