حكايات عن ضحايا تكنولوجيا المعلومات والرقمنة الروسية القاسية

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

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

عندما اتصلوا بنا لفهم ، كان هناك حوالي 10 إصدارات برامج مختلفة (الإصدارات من 0.9 إلى 2.4). هناك 1.5 مصادر ، تم جمع هذا الإصدار مرة واحدة منهم. لا وثائق. ويحتاج النظام إلى تطويرها وتطويرها. لقد عدوا "إعادة كتابة كل شيء مرة أخرى" و "وضع اللمسات الأخيرة على 1.5" واستقروا في الثانية - TtM من ثلاثة إلى أربعة أشهر مقابل السنة. علمونا كيفية جمع متخصصي الدعم ، وتصحيح المصادر ، وخفض قواعد الكود ، وإنشاء البنية التحتية ، وتنظيم "صب" واحد ، حيث يتم استلام المصدر ، وجمعه وتوزيعه هناك. كلفنا والعميل الكثير من البواسير.

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

مثال آخر

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

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

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

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

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

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

ما الخطأ عادة؟ مجموعة من الأمثلة

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

1. عقوبة الأخطاء في البرامج التي ساهمت بها المطورين.

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

2. اجتماعات من الصباح إلى المساء.

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

3. عبادة البضائع. نأخذ منهجيات مرنة وننفذها بشكل صارم.

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

4. الأدوات: ننفذ للإبلاغ عن تنفيذها.

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

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

5. معايير الترميز: مكتوبة دون فهم أو لم يتم تحديثها لمدة 10 سنوات.

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

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

6. أخطاء اللوائح.

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

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

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

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

7. قتال حراس الأمن.

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

8. لم يتم تأسيس التواصل بين المطورين والمحللين.

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

9. المؤتمر يحركها التنمية.

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

نظرًا للمؤتمرات الداخلية ، لا يزال من الممكن الوصول إلى النتيجة وفقًا للمخطط "جاهز دائمًا بنسبة 80٪". في التقارير العامة - "انتهى تقريبًا" ، ولا ينتهي. يصل إلى 100 ٪ يحدث أبدا. لماذا؟ حسنًا ، على سبيل المثال ، انظر النقطة 1.

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

10. مخيف لإجراء تغييرات.

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

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

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

وتر النهائي. شخص آخر في شركة واحدة هو الترميز الحق في همز. "هناك واحد كمان صغير ، وأنا أعلم ما أفعله." شكراً لك يا عزيزي ، ولكن إذا وجدت لك ، فأنا لا أعرف ماذا أفعل معك.

بشكل عام ، تحدث. إذا اكتشفت مشاكلك ، فاكتب إلى oeremeev@croc.ru. بالنسبة إلى الشركات الكبيرة ، لدينا طيارون مجانيون تقريبًا مع تشخيصات سريعة (البحث عن الاختناقات في 3-5 أيام). إذا احتاج شخص من عملك إلى شرح أنه من المستحيل تحمل الديون الفنية ، - اكتب أيضًا ، يمكننا حساب ذلك بشكل طبيعي.