القائمة الرئيسية

الصفحات

21 مفتاحًا لبناء برامج أعمال أفضل




 أعرف ، 21 الكثير من المفاتيح. 

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

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

1. يجب أن يتبع البرنامج العملية وليس العكس بوضوح! هذه هي   الميزة الرئيسية للبرامج المخصصة أو المخصصة.      

2. بناء ما يصلح جرب دائمًا العمليات الجديدة يدويًا قبل تشغيلها تلقائيًا. لا تستخدم برامج باهظة الثمن (نسبيًا) لتأكيد أن العمليات التي تخيلتها لن تعمل في الواقع.      

3. المهارات ≥ المواهب مثير للجدل أدرك ، 

سأخوض في مزيد من التفاصيل حول هذا الموضوع ...      

حيثما أمكن ، استخدم فرق التطوير متعددة المهارات حيث يكون لدى العديد من الأفراد فهم كامل وليس هناك نقطة واحدة للفشل. من الناحية المثالية ، سيكون لدى كل مطور فهم معقول لما يلي:      

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

 الأفراد الموهوبون الذين يعملون في الصوامع لا يمكنهم تحقيق ذلك.      

4. المعقد سهل ، والبسيط هو الأصعب 

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

5. السماح بالوصول ، على جميع المستويات

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

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

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

على سبيل المثال ،  يقوم ممارسو DevOps الأعلى أداءً بإصدار كود أكثر من 200 مرة أكثر من ذوي الأداء المنخفض ، كما أنهم أسرع بمقدار 2600 مرة للتعافي من الحوادث .      

مثال آخر ،  توقعت IDC مؤخرًا أن الإنفاق العالمي على تكنولوجيا المعلومات سينخفض ​​بنسبة 2.7٪ في عام 2020 بسبب تأثير COVID-19 ، وقد يكون أكثر في صناعتك. الاستفادة من تقنيات Serverless يجلب فوائد مشتركة تتمثل في تقليل وقت التطوير بشكل كبير (ومن ثم التكلفة) وتكاليف الاستضافة المستمرة.      

7. التغيير أمر لا مفر منه ، احتضانه أنظمة البرمجيات ، مثل العمليات التجارية لا تكتمل أبدًا ، مع استثناءات قليلة جدًا يمكن (ويجب أن تكون كذلك) ، يتم تحسينها باستمرار.      

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


      

8. "عامل سيء ..." 🛠️

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

9. لا يمكنك التنبؤ بالمستقبل 🔮

 6 أشهر هي فترة طويلة في العمل ،

 أطول في التكنولوجيا وحتى أطول في البرمجيات. في البرمجيات ،  حقق Agile نجاحًا أكبر بنسبة 28٪ من الشلال .      

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

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

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

11. القليل من التخطيط يقطع شوطا طويلا 

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

12. 🤔 فكر في المشكلة وليس الحل 💭 



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

لا ينبغي لفريق التطوير الخاص بك فقط تقديم حلول للمشاكل التي حددتها بالفعل.     

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

13. ثم تخلص من المخاطرة في الحل

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

14. يمكن أن تكون عمليات نشر 

Big Bang مجرد 💥 إذا كان لديك الخيار (الذي يجب عليك دائمًا) ، فقم بطرح الأنظمة الجديدة بحذر.      

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

15. الاختبار صعب ، لكنه ضروري 📋 

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

لا ينبغي أن يكون هناك أي مفاجآت لأن فريقك كان يجب أن يتعاون ويتواصل طوال الوقت ولكن ستكون هناك دائمًا أخطاء ...      

16. سيكون هناك  دائما  البق 🐛 



إنها حقيقة ، تعامل معها. تم تقدير (من المسلم به منذ فترة) ، أن هناك ما بين 15 و 50 خطأً لكل 1000 سطر من التعليمات البرمجية ("اكتمل الرمز بواسطة Steve McConnell). ومع ذلك ، فقد ساعدت الممارسات الحديثة في تقليل هذا الرقم بشكل كبير. بعض الممارسات الحديثة أكثر فعالية من غيرها في هذا المجال ...      

17. ... الإصرار على الاختبارات الآلية 🤖

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

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

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

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

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

20. الأمن أساسي 🔒 لديك فرصة واحدة فقط في هذا.

 يبلغ متوسط ​​تكلفة خرق البيانات في المملكة المتحدة 3.1 مليون جنيه إسترليني (124 جنيهًا إسترلينيًا لكل سجل ضائع) وهو في ازدياد ، لذلك لا يمكنك تحمل الخطأ.     

 إذا كان فريقك لا يفهم أمان التطبيق تمامًا ، فابحث عن شريك يفعل ذلك.      

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



وأخيرا   

21. الاتصال والتواصل والاتصال 💬 

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

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

قم بتيسير الاتصالات المخصصة ، وقم بإعداد اجتماعات منتظمة ولا تدعها تفلت من أيدينا.      

باختصاركما ترى ، هناك الكثير مما يجب مراعاته.      

إن العثور على الفريق المناسب أو بنائه ، وهو فريق يمكنك الوثوق به ويثق بك أمر ضروري.

هل اعجبك الموضوع :

تعليقات