في الشركات الكبيرة | أصلي، ترجم بواسطة AI
جدول المحتويات
- حول الشركات الكبيرة
- كثافة المواهب تفوق حجم الفريق الكبير
- الإجراءات تحل محل الثقة في الموظفين
- تجنب المخاطر يخنق نمو الابتكار
- الشركات الناشئة تنشر بسرعة أكبر من الشركات الكبرى
- البيروقراطية تخفي المساءلة الفردية
- الهندسة في الشركات الكبيرة
- القواعد تفرض الاتساق ولكنها تقيد الإبداع
- الفحوصات الآلية تفوت جودة التصميم الدقيقة
- أدوات الاختبار تفتقر إلى عمق التقييم الاستراتيجي
- الأنظمة الأحادية تقاوم التوسع السريع
- سير العمل المكرر يضمن الاحتفاظ بالمعرفة
- حول التعاون
- الفرق تعكس تنظيم الشفرات الوحدوي
- ملكية المهام تقلل من عبء الاتصال
- الشفافية تحل محل حاجة المحاذاة في الوقت الفعلي
- أدوات الذكاء الاصطناعي تعزز المساهمات الفردية
- توقعات غير متطابقة تعيق نجاح المشروع
حول الشركات الكبيرة
الشركات الكبيرة تشبه البرامج الكبيرة. بالنسبة لشركة كبيرة تضم 100,000 موظف و50,000 مقاول، فهي تشبه برنامجًا كبيرًا يحتوي على 150,000 طريقة.
قال داريو أمودي إن كثافة المواهب أكثر أهمية بكثير من عدد المواهب. مائتان من الأشخاص الموهوبين جدًا يمكنهم التغلب على 1,000 شخص موهوب مع 800 شخص عادي.
كما ذكر داريو أمودي أيضًا أن الشركات الكبيرة لديها الكثير من الإجراءات والعمليات لأنها لا تثق بموظفيها أو مقاوليها. لذلك يحتاجون إلى التحقق كثيرًا والتحكم كثيرًا.
إحدى نقاط الشركات الكبيرة هي أنها تخاف من ارتكاب الأخطاء. أحد الأسباب هو أنها نمت لتصبح كبيرة جدًا بقيمة 300 مليار أو 1 تريليون دولار؛ لا بد أنها ارتكبت الكثير من الأخطاء ونمت منها. ومع ذلك، عندما تنجح، فإنها تكره المخاطرة وارتكاب الأخطاء مرة أخرى.
إنها تشبه برنامجًا كبيرًا لا يحب الأخطاء ويحاول القضاء على أي أخطاء، خاصة أخطاء الأمان، خاصة في البنوك الكبيرة.
الشركات الناشئة سريعة، لكن موارد الشركة الناشئة أقل بكثير، وعلامة الشركة الناشئة غير معترف بها؛ ليس لديها ثقة الشركات الكبيرة.
في الصين، لا يزال الشباب الموهوبون يرغبون في الالتحاق بالشركات الكبيرة بعد التخرج ويكافحون للقيام بذلك. في وادي السيليكون، هناك العديد من الشركات الناشئة، بعضها يؤدي بشكل جيد حتى في البداية بمجرد أفكار.
بعض الشركات تعمل لمدة 20 عامًا ولا تزال تكافح، وربما تم شطبها من البورصة، وبعض الشركات تقدر قيمتها بـ 5 مليارات أو 10 مليارات عندما يبلغ عمرها بضعة أشهر فقط.
يذكر أن مختبر ميرا مراتي للآلات المفكرة تبلغ قيمته 12 مليار دولار في جولة التمويل الأولى. وشركة إيليا سوتسكيفر للذكاء الاصطناعي الآمن تجمع 2 مليار دولار بقيمة 32 مليار دولار.
لذا فإن استخدام الوقت المنقضي لقياس الشركة الناشئة ليس مؤشرًا جيدًا؛ من الأفضل قياسها بناءً على ما هو الفريق، ومن هم المؤسسون، وفي أي مجال هم.
في شركتي الناشئة الفردية، أحتاج فقط إلى دقيقة واحدة لنشر خادم الخلفية و5 دقائق لإصلاح خطأ بسيط ونشره. إنه مباشر وسريع. بالنسبة للشركات الكبيرة، يستغرق الأمر أسبوعًا لإعداد طلب النشر، والحصول على موافقات من المديرين، والقيام بالنشر مع فريق تكنولوجيا المعلومات، وإجراء فحوصات الصحة.
على الرغم من أن الوقت الفعلي المستغرق قد يكون 8 ساعات، إذا قسناه، فهو لا يزال أسبوعًا واحدًا من التحضير للنشر إلى الفحص النهائي.
لإصلاح خطأ بسيط ونشره، يستغرق الأمر أسبوعين للقيام بذلك. تحصل على التذكرة للتحقيق، وإجراء التحليل والاختبار، ثم المراجعة، ودمج الكود، وإبلاغ فرق الاختبار للاختبار، ثم النشر.
الشركات الكبيرة تحب فرض سياساتها على جميع الفرق أو المشاريع. لأن شركة كبيرة تضم 200,000 شخص، تلك السياسات أو العمليات الداخلية التي تنطبق فقط على 10,000 شخص لا تحقق الكثير من المعنى أو النتيجة. بالنسبة لبعض العمليات الداخلية، تحتاج الشركات الكبيرة إلى استثمار أفراد أو أموال لتطوير أدوات لدعمها. لذا إذا كانت تخدم نسبة صغيرة جدًا من الموظفين، فإن العائد لا يبرر الاستثمار.
جانب سلبي آخر للشركات الكبيرة هو أنه غالبًا لا يتم معاقبة أي شخص على الأخطاء الكبيرة.
في شركتي الناشئة، حصلت مرة على استثمار نصف مليون لتوظيف 9 أشخاص، وبعد شهرين، اضطررت إلى فصلهم وخسرت هذه الأموال. قمت بـ50 مشروعًا برمجيًا صغيرًا مع مهندسين بدوام جزئي لكسب هذه الأموال ردًا للمستثمر.
هذه ذكرى مؤلمة للغاية. وهذا جعلني أتذكر هذا الدرس طوال الوقت.
في حالة ملحوظة داخل شركة كبيرة، لوحظ أنه لم تكن هناك عواقب كبيرة لأولئك المعنيين. تم فصل بعض المديرين الكبار والعديد من الموظفين الجدد. ولا يزال من غير الواضح ما إذا كان هذا مرتبطًا بحملة توظيف سريعة وكبيرة.
أحد العوامل المساهمة في هذه النتيجة هو العمليات المعقدة والكثيرة داخل الشركات الكبيرة. المهندسون الذين كانوا في الشركة لمدة ستة أشهر إلى عام لم يتمكنوا من تقديم مساهمات كبيرة. شمل الجدول الزمني عادة شهرين لفهم الأساسيات، وثلاثة أشهر للتعرف على المشاريع، وثلاثة أشهر في التنقل خلال الإجراءات المملة أو الاختبار، وأخيرًا، شهرين من العمل المنتج الذي أثر على المستخدمين.
بافتراض يوم عمل مدته ثماني ساعات، فإن شهرين من العمل المنتج لم يحققا نتائج كبيرة. تم استنفاد ميزانية القسم، ولم يتم توسيع قاعدة المستخدمين كما هو متوقع، مما أدى إلى المزيد من عمليات الفصل.
يبدو أنه لم يتم تعلم أي دروس قيمة من هذه التجربة. في البداية، قررت مجموعة من المديرين على استراتيجية توظيف سريعة وواسعة، والتي بدت غير ضرورية في ذلك الوقت. لوم مجموعة المديرين بأكملها لم يكن ممكنًا، كما لم يكن عمليًا فصل أولئك الذين كانوا في الشركة لفترة قصيرة فقط، خاصة عندما كان مديرون آخرون وقادة تقنيون جزءًا من الفريق لمدة ست إلى ثماني سنوات.
لم يحصل المدير الإداري على الكثير من البصيرة من الموقف، حيث كان هذا واحدًا من ثلاثة أقسام تحت إشرافهم، وظل تعويضهم دون تغيير. حتى داخل الفريق، أولئك غير المسؤولين مباشرة لم يتمكنوا من التعلم من التجربة، مما يعكس تصريحات ستيف جوبز حول الاستشارات. ونتيجة لذلك، لم يستوعب أي شخص الدرس اللازم لتشكيل فريق استثنائي قادر على تقديم نتائج استثنائية للمستخدمين.
بالنسبة للشركات الناشئة، يبدو الوضع أفضل بكثير. لأن الأمر جاد حقًا. بعض المؤسسين الذين يخسرون أو يفشلون يواجهون أوقاتًا صعبة حقًا، خاصة الصادقين.
بالنسبة للأفراد ذوي النزاهة، يمكن أن يكون من المحبط للغاية فقدان أموال استثمارية كبيرة، تتراوح من الملايين إلى مئات الملايين من الدولارات، وينتهي بهم الأمر بلا شيء يذكر - ربما مجرد منتج بدائي أو قاعدة مستخدمين رغم حجمها تولد الحد الأدنى من الإيرادات.
كتب بول جراهام مقالة من قبل، التوظيف أصبح قديمًا.
ولكن ما الذي تفعله الشركات الكبيرة بشكل جيد؟ أولاً، النظرة طويلة المدى. إنهم يميلون إلى القيام بأشياء على المدى الطويل. بالنسبة لبعض الشركات الكبيرة الجيدة، فإن تصميمات مشاريعهم جيدة جدًا؛ يستخدمون الخدمات المصغرة لتجنب خطأ تحول البرنامج إلى برنامج أحادي كبير بعد عقد من الزمن. ولديهم فرق حوكمة لوضع بعض الأطر الأساسية وتوحيد ممارسات التطوير للفريق بأكمله.
العمليات أو الإجراءات ليست سيئة بطبيعتها. لكنها غالبًا ما تجعل الأمور معقدة وبطيئة. لا نجد تنسيق الكود الموحد لجافا غير سار لأن هناك ملحق Spotless أو Checkstyle للمساعدة. هذه الملحقات لها تصميم جيد وسهلة الاستخدام.
شيء آخر هو أن الشركات الكبيرة تميل إلى صنع بعض الأدوات أو المشاريع للاستخدام الداخلي، للموظفين الأماميين. لكن قاعدة المستخدمين هذه هي فقط مئات أو 10,000. قاعدة المستخدمين هذه محدودة للغاية.
أعتقد أنه من الأفضل استخدام أدوات خارجية لهذا الغرض. إذا كانت الأداة رائعة حقًا لبنك واحد، فمن المحتمل أن تكون جيدة لـ200 بنك. وهذا يمكن أن يجعل هذه الشركة وحيدة القرن.
يقول تيانشينغ لو، مؤسس Pony.ai، إن سبب حاجة الشركات إلى أن تكون مستقلة هو أنها أكثر كفاءة. هذا صحيح.
والشركات الكبيرة تميل إلى استخدام الخبرة لمكافأة الموظفين. بينما السوق يكافئ النتيجة أو التنفيذ لفرق الشركات الناشئة. إنهم في الواقع مختلفون جدًا.
العمل في الشركات الكبيرة يشبه التعلم في المدرسة. تتقدم من المدرسة الابتدائية إلى المدرسة المتوسطة، ثم إلى الجامعات. ومع ذلك، في الشركات الناشئة، هناك تقلبات أكثر، وهناك مرونة أكبر أثناء الانتقال من فكرة أو سوق إلى آخر.
بالنسبة للشركات الكبيرة، فإن فائدة تجنب المخاطر هي أن منتجاتها مستقرة نسبيًا بدون أخطاء واضحة أو توقف. هذا جيد.
ولكن مثل الذكاء الاصطناعي، في الواقع، الكثير من المستخدمين لا يمانعون المنتج الذي ليس مستقرًا جدًا في البداية، مثل deepseek. نعلم أن deepseek تعطل كثيرًا حوالي فبراير-مارس 2025 عندما حظي باهتمام كبير. لكن بعد بعض الوقت، أصبح أفضل ولا يبدو أن المستخدمين يواجهون مشكلة كبيرة في ذلك.
لذا فإن الأمر يعتمد. في بعض الأحيان، بالنسبة للمنتجات المبتكرة، نحتاج إلى إحضارها إلى السوق بسرعة، حتى لو كان لديها بعض المشكلات. يمكن للمستخدمين التفهم.
إذا فكرنا في العملية، يمكننا أن نكون أكثر حذرًا. يجب أن نقسم أنواع النشر بشكل أفضل. بعض أنواع التغييرات لا بأس بنشرها بسرعة، بينما البعض الآخر ليس كذلك. بالنسبة للاختبار، يجب أن نقسم أي أجزاء من الاختبار نحتاج إلى إجرائها لاختبار الارتداد للكود المعدل، وأي أجزاء لا نفعلها. نفس الشيء ينطبق على فحص SonarQube.
في الشركات الكبيرة، من المؤكد أن العديد من الفحوصات أو الاختبارات أو الموافقات غير ضرورية. قد نترك المهندسين يقومون بعملهم، وبما أن النظام يحتوي على جميع السجلات، يمكننا اختيار بعضها للمراجعة.
يجب علينا أيضًا التخلص من جميع موافقات المديرين. ما هي المعرفة التي يمتلكها المديرون ولا يمتلكها المهندسون؟ هل يمكن كتابة هذه المعرفة في كود للموافقة على الطلبات أو رفضها تلقائيًا؟
لأن كل شيء بطيء هناك، فمن غير المحتمل أن يغير العمال الأشياء. قد يستغرق التغيير من مشروع أحادي كبير إلى خدمات مصغرة لمشروع يعمل منذ عقد من الزمن عامين.
بالنسبة للبرمجيات، فإن الكود والمنطق متشابكان بشدة، خاصة في الأنظمة المصممة جيدًا. وبالتالي، فإن التطوير أو الاختبار أو التعاون المرتبط يمكن أن يكون كبيرًا.
هذا هو السبب في أن توسيع الفريق فجأة غالبًا لا يعمل. إذا كانت هناك بنية خدمات مصغرة مترابطة بشكل فضفاض، فقد يكون ناتج الفريق متناسبًا مع عدد أعضاء الفريق. إذا كان هناك مشروع أحادي مترابط بشدة، فقد يزيد ناتج الفريق بنسبة 30٪ فقط إذا ضاعفنا حجم الفريق العامل عليه.
بسبب وتيرته البطيئة، يمكن أن يكون من الصعب في بعض الأحيان تحديد ما إذا كان الموظف أو المقاول غير قادر أو إذا كان النظام معقدًا جدًا ومتعارضًا للوافدين الجدد. في إحدى الحالات التي لاحظتها، كان أحدهم في الشركة لمدة أربعة أشهر ولم يحقق الكثير، حيث قام فقط بتغيير بضعة أسطر من الكود لتقديم طلب سحب. علاوة على ذلك، كانت جودة الكود ضعيفة لأنه لم يفهمه جيدًا. لغته الإنجليزية كانت ضعيفة جدًا، ولم يتمكن إلا من التواصل بلصق لقطات الشاشة واستخدام الإنجليزية الأساسية لطرح الأسئلة.
بخصوص الاستقرار، أرى أن الشركات الكبيرة تميل إلى جعل أعضاء الفريق يعملون على مهام مكررة. على سبيل المثال، بالنسبة للمهمة A والمهمة B، لا يقومون بتعيين مهندسين من الفريق للعمل بشكل منفصل على المهمة A والمهمة B. بدلاً من ذلك، يقومون بجعل كليهما يعملان على أجزاء من المهمة A والمهمة B بحيث يعرف هذان المهندسان ما يفعله الآخر. وهذا يجعل الفريق أكثر استقرارًا، حيث يمنع حالة معرفة شخص واحد فقط بالكثير من أجزاء الكود والعمل عليها لعدة سنوات دون تعاون. ثم إذا غادر هذا الشخص الشركة، لا يمكن لأي شخص آخر العمل عليها.
شيء آخر تفعله الشركات الكبيرة جيدًا هو الحفاظ على الانضباط المالي والربحية. السبب هو أنه مع نموها الكبير، تواجه غالبًا أزمات مالية كبيرة. هذا على الأرجح أهم شيء تفضله. لقد تعلموا هذا بالطريقة الصعبة وأدخلوا هذه الممارسات في عملياتهم. حتى عندما يحققون أرباحًا تبلغ 10 مليارات دولار أو 30 مليار دولار سنويًا، فإنهم يستمرون في تحسين قوتهم العاملة وإجراء عمليات فصل.
أخبرني أحد زملائي أن الشركات الكبيرة تعمل باحتكار بعض المنتجات التي تتطلب الكثير من العمالة أو الوقت لبنائها. هذا منطقي. لا يعتمدون على السرعة ولكن على حجمهم ومواردهم وعلامتهم التجارية.
كيف تنجو في الشركات الكبيرة؟ أولاً، افعل المزيد، وتحدث أقل. هذا ما قاله لي مدير التسليم في مورد تعهيد.
الشيء الثاني هو اتباع ما يفعله الآخرون؛ فهو آمن. أن تصبح مهندسًا متوسطًا في الفريق أمر آمن، تمامًا مثل أن تكون شخصًا عاديًا في الشارع - لا بارزًا جدًا ولا مهملًا جدًا، ولكن في المنتصف تمامًا.
يجب أن أقول إن هناك العديد من الشركات الكبيرة. بعضها لديه أكثر من 200,000 موظف، بينما البعض الآخر لديه حوالي 20,000. هناك أيضًا شركات كبيرة جيدة وأخرى ذات أداء ضعيف. المظهر أو القيمة السوقية لا يكشفان الكثير أحيانًا. يمكن أن ترتفع بشكل كبير في بضع سنوات، كما فعلت Nvidia مؤخرًا، أو يمكن أن تنهار فجأة، مثل Credit Suisse.
الهندسة في الشركات الكبيرة
الشركات الكبيرة جيدة في التحكم في سياساتها وإدارتها الصارمة. الشركات الكبيرة جيدة في إجراء فحوصات دقيقة وتقييم شامل لإصدار البرامج.
ولكن الكثير من الهندسة لا يمكن حسمها في قواعد واضحة. بساطة التصميم وتحسين كل طريقة أو كل فئة في جافا ليس من السهل التحقق منه بالقواعد.
فحص SonarQube شيء جيد، والتغطية العالية للاختبار شيء جيد. لكن الكثير من تصميم البرامج أو الهندسة لا يمكن قياسه بهذه البساطة.
جودة واجهات برمجة التطبيقات وسهولة استخدام الوظائف لا يمكن تقييمها بسهولة.
معلمات الطرق لا يمكن تقييمها بسهولة. تصميم الوظائف، استراتيجية الفرع، استراتيجية التطوير لا يمكن قياسها بسهولة، وكذلك التسمية.
علي بابا لديها دليل جافا الخاص بها، وجوجل وPlantier لديها تنسيقات جافا الخاصة بهم. هذا جيد. لكن ليس كل شيء في مشروع جافا يمكن التحقق منه تلقائيًا بواسطة الكود.
بخصوص الاختبار، هذا صحيح. هناك الكثير من أدوات الاختبار التلقائي. لكن ليس كل استراتيجيات الاختبار أو تصاميمها أو فلسفاتها أو تقنياتها لديها قواعد ثابتة.
بخصوص المنتجات، هذا صحيح. هناك الكثير من اختبارات A/B وتطوير المنتجات القائمة على البيانات. لكن ليس كل تكنولوجيا أو مهارات أو رؤى المنتج يمكن قياسها بقواعد ثابتة.
لماذا أريد مناقشة هذا؟ لأنه يعني أن قيمتنا تكمن في هذه القطاعات. ما هي الأشياء التي لا تجيدها الشركات الكبيرة؟ حتى نتمكن من مساعدتهم في القيام بها.
لماذا أذكر الهندسة في الشركات الكبيرة بدلاً من الهندسة في الشركات؟ في الواقع، الأمر لا يتعلق فقط بالشركات الكبيرة أو الشركات الناشئة الصغيرة. إنها مكونة من أشخاص؛ فقط عدد الموظفين لديه بعض الاختلاف.
الهندسة في الشركات الكبيرة أقل تنوعًا منها في الشركات الناشئة.
حول التعاون
التعاون صعب. إنه يتضمن العمل معًا لتحقيق أهداف مشتركة. دعونا نفكر في هذا من منظور البرمجة.
في الجوهر، كل فرد هو مثل برنامج معقد، مكون من تجارب الحياة، والخبرة العملية، ورؤى العالم، والعلاقات الوثيقة، والنشأة، والتفاعلات الرقمية.
التحدي يكمن في تحقيق هدف كفريق. كيف يجب أن تتعاون المجموعة بفعالية؟ كيف يمكن للخدمات المصغرة العمل معًا لتعمل بتناغم؟
بالنسبة للمشاريع الشخصية، يمتلك الفرد كل شيء ويتعامل مع كل شيء دون الحاجة إلى التعاون. في الوقت الحاضر، يستخدم الأفراد العديد من أدوات الذكاء الاصطناعي لتحقيق أهدافهم.
في فريق صغير مكون من بضعة أشخاص، يتم تقسيم المسؤوليات. على سبيل المثال، قد يتعامل شخص واحد مع التصميم بينما يركز آخر على التطوير. بدلاً من ذلك، يمكن أن يكون شخص واحد مسؤولاً عن الواجهة الخلفية، وآخر عن الواجهة الأمامية.
في الشركات الكبيرة، هناك غالبًا قلق من مغادرة الموظفين، مما يخلق فجوات معرفية في المشاريع. قد يحتاج الشخص الجديد الذي يتولى المسؤوليات إلى شهور أو حتى عام لمواكبة ذلك، مما يؤدي إلى إبطاء أو تعطيل المشروع.
ومع ذلك، في عصر الذكاء الاصطناعي، أعتقد أنه يجب علينا تكييف نهجنا. مفهوم “خرافة رجل الشهر” صحيح.
أنا أؤيد بشدة التعاون الطبيعي. لمصلحة الفريق، مع تقدم المشروع، تتشكل عادات تعاونية طبيعية داخل الفريق.
هذا يشبه التوزيع الطبيعي للكود. بعد بعض التطوير، قد يكون لدينا 50 فصلًا في جافا، نقوم بعد ذلك بتنظيمها في حزم. وبالمثل، مع 100 ملف بايثون، نستخدم الوحدات لإدارتها.
يجب أن يأخذ فصل المهام في الاعتبار نقاط قوة كل شخص. في عصر الذكاء الاصطناعي، يمكن للأفراد التفوق في مجالات متعددة. لذلك، يجب أن نعيد التفكير في كيفية تقسيم المهام الكبيرة بين أعضاء الفريق.
أعتقد أن كل عضو في الفريق يجب أن يكون مسؤولاً عن مهمة كبيرة نسبيًا في كل مرة. يقلل هذا النهج من الحاجة إلى اتصال متكرر أو محاذاة مع الآخرين. يجب أن تكون المهمة الكبيرة مستقلة نسبيًا، مما يسمح للأفراد بطلب المساعدة من كبار أعضاء الفريق الذين لديهم المزيد من الخبرة عند الحاجة. بهذه الطريقة، يمكن أن يشارك المزيد من الأشخاص، لكن تظل المهمة مملوكة في المقام الأول للشخص المكلف.
إذا تعاون شخصان لتحرير كل سطر من الكود أو العمل على كل التفاصيل معًا، فقد يكون ذلك مرهقًا. سيحتاجون إلى محاذاة أفعالهم في كل خطوة، وهذا صعب. في الحوسبة، هناك طرق عديدة لتحقيق هدف. طالما أن النتيجة ذات جودة جيدة وتفي بالهدف، يجب أن نقبل طرقًا أو أدوات مختلفة، سواء كانت بيئة تطوير متكاملة معينة، أو عميل SQL، أو نصوص بايثون، أو عمليات يدوية.
تحسين آخر في التعاون هو ضمان أن تكون سجلات العمل شفافة قدر الإمكان. في عملي الأخير، شاركت نصوصي وسجلاتي وملاحظاتي مع أعضاء الفريق. يمكنني مشاركة الاستفسارات التي طرحتها على Copilot، والمشكلات التي واجهتها على طول الطريق، والسجلات ذات الصلة. هذه الشفافة تجعل التواصل مع أعضاء الفريق أسهل.
بفعل ذلك، يشبه الأمر تسجيل شاشة الكمبيوتر الخاصة بي أثناء أداء المهام. على الرغم من أننا نستخدم النص هنا لمشاركة المعلومات، فإن الهدف من اتصال أفضل يتحقق.
لماذا يفشل التعاون؟ ما هي أنواع السيناريوهات التي تؤدي إلى عدم عمل التعاون؟ أحد الأسباب هو التوقعات غير المتطابقة بين أعضاء الفريق. النتيجة المحتملة هي تأخير المشروع أو فشل العمل في تلبية متطلبات الجودة.