تصاعد الديون التقنية في شركات البرمجيات الهندية الصغيرة التي تطور التطبيقات والمواقع الإلكترونية: من المسؤول عنها؟

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

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

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

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

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

1. العملاء غير الصادرين والذكاء

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

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

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

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

2. مديرو كسول وخطير

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

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

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

3. المبرمجين

أوه نعم ، لن أنهي هذا الموضوع بلومكم يا رفاق أيضًا! لكن مهلا ، #notallprogrammers أليس كذلك؟ حسنًا ، أجل ، لكن ما يقرب من 94٪ من المبرمجين. على الأقل هذا ما يعتقده CP Gurani ، الرئيس التنفيذي لشركة Tech Mahindra ، عندما كشف عن اكتشاف صادم قبل عامين بأن 94٪ من خريجي تكنولوجيا المعلومات غير مؤهلين للوظيفة. لا أعرف بالضبط كيف وصل إلى هذا الرقم ، ولكن لكوني نتاج كليات الهندسة الهندية وبعد أن شاهدت النظام البيئي لهندسة تكنولوجيا المعلومات بالكامل على مدار السنوات العشر الماضية ، يمكنني القول إنني أميل إلى الموافقة على ما قاله السيد جوراني.

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

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

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

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

سأنهي هذا بهذا الاقتباس الختامي من صموئيل بيكيت: