تقدیم به مدیران پروژه (و کسانی که رویای رئیس شدن را دارند).
نوشتن چندین کد سخت است، اما مدیریت افراد حتی سخت تر است! بنابراین برای یادگیری نحوه انجام هر دو فقط به این کتاب نیاز دارید.
آیا می توان داستان های خنده دار و درس های جدی را با هم ترکیب کرد؟ مایکل لوپ (که در محافل باریک با نام رندز نیز شناخته می شود) موفق شد. شما داستان های تخیلی درباره افراد خیالی با تجربیات فوق العاده ارزشمند (هرچند تخیلی) پیدا خواهید کرد. رندز تجربیات متنوع و گاه عجیب خود را که طی سال‌ها کار در شرکت‌های بزرگ فناوری اطلاعات کسب کرده است، به اشتراک می‌گذارد: Apple، Pinterest، Palantir، Netscape، Symantec و غیره.
آیا شما یک مدیر پروژه هستید؟ یا می خواهید بفهمید که رئیس لعنتی شما تمام روز چه می کند؟ رندز به شما می آموزد که چگونه در دنیای سمی بوقلمون های متورم زنده بمانید و در جنون عمومی افراد پر زرق و برق ناکارآمد پیشرفت کنید. در این جامعه عجیب مغزهای شیدایی، موجودات غریب تری هم وجود دارند - مدیرانی که از طریق یک تشریفات سازمانی عرفانی، بر نقشه ها، افکار و حساب های بانکی بسیاری از مردم قدرت پیدا کرده اند.
این کتاب شبیه هیچ نسخه خطی مدیریت یا رهبری نیست. مایکل لوپ چیزی را پنهان نمی کند، فقط آن را همانطور که هست می گوید (شاید همه داستان ها نباید علنی شوند: P). اما فقط از این طریق می توانید بفهمید که چگونه با چنین رئیسی زنده بمانید، چگونه گیک ها و نردها را مدیریت کنید و چگونه "آن پروژه لعنتی" را به پایان خوشی برسانید!
گزیده. ذهنیت مهندسی
افکاری در مورد: آیا باید به نوشتن کد ادامه دهید؟
کتاب رندز در مورد قوانین برای مدیران حاوی فهرست بسیار کوتاهی از «باید»های مدیریتی مدرن است. لاکونیسم این فهرست از این واقعیت ناشی می شود که مفهوم "باید" نوعی مطلق است و وقتی صحبت از مردم می شود، مفاهیم مطلق بسیار کمی وجود دارد. یک روش مدیریت موفق برای یک کارمند یک فاجعه واقعی برای دیگری خواهد بود. این فکر اولین مورد در لیست «باید»های مدیر است:
انعطاف پذیر باشید!
فکر کردن به اینکه از قبل همه چیز را می دانید ایده بسیار بدی است. در شرایطی که تنها واقعیت ثابت این است که جهان دائماً در حال تغییر است، انعطاف‌پذیری به تنها موقعیت صحیح تبدیل می‌شود.
به طرز متناقضی، دومین مورد در لیست به طرز شگفت آوری انعطاف ناپذیر است. با این حال، این نکته مورد علاقه شخصی من است زیرا معتقدم به ایجاد پایه ای برای رشد مدیریتی کمک می کند. در این بند آمده است:
نوشتن کد را متوقف کنید!
در تئوری، اگر می‌خواهید یک مدیر باشید، باید یاد بگیرید که به کسانی که برای شما کار می‌کنند اعتماد کنید و کدنویسی را به طور کامل به آنها بسپارید. هضم این توصیه معمولاً دشوار است، مخصوصاً برای مدیران تازه کار. احتمالاً یکی از دلایلی که آنها مدیر شدند، بهره وری آنها در توسعه است، و وقتی همه چیز اشتباه می شود، اولین واکنش آنها این است که به مهارت هایی که به آنها اعتماد کامل دارند، یعنی توانایی آنها در کدنویسی، بازگردند.
وقتی می بینم که یک مدیر تازه کار در نوشتن کد «غرق» می شود، به او می گویم: «ما می دانیم که شما می توانید کد بنویسید. سوال این است: آیا می توانید رهبری کنید؟ شما دیگر به تنهایی مسئول خودتان نیستید، شما مسئول کل تیم هستید. و من می‌خواهم مطمئن شوم که می‌توانید تیمتان را وادار کنید تا مشکلات را خودشان حل کنند، بدون اینکه نیازی به نوشتن کد داشته باشید. وظیفه شما این است که بفهمید چگونه خود را مقیاس بندی کنید. من نمی‌خواهم که تو فقط یکی باشی، می‌خواهم خیلی‌ها مثل تو باشند.»
توصیه خوبی است، درست است؟ مقیاس. مدیریت. مسئوليت. چنین کلمات رایج رایج. حیف که نصیحت اشتباه است.
غلط؟
آره توصیه اشتباه است! کاملاً اشتباه نیست، اما به اندازه کافی اشتباه بود که مجبور شدم با برخی از همکاران سابق تماس بگیرم و عذرخواهی کنم: «آن جمله مورد علاقه من را در مورد اینکه چگونه باید نوشتن کد را متوقف کنید، به خاطر دارید؟ این اشتباه است! بله... دوباره برنامه نویسی را شروع کنید. با پایتون و روبی شروع کنید. بله، جدی می گویم! حرفه شما به آن بستگی دارد!»
زمانی که کارم را به عنوان توسعه‌دهنده نرم‌افزار در Borland شروع کردم، در تیم Windows Paradox کار می‌کردم که تیم بزرگی بود. به تنهایی 13 برنامه نویس وجود داشت. اگر افرادی را از تیم‌های دیگر اضافه کنید که دائماً روی فناوری‌های کلیدی این پروژه مانند موتور پایگاه داده اصلی و خدمات برنامه اصلی کار می‌کردند، 50 مهندس به طور مستقیم در توسعه این محصول مشارکت داشتند.
هیچ تیم دیگری که من تا به حال برای آن کار کرده ام به این اندازه نزدیک نیست. در واقع هر سال که می گذرد به تدریج تعداد افراد تیمی که من روی آن کار می کنم کاهش می یابد. چه خبر است؟ آیا ما توسعه دهندگان در مجموع باهوش تر و باهوش تر می شویم؟ نه، ما فقط بار را به اشتراک می گذاریم.
توسعه دهندگان در 20 سال گذشته چه کار کرده اند؟ در این مدت ما مقدار زیادی کد نوشتیم. دریای رمز! ما آنقدر کد نوشتیم که تصمیم گرفتیم همه چیز را ساده کنیم و به منبع باز برویم.
خوشبختانه، به لطف اینترنت، این روند اکنون تا حد امکان ساده شده است. اگر یک توسعه دهنده نرم افزار هستید، می توانید همین الان آن را بررسی کنید! نام خود را در Google یا Github جستجو کنید، کدی را خواهید دید که مدت هاست آن را فراموش کرده اید، اما هر کسی می تواند آن را پیدا کند. ترسناکه، درسته؟ آیا نمی دانستید که این کد برای همیشه زنده است؟ بله، او برای همیشه زنده است.
رمز برای همیشه زنده است. و کد خوب نه تنها برای همیشه زنده می ماند، بلکه رشد می کند زیرا کسانی که به آن ارزش می دهند دائماً از تازه ماندن آن اطمینان می دهند. این انبوه کد با کیفیت بالا و به خوبی حفظ شده به کاهش میانگین اندازه تیم مهندسی کمک می کند زیرا به ما امکان می دهد به جای نوشتن کد جدید روی کدهای موجود تمرکز کنیم و کار را با افراد کمتر و در بازه زمانی کوتاه تری انجام دهیم.
این خط استدلال ناامید کننده به نظر می رسد، اما ایده این است که همه ما فقط یک دسته اتوماتای یکپارچه هستیم که از نوار چسب برای اتصال قطعات مختلف چیزهای موجود به یکدیگر استفاده می کنیم تا نسخه کمی متفاوت از یک چیز ایجاد کنیم. این یک تفکر کلاسیک در میان مدیران ارشد است که عاشق برون سپاری هستند. هر کسی که می داند چگونه از گوگل استفاده کند و نوار چسب دارد، می تواند این کار را انجام دهد! پس چرا ما پول زیادی به ماشین های خود می پردازیم؟
ما به این مدیران واقعاً پول زیادی می دهیم، اما آنها چنین فکر مزخرفی می کنند. یک بار دیگر، نکته کلیدی من این است که بسیاری از توسعه دهندگان درخشان و بسیار سخت کوش در سیاره ما وجود دارند. آنها واقعاً باهوش و کوشا هستند، اگرچه حتی یک دقیقه را در دانشگاه های معتبر سپری نکرده اند. اوه بله، اکنون تعداد آنها بیشتر و بیشتر شده است!
من به شما پیشنهاد نمی کنم که نگران مکان خود باشید فقط به این دلیل که برخی از رفقای باهوش ظاهراً به دنبال آن هستند. من به شما پیشنهاد می کنم که نگران آن باشید زیرا تکامل توسعه نرم افزار احتمالا سریعتر از شما در حال حرکت است. شما ده سال است که پنج سال از آنها به عنوان مدیر کار می کنید و فکر می کنید: "من قبلاً می دانم که چگونه نرم افزار توسعه می یابد." بله. تو میدانی. خدا حافظ…
نوشتن کد را متوقف کنید، اما ...
اگر توصیه اصلی من را دنبال کنید و نوشتن کد را متوقف کنید، همچنین داوطلبانه شرکت در فرآیند ایجاد را متوقف خواهید کرد. به همین دلیل است که من فعالانه از برون سپاری استفاده نمی کنم. اتومات ها ایجاد نمی کنند، آنها تولید می کنند. فرآیندهایی که به خوبی طراحی شده اند باعث صرفه جویی در هزینه های زیادی می شوند، اما چیز جدیدی به دنیای ما نمی آورند.
اگر تیم کوچکی دارید که کارهای زیادی را برای پول کم انجام می دهد، پس ایده توقف نوشتن کد برای من تصمیم بدی به نظر می رسد. حتی در شرکت‌های هیولا با قوانین، فرآیندها و سیاست‌های بی‌پایان خود، حق ندارید فراموش کنید که چگونه خودتان نرم‌افزار توسعه دهید. و توسعه نرم افزار دائما در حال تغییر است. در حال حاضر در حال تغییر است. زیر پایت! در همین ثانیه!
اعتراض داری فهمیدن. بیا گوش بدهیم.
"رندز، من در حال رفتن به سمت صندلی کارگردان هستم! اگر به نوشتن کد ادامه دهم، هیچ کس باور نمی کند که بتوانم رشد کنم."
من می خواهم این را از شما بپرسم: از زمانی که روی صندلی "من در شرف تبدیل شدن به مدیر عامل هستم!" خود نشسته اید، آیا متوجه شده اید که چشم انداز توسعه نرم افزار در حال تغییر است، حتی در داخل شرکت شما؟ اگر پاسخ شما مثبت است، من یک سوال دیگر از شما می‌پرسم: دقیقاً چگونه تغییر می‌کند و در مورد این تغییرات چه خواهید کرد؟ اگر به سوال اول من "نه" پاسخ دادید، پس باید به صندلی دیگری بروید، زیرا (شرط می‌بندم!) حوزه توسعه نرم‌افزار در همین لحظه در حال تغییر است. اگر به آرامی اما مطمئناً نحوه توسعه نرم افزار را فراموش کنید، چگونه می خواهید رشد کنید؟
توصیه من این است که خود را ملزم به پیاده سازی چندین ویژگی برای محصول بعدی خود نکنید. شما باید دائماً اقداماتی را انجام دهید تا از نحوه ساخت نرم افزار تیم خود مطلع باشید. هم به عنوان مدیر و هم به عنوان معاون می توانید این کار را انجام دهید. یک چیز دیگر؟
«اوه، رندز! اما یک نفر باید داور باشد! کسی باید تصویر بزرگ را ببیند. اگر کد بنویسم، دیدگاه را از دست خواهم داد."
شما هنوز باید داور باشید، هنوز باید تصمیمات را پخش کنید، و هنوز هم باید هر دوشنبه صبح چهار بار با یکی از مهندسان خود در ساختمان قدم بزنید تا به 30 اهنگ هفتگی "ما همه محکومیم" او گوش دهید. دقیقه. ! اما فراتر از همه اینها، شما باید یک ذهنیت مهندسی را حفظ کنید و برای انجام این کار لازم نیست یک برنامه نویس تمام وقت باشید.
نکات من برای حفظ ذهنیت مهندسی:
- از محیط توسعه استفاده کنید. این بدان معنی است که شما باید با ابزارهای تیم خود از جمله سیستم ساخت کد، کنترل نسخه و زبان برنامه نویسی آشنا باشید. در نتیجه، در زبانی که تیمتان هنگام صحبت در مورد توسعه محصول استفاده می کند، مهارت خواهید داشت. این همچنین به شما امکان می دهد به استفاده از ویرایشگر متن مورد علاقه خود که به خوبی کار می کند ادامه دهید.
- شما باید بتوانید نمودار معماری دقیقی را ترسیم کنید که محصول خود را در هر سطحی در هر زمانی توصیف می کند. حالا منظورم نسخه ساده شده با سه سلول و دو فلش نیست. شما باید نمودار دقیق محصول را بدانید. سخت ترین. نه هر نمودار زیبا، بلکه نموداری که توضیح آن سخت است. باید نقشه ای مناسب برای درک کامل محصول باشد. دائماً در حال تغییر است و همیشه باید بدانید که چرا تغییرات خاصی رخ داده است.
- اجرای یکی از توابع را به عهده بگیرید. وقتی این را می نویسم به معنای واقعی کلمه می پیچم زیرا این نقطه خطرات پنهان زیادی دارد، اما واقعاً مطمئن نیستم که بتوانید نقطه 1 و 2 را بدون متعهد به اجرای حداقل یک ویژگی انجام دهید. با پیاده‌سازی یکی از ویژگی‌ها، نه تنها به طور فعال در فرآیند توسعه شرکت می‌کنید، بلکه به شما این امکان را می‌دهد که به طور دوره‌ای از نقش «مدیر مسئول همه چیز» به نقش «مردی که مسئولیت اجرای آن را بر عهده دارد» تغییر دهید. از توابع." این نگرش فروتنانه و بی ادعا اهمیت تصمیمات کوچک را به شما یادآوری می کند.
- هنوز همه جا می لرزم به نظر می رسد که یک نفر از قبل بر سر من فریاد می زند: "مدیری که اجرای عملکرد را به عهده گرفته است؟!" (و من با او موافقم!) بله، شما هنوز مدیر هستید، یعنی باید یک عملکرد کوچک باشد، خوب؟ بله، هنوز کارهای زیادی برای انجام دادن دارید. اگر نمی‌توانید اجرای این تابع را به عهده بگیرید، پس من توصیه‌های پشتیبان‌گیری برای شما دارم: رفع برخی از اشکالات. در این صورت، لذت خلقت را احساس نخواهید کرد، اما درک درستی از نحوه خلق محصول خواهید داشت، به این معنی که هرگز از کار رها نخواهید شد.
- تست های واحد را بنویسید. من هنوز این کار را در اواخر چرخه تولید انجام می دهم، وقتی مردم شروع به دیوانه شدن می کنند. آن را به عنوان یک چک لیست سلامت برای محصول خود در نظر بگیرید. این کار را اغلب انجام دهید.
بازم اعتراض؟
"رندز، اگر کد بنویسم، تیمم را گیج خواهم کرد. آنها نمی‌دانند من کی هستم - مدیر یا توسعه‌دهنده.»
بسیار خوب.
بله گفتم: باشه! خوشحالم که فکر می کنید فقط با شنا در حوضچه توسعه می توانید تیم خود را گیج کنید. ساده است: مرزهای بین نقش های مختلف در توسعه نرم افزار در حال حاضر بسیار مبهم است. دوستان رابط کاربری کاری را انجام می دهند که به طور کلی برنامه نویسی جاوا اسکریپت و CSS نامیده می شود. توسعه دهندگان بیشتر و بیشتر در مورد طراحی تجربه کاربری یاد می گیرند. مردم با یکدیگر ارتباط برقرار می کنند و در مورد اشکالات، در مورد سرقت کد دیگران و همچنین در مورد این واقعیت که هیچ دلیل خوبی برای یک مدیر وجود ندارد که در این اطلاعات عظیم، جهانی و گرده افشانی متقابل شرکت نکند، یاد می گیرند.
علاوه بر این، آیا می خواهید بخشی از یک تیم متشکل از اجزای قابل تعویض باشید؟ این نه تنها تیم شما را زیرک تر می کند، بلکه به هر یک از اعضای تیم این فرصت را می دهد که محصول و شرکت را از دیدگاه های مختلف ببینند. چگونه می توانید به فرانک، مرد آرامی که مسئول ساخت است، بیشتر از دیدن ظرافت ساده فیلمنامه های ساختش احترام بگذارید؟
من نمی خواهم تیم شما گیج و آشفته شود. برعکس، من از تیم شما می خواهم که ارتباط موثرتری برقرار کند. من معتقدم که اگر در ایجاد محصول و کار بر روی ویژگی‌ها مشارکت داشته باشید، به تیم خود نزدیک‌تر خواهید شد. و مهمتر از آن، شما به تغییرات مداوم در فرآیند توسعه نرم افزار در سازمان خود نزدیک خواهید شد.
توسعه را متوقف نکنید
یکی از همکارانم در بورلند یک بار به من حمله کرد که او را "کدگذار" خطاب کرده بودم.
"رندز، رمزگذار یک ماشین بی فکر است! میمون! کدگذار هیچ کار مهمی انجام نمی دهد به جز نوشتن خطوط خسته کننده از کدهای بی فایده. من یک کدنویس نیستم، من یک توسعه دهنده نرم افزار هستم!»
حق با او بود، او از توصیه اولیه من به مدیران اجرایی جدید متنفر بود: "کد نوشتن را متوقف کنید!" نه به این دلیل که پیشنهاد می کنم آنها کدنویس هستند، بلکه بیشتر به این دلیل که به طور فعال پیشنهاد می کنم که شروع به نادیده گرفتن یکی از مهم ترین بخش های شغل خود کنند: توسعه نرم افزار.
بنابراین من توصیه خود را به روز کردم. اگر می خواهید رهبر خوبی باشید، می توانید از نوشتن کد دست بردارید، اما...
انعطاف پذیر باشید. به یاد داشته باشید که مهندس بودن به چه معناست و توسعه نرم افزار را متوقف نکنید.
درباره نویسنده
مایکل لوپ یک توسعه دهنده نرم افزار کهنه کار است که هنوز سیلیکون ولی را ترک نکرده است. در طول 20 سال گذشته، مایکل برای شرکت‌های نوآورانه مختلفی از جمله اپل، نت اسکیپ، سیمانتک، بورلند، پالانتیر، پینترست کار کرده است و همچنین در استارتاپی شرکت کرده است که به آرامی به فراموشی سپرده شد.
خارج از محل کار، مایکل یک وبلاگ پرطرفدار در مورد فناوری و مدیریت با نام مستعار رندز راه‌اندازی می‌کند، جایی که او ایده‌هایی در زمینه مدیریت را با خوانندگان مورد بحث قرار می‌دهد، نگرانی خود را در مورد نیاز دائمی به نگه داشتن انگشت روی نبض ابراز می‌کند، و توضیح می‌دهد که، علی‌رغم پاداش های سخاوتمندانه برای ایجاد یک محصول، موفقیت شما تنها به لطف تیم شما امکان پذیر است. وبلاگ را می توانید در اینجا پیدا کنید .
مایکل با خانواده اش در ردوود، کالیفرنیا زندگی می کند. او همیشه برای دوچرخه سواری در کوهستان، بازی هاکی و نوشیدن شراب قرمز وقت پیدا می کند، زیرا سالم بودن مهمتر از مشغول بودن است.
» جزئیات بیشتر در مورد کتاب را می توانید در اینجا بیابید
»
»
برای Khabrozhiteley 20% تخفیف با استفاده از کوپن - مدیریت افراد
پس از پرداخت وجه نسخه کاغذی کتاب، نسخه الکترونیکی کتاب از طریق ایمیل ارسال خواهد شد.
پ.ن: 7 درصد از قیمت کتاب صرف ترجمه کتاب های کامپیوتری جدید، لیست کتاب های تحویل شده به چاپخانه می شود. .
منبع: www.habr.com