كيف يساعدنا عدم الراحة في تحسين عملية التطوير.

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

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

قليلا من السياق

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

الانزعاج كأداة تشخيص

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

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

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

كيف تتصرف في موقف مماثل:

1. وقف الذعر وأدرك لماذا نحن غير مرتاحين الآن.
2. وصول إلى أسفل السبب الجذري. على سبيل المثال ، باستخدام تقنية Five Why أو الحس السليم.
3. تقرر كيفية التعامل مع المشكلة. ستتم مناقشة إرشادات اختيار الحل الصحيح في نهاية المقالة. ألاحظ هنا نقطة مهمة بشكل أساسي: نستخدم عدم الراحة لتشخيص المشكلات ، لكن هذا لا يعني أن المبدأ التوجيهي لاختيار الحلول هو تحقيق الراحة. تذكر أن السبب الرئيسي لوجودك كفريق واحد هو قيمة العمل. لا أحد يحتاج إلى فريق سعيد لا يحقق نتائج.
4. بعد فترة من الوقت ، إجراء بأثر رجعي. إذا لم يساعد القرار ، نعود إلى الفقرة 1 بفهم جديد. إذا كان ذلك مفيدًا ، فنحن نقوم تلقائيًا أو نضيف إلى قائمة المبادئ للمبتدئين في المستقبل. لم تعد هناك حاجة إلى السيطرة ، فإن المشاركين أنفسهم سوف يتخذون نهج العمل إذا كان جيدًا حقًا.

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

المبادئ التي نبني عليها العملية

1. نحن باستمرار إنشاء وتقصير حلقات ردود الفعل

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

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

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

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

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

لذلك ، فإن وجود عدد كبير من حلقات التغذية الراجعة السريعة والمفيدة أمر حيوي.

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

• القدرة على تشغيل وتشغيل المشروع محليًا.
• مصممة لتفشل بسرعة .
• بناء CI سريع وغني بالمعلومات.
• مراجعة التعليمات البرمجية المستمرة والعمل مع التعليمات البرمجية من خلال طلبات السحب.
• توافر الاختبارات الذاتية. الاختبارات سريعة ومستقرة ورسائل خطأ بالمعلومات.
• النشر التلقائي ، لأنه سيتم تنفيذ دليل أقل تواترا.
• الإصدارات المتكررة بدلاً من تجميع إصدار وإصداره بعد أسبوع من إكمال المهام.
• سجلات بالمعلومات ، والرصد ، وأدوات التشخيص. الوصول إليهم من الفريق بأكمله.
• القدرة على تصفية وتصور الرسوم البيانية للسجلات.
• المراقبة المستمرة للمؤشرات الفنية والوظيفية للنظام كجزء من العمل اليومي.
• دراسة تجريبية للنظام - تحليلات جوجل ، تحليل البيانات المتراكمة في النظام.
• يؤدي تخزين بيانات السجل إلى تغيير السجل بدلاً من الحالة النهائية ، إن أمكن.
• ضيق ، العمل المشترك لـ Dev و Ops و QA والأعمال بدلاً من "إلقاء السور" من نتائج المرحلة السابقة.
• القيام بأثر رجعي منتظم سواء داخل الفريق أو مع الشركة.
• ردود فعل منتظمة من العمل. حتى الأفضل هو ردود الفعل من المستخدم النهائي.
• القدرة على مراقبة عمل المستخدمين "في الحقول".
• القدرة على مراقبة المستخدم الذي يرى نظامك لأول مرة.

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

ما هو جدير بالملاحظة ، في بعض الأحيان تغيير طفيف للغاية يكفي لتحسين جذري.

على سبيل المثال ، تكتب السجلات في ELK . وهي منظمة ومحللة ومتاحة للجمهور - كل شيء على ما يرام. ولكن كم مرة ينخفض ​​المطور أثناء تصحيح الأخطاء؟ على الأرجح لا.

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

2. أي نشاط يترك الآثار العامة

يجب أن تكون القطع الأثرية عامة تمامًا. ومفيد.

بفضل هذا المبدأ ، نقوم بتقليل عامل الحافلة إلى الحد الأدنى ، ونوفر فهماً موحداً للوضع ، والعمل (و fakapim) بوعي ، ونتوصل دائمًا إلى استنتاجات.

بعض الممارسات واضحة ومقبولة بشكل عام: رسائل إعلامية من عمليات ارتكاب ، واتصال من المهام ، ووصف كيفية اختبار ، وتعريف تم.

هناك نقاط أقل وضوحا:

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

3. نحن نحترم حق بعضنا البعض في العمل المركز

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

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

4. نتجنب تعدد المهام

لأن تعدد المهام لا يعمل . انها فقط يستنفد ، وينبذ الاهتمام وتأجيل تلقي النتيجة.

ما هي الممارسات المساعدة:

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

5. نتخذ القرارات المعمارية في أقرب وقت ممكن

هذه ليست معرفتنا ، ولكن واحدة من المبادئ الأساسية لتصنيع العجاف .

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

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

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

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

6. رمز التشغيل في أي وقت معين.

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

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

توفر الثقة الناتجة في تشغيل النظام فرصة ثمينة للنشر في أي وقت.

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

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

كيف نحافظ على الأداء المستمر:

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

7. نحن فريق وليس مجموعة تطوير.

ماذا يعني "الفريق":

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

8. نحن ختم ذيول

من أجل تعظيم كفاءة وتركيز العمل الحالي ، نقوم بإلغاء "الديون" المرتبطة بالعمل الذي تم بالفعل:

• يتم إحضار المهام إلى المبيعات في أسرع وقت ممكن. فقط بعد ذلك نعتبرهم يقومون به.
• إننا نعمل باستمرار على التخلص من الديون الفنية بحيث لا تنمو وفقًا للتكلفة العالية للإصلاح (أسبوعًا) ولا تمنع العمل ، مما يفسد خطط تقديم وظائف العمل.
• نحن لا نبدأ المهام التي سنفعلها "يومًا ما" ، لكننا نحذف المهام الطويلة. سيأتي العمل بالتأكيد لمهمة عندما يأتي (إذا) وقت القيام بذلك حقًا. وفقط في حالة ، في تعقب المهام ، يمكنك استعادة المهمة المحذوفة. لكن هذه الوظيفة لم تكن مفيدة لنا.
• فروع طويلة العمر ، رمز معلق ، To-do-shki - كل هذا رمز ميت ، وموضعه في السلة.
• اختبارات غير مستقرة يتم إصلاحها على الفور أو حذفها واستبدالها بأخرى أقل.
• نحن تتبع المهام "الزاحف".

النقطة الأخيرة تستحق شرح منفصل.

أعني المهام "الزاحفة" بتكاليف العمالة الصغيرة في البداية ، ولكن الانتظار قيد التنفيذ لعدة أيام أو أسابيع.

لماذا يمكن أن يكون هذا:

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

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

يساعد الرسم البياني لدورة الوقت في البحث عن مثل هذه المهام. إنه يظهر الوقت من لحظة الاستيلاء على العمل حتى الانتهاء. إذا كانت المهمة "خارج الحشد" ، فهذا مرشح للامتحان الدقيق.

كيفية اختيار الحلول المفيدة

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

ولكن لا يزال هناك بعض المرجعية. ومن هنا:

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

استنتاج

في الختام ، دعونا نناقش نقاط الضعف في النهج.

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

أسألك أيضًا ، لا تأخذ قائمة مبادئ جاهزة ، استخدم الأداة التي تم إنشاؤها بها. إليك السبب:

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

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