أهم شيء هو أن المبرمجين لا يفهمون كيفية التواصل مع العميل ومع بعضهم البعض. كيفية بناء عملية تطوير منتجات ذات جودة مستمرة. كيف تخطط ليوم عملك والسباقات.
وكل هذا يترجم في النهاية إلى مواعيد نهائية متقطعة ، ووقت إضافي ، ومواجهة مستمرة حول من يقع اللوم ، وعدم رضا العملاء - أين وكيف يتحرك كل شيء. في كثير من الأحيان ، كل هذا يؤدي إلى تغيير في المبرمجين ، أو حتى فرق كاملة. فقدان العميل وتدهور السمعة وما إلى ذلك.
في وقت من الأوقات ، بدأت للتو في مشروع كهذا ، حيث كانت كل هذه التعويذات.
لم يرغب أحد في تحمل المسؤولية عن المشروع (سوق خدمات كبير) ، كان معدل الدوران رهيبًا ، لقد مزق العميل وسحق. جاءني الرئيس التنفيذي ذات مرة وقال إن لديك الخبرة اللازمة ، لذا فهذه البطاقات بين يديك. خذ المشروع بنفسك. أنت تفشل ، سنغلق المشروع ونطرد الجميع. سيظهر ، سيكون رائعًا ، ثم يقودها ويطورها كما تراه مناسبًا. ونتيجة لذلك ، أصبحت قائد فريق في المشروع وسقط كل شيء على كتفي.
كان أول شيء فعلته هو تصميم سير عمل من الصفر يطابق رؤيتي في ذلك الوقت وكتب وصفًا وظيفيًا للفريق. لم يكن من السهل تنفيذها. ولكن في مكان ما خلال شهر ، استقر كل شيء ، واعتاد المطورون والعميل على ذلك ، وسار كل شيء بهدوء وراحة. لكي أظهر للفريق أن هذه ليست مجرد "عاصفة في كوب" ، ولكنها طريقة حقيقية للخروج من الموقف ، تحملت أكبر قدر من المسؤوليات ، وأزيلت الروتين غير السار من الفريق.
لقد مر عام ونصف بالفعل ، والمشروع يتطور بدون ساعات عمل إضافية ، وبدون "سباقات الفئران" وجميع أنواع الإجهاد. شخص ما في الفريق القديم لم يرغب في العمل بهذا الشكل وغادر ، على العكس من ذلك ، كان شخص ما حريصًا جدًا على ظهور قواعد شفافة. ولكن نتيجة لذلك ، فإن كل من هو في الفريق متحمس للغاية ويعرف المشروع الضخم بالكامل ، مع كل من الواجهة الأمامية والخلفية. بما في ذلك كل من التعليمات البرمجية ومنطق الأعمال. لقد وصل الأمر إلى حد أننا لسنا مجرد "مجدفين" ، لكننا نحن أنفسنا نبتكر العديد من العمليات التجارية والميزات الجديدة التي وجدتها الشركة ترضيها.
بفضل هذا النهج من جانبنا ، قرر العميل طلب سوق آخر من شركتنا ، وهو خبر سار.
نظرًا لأنه يعمل في مشروعي ، فقد يساعد أيضًا شخصًا ما. إذن ، العملية نفسها التي ساعدتنا في إنقاذ المشروع:
عملية العمل الجماعي في المشروع "مشروعي المفضل"
أ) عملية فريق داخلي (بين المطورين)
- يتم إنشاء جميع المهام في نظام Jira
- يجب وصف كل مهمة قدر الإمكان ، وتنفيذ إجراء واحد بدقة
- أي ميزة ، إذا كانت معقدة بدرجة كافية ، يتم تقسيمها إلى العديد من المقايضات الصغيرة
- يعمل الفريق على ميزات مثل مهمة واحدة. أولاً ، نقوم جميعًا بميزة واحدة معًا ، ونرسلها للاختبار ، ثم نأخذ الميزة التالية.
- يتم تمييز كل مهمة للواجهة الخلفية أو للواجهة الأمامية
- هناك أنواع من المقايضات والأخطاء. تحتاج إلى الإشارة إليهم بشكل صحيح.
- بعد الانتهاء من المهمة ، يتم نقلها إلى حالة مراجعة الكود (وهذا يؤدي إلى إنشاء طلب سحب لزميلك)
- كل من أكمل المهمة يتتبع على الفور وقته لهذه المهمة.
- , , , , , .
- , , ( ), , - . —
- ,
- ,
- , , . ,
- : To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- , . , , .
- . , .
- .
- , .
- , , , , .
- , , , , . ( ) . , /.
- ( 12.00)
- , , , . . , . , , .
- , . .
- , , , , .
- . .
- . , , . . , , , .
- , . . .
- , , . .
- كل يوم ، يجب على المطور أن يكتب في محادثة العميل حول المهام التي عمل عليها بالأمس والمهام التي سيعمل عليها اليوم
- يعتمد سير العمل على سكرم. كل شيء مقسم إلى سباقات السرعة. كل عدو يستمر أسبوعين.
- سباقات السرعة تنشئ وتعبئ وتغلق قائد الفريق.
- إذا كان للمشروع مواعيد نهائية صارمة ، فإننا نحاول تقدير جميع المهام تقريبًا. ونقوم بجمع العدو السريع منهم. إذا حاول العميل إضافة المزيد من المهام إلى السباق ، فإننا نحدد الأولويات ، وننقل بعض المهام الأخرى إلى السباق التالي.
ب) عملية العمل مع العميل
- يمكن لكل مطور ويجب عليه التواصل مع العميل
- لا ينبغي السماح للعميل بفرض قواعد اللعبة الخاصة به. من الضروري بطريقة مهذبة وودودة أن نوضح للعميل أننا متخصصون في مجالنا ، ويجب علينا فقط بناء إجراءات العمل وإشراك العميل فيها
- , , - , - (). . , , , .. , , , , , , .
- /-/ .. /, .
- . , , -, /.
- , . , , . .
- , . . , .
- , , . , . , . , . .
- , , . , . , .
- إذا بدأ العميل في الخروج بمهام مختلفة من رأسه ، وبدأ في التخيل والشرح على الأصابع ، فإننا نطلب منه تزويدنا بتخطيط الصفحة وتدفق المنطق الذي يجب أن يصف بشكل كامل سلوك التخطيط بأكمله وعناصره.
- قبل أن نتولى أي مهمة ، يجب أن نتأكد من تضمين هذه الميزة في شروط الاتفاقية / العقد. إذا كانت هذه ميزة جديدة تتجاوز اتفاقياتنا الأولية ، فيجب علينا بالتأكيد تقييم هذه الميزة ((المهلة المقدرة + 30٪) × 2) وإبلاغ العميل بأن الأمر سيستغرق الكثير من الوقت لنا ، بالإضافة إلى تغيير الموعد النهائي بمقدار ضعف التقدير. لنجعل المهمة أسرع - عظيم ، سيستفيد الجميع من ذلك. إذا لم يكن كذلك ، فنحن مؤمنون.
ج) ما لا نقبله في الفريق:
- الاختيارية ، عدم التجمع ، النسيان
- „ “. , , , .
- , . , , :)
- . , , . , , — . -, .
- .
- ! - - , .
وعدد من الأسئلة / الأطروحات الأخرى التي أطلبها أحيانًا من عملائي لإزالة كل سوء الفهم:
- ما هي معايير الجودة الخاصة بك؟
- كيف تحدد ما إذا كان المشروع به مشكلة أم لا؟
- انتهاك جميع توصياتنا ونصائحنا بشأن تغيير / تحسين النظام ، تتحمل أنت وحدك جميع المخاطر
- ستؤدي أي تغييرات كبيرة في المشروع (على سبيل المثال ، جميع أنواع التدفقات الإضافية) إلى ظهور محتمل للأخطاء (التي سنقوم بإصلاحها بالطبع)
- من المستحيل لمدة دقيقتين فهم نوع المشكلة التي حدثت في المشروع ، والأكثر من ذلك حلها على الفور
- نحن نعمل على منتج تدفق معين (مهام في الدهون - تطوير - اختبار - نشر). هذا يعني أنه لا يمكننا الرد على مجموعة الطلبات والشكاوى بالكامل في الدردشة
- المبرمجون هم مجرد مبرمجين ، وليسوا مختبرين محترفين ، ولا يمكنهم ضمان الجودة المناسبة لاختبار المشروع
- , , ( )
- ( ), ,
- — ,
- , , , ,
- , , , ,
- .
- , ( ),
كقاعدة عامة ، يدرك العميل على الفور أن كل شيء ليس بهذه البساطة في تطوير البرامج ، ومن الواضح أن الرغبة وحدها ليست كافية.
بشكل عام ، هذا كل شيء. تركت وراء الكواليس الكثير من المفاوضات والتصحيح الأولي لجميع العمليات ، ولكن نتيجة لذلك نجح كل شيء. أستطيع أن أقول إن هذه العملية أصبحت نوعًا من "الرصاصة الفضية" بالنسبة لنا. يمكن للأشخاص الجدد الذين أتوا إلى المشروع أن يعتادوا على العمل فورًا من اليوم الأول ، حيث تم وصف جميع العمليات ، والتوثيق والهندسة المعمارية في شكل مخططات على الفور أعطت فكرة عما كنا نفعله جميعًا هنا.
ملاحظة: أود أن أوضح أنه لا يوجد مدير مشروع من جانبنا. إنه في جانب العميل. ليس فني على الإطلاق. المشروع أوروبي. جميع الاتصالات باللغة الإنجليزية فقط.
حظا سعيدا للجميع في المشاريع. لا تحترق وتحاول تحسين عملياتك.
المصدر على مدونتي .