مخصص لمديري المشاريع (وأولئك الذين يحلمون بأن يصبحوا رؤساء).
إن كتابة الكثير من الأكواد البرمجية أمر صعب، لكن إدارة الأشخاص أصعب بكثير! لذلك تحتاج فقط إلى هذا الكتاب لتتعلم كيفية القيام بالأمرين معًا.
هل يمكن الجمع بين القصص المضحكة والدروس الجادة؟ نجح مايكل لوب (المعروف أيضًا في الدوائر الضيقة باسم راندز). ستجد قصصًا خيالية عن أشخاص خياليين لديهم تجارب مجزية بشكل لا يصدق (وإن كانت خيالية). هذه هي الطريقة التي يشارك بها راندز تجاربه المتنوعة والغريبة أحيانًا التي اكتسبها على مدار سنوات العمل في شركات تكنولوجيا المعلومات الكبيرة: Apple، وPinterest، وPalantir، وNetscape، وSymantec، وما إلى ذلك.
هل أنت مدير المشروع؟ أو تريد أن تفهم ما يفعله رئيسك اللعين طوال اليوم؟ سوف يعلمك راندز كيفية البقاء على قيد الحياة في العالم السام للديك الرومي المتضخم والازدهار في الجنون العام للأشخاص المتهورين المختلين وظيفياً. في هذا المجتمع الغريب من المجانين المهووسين، توجد مخلوقات غريبة - مديرون اكتسبوا، من خلال طقوس تنظيمية غامضة، السلطة على الخطط والأفكار والحسابات المصرفية للعديد من الأشخاص.
هذا الكتاب لا يشبه أي مخطوطة الإدارة أو القيادة. لا يخفي مايكل لوب أي شيء، بل يروي الأمر كما هو (ربما لا ينبغي نشر كل القصص علنًا: P). ولكن بهذه الطريقة فقط ستفهم كيفية البقاء على قيد الحياة مع مثل هذا الرئيس، وكيفية إدارة المهووسين والمهووسين، وكيفية جلب "هذا المشروع اللعين" إلى نهاية سعيدة!
مقتطفات. العقلية الهندسية
أفكار حول: هل يجب عليك الاستمرار في كتابة التعليمات البرمجية؟
يحتوي كتاب راندز حول قواعد المديرين على قائمة قصيرة جدًا من "الواجبات" الإدارية الحديثة. تنبع إيجاز هذه القائمة من حقيقة أن مفهوم "يجب" هو نوع من المطلق، وعندما يتعلق الأمر بالناس، هناك عدد قليل جدًا من المفاهيم المطلقة. إن أسلوب الإدارة الناجح لموظف واحد سيكون بمثابة كارثة حقيقية لموظف آخر. هذه الفكرة هي العنصر الأول في قائمة "ما يجب القيام به" للمدير:
كن مرنًا!
إن الاعتقاد بأنك تعرف كل شيء بالفعل هو فكرة سيئة للغاية. في موقف تكون فيه الحقيقة الثابتة الوحيدة هي أن العالم يتغير باستمرار، تصبح المرونة هي الموقف الصحيح الوحيد.
ومن المفارقة أن العنصر الثاني في القائمة غير مرن بشكل مدهش. ومع ذلك، هذه النقطة هي المفضلة لدي لأنني أعتقد أنها تساعد في إنشاء الأساس للنمو الإداري. تنص هذه الفقرة على ما يلي:
التوقف عن كتابة التعليمات البرمجية!
من الناحية النظرية، إذا كنت تريد أن تصبح مديرًا، عليك أن تتعلم الثقة في أولئك الذين يعملون لديك وتسليمهم البرمجة بالكامل. عادة ما تكون هذه النصيحة صعبة الهضم، خاصة بالنسبة للمديرين الجدد. ربما يكون أحد أسباب تحولهم إلى مديرين هو إنتاجيتهم في التطوير، وعندما تسوء الأمور، يكون رد فعلهم الأول هو اللجوء إلى المهارات التي يثقون بها تمامًا، وهي قدرتهم على كتابة التعليمات البرمجية.
عندما أرى أن المدير الجديد "يغرق" في كتابة التعليمات البرمجية، أقول له: "نحن نعلم أنه يمكنك كتابة التعليمات البرمجية. السؤال هو: هل تستطيع القيادة؟ لم تعد مسؤولاً عن نفسك وحدك، أنت مسؤول عن الفريق بأكمله؛ وأريد التأكد من أنه يمكنك جعل فريقك يحل المشكلات بنفسه، دون الحاجة إلى كتابة الكود بنفسك. مهمتك هي معرفة كيفية توسيع نطاق نفسك. لا أريدك أن تكون واحدًا فقط، بل أريد أن يكون هناك الكثير مثلك."
نصيحة جيدة، أليس كذلك؟ حجم. إدارة. مسؤولية. مثل هذه الكلمات الطنانة الشائعة. ومن المؤسف أن النصيحة خاطئة.
غير صحيح؟
نعم. النصيحة خاطئة! لم يكن الأمر خاطئًا تمامًا، ولكنه كان خاطئًا بدرجة كافية لدرجة أنني اضطررت إلى الاتصال ببعض زملائي السابقين والاعتذار: "هل تتذكر بياني المفضل حول كيفية التوقف عن كتابة التعليمات البرمجية؟ هذا خطأ! نعم... ابدأ البرمجة مرة أخرى. ابدأ ببايثون وروبي. نعم انا جدي! حياتك المهنية تعتمد على ذلك!
عندما بدأت مسيرتي المهنية كمطور برامج في شركة Borland، عملت ضمن فريق Paradox Windows، الذي كان فريقًا ضخمًا. كان هناك 13 مطور تطبيقات فقط. إذا أضفت أشخاصًا من فرق أخرى كانوا أيضًا يعملون باستمرار على التقنيات الأساسية لهذا المشروع، مثل محرك قاعدة البيانات الأساسية وخدمات التطبيقات الأساسية، فستحصل على 50 مهندسًا يشاركون بشكل مباشر في تطوير هذا المنتج.
لا يوجد فريق آخر عملت معه على الإطلاق يقترب من هذا الحجم. في الواقع، مع مرور كل عام، يتناقص تدريجيًا عدد الأشخاص في الفريق الذي أعمل فيه. ماذا يحدث هنا؟ هل أصبحنا نحن المطورين مجتمعين أكثر ذكاءً وذكاءً؟ لا، نحن فقط نتقاسم العبء
ما الذي كان يفعله المطورون على مدار العشرين عامًا الماضية؟ خلال هذا الوقت كتبنا كمية كبيرة من التعليمات البرمجية. بحر الكود! لقد كتبنا الكثير من التعليمات البرمجية لدرجة أننا قررنا أنه سيكون من الجيد تبسيط كل شيء والتحول إلى مصدر مفتوح.
ولحسن الحظ، وبفضل الإنترنت، أصبحت هذه العملية الآن بسيطة قدر الإمكان. إذا كنت مطور برامج، يمكنك التحقق من ذلك الآن! ابحث عن اسمك على Google أو Github وسترى الرمز الذي نسيته منذ فترة طويلة، ولكن يمكن لأي شخص العثور عليه. مخيف، أليس كذلك؟ ألا تعلم أن هذا الرمز يعيش إلى الأبد؟ نعم، إنه يعيش إلى الأبد.
الكود يعيش إلى الأبد. والرمز الجيد لا يعيش إلى الأبد فحسب، بل ينمو أيضًا لأن أولئك الذين يقدرونه يضمنون باستمرار بقائه متجددًا. تساعد هذه الكومة من التعليمات البرمجية عالية الجودة والتي يتم صيانتها جيدًا على تقليل متوسط حجم الفريق الهندسي لأنها تتيح لنا التركيز على التعليمات البرمجية الحالية بدلاً من كتابة تعليمات برمجية جديدة، وإنجاز المهمة مع عدد أقل من الأشخاص وفي إطار زمني أقصر.
يبدو هذا المنطق محبطًا، لكن الفكرة هي أننا جميعًا مجرد مجموعة من الآلات التكاملية التي تستخدم شريطًا لاصقًا لربط أجزاء مختلفة من الأشياء الموجودة معًا لإنشاء نسخة مختلفة قليلاً من نفس الشيء. هذا هو خط التفكير الكلاسيكي بين كبار المسؤولين التنفيذيين الذين يحبون الاستعانة بمصادر خارجية. "أي شخص يعرف كيفية استخدام Google ولديه شريط لاصق يمكنه القيام بذلك! فلماذا ندفع الكثير من المال لآلاتنا؟
نحن ندفع لهؤلاء الإدارة أموالاً طائلة حقًا، لكنهم يعتقدون أن مثل هذا الهراء. مرة أخرى، نقطتي الأساسية هي أن هناك العديد من المطورين الرائعين والمجتهدين للغاية على كوكبنا؛ إنهم حقًا متألقون ومجتهدون، على الرغم من أنهم لم يقضوا دقيقة واحدة في الجامعات المعتمدة. أوه نعم، الآن هناك المزيد والمزيد منهم!
لا أقترح عليك أن تبدأ بالقلق بشأن مكانك لمجرد أن بعض الرفاق اللامعين يبحثون عنه. أقترح عليك أن تبدأ بالقلق بشأن هذا الأمر لأن تطور تطوير البرمجيات ربما يتحرك بشكل أسرع منك. لقد عملت لمدة عشر سنوات، خمس منها كمدير، وتفكر: "أنا أعرف بالفعل كيف يتم تطوير البرمجيات". نعم انت تعرف. الوداع…
توقف عن كتابة التعليمات البرمجية، ولكن...
إذا اتبعت نصيحتي الأصلية وتوقفت عن كتابة التعليمات البرمجية، فسوف تتوقف أيضًا طوعًا عن المشاركة في عملية الإنشاء. ولهذا السبب لا أستخدم الاستعانة بمصادر خارجية بنشاط. الآلات لا تخلق، بل تنتج. إن العمليات المصممة بشكل جيد توفر الكثير من المال، ولكنها لا تجلب أي شيء جديد إلى عالمنا.
إذا كان لديك فريق صغير يقوم بالكثير مقابل القليل من المال، فإن فكرة التوقف عن كتابة التعليمات البرمجية تبدو قرارًا مهنيًا سيئًا بالنسبة لي. حتى في الشركات الضخمة ذات الأنظمة والعمليات والسياسات التي لا نهاية لها، ليس من حقك أن تنسى كيفية تطوير البرمجيات بنفسك. وتطوير البرمجيات يتغير باستمرار. إنه يتغير الآن. تحت قدميك! في هذه الثانية بالذات!
لديك اعتراضات. يفهم. دعونا نستمع.
"راندز، أنا في طريقي إلى كرسي المخرج! إذا واصلت كتابة التعليمات البرمجية، فلن يصدق أحد أنني أستطيع النمو."
أريد أن أسألك هذا: منذ أن جلست في كرسي "أنا على وشك أن أصبح مديرًا تنفيذيًا!"، هل لاحظت أن مشهد تطوير البرمجيات يتغير، حتى داخل شركتك؟ إذا كانت إجابتك بنعم، فسأطرح عليك سؤالاً آخر: كيف يتغير بالضبط وماذا ستفعل حيال هذه التغييرات؟ إذا أجبت بـ "لا" على سؤالي الأول، فأنت بحاجة إلى الانتقال إلى كرسي مختلف، لأن (أراهن!) مجال تطوير البرمجيات يتغير في هذه اللحظة بالذات. كيف ستنمو إذا نسيت ببطء ولكن بثبات كيفية تطوير البرمجيات؟
نصيحتي هي ألا تلزم نفسك بتنفيذ الكثير من الميزات لمنتجك التالي. أنت بحاجة إلى اتخاذ خطوات باستمرار للبقاء على اطلاع بكيفية بناء فريقك للبرامج. يمكنك القيام بذلك كمدير ونائب للرئيس. شيء آخر؟
"آه، راندز! ولكن يجب أن يكون شخص ما هو الحكم! يجب على شخص ما أن يرى الصورة الكبيرة. إذا كتبت التعليمات البرمجية، فسوف أفقد المنظور."
لا يزال يتعين عليك أن تكون الحكم، ولا يزال يتعين عليك بث القرارات، ولا يزال يتعين عليك التجول حول المبنى أربع مرات صباح كل يوم اثنين مع أحد مهندسيك للاستماع إلى صراخه الأسبوعي "كلنا محكومون" لمدة 30 دقيقة دقائق.! ولكن بعد كل ذلك، عليك أن تحافظ على عقلية هندسية، وليس عليك أن تكون مبرمجًا بدوام كامل للقيام بذلك.
نصائحي للحفاظ على العقلية الهندسية:
- استخدم بيئة التطوير. هذا يعني أنك يجب أن تكون على دراية بأدوات فريقك، بما في ذلك نظام بناء التعليمات البرمجية والتحكم في الإصدار ولغة البرمجة. ونتيجة لذلك، سوف تصبح ماهرًا في اللغة التي يستخدمها فريقك عند الحديث عن تطوير المنتج. سيسمح لك هذا أيضًا بمواصلة استخدام محرر النصوص المفضل لديك، والذي يعمل بشكل مثالي.
- يجب أن تكون قادرًا على رسم مخطط معماري تفصيلي يصف منتجك على أي سطح في أي وقت. الآن لا أقصد النسخة المبسطة التي تحتوي على ثلاث خلايا وسهمين. يجب أن تعرف الرسم التخطيطي التفصيلي للمنتج. أصعب واحد. ليس فقط أي رسم تخطيطي لطيف، ولكن رسم تخطيطي يصعب تفسيره. يجب أن تكون خريطة مناسبة للفهم الكامل للمنتج. إنه يتغير باستمرار، ويجب أن تعرف دائمًا سبب حدوث تغييرات معينة.
- تولي تنفيذ إحدى الوظائف. أنا أشعر بالفزع حرفيًا وأنا أكتب هذا لأن هذه النقطة بها الكثير من المخاطر الخفية، لكنني لست متأكدًا حقًا من أنه يمكنك إنجاز النقطة رقم 1 والنقطة رقم 2 دون الالتزام بتنفيذ ميزة واحدة على الأقل. من خلال تنفيذ إحدى الميزات بنفسك، لن تشارك بنشاط في عملية التطوير فحسب، بل ستسمح لك أيضًا بالتبديل بشكل دوري من دور "المدير المسؤول عن كل شيء" إلى دور "الرجل المسؤول عن تنفيذ واحدة" من الوظائف." سيذكرك هذا الموقف المتواضع والمتواضع بأهمية القرارات الصغيرة.
- ما زلت أرتعش في كل مكان. يبدو أن أحدهم يصرخ في وجهي بالفعل: "المدير الذي تولى تنفيذ الوظيفة؟!" (وأنا أتفق معه!) نعم، أنت لا تزال المدير، مما يعني أنه يجب أن تكون هناك وظيفة صغيرة، حسنًا؟ نعم، لا يزال أمامك الكثير لتفعله. إذا لم تتمكن من تنفيذ الوظيفة، فلدي بعض النصائح الاحتياطية لك: أصلح بعض الأخطاء. في هذه الحالة، لن تشعر بفرحة الإبداع، لكن سيكون لديك فهم لكيفية إنشاء المنتج، مما يعني أنك لن تترك عاطلاً عن العمل أبدًا.
- كتابة اختبارات الوحدة ما زلت أفعل هذا في وقت متأخر من دورة الإنتاج عندما يبدأ الناس بالجنون. فكر في الأمر كقائمة مرجعية صحية لمنتجك. افعل هذا كثيرًا.
الاعتراض مرة أخرى؟
"راندز، إذا كتبت التعليمات البرمجية، فسوف أربك فريقي. لن يعرفوا من أنا – مديرًا أم مطورًا”.
حسنا.
نعم، قلت، "حسنا!" أنا سعيد لأنك تعتقد أنه يمكنك إرباك فريقك بمجرد السباحة في بركة المطورين. الأمر بسيط: الحدود بين الأدوار المختلفة في تطوير البرمجيات غير واضحة حاليًا. يقوم فريق واجهة المستخدم بما يمكن تسميته على نطاق واسع ببرمجة JavaScript وCSS. يتعلم المطورون المزيد والمزيد عن تصميم تجربة المستخدم. يتواصل الناس مع بعضهم البعض ويتعلمون عن الأخطاء، وعن سرقة رموز الآخرين، وأيضًا عن حقيقة أنه لا يوجد سبب وجيه لعدم مشاركة المدير في هذه المعلومات الضخمة والعالمية المتداخلة.
علاوة على ذلك، هل تريد أن تكون جزءًا من فريق يتكون من مكونات قابلة للاستبدال بسهولة؟ وهذا لن يجعل فريقك أكثر ذكاءً فحسب، بل سيمنح كل عضو في الفريق الفرصة لرؤية المنتج والشركة من وجهات نظر متنوعة. كيف يمكنك أن تحترم فرانك، الرجل الهادئ المسؤول عن التصميمات، أكثر من مجرد رؤية الأناقة البسيطة لنصوص التصميم الخاصة به؟
لا أريد أن يصبح فريقك مرتبكًا وفوضويًا. على العكس من ذلك، أريد أن يتواصل فريقك بشكل أكثر فعالية. أعتقد أنه إذا شاركت في إنشاء المنتج والعمل على الميزات، فسوف تكون أقرب إلى فريقك. والأهم من ذلك أنك ستكون أقرب إلى التغييرات المستمرة في عملية تطوير البرامج داخل مؤسستك.
لا تتوقف عن التطور
ذات مرة، هاجمتني إحدى زميلاتي في بورلاند لفظيًا لأنني وصفتها بـ "المبرمجة".
"راندز، المبرمج هو آلة طائشة! قرد! لا يقوم المبرمج بأي شيء مهم باستثناء كتابة سطور مملة من التعليمات البرمجية عديمة الفائدة. أنا لست مبرمجًا، أنا مطور برامج!
لقد كانت على حق، وكانت ستكره نصيحتي الأولية للرؤساء التنفيذيين الجدد: "توقف عن كتابة التعليمات البرمجية!" ليس لأنني أقترح أنهم مبرمجون، ولكن لأنني أقترح بشكل استباقي أن يبدأوا في تجاهل أحد أهم أجزاء عملهم: تطوير البرمجيات.
لذلك قمت بتحديث نصيحتي. إذا كنت تريد أن تصبح قائدًا جيدًا، فيمكنك التوقف عن كتابة التعليمات البرمجية، ولكن...
كن مرنًا. تذكر ما يعنيه أن تكون مهندسًا ولا تتوقف عن تطوير البرمجيات.
نبذة عن الكاتب
مايكل لوب هو مطور برمجيات مخضرم لم يغادر وادي السيليكون بعد. على مدار العشرين عامًا الماضية، عمل مايكل في مجموعة متنوعة من الشركات المبتكرة، بما في ذلك Apple وNetscape وSymantec وBorland وPalantir وPinterest، وشارك أيضًا في شركة ناشئة طفت ببطء إلى غياهب النسيان.
خارج العمل، يدير مايكل مدونة شعبية حول التكنولوجيا والإدارة تحت الاسم المستعار راندز، حيث يناقش الأفكار في مجال الإدارة مع القراء، ويعرب عن قلقه بشأن الحاجة المستمرة لإبقاء إصبعه على النبض، ويوضح أنه على الرغم من مكافآت سخية لإنشاء منتج، نجاحك ممكن فقط بفضل فريقك. المدونة يمكن العثور عليها هنا .
يعيش مايكل مع عائلته في ريدوود، كاليفورنيا. يجد دائمًا وقتًا لركوب الدراجة الجبلية ولعب الهوكي وشرب النبيذ الأحمر، لأن الصحة أهم من الانشغال.
»لمزيد من المعلومات حول الكتاب ، يرجى زيارة
»
»
ل Khabrozhiteli خصم 20٪ على الكوبون - إدارة الناس
عند دفع ثمن النسخة الورقية من الكتاب، سيتم إرسال نسخة إلكترونية من الكتاب عبر البريد الإلكتروني.
ملحوظة: 7% من سعر الكتاب سيذهب لترجمة كتب الكمبيوتر الجديدة، قائمة الكتب المسلمة إلى المطبعة .
المصدر: www.habr.com