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