في صحراء المواهب المؤهلة ، هناك حاجة إلى مطوري المياه مثل الماء ، حتى لو تم حملهم على يديهم أو إهانتهم ، لكن هذه حقيقة. بدونهم ، لن يكون هناك صناعة ، وهم أنفسهم يدركون ذلك جيدًا. وهذا يؤدي إلى هذا الإحساس المثير لحق الذات ، والذي نادراً ما ينظر إليه في تاريخ البشرية. نتيجة لذلك ، وُلِد طيف كامل من شخصيات المشكلة المشرقة للغاية.
يمكن للمطور الجيد أن يساوي وزنه بالذهب -
حرفيًا . في عدد قليل من المهن ، وهذا الدخل ممكن. اعتاد بعض من أغنى الناس على هذا الكوكب أن يكونوا مبرمجين ، لذا فإن كونك مطورًا في الوقت المناسب في المكان المناسب يعد أحد أسهل الطرق وأكثرها مباشرة للثروة الكبيرة.
ولكن مع مثل هذه الفرص غالبًا ما تأتي الافتقار التام إلى احترام المشاركين في المشروع في المهن الأخرى. قد يتحول هذا الافتقار إلى الاحترام إلى عمق كبير لدرجة أنه يثير اعتقادًا راسخًا في ذهن المطور بأنه ليس فقط أكثر المشاركين قيمة في مشروع البرنامج ، ولكنه ضروري أيضًا للشركة ككل. لسوء الحظ ، على الرغم من أن عددًا صغيرًا فقط من المطورين قادرين على تجميع أي شيء يشبه الثروة ، يتصرف الكثيرون كما لو كانوا يتبعون مارك زوكربيرج أو بيل جيتس أو ستيف جوبز ؛ على الرغم من أنها بعيدة جدا عن الحقيقة. هذا يؤدي إلى مشاكل في الشخصية ، والتي هي مثيرة للمشاهدة بنفس القدر كما هو مخيف للتفكير في نفسك.
فيما يلي
الهويات الإشكالية بين مطوري البرامج:
بريما دونا
المطور على قناعة تامة بأنه لا غنى عنه بحيث يصبح متعجرفًا ومستحيل القيادة.
المشكلة
في مستوى معين ، لإدارة الموظف ، يجب عليه أن يفعل ما تقوله. لا يمكن التحكم في براما دونا ، لأنها بطبيعتها لا تعتقد أنها تعمل من أجلك. في رأيه ، إنه لشرف لك العمل معه. إنه يعتبر نفسه لا غنى عنه تماما وهو محق في أي نقاش.
على عكس قناعتها الخاصة ، فإن بريما دونا ليست بالضرورة مطورة مؤهلة (انظر
نوع نجم الروك ). يعتمد غطرسته على تقديم مكانه في المنظمة ، وليس على المهارات الفنية الفعلية. نتيجة لذلك ، غالبًا ما تُصنَّف براما دونس مستوى مهارتها أعلى بكثير من نظرائها ،
على الرغم من أن هذا ليس هو الحال في الواقع . هذا عادة ما يؤدي إلى حقيقة أن بريما دونا عادة لا يحبها الزملاء.
يمكنك تحديد بريما دونا بالعبارات النموذجية:
- "هذا غبي - لن أفعل ذلك بهذه الطريقة"
- "علينا أن نفعل ذلك مثل هذا."
- "إذا كنت لا تحب ذلك ، يمكنك التحدث إلى مديري"
- "حسنا ، سوف نرى".
- "سوف أتحدث إلى رئيسك في العمل ونرى ما يقوله"
بريما دونا لا تقبل القيادة. إنه يرى أي محاولة للقيادة بمثابة إهانة ، لأنه أعلى من المساءلة عن أفعاله. تم العثور على هذه المشكلة الشخصية عادة بين المطورين منذ فترة طويلة الذين يشاركون بعمق في النجاح المبكر للشركات. الآن ، بعد سنوات ، وبفضل سنوات عديدة من العلاقات مع مؤسسي الشركة ، يعتبر رأيه أعلى من رأي مدير بسيط من المستوى المتوسط.
لا تشكل البدائية خطرًا جوهريًا على المشروع ، لأنه عادة لا يفعل شيئًا ، ولكنه يهز القانون فقط. ومع ذلك ، فإنه يؤثر سلبًا على معنويات الفريق ، وخاصة المطورين الجدد الأكثر إنتاجية. لذلك ، يجب وضعه في مكانه بحيث يعمل المشروع بسلاسة.
الحل
حل المغنية هو دحض الاعتقاد الأساسي:
أنه لا يمكن الاستغناء عنه ، وبالتالي يمكنه أن يفعل ما يريد . الطريقة الأكثر مباشرة لدحض هذا الاعتقاد هي توظيف بديل للعمل معه عن قرب. لكي ينقل إلى الوهلة الأولى بشكل كافٍ أن هذا هو بديله بالفعل ، يجب استيفاء شرطين:
- يجب أن يكون الاستبدال أكثر تأهيلًا.
- من الضروري أن نوضح لبريما دونا أن بديله ليس لديه وظيفة أخرى سوى متابعة ظل البدانة دونيا ومعرفة كيفية استبدالها.
كلما كان الاستبدال أسرع في جمع كل المعرفة حول الكود القديم الذي يمكن أن تمتلكه بريما دونا (راجع أنواع المطورين
، حارس الكود القديم وراعي الرهائن ) ،
كلما عادت براما دونا إلى السيطرة عليها بشكل أسرع. قد يكون التأثير دراماتيكيًا: كل شيء يمكن أن يتغير في غضون أيام قليلة. في النموذج ، تبدأ المغنية في أداء وظيفة إضافية لاستبدالها. في النهاية ، لم يعد لا غنى عنه ، وبالتالي لم يعد مغنيًا ، ولكن ببساطة موظف فقير.
الأمل الوحيد لبريما دونا هو الحفاظ على الإحساس بالوضع - للحصول على ترقية إلى منصب إداري (راجع مطورًا مثل
مديري العلامات ). كلما كان ذكاءه أفضل ، كلما كان بديلاً سيحاول القيام بذلك. ومع ذلك ، لا يُنصح بالزيادة ، لأنك من المحتمل أن ترى إقالة المطورين الذين تكون المغنية مسؤولة عنهم. لذلك ، عند رفض طلب الترقية ، فلديه خياران فقط: الوقوف على قدم المساواة مع المطورين الآخرين أو المغادرة. في أي حال ، يتم حل مشكلتك.
المثالي
المطور مهووس للغاية بتحقيق الأناقة المعمارية وتميز الكود بحيث ينسى أن عمله يجب أن يستفيد منه.
المشكلة
تتطلب مهنة مهندس البرمجيات توازنًا ثابتًا بين مهمتين متعارضتين:
- الرغبة في الاستفادة من الأعمال (والحصول على أموال).
- الرغبة في كتابة برامج ممتازة (وكن فخوراً).
تجاهل المثالي تمامًا هدف الاستفادة من الأعمال ، وبدلاً من ذلك ركز فقط على كتابة برامج رائعة.
المطور المثالي هو عادة ذكي للغاية وذوي الخبرة والمهنية. إنه يعرف حقًا ما الذي يتحدث عنه. إنه يعرف حقًا كيفية كتابة برامج رائعة ، وإذا تم إعطائه وقتًا كافيًا ، فيمكنه إنشاء نظام مثالي. المشكلة هي
أنه يعتقد أن لديه طوال الوقت في العالم وحرية كاملة ، على الرغم من أن هذا أبعد ما يكون عن القضية.
بدلاً من المساومة ، ركز على إنشاء نظام مثالي. وهو يعتقد أن هذا أفضل للأعمال. لا تخلط بينهم وبين العلماء الذين يصنعون شيئًا "مطلقًا" أو "رائعًا": يعتقد المثاليون بصدق أن نظامهم المثالي هو الأنسب لتطوير الشركة. بسبب صمود هذا الإيمان يصعب تصحيحه.
يعتبر المثاليون خطرين بشكل خاص على المشروع ، لأنهم عادة ما يتمتعون بالقدرة على تطوير مطورين رئيسيين آخرين ، لأنهم يمثلون المثالية التي يسعى إليها المطورون ، لذلك يسهل عليهم توصيل المبرمجين الآخرين إلى جانبهم ، لأن جميع المطورين يريدون أن يفخروا بالبرنامج الذي يكتبونه. وبالتالي ،
فإنهم يأخذون فريق التطوير بأكمله رهينة ، وأنت الآن في وسعهم. إذا كنت محظوظًا ، فسوف يبدأون في تقديم قيمة إلى العمل ، لكن سيكون ذلك مجرد تأثير جانبي عشوائي في سعيهم لإنشاء برامج رائعة. في الواقع ، لن تظهر الفوائد التي تعود على النشاط التجاري إلا في نهاية العمل ، لكن لا يمكنها إخبارك بالإطار الزمني أو تقييم هذه الميزة. في الحقيقة ، إنهم ليسوا مهتمين حتى بالاكتمال ، لأن العملية في حد ذاتها ، وليس الهدف ، هي التي ترضيهم.
الحل
نلخص السمات المثالية:
- ذكي جدا وذوي الخبرة والمهنية.
- يعتقد مع خالص التقدير أن نظامه أفضل لمستقبل الشركة.
من نواح كثيرة ، إنه موظف جيد جدًا ، وإذا نظرت إلى أكثر الشركات ابتكارًا على وجه الأرض ، فإن لديهم الكثير من المثاليين في أقسام البحث والتطوير. ومع ذلك ، فإن أفضل الشركات لديها ثلاثة أشياء لا تملكها البقية:
- يتمتع موظفو الإدارة بالكفاءات المثالية ، ويقدمون الشيكات والأرصدة لاتخاذ القرارات الفنية.
- توقع فشل عدد معين من المشاريع ، وهي التكلفة المعتادة لممارسة الأعمال.
- ميزانية كبيرة لمواصلة تمويل المشاريع غير المربحة.
إذا كان لدى شركتك هذه الأشياء الثلاثة ، فاترك المثالي بمفرده ، فدعه يفعل ما يريد. ولكن إذا لم تكن لديك ، مثل معظم الشركات ، هذه الظروف الفاخرة ، فستظهر مشكلة حقيقية ، حيث إن كل ما تفعله تقريبًا سيؤدي إلى كارثة:
- إذا قمت بطرده على الفور ، يمكن للمطورين المخلصين متابعته قريبًا.
- إذا وضعت قواعد صارمة ، فيجوز له أن ينفصل عقليًا عن المشروع ، مما يتركك دون توجيه فني.
- إذا تركته وشأنه ، فسوف تتعب السلطات في النهاية من عدم إحراز تقدم ملموس.
لإجبار المثالي على تغيير السلوك ، تحتاج إلى العثور على شخص يمكنه إقناعه. يجب أن يثبت هذا الشخص للمثالي أنه قادر أيضًا على إنشاء نظام ممتاز. هذا أمر مهم ، حيث سيتم ببساطة تجاهل الشخص الذي لا يتمتع بالكفاءة الفنية لأنه غير قادر على فهم عبقرية التصميم المثالي.
إذا تم العثور على شخص لديه مثل هذه الثقة ، فسيتعين عليه أن يستنتج المثالي ببطء وبصورة منهجية من طريقة تفكيره المثالية. وهذا يتطلب أن يكون الشخص المحترف ذو الخبرة العالية والذكي مستعدًا للقيام بما يعتقد أنه على صواب. فرص هذا قليلة ، وبالتالي ، هناك فرصة ضئيلة لتصحيح المثالي.
نجم الروك
المطور موهوب جدًا ومنتج ومهم جدًا لدرجة أنه في حالة مغادرته ، سينهار المشروع بالكامل.
المشكلة
في صناعة البرمجيات ، غالبًا ما يستخدم مصطلح "نجم الروك" من قِبل شركات التوظيف التي تحاول جذب المطورين من خلال تضخيم الأنا ، أي أننا نبحث عن العديد من مطوري نجوم الروك. من الصعب العثور على نجوم روك حقيقيين ، لأنهم مبرمجون مثاليون:
- لا توجد مشكلة أنهم لا يستطيعون حلها (وبسرعة).
- انهم يعملون طوال الليل للقبول بالموعد النهائي.
- لا يوجد عمليا أي أخطاء في التعليمات البرمجية الخاصة بهم أو يتم إصلاح أي أخطاء بسرعة.
- يأخذون على أصعب أجزاء المشروع.
- هم عادة مولعا جدا من الزملاء.
لسوء الحظ ، بمجرد تعيينهم ، يصبحون لا غنى عنهم في المشروع.
يبدو نجم الروك وكأنه ثقب أسود: يتراكم العمل حولهم وفي النهاية يتم امتصاصه في النهاية. قد يصل الأمر إلى درجة أنهم يسلبون العمل من المطورين الأبطأ للوفاء بالمواعيد النهائية - مما يريح الجميع. إذا وجد المشروع نفسه في مأزق ، فسوف ينقذ الموقف. إذا حدث شيء مثير وغير متوقع ، فسوف يعرفون ماذا يفعلون. إنها رائعة حقًا - وكل مجند يعرف ذلك.
سيتصل المجندون بنجمة موسيقى الروك عدة مرات كل يوم. سمعتها أمامهم. ترغب الشركات دائمًا في جذب نجوم الروك لأنهم يفهمون قيمتها ، وفي كثير من الحالات سيفعلون كل شيء تقريبًا للحصول عليها. لذلك ، فإن الموقف هو أن هناك شخصًا لا غنى عنه لمشروعك ، والذي تريد كل شركة ثانية إغرائه. إذا فعلوا ذلك ، فسوف يفشل المشروع. الحالة الكلاسيكية هي عندما يتم وضع الكثير من البيض في سلة واحدة.
الحل
لا يوجد "حل" لنجم موسيقى الروك. في النهاية ، فإن أحمق فقط هو الذي سيرغب في "إصلاحه" ، لأنه أكثر مطورك إنتاجية حتى الآن. كل ما يمكنك فعله هو التخفيف من الضرر عن طريق إنشاء فريق من حوله قادر على العمل بفعالية إذا غادر. على الأرجح ، ستحتاج إلى عدة مطورين ليحلوا محل أداء نجم روك واحد ، ولكن على الأقل يمكنك البقاء على قيد الحياة عند مغادرته.
للتحقق من مدى سوء وضعك ، انتبه جيدًا إلى إنتاجية المطورين عندما يذهب نجم الروك في إجازة. إذا توقفت جميع عمليات التطوير خلال غيابها الأسبوعي ، فأنت بحاجة إلى مضاعفة الجهود للوصول بالمطورين الآخرين إلى المستوى الذي يمكنهم من خلاله الحفاظ على تطوير المشروع في غياب نجم روك.
قد يكون هذا صعبًا إذا اعتاد المطورون على تعامله مع المشكلات المعقدة ، يصبحون كسالى ومتعججين. هناك فرصة أنه مع المغادرة المفاجئة لنجم موسيقى الروك ، سيتخذ مطورو البرامج الآخرون إجراءات. لكن ، على الأرجح ، يحبونه كثيرًا لدرجة أنهم سوف يتبعونه إلى شركة جديدة.
بمناسبة في المديرين
مطور قرر تجنب صعوبات البرمجة ويصبح أحد المديرين.
المشكلة
البرمجة صعبة التعلم. يتطلب القدرة على حل المشاكل بسرعة ، وكمية كبيرة من المعرفة وحتى تجربة أكثر واقعية. على عكس المجالات المهنية المماثلة ، تصبح هذه المعرفة والخبرة قديمة بشكل أسرع (أحيانًا خلال أشهر) ، مما يتطلب التطوير المستمر لأساليب وتقنيات وأدوات جديدة.
يريد رمي المديرين
التخلص من هذه الضجة ، ويرى مخرجًا في الإدارة .
كقاعدة عامة ، بالنسبة لمديري التطوير ، تكون متطلبات مهارات البرمجة أقل من متطلبات المطورين. يقضي الوقت في الاجتماعات ، وإرسال رسائل البريد الإلكتروني ، أو حتى المشي والدردشة مع أشخاص آخرين. يميل المديرون أيضًا إلى كسب أكثر من المبرمجين ، ولكن مع الوضع ، تأتي الصلاحيات. هذا اختيار واضح للمطورين الذين يريدون التخلص من كتابة البرامج.
المشكلة مع المطور ، الذي بدأ التفكير في مهنة المدير ، هو أنه يسعى لإظهار مهاراته الإدارية على أمل التحسين ،
بدلاً من التفكير في البرمجة . لممارسة المهارات الإدارية ، يحاول مدير المستقبل توجيه زملائه للمطورين: يعين العمل ، ويتحدث في الاجتماعات ، وكقاعدة عامة ، يسعى إلى المشاركة في اتخاذ المزيد من القرارات الإستراتيجية. لذلك ، فإن زملائهم في مجال التطوير والمديرين الآخرين الذين يرون تهديدًا لعملهم ليسوا مولعين بنفس القدر.
الحل
من المستحيل حل مشكلة مدير المستقبل ، لأنه اختار بالفعل اختيارًا وظيفيًا واضحًا. بمجرد اتخاذ القرار ، لا يوجد العودة إلى الوراء. لا يمكنك إجباره على كتابة البرامج مرة أخرى. حتى لو أجبرت ، ستجد قريبًا سبب بدء التفكير في مهنة المدير: الرجل ليس جيدًا في البرمجة. نظرًا لتعقيد هذا الموقف ، يحصل الكثير من المبرمجين والمديرين على ما يريدون: الترقية إلى منصب المدير ، إذا كان هناك شاغر.
كقاعدة عامة ، المطورين في هذا الموقف ليسوا ضارين بشكل خاص للمشروع ، لأن إنتاجيتهم منخفضة للغاية ، وعادة ما لا يتمتعون بثقة خاصة من المطورين أو المديرين. غالبًا ما يتجول هؤلاء الأشخاص طوال حياتهم المهنية حول المؤسسة ،
وتكافح الإدارة العليا للعثور على طلباتهم . على هذا النحو ، يمكن أن تصبح خطرة إذا تم تكليفها بمهمة حرجة ، ولكن بما أنه يمكن تجنب ذلك تمامًا ، فيمكن أن تظل بأمان مجرد عامل مزعج صغير.
محتجز الرهائن
مطور قام بكتابة جزء من برنامج حاسم ولا يسمح لأي شخص بالعمل عليه من أجل الحفاظ على قابلية الاستغناء عنه.
المشكلة
من المهم لأي شخص لديه التزامات مالية ضمان سلامة مكان العمل والراتب. بالإضافة إلى ذلك ، يعد العمل باستخدام التعليمات البرمجية المألوفة أسهل بكثير من العمل باستخدام التعليمات البرمجية غير المألوفة. من بين هذين الشهرين ، ولد محتجز رهائن - وهو مطور
كتب وحاز يمتلك قطعة حاسمة من البرامج ، يرفض العمل على أي شيء آخر .
كقاعدة عامة ، هذا مهندس برمجي سيئ ، والذي من المفارقات أن يصبح ميزة مهمة:
عادةً ما لا يكون رمزه مفهومًا لأي شخص آخر ، لذلك يخشى المطورون الآخرون الدخول في مثل هذا المستنقع ، خوفًا من إلحاق ضرر أكبر مما ينفع. لذلك ، يتم نقل جميع الأعمال الجديدة على نظام حرج إلى الغازي ، وبالتالي مواصلة الحلقة المفرغة.
يأخذ محتجز الرهائن عادة موقفًا دفاعيًا ومواجهًا ، فهو مقفل تمامًا بالنقد أو التعاون فيما يتعلق بقاعدة الشفرات الخاصة به. إذا دفعته حقًا إلى الزاوية ، سيهدد بمغادرة المكان ، وبما أنه لا أحد يريد أن يأخذ منتجًا خطيًا ومصمم بشكل سيئ ، فنادراً ما يعاقب مثل هذا الخداع. يمكن أن يصبحوا عنق الزجاجة في المشروع ، لأن مصير المشروع بأكمله يعتمد على رغبتهم وقدرتهم على إصدار رمز.
الحل
بصرف النظر عن مدى خطورة الأمر ، فإن الحل بسيط: إسناد اثنين أو أكثر من مطوري البرامج المسؤولية عن جزء من نظام الغازي ، ونقله إلى جزء آخر. , , .
, .
المشكلة
. « » , . , .
. , , , (.
) . , , , . , , .
- . — , . « », , , - .
الحل
, :
- , . .
- , .
- . . , , .
- , . , .
- , , .
, . , . , , .
, .
المشكلة
, . , , . - .
, :
- .
- « » , .
- (. ), .
- , .
- .
- .
- , .
- (. ), « ».
. , .
الحل
, . , , . , .
, . , , — , .
, , . :
- , (. )
- , .
, ,
. , . ( ), .
, , .
المشكلة
, . , . , - , .
: . / , -. , , , , . , ; , , .
. , , . , - .
الحل
, , :
- , .
- , .
- , .
- , — .
- «TODO» , . .
- : , .
, , , .
, :
, , , . , , , .
, , .
المشكلة
, , . , . , , .
. , , , -, . :
. , .
الحل
, . — , . , , :
- , .
- , .
- . , .
, . , .
, , , , , .
المشكلة
, , , ? , , . , . , :
, , .
:
- . : , . , , .
:
- , : . , , .
- , , , .
- , , , .
- , , , - .
- , , .
- , — , .
- , — , , .
- , .
, , .
الحل
, . — . , , . , , . .
, , . , . , . , , «», .
, , , . , , . , . .
, . , .
, , , .
المشكلة
. -, . .
- : , . , , -.
. , . , , . , , .
الحل
سيتم إصلاح مراوح التكنولوجيا إذا قامت الشركة بتثبيت حزمة تقنية قياسية. ثم تحتاج فقط للتأكد من أن المطورين لا يحيدون عن ذلك. إذا لم يكن لديك حزمة تقنية مثبتة ، يوصى بشدة بتعريفها مقدمًا ، حيث سيكون من غير المناسب إدخالها بعد بدء تشغيل مروحة التكنولوجيا.
من المحتمل أن تؤذي الأخبار التي تفيد بعدم إمكانية استخدام التكنولوجيا الجديدة الخاصة بك معنويات محبي التكنولوجيا ، ولكن يمكن استعادة هذه الروح المعنوية بسرعة من خلال مطالبه بتقديم عرض تقديمي حول هذه التقنية الجديدة. هذا قرار صحي للغاية ، لأنه بعد العرض التقديمي ، يمكن للفريق أن يناقش معًا ما إذا كان من المنطقي توسيع رزمة تقنيات الشركات. سيكون معظم عشاق التكنولوجيا راضين عن هذه التجربة ، حتى لو لم يعجبهم القرار النهائي.
Legacy Keeper
مطور له القدرة الوحيدة على الحفاظ على البرامج القديمة ، وبالتالي فهو غير قادر على تولي وظيفة جديدة.
المشكلة
عندما يأتي مطور جديد للشركة ، فإنه عادة ما يكون مليئًا بالنار والعاطفة ، ويحاول إثبات نفسه بكل طريقة ممكنة. ولكن بمرور الوقت ، يأخذ مكان العاطفة الرضا عن النفس: يعتقد المطور أن الخبرة في الشركة تمنحه بعض الامتيازات. لنفسه ، فهو يعترف بالالتزام بالحفاظ على أنظمته ، ولكن ليس للقيام بتطوير أجزاء جديدة.
ترتبط مشكلة أمين الحفظ القديم بالتدريج: فهي ببساطة ليست مدرجة في مجموعة الموارد المتاحة للعمل الجديد. في هذه المرحلة ، يطرح السؤال ما إذا كان بإمكانك الاحتفاظ بها في فريق عمل ، أي ما إذا كان يمكن للمطورين الآخرين الاضطلاع بمهمتهم المتمثلة في خدمة التعليمات البرمجية القديمة. عادة ما يكون من الصعب إقناع المطورين الآخرين بالقيام بذلك لسببين:
- عادةً ما يتم كتابة التعليمات البرمجية القديمة ويصعب التعامل معها.
- الدعم هو طريق وظيفي مسدود لأنك لا تفعل شيئًا جديدًا أو مبتكرًا ، وقد يتم تمييزك به.
هذا هو السبب في أن المشرفين القدامى كانوا مع الشركة لفترة طويلة. غالبًا ما كانوا مع الشركة منذ إنشائها وهم مؤلفو البرنامج الذي بنيت عليه الشركة. ومع ذلك ، مع نمو الشركة ، لم يتقدموا في الخدمة أو لم يحاولوا إتقان مهارات جديدة أو أجزاء جديدة من النظام ، وكنتيجة لذلك تم ربطهم بشدة بالكود الوحيد الذي عرفوه.
الحل
لا يخلق حارس الكود القديم مشاكل إذا فهمت أنها ليست من بين الموارد للعمل في مشاريع جديدة. في أفضل الأحوال ، يمكنك أن تطلب منه إصلاح الأخطاء وتنفيذ تحسينات ميزة صغيرة. تنشأ المشكلة الوحيدة إذا منعوا الآخرين من التعرف على جزءهم من النظام (انظر
محتجز الرهائن ).
لا يمكن إصلاح الجارديان لأنه ليس لديه مثل هذه الرغبة. لديه عقلية العامل في المصنع: قم بتحريف نفس البندق كل يوم طوال حياته المهنية ، ثم اعتزل. لا يمكن تغيير هذا الموقف ، لأنه جوهر الإنسان.
أحد الخيارات التي يمكن أن تغير هذا الموقف هو إذا واجه الشخص أحداثًا مهمة في الحياة (زفاف ، ولادة ، وشراء منزل ، وما إلى ذلك) ، الأمر الذي سيتطلب دخلًا إضافيًا. في هذه الحالة ، سيتفهم أن دعم البرامج القديمة لن يؤدي إلى زيادة. لسوء الحظ ، أنت لا تتحكم في هذا العامل.
انظر أيضا: