این بلاگ خلاصه‌ای از تجربیات آقای Fergus Henderson هست که بیش از ده سال در گوگل، مهندس نرم افزار است و نشان می‌دهد که چگونه گوگل بازی توسعه نرم افزار را انجام می‌دهد.

گوگل محصولات پیچیده و زیادی دارد مانند Google Search, AdWords, Maps و Android ... اما چگونه این همه محصولات را مدیریت می‌کنند و توسعه می‌دهد؟

ما در این بلاگ سعی می‌کنیم که شیوه‌های مهندسی نرم‌افزار را که در گوگل استفاده می‌شود، بررسی کنیم و ببینیم که گوگل چگونه محصولات نرم افزاری خود را مدیریت می‌کند. دانستن فرآیند‌های یک شرکت موفق مانند گوگل می‌تواند یک معیار ارزیابی خوب برای سازمان‌های دیگر باشد.

یکی از دلایل مهم موفقیت گوگل استفاده از این شیوه‌ها هست، مانند:

· مخزن کد یکپارچه: گوگل تمام کدهای خود را در یک کتابخانه دیجیتالی عظیم نگه می دارد که هر مهندس می تواند به آن دسترسی داشته باشد. این مانند داشتن یک پوشه آنلاین غول پیکر و مشترک برای همه پروژه های Google است که پیدا کردن کد مورد نیاز و کار با آن را برای همه آسان تر می کند.

· سیستم Build معروف به Blaze : آنها از ابزار خاصی به نام Blaze برای انجام کارهای سنگین کامپایل و تست کد استفاده می کنند. Blaze به‌عنوان یک خط مونتاژ تصور کنید که همه نرم‌افزارهایی را که Google می‌سازد کنار هم قرار می‌دهد و بررسی می‌کند و از اجرای روان همه چیز اطمینان می‌دهد.

· بازنگری کد: قبل از اینکه هر کدی بخشی از پروژه های گوگل شود، مهدنس‌های دیگری آن‌ها را به طور کامل بررسی می کنند. این مرحله مطمئن می شود که کد نقص کمی دارد و کار تیمی را ارتقا می دهد.

· تست کردن مداوم: گوگل به جای اینکه منتظر تست همه چیز باشد، دوست دارد نرم افزار خود را اغلب و در قطعات کوچک تست کند. این شبیه به چشیدن سوپ در حین پختن است و در آخر به جای همه چیز، چاشنی را کم کم تنظیم کنید.

· مدیریت پروژه ها و افراد: گوگل روش هوشمندانه ای برای اجرای پروژه ها و مراقبت از مهندسان خود دارد. به عنوان مثال، مهندسان می توانند 20 درصد از زمان خود را صرف هر پروژه ای کنند که به آن علاقه دارند. این آزادی جرقه خلاقیت و ایده های جدید می دهد.

· نرم‌افزار بازنویسی: گوگل به‌جای اینکه به قدیمی‌ها بچسبد، بیشتر نرم‌افزارهای خود را با نیاز‌های جدید و تکنولوژی‌های جدید بازنویسی می‌کند.

1 توسعه نرم افزار

1-1 مخزن کد

بیشتر کد‌های گوگل در یک مخزن قرار دارند و اکثر مهندس‌ها به این مخزن دسترسی دارند.(( داده‌های کاربران کاملا محافظت شده هست، فقط کد‌ها برای مهندس‌ها در دسترس هست)). البته قسمت‌هایی از کد‌ها برای برخی از پروژه‌ها محافظت شده هستند. اما پروژه‌های متن باز مثلا اندروید و کروم کاملا قابل دسترس هستند. . دسترسی نوشتن برای اطمینان از کیفیت کد‌ها کنترل می‌شود، اما فرهنگ به گونه‌ای هست که هر مهندس را تشویق می‌کند تا در پروژه‌های مختلف مشارکت کنند و احساس مسئولیت جمعی برای دارایی‌های نرم‌افزاری شرکت را تقویت کند.

توسعه همیشه روی head یا آخرین ورژن هست نه بر روی برنچ‌ها. این کار مشکلات merg و integrity را کاهش می‌دهد.

سیستم‌های تست خودکار بر روی توسعه‌ها مرتبا در حال اجرا هست.

موضوعات مالکیت کد‌ها هست از این جهت که کاملا مشخص است چه کدی را چه کسی زده است و آن شخص می تواند روی آن قسمت دسترسی‌هایی ایجاد کند و یا تغییری بدهد. این موضوع را در مخزن‌های مدیرت subtreeها می‌گویند و این باعث می‌شود که آن شخصی که تغییری را ایجاد می‌کند همان شخصی هست که بیشترین عمق شناخت از کد را دارد.

1-2 سیستم Build در گوگل

گوگل از یک سیستم ‌build توزیع شده به نام Blaze استفاده می کند تا فرآیند توسعه نرم افزار خود را ساده کند. Blaze عملیات کامپایل، Link، و تست نرم افزار را انجام می دهد و دستورات استانداردی را برای این وظایف در کل مخزن کد Google ارائه می دهد. بهینه‌سازی و یکنواختی آن، مراحل ساخت و تست را برای مهندسان ساده و تسریع می‌کند، و آنها را قادر می‌سازد تا به طور مؤثر روی پروژه‌هایی که فراتر از حوزه کاری خود هستند، کار کنند و در آنها مشارکت کنند. این سیستم یک محیط توسعه مشارکتی و انعطاف پذیر را فراهم کرده است.

در فرآیند توسعه گوگل، برنامه نویسان فایل های “BUILD” را ایجاد می کنند که پیکربندی‌های Blaze است و این سیستم با استفاده از این فایل عملیات Build را انجام می‌دهد. این فایل ها حاوی دستورالعمل های سطح بالا یا "مشخصات ساخت" برای اجزای مختلف نرم افزار مانند کتابخانه ها، برنامه ها و تست ها هستند.

در فرآیندBuild گوگل، هر مرحله Build به گونه‌ای طراحی می‌شود که «hermetic» باشد، به این معنی که صرفاً فقط از ورودی های صراحتاً اعلام شده خود استفاده می کند. این تضمین می کند که سیستم ‌Build به طور دقیق همه وابستگی‌ها را دارد، زیرا تنها ورودی های اعلام شده به ماشینی که Build را انجام می دهد ارائه می شود. این رویکرد به کامپایلرهای مورد استفاده در فرآیند Build، که به عنوان ورودی نیز در نظر گرفته می شوند، گسترش می یابد. این اصل hermetic، قابلیت اطمینان سیستم ‌Build را در مدیریت موثر وابستگی ها تضمین می کند.

سیستم Build گوگل تضمین می کند که هر مرحله Build قطعی است، به این معنی که به طور مداوم خروجی یکسانی را با همان ورودی تولید می کند. این اجازه می دهد تا نتایج Build در کش ذخیره شود، و مهندسان نرم افزار را قادر می سازد تا به نسخه قبلی کار خود بازگردند و دقیقا همان باینری را بازتولید کنند. ماهیت قطعی فرآیند Build همچنین به این معنی است که این نتایج ذخیره شده در کش می توانند به طور ایمن بین کاربران مختلف به اشتراک گذاشته شوند و کارایی و همکاری را افزایش دهند. دستیابی به این امر مستلزم حذف هر چیز رندومی در ابزارهای Build، مانند حذف time stamp از فایل های خروجی برای اطمینان از نتایج ثابت است.

سیستم ‌Build گوگل برای قابلیت اطمینان بالا طراحی شده است و نه تنها تغییرات کد، بلکه تغییرات در قوانین Build را ردیابی می کند. اگر تغییری در نحوه Build چیزی ایجاد شود، مانند تغییر در گزینه های کامپایلر بدون تغییر فایل های ورودی، سیستم به طور خودکار می داند که قسمت های آسیب دیده را بازسازی کند. علاوه بر این، وقفه‌ها را به خوبی مدیریت می کند. اگر یک Build در میانه راه متوقف شد یا اگر فایل ها در طول Build تغییر کردند، به سادگی راه اندازی مجدد دستور Build کافی است. هیچ نیازی به فرآیندهای پاکسازی دستی مانند «make clean» و streamlining development نیست.

سیستم Build گوگل نتایج Build را کش می‌کند و علاوه بر آن نتایج میانی را هم ذخیره می‌کند و در نهایت در فضای ابری ذخیره می‌کند. این راه‌اندازی به آن اجازه می‌دهد تا به طور مؤثر از این نتایج برای درخواست‌های Build بعدی که به نتایج یکسانی نیاز دارند، استفاده مجدد کند و از Rebuild غیرضروری اجتناب کند. این ویژگی به طور کلی اعمال می‌شود، حتی زمانی که درخواست‌هایی از سوی کاربران مختلف ارائه می‌شود، کارایی را افزایش می‌دهد و زمان Build را در سراسر ‍‍‍‍‍‍پروژه کاهش می‌دهد.

عملیات Rebuild تدریجی سریع است. سیستم Build در حافظه باقی می ماند به طوری که برای Rebuild می تواند به صورت تدریجی فقط فایل‌هایی را که از آخرین Build تغییر کرده اند تجزیه و تحلیل کند.

1-3 باز نگری کد در گوگل

گوگل ابزارهای مبتنی بر وب پیشرفته‌ای را برای بررسی کد، توسعه داده است که با ایمیل یکپارچه شده اند و روند بررسی را ساده می کند. این ابزارها با رنگبندی‌هایی که روی متن‌ها ایجاد می‌کنند راحتی کار را برای کسی که بازنگری می‌کند و کسی برنامه نویسی می‌کند فراهم کرده‌اند. وقتی بازنگری (code review) درخواست می‌شود، بازنگر از طریق ایمیل مطلع می‌شوند که یک لینک به تغییر خاص است که در ابزار مشخص است. آنها همچنین پس از ارسال نظرات بررسی، ایمیل را دریافت می کنند. علاوه بر این، سیستم‌های خودکار با ارسال اعلان‌هایی درباره نتایج تست یا یافته‌های ابزارهای تحلیل استاتیک، این فرآیند را بهبود می‌بخشند و یک گردش کار بررسی جامع و کارآمد را ارائه می‌دهند.

فرآیند‌های Google موظف می‌کند که هر تغییری که در مخزن کد اصلی ایجاد می‌شود، توسط حداقل یک مهندس دیگر برای تضمین کیفیت بررسی شود. علاوه بر این، اگر شخصی که تغییر را انجام می‌دهد مالک فایل‌های در حال تغییر نیست، حداقل یکی از صاحبان فایل باید اصلاحات را بررسی و تأیید کند و اطمینان حاصل کند که تغییرات توسط کسانی که بیشتر با محتوا آشنا هستند نظارت می‌شوند.

در شرایط اضطراری، صاحب کد می‌تواند تغییراتی را در بخش مخزن خود بدون بررسی قبلی انجام دهد. با این حال، باید یک بازنگر به آن تغییر اختصاص داده شود و تا زمانی که تغییر، بررسی و تایید نشود، هم فرد تغییر دهنده و هم بازنگر، یادآوری دریافت خواهند کرد. اگر بازنگر مشکلاتی را شناسایی کرد، هر گونه اصلاحات لازم باید از طریق ارسال جدید انجام شود، زیرا تغییر اولیه قبلاً در پایگاه کد ادغام شده است.

گوگل از ابزارهای خودکار برای توصیه به بازنگران احتمالی برای تغییرات کد استفاده می‌کند، بر اساس عواملی مانند مالکیت کد، نویسنده، سابقه افرادی که تغییرات مشابه را بررسی کرده‌اند، و حجم کار بررسی فعلی هر نامزد. در حالی که حداقل یکی از مالکان ناحیه کد تحت تأثیر این تغییر باید آن را تأیید کند، نویسنده این امکان را دارد که بازنگر‌های دیگری را بر اساس اولویت خود انتخاب کند.

چالشی که در فرآیند بررسی کد وجود دارد، احتمال تأخیر در صورت کندی بازنگران در تأیید تغییرات است که می تواند توسعه را کند کند. با این حال، گوگل با فراهم کرده اجازه‌هایی برای برنامه نویس، این مشکل را کاهش می دهد. این انعطاف‌پذیری به مهندسان اجازه می‌دهد تا بازنگر‌هایی را انتخاب کنند که بسته به پیچیدگی تغییر، سریع‌تر و مناسب‌تر پاسخ دهند، در نتیجه سرعت توسعه را با دوری از بازنگر‌های بیش از حد محتاط یا صاحب نظر برای به‌روزرسانی‌های ساده، حفظ کرده و بازنگر‌های با تجربه‌تر را برای تغییرات پیچیده انتخاب کنند.

گوگل به طور خودکار بحث‌های بازنگری کد پروژه‌ها را به لیست ایمیل خاصی که توسط نگهدارند‌های پروژه مدیریت می شود ارسال می کند. این راه‌اندازی به هر کسی اجازه می‌دهد تا در هر زمانی قبل یا بعد از ایجاد تغییر، بدون توجه به نقش رسمی خود به‌عنوان بازنگر، درباره هر تغییر پیشنهادی نظر دهد. اگر یک اشکال بعداً شناسایی شود، این یک روش معمول است که تغییری را که باعث آن شده است پیدا کنند و در موضوع بررسی اصلی اظهار نظر کنند. این تضمین می کند که هم شخصی که تغییر را ایجاد کرده و هم بازنگران در مورد موضوع برای ارجاع و یادگیری در آینده مطلع می شوند.

گوگل اجازه می‌دهد تغییرات کد توسط چندین نفر بررسی شود و به محض اینکه یک بازنگر، که باید مالک یا نویسنده باشد، آن را تأیید کند، اجازه می‌دهد تغییر انجام شود. این فرآیند می‌تواند حتی قبل از اینکه دیگر بازبینان بازخورد خود را ارائه دهند، رخ دهد. هر گونه نظر اضافی از بازبینان را می توان در به روز رسانی های بعدی بررسی کرد. این رویکرد به سرعت بخشیدن به روند بررسی با اجازه دادن به تأییدها و تنظیمات سریعتر بر اساس بازخورد کمک می کند.

مخزن Google شامل یک بخش "تجربه" است که در آن قوانین سختگیرانه بررسی کد اعمال نمی شود. با وجود این، برای استفاده از کد در production، باید در بخش اصلی مخزن قرار گیرد. مهندسان به شدت تشویق می شوند که از همان ابتدا در بخش اصلی کار کنند و تأکید می کنند که بررسی کد در طول توسعه به جای بعد از آن سودمندتر است. با این وجود، معمولاً مهندسان به دنبال بررسی برای کار در بخش آزمایشی هستند و به بهترین شیوه ها برای تضمین کیفیت پایبند هستند.

گوگل مهندسان خود را تشویق می‌کند تا تغییرات کوچک و قابل مدیریتی در کد ایجاد کنند، و پیشنهاد می‌کند که به‌روزرسانی‌های بزرگ‌تر باید به قطعات کوچک‌تر و قابل بررسی‌تر تقسیم شوند. این رویکرد نه تنها فرآیند بررسی را تسهیل می‌کند، بلکه به نویسندگان اجازه می‌دهد تا بازخورد را با سهولت بیشتری اجرا کنند. برای ترویج این عمل، ابزارهای بررسی کد گوگل تغییرات را بر اساس اندازه طبقه‌بندی می‌کنند، با برچسب‌هایی از «medium-size» برای تغییراتی که بر 30 تا 99 خط تأثیر می‌گذارند تا توصیف‌کننده‌هایی مانند «large» یا «freakin huge» برای تغییرات اساسی‌تر. این سیستم، در حالی که کاربردی است، اما با گیمیفیکیشن‌های خاصی به فرآیند‌ها تزریق می‌شود.

1-4 تست

گوگل تاکید زیادی بر تست واحد دارد و انتظار دارد تمام کدهای production با تست های واحد همراه باشد. ابزارهای بازبینی کد به طور خودکار هر فایل منبع جدیدی را که فاقدunit test است علامت گذاری می کند. بررسی‌کنندگان معمولاً اصرار دارند که هرگونه افزودن ویژگی‌های جدید با تست‌های جدید تطبیق داده شود تا اطمینان حاصل شود که عملکرد همانطور که در نظر گرفته شده است کار می‌کند. برای راحت کردن تست، حتی برای کدهایی که به کتابخانه های پیچیده وابسته هستند، مهندسان گوگل اغلب از mocking frameworks استفاده می کنند که امکان ایجاد تست های کارآمد و سبک را فراهم می کند.

تست یکپارچه سازی و تست رگرسیون نیز به طور گسترده انجام می شود.

گوگل همچنین ابزارهای خودکاری برای اندازه گیری test coverage دارد. نتایج همچنین به عنوان یک لایه اختیاری در مرورگر کد یکپارچه شده است.

گوگل قبل از استقرار نرم‌افزار، تست load را الزامی می‌کند و تیم‌ها را ملزم می‌کند تا نحوه عملکرد سیستم در شرایط فشار مستند کنند. این شامل تولید داده‌هایی مانند جداول یا نمودارها است که شاخص‌های عملکرد کلیدی مانند تاخیر و نرخ خطا را در پاسخ به سطوح مختلف درخواست‌های کاربر نشان می‌دهند. این عمل تضمین می کند که سیستم ها در شرایط دنیای واقعی قوی و قابل اعتماد هستند.

1-5 ردیابی bug

گوگل از یک ابزار ردیابی bugبه نام Buganizer برای مدیریت مسائل مختلف از جمله bug، درخواست‌های featureو مشکلات مشتری، در کنار ردیابی انتشار و عملیات پاکسازی استفاده می‌کند. مشکلات موجود در Buganizerبه دسته‌هایی با قابلیت تخصیص کنترل‌کننده‌های پیش‌فرض و اطلاع دادن به اشخاص مربوطه از طریق ایمیل، سازمان‌دهی شده‌اند. مهندسان تشویق می شوند تا هرگونه تغییر کد ارائه شده برای بررسی را به versionهای خاص مرتبط کنند و ردیابی و حل مشکل سازمان یافته و کارآمد را تسهیل کنند و کاملا بفهمند که چه bugای در چه نسخه‌ای بوده و در چه وضعیتی هست.

1-6 زبان‌های برنامه نویسی

مهندسان نرم افزار در گوگل به شدت تشویق می شوند که به یکی از پنج زبان برنامه نویسی رسمی تایید شده در گوگل برنامه نویسی کنند: C++، Java، Python، Go یا JavaScript. به حداقل رساندن تعداد زبان های برنامه نویسی مختلف استفاده شده، موانع استفاده مجدد از کد و همکاری برنامه نویس را کاهش می دهد.

گوگل برای اطمینان از سازگاری در code style، طرح‌بندی، و قراردادهای نام‌گذاری، راهنماهایی را برای زبان‌های برنامه‌نویسی مختلف حفظ می‌کند. علاوه بر این، گوگل یک برنامه آموزشی خوانایی کد را اجرا کرده است که در آن مهندسان با تجربه دیگران را در نوشتن کد واضح راهنمایی می کنند. این شامل بررسی تغییرات قابل توجه کد است تا زمانی که مربی از توانایی مربی در نوشتن کد قابل خواندن مطمئن شود. هر کد جدید قابل توجهی باید تاییدیه شخصی دریافت کند که استانداردهای خوانایی زبان را تایید کرده است و اهمیت کد واضح و قابل نگهداری را تقویت می کند.

گوگل ارتباط بین زبان های برنامه نویسی مختلف را عمدتاً از طریق Protocol Buffers تسهیل می کند، روشی برای رمزگذاری موثر داده های ساختاریافته. بافرهای پروتکل شامل یک زبان تخصصی برای تعریف ساختارهای داده و یک کامپایلر است که کدی را برای مدیریت این ساختارهای داده در C++، جاوا و پایتون تولید می کند. این سیستم، که با کتابخانه‌های (RPC) Google یکپارچه شده است، به RPC‌های چندزبانه ساده اجازه می‌دهد تا به‌طور خودکار سریال‌سازی و سریال‌زدایی داده‌ها را در محیط‌های برنامه‌نویسی مختلف مدیریت کنند.

گوگل فرآیند توسعه نرم افزار خود را با استفاده از مجموعه ای یکپارچه از دستورات برای وظایف مهندسی رایج در پایگاه کد گسترده و زبان های برنامه نویسی مختلف ساده می کند. این استانداردسازی به این معنی است که توسعه‌دهندگان می‌توانند بدون توجه به پروژه یا زبانی که با آن کار می‌کنند check out, edit, build, test, review, commit و گزارش باگ را با استفاده از دستورات مشابه انجام دهند. در نتیجه، توسعه دهندگان می توانند به راحتی بین پروژه ها بدون نیاز به یادگیری فرآیندهای جدید جابجا شوند و کارایی و سادگی در کار توسعه را افزایش دهند.

1-7 رفع اشکال و ابزار‌های profiling

گوگل اشکال زدایی سرور را با کتابخانه های مجهز به ابزارهایی که ثبت و تجزیه و تحلیل خطا را خودکار می کند، افزایش می دهد. در صورت خرابی سرور، این ابزارها به‌طور خودکار گزارش‌های خطا، از جمله stack tracesو core files را ضبط و ثبت می‌کنند. آنها همچنین می توانند مسائلی مانند سرریز حافظه را با logging the memory allocation at fault در خطا شناسایی کنند. به‌علاوه، Google رابط‌های وب را برای اشکال‌زدایی عمیق ارائه می‌کند، اطلاعاتی در مورد ارتباطات سرور، معیارهای عملکرد، و استفاده از منابع سیستم ارائه می‌دهد. این قابلیت‌ها امکان تنظیمات دقیق و عیب‌یابی را فراهم می‌کنند، و اغلب نیاز به روش‌های عیب‌یابی سنتی مانند استفاده از gdb را از بین می‌برند، بنابراین فرآیند اشکال‌زدایی را به طور قابل توجهی ساده می‌کنند.

1-8 مهندسی انتشار یا Release engineerin

برای انتشار چندین مهندس متخصص مجزا وجود دارد، اما برای اکثر تیم‌های گوگل، کار مهندسی انتشار توسط مهندسان نرم‌افزار معمولی انجام می‌شود.

هدف گوگل، انتشار نرم‌افزارهای مکرر - هفتگی، دو هفته‌ای یا حتی روزانه برای برخی تیم‌ها - از طریق اتوماسیون گسترده فرآیندهای انتشار است. این چرخه انتشار سریع، انگیزه مهندس را افزایش می دهد و با فعال کردن تکرارهای بیشتر سرعت توسعه را تسریع می کند. انتشار مکرر به معنای فرصت های بیشتر برای بازخورد و پاسخ به موقع به آن بازخورد است که کیفیت و ارتباط نرم افزار را افزایش می دهد.

فرآیند انتشار گوگل با راه‌اندازی یک فضای کاری جدید و استفاده از آخرین buildهای مطمئن به عنوان پایه برای ایجاد release branch آغاز می‌شود. سپس مهندس انتشار ممکن است به روز رسانی های خاصی را برای گنجاندن در این branch انتخاب کند. در ادامه این نرم افزار به صورت جامع بازسازی و تست می شود. اگر هر مشکلی شناسایی شود، برطرف می‌شود و به‌روزرسانی‌ها به branchانتشار اضافه می‌شوند و سپس یک دور دیگر build و آزمایش انجام می‌شود. این چرخه تا زمانی ادامه می‌یابد که نرم‌افزار تمام تست‌ها را پشت سر بگذارد و در این مرحله برای انتشار پکیج می‌شود. این فرآیند تا حد زیادی خودکار است و به مهندس انتشار اجازه می‌دهد آن را با دستورات ساده یا از طریق یک رابط کاربر پسند مدیریت کند و آماده‌سازی انتشار را ساده‌تر کند.

هنگامی که یک build کاندید پکیج شد، معمولاً برای تست یکپارچه سازی بیشتر توسط مجموعه کوچکی از کاربران (گاهی اوقات فقط تیم توسعه) روی یک سرور "stage" بارگذاری می شود.

تکنیکی که توسط Google به کار می‌رود شامل mirror کردن بخشی از درخواست‌های کاربران live به یک سرور stage است، در حالی که درخواست‌های واقعی توسط سرورهای productionپردازش می‌شوند. پاسخ‌های سرور stageاستفاده نمی‌شود، اما این راه‌اندازی به Google اجازه می‌دهد تا بررسی کند که چگونه محیط استیجینگ، ترافیک واقعی را مدیریت می‌کند. این روش به شناسایی و حل مشکلات احتمالی، مانند خرابی سرور، در مرحله قبل از تأثیرگذاری بر محیط تولید کمک می‌کند و از ثبات و قابلیت اطمینان در استقرارهای زنده اطمینان می‌دهد.

پس از تست اولیه، گوگل معمولاً به استقرار به‌روزرسانی‌ها روی سرورهای «قناری» می‌رود که ترافیک واقعی کاربر را در مقیاس کوچک‌تر مدیریت می‌کنند. این مرحله امکان آزمایش مستقیم تغییرات را با کاربران واقعی فراهم می‌کند، اما تأثیر بالقوه را محدود می‌کند. در صورت موفقیت آمیز بودن، به‌روزرسانی به تدریج در طول چند روز در تمام سرورهای مراکز داده، به‌ویژه برای سرویس‌های حیاتی ارائه می‌شود. این رویکرد مرحله‌ای با هدف به حداقل رساندن اختلالات ناشی از باگ‌های کشف‌نشده احتمالی، تضمین انتقال روان به نسخه جدید است.

1-9 تایید راه اندازی

قبل از اینکه Google بتواند تغییرات قابل مشاهده برای کاربران یا به‌روزرسانی‌های قابل توجه طراحی را منتشر کند، این تغییرات باید توسط سهامداران مختلف فراتر از تیم مهندسی اصلی تأیید شود. این فرآیند بررسی کامل، انطباق با استانداردهای قانونی، حریم خصوصی، امنیت، و قابلیت اطمینان و سایر الزامات را تضمین می کند. این شامل بررسی های مربوط به پایبندی به اهداف تجاری و گنجاندن مکانیسم هایی مانند نظارت خودکار برای مسائلی مانند قطع شدن سرور است، اطمینان از اینکه به روز رسانی قوی و مطابق با سیاست های شرکت و انتظارات کاربر است.

گوگل از یک ابزار داخلی تخصصی برای مدیریت و پیگیری فرآیند بررسی و تأیید برای راه اندازی محصول استفاده می کند. این ابزار تضمین می‌کند که هر محصول به رویه‌های راه‌اندازی خاص خود، از جمله بررسی‌های انطباق و تأییدیه‌ها پایبند است. به گونه‌ای طراحی شده است که انعطاف‌پذیر باشد و امکان سفارشی‌سازی برای نیازهای مختلف محصولات یا مناطق مختلف را فراهم کند، بنابراین فرآیند راه‌اندازی را ساده‌تر می‌کند و در عین حال استانداردهای بالایی را برای هر نسخه حفظ می‌کند.

1-10 پس از فاجعه یا مرگ (Post-mortems)

پس از یک قطعی یا مشکل قابل توجه در سیستم های production، پرسنل درگیر باید یک سند Post-mortems جمع آوری کنند. این گزارش جزئیات این حادثه را شامل ماهیت، اثرات، توالی رویدادها، علل ریشه‌ای و پاسخ‌های مؤثر و غیرمؤثر آن است. تاکید بر درک موضوع و راهبردهای پیشگیری، اجتناب از سرزنش شخصی است. با اندازه‌گیری زمان خرابی، اختلالات خدمات و پیامدهای مالی، تأثیر قطعی را ارزیابی می‌کند. این سند همچنین جدول زمانی حادثه را از شروع تا حل مشخص می کند و ارزیابی می کند که چه اقداماتی در رسیدگی به مشکل موفق بوده یا نه. درس‌های آموخته‌شده برای راهنمایی بهبودهای آینده و به حداقل رساندن بازگشت، با اقدامات بعدی خاص برای رفع کاستی‌های شناسایی‌شده مشخص می‌شوند.

1-11 بازنویسی های مکرر

گوگل به طور مکرر نرم افزار خود را به روز می کند، معمولاً هر چند سال یک بار آن را بازنویسی می کند تا اطمینان حاصل کند که با پیشرفت های تکنولوژیکی و نیازهای در حال تکامل کاربر مطابقت دارد.

در حالی که بازنویسی منظم نرم افزار بخش قابل توجهی از منابع Googleرا مصرف می کند، این استراتژی است که مزایای کلیدی را برای چابکی و موفقیت پایدار شرکت ارائه می دهد. با تکامل فناوری و نیازهای کاربر، نیازهای نرم افزار تغییر می کند و برنامه های قدیمی را کارآمدتر یا مرتبط تر می کند. نرم‌افزار بازنویسی نه تنها پیچیدگی‌های قدیمی را حذف می‌کند، بلکه پایگاه کد را نیز جوان‌سازی می‌کند و اطمینان می‌دهد که نیازهای فعلی را برآورده می‌کند. این فرآیند همچنین اعضای جدیدتر تیم را درگیر می‌کند و حس مالکیت و بهره‌وری را القا می‌کند، زیرا مهندسان انگیزه بیشتری برای کار روی کدهایی دارند که آنها را متعلق به خود می‌دانند. به‌علاوه، بازنویسی‌های مکرر محیطی پویا را ایجاد می‌کند که در آن مهندسان بین پروژه‌ها حرکت می‌کنند، تبادل ایده‌ها را ترویج می‌کنند و اطمینان می‌دهند که نرم‌افزار Google از آخرین پیشرفت‌ها و روش‌های فناوری استفاده می‌کند.

2 مدیریت پروژه

2-1 بیست درصد زمان

گوگل به مهندسان اجازه می‌دهد تا ۲۰ درصد از زمان خود را به پروژه‌های مورد نظر خود اختصاص دهند و فرهنگ اعتماد و نوآوری را تقویت کنند. این سیاست مزایای متعددی دارد: کاوش و توسعه ایده‌های جدیدی را که در غیر این صورت ممکن است مورد توجه قرار نگیرند را امکان‌پذیر می‌سازد، شفافیت پروژه‌های نوآورانه را برای مدیریت تضمین می‌کند، با اجازه دادن به مهندسان برای کار بر روی پروژه‌های پرشور در کنار وظایف معمول، از فرسودگی جلوگیری می‌کند و به طور قابل توجهی بهره‌وری و انگیزه را افزایش می‌دهد. علاوه بر این، این روش فرهنگ نوآوری را در شرکت ترویج می کند، زیرا مهندسان از دیدن همکاران خود در پروژه های خلاقانه و تجربی الهام می گیرند. به طور کلی، قانون 20 درصد یک رویکرد استراتژیک برای پرورش استعدادها و تشویق نوآوری مستمر در گوگل است.

2-2 اهداف و نتایج کلیدی (OKR)

در Google، افراد و تیم‌ها موظف هستند اهداف روشنی را تعیین و مستند کنند، سپس پیشرفت خود را به سمت این اهداف از طریق اهداف فصلی و سالانه دنبال کنند. این اهداف با نتایج کلیدی قابل اندازه‌گیری و همسویی با اهداف گروهی و کلی شرکت، کمیت می‌شوند. پیشرفت در پایان هر کوارتر ارزیابی می شود و هر گل در مقیاسی از 0.0 تا 1.0 به ثمر می رسد که نشان دهنده میزان تکمیل است. اگرچه این اهداف و نتایج کلیدی (OKR) و امتیازات آن‌ها عموماً در گوگل شفاف هستند، اما مستقیماً برای ارزیابی عملکرد استفاده نمی‌شوند. این سیستم همسویی اهداف را در سطوح مختلف سازمان تضمین می کند و فرهنگ مسئولیت پذیری و پیگیری پیشرفت را ترویج می کند.

رویکرد گوگل برای تعیین اهداف و نتایج کلیدی (OKR) از هدف گذاری جاه طلبانه با هدف میانگین نمره ایده آل 65 درصد حمایت می کند. این تیم ها را تشویق می کند تا حدود 50٪ بیشتر از آنچه که ممکن است به طور واقعی به آن دست یابند، کارهایی را هدف قرار دهند. تیم هایی که از این هدف بهتر عمل می کنند، انگیزه بیشتری برای هدف گذاری در سه ماهه بعدی دارند، در حالی که به آنهایی که امتیازهای زیر را کسب می کنند، توصیه می شود OKRخود را طوری تنظیم کنند که دست یافتنی تر باشد و از تعادل بین جاه طلبی و عملی بودن در هدف گذاری اطمینان حاصل کنند.

موضوع OKRها در Googleبه عنوان ابزاری حیاتی برای ترسیم و انتقال اهداف در سراسر شرکت عمل می‌کنند و فرهنگ عملکرد بالا را از طریق مشوق‌های اجتماعی پرورش می‌دهند. اگرچه OKRها مستقیماً بر بررسی عملکرد یا جبران خسارت تأثیر نمی‌گذارند، آگاهی از اینکه دستاورد آنها در جلسات تیم بررسی و امتیازدهی می‌شود، مهندسان را برای برتری انگیزه می‌دهد. با تنظیم نتایج کلیدی واضح، عینی و قابل اندازه‌گیری، OKRها تمایل کارکنان را برای عملکرد خوب به سمت فعالیت‌هایی هدایت می‌کنند که به‌طور محسوسی اهداف جمعی شرکت را پیش می‌برد و اطمینان حاصل می‌کند که تلاش‌ها همسو و تاثیرگذار هستند.

2-3 تایید پروژه

در حالی که گوگل فرآیند روشنی برای تایید راه اندازی دارد، این شرکت فاقد یک سیستم یکسان برای تایید یا لغو پروژه ها است. تصمیم گیری در سازمان متفاوت است و مدیران در سطوح مختلف در مورد پروژه های تیم خود صلاحدید خود را اعمال می کنند. در برخی موارد، تصمیمات پروژه از پایین به بالا گرفته می شود و به مهندسان امکان می دهد پروژه های خود را انتخاب کنند. برعکس، در سناریوهای دیگر، تصمیمات از بالا به پایین است و مدیران یا مدیران جهت پروژه، تخصیص منابع و لغو را تعیین می کنند. این انعطاف پذیری در مدیریت پروژه نشان دهنده رویکرد متنوع گوگل به نوآوری و نظارت بر پروژه است.

2-4 سازماندهی مجدد شرکت ها

در Google، تصمیمات اجرایی می‌تواند منجر به لغو پروژه‌های بزرگ یا ادغام پروژه‌های پراکنده جغرافیایی شود و مهندسان را ملزم به یافتن نقش‌ها یا تیم‌های جدید کند. در طول چنین سازمان‌دهی‌هایی، مهندسان معمولاً این آزادی را دارند که موقعیت‌های جدید را در محل خود انتخاب کنند یا در موارد ادغام، گزینه جابجایی برای ادامه تیم فعلی خود را دارند. سازمان‌دهی مجدد شرکت‌ها، از جمله ادغام یا تقسیم تیم‌ها و تغییرات در ساختارهای گزارش‌دهی، در Google نسبتاً رایج هستند. این تنظیمات برای حفظ کارایی و انطباق با فناوری‌ها و الزامات در حال تحول ضروری تلقی می‌شوند، با هدف جلوگیری از تأثیرگذاری بیش از حد ساختار سازمان بر طراحی و عملکرد محصولاتش.

2-5 هفته‌های hackسالانه

گوگل با میزبانی سالانه hackathons یک هفته ای، نوآوری را تقویت می کند و به مهندسان اجازه می دهد از وظایف معمول خود برای توسعه پروژه های جدید منحرف شوند. این رویدادها با جلسه ای شروع می شوند که در آن ایده ها مطرح می شوند و منجر به تشکیل تیم‌هایی می شود که روی ایجاد دمو یا نمونه های اولیه کار می کنند. نقطه اوج هفته یک جلسه ارائه است که در آن پروژه‌ها به نمایش گذاشته می‌شوند و جوایز کوچکی اعطا می‌شوند، اگرچه بزرگترین پاداش این است که یک پروژه hackathonsبه یک پروژه در مقیاس کامل تبدیل شود. علیرغم تشویق رسمی، مشارکت واقعی به دلیل تقاضاهای شغلی روزانه نسبتاً کم است، با 5 تا 20٪ از مهندسان شرکت می کنند، اگرچه بسیاری دیگر به ارائه های اولیه و پایانی علاقه نشان می دهند و از نوآوری های نمایش داده شده الهام می گیرند.

3 مدیریت افراد

3-1 نقش‌ها

گوگل مسیرهای شغلی متمایزی برای مهندسی و مدیریت دارد که به وضوح نقش رهبران فناوری را از مدیران متمایز می کند. این ساختار همچنین تحقیقات را مستقیماً در تیم‌های مهندسی ادغام می‌کند و از طریق نقش‌هایی مانند مدیران محصول، مدیران پروژه، و مهندسین قابلیت اطمینان سایت (SREs)، پشتیبانی جامع را فراهم می‌کند و فرهنگ قوی نوآوری را تقویت می‌کند. در حوزه مهندسی، گوگل نقش‌های مختلفی را ارائه می‌کند که هر کدام دارای یک پیشرفت شغلی تعریف‌شده، از جمله سطوح متعدد و فرصت ارتقاء هستند، که با مزایایی مانند افزایش حقوق همراه است. این رویکرد شناخت عملکرد را تضمین می کند و از توسعه شغلی در شرکت پشتیبانی می کند.

نقش‌های اساس عبارتند از:

3-1-1 مدیر مهندسان یا Engineering Manager

مدیران مهندسی در گوگل، اغلب با پیشینه مهندسان نرم افزار، نقش اصلی مدیریت افراد در شرکت را تشکیل می دهند که دارای مهارت های فنی و بین فردی هستند. برخلاف مدیران فنی، که بر هدایت جهت فنی پروژه ها تمرکز می کنند، مدیران مهندسی بیشتر درگیر مدیریت افراد از جمله انتخاب رهبران فنی، نظارت بر عملکرد تیم، مربیگری، توسعه شغلی، ارزیابی عملکرد و جنبه های پاداش و استخدام هستند. به طور معمول، یک مدیر مهندسی بر 3 تا 30 نفر نظارت می کند که 8 تا 12 نفر رایج ترین محدوده هستند. این تعیین تمایز واضح بین توسعه پروژه پیشرو و پویایی تیم مدیریت را تضمین می کند.

3-1-2 مهندسان نرم افزار یا (SWE)

نقش مهندس نرم‌افزار در میان کسانی که توسعه نرم‌افزار را در گوگل انجام می‌دهند رایج‌ترین نقش است، جایی که معیارهای انتخاب به‌طور مشخص برای اطمینان از خروجی‌های با کیفیت بالا و مشکلات نرم‌افزاری کمتری سخت‌گیرانه هستند. Googleمسیرهای شغلی متمایزی را برای مهندسی و مدیریت حفظ می‌کند و به مهندسان نرم‌افزار اجازه می‌دهد بدون اینکه لزوماً نقش‌های مدیریت افراد را بر عهده بگیرند، پیشرفت کنند. رهبری در سطوح ارشد به طور گسترده تعریف شده است، از جمله کمک های قابل توجهی به توسعه نرم افزار، افراد با تخصص فنی قوی اما تمایل کمتری به مدیریت را قادر می سازد تا شغل خود را ارتقا دهند. این رویکرد از سناریویی که اغلب در سازمان‌های دیگر دیده می‌شود، جلوگیری می‌کند، که در آن افراد نقش‌های مدیریتی را صرفاً برای پیشرفت شغلی دنبال می‌کنند و این امر به‌طور بالقوه به قیمت از دست دادن رهبری مؤثر تیم انجام می‌شود.

3-1-3 محققان یا Research Scientist

گوگل استانداردهای استخدامی بسیار بالایی را برای نقش دانشمند پژوهشی تعیین می کند و نه تنها به یک سابقه اثبات شده در تحقیقات، همانطور که توسط انتشارات نشان داده شده است، بلکه همچنین مهارت کدنویسی را می طلبد. علیرغم واجد شرایط بودن بسیاری از دانشگاهیان برای موقعیت های مهندسی نرم افزار، همه نمی توانند معیارهای یک دانشمند پژوهشگر در گوگل را برآورده کنند. دانشمندان پژوهشگر و مهندسان نرم افزار در گوگل در حالی که عناوین متمایز دارند، مسئولیت های زیادی از جمله انجام تحقیقات اصلی، توسعه فناوری های جدید و نوشتن کد را به اشتراک می گذارند. این همکاری که اغلب روی پروژه‌های مشابهی با هم کار می‌کنند، ادغام یکپارچه تحقیقات نوآورانه را در محصولات کاربردی و آماده بازار تسهیل می‌کند، که نمونه‌ای از رویکرد Googleبرای ترکیب تحقیقات با مهندسی است.

3-1-4 مهندسان اطمینان سایت یا Site Reliability Engineer

در Google، تعمیر و نگهداری سیستم‌های عملیاتی توسط تیم‌های مهندسی نرم‌افزار به جای مدیران سیستم سنتی انجام می‌شود و مهندسان قابلیت اطمینان سایت (SRE) نقش کلیدی را ایفا می‌کنند. معیارهای موقعیت‌های SREبا معیارهای مهندسین نرم‌افزار کمی متفاوت است و به طیف وسیع‌تری از تخصص اجازه می‌دهد. در حالی که سطح مهارت مهندسی نرم افزار مورد نیاز برای SRE ها ممکن است انعطاف پذیرتر باشد، این می تواند با دانش قوی در زمینه هایی مانند شبکه یا سیستم یونیکس متعادل شود. مشخصات نقش SRE و اهمیت آن به طور گسترده در کتاب SREشرح داده شده است و عملکرد مهم آن را در چارچوب عملیاتی Google برجسته می کند.

3-1-5 مدیر محصول

مدیران محصول در گوگل نقش مهمی در نظارت بر توسعه و مدیریت محصولات دارند. آنها در نقش حامیان کاربر، مهندسان نرم‌افزار را با اولویت‌بندی ویژگی‌ها، همکاری با تیم‌های دیگر، مدیریت باگ‌ها و زمان‌بندی‌ها، و اطمینان از در دسترس بودن تمام منابع لازم برای ایجاد محصولات با کیفیت بالا راهنمایی می‌کنند. در حالی که معمولاً در کدنویسی دخالتی ندارند، مدیران محصول از نزدیک با مهندسان کار می کنند تا اطمینان حاصل کنند که توسعه با دیدگاه محصول و نیازهای کاربر همسو است.

3-1-6 مدیر برنامه یا برنامه فنی Program Manager / Technical Program Manager

مدیران برنامه در Google، دقیقاً مانند مدیران محصول، به جای خود محصولات، بر اجرای پروژه‌ها، فرآیندها یا عملیات نظارت می‌کنند و بر جنبه‌هایی مانند جمع‌آوری داده‌ها تمرکز می‌کنند. مدیران برنامه های فنی، زیرمجموعه ای از این نقش، با نیازشان به مهارت های فنی خاص مرتبط با پروژه هایشان، مانند تخصص زبان شناسی برای پروژه های داده گفتاری، متمایز می شوند. نسبت مهندسان نرم‌افزار به مدیران محصول و برنامه در Googleنسبتاً بالا است، معمولاً از 4:1 تا 30:1 متغیر است، که نشان‌دهنده تأکید شدید بر مهندسی در چارچوب مدیریت پروژه و محصول شرکت است.

4 امکانات

محل کار Google به گونه ای طراحی شده است که هم سرگرم کننده و هم کاربردی باشد و دارای امکاناتی مانند سرسره، گودال توپ، اتاق بازی، کافه رایگان، و «میکرو آشپزخانه» است که تنقلات و نوشیدنی های رایگان ارائه می دهد که به جذب و حفظ استعدادها کمک می کند. این فضاها نه تنها کارمندان را تشویق می کنند که مدت بیشتری در محل کار بمانند، بلکه تعاملات غیررسمی و اشتراک ایده را نیز تقویت می کنند. امکانات اضافی مانند سالن های ورزشی، ورزش، و خدمات ماساژ باعث ارتقای سلامت و شادی، افزایش بهره وری و حفظ کارمندان می شود. طرح دفتر برای تسهیل ارتباطات، علیرغم تأثیرات بالقوه بر تمرکز، طرح باز است. صندلی‌ها اختصاص داده می‌شوند، اما اغلب برای تشویق تعامل‌های جدید تغییر می‌کنند. علاوه بر این، اتاق‌های جلسه مجهز به فناوری کنفرانس ویدیویی پیشرفته برای ارتباط یکپارچه هستند که نشان‌دهنده تعهد Google به یک محیط کاری مشترک و نوآور است.

4-1 آموزش

گوگل تاکید زیادی بر آموزش کارکنان دارد و فرصت‌های یادگیری مختلف و ساختارهای پشتیبانی را برای نیروی کار خود فراهم می‌کند. این شامل آموزش اجباری برای استخدام‌های جدید، معروف به "Nooglers" و "Codelabs" برای کارکنان فنی است تا از طریق دوره‌های آنلاین مختصر، در مورد فناوری‌های خاص بیاموزند. علاوه بر این، Google طیف گسترده‌ای از دوره‌های آموزشی آنلاین و حضوری را ارائه می‌دهد و از آموزش‌های بیشتر در مؤسسات خارجی پشتیبانی می‌کند. برای کمک به ادغام و یادگیری، به کارمندان جدید یک «مرشد» رسمی برای راهنمایی و یک «رفیق» برای حمایت غیررسمی‌تر اختصاص داده می‌شود که با راهنمایی‌های غیررسمی از طریق تعامل با مدیران، شرکت در جلسات بررسی تیم و کد، و سایر فرآیندهای غیررسمی محل کار تکمیل می‌شود.

4-2 ارزیابی عملکرد و پاداش

گوگل برای بازخورد در میان کارمندان خود ارزش زیادی قائل است و فرهنگ شناخت را از طرق مختلف پرورش می دهد. مهندسان و کارمندان می‌توانند برای کار یا مشارکت‌های استثنایی «peer bonuses» و «kudos» به یکدیگر اعطا کنند، با پاداش‌های همتا که 100 دلار مشوق نقدی ارائه می‌کنند و تجلیل به عنوان ستایش غیرپولی ارائه می‌شود. به‌علاوه، مدیران این اختیار را دارند که برای دستاوردهای خاص، جوایزی بدهند. فرآیند ارتقاء Google کامل است، شامل نامزدهای شخصی، بررسی همتایان و مدیران، و تصمیمات کمیته، با مکانیسم‌هایی برای تجدیدنظر. این شرکت از طریق برنامه‌های بهبود هدفمند، عملکرد ضعیف را برطرف می‌کند، که خاتمه آن یک نتیجه نادر است. کیفیت مدیریت نیز از طریق نظرسنجی های دوسالانه کارکنان، حصول اطمینان از پاسخگویی و فرصتی برای بهبود مدیریت ارزیابی می شود. این سیستم بازخورد و شناسایی جامع، کلید تلاش Google برای ایجاد انگیزه و حفظ استانداردهای بالا در میان نیروی کار خود است.

آدرس لینکدین:

https://www.linkedin.com/in/mohammadhosseinjalili/