كيفية جعل عملية الإطلاق الخاصة بك المشي في الحديقة

الصورة عن طريق جيمي تايلور على Unsplash

كان 2:00. كان هاتفي لا يزال ينبض بالحديث مع مطوري البرامج حول كيفية التعامل مع 404 صفحة. كانت فقط البداية ...

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

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

كما ينص قانون مورفي:

أي شيء يمكن أن تذهب الخطأ، وسوف تذهب الخطأ.

كيف نطلق منتجًا ونتأكد من عدم حدوث خطأ ما (بقدر ما نستطيع)؟

في ما يلي الإصدار التجريبي من استراتيجيتي للإطلاق التالي.

هل لديك محتوى للأسبوع الأول

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

في النهاية ، نحن نبحث عن الأشياء بسبب التغييرات المفاجئة في الصور والنصوص - "الأشياء الصغيرة".

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

يضيع الوقت الثمين خلال هذا الاتصال ذهابًا وإيابًا.

كيفية حث العميل على تقديم المعلومات التي تحتاجها دون أن تكون وقحًا

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

ماذا لو قال العميل ، "Chill ... bro ، نحن على ذلك". وليس هناك إجراء واضح ترى أنه تم اتخاذه؟

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

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

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

كن حازما على تجميد الميزة

تجميد الميزات هو مفهوم مفيد يُقال أسهل من القيام به.

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

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

قطعة منفصلة من الوظائف المطلوبة من قبل أصحاب المصلحة - أوليفر دولان

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

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

لذلك قد نضعه في جدولنا كميزة.

الصورة عن طريق rawpixel على Unsplash

ولكن ، كيف نقرر ما إذا كانت هذه الميزة تستحق وقتنا؟

فيما يلي الأسئلة التي تطرحها على فريقك وعميلك عن كل ميزة تخطط لتنفيذها

  1. ماذا يحدث إذا لم ننفذ هذا؟
  2. ما هو مستوى الأولوية لهذا؟
  3. هل لدينا القدرة على القيام بهذا العمل دون تأخير تاريخ الإطلاق؟

كن أكثر حزما مع آرائك

تؤثر متلازمة إمبوستر في جميع مراحل حياتنا المهنية. عندما يقول مطور كبير لديه خبرة 20 عامًا ، فلنفعل ذلك بهذه الطريقة ، ولست متأكدًا بنسبة 100٪ من الجدال المضاد ، فأنت تهمس تحت أنفاسك ، "أوه ... حسنًا".

هذا هو ما أقوم به عندما لا أستطيع التوصل إلى حل أفضل على الفور.

لذلك ، كيف نستعد لحالات مثل هذا؟

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

اعتني بـ DevOps أولاً

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

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

لذلك ، كيف يمكن أن نفعل ذلك بطريقة مختلفة؟

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

لديك قائمة مرجعية للاختبار

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

أنا لا أتحدث عن كتابة التعليمات البرمجية لاختبار التعليمات البرمجية الخاصة بك. كم مرة نقوم بإصلاح شيء ما وكسر شيء آخر؟

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

  • اكتب قائمة المراجعة من وجهة نظر المستخدم
  • ينمو القائمة مع ردود الفعل من كل التكرار
  • لديك مجموعة جديدة من العيون من خلال تشغيل القائمة
  • ساعد المطورين الآخرين في الفريق على التحقق من القائمة

ممارسة التعاطف

بغض النظر عن الموقف الذي أنت فيه. هناك القليل من التعاطف يقطع شوطًا طويلاً.

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

إنك تدرك أن أسماء مفاتيح البيانات المعينة قد تم تضمينها في كل مكان بواسطة مطور آخر في تطبيق ويب. قم بإخطار المطورين الآخرين بشكل استباقي قبل أن تسوء الأمور.

الصورة من قبل NESA بواسطة صناع على Unsplash

بإشعار جميع الفرق التي قد تتأثر بالتغيير ، يمكننا تقليل احتمال حدوث الفواق أثناء العرض التوضيحي المباشر أو حتى الإنتاج.

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

شكرا للقراءة

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