👊🏾 ♿️ 👥 كيف تتجنب غضب البرمجة؟ نصائح للتكامل 🌲 🥠 🔙

في مقال سابق حول مشاكل إدخال تخطيط موارد المؤسسات في المؤسسات الصناعية كدراسة حالة ، تم إحضار إحدى النقاط إلى "الفوضى المبرمجة".

لدينا زبون لديه موظفيه الآن ، يرسل إلينا متطلبات مريبة ، ويحدد ما إذا كان هذا هو انعدام القانون الآلي. والبعض لا يحدد ، ولكن يخلقونه.

الموضوع ذو صلة ، وقررت كتابة مقال منفصل عنه.

ما هذا؟

ما نوع اللوحات التي يرسمها خيالك عندما تسمع عبارة "انعدام القانون الآلي"؟

يضرب رجل ملتح ذو مظهر ذكي ذكي كبير المحاسبين الدموع بكمية من Knut ، قائلاً: "كوبيك ، تقول أنك لم توافق على الفاتورة؟ المرسل إليه لا يصلح في الزنزانة؟ الآن سنقوم بختمه بكتاب وكل شيء مناسب! "

, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»

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

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

اسمحوا لي أن أقدم لكم بضعة أمثلة:

, , . - , .
. , , «» . . , , .

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

سأحاول تحديد حدود توصياتي مقدمًا - نحن نتحدث عن:

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

إذن ما هي أسباب هذه الظاهرة وما الذي يمكن فعله حيالها؟

عدم الرغبة أو عدم القدرة على النظر إلى جوهر العملية

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

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

"أضف حقلاً جديدًا من هذا النوع إلى مرجع التسميات" - "جيد. تعقيد 15 دقيقة ". لذا ، لماذا تحتاج هذا المجال في التسميات؟ هذه خاصية تختلف من طرف إلى آخر. ربما من الأفضل إضافة هذا الحقل إلى دليل الأطراف؟

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

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

عدم القدرة على التحمل في مكافحة الرغبة في ترك كل شيء بالطريقة القديمة

هذا هو الحال عندما لا يتم إنشاء فوضى المبرمج من قبل المطورين ، ولكن بتواطؤهم.

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

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».

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

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

عادة حل جميع المشاكل بالبرمجة

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

, , . , , , . . , . , , . : .

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

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

الثقة بالنفس

هناك وظيفة لا ينبغي تعديلها. في Axapt ، هذا ، على سبيل المثال ، التخطيط الرئيسي. في ذاكرتي ، لمسناه مرتين فقط. وفي كل مرة لم يتم تضمينها في الشفرة ، ولكن نوعًا من "اللطخة" - الوظائف التي تم تنفيذها قبل أو بعد التخطيط الموحد. ومع ذلك ، أتذكر هذه التحسينات مع الشوق.

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

هنا يمكن نصح بشيء واحد: لتوظيف أشخاص من ذوي الخبرة ، الذين حصلوا بالفعل من عملاء آخرين أو في مشاريع أخرى ، على جميع المطبات التي يمكن ، من حيث المبدأ ، ملؤها.

عدم وجود لوائح التطوير

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

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

يتم التطوير على تطبيق مطور البرامج.
يتم الاختبار على تطبيق الاختبار ؛
يجب أن يحتوي الرمز على تعليقات.

يجب أن يكون هذا مستندًا كاملاً مع عشر صفحات بأقسام:

متطلبات تطوير التطبيقات.
متطلبات كتابة بيان المشكلة.
متطلبات كتابة التعليمات البرمجية.
متطلبات الاختبار.
متطلبات الترحيل بين التطبيقات.

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

الوحدة وانعدام السيطرة

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

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

مراقبة جودة التنمية ؛
تدريب المبرمجين الأقل خبرة.

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

استنتاج

وبالتالي ، من أجل تقليل احتمالية "انعدام القانون الآلي" ، من الضروري تشكيل قسم التطوير الداخلي الخاص بك وفقًا للقواعد التالية:

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

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

كيف تتجنب غضب البرمجة؟ نصائح للتكامل