امروز برخی سرویسهای گوگل برای ۴۵ دقیقه خوابید و رفت در خبرها. بیشتر outageهای بزرگ حاصل تعامل چند اشکال با همه، این بار در file system توزیعشدهی گوگل (Colossus) برای سرویسدهی به سیستم احراز هویت گوگل (GAIA). بهانهایست تا یک رویکرد سازمانی مرتبط و خیلی مهم رو مرور کنیم: (۱)
یک مثال که معمولا در کلاسهای دورهی معارفه مرور میشه اینه که یک بار یک بابایی یک configای در سیستم مدیریت jobها (سیستم Borg که بابای Kubernetes است) push کرد و کلّ گوگل رفت پایین! pagerها شروع کرد به زنگ و SREها این ور اون ور میدویدن و این حرفا. (۲)
این بابا، با این pushاش ظاهرا نامرتبط بود و بعید بود کار اون باشه، سریع به همه خبر داد و rollback هم کرد. و قضیه حل شد. این شخص که کل گوگل رو برای چند دقیقه آورده بود پایین، توبیخ شد؟ نه اتفاقا جایزه گرفت (peer bonus که همکار به همکار میده) چون دقیقا کارِ درست رو کرده بود. (۳)
این بخشِ مهمی از فرهنگ برخورد با مشکلاته که مرتبا به همه یادآوری میشه مثلا در آموزشهای دورهای و سخنرانیها و ارتباطاتِ درونسازمانی (مثلا فصلنامهی جالبی که ۵ حادثهی برترِ محصولات گوگل در فصل رو با مایهی آموزش و طنز مرور میکنه هر بار اینو تکرار میکنه) که: (۴)
«وقتی مشکلات رخ میدن ما دنبال اینیم که چه چیزی رو در سیستمها و فرآیندها بهبود بدیم نه این که چه کسی هنگام مشکل چی کار کرد». ما حتی در کالبدشکافیها (postmortem، مستندی که پس از حادثه مینویسیم) ترجیح میدیم نام افراد رو نیاریم، فقط نقششون رو بیاریم یا افعال مجهول بنویسیم. (۵)
این مساله مهمه، چون افراد باید ترغیب بشن اشتباهاتشون رو خیلی باز و سریع اطلاعرسانی کنن، نه این که مخفی کنن. مقصریابی (blaming) سوتیدهنده هیچوقت مطرح نیست - از قضا یک بار مطرح شد همراه با گفتگوی جدی، و اون نه برای اشتباه شخص بلکه برای مخفیکردنش وسرِ کار گذاشتنِ بقیه بود. (۶)
از همکارانی از شرکتهای معروف دیگر بهتره نام نبرم، مثالهای برعکس شنیدم مثلا کسی که سوتی داده دیگه حالا حالاها شانسی برای ترفیع نداره. این فرهنگ بده چون باعث میشه دو زهر «سکوت» و «ترس از تغییر» مُد بشه.
بد نیست در شرکتتون روی این زیرساخت فرهنگی کار کنید. (۷)
بودجهی استادها، که ازش حقوق دانشجو و خرج سفرها و امکانات و ... رو میدن، دادنی نیست بلکه گرفتنیست و باید روزها وقت گذاشت و proposalها نوشت و از فلان شرکت و دولت و شهرداری بودجه گرفت برای پژوهش روی فلان مسالهها. خوب عیبیش چیه؟ (۱)
اینه که عمدتا کار به درد بخوری از این همه پول و زحمت درنمیآد و همه هم اینو میدونن و باز ادامه داره. یعنی بودجهایست که از طرف شرکت/دولت/شهرداری/... باید به اسم «پژوهش» صرف بشه و میشه. آوردهاش؟ چندتا مقاله و البته سفر به نصف دنیا! آوردهاش برای منبع بودجه؟ آها، اون هیچی. (۲)
مثال: استادِ بنده از چندین شرکت و نهاد معروف بودجه داشت تا براشون پژوهش کنه ولی نامشون یا نیازهاشون برای ما هنگام جهتدهی به پژوهشهامون اصلا مطرح نبود. تنها در پایان مقاله میگفتیم با حمایت اونا بوده.
مثال: گروهی از استادانِ نامیِ دانشگاهِ نامیِ ما، از شهرداری تورنتو ... (۳)
اگر در شرکتتون در استفادهی درست از OKR بحث دارید---چون بحثهاش رو دیدم میگم و اگر نه که چه بهتر---بد نیست بدونید که در خود گوگل که بابای اشاعهی OKR است هم، همهی تیمها یکشکل OKR استفاده نمیکنن یا کلا نمیکنن. ببینید چی برای خودتون بهینه است.
چند نکته که شاید به درد خورد:
(برای خوانندهی ناآشنا ولی علاقهمند: OKR=هدفگذاری)
۱. ارزیابی کارکنان/تیمها رو نباید ریخت تو OKRها، وگرنه هدفگذاری بلندپروازانه که هیچ، هدفگذاری معمولیتون هم عقیم میشه.
این خطا رو مدیران سنتی که OKR فقط براشون مُدِ روزه میکنن. اینجوری قضاوتی گفتم که قشنگ ازش دوری کنید.
۲. امتیاز ۳۰٪ در پایان فصل فقط یعنی هدفبندیمون نادقیق بوده و باید بهترش کنیم، نه این که اجرا ضعیف بوده - اجرا رو جور دیگه میسنجن نه با امتیاز OKR. همچنین امتیاز ۹۰٪ در پایان فصل هم باز یعنی هدفبندیمون نادقیق و محافظهکارانه بوده. ما دنبال ۷۰٪ایم ولی نسخه نمیپیچم.
متاسفانه اکثر قریب به اتفاق پژوهشها در این فضا پر از لافزنیاند، مثل تعریفی که بُنگاهی ماشین میکنه. ادعاهای گزاف و بزرگنمایی در کاربردها، رفتارِ پیشفرضه و همه میدونن و عادی شده. دربارهی کنفرانسها و ژورنالهای سطح اول هم صادقه. (۱)
در آغاز راه، همهی مقالهها به نظرتون فوقالعاده میان ولی عادت میکنید که به عهدهی شماست تا چرندیات رو تشخیص بدید، مثل inboxی که فیلتر spam نداره. متاسفانه همه به این مساله عادت کردن در حالی که این رویکرد بنگاهی (شاید طبیعی در جاهای دیگر ولی) برای محیط علمی و فنی مثل سرطانه. (۲)
برخلاف دنیای آکادمیک، در دنیای صنعت به ويژه محیط فنیِ شرکتهای حرفهای، چنین نیست - کسانی که اهل لافزنی باشن جدی گرفته نمیشن و به حاشیه میرن. حداقل در تجربهی بنده. (۳)
شما ماهها تلاش کردید و یک پژوهش خطشکن/groundbreaking انجام دادید و میخواید چاپش کنید، ولی این پژوهش باارزش باید از یک پُل معلق پوسیده و متزلزل با سلام و صلوات رد بشه تا به دست دنیا برسه: سیستم بازبینی و داوری مقالهها. (۱)
اول، بسیاری از داوران اصلا مقاله رو کامل نخونده ایراد میگیرن - و این چنین قراره علم پیشرفت کنه!
دوم، بسیاری میخونن ولی نمیفهمن و ایراد میگیرن، شاید چون خوب ارائه نشده ولی (دلیل متداولتر) چون سطح دانش داور از سطح علمی مقاله پایینتره. خود من همینطوری کلی مقاله ... (۲)
... رد کرده بودم، از جمله در ژورنالهای تراز اول! همچنین استادان به صورت کیلویی مقالههاشون رو میدن دانشجوهاشون بازبینی کنن.
سوم، بدون استریوتایپسازی (یعنی تعمیم ندید)، شخصیت عیبجو و شاکی و دُگم در فضای آکادمیک کم نیست. البته ایرادگیری خیلی هم خوبه برای کیفیت، ولی ... (۳)
چند مشاهده از سالیانی که در دنیای «رّیسرچ» آکادمیک (تعمدا فینگلیش) داشتم رو به مرور و با چارخط #آکادمی_خسته اینجا مینویسم بلکه به درد جوانان آغاز راه بخوره. این مشاهدهها هم سودار (biased) است و هم از روی تجربههای محدود و هم فقط از زیرشاخههایی از علوم/مهندسی کامپیوتر. (۱)
بخش اول: حباب
در تقریبا همهی پژوهشها، حتی در بالاترین سطح، هدف اول نه «به درد خوردن» (که فقط هدف کمکی است) بلکه چاپ در جای خوب و ارجاع گرفتنه. اشکالی هم نداره اگر این دو هدف هم سو میبودن، ولی نیستن بلکه تضاد دارن. به زبان ساده: باید تخیلی (نه واقعی) کار کنید تا چاپ کنید. (۲)
مثال: در کارآموزی که سالها پیش با گوگل داشتم موفق شدم مدیران ارشد رو راضی کنم تا سیستم CDN گوگل رو در قالب یک مقاله چاپ کنیم تا پژوهشگران دنیای بیرون (از جمله خودم پس از بازگشت به دنیای پژوهش دکترا) نفع ببرن و دیدِ واقعی و مسالههای عملی برای کار داشته باشن. (۳)
نمیدونم این موج «هر چیزی از من بپرس» (ask me anything) یا AMA به کجاها رسیده ولی دست کم در شرکت ما خیلی باب شده برای ارتباطگیریِ انسانی بین لایههای بالای شرکت با لایههای پایین و به نظر مفید بوده. یعنی مثلا یک مدیر (معمولا رده بالا) با یک مجری اون جلو مینشینن و حاضرین ... (۱)
... هر سوالی بخوان میپرسن، بیشتر هم شخصی تا کاری - طبیعتا بدون ورود به حریم خصوصی. حتی سوال چالشی. گاهی حضوری و گاهی هم به کمک یک سیستم سادهی ارسال و like زدن سوال. حالت گپ داره نه سخنرانیِ بالا به پایین.
یکی از مشکلات یک درخت یا زیردرخت سازمانی بزرگ اینه که منِ نوعی ... (۲)
... برام مهم نیست مدیر ۳ ۴ لایه بالاتر کیه یا چیا میگه چون در کار روزمرهی من تاثیر نداره. پس میزان شرکت در جلسههای فراگیر تیمی (جلسههای All Hands یعنی «همه بیان») که قراره باشه هزار نفر میشه فقط صد نفر، و ارتباط بالا و پایین قطع میشه و شاید اولیتبندیها زاویه پیدا کنه. (۳)