برای «ارزیابی کارکنان»، سیستم گوگل یکی از معقولترینها میان شرکتهای مشابهه که شنیدم و خوندم. جزییات این سیستم در اینترنت هست. چند ویژگی مهم در این سیستم محقق میشه (مثل سلیقهزدایی و رشد) و البته کاستیهایی داره، که در این رشته خلاصه میکنم. (۱)
شما نردبان خودتون رو تعریف کنید. نمونهها در اینترنت هست. اونهایی که به اسم گوگل دیدم، چند جابجایی داشتن ولی برای نمونه خوبن. (۲)
فرآیند ارزیابی تقریبا همون فرآیند استاندارد ۳۶۰ درجهست: افراد خود-ارزیابیشون (self assessment) رو مینویسن و چند همکار (peer) برای گرفتن نظر/بازخورد انتخاب میکنن. مدیر برای کارمند، کارمند برای مدیر، و همکاران انتخاب شده برای همدیگه، نظر/بازخورد مینویسن. (۳)
همکار میتونه از تیم خود یا (چه بهتر) از تیم دیگری باشه - هر کسی که با کارهای شما در بازهی ارزیابی (۶ یا ۱۲ ماه گذشته) آشناست. راستش دو هدف در مقولهی peer review خَلط شده، دریافت بازخورد برای رشد و دریافت تعریف و تمجید برای ارزیابی/ترفیع، و این یکی از نابهینگیهای سیستمه. (۴)
برای نیروی تازهکار، کل فرآیند شاید فقط نصف روز ولی برای مدیران به ویژه در ردههای بالاتر چندین هفتهی تمام-وقت زمان میبره و از کار و زندگی میندازدشون.
سودمندیهای این همه درگیری رو خواهیم دید. بیشتر این زمان، صرف review نویسی و شرکت در جلسات ارزیابی و ترفیع میشه. (۵)
در پرانتز: تلاشهای زیادی برای کم کردن این هزینهی هنگفت ضمن حفظ سودمندیهای سیستم شده مثلا peer review به دو شکل مفصل و خلاصه ممکن شده یا برای text box ها محدودیت شمار واژگان گذاشته شده یا ترفیع ردههای پایین تمرکززدایی شده. ولی کلیّت فرآیند حفظ شده چون فایدههای زیادی داره. (۶)
در پایان، فرد در یکی از پنج ردهی {نیاز به بهبود، سازگار با انتظارات، فراتر، بسیار فراتر، فوقالعاده} قرار میگیره بر اساس انتظارات از سطح فرد در «نردبان». این تکهی آخر مهمه.
یک نیروی «بسیار فراتر» در سطح N، کم و بیش همترازه با نیروی «سازگار» در N+1، و شاید آمادهی ترفیع. (۷)
مثل دور موتور و سرعت بین دندههای ماشین که پیشتر گفتم. این سیستم خیلی بهتر از سیستمهاییه که نیروهای یک تیم رو در کنار هم در یک سطح ارزیابی میکنن، یا صرفا بر اساس سال سابقه سطح میبندن.
این پنج رده، کمی توی ذوق میزنه چون مثلا «سازگار» میشه ردهی ۲ از ۵، ولی واضحه چرا. (۸)
متن خود-ارزیابی و ارزیابی مدیر و نظرات همکاران و جلسات غیره، همه گِرد تعریفِ مشخصِ سطحِ فرد در نردبانه. همهی فُرمها با یک لینک به نردبان آغاز میشه.
هر شغل نردبان جدا داره - مهندس نرمافزار و SRE و product manager و غیره. نردبان مدیریت هم جداست.
(۹)
برخلاف بیشتر جاهایی که دیدم، ردهی ارزیابی فرد (مثلا «فراتر از انتظارات») توسط مدیر تعیین نمیشه بلکه فقط «پیشنهاد» میشه و باید اون رو ارائه و از پیشنهادش دفاع کنه: در جلسات قِلِقگیری (calibration). یعنی اگر یک مدیر سختگیر بود و یکی آسونگیر، نباید روی ارزیابی نیرو ... (۱۰)
... تاثیر بذاره - البته میذاره و تلاش فقط برای کمینه کردن این تاثیره. در جلسات قلقگیری، مدیر یادداشتهاشو ارائه میکنه که فلانی چه کارهایی در ۶ ماه گذشته کرده (و شاید تکههایی از peer reviewهای همکارانِ نیرو رو نقل قول کنه) که مثلا ایشون رو لایق ردهی پیشنهادی X میکنه. (۱۱)
حتی مشخصا از مدیر پرسیده میشه چرا ردهی X+1 نه؟ چرا X-1 نه؟ اون یادداشتهایی که گفتم رو، مدیر پیش از جلسه برای هر نیرو نوشته و سرمشق جلسه در اون N دقیقهایست که هر نیرو به بحث گذاشته میشه. رهبران فنی (TLهایی) که مدیر نیستند هم در این جلسات شرکت دارن و اطلاعات میدن. (۱۲)
مثال اول: بارها دیدم که ارزیابی مد نظر مدیر، در پی این مباحثههای سازنده، عوض میشه. مثال دوم: مدیری که وقت نگذاشته و برای نیروهاش یادداشتِ کافی و ساختیافته ننوشته، براش بد میشه. مثال سوم: یک بار مدیری گفت فلانی فلان کارو کرده و فلان خصیصهی خوب رو هم داره ولی در پاسخش ... (۱۳)
... گفته شد که فلان خصیصه خوبه ولی جزو نردبان نیست - «نردبان» و «قلقگیری» کلیدیترین مولفههاییست که فرآیند رو به دور از سلیقه و سوگیری (objective) نگه میداره. مثال چهارم: یک بار گفته شد فلانی ضعیف عمل کرد و نتونست فلان کارو درست انجام بده، و در پاسخش گفته شد فلان کار ... (۱۴)
... کار اصلا نباید به نیروی سطح فلان داده میشد و ضعیف عمل کردنش ملاک نیست (و حالا ببینیم در بقیهی کارهایی که در سطح خودش بوده چه کرده). مثال پنجم: نیرویی که اخیرا از تیم/شرکت رفته، روند ارزیابیش هیچ تفاوتی با بقیه نداره. مثال ششم: بارها پیش اومده که گفته شده ... (۱۵)
... این کارهایی که از فلانی توضیح دادی به ردهی مثلا «بسیار فراتر» میخوره نه «فراتر» ولی توضیح این بوده که نیرو همین اواخر به حد «بسیار فراتر» رسیده بوده نه به طور متداوم (consistent) در طول ۶ ماه، که نکتهی مهمیه. امیدوارم این مثالها به ملموس شدن فرآیند کمک کنه. (۱۶)
از دیگر تفاوتهای این سیستم اینه که ترفیع دست مدیر نیست. شخص حتی میتونه علیرغم مخالفت مدیرش برای ترفیع درخواست بده - البته باید case قوی داشته باشه. برای ترفیع، باید بستهی مفصلتری از صِرف خود-ارزیابی نوشت: خلاصهای از پروژههای اصلی که از ترفیع گذشته (مثلا ۳ سال پیش) ... (۱۷)
... تا کنون انجام داده و این که چه طور ویژگیهای سطح N+1 رو داره، با تمرکز بر سه محور «رهبری»، «پیچیدگی» و «تاثیر» (leadership, complexity, impact). خود-ارزیابی نیمسالانه در واقع نسخهی سادهتر همون بستهی ترفیعه: کارهایی که تو این ۶ ماه کردی رو گِرد اون سه محور توضیح بده. (۱۸)
پس از چند هفته ارزیابی، نوبت جلسات مدیر:نیرو است که ردهی ارزیابی فرد به همراه (اصل کاری) بازخورد عملپذیر (actionable feedback) به نیرو داده میشه. بازخورد عملپذیر منحصر به دو بار در سال نیست و قراره به طور پیوسته داده بشه - اصلا یکی از پرسشها در ارزیابی نیرو از مدیر ... (۱۹)
... اینه که مدیرم به من به طور پیوسته بازخورد عملپذیر میده یا نه. بازخورد عملپذیر رو با سمّ micromanagement اشتباه نگیرید. اتفاقا این هم یکی از پرسشهاست: منو micromanage میکنه یا نه.
باید تا الان معلوم شده باشه که هدف اصلی کل فرآیند ارزیابی، تشویق به «رشد» هست. (۲۰)
طبیعتا تعیین دستمزد هم هست، ولی یکی از کارهای خوبی که گوگل میکنه، جدا کردن گفتگوهای ارزیابی و گفتگوهای دستمزده که با یکی دو ماه فاصله انجام میشه. اگر این دو تا با هم باشه، فضای فکری و اولیویتهای کارکنان عوض میشه و «رشد» تعطیل میشه. (۲۱)
در تیم ما، ما یک خود-ارزیابی غیر رسمی و سادهی سه-ماهانه هم مینویسیم، یعنی نسخهی رسمی شش-ماهانه صرفا ادغام ۲ تا از ایناست. هر شخص هم برای خودش خلاصههای هفتگی مینویسه، البته اختیاریه ولی توصیه میشه، تا موقع نوشتن خود-ارزیابی N-ماهانه مرور کنیم چه کارایی کردیم. (۲۲)
خود-ارزیابی باید مختصر و مفید و پر از داده و ارجاع باشه. مثلا بگی که در هر پروژه (معمولا ۳ ۴ تا) چه طور خصوصیات {رهبری، حل پیچیدگی، تاثیرگذاری برای شرکت} رو در سطح خودت یا فراتر محقق کردی و به design docها و email threadهای مهم و مصنوعات دیگه که ادعاها رو نشون بده لینک بدی. (۲۳)
اما از کاستیهایی که همچنان در این سیستم وجود داره، یکی اینه که سرنوشت رشد شغلی نیرو هرچند از انحصار مدیر دراومده ولی یک مدیر بد همچنان میتونه یک سرعتگیر بزرگ باشه. دوم این که همچنان اینرسی وجود داره یعنی اگر شما در فصل پیش (با ناداوری) ردهی N گرفتید، در فصل فعلی ... (۲۴)
... برای گرفتن N+2 و رفتن برای ترفیع باید تلاش بیشتری بکنید نسبت به کسی که فصل پیش N+1 گرفته و این منصفانه نیست. این البته فقط یکی از کاستیهای کوچک فرآیند ترفیع در گوگل هست، فرآیند معیوبی که اصلا در این گفتار بهش نپرداختم. سوم این که سیستم طوری طراحی شده که سود شخص و ... (۲۵)
... سود شرکت همسو باشه ولی سیستم هنوز به اونجا نرسیده، مثلا شما گاهی ناچارید بین پروژهی الف و ب که یکی سودِ بیشتری برای شرکت داره و دیگری خوشآوازهتر برای ترفیعه (مثلا سودِهی به N نفر بیرون از تیم خودت)، دومی رو انتخاب کنید. چهارم این که سطح اولیهای که به نیروها ... (۲۶)
... هنگام استخدام ارائه میشه با وسواس خیلی کمتری از سطحبندی نیروهای فعلی انجام میشه. دربارهی فرآیند مصاحبه پیشتر اینجا نوشتم:
برای داشتن یک #سیستم_همیشه_بالا، از کارهایی که باید مرتب و مکرر روی سرویسها انجام داد مانورهای تابآوری/بهبودی در برابر فاجعه (disaster recovery test = DiRT) است - برای نمونههای جالب و تجربیاتِ آموخته جستجو کنید Google dirt program. مسلما شرکتهای دیگر هم دارند. (۱)
مثلا ما هر سال اون سیستمی رو که سپر اصلیمون در برابر overload است--چه organic مثلا فینال مسابقات کریکت چه بر اثر outage و کاهش ظرفیت سرویس--با خارج کردن چند datacentre از مدار، تست میکنیم. یا یک cache که سیستم ما بهش وابستهست رو disable میکنیم. یا حتی ساز و کار ... (۲)
... خودکاری داریم که هر روز چند سرور از N سرور واقعی (نه سرور تست!) رو انگولک کنه و اگر چکشخوار (resilient) نبودن هشدار بده - حتی سر این مورد آخری مقاومت وجود داشت ولی الان که جاافتاده همه از یافتههاش راضیاند.
چنین ساز و کارهایی از ملزومات پیشگیری از سورپریزهای دردناکه. (۳)
از نزدیک ۱۰۰۰ سال پیش یادداشتی به جا مونده از «ابوالفضل شاگرد بونصر مشکان»، احتمالا همون بیهقی، برای برگردان فارسی و عربی. اون زمان، فارسینویسی داشت از نو شکوفا میشد در حضور پررنگ عربی - مثلا یک وزیر سلطان محمود فارسی رو زبان رسمی میکرد و بعدی باز عربی و ... (۱)
چند نمونهی خوشگل از برگردانها رو اینجا مینویسم. اصلش در «پارسی نغز» در ۱۳۳۰ و «چند سخن که دبیران در قلم آرند» در ۱۳۵۵ چاپ شده.
خود تاریخ بیهقی هم سراسر عبارت چشمنواز فارسیه مثل «گُرگآشتی» (توافق الکی) و «خاکی و نمکی بیختن» (سَمبَل کردن) و ... اگر علاقه داشتید بخونید. (۲)
برگردانها به این شکله: بدان که به جای «ترسانیدن» «تهدید» نویسند و به جای «شوریدگی» «اضطراب».
یعنی واژهسازیِ فارسی نیست بلکه مثلا «بستاخی / خویشتن کشیدن» (انبساط / انقباض)، واژگان متعارف فارسیسخنانِ روز بوده و میگه ما در نامههای رسمی دربار چه عبارت عربی به جاش مینویسیم. (۳)
از دیگر مهمهایی که شاید در آغاز، دغدغهی توسعهدهندگان نباشه ولی بعدا که سیستم بزرگ شد پشیمون میشن، بُعد دادن به سنجه (metric) هاییه که گفتیم دست و دلبازانه در کُدها میذاریم، تا بتونیم قاچ (slice) های ریز رو پایش کنیم نه فقط مجموعِِ فلّهایِ رو. (۱)
مثلا در مثال فروشگاه اینترنتی، اگر کالاهایی که پیشنهاد میدیم از ۲ جور مخزن A و B میان و کاربر از دو شیوهی app یا web با ما تعامل میکنه، به همهی سنجههای مهممون بُعد «مخزن» و «محیط کاربر» میدیم. اون وقت نه تنها مقدار مجموع سنجهی الف رو میبینیم، بلکه مقدار الف در هر ... (۲)
... قاچ {A:web, A:app, B:web, B:app} رو هم. مثلا اگر app ما دچار bug شد و یک سیگنال لازم برای پیشنهاددهی بهینه به کاربر از مخزن B رو نفرستاد، از قاچ B:app میفهمیم. در عمل بعدهای بیشتری هم لازمه مثل سیستم عامل و مرورگر تا مثلا اگر apple یک نسخه داد که به ما نمیساخت، بفهمیم. (۳)
گفتار پیش دربارهی پایش بر اساس سنجههای بیدرنگ (real time) از سرورها بود. یک مکتب موازی در پایش، پایش بر اساس logهاست - نه debug log (مثل info و warning و ...) بلکه log ردگیری (trace) که به ازای هر درخواست ذخیره میکنیم. (۱)
پایش از روی logهای تجمیع و پردازش شده (که مثلا بر اساسش پرداخت انجام میدیم) سودهایی داره مثل: (۱) به اونچه نهایتا برای ما مهمه نزدیکتره تا سنجههای خام از وسط کُد، (۲) با logها میشه قاچ (slice) های ریزدانهتر پایش کرد مثلا نمودار فلان چیز قاچشده بر اساس نسخهی مرورگر. (۲)
ولی کاستیهایی داره مثل: (۱) تاخیر زیاد، چون logهای نهایی حاصل pipelineهای کُندِ پردازشیه (مثلا ترکیب میلیونها رخداد «نمایش پیشنهاد» توسط ما و «کلیک روی اون» توسط کاربر و سپس تجمیع و سپس خطا/spam زدایی و سپس ...)، (۲) به خوبی عملپذیر (actionable) نیست چون داریم میگیم ... (۳)
سرویس ما اگر قراره موفق باشه، زود یا دیر پایش سطح بالا خواهد داشت. مثلا اگر یک سرویس خرید اینترنتی داریم، فقط سالم بودن سرورها و مصرف پردازش و حافظه رو پایش نخواهیم کرد بلکه نمودار تعداد خرید بر ثانیه و تعداد نمایش فلان پیشنهاد بر ثانیه و نتایجی که به دلیل الف و ب ... (۱)
... فیلتر میکنیم و غیره و غیره رو هم خواهیم پایید تا (دلیل اول) اگر یک bugی فعال شده یا یک مدل یادگیری پسرفت کرده یا به هر دلیلی داریم خراب میکنیم، خبردار شیم - بدیهتا روی هر چیزی هشدار تعریف نمیکنیم و شاید بعدتر از مسالهی لوث شدن هشدار بنویسم. خوب خبردار شدیم، حالا ... (۲)
... چه طور کند و کاو میکنیم؟ (دلیل دوم) از طریق همون دادههای پایشی - چندین برابر سنجه (metric) هایی که برای هشداردهی تعریف کردیم معمولا سنجه برای کند و کاو تعریف کردیم. (دلیل سوم) همین سنجهها هستن که یک قناری موفق رو ممکن میکنن: هنگام بیرون دادن (release) هر نسخهی ... (۳)
اگر برای سرویستون پایش و هشدار (monitoring & alerting) انجام میدید شاید این به دردتون بخوره. از تیمهایی که روی هم سرویس فعلی ما رو میسازن، برخیها هم یک نیروی گوشبهزنگ (oncall) از تیم توسعهدهنده (dev) دارن و هم یکی از SRE (سرویسهای ... (۱)
... حیاتیتر و پیچیدهتر)، برخی فقط SRE و برخی فقط dev. همه جورش، ذیل یک سرویس مادر یکسان، هست. سرویس دیگر (CDN) که کوچکتر بود هم، هم SRE گوشبهزنگ داشت و هم dev. برخی هشدارها به این گروه میره و برخی به اون. دربسیاری مواقع، این دو همدیگر رو (یا تیمهای دیگر رو) فرامیخونن. (۲)
این جزییات رو برای این میگم که نقش SRE اخیرا در بازار ایران پررنگ شده و دربارهش میپرسن. طبیعتا کاری که ما میکنیم مرجع نیست، هدف فقط دادن دادهی پراکنده هست. دربارهی همکاریهای dev و SRE و غیره اگر به درد میخوره میتونم بیشتر بنویسم. (۳)