نظرة جديدة على السؤال القديم: هل يجب إعادة كتابة التطبيق من نقطة الصفر أم هل هو "الخطأ الاستراتيجي الأسوأ الذي يمكن لمطور البرنامج أن يرتكبه"؟ اتضح أنه عند العمل مع قاعدة الشفرة الناضجة ، يوجد أكثر من خيارين للإجابة.
"يبدو أن شفرة المصدر صدئة !" - جويل سبولسكي
منذ ما يقرب من عقدين من الزمن ، قام
جويل سبولسكي بتنظيم Netscape لإعادة كتابته قاعدة بيانات المتصفح في مقالته الملحمية
"ما لا يمكنك فعله أبدًا" . لقد توصل إلى استنتاج مفاده أنه
لا ينبغي أبدًا إعادة كتابة البرنامج الوظيفي من البداية . كان لديه حجتان رئيسيتان:
- غالبًا ما تشتمل الأجزاء التي تبدو وكأنها جزء من قاعدة الكود على معرفة تم الحصول عليها بشق الأنفس بشأن المواقف الحدودية والأخطاء الغريبة.
- التغيير الكامل هو مشروع طويل الأجل يصرف الانتباه عن تحسين المنتج الحالي ، والذي يعطي بطاقات رابحة للمنافسين.
بالنسبة للكثيرين ، أصبحت نتائج جويل عقيدة ؛ في وقت واحد كان لديهم تأثير كبير على لي. لكن في السنوات اللاحقة ، أدركت أنه في بعض الحالات لا يزال من المنطقي إعادة المنتج بالكامل. على سبيل المثال:
- في بعض الأحيان ، لا يمكن بالفعل استرداد قاعدة الشفرة القديمة ، لذا فإن الترقية البسيطة تتطلب تغييرات متتالية في أجزاء أخرى من الشفرة.
- حلول التكنولوجيا الأصلية قد تتداخل مع التحسينات اللازمة.
- أو ، قد تكون التكنولوجيا الأصلية قديمة ، مما يجعل من الصعب (أو باهظ التكلفة) تعيين مطورين مؤهلين.
بالطبع ، في الواقع يعتمد الكثير على الظروف. نعم ، في بعض الأحيان يكون من المنطقي إعادة تكوين كود قديم بشكل تدريجي. ونعم ، في بعض الأحيان يكون من المنطقي رمي كل شيء بعيدًا والبدء من جديد.
لكن هذا ليس هو الخيار الوحيد . دعونا نلقي نظرة على ستة قصص ونرى ما هي الدروس التي يمكن تعلمها.
1. نتسكيب
تمت إعادة كتابة رمز المتصفح ثلاث مرات من البدايةكان الانتقال الكارثي لنيتسكيب من 5.0 إلى 6.0 مناسبة للمقالة المذكورة أعلاه التي كتبها جويل سبولسكي وكثيرون مقتنعون بأنه لا ينبغي القيام بذلك.
تم إصدار Netscape Navigator في عام 1994 ، في السنوات الأولى من الإنترنت التجاري. بعد عامين ، افتتحت الشركة عصر dot-com بإصدار عام أولي بقيمة 3 مليارات دولار.
أول منافس رئيسي لشركة Netscape كان Microsoft Internet Explorer ، الذي صدر في عام 1996.
في أوائل عام 1998 ، كان نتسكيب لا يزال المتصفح الرئيسي ، ولكن بصعوبة كبيرة. كان برنامج Netscape عبارة عن برنامج تجاري تم بيعه مقابل 49 دولارًا ، وقد قامت Microsoft بتسليم IE مجانًا وتسليمه كمتصفح افتراضي على Windows.
مع إصدار Netscape 4.0 ، أعلنت الشركة أن الإصدار التالي سيكون مجانيًا وسيتم تطويره بواسطة مجتمع مفتوح المصدر ، تم إنشاؤه بتمويل من Mozilla. في الوقت المناسب ، كانت هذه خطوة غير مسبوقة بشكل أساسي ، واكتسب Netscape الكثير من المؤيدين لمثل هذا القرار الجريء. لكن في الواقع ، فإن هذا "المجتمع" لم يتحقق فعليًا. يوضح جيمي زاوينسكي ، أحد أوائل مطوري المتصفح ،
ما يلي:
الحقيقة هي أن مشروع موزيلا شارك فيه حوالي مائة من مطوري Netscape بدوام كامل وحوالي ثلاثين مطورًا مستقلًا ، لذلك كان المشروع لا يزال مملوكًا بالكامل لشركة Netscape.
توصل الفريق إلى استنتاج مفاده أن المطورين من الخارج لم يكونوا مهتمين بالمشروع ، بما في ذلك بسبب الفوضى في قاعدة الكود:
تبين أن الشفرة معقدة للغاية ومربكة في التغيير ، لذلك لم يساهم الناس ... لهذا السبب تحولنا إلى محرك جديد. قاعدة رمز أنظف وأعذب يسهل فهمها والانضمام إليها.
من الصفر
وهكذا ، بعد مرور عام ، قررت المجموعة التخلي عن الإصدار 5.0 دون إصدار إصدار ، والبدء في تطوير الإصدار 6.0 من نقطة الصفر.
استغرق إعداد Netscape 6.0 عامين كاملين ؛ وحتى بعد كل هذا ، كان من الواضح أن المتصفح كان خامًا. وفقًا
لكاتب العمود في صحيفة نيويورك تايمز ديفيد بوغ ، فإن المتصفح ركض لمدة دقيقة كاملة (!) واستهلك ذاكرة الوصول العشوائي. كانت تفتقر إلى عدد من ميزات قابلية الاستخدام البسيطة التي كانت في الإصدارات السابقة:
اختفت وظيفة معاينة الطباعة ، وكذلك القدرة على سحب أيقونة عنوان الموقع مباشرة إلى قائمة العلامات. أيضًا ، لا يمكنك نسخ أو لصق عنوان ويب في شريط العناوين بالنقر فوقه بزر الماوس الأيمن. وفي كل مرة في بداية العمل ، يتعين عليك تغيير حجم النافذة: لا يتذكر Navigator الحالة السابقة. لكن العيب الأكثر سوءًا هو أنه لا يمكنك تحديد شريط العنوان بالكامل بنقرة واحدة.
ولكن هذا لم يكن ذا صلة تقريبًا ، لأنه في السنوات الثلاث التي بقيت فيها Netscape ثابتة ، استحوذ Internet Explorer على الحصة السوقية المتبقية:
عندما بدأت عملية تحسين المتصفح ، فقدت Netscape موقع Microsoft Internet Explorer بسرعة. خرج المتصفح الجديد بعد ثلاث سنوات ، وكان عربات التي تجرها الدواب وبطيئة. وفي الوقت نفسه ، انخفضت حصة Netscape في السوق إلى الصفر تقريبًا (مخطط مقتبس من ويكيبيديا )في عام 1999 ، عندما كان إعادة تصميم المتصفح على قدم وساق ، استحوذت AOL على Netscape مقابل 10 مليارات دولار ، وبعد عامين فقط من إصدار Netscape 6.0 ، تمت تصفية قسم AOL الخاص بـ Netscape.
ستستمر Mozilla ، مجتمع المصادر المفتوحة الذي أنشأته Netscape ، في إطلاق متصفح Firefox في عام 2002 ، وهو مشروع آخر نظيف. تمكن Firefox من إعادة بعض المستخدمين الذين غادروا إلى Microsoft.
لكن Netscape ، كعمل تجاري ، قد مات (ستدفن Microsoft بقايا الملكية الفكرية لـ Netscape كنتيجة لصفقة 2012 مع AOL).
بعد ربح هذه المعركة ، رفضت شركة Microsoft الاستثمار في تقنية المتصفح. تم إصدار Internet Explorer 6.0 في عام 2001 ولم يتم تحديثه منذ
خمس سنوات . يعتبر البعض أن هذه محاولة متعمدة لمنع الترويج للإنترنت كمنصة للتطبيقات.
الاستنتاجات
يعتقد البعض أن إعادة الكتابة من الصفر لم تكن كارثة. في النهاية ، وبفضل هذا ، ظهر محرك Gecko ومتصفح Firefox في النهاية.
ولكن كان علينا جميعًا أن نتحمل سنوات من الركود في تقنيات الويب في ظل
احتكار IE6 الذي لا نهاية له ، بينما كنا نتطلع إلى متصفح جديد ينفث الحياة في هذه الصناعة. ولم يتم وضع نهاية عصر IE6 بواسطة Firefox ، ولكن Google Chrome.
على أي حال ، لا يتعلق الأمر بكيفية تأثير المشروع على الإنترنت. إنها عن النتيجة بالنسبة للشركة. لا يمكن إلقاء اللوم على وفاة نتسكيب في هذه الأسباب:
وافقت المحكمة على أن مايكروسوفت أساءت استغلال احتكارها عن قصد. لكن بالطبع ، كان قرار إعادة كتابة كل شيء من نقطة الصفر عاملاً مهمًا وأدى إلى النتيجة النهائية: تدمير شركة تبلغ قيمتها مليارات الدولارات وآلاف عمليات التسريح من العمل. لذلك ، أتفق مع جويل في أن
العواقب الصافية لهذا القرار كانت كارثية .
2. القاعده
في أوائل الألفينيات من القرن العشرين ، أصبح استوديو تصميم مواقع الإنترنت الذي يقع مقره في شيكاغو والمسمى
37signals مشهورًا
بمدونته المؤثرة والمثيرة للجدل في كثير من الأحيان ، والتي شارك في تأسيسها مؤسسوها
Jason Fried و
DHH .
عندما بدأت في تصميم المواقع لأول مرة ، لفتوا انتباهي بسلسلة من المقالات مع أمثلة على التصميم وخيارات غير صحيحة لكيفية إعادة تشكيلها لمواقع مثل Google و PayPal. كان يسمى المشروع
37better .
لا يزال إعادة تصميم نموذج التسليم FedEx 37 (أعلاه) أفضل من التصميم الحقيقي ، بعد عقدين تقريبًاكان لدى الشركة
نظام لإدارة المشاريع للاستخدام الداخلي ، والذي أصدروه في عام 2004 كخدمة SaaS تسمى
Basecamp .
ادارة العلاقات مع لا يزال جديدا في ذلك الوقت. تم بيع أدوات إدارة المشروع في صناديق بها علامات أسعار مكونة من أربعة أرقام وأدلة مهمة. لقد عملوا جميعًا على مفهوم نمذجة المسارات الحرجة ورسموا مخططات جانت المعقدة. يباع Basecamp بمبلغ 50 دولارًا شهريًا ، وأصبح نفحة من الهواء النقي من خلال واجهته فائقة البساطة والتركيز على التواصل.
بسرعة إلى الأمام بضع سنوات ، لدى Basecamp نصف مليون مستخدم سعيد ، والمدفوعات تصل كل شهر ، ولكن جايسون وديفيد بدأت تقلق.
منذ بضع سنوات ، روى ديفيد هذه القصة في مؤتمر
أعمال البرمجيات . اعترف بأنه تأثر بجويل سبولسكي ويعتقد أن إعادة كتابة البرمجيات ستقتل الشركة. بالإضافة إلى ذلك ،
كان هناك
عنصر معين من الرضا والصلاح الذاتي فيما يتعلق بشعبية حركة Agile:
تم استيعاب [I] بالكامل في فكرة البرنامج المتسامي ... رمز بلا حدود من البلاستيك. تراث قيمة بلا حدود. يمكنك تغيير أي شيء أو إعادة كتابة أي برنامج أو أي رمز ... إذا كان من الصعب تغيير البرنامج ، فهذا خطأ خاص بك. أنت مبرمج ضعيف ، لذلك تحتاج إلى تحسين.
ومع ذلك ، بعد "سبع سنوات سمينة" وجدت الشركة نفسها في مأزق -
والمشكلة لا علاقة لها بالدين التقني .
الأصفاد الذهبية
بدأ كل شيء بحقيقة أن اللاعبين لاحظوا عدم وجود حماس. لم يكن هناك فقط دافع كاف للعمل على منتج رئيسي ، لكنهم أنفسهم لم يستخدموا برنامجهم بشكل خاص.
لقد كانت لديهم العديد من الأفكار حول كيفية جعل المنتج أفضل بشكل أساسي ، ولكن أي تغيير سيؤدي إلى تعطيل سير العمل المعتاد لمئات الآلاف من مستخدمي Basecamp.
كانت المشكلة ليست في قاعدة التعليمات البرمجية المعقدة ، ولكن في المستخدمين.بسبب الرغبة في إرضاء العملاء الحاليين ، توقف المنتج عن التطوير ، مما حال دون جذب مستخدمين جدد. هذا لم يهدد العمل بشكل مباشر ، لكنه شكل تهديدًا طويل الأجل. قارن DHH الوضع مجازًا مع دلو متسرب:
يمكنك توصيل جميع الثقوب وإصلاح جميع الأخطاء وتحديث جميع الوظائف التي يشكو منها العملاء الحاليون - ولكن جزءًا من الماء يتدفق دائمًا. العملاء يتركون العمل ويتركون البرنامج ، حتى لو [أعجبهم]. قد يتم تضليلك: "مهلا ، الدلو ممتلئ أكثر من النصف. لا يوجد سوى ثقب صغير ، تسرب صغير ، إنه طبيعي تمامًا ". ولكن ، إذا استمر الوضع ، فسيكون الدلو فارغًا تمامًا.
جزء من المشكلة هو أنك تستمع باستمرار إلى العملاء الحاليين ، لكنك لا تسمع عملاء في المستقبل:
الأشخاص الذين زاروا صفحة Basecamp في عام 2011 ورفضوا شراء المنتج لأنه لم يعد يناسبهم: كيف تفكر ، كم عدد المرات التي استمعنا فيها إلى رأيهم؟ ابدا لقد استمعنا فقط إلى قاعدة واسعة من العملاء الحاليين الذين أرادوا منا أن نستمر في سد هذه الثقوب الصغيرة.
بدأ المطورون في اعتبار المنتج المربح بمثابة زوج من الأصفاد الذهبية:
الشيء الرئيسي هو التأكد من أن جميع المستخدمين الحاليين راضون. المال يأتي كل شهر ، شيك جديد ، شيك جديد ، شيك جديد. عظيم لكن بعد ذلك تواصل مع الآخرين واعترف: "هذا كل شيء ، لن أغير برنامجي أبدًا مرة أخرى."
Spoiler: تمت إعادة كتابة Basecamp من البداية ، واتضح أنه رائع. استغرق الأمر حوالي عام ، وفور إصدار Basecamp 2 ، تضاعف عدد التسجيلات الجديدة.
أعتقد أنهم فعلوا شيئين رئيسيين.
أولاً ،
لم يحاولوا إعادة تشكيل المنتج القديم - لأنهم أولاً أرادوا تنفيذ أفكار جديدة حول كيفية التعامل مع حل المشكلات التي حلها المنتج القديم.
هل نحن مفتونون إلى درجة الاعتقاد بأن أفكار 2003 لا تزال أفضل الأفكار لعام 2011؟ نعم ، لقد اتُهمت بالغطرسة ، لكن خرجت كل القوة في عام 2008.
وبالتالي ، قاموا بتقديم Basecamp 2 كمنتج جديد تمامًا ، دون أي ضمانات متوافقة مع Basecamp Classic. ظهرت أشياء جديدة كثيرة ، اختفى شيء ما تمامًا ، وتغير كثيرًا تمامًا.
أعطى هذا القرار درجة معينة من الحرية. الحرية تحفز الناس المتحمسين وتعمل بشكل أفضل.
ساعد عدم الحاجة إلى دعم كل خيار لاستخدام المنتج الأصلي. على سبيل المثال ، سمح لك Basecamp الأصلي باستضافة المستندات على خادم FTP الخاص بك. قام المطورون بإزالة هذا وغيره من الوظائف المشابهة التي كانت منطقية ، لكنهم الآن مهمشون. مثل هذا التخفيض في الوظائف غير الضرورية جعل من الممكن طرح منتج جديد في السوق في غضون فترة زمنية معقولة.
تعتبر الغروب ضارة
ولكن ماذا عن مئات الآلاف من المستخدمين الحاليين الذين استولوا على لعبتهم المفضلة؟ يقودنا هذا إلى الشيء المثير للاهتمام الثاني الذي قام به المطورون:
لقد احتفظوا بالمنتج القديم .
كان لدى David رحلة رائعة على مصطلح "برنامج غروب الشمس":
لقد توصل شخص ما في مكان ما إلى كلمة ملطفة جميلة تسمى "غروب الشمس" ... أطلقوا عليها اسم "غروب" تدمير البرنامج ... مثل ، جميع المستخدمين على الشاطئ - وهم يشاهدون بعاطفة كيف تختفي معلوماتهم. هذا رائع!
الأشخاص الوحيدون الذين يؤمنون بـ "غروب الشمس" هم أولئك الذين يطلقون عليها. ليس هناك مستخدم واحد سبق له أن مر بفترة الغروب ويعود ويقول "أوه ، لقد كان جميلًا". عادوا ويقولون: "اللعنة! لقد وضعت سنوات من العمل هنا! .. والآن أنت ذاهب إلى لي؟ "
وأشار إلى أن إجبار الناس على الحزم والانتقال هو "الخطأ الاستراتيجي الأسوأ" لأنك تجبر جميع العملاء النظاميين على اتخاذ قرار ، أو الاستمرار في استخدام البرنامج ، أو التحول إلى شيء آخر.
هل أحتاج حقًا إلى القاعده؟ إذا كنت لا تزال بحاجة إلى نقل كافة الرسائل غير المرغوب فيها ، فربما نقلها إلى مكان آخر. إذا كنت بحاجة إلى حزم الأشياء في صناديق وتحميلها في شاحنة ، يمكنني ببساطة شحن هذه الشاحنة عبر المدينة. ليست هذه مشكلة كبيرة. المشكلة الكبيرة هي تعبئة جميع المانات. وحيث تنتقل ، مرة أخرى إلى Basecamp أو إلى مكان آخر ، هذه مشكلة ثانوية.
قام ديفيد بمقارنة Basecamp Classic مع Leica M3: لم يتم إنتاج الكاميرا منذ عام 1967 ، لكن لايكا وعدت بصيانتها وإصلاحها حتى نهاية أيامه (الصورة: Dnalor 01 )بدلاً من ذلك ، تعهد Basecamp
"باحترام تراثه" : لقد قاموا بتبسيط عملية الترقية إلى الإصدار الجديد ، لكنهم لم يطلبوا ترك Basecamp Classic. بالإضافة إلى ذلك ، تعهدوا بالحفاظ على Basecamp Classic إلى الأبد.
المزاح هو أنه بعد أربع سنوات قاموا بذلك مرة أخرى: في عام 2015 ، تم إصدار Basecamp 3 ، وإعادة كتابته مرة أخرى من نقطة الصفر ، مع بعض الميزات الجديدة وبدون بعض الميزات القديمة ، ومرة أخرى تغير الكثير. كما كان من قبل ، يمكن لمستخدمي الإصدارات القديمة الترقية بسهولة. ولكن إذا أرادوا ، فيمكنهم الاستمرار في استخدام Basecamp Classic أو Basecamp 2 "حتى نهاية الإنترنت."
القاعده 3 لن يلف شيئا. ليس الإصدار الحالي ، وليس الإصدار الكلاسيكي الأصلي من Basecamp. هل أي من هذه تعمل بشكل جيد بالنسبة لك؟ رائع! يرجى الاستمرار في استخدامه حتى نهاية الإنترنت! نتأكد من بقاء البرامج سريعة وآمنة ويمكن الوصول إليها دائمًا.
ولكن هناك الكثير من "لكن". ليس هو مكلف؟ هل يستغرق دعم الإصدارات المتعددة الكثير من الجهد؟ ماذا عن الأمن؟ ماذا عن الأكواد التي عفا عليها الزمن؟ ماذا يمكنني أن أقول. نحن نهتم فقط بالعملاء ، حتى إذا كانوا لا يرغبون في التحديث وفقًا لجدولنا الزمني.
الاستنتاجات
شخصيا ، هذا النموذج يبدو ملهمًا جدًا لي.
كل تغيير سمح لـ Basecamp بالرجوع إلى الوراء وإعادة صياغة المنتج استنادًا إلى التجربة. بالنسبة للمستخدمين ، هذه لعبة رابحة: المحافظون يحتفظون بلعبهم ؛ والمبتكرين الذين يواجهون قيود النظام يحصلون على تطبيق جديد ، وآمل أن يكون ذلك أكثر تفكيرًا.
بالطبع ، دعم إصدارات متعددة لفترة طويلة بلا حدود يأتي بثمن ؛ ولكن كما يقول ديفيد:
انها ليست حرة. بالطبع لا. هذا منتج ذو قيمة وبالطبع الدعم ليس مجانيًا. لكنه يستحق كل هذا العناء.
3. Visual Studio و VS Code
ملاحظة: محب أيقونةقامت Microsoft بعمل كود VS للوصول إلى المطورين على منصات أخرى.
يجب أن تتذكر أنه لمدة طويلة ، قدمت Microsoft "كل شيء أو لا شيء". إذا كنت تستخدم Visual Studio ، فيجب أن تكون قد عملت في .NET ، والعكس صحيح. أدى هذا إلى تقسيم مجتمع البرامج إلى معسكرين كبيرين ، معظمهما حصريان بشكل متبادل - على حساب الجميع.
نداء الى الرجال بارد
بدأ الموقف يتغير مرة أخرى في سنوات ستيف بالمر: تذكر كيف بصوت عال
قرار مطوري ASP.NET بعدم اختراع jQuery أصبح!
كانت إحدى المهام الرئيسية للمدير التنفيذي لشركة Satya Nadella الاتصال بالمطورين خارج "حديقته المسورة".
ولكن كانت هناك مشكلة. إليكم ما تقول جوليا لويسون ، نائبة رئيس Visual Studio في
هذه الطبعة من بودلاست Changelog:
لم نتمكن من تقديم فئة كاملة من المطورين: حديث ، موجه نحو الويب ، يعمل مع Node و JavaScript - لم يكن لدينا شيء نتحدث عنه معهم. ببساطة لم نتمكن من جذب هؤلاء المطورين.
لذلك تم إنشاء رمز VS لكسر هذا الحاجز والقول ، "هل تعرف حقًا ماذا يا شباب؟ لا يزال لدينا شيء مفيد لك. "
إن Visual Studio منتج ثقيل الوزن بكل معنى الكلمة: التثبيت فقط يمكن أن يستغرق أكثر من نصف ساعة. وهو يدعم مجموعة واسعة من حالات الاستخدام المعقدة التي يعتمد عليها العملاء من الشركات. وبالتالي ، لم تكن هناك فائدة من أخذ Visual Studio كنقطة بداية
وإضافة ميزات في مشروع جديد على منصات أخرى. ومن الواضح أن فكرة إطلاق Visual Studio لنظام التشغيل Mac أو Linux لم تكن مدعومة بشكل خاص.
لذلك ، بدأت Microsoft من نقطة الصفر ، دون ضمانات التوافق مع الإصدارات السابقة.
في الواقع ، ليس تمامًا من البداية: لدى Microsoft بالفعل بعض الأجزاء المهمة ، مثل محرر Monaco في المتصفح. ولأن VS Code هو تطبيق Node.js (مكتوب في Typescript وتم إطلاقه في Electron) ، فقد استفادوا من الموارد الغنية لنظام جافا سكريبت البيئي.
أصبح رمز المصدر المفتوح VS ، خفيف الوزن وسريع وقابل للتمديد - وهو أمر يثير الدهشة لمنتج Microsoft - أداة برمجة عصرية للشباب المتقدم.
أصبح VS Code هو المحرر الرئيسي لـ JS-hipsters (رسم تخطيطي للتقرير State of JavaScript Survey، 2018 )لا يزال كلا المنتجين قيد التطوير النشط ، وليس هناك ما يشير إلى أن Microsoft تعتزم إغلاق Visual Studio.
الاستنتاجات
على عكس Netscape ، تمكنت Microsoft من إنشاء مجتمع نشط مفتوح المصدر حول VS Code. زاد من جهود المطورين لتحسين المنتج.
من بين جميع المشاريع مفتوحة المصدر ، يحتل Visual Studio Code المرتبة 13 من حيث عدد النجوم على جيثب - من قبيل الصدفة ، أسفل لينكس مباشرة!بالطبع ، لا يمكن لكل شركة أن تسمح لمنتجها الرئيسي بأن يكون متاحًا مجانًا. ولكن إذا كان المصدر المفتوح جزءًا من استراتيجية التطوير الخاصة بك ، فمن المنطقي مقارنة قصص Microsoft و Netscape - ومعرفة ما قامت به Microsoft بطريقة مختلفة حتى يزدهر مجتمعها.عامل مهم آخر: قامت Microsoft بتزويد VS Code بنموذج قابلية عالية للتوسعة ، ونتيجة لذلك كتب المجتمع بالفعل حوالي 10000 امتداد.أحد الاستنتاجات الأخيرة من تاريخ VS Code هو أنه خلال السنوات القليلة الماضية ، تغير كل شيء بشكل كبير: في هذه الأيام أصبح إنشاء النماذج الأولية والبرامج أسهل من أي وقت مضى .على الرغم من الانزعاج من تعقيد الأدوات الحديثة ، فقد أصبح نظام جافا سكريبت البيئي على مدار السنوات القليلة الماضية جنة حقيقية مفتوحة المصدر. في هذا الصدد ، الآن هو وقت غير مسبوق تاريخيا.
4. بريد جوجل والبريد الوارد
ملاحظة: تمتقديم رمز غروب Inbox for Gmail في الأصل باعتباره UX بديلاً بسيطًا لـ Gmail ، "مع التركيز على ما يهم حقًا." لم يحاول مطلقًا مطابقة وظائف Gmail الأصلية ، وقدم ميزات جديدة: المجموعات المواضيعية (حزم) ، والرسائل المثبتة والرسائل المعلقة.قبل بعض المستخدمين ، بمن فيهم أنا ، صندوق الوارد الوارد بحماس. اعتقدت دائمًا أن Inbox كان عرضًا لما سيصبح Gmail في نهاية المطاف ، لذا فقد تعاملت مع نقص بعض الفروق الدقيقة في Gmail ، وأتوقع منهم أن يصلوا في النهاية إلى Inbox.واجهات اثنين ، خدمة واحدة
يعمل البريد الوارد و Gmail على نفس الخلفية. في الواقع ، هذه مجرد واجهات مستخدم مختلفة لنفس الخدمة ، ويمكنك التبديل ذهابًا وإيابًا كما تشاء. كان لهذا ميزاته وعيوبه: إذا كانت علبة الوارد تفتقر إلى وظيفة (على سبيل المثال ، جهاز الرد على المكالمات لقضاء إجازة) ، فيمكنك دائمًا الرجوع إلى Gmail وتكوين ما تحتاج إليه ، على الرغم من أن التبديل بين يديك وإليه بدا غريبًا.ومع ذلك ، بعد فترة ، توقف صندوق الوارد عن التحسن - أصبح من الواضح أن Google لم تعد تستثمر الموارد فيه. بطبيعة الحال ، بعد مرور أربع سنوات على إطلاقه ، أعلنت Google عن غروب Inbox .مثل أي شخص آخر ، في البداية كنت غاضبًا من هذا القرار. ولكن بعد قضاء بعض الوقت مع أحدث إصدار من Gmail ، وجدت أن العديد من ميزات Inbox المفضلة الخاصة بي قد تم نقلها إلى المنتج الأصلي : إجابة ذكية وإجراءات تحويم ومرفقات مضمنة وصور. تحل العديد من صناديق بريد Gmail محل مجموعات سمات علبة الوارد بشكل جيد.ولكن لم يتم نقل كل شيء من Inbox إلى Gmail: على سبيل المثال ، يتم استخدام الأشخاص على "وضع الإيقاف المؤقت" (قيلولة بعد الظهر) بحيث بدونه يعانون جسديًا حرفيًا.الاستنتاجات
مكّن البريد الوارد مطوري Gmail من تجربة الميزات دون تعطيل سير عمل الغالبية العظمى من المستخدمين.ومع ذلك ، وبتقديم كلا الإصدارين على نفس الخلفية ، فرض Gmail قيودًا شديدة على الابتكار .مرة أخرى ، تم انتقاد Google كثيرًا لإغلاقها الخدمة الشعبية. وبطبيعة الحال، وجوجل بشكل دائم يغلق على المشاريع ، بحيث لا شيء غير متوقع.ولكن في هذه الحالة ، دفعنا موقف Google الأولي تجاه Inbox إلى الاعتقاد بأن لدينا عرضًا تجريبيًا لمستقبل Gmail. كما يقول DHH ، خرج غروب الشمس قبيحًا: وجد الكثير من الناس أنه من غير السار العودة إلى منتج قديم وفقدان سير عمل Inbox المبتكرة.أعتقد أنه بالنسبة للكثيرين ، كان الانتقال أسهل بكثير ، قبل إغلاق البريد الوارد ، تم دمج جميع وظائفه في Gmail.
5. FogBugz و Trello
ملحوظة:تمثل أيقونات FogBugz للانحدار الحزين و "المال ، والمال ، والمال" حالة مثيرة للاهتمام بشكل خاص ، لأن هذا نتاج لجويل سبولسكي نفسه: إنه يعطي فكرة عن كيفية مواجهة مبدأ "عدم إعادة الكتابة" مع الحياة الحقيقية.قبل ظهور إصدارات Jira و GitHub ، كان هناك نظام تتبع التذاكر عبر الإنترنت يسمى FogBugz. تم إطلاق هذا النظام في عام 2000 ، وكان أول منتج لشركة Fog Creek Software الجديدة ، التي أسسها Joel مع Michael Prior. لأكثر من عقد من الزمان ، ظلت FogBugz المنتج الرئيسي. في البداية ، تم بيعها فقط كإصدار محاصر للتثبيت على خوادمها الخاصة ، ولكن في وقت لاحق تم إصدار خيار SaaS مع دفع الاشتراك.أصبح موقع FogBugz شائعًا للغاية ، لا سيما بين المطورين الذين قرأوا ، على سبيل المثال ، مدونة جويل وأخذوا نصائحه إلى القلب. استخدمت شركتي النظام لسنوات عديدة ، لقد كان منتجًا رائعًا لوقته.كتب FogBugz في الأصل على ASP الكلاسيكية ، التي عملت على خوادم Windows. عندما خرج ASP.NET ، أوضح جويل سبب عدم تعجله بالتحديث .لتثبيت FogBugz على خوادم Linux ، كتب متدرب في شركة مترجم Thistle لتحويل ASP التقليدي إلى PHP. بحلول عام 2006 ، تطور Thistle إلى لغة برمجة خاصة تسمى Wasabi ، والتي تم تجميعها في ASP و PHP و JavaScript من جانب العميل.قصة الوسابي الغريبة
في الوقت الحاضر ، يعد تطوير لغة البرمجة الخاصة والمترجم الخاص بك ، كما يقول ، خيارًا غريب الأطوار. لذلك من المثير للاهتمام أن نرى كيف حدث كل شيء.في وقت من الأوقات ، ذكر جويل الوسابي في إحدى مدونته. اعتقد البعض أنها كانت مزحة ، لذلك أوضح أنها ليست مزحة . جيف أتوود ، زميل مدون ، فجر رأسه من هذه الأخبار:الكتابة بلغتك الخاصة تتجاوز الحدود تمامًا. هذا هو الحل السام الذي يتعارض مع نصائح جويل السابقة لتطوير البرمجيات الممتازة والقوية التي اعتقد الناس حقًا أنه يمزح.
أصر جويل
على أن القرار منطقي من منظور الأعمال. بالطبع ، من الناحية النظرية ، لا يستحق اختراع لغتك الخاصة ، ولكن إذا قمت بتقييم كل خطوة صغيرة نحو هذا القرار ، بالنظر
إلى السياق التكنولوجي وقاعدة الشفرات ، فكل شيء يبدو منطقيًا.
التفكير في الوسابي في مقال كبير بعنوان
"الدين الفني والبحث عن الريح" ، يقارن المهندس السابق Fog Creek Ted Unangst العملية بالسفر دون خريطة:
تخيل أنك في سافانا ، جورجيا ، وتريد الذهاب إلى لندن ، إنجلترا. ليس لديك خريطة ، بل إحساس غامض بالاتجاه ... أنت لا تسير في خط مستقيم لأنك لا تملك قاربًا ، ولكن المحيط أمامك. ولكن من ناحية أخرى ، يؤدي الشاطئ الجميل إلى الشمال الشرقي ، وهذا هو الاتجاه الصحيح تقريبًا. أنت تمشي على طول الشاطئ ، والمشي والمشي. الوقت يمر. أنت ترى وترى أنه مع كل خطوة تقترب من الهدف ، على الرغم من أنك لا تتحرك نحو ذلك مباشرة.
في مكان ما في بوسطن ، أو في نوفا سكوتيا ، تتوقف أخيرًا وتفكر في اختيارك. ربما هذا الطريق لا يؤدي إلى لندن؟ بعيدًا عن المعرض ، يمكنك سماع الضحك: "ها ها ها ها ، انظر إلى هذه البلاهة. إنهم لا يرون الفرق بين إنجلترا ونيو إنجلترا. أعط هؤلاء الحمقى خريطة ". لكن هذه هي المشكلة بالتحديد: ليس لديك بطاقة. يتم عمل الخرائط بواسطة أشخاص لا يعرفون بحكم تعريفهم إلى أين يذهبون.
في أي حال ،
يوضح جاكوب كرال ، مطور سابق آخر لشركة Fog Creek ، أن الحل ضحى بصيانة الغد لسرعة التطوير الحالية. وبحلول عام 2010 ، بدأت حسابات هذا الدين في الوصول.
لم نضع [Wasabi] في المصدر المفتوح ، لذا فقد تكبدنا التكاليف بمفردنا ، نظرًا لمنتجاتنا الرئيسية المربحة ... لقد كان اعتمادًا كبيرًا يتطلب مطورًا دائمًا على هذا المنتج وحده: ليس رخيصًا بالنسبة لشركة بحجمنا. أحيانًا يكون المحول البرمجي لعن جزءًا من التعليمات البرمجية التي تبدو معقولة جدًا للشخص. انه جمع ببطء. تعذر على Visual Studio تحرير المصحح أو توصيله بسهولة بـ FogBugz ... تم تدريب جميع الموظفين الجدد لفترة طويلة من قبل Wasabi ، بصرف النظر عن تجربتهم السابقة ... بالإضافة إلى ذلك ، لم نكن نعيش في فراغ. لقد تحسنت لغات البرمجة ، بالطبع ، خارج Fog Creek ... بدأ المطورون يشعرون أن أفكارهم الرائعة تواجه قيود عالمنا الوسابي الصغير.
نقطة انعطاف
بحلول ذلك الوقت ، كان FogBugz يبلغ من العمر عشر سنوات: لقد كان منتجًا ناضجًا ومستقرًا. كمشروع جانبي ،
أطلق Joel Stack Overflow مع Jeff Atwood (من الواضح أن رئيس Jeff's Blown قد تمكن من الشفاء بحلول ذلك الوقت).
FogBugz هو الشيخوخة تدريجيا. على الرغم من أن سوق تعقب الأخطاء ظل مجزأًا ، إلا أن جيرا من شركة Atlassian ، والتي ظهرت بعد عامين من FogBugz ، احتلت مركز الصدارة. لقد أصبح الخيار الافتراضي ، خاصة بالنسبة للمستخدمين من الشركات الكبيرة.
من المثير للاهتمام حقًا أن ننظر إلى نقطة الانعطاف هذه في تاريخ FogBugz. مثل Basecamp ، لديهم منتج مربح وناضج. نعم ، لم يعد من المألوف بعد الآن ، وربما لم يكن من المثير للاهتمام العمل عليه. للأفضل أو الأسوأ ، فهو يشتمل على سنوات عديدة من التغيير التكنولوجي وأفكار جديدة حول كيفية حل مشكلة واحدة محددة: تتبع الأخطاء.
بالطبع ، كان هناك خيار Basecamp: مع الأخذ في الاعتبار كل الخبرة ، خذ FogBugz وأعد كتابته من البداية. أفترض أن هذه الفكرة لم تذهب بعيداً ، لأننا نتذكر: "ما الذي لا يمكن فعله أبدًا" ، "أسوأ خطأ استراتيجي" وما إلى ذلك.
لقد اشتعلت مؤخراً مقال في عام 2009 كتبه جويل لصالح
شركة. مجلة عمود مؤلفه بعنوان "هل النمو البطيء يعني الموت البطيء؟" لهجتها لا تشبه تمامًا البهاء العادي الذي يثق في نفسه: إنها تبدو استقلالية ، غير مؤكدة ، مليئة بالشكوك. يخشى جويل من النمو السريع لشركة أتلاسيان ، ويناقش ما إذا كان هناك مجال للعديد من اللاعبين في السوق.
كان علي أن أفكر. لدينا منافس كبير ينمو بوتيرة أسرع بكثير منا. تقوم الشركة بإغلاق صفقات كبيرة مع العملاء من الشركات الكبيرة ... وفي الوقت نفسه ، فإن منتجنا أفضل بكثير ونحن شركة مُدارة جيدًا ، لكن هذا لا يبدو مهمًا. لماذا؟
يقرر أن يفعل شيئين. أولاً ، أضف
جميع الميزات إلى FogBugz :
تتمثل مهمة فريق التطوير لعام 2010 في التخلص من أي سبب محتمل لقيام العملاء بشراء القمامة من منافسينا لمجرد وجود بعض الوظائف الصغيرة التي يفترض أنهم لا يستطيعون العيش بدونها. بصراحة ، لا أعتقد أنه سيكون من الصعب للغاية.
ثانيا ،
إنشاء فريق مبيعات الشركات . يعترف جويل بأنه غير قوي هنا ، ويجد هذه المهمة غير سارة.
لا أعرف كيف نجحت هذه الإجراءات. ذكر جويل آخر مرة FogBugz على مدونته
في مايو 2010 ، حيث أعلن لفترة وجيزة عن إصدار جديد.
أمل جديد
وهذا
ما حدث:
في مجال الذكرى السنوية العاشرة لبرنامج Fog Creek Software ، بدأت أفكر: من أجل الحفاظ على تحفيز موظفينا لمدة عشر سنوات أخرى ، نحتاج إلى بدء العمل على شيء جديد.
لذلك ، تم تقسيمهم إلى فريقين ، كل منهما صنع نموذجًا أوليًا لمنتج جديد. تم إنشاء الفكرة الفائزة بروح
لوحة kanban - وهي لوحة غير
متصلة بالإنترنت يتم استخدامها غالبًا في مشاريع تطوير البرامج: عادة ما تبدو مثل الملاحظات مرتبة في أعمدة على لوحة.
قدم جويل هذا البرنامج كأداة إدارة على مستوى أعلى من FogBugz:
بصراحة ، مع كل هذا البرنامج الهائل من أجل "إدارة المشاريع" ، لم أتمكن أبدًا من تتبع من يعمل على ما ... بصفتي مؤسس شركتين ، كنت أمشي في الممرات ورأيت عشرات الأشخاص الذين يتقاضون رواتبهم للجلوس على أجهزة الكمبيوتر ... ولم يكن لدي أي فكرة عما إذا كانوا يقومون بعملهم بشكل صحيح أو ما إذا كانوا يعتبرون أنه من المهم في الواقع ما قد لا يهم.
عند إنشاء Trello ، حصل مطورو Fog Creek على فرصة لاستخدام التقنيات الحديثة:
نحن نستخدم التكنولوجيا المتقدمة ، لذلك لا يخلو من التضحيات. تنتشر جروح المطور لدينا في جميع أنحاء MongoDB و WebSockets و CoffeeScript و Node. لكن الآن هم مهتمون. في سوق العمل المزدحم اليوم ، يقرر المبرمجون الموهوبون الكثير حول ما يريدون العمل عليه. إذا أعطيتهم منتجًا مثيرًا للاهتمام ... فسيحبونه وسيحبون شركتهم.
دعم الإضافات Trello من البداية ، لذا بدأ مطورو الطرف الثالث بالمساعدة:
تحظى الإضافات وواجهات برمجة التطبيقات (APIs) بالأولوية القصوى ... لا تقم أبدًا بإعداد منتج بنفسك إذا كان بإمكانك توفير واجهة برمجة تطبيقات أساسية ، وسيعمل المستخدمون القيمون على توفيره لك. هناك قاعدة لفريق Trello بأنه إذا كان يمكن تنفيذ أي وظيفة من خلال مكون إضافي ، فيجب أن يتم تنفيذها بهذه الطريقة.
بالطبع ، فهم المبرمجون على الفور فوائد تريللو ، لكن لم يكن هناك شيء محدد في الأداة لتطوير برامج محددة. وصف جويل تريللو كأداة مفيدة "لكل شيء تريد مشاركة
القوائم فيه مع أشخاص آخرين." سرعان ما بدأ استخدام Trello لتنظيم كل شيء على التوالي: من
حفلات العشاء الأسبوعية إلى
حفلات الزفاف وملاجئ الكلاب .
بينما كان FogBugz منتجًا
رأسيًا موجهًا إلى مكانة سوق محددة - كان Trello منتجًا
أفقيًا مناسبًا لأي شيء. يعتبر جويل "الحركة الأفقية" لـ Fog Creek صحيحة في تلك المرحلة:
يكاد يكون من المستحيل إنشاء منتج أفقي كبير ، مفيد في جميع المجالات. لا يمكن أن يكون مكلفًا ، لأنك تنافس المنتجات الأفقية الأخرى التي يمكنها استيعاب تكاليف التطوير الخاصة بك لعدد كبير من المستخدمين. هذه مخاطرة عالية ومكافأة عالية: هذا المسار غير مناسب للشركات الناشئة الناشئة ، ولكنه فكرة جيدة لمنتج ثانٍ أو ثالث من شركة ناضجة ومستقرة مثل Fog Creek.
للتوسع بسرعة إلى عدد كبير جدًا من المستخدمين ، تم عرض Trello في البداية مجانًا. في وقت لاحق قدم
خطة العمل .
في عام 2014 ،
تم تمييز شركة
Trello كشركة مستقلة. بعد ثلاث سنوات ،
باعت أكثر من 425 مليون دولار مع أكثر من 17 مليون مستخدم. ومن المفارقات أن المشتري كان الأطلسية ، العدو القديم لجبهة الضباب.
في غضون ذلك ، نعود إلى الوطن ...
واصل Fog Creek تطوير منتج جديد آخر ، وهو بيئة برمجة تعاونية تسمى
HyperDev ، تمت إعادة تسميتها لاحقًا باسم
GoMix ثم
Glitch .
في الوقت نفسه ، جمد نظام FogBugz في الغموض. في عام 2017 ، قرر شخص ما أن FogBugz هو اسم سخيف ، والجهد الهندسي ذهب إلى إعادة تسمية المنتج كـ
Manuscript . بعد عام - قبل بضعة أشهر فقط - باع Fog Creek المنتج لشركة صغيرة
DevFactory ، التي
أعادت اسم FogBugz على الفور .
تحت قيادة الرئيس التنفيذي أنيل داش ، أصبح Fog Creek شركة منتج واحد
وغيرت اسمها إلى Glitch .
الاستنتاجات
لدي الكثير من الأفكار حول هذا الموضوع.
المفتاح لفهم التاريخ هو أن Fog Creek لم يهتم دائمًا بتتبع الأخطاء بقدر ما كان يتعلق
بتمكين المبرمجين - بدءًا من تلقاء نفسه:
المهمة الرئيسية: لخلق ظروف عمل مريحة. لقد صنعنا حسابات شخصية للموظفين ، فقد طاروا من الدرجة الأولى فقط ، وعملوا 40 ساعة في الأسبوع ، وتلقوا وجبة غداء مجانية ، وكراسي Aeron وأفضل أجهزة الكمبيوتر. شاركنا صيغتنا البارعة مع العالم: ظروف عمل ممتازة ← مبرمجون ممتازون ← برمجيات ممتازة ← ربح!
بناءً على هذه "الصيغة" ، يمكن التوصل إلى استنتاج منطقي ومشجع: بنى Fog Creek مشروعًا تجاريًا حول سعادة المطورين. أثر هذا على كل من منتجات الشركة و
"نظام التشغيل" الداخلي. كان المنتج الأول ، وهو تعقب الأخطاء ، بمثابة الأساس لإطلاق منتج جديد يحل مشكلة مماثلة بطريقة أكثر تجريدية.
وفقًا لجويل ، يبدو أن قصة Trello ليست بحثًا عن عمل جديد بقدر ما هي
فرص لدعم حافز ومشاركة مطوري Fog Creek . كان المنتج بقيمة نصف مليار دولار مجرد تأثير جانبي لطيف.
ومع ذلك ، حزينة بعض الشيء كيف انتهى كل شيء ل FogBugz. لا أعتقد أن مطوري Fog Creek كانوا سعداء بشكل خاص في الأيام الأخيرة قبل البيع.
من الواضح أن هناك مشاريع أكثر أهمية وأكبر: Stack Overflow و Trello و Glitch - كل على حدة أكثر فائدة وأكثر قيمة من FogBugz ؛ ومن المستحيل على شخص واحد تتبع كل شيء. لذلك ، لا أستطيع إلقاء اللوم على أي شخص ، على وجه الخصوص ، لفقدان الاهتمام في FogBugz بقاعدة الشفرة لمدة 20 عامًا والمنافسة القوية في السوق. لكن المستخدمين المخلصين على الأقل وجدوا منزلًا جيدًا ولم يتلقوا دواءًا لغروب الشمس!
ومع ذلك ، يفضل الجزء العاطفي مني "تكريم تراث" جميع المشاركين في إنشاء واستخدام هذا المنتج على مدار السنوات الماضية.
6. FreshBooks و BillSpring
ملاحظة: أيقونة العملية السريةنمت المقالة أكثر مما كنت أتوقع ، لكن لا يمكنني ترك هذه القصة جانباً. انتظر ، سيكون هناك منعطف غير متوقع.
توقفني إذا سمعت ذلك من قبل
في أوائل العقد الأول من القرن العشرين ، كان
لدى Mike McDerment شركة تصميم صغيرة. قرر أن برنامج المحاسبة كان معقدًا جدًا ، لذا استخدم Word و Excel لإعداد الفواتير.
كل شيء سار على ما يرام
حتى حالة واحدة :
جاءت اللحظة الحرجة عندما حفظت القضية فقط فاتورة عميل مهمة - لقد قمت فقط بالنقر فوق الزر المطلوب. كنت أعلم أنه يجب أن يكون هناك طريقة أفضل ، لذلك أمضيت الأسبوعين المقبلين في برمجة نموذج أولي سيكون أساس FreshBooks اليوم.
مايك مصمم ، وليس مبرمجًا ، لكنه تمكن هو واثنين من المؤسسين من وضع أداة جيدة بما يكفي لعدة أشخاص لدفع 10 دولارات شهريًا لاستخدامها.
استغرق الأمر ما يقرب من أربع سنوات لقطاع الأعمال لمغادرة الطابق السفلي من منزل الوالدين.
بحلول الذكرى العاشرة للبرنامج (هل يبدو ذلك مألوفًا؟) أصبحت Freshbooks شركة مربحة تضم أكثر من 10 مليون مستخدم و 300 موظف.
ولكن كانت هناك مشكلة واحدة. بحلول الوقت الذي تمكنت فيه الشركة من توظيف مبرمجين "حقيقيين" ، كان لديهم مليون سطر من "رمز المؤسس". قام محلل خارجي بمراجعة قاعدة الشفرة وخلص إلى:
والخبر السار هو أنك قد حلّت المهمة الأكثر صعوبة. لقد تعرفت على كيفية بناء مشروع تجاري ، ولديك منتج يحبه الناس. الأخبار السيئة هي أنكم يا رجال على دراية سيئة بالتكنولوجيا ".
والأهم من ذلك ، كان من المستحيل تنفيذ الأفكار الحالية في منتج موجود:
أسسنا الشركة منذ أكثر من عشر سنوات ، تغير العالم ، وتعلمنا الكثير عن تطوير البرامج واحتياجات أصحاب المشاريع الفردية ، والتي أصبحت أكثر فأكثر في المجتمع ... لقد أدركنا أنه يلزم بذل بعض الجهود للحفاظ على تحديث FreshBooks في غضون خمس سنوات.
MacDerment على
دراية بالحكمة التقليدية التي لا يمكنك إعادة كتابة نظام من البداية:
إعادة كتابة التعليمات البرمجية من نقطة الصفر هو أكبر خطر لشركة البرمجيات. على الأرجح ، لن تنتهي من المشروع. سيستغرق الأمر وقتًا أطول مما هو مخطط له ، وسوف يكلف أكثر. النتيجة النهائية قد لا تروق للعملاء. وليس هناك ما يضمن أن النظام الجديد سيكون بالفعل أفضل من النظام السابق. القاعدة الأولى في البرنامج ليست إعادة كتابة البرنامج.
وهكذا ، قاموا بعدة محاولات لمسح الفوضى دون إعادة كتابة النظام من نقطة الصفر ؛ لكن "استبدال الإطارات أثناء التنقل" لم يكن ممكنًا.
ما حدث بعد ذلك قد يفاجئك
تمت زيارة McDermint بفكرة إنشاء كتب منافس لـ "منافس" سرا.
أسس شركة جديدة تمامًا في ولاية ديلاوير تسمى BillSpring. كان لديها موقع الويب الخاص بها ، والعلامة التجارية والشعار. حاول عدم الاتصال بين الشركتين ، وأمر محاميا خارجيا لتطوير وثائق جديدة لها.
قام فريق التطوير بتنفيذ ممارسات تطوير
سريعة تستند إلى كتاب أعده
جيف جوتلف وجوش سايدن "Lean UX: تصميم منتجات رائعة مع فرق مرنة" : فرق سكروم وتكرار أسبوعي مع تعليقات من عملاء حقيقيين. طلب منهم MacDerment أن يتصرفوا مثل بدء التشغيل ، وأن يأخذوه كمستثمر في مشروع:
لديك أربعة أشهر ونصف. إذا دخلت السوق ، احصل على المزيد من المال. خلاف ذلك ، فإن النهاية. "
تمكن الفريق من الإفراج عن MVP قبل بضعة أيام من الموعد النهائي. لقد اشتروا كلمات رئيسية في AdWords لزيادة عدد الزيارات ، وقدموا للمستخدمين حسابات مجانية للسنة الأولى. قريباً ، ظهر العملاء - وبدأت دورات التكرار السريع للمنتج الحقيقي.
في نهاية السنة الأولى ، بدأت BillSpring بتوجيه الاتهام. في مرحلة ما ،
تلقى المنتج الجديد
تقييمًا غير متوقع للجودة :
يقول مكديرمنت: "شخص واحد دعا إلى إلغاء الاشتراك من FreshBooks والانتقال إلى شركتنا الجديدة". "لقد كان يوما رائعا."
سرعان ما رفعوا حجاب السرية وأبلغوا عملاء BillSpring بأنه منتج FreshBooks ، وأبلغوا عملاء FreshBooks الحاليين أن إصدارًا جديدًا سيصدر قريبًا.
تدريجيا ، تم قبول عملاء FreshBooks "الكلاسيكية" في الإصدار الجديد ، لكن يمكنهم دائمًا العودة إلى الإصدار القديم إذا أرادوا ذلك.
الاستنتاجات
لم يكن مشروع FreshBooks السري رخيصًا: طبقًا لماكدميرت ، فقد أنفقوا عليه 7 ملايين دولار ، لكن بعد أكثر من عقد من النمو ، جمعوا 30 مليون دولار من رأس المال الاستثماري على مواردهم الخاصة فقط ، لذلك كان هناك أموال. لا يمكن للجميع تحمله.
قدرت فوربس إيرادات FreshBooks في عام 2013 بمبلغ 20 مليون دولار ، وبعد اكتمال التحديث في عام 2017 ، كسبت 50 مليون دولار ، ومن غير المعروف كم جاء من المنتج الجديد ، لكن كتابة نظام من نقطة الصفر لم يبطئ بشكل واضح نمو الشركة.
يقول MacDerment أن عملية تطوير وتنفيذ ميزات جديدة أصبحت أسرع وأسهل. الأهم من ذلك ، لديهم الآن في أيديهم منتج ينفذ أفضل الأفكار. مع هذا واحد لا يخاف أن ننظر إلى المستقبل.
بالإضافة إلى ذلك ، فإن الخبرة المكتسبة قد غيرت ثقافة الشركة - بطريقة جيدة. عندما تظاهروا بأنهم بدء التشغيل ، تعلموا كيفية العمل كبداية. انتشرت ممارسات Lean UX في فريق التطوير بأكمله. يشارك العملاء بنشاط في تطوير ميزات جديدة.
اتخذت FreshBooks تدابير استثنائية لحماية نفسها من المشاكل المحتملة: من خلال تقديم الابتكارات تحت العلامة التجارية المزيفة ، يمكن للمطورين إعادة التفكير في البرنامج بشكل كامل وتحمل مخاطر كبيرة. حتى في أسوأ الحالات ، لن يضروا بالعلامة التجارية الحالية.
يبدو كل شيء متطرف بعض الشيء. ربما كانت هذه التدابير ليست ضرورية. لكن هذا تذكير بمدى خطورة المخاطر.
بعض الأفكار
من المقبول عمومًا أنه من الأفضل تجنب إعادة كتابة البرنامج من البداية ، وإدخال تحسينات تدريجية إن أمكن. بالنسبة للجزء الأكبر ، وأنا أتفق مع ذلك.
لكن النصيحة تشير إلى أنه في النهاية نحصل على منتج أصلي
بالإضافة إلى مجموعة من الميزات الجديدة.
ولكن ماذا لو كنت تريد
إزالة وظيفة؟ أو تنفيذ بعض الخيار بشكل
مختلف تماما؟ ماذا لو جاءت التجربة بأفكار مقاربة جديدة بشكل أساسي؟
استنتاجي من هذه القصص هو: بمجرد أن تفهم أن الإصدار الحالي
مختلف تمامًا عن المثالية الوهمية ،
لا ينبغي إصدار النسخة الجديدة
كبديل ، ولكن بالتوازي مع الإصدار الحالي .
عندما تكون هناك أفكار لإعادة كتابة كل شيء من البداية ، قد يكون من المفيد طرح أسئلة أخرى. ربما خلق منافسيك؟ إذا كان المنتج الخاص بي هو FogBugz ، فماذا سيكون Trello الخاص بي؟ إذا كان هذا هو Visual Studio ، كيف سيبدو رمز VS الخاص بي؟
إذا قارنا
مقالة Spolsky حول Netscape
ونشرة DHH حول Basecamp ، فإنهم يتفقون على شيء واحد: Legacy له قيمة.
الأخبار الجيدة هي أنك لست بحاجة إلى التخلص من هذه القيمة للابتكار.