ترک اوبر در سال 2022 بهترین کاری بود که برای خودم انجام دادم 🚶💼

Summarize this content to 400 words in Persian Lang

tl;dr 📖

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

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

«آزاد از قید و بند!» میگویند…

اکنون نسخه طولانی تر…

آسایش اوبر 🛌

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

ترک آن شغل آرام و پردرآمد در اوبر یکی از سخت ترین تصمیماتی بود که تا به حال گرفته ام (ماه ها طول کشید تا تصمیم بگیرم).

را اوبر Office S01E01 🏢

اولین پروژه من در اوبر kickass بود و همه مدیران من در اوبر عالی بودند. در واقع، در تجربه شخصی من همه افرادی را که با آنها کار کردم دوست داشتم. دوستانه. ماهر. قابل توجه

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

و چون چیزی بود که از ابتدا ساخته می شد، بارهای گذشته زیادی برای حمل وجود نداشت. «تأییدات» زیادی از خارج از تیم اصلی مورد نیاز نبود. برنامه ریزی، طراحی، اجرا در “دایره داخلی” قرار داشت. این بدان معنی بود که همکاری فوق العاده سریع بود، و به همین ترتیب اجرا.

اما قرار نبود دوام بیاورد.

و بعد دوره ماه عسل تمام شد…

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

اینطور نیست که من هم کم کار بودم. من باید عملکرد خوبی داشته باشم زیرا به طور یکنواخت در چرخه های بازخورد، ارزیابی ها و این واقعیت که به من “جایزه تاثیر” داده شد منعکس شده است.فقط احساس می کردم با وجود همه اینها، آن کاری را که می خواستم انجام نمی دادم.

نوار قرمز 🔴

یک شرکت بزرگ مانند یک کشتی سنگین بزرگ است. به جایی می رسد که نیاز است، اما زمان می برد، و قطعا به آرامی مسیر را تغییر می دهد.

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

Uber همچنین دارای مفهوم شگفت انگیز ERDs است (البته مختص آنها نیست). که اساسا PRD هستند اما بسیار خاص مهندسی و پیاده سازی هستند. اما این ایده نیز به دلیل فرآیندهای بوروکراتیک و تعداد افرادی که در نهایت باید درگیر شوند کند شد.

همه چیز در این مرحله هفته ها را سپری می کند! مطمئناً، این امکان اجرای بسیار محکم و فکری را فراهم کرد، و شرکتی مانند اوبر ممکن است برای اجرای قوی‌تر با تاخیر مواجه شود. بجز…

هیچ کس برای تأیید اینکه آیا پیاده سازی واقعاً با اسناد مطابقت دارد یا خیر وجود نداشت.نیت خوب است، اما به خوبی رعایت نشده است.

«یک روز، من می‌خواهم از آن نوع توسعه‌دهندگانی باشم که قبل از ارائه کد، 5 مرحله را پشت سر می‌گذارند!» – گفت: هیچ کس تا به حال.

همه چیز با حمله Metrics Nation تغییر کرد

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

بازخورد بین فردی و ارزیابی مستقیم توسط مدیر اهمیت قابل توجهی داشت و به طور کلی کل فرآیند کاملاً شفاف بود. من با آن مشکلی نداشتم. اما پس از آن، تلاش هایی برای خودکارسازی این فرآیند انجام شد…

داشبوردهایی برای ردیابی آمار افراد در تیم های مختلف ایجاد شده است.

و… یکی از چیزهایی که اندازه گیری می شد این بود تعداد خطوط و تعداد PR در ماه. 😱بله… 0.01234 میکروثانیه طول می کشد تا متوجه شوید این ایده بدی است. در عرض چند روز، توسعه دهندگان به طور مصنوعی تعداد روابط عمومی را افزایش دادند، در حالی که نیازی به افزایش این تعداد نبود، روابط عمومی را تقسیم کردند.

من آنها را سرزنش نمی کنم. 🤷

بنابراین، من سعی کردم آن را مرتب کنم 💪

من همیشه دوست داشتم مشکلات را حل کنم. من در اوقات فراغتم پازل انجام می دهم، اغلب بازی های استراتژیک را در رایانه شخصی خود انجام می دهم (زمانی که در ولفنشتاین به نازی ها شلیک نمی کنم، یا کلم هایم را در Stardew Valley ذخیره نمی کنم).

من اغلب مشکلاتی را که بر من یا تیمم از نظر تجربه توسعه‌دهنده، بهره‌وری، مستندات و غیره تأثیر می‌گذاشت، معمولاً با کنار گذاشتن مسیرم حل می‌کردم. من آن را سرگرم کننده یافتم. 🤷

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

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

معیارهای قابل بازی

🗓️ در این مرحله، ما در نیمه دوم سال 2021 هستیم 🗓️

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

برخی از موارد خاص اندازه گیری شد:

تعداد PR در ماه

توسعه دهندگان شروع به ساخت PRهای کوچکتر از نیاز یا بیهوده تر کردند
توسعه دهندگان شروع به ساخت PR برای چیزهای قدیمی با اولویت کم کردند، اگر تعداد روابط عمومی آنها کم بود
برخی از روابط عمومی ها توسط توسعه دهندگان دوستانه در همان تیم تأیید شدند تا تعداد روابط عمومی افزایش یابد

تعداد خطوط در هر PR

توسعه دهندگان شروع به نوشتن کدهای مفصل تر کردند
خطوط جدید اضافی
بازسازهای غیر ضروری

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

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

و این زمانی بود که من به طور فزاینده ای از زمانم در اوبر ناراضی بودم…

این ما را به سال 2022 می رساند 🗓️

ایده میان افزار

در همین زمان، Dhruv ایده Middleware را به من ارائه کرد. مفهوم جالب بود: پلتفرمی که برای توسعه دهندگان را قادر می سازد تا در واقع کار خود را انجام دهند، آنچه را که آنها را از انجام کاری که دوست دارند باز می دارد برجسته کنید، تنگناها، مسدود کننده های فرآیند و غیره.

اولین چیزی که به ذهنم خطور کرد این بود…”اگر من چیزی شبیه به این برای نشان دادن بینش به مدیرم داشتم، بسیار مفیدتر از هر کاری بود که آنها در حال حاضر انجام می دهند.”

پس از چندین ماه بحث و بررسی، در آگوست 2022 در نهایت تصمیم گرفتم جهش کنم و در این سفر به مرد ملحق شوم. تصمیم آسان نبود، اما به نظر درست بود. 🚀این فقط 2 روز بعد از تولد من بود! 🎂

استارتاپ Hustle

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

هدف ما مستقیم بود؟چیزی بسازیم که مهندس گذشته ما آن را معقول می‌داند.

ساختن تیم مناسب بسیار مهم و تلاش مستمر بود. درس های بزرگی در رهبری، پویایی تیم و فرهنگ شرکت آموخته شد. به نظر می رسد، NERF تقریباً برای همه چیز جواب می دهد. 😂 jk، jk.رشد یک شرکت به معنای پرداختن به امور مالی، بازاریابی، رعایت قوانین و البته مشتریان بود. این یک منحنی یادگیری بزرگ فراتر از روزهای اوبر من بود.

با تأمل در این سفر، می توانم با اطمینان بگویم که سخت اما خوشحال کننده بود. ساختن چیزی معنادار بیشتر از راحتی است که من در اوبر به جا گذاشتم، اما بدون حمایت همسرم، Mehak، بسیار دشوارتر بود.

و بله، دوباره این کار را با ضربان قلب انجام می دهم. 💗

Psst.اگر می‌خواهید بررسی کنید که ما در حال ساخت چه چیزی بوده‌ایم، اینجا بروید. اگر بتوانید ستاره ای را در مخزن بگذارید، برای من بسیار معنی خواهد داشت. 😄

✨ پلت فرم متریک DORA منبع باز برای تیم های مهندسی ✨

مدیریت مهندسی منبع باز که پتانسیل توسعه دهندگان را باز می کند

معرفی

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

آن ها هستند:

فرکانس استقرار: فراوانی استقرار کد در تولید یا یک محیط عملیاتی.

زمان سرب برای تغییرات: زمانی که طول می کشد تا یک تعهد به تولید برسد.

میانگین زمان بازیابی: مدت زمانی که طول می کشد تا سرویس پس از یک حادثه یا خرابی بازیابی شود.

نرخ شکست را تغییر دهید: درصد استقرارهایی که منجر به خرابی یا نیاز به اصلاح می شود.

فهرست مطالب

…