نوشته های Kian

نردبان شغلی و ساختار مشوق

Kian — Fri, 03 May 2024 08:57:54 +0330

بخش عمده‌ی مشکلاتِی که با همکاران در شرکت‌های مختلف درباره‌شان گپ زده‌ایم، (به زعم بنده)‌ یک سرشان برمی‌گشته به نداشتن نردبان شغلی مناسب و ساز و کار اِعمال آن (برای ارزیابی و ترفیع‌/promotion و غیره)، یک مقوله‌ی حیاتی برای کارآمدی سازمان ولی غایب.مثلا اگر افراد خود را صرفا در قبال task خود مسئول می‌دانند و نه موفقیت نهایی محصول، اگر کدهای کثیف و بی‌تست و باگ‌دار می‌زنند و تضمین کیفیت آن را کارِ افراد دیگر می‌دانند، اگر دور تیم‌هایشان حصار کشیده‌اند و «قلمرو» ساخته‌اند، اگر وضعیت بدهی فنی از کنترل خارج شده، اگر مشارکت شهروندی (مصاحبه و اشتراک دانش و الخ) نمی‌کنند، یک سرِ آن در آموزش و یک سرِ آن در نردبان و ارزیابی است.کمی از نردبان و «ساختار مشوق» (incentive structure) صحبت کنیم—با الهام از گوگل—همچنین از ناکارآمدی‌های آن و تله‌هایی که باید مواظبشان بود. افراد زیادی پی‌گیر مساله‌ی نردبان و ساختار مشوق از بنده بودند و بنا داشتیم کارگاهی درباره آن برگزار کنیم ولی فعلا به این یادداشت بسنده کنیم. درباره ارزیابی عمل‌کرد (ساز و کار اِعمال نردبان پیش‌تر همینجا نوشته‌ام: بخش اول؛ بخش دوم).نردبان یا شرح شغلی، چیست؟ یک سند برای هر شغل، مثلا مهندس نرم‌افزار یا مدیر محصول، که سطح‌های آن شغل را مشخص کرده و انتظاراتی که از افراد در هر سطح می‌رود را توضیح می‌دهد؛ مهندس تازه‌کار فلان،‌ مهندس ارشد فلان. اگر آشنا نیستید، به کمی پایین‌تر که نمونه‌ی گوگلی آن خلاصه شده بپرید و بعد برگردید بالا.افراد بر اساس شایستگی از نردبان بالا می‌روند - نه بر اساس تعداد سال سابقه!نردبان معیاری برای سپردن کار به افراد است؛ پروژه‌ی الف پروژه‌ی سطح ۴ای است، آن را به رضا (که مهندس سطح ۳ با پتانسیل برای رشد است) بدهیم.نردبان معیاری برای ارزیابی افراد و تعیین‌کننده‌ی حقوق و پاداش هم هست.اینجا در ایران، نردبان و شرح شغلی دستاورد-محور (impact based) را با کمک دوستان در دو سازمان پیاده کردیم و نتایج آن برآیندی کاملا مثبت داشته: همه خودشان را برای موفقیت محصول نهایی مسئول می‌دانند؛ همه دنبال انجام کار با سرعت و کیفیت بالا هستند؛ دنبال خود-رهبر شدن و own کردن (با تعریفی که پایین‌تر ارائه شده) هستند؛ دنبال پوشش دادن شکاف‌های بین‌تیمی (که آفت شایعی در بازار ایران است) هستند؛ و الی آخر.اصولاولین اصل در قضیه‌ی نردبان و ساختار مشوق: تصورات کمونیستی‌مانند که افراد به دنبال نفع شخصی و ترفیع نباشند و از روی مرام یا وفاداری به فکر محصول و سازمان باشند، متاسفانه توهمی بیش نیست؛ اینجا هم دنیا دنیای کاپیتالیستی است. احتمالا استارتاپ‌هایی هستند که همه هم‌دلانه کار می‌کنند یا معدود «قهرمان»هایی در سازمان‌های بزرگ‌تر هستند که مثال نقض این اصل هستند و منافع سازمان را به منافع خود ترجیح می‌دهند - هم خودم پیش‌تر بوده‌ام و هم بسیاری را دیده‌ام. ولی این، بلندمدت نیست، یا به عبارت بهتر: حساب کردن روی صِرف هم‌دلی مرام و وفاداری، بقاپذیر (sustainable) نیست. اولین اصل این است که انگیزه‌های فردی افراد (مانند ترفیع و کسب حقوق بیشتر؛ کسب تخصص‌های جدید و رشد؛ …) را به رسمیت بشناسیم. باید به دنبال «طراحی بازار» باشیم، به گونه‌ای که انگیزه‌های فردی افراد با رشد سازمان هم‌سو شود - تا وقتی افراد برای نفع خود حرکت می‌کنند، سازمان را جلو ببرند.دومین اصل: تعمدا، به امروزِ سازمان نگاه «نکنیم». برخلاف یک تصور رایج، نردبان برای این نیست که اعضای امروزِ سازمان را دسته‌بندی کند و مثلا در تعیین حقوق و غیره کمک کند. نردبان و ساختار مشوق برای این است که به افراد و سازمان، مانند خمیر، شکل دهد. دسته‌بندی و کمک به تعیین حقوق و غیره، آورده‌ی جانبی نردبان است. روی امروزِ سازمان گیر نمی‌کنیم که مثلا «اگر نردبان از افراد انتظار خود-رهبری داشته باشد، به سازمان ما که به روش سنتی عِسکرامی task-بده-task-بگیر کار می‌کند، نمی‌خورد»؛ یا مثلا «اگر نردبان از افراد انتظار رابطه ساختن یا تاثیرگذاری روی تیم‌های دیگر داشته باشد، به سازمان ما که بین تیم‌هایش دیوارهای بلند است، نمی‌خورد». بپرسیم: دوست داریم سازمان ما در پایان سال آینده چه شکلی باشد (با یک نگاه واقع‌بینانه)؟ نردبان را برای آن تصویر، طراحی می‌کنیم، نه برای امروز. نخوردنِ نردبان به امروز سازمان را طور دیگری حل می‌کنیم؛ مثلا شُل‌تر گرفتن بعضی شاخصه‌های نردبان برای یکی دو دوره‌ی عمل‌کردی و سپس جدی‌تر گرفتن آن.سومین اصل: دستاورد-محوری. شرح شغلی و نردبان مهندسی نرم‌افزار گوگل، پیش‌تر افراد را در سه بُعد می‌سنجید: دستاورد یا اثرگذاری/impactهای حاصل شده، رهبریِ نمایش‌داده‌شده، و پیچیدگی‌های حل شده. از پیارسال، ابعادش عوض شد: مشارکت، چالش، نفوذ و تخصص. خیلی بهتر شد. پس اثرگذاری کو؟ اثرگذاری شد شرط لازم همه‌ی بُعدها، نه یک بعد جدا. خیلی بهترتر شد. یعنی اگر چالش بزرگی حل کردی، چه سنگی را برای سازمان تکان دادی؟ اگر تخصص خاصی از خودت نشان دادی، اثرگذارش‌اش چه بوده؟ دنبال «تخصص برای تخصص» نیستیم. دنبال تخصص/رهبری/نفوذ/… برای اثرگذاری هستیم. دوست عزیزی از یکی از شرکت‌های ترازِ اکوسیستم مثال می‌زد که نردبان تخصص‌-محور باعث شده بود مثلا یکی برای نگه‌داشتن یک config چند کیلوبایتی بخواهد کاساندرا بالا بیاورد.چهارمین اصل: همه چیز گردِ نردبان/شرح شغلی می‌گردد. هر یک از ما ممکن است به دلایل مختلفی یک فرد را «خفن» بدانیم، مثلا «همه او را می‌شناسند» یا «یک سیستم بزرگ دستش است». ولی این‌ها شاخصه‌های خواسته شده‌ی نردبان نیست، بنابراین آن دو جمله به خودی خود، بی‌معنی‌اند. آن معروف بودنِ فلانی، به زبان نردبان/شرح شغلی چه‌گونه ترجمه می‌شود؟ مثلا آیا روی فراتر از تیم خود، تاثیرگذاری مثبت دارد؟ فلانی برای نگه‌داشت آن سیستم بزرگ، چه چالشی حل می‌کند؟ اصلا در پیِ کم‌کردن بار نگهداری دستی هست؟ نردبان/شرح شغلی وجود دارد تا انتظارها از افراد را عینی (objective) کند:‌ همه به یک زبان و با یک سیستم ارزشی. نوشتن خودارزیابی، نوشتن بازخورد برای همکار، نوشتن گزارش کمیته‌ی ارزیابی، همه گِرد نردبان می‌گردند و نه توصیفات سلیقه‌ای (subjective).پنجمین اصل: قرار نیست سیستم صرفا «منصفانه» باشد. قرار است سیستم «کار کند»، یعنی سازمان را به جلو ببرد، و قطعا نابهینگی‌هایی در هر دو جهت «انصاف» و «کارآمدی» خواهد داشت. مثلا گلایه‌هایی مانند: «من سهم خودم را انجام دادم و حالا اگر پروژه عملیاتی نشده، چرا من ترفیعم را نمی‌گیرم» (در سطحی که انتظارِ نه صرفا impact on the project و بلکه impact of the project معیار ارزیابی است)، یا «در تیم من اصلا پروژه‌هایی از اندازه‌ای که برای ترفیع به سطح بعدی انتظار می‌رود وجود ندارد»، یا …، وجود خواهند داشت. هر یک هم به طور مجزا قابل بررسی‌اند. ولی این انتظار که سیستم باید کاملا «منصفانه» باشد را از الان کنار بگذارید. چرا؟ چون سازمانی که به صِرف «تلاش» پاداش دهد، به «من کارم رو رسوندم و بقیه‌ش مشکل من نیست» پاداش دهد، در بلندمدت چه شکلی خواهد شد؟ سازمانی که به افراد تیم الف، چون در تیمشان پروژه‌های بزرگ نیست، ترفیع کیلویی دهد، در درازمدت چه‌شکلی خواهد شد؟ آن مشکلات را باید طور دیگری حل کرد و نه شُل گرفتنِ نردبان.نردبان گوگلبسته به تصویری که برای درازمدت سازمانتان دارید احتمالا یک نمونه‌ی خوب برای الگوبرداری باشد. نردبان و شرح شغلی عملا یک چیزند، اصلا گوگل نام ladder را هم عوض کرد به role profile. این نردبان، افراد را در چهار بعد زیر می‌سنجد. چنان‌که گفته شد، اثرگذاری (impact) شرط لازم همه‌ی این بعدها است، برای سطوح پایین‌تر با شکل impact on the project و برای سطوح بالاتر به شکل impact of the project. ابعاد این نردبان:مشارکت:یک مهندس تازه کار (سطح ۳)، taskهای محول‌شده (و نه پروژه‌ی سرتاسری) انجام می‌دهد، با کیفیت و سرعت مناسب، و با مقداری راهنمایی.در سطح بعدی، کارهای بزرگ‌تر از مقیاس چندماهه را به شکل سرتاسری (end to end) از آنِ خود می‌کند یا اصطلاحا own می‌کند (به این معنی که به هر گیر و گوری خورد، مسئول حل آن‌ها به نتیجه رسیدن کار، او است)، مدیریت پروژه می‌کند، کارها را می‌شکند و پروژه را با سرعت مناسب پیش می‌برد.مهندس سطح ۵ (ارشد)، تاثیر فراتر از خود دارد، احتمالا ۳-۲ نفر دیگر را رهبری می‌کند، یک حوزه (نه فقط تک‌پروژه‌ها) را own می‌کند و به نتیجه می‌رساند، خودش منشا ایده است و صرفا ایده‌های دیگران را پیاده‌سازی نمی‌کند.در سطوح بالاتر (استراتژیست به بالا)، برای گستره‌ی بزرگ و بزرگ‌تری از افراد و تیم‌ها، جهت و استراتژی تعیین می‌کند و آن‌ها را به نتیجه می‌رساند.چالش:یک مهندس تازه‌کار، با ابزارها و فرایندهای استاندارد تیم آشنا است، و بلد است کِی دنبال راهنمایی برود (و گیر نکند).در سطح بعدی، یک گام جلوتر می‌رود و برای تیم، مسیر باز می‌کند: مساله‌ها و نیازمندی‌هایشان را شناسایی می‌کند، برای خودش و تیم، کارهای آینده پیشنهاد می‌کند، تیم را اصلاح‌مسیر می‌کند.در سطح بعدی (ارشد)، مساله‌های پیچیده و مبهم را می‌شکند و حل می‌کند (معمولا شامل چندین کارِ فراتر از کدنویسی)، و قضاوت‌های قوی و مستدل و نگاه‌های کوتاه و بلندمدت در طراحی‌هایش دارد.در سطوح بالاتر، مساله‌های بزرگی از جنس «نادانسته‌های نادانسته» را شفاف و حل می‌کند و تعیین می‌کند که سازمان روی چه مساله‌هایی سرمایه‌گذاری بکند و نکند.قدرت نفوذ:از یک مهندس تازه‌کار صرفا انتظار می‌رود که به خوبی کار تیمی کند.در سطح بعدی، با ذی‌نفعان کار، ارتباط می‌سازد و هماهنگی‌های لازم را انجام می‌دهد (یعنی منفعل نیست).در سطح بعدی (ارشد)، نفوذ و تاثیری فراتر از خودش (در تیم خود یا تیم‌های دیگر) دارد.در سطوح بعدی، روی گستره‌ی بزرگ و بزرگ‌تری از تیم‌ها و نقش‌ها نفوذ دارد، شبکه‌سازی می‌کند و آن‌ها را رهبری می‌کند.تخصص:یک مهندس تازه‌کار، حوزه کاری خودش (معماری‌ها، تکنولوژی‌ها، …) را می‌شناسد.در سطح بعدی، دست کم یک مهارت عمده فراتر از کدنویسی (یا هر آن‌چه کار روزمره‌اش است) را کسب کرده است (می‌بینیم که تعمدا اصرار به خارج کردن افراد از دایره‌ی راحتی‌شان وجود دارد).در سطح بعدی (ارشد)، در چندین زمینه چنین مهارت‌هایی از خود نشان می‌دهد، و یک مرجع قابل اعتماد در عمق یا در عرض است.در سطوح بعدی: هم در عمق و هم در عرض.حالا همین‌ها را به شکل ترانهاده‌اش ببینیم:مهندس تازه‌کار (سطح ۳) معمولا تازه فارغ‌التحصیل‌ها یا کم‌سابقه‌ها هستند. به سطح ۳ می‌توان کارهایی که بخشی از پروژه‌ی بزرگ‌تر هستند و محدوده/scope مشخص (و نه مبهم) دارند و برای تیم ناآشنا نیستند بدهید، و می‌تواند برود تا یک فصل/quarter هم سرشان مشغول باشد و فقط تا حدی سرپرستی بخواهد.در هیچ سطحی حتی تازه‌کار، ریزمدیریت/micromanagement نداریم. اگر فردی نیازمند ریزمدیریت است، باید به سرعت او را از این فضا خارج کرد - با دادن آموزش و فضا.مهندس سطح متوسط (۴)، مستقل‌تر است. می‌توان کارهای بزرگ‌تر و مبهم‌تر به او سپرد و او کار را به شکل سرتاسری از آنِ خود کرده (چنان‌که شرحش رفت) و اولویت‌بندی و مدیریت می‌کند. گاهی طراحی سیستم هم می‌کند.مهندس سطح ارشد (۵)، برای افراد دور و بر خودش هم جهت‌دهی می‌کند. تشخیص می‌دهد که برای مساله‌های بزرگ و مبهم، چه راه‌حل‌هایی مناسب یا نامناسب‌اند، و مسؤل کاملِ پیش‌بردِ یک حوزه است - از هماهنگی با تیم‌های دیگر تا ایجاد چرخه‌های تست و تنظیم کارایی و ایجاد پایش و الخ.انتظارات از سطح ۶ به بعد (استراتژیست، استراتژیست ارشد، …) به طور نمایی سخت می‌شوند و بیشتر درباره‌ی بینش (vision) هستد - در چه سطحی چه مساله‌هایی مهمه حل بشوند.به طور سرانگشتی، ۵۰٪ کارمندان گوگل در سطح ۵ به بالا و ۱۰٪ در سطح ۶ به بالا هستند.آیا تصویری که شرح بالا در بلندمدت از افراد و از سازمان می‌سازد، روشن هست؟نردبان و شرح شغلی همچنین شامل انتظارات مشترک از افراد است، مانند کار تیمی، احترام، قابل اتکا بودن، ارتباط موثر کلامی و نوشتاری، تعالی مهندسی، … مشترک یعنی همه باید با احترام رفتار کنند یا کدهای تمیز بنویسند، و کسی با احترامِ بیشتر یا کدهای تمیزتر، ترفیع نمی‌گیرد،‌ بلکه شرط لازم برای همه سطح‌ها است.کار را از آنِ خود کردن (own کردن). از انتظارات کلیدی است: یعنی مسئول به‌سرانجام‌رسیدن کار، «من» هستم. اگر مشکل پیش آمد، خودم برای رفعش اقدام می‌کنم - یا شخصا حلش می‌کنم یا افراد لازم را درگیر و پی‌گیری‌های لازم را تا تهش انجام می‌دهد. چه چیزی خلاف own کردن است؟‌ این که تا روزی که شرایط انجام کارم مهیاست، کدم را بزنم و جلو بروم، ولی وقتی به مشکلی خارج از حیطه کار مستقیمم خورد، مثلا کتابخانه‌ی دیگری آماده نبود یا یک مساله‌ای باید از سوی تیم دیگری شفاف می‌شد یا …، کار را کنار بگذارم و بگویم «pend ام»! نه، انتظار می‌رود یا از مسئولش پی‌گیری کنم، یا گزینه جایگزین پیدا کنم، یا escalate کنم، و کلا آروم نگیگیگیرم! قرار است «یا راهی خواهم یافت یا راهی خواهم ساخت» باشم. چندین شاخص هم گِرد همین مساله‌ی own کردن در نردبان تعریف شده، مانند:به سرانجام رساندن کار (و حل مشکلات سر راه) با حداقل نظارت؛عمیق شدن در تخصص‌های غیر از کدنویسی (به جای pend تیم‌های دیگر شدن)؛ارتباط کاری ساختن با انواع شرکا و ذی‌نفعان (برای حل مشکلات/اصلاح‌مسیر)؛مشخصا حل چالش‌های «سازمانی» در کنار چالش‌های «فنی»؛ یعنی این پنبه را از گوش درآورید که «قراره سازمان درست کار کنه تا من درست کار کنم».مدیریت. مدیر مهندسی (EM) و رهبری فنی (TL) دو نقش جدا هستند. EM درگیر بُعد انسانی افراد و ساختن تیم کارآمد با خروجی مناسب، و TL درگیر جهت‌دهی فنی به افراد و جلو بردن کارهاست. بر این اساس، نردبان مهندسی نرم‌افزار و نردبان مدیریت هم از هم جدا هستند و افراد انتخاب می‌کنند روی کدام نردبان باشند. ولی این جدایی آن‌قدر هم جدی نیست. اولا افرادی که روی نردبان مهندسی هستند هم می‌توانند مدیر باشند (مدیر رهبر فنی یا TLM). بنده خودم همین بودم. یعنی شرط لازم مدیریت، بودن روی نردبان مدیریت نیست،‌ بلکه نردبان مهندسی هم بندهایی دارد مانند «اگر مدیر هم هستی، فلان انتظارات تیم‌سازی و غیره هم ازت می‌رود». دوما سازمان در سال‌های اخیر به سمت حذف نقش TLM حرکت کرده و در عوض نردبان مدیریت به نقش TLM نزدیک شده.تله‌هاحکایت‌ها (anecdoteها) درباره کار کردن یا کار نکردنِ ساختارهای مشوق، فراوانند - و گمراه‌کننده. مثلا «در گوگل همه به دنبال ترفیع هستند و نه تعالی محصول» یا «سیستم گوگل منصفانه نیست و سال‌ها درجا می‌زنی» و این دست؛ من فقط مثال‌های گوگلی‌اش را بلدم ولی مطمئنم درباره‌ی بقیه هم هست. اتفاقا در موارد بسیاری، کاملا درست هم هستند. خود من، این ناکارآمدی‌ها را زیسته‌ام. بارها هم در دوراهی بین آن‌چه ترفیعم می‌دهد و آن‌چه برای محصول بهتر است، گیر کرده‌ام (در حالی که قرار بوده هم‌سو باشند). در کمیته‌ی ارزیابی صدها نفر نشسته و بحث کرده، و کارآمدی‌ها و ناکارآمدی‌های سیستم را دیده‌ام.ناکارآمدی‌هایی که به شکل حکایتی می‌شنویم، دلیل دارند و قابل اصلاح‌اند، و نباید سبب نگاه منفی کلی شوند - دیده‌ام که برخی دوستان با دیدن دو سه بلاگ به چنین نتیجه‌هایی می‌رسند. مثلا سیستم گوگل ناکارآمد است چون عموما کمیته‌هایی که ترفیع من را بررسی می‌کنند، فاصله زیادی از کار من دارند، بنابراین «آن‌چه بر اساس نردبان در چشم آن‌ها می‌درخشد» لزوما «آن‌چه برای محصول بهتر است» نیست. مثلا یک launch جدید برای همه (از جمله یک کمیته از افراد ناآشنا با جزییات حوزه کاری من) جذاب است، ولی یک نگهداری پیچیده و ارزشمند، نه. برای همین گوگل شده سازمان launch and celebrate and then forget؛ شده سازمانی که هر چه بهتر خودنمایی بلد باشی بیشتر رشد می‌کنی. این مساله در یک سازمان کوچک‌تر که افراد (و به ویژه مدیران ارشد که اعضای کمیته‌های ارزیابی هستند) با همه پروژه‌های جاری کم و بیش آشنا هستند، قابل حل است - چنان‌که تجربه‌ی این یک سال ما نشان داده.مشکلات عمده در ساز و کار گوگل که باید حواسمان باشد تکرار نکنیم، یکی همین دور بودن کمیته‌هاست؛ یکی اصلا جدا بودن کمیته‌های بررسی ترفیع و کمیته‌های ارزیابی عمل‌کرد (دوستی داشتم که شش دوره عمل‌کردی در رده «بسیار فراتر از انتظارات» قرار می‌گرفت یعنی سه سال بود که عملا داشت در سطح بعدی عمل کی‌کرد ولی ترفیع نمی‌گرفت!)؛ یکی خَلط شدن بازخورد همکار و ارزیابی همکار (peer feedback vs. peer review) که باعث شده بود افراد از هم به‌به و چه‌چه کنند به جای دادنِ بازخوردهای سازنده؛ یکی اتکای زیاد به بسته‌ی ترفیع (promo packet)‌ که افراد می‌نوشتند و سیستم را تبدیل به رقابت در self representation کرده بود؛ و یکی اتکای زیاد به خود-محوری به طوری که افراد را به رقابت به جای همکاری سوق می‌داد. گوگل سیستم ارزیابی‌اش را پیارسال کلا کوبید و از نو ساخت، و دست کم در ظاهر قرار است بسیاری از این ایرادها برطرف شوند (مثلا بازخورد همکار از ارزیابی جدا شد یا promo packet نوشتنِ افراد حذف شد)، ولی عوض کردن فرهنگ ۲۰-۱۵ ساله به این راحتی نیست. ما خودمان به طور ناخودآگاه در کمیته‌ها به دنبال شبیه‌سازی سیستم قدیم با سیستم جدید بودیم! باید صبر کرد و دید. ولی به هر حال ایراداتی که باید حواسمان بهشان باشد را هم در ذهن داشته باشیم. چشم‌بسته copy paste نکنیم. این مطلب را هم ببینید.در پایان به این تفاوت بازار ایران هم دقت کنیم که تب انگیزه‌های شخصی، اینجا خیلی پررنگ‌تر است. در گوگل برخی به دنبال ترفیع بودند و برخی نبودند؛ لنگر را انداخته و زندگی‌شان را می‌کردند. اینجا «همه» دنبال ترفیع‌اند - یک دلیل اصلی‌اش شرایط اقتصادی‌ست و نیز این تفاوت که بازه‌ی دستمزد سطح x نسب به سطح y که در گوگل شاید 1.5x تفاوت داشت، اینجا 5x تفاوت دارد.اینجا با یا بی‌نردبان، همه دنبال ترفیع بوده و هستند، که اهمیت آن‌چه در این یادداشت گفته شد را دوچندان می‌کند. باید حتما به این انگیزه‌های فردی جهت داد.

مدیریت محصول / PMگری چه هست و چه نیست؟

Kian — Thu, 11 Apr 2024 12:39:21 +0330

مدیریت محصول (PM) یک نقش نسبتا جدید است، رشته دانشگاهی نداشته، و در هر سازمانی به شکلی شکل گرفته است - در بسیاری جاها به شکل اصطکاک‌زا. در این یادداشت نگاهی به آن‌چه PMگری نیست و آن‌چه هست، می‌کنیم. بدیهیات: منظور از فلان هست و فلان نیست صرفا یعنی فلان مدل معمولا کارآمد هست/نیست، وگرنه همه در تعریف هر نقشی آزادند. همچنین نظرهای زیر، صرفا شخصی و بر اساس تجربیات محدود از یک سازمان خاص (گوگل) است.۱. مدیریت اجرای پروژهمدیریت محصول در آغاز به شکل نارستی در بازار ایران رواج پیدا کرد - گویی یعنی مدیریت پروژه. دوست عزیزی می‌گفت در آغاز که از ایران به گوگل آمده بودم، به PMهامون گفتم شما همان‌هایید که نمودار گانت می‌کشید؟ و چپ چپ نگاهم کردند که نخیر، آن «مدیر برنامه»/PgM (نام گوگلی برای مدیر پروژه) است و نه «مدیر محصول».در خیلی از سازمان‌ها می‌بینیم که مدیران محصول عملا مدیر پروژه هستند. سعی می‌کنند هفته به هفته به تیم توسعه task بدهند و خروجی بگیرند، یا حتی در یک رابطه ناسالم کارفرما-پیمانکاری فشار بیاورند تا «کارها برسد»! قضیه این نیست که آن PMها سیریش‌اند یا آن مهندسان، تنبل. بلکه آن‌ها هم فکر می‌کنند مدل default همین است. مثلا یک PM صادقانه آمده بود برای مشورت با بنده که چه‌طور می‌توانم از «دولوپرهام» خروجی بیشتر بگیرم. حتی نمی‌پرسد که «آیا» این مدل کاری، خوب است؟خیلی از مهندسان نرم‌افزار هم همین مدل را پسندیده و به حاشیه‌ی امن‌شان رفته‌اند: به من چه درگیر مدیریت پروژه یا فهم محصول شوم؛ به من task بدهید تا انجام بدهم! ولی مهندسان و رهبران فنی قرار است مسئول own کردن اجرای کار به شکل ۰ تا ۱۰۰، شامل شکستن کار و تعریف وابستگی‌ها و مدیریت taskها و الخ، و بدون نیاز به درگیر شدن PM، باشند. PM در سطح feature درگیر است و نه در سطح task.متاسفانه مفاهیم بدِ اسکرامی مانند product ownerای هم در نهادینه کردن این وضعِ مریض، نقش داشته‌اند. در حالی که شما اگر PMگری دارید دیگر باید کارهای POگری را بیرون بریزید. چرا؟ این ویدیو از ایمان، به خوبی مقایسه‌شان کرده - کافی‌ست دقیقه ۲۵ تا ۲۹ را ببینید. مفهوم PO، چه به آن PO بگویید و چه صرفا اسمش را PM کنید که عملا همان کار PO را می‌کند، صرفا نقشی برای ایجاد اصطکاک است. آن ۴-۳ دقیقه ویدیو را ببینید؛ ارزشش را دارد.اگر این مدل ناسالم را مناسب می‌دانید، که هیچ، ولی اگر مایلید بدانید در گوگل و متا و امثال آن‌ها در دره‌ی سیلیکون چه‌شکلی کار می‌کنند: رهبر فنی و رهبر محصولی، همتا/peer هم هستند و با هم در قبال رسیدن و موفقیت یک محصول، مسئول‌اند. PM هزار و یک کار مهم‌تر از مدیریت پروژه دارد.چرا این مدل که PM برای تیم توسعه، مدیریت پروژه کند، بد است؟ چون کسی که در عمق فنی نیست: چه‌طور می‌تواند بگوید «اول این task سپس این task»؟ چه‌طور می‌تواند بگوید «چرا سه هفته؟ یک هفته‌ای بزنید»؟ مهم‌تر از همه: چه‌طور می‌تواند پاسخگوی چیزی باشد که مسئولیتی در انجامش ندارد؟ نتیجه آن، فقط اصطکاک است.۲. نقش TPMاصطلاح TPM را زیاد می‌بینیم که به معنی PMای که فنی است، استفاده می‌شود. دست کم با تعریف گوگلی، TPM یعنی techincal PgM، نه technical PM! در یک شرکت tech، همه PMها قرار است فنی هم باشند، اصلا اصطلاح technical PM جدا نداریم.نقش technical PgM یعنی PgMای که کمی فنی هم هست (داشبودر می‌سازد و ...). خودِ PgM یعنی program manager یا به اصطلاح رایج‌تر: مدیر پروژه. این نقش در این یادداشت توضیح داده شده (بخش پایانی یادداشت با عنوان «مدیر پروژه/برنامه» را ببینید).در واقع نکات بخش قبل (درگیری PM در اجرای پروژه) را می‌توان این‌طور خلاصه کرد: نقش PM را با نقش TPM بسیار خَلط شده می‌بینیم، در حالی که PM و TPM هیچ ربطی به هم ندارند جز این که یک پ و م دارند.۳. چیستی/چرایی‌ها با PM و چگونگی‌ها با dev؟!این بازی با واژگان را هم زیاد می‌بینیم (به ویژه در لایه‌های مدیریت) که مثلا what ِ کارها با PM و howاش فلان؛ whyاش چی‌چی؛ و این دست. این جملات شاید گاهی برای رساندن کلیّت و «در حوزه یک پروژه خاص» معنی داشته باشند، ولی در حالت کلی (مثلا بگوییم «what ِ کارها»)، صرفا بازی با واژگان است.هر how یا whyای، یک what در یک scope دیگر است. هم مهندس نرم‌افزار درگیر what و why و how است و هم PM؛ هم مهندس سطح تازه‌کار در هر سه درگیر است و هم راهبر استراتژیست. قطعا scopeهایش فرق می‌کند، ولی از هر سه جنس هست و این‌طور نیست که «یکی درگیرِ what ِ کارها و یکی how» و این بیش‌ساده‌سازی‌ها (oversimplificationها). خیلی درگیر این بازی با واژگان نشویم.۴. اصطکاک‌های فرسایندهنسخه‌های مختلف این ادعا را از همکاران در بازار ایران زیاد می‌شنویم: «اگر کلا نقش PM را کنار بگذاریم، اتفاق خاصی نمی‌افتد و برای پیش رفتنِ کارها بهتر هم هست». چرا؟ به دلیل بدتعریفیِ نقش مدیریت محصول و تعاملات آن (به زعم بنده).از یک سو، ادعای بالا کاملا نادرست است: (اگر محصولات کلاسیک مثل نوشتنِ نرم‌افزار حساب‌داری یا اتوماسیون اداری که سر تا تهش مشخص است را کنار بگذاریم) رشد و بالندگی یک «محصولِ زنده» مانند دیوار و دیجی‌کالا و تپسی و الخ، بدون نقش مدیریت محصول اصلا متصور نیست - دست کم در ذهن بنده. منظورم بیش از آن که درباره‌ی نیاز به تیم با «تخصص» مدیریت محصول باشد، نیاز به تیم با «تمرکز» بر کارهای مدیریت محصول است. یعنی مدیریت محصول، کارِ جانبی نیست؛ شهروند درجه اول در مجموعه‌ی کارهای یک محصولِ زنده است.ولی ا یک سو، نقش PMای که بیش از آن که برای تعالی محصول آورده داشته باشد:در دست و پای کارهای روزمره‌ی توسعه نرم‌افزار است و در افق‌های کوتاه‌مدت (مثلا هفتگی) سعی در هدایت می‌کند، یانقش مدیریت پروژه برای پروژه‌ی نرم‌افزاری را برداشته و در سطح task سعی در پی‌گیری پیشرفت پروژه دارد، یاصرفا نقش واسطه‌گری (و فاصله انداختن) بین ذی‌نفعان بیزینسی و مهندسان را دارد، یا<شما اضافه کنید: کارکردهای نادرست ولی شایع در مدیریت محصول>اگر این نقش کلا حذف شود، با همه‌ی ضررش، در مجموع یک گام رو به جلو است؛ هرچند مسیر درست‌تر، نه حذف بلکه بازتعریف این نقش است.۵. پس مدیر محصول چه می‌کند؟تکرار کنم که تعاریفی که از آن صحبت می‌کنیم، صرفا از شرح شغلی/نردبان مدیریت محصول به تعریف یک سازمان خاص (گوگل) و تجربیات شخصیِ محدود، هستند. انتظارها از نقش PM به شکل سرفصل‌وار به این شرح است:طراحی محصول و تجربه کاربری، ساخت و مستندسازی نیازمندی‌ها (PRDها) برای محصولات و featureها، خلق design conceptها.تعریف نقشه راه محصولی و شکل‌دهی اهداف محصولی، تعریف منزل‌گاه‌ها (milestoneها)، پژوهشِ مسیرساز (formative research) و شناسایی gapها در بازار.تعریف متریک‌های محصولی یا بیزینسی، ارائه برنامه برای اندازه‌گیری آن‌ها، ایجاد هم‌سویی با اهداف بیزینسی، اندازه‌گیری آن‌ها.اولویت‌بندی محصولی، برنامه‌ریزی منابع، تعیین مسیر پروژه‌ها در همکاری با تیم‌های مهندسی و سایر ذی‌نفعان.ایجاد چشم‌انداز (vision) محصولیِ گیرا و جلب نظر ذی‌نفعان برای همکاری (بیزینس، مهندسی، حقوقی، …).برنامه‌ریزی ورود به بازار (go-to-market)، تحلیل اندازه بازار و فرصت بیزینسی در هر دو افق کوتاه و بلندمدت، قیمت‌گذاری در فضای رقابتی بازار.مدیریت چرخه حیات محصول، تسهیل launchها، تصمیم‌سازیِ داده‌محور برای نگهداری یا بازنشسته کردن محصولات، همکاری با تیم‌های پشتیبانی برای محصولات.توسعه استراتژی بلندمدت محصولیِ سازمان، بازبینی مستمر و ریسک‌زدایی از استراتژی‌ها.همه‌ی کارهای بالا به شکل کامل، از هر PMای در هر سطحی انتظار نمی‌رود، بلکه گستره/scope آن بسته به سطح PM فرق می‌کند. مثلا از یک PM تازه‌کار (junior) انتظار مشارکت در تعریف یک feature می‌رود؛ از یک PM ارشد انتظار تعریف کامل یک محصول؛ از یک رهبر محصولی (+L6) انتظار رهبری کردنِ شکل‌گیری جمعیِ یک چشم‌انداز و استراتژی محصولی.و اما نکته‌ی مهم‌تر: شاخصه‌هایی در مدیریت محصول هست که موارد جداگانه در لیست بالا نیستند، بلکه در یَک‌یَک موارد بالا بروز می‌یابند. دو تا از کلیدی‌ترینِ آن‌ها:انجام پژوهش کاربری (user research) و تحلیل داده و شکل دادن و اعتبارسنجی فرضیه‌ها و این دست. این تخصص‌ها مهم‌اند و قرار است هر PMای در درونش یک data analyst/آماردان هم داشته باشد. حتی ممکن است گاهی کد هم بخواند و بفهمد - و این موارد در شرح شغلیِ حتی PM تازه‌کار هم آمده.مدیریت ذی‌نفعان (از فروش و بیزینس و بازاریابی و حقوقی گرفته تا تیم‌های مهندسی نرم‌افزار)، ایجاد همسویی بین انواع واحد‌های درگیر در پروژه‌ها، و انجام همه‌ی هماهنگی‌ها. حجم این کارها در حدی‌ست که بسیاری از رهبران فنی اصلا شاکی‌اند که چرا این‌قدر به زحمت PMها را پیدا می‌کنند.درگیری در اجرا: تکرار می‌کنم که از جهت درگیری در اجرا و تحویلِ پروژه‌ی نرم‌افزاری، PMای که درگیر اجرا در ریزدانگی روز/هفته/ماه شود، عملا وقتش را تلف می‌کند - و در دست و پای تیمِ توسعه است. مشخصا این ادعا را، به جز تجربه شخصی، با چندین تن از دوستان از شرکت‌های دیگرِ دره‌ی سیلیکون هم به بحث گذاشتم و نگاه‌ها را مشابه یافتم. PM در مقیاس درشت درگیر زمان‌بندی پروژه‌های نرم‌افزاری‌ست (چه چیزهایی در پایان Q1 می‌رسند، چه چیزهایی در Q2) و آن هم برای هماهنگی و نه برای مدیریتِ پروژه. درگیری PM در مقیاس «هفته»، چیزی‌ست که در بازار ایران زیاد می‌بینیم.متوجه‌ام که بسیاری از ناکارآمدی‌ها، کشمکش بر سر قلمرو و سهم‌خواهی از پروژه‌ها و عملا جنگ قدرت و نفوذ هستند (نه تنها بین نقش‌ها بلکه در هر سطحی) - از جمله در گوگل. ولی در این یادداشت فرض کردیم ساخت‌یافته فکر می‌کنیم، آن مشکلات را جدا کردیم، و با فرض «همه به دنبال تعالی کسب‌وکارِ شرکت هستیم» درباره کارآمدیِ سازمان صحبت می‌کنیم.

مطالبی از گشت و گذار در اکوسیستم فناوری ایران

Kian — Fri, 28 Jul 2023 15:17:51 +0330

در اوایل بازگشتمون، سعادتِ این رو داشتم که دوری در اکوسیستم فناوری زدم و همچنین با دوستانی از شرکت‌های مختلف گپ و گفت داشتم و با کارها و مساله‌هاشون آشنا شدم. این یادداشت، به برخی‌شون که نسبتا شایع بودن می‌پردازه (مشاهده‌ها محدود و از ۱۵-۱۰ شرکت هست). این تکه‌ها پیش‌تر در توییتر/اینستاگرام منتشر شده و اینجا در این یادداشت جمع‌آوری می‌شه؛ یعنی دلیل عدم انسجام احتمالی، اینه. کپی با یا بدون ذکر منبع آزاده.شفاف کنم که نگاه انتقادی به این مساله‌ها، برای کمک به بهتر شدنه و نه ایراد گرفتن یا کم شمردن کارهایی که انجام شده؛ از متعالی‌ترین سازمان‌ها و محصولات دنیا هم می‌تونم صفحه‌ها نقد بنویسم. مشخصا مایلم روشن کنم که کارهایی که در اکوسیستم فناوری ایران انجام می‌شه شگفت‌آوره: با وجود این همه موانع و معضل‌هایی که هر یک به تنهایی برای سد راه کافی هست، سنگ‌اندازی‌های داخلی، تحریم‌های خارجی، بحران نیروی انسانی، همچنان چیزهایی ساخته شده که (به دید منِ کاربر) فاصله‌ی چندانی با محصولات مشابه جهانی نداره یا در برخی موارد بهتره. قطعا همیشه هم نیاز به بهبود هست.متدولوژیدر یک سری کارگاه‌های توسعه‌ی نرم‌افزار که برگزار کردم، بچه‌ها می‌گفتن در درس «مهندسی نرم‌افزار»، از چرخه‌ی توسعه (مثلا trunk based و feature branchای یا تک‌مخزنی و چندمخزنی یا بازبینی/review کد و …) یا تست قناری و تکنیک‌های پایش و غیره، خیلی گفته نمی‌شه، ولی مقدار خوبی متدلوژی و «اسکرام» گفته می‌شه - و درباره اسکرامِ ما (در گوگل) می‌پرسیدن. از نکات مشترک بین دانشگاه‌ها بود.پاسخ: نه ما و نه هیچ‌یک از ده‌ها تیمی که بنده در این ۱۰ سال در گوگل باهاشون کار مشترک کردم، «اسکرام» کار نمی‌کردن. احتمالا هستن تیم‌هایی که اسکرام کار کنن ولی مرسوم نیست - و کلا «پکیج» مدیریت پروژه اون‌قدر مهم نیست. شما هم ببینید چی براتون کار می‌کنه. گیرِ این چارچوب‌ها نباشید. ما گاهی standup روزانه گذاشتیم، تو دست و پا بود، جمعش کردیم. sprint رو یه مدل دیگه رفتیم و چند بار هم عوضش کردیم. retro نرفتیم. اون مفهوم کذایی product owner رو هرگز نداشتیم و اصلا سَم می‌دونستیم. برای ابزار هم، یکی Google sheet، یکی Kanban، یکی SmartSheet. اون‌قدر مهم نیست. غیرقابل‌بازگشت هم نیست.مدل trunk based و ادغام پیوسته (CI) و تست قناری و غیره ولی مثل مباحث مدیریت پروژه نیست، مساله‌های عینی‌تره/objectiveتره. از الان می‌تونم بهتون بگم بدون قناری چه بلاهایی سرتون می‌آد ولی بدون اسکرام احتمالا بلایی سرتون نمی‌آد. جا داره در سیلابس این درس‌های مهندسی نرم‌افزار یک بازنگری بشه.مدل taskدهییک مدل ناکارآمد در مدیریت پروژه در برخی جاها، اینه که یک «نقش» تعریف شده که به توسعه‌دهنده‌ها تکه کار (مثلا روزانه یا هفتگی) بده و تحویل بگیره. این مدل خودش بده، و بدتر این که این نقش رو هم یک فرد غیر فنی مثلا مدیر محصول (PM) یا مدیر پروژه/مدیر برنامه به عهده می‌گیره. مثلا طرف به من می‌گه ما چه‌طوری اطمینان حاصل کنیم توسعه‌دهنده کارش رو درست جلو می‌بره؟ می‌گم چرا تو؟ می‌گه پس کی؟! نمی‌دونم این تفکر از کجا اومده. شاید از اون مفهوم کذایی product owner در اسکرام. گویی توسعه‌دهنده‌ها واحدهای تک‌سلولی هستن که فقط حل مساله‌ی فنی بلدن و برای پیشرفتِ کار باید ریزمدیریت بشن.پس مدل کارآمد چیه؟ خود توسعه‌دهنده‌ها مسؤل پیشرفت کار هستن؛ ولی یه کم توضیح داره، چون می‌گن «آقا دلت خوشه و اون گوگله و توسعه‌دهنده‌هاش فرق دارن و فلان». نه، آدماش فرق ندارن. اونجا هم آدم تازه‌کار که می‌آد، در آغاز نیاز به تکه کارهای کوچک و ریزمدیریت متناوب داره. حتی اگر رهاش کنی ممکنه چند هفته روی یک compile error دور خودش بچرخه. ولی نکته اینه که موظفه به سرعت از این مدل کاری فاصله بگیره - و این خودش یک اولویت مدیریتیه (همون‌طور که پیشرفت پروژه یک اولویته).فاصله بگیره یعنی چی؟ چرا باید چنین کنه؟ چه‌طور این اولویت اِعمال می‌شه؟ نردبان. نردبان و ارزیابی رو نمی‌خوام الان باز کنم. به طور خلاصه، افراد رو شکل می‌ده. اگر می‌خوایم آچار فرانسه بشن، خود-رهبر بشن، به محصول نهایی اهمیت بدن، … موارد متناسبش رو می‌آریم تو نردبان: می‌گیم برای رشد شغلی و افزایش دستمزد و آزادی عمل و غیره، مسیرت از این شکلی شدن می‌گذره.حالا شما نردبان فنی گوگل (که کلا در دره‌ی سیلیکون هم محبوبه) رو که ببینید، تمرکز بیشتر از این که بر عمق فنی باشه بر اینه که فرد باید زودتر به جایی برسه اولویت‌های خودش رو مدیریت کنه و کارهای بزرگ رو سر تا سر (e2e) جلو ببره. نیروی صفرکیلومتر که تازه از دانشگاه می‌آد معمولا در کمتر از یک سال به اینجا می‌رسه که ریزمدیریت نخواد. قطعا در جلسه‌های ۱:۱ همیشه در جریان پیشرفت کار فرد هستیم ولی از این جنسه که «داری چه می‌کنی؟ ایول. اینم یه نگاهی بکن»، نه این که هر هفته بیاد بگه حالا این هفته چه کار کنم. همین کار رو هم رهبر فنی (TL) می‌کنه، نه PM یا مدیر پروژه.نه تنها ساز و کار ارزیابی عملکرد، افراد رو هُل می‌ده به سمت خود-رهبری، انتظار از مدیر هم همینه: کمک کنه و تو دست و پا نباشه. ریزمدیریت مثل فُحشه. از پرسش‌هایی که از همه در ارزیابی مدیرشون پرسیده می‌شه اینه که آیا مدیرت بهت فضا و اختیار عمل کافی می‌ده؟ ریزمدیریتت که نمی‌کنه؟مدیریت پروژهپرسیدن پس مدیر پروژه چیه؟ جداسازی کارهای مدیریت پروژه‌ای از رهبری فنی هزینه‌هایی داره، و در عوض انجامشون توسط خود رهبری فنی هم هزینه‌هایی داره. باید سنجید. (در اون فضایی که ترسیم شد) مدیریت پروژه در سطح کار ۱۵-۱۰ نفره معمولا توسط خود رهبران فنی انجام می‌شه، نه یک شخص سوم.ولی در پروژه‌های بزرگتر و به ویژه «بین تیمی»، کمک تخصصی مدیر پروژه / مدیر برنامه لازم و لازم‌تر می‌شه. از وظایف این نقش:مدیریت ارتباطات درونی و بیرونی درباره‌ی پیشرفت؛ نوشتن نوشتنی‌ها (مستند‌ها و صورت جلسه‌ها و ...) و کشیدن کشیدنی‌ها (جدول و نمودار و …) برای ذی‌نفعان؛ سوار بودن بر همه‌ی شاخه‌های کار؛ تشخیص موانعِ پیشرفتِ هر یک و پیدا کردن مسول و پی‌گیری؛ کشف deadlockها (مثلا این منتظر اونه و اون منتظر این) و حلّ اون‌ها؛ اطمینان از گم نشدن کارها در فاصله‌ی بین تیم‌ها؛ آموزش و کمک به رهبران فنی برای رهبری پروژه در مقیاس تیم خودشون.یک ناکارآمدی دیگه در مدیرت پروژه اینه که (عموما دوستان مهندسی صنایع) روش‌هایی که برای صنایع دیگه ساخته شده رو می‌زنن به پروژه‌های نرم‌افزاری. ولی اینجا فضا خیلی پویاتره. مثلا نمودار گانت (Gantt chart) کشیدن: من نمونه‌ای که این کار واقعا آورده داشته باشه ندیدم و فقط تو دست و پاست. تجربه‌ی بنده محدوده، شاید مثلا در پروژه‌های نرم‌افزاری کلاسیک (تحویل نرم‌افزار حساب‌داری به مشتری برای نصب) به کار بیاد. ولی در بیشتر کارهای نرم‌افزاری امروز، یک مولفه‌ی پررنگ غیرقطعیت و اکتشافی بودن هست و پویایی بالایی هست.حوزه‌های باریکیک مساله‌ی فراگیر، حوزه‌های «باریک» است که برخی برای خودشون تعریف می‌کنن؛ مثلا «BI کار»؛ «php کار». این رویکرد به یک سرعت‌گیر برای شرکت‌ها تبدیل شده - و جلوی رشد خود آدم‌ها رو هم می‌گیره و اصلا مفهوم مهندس ارشد (senior) عوض شده. متوجه تخصصی شدن کارها و این که همه چیز در «مهندس نرم‌افزار» جا نمی‌شه و مثلا گاهی نقش جداگانه‌ی data scientist لازمه هستم، ولی بحث افراط در این امره. از یک مهندس نرم‌افزار انتظار می‌ره بتونه SQL query بنویسه و داده تحلیل کنه، گراف بکشه و داشبورد بسازه، release و production بفهمه. نه از پیش، بلکه یعنی هر وقت لازم شد بتونه یاد بگیره.یک مثال بزنیم. فرض کنید یکی قرار شده یک داده رو در قالب xml تبادل کنه، ولی بگه «من json کارم و xml کارِ من نیست». حرف عجیبیه، نه؟ اگر یکی بگه «من php کارم و پایتون کارِ من نیست» هم همین‌طور عجیبه واقعا. بسیاری از این حوزه‌های باریکی که مد شده هم همین‌طور: «دیتا آنالیست»، «دیتا انجینییر»، ...بحث «کارِ من نیست» نادرسته. همه‌ی این‌ها در یک دایره هستن: مهندسی نرم‌افزار (شاید حالت عمیقشون خارج از این دایره باشه ولی دراین سطحی که رایج می‌بینم نه). بحث صرفا بحث «هزینه‌ی یادگیری» است: اگر من برم SQL یا پایتون یا مقدمات ML یاد بگیرم، یک ماه عقب می‌افتم. می‌صرفه؟ حالا سازمان تصمیم می‌گیره که یا آره یا نه. ولی همه در یک دایره‌ان.یادگرفتن مهارت‌ها/تکنولوژی‌هایی که برای پیش‌بردِ کار لازم می‌شه، از شاخصه‌های مهندس نرم‌افزار متوسط/intermediate هست و نه حتی ارشد - بر اساس نردبان تعاریف سطحِ گوگل که در دره‌ی سیلیکون هم زیاد استفاده می‌شه. حتی مهندس‌های تازه‌کار/junior هم هرچند در آغاز ازشون انتظار نمی‌ره، در عمل چنین هستن و هر مهارتی لازم بشه یاد می‌گیرن چون می‌خوان نشون بدن لایق ارتقا به سطح متوسط/intermediate هستن.نفرمایید «اونجا گوگله فرق می‌کنه». اولا از نظر کیفیت افراد، گوگل مطلقا اون تصویری که فکر می‌کنید نیست. دوما اتفاقا باید گفت «حتی» گوگل هم که حوزه آدم‌ها درش بسیار محدوده (سال تا سال فقط یک پیچ مشخص سفت می‌کنی) آچار فرانسه می‌خواد؛ در شرکت کوچکتر که انتظار گستره/breadth بیشتر هم می‌ره که دیگه هیچ.مرزهای پررنگمساله‌ی «مرزها» متاسفانه گاهی زیادی پررنگه. مثلا «من مهندس‌ام، در کار محصولی دخالت نمی‌کنم» یا «من PMام، به فنی کاری ندارم». عزیزان، «حوزه مسؤلیت» عالیه، ولی «حوزه استحفاظی» نه. مهندس خوب اونیه که محصول بفهمه و یک PM خوب اونیه که فنی بفهمه و در کار هم نظر بدن. این هم در نردبانی که در بالا گفتم، هست. با این «سیلو»هایی که برای نقش‌ها می‌سازیم، کارها ناکارآمد جلو می‌رن.فقط بحث فنی و محصولی نیست. مثلا بین «مهندس backend» و «مهندس data» و … هم هست. هم عدم علاقه از سوی شخص مثلا کدنویس هست که داشبورد ساختن یاد بگیره، هم در برخی جاهای دیدم مثلا اون تیمی که روی داده نشسته دسترسی نمی‌ده و برای خودش نقش دربانی/gatekeeper می‌بینه. این بسیار نابهینه‌ست - مواردی که حفاظت اطلاعات می‌طلبه به کنار.مثال: در زیرسازمان ما در گوگل اصلا تیمی وجود نداره که برات داشبورد بسازه. اگر لازم داری برو بساز. اون‌هایی که کارشون اینه، صرفا بهت سرخط می‌دن بری یاد بگیری.درباره‌ی کدها هم همین‌طور. برخی جاها می‌بینم هنوز مفهوم منسوخ code ownership پررنگه و این که در کدهای همدیگه کد بنویسیم، قبح داره. این خوب نیست. عموما هم رهبران سازمان‌ها طرفدار جمع شدن این سیستم هستن ولی شاید اراده‌ش کم‌رنگه.تست و QAکمی هم از QA: در دو شرکتی که بنده قدیم‌ترها کار می‌کردم (خارج از ایران) تیم QA داشتیم و مدلش خیلی ناکارآمد بود. اون مدل رو امروز هم در برخی شرکت‌ها می‌بینم. در عوض در شرکت دیگرم (گوگل) در ۱۰ سال گذشته و میان ده‌ها تیم، هیچ‌جا تیم یا عنوان QA ندیدم، جز یک مورد که خواهم گفت. مسولیت QA («اطمینان از کیفیت») به عهده‌ی خود تیم توسعه‌ست.اما ... اتفاقا تیم‌هایی هستن با تمرکز بر تست، ولی کارشون «تست کردن و bug زدن» (شکل سنتی QA) نیست بلکه توسعه ابزار و زیرساخت تست است - تست‌هایی برای اجرای خودکار در فرایندهای CI و انتشار. اگر هم گاهی تست‌هایی دستی انجام بشه، معمولا کی داره انجام می‌ده؟ خود تیم توسعه (برای مثلا debug). تعریف انواع testهای لازم روی اون زیرساخت‌ها رو کی انجام می‌ده؟ خود تیم توسعه. امیدوارم تفاوت دو رویکرد مشخص باشه.این تیم‌ها عضو زیرسازمانی با نام بهره‌وری مهندسی/EngProd هستن. تفاوت رویکرد از نام‌گذاری‌ها هم مشخصه: تیم «اطمینان از کیفیت» (QA) یا تیم «بهره‌وری مهندسی» (توانمندسازی تیم توسعه برای اطمینان از کیفیت). تست و اطمینان از کیفیت، یک بخش ذاتی از فرایند توسعه‌ست، و برای «بعدا» و «تیم دیگه» نیست، ولی مدل سنتی QA به اون سمت سوق می‌ده.اما اون مورد که QA داشت چی بود؟ تیم‌هایی که device می‌ساختن می‌دادن دست کاربر. تیم QA، کارهایی که هیچ‌رقمه نمی‌شد ساخت‌یافته تست کرد رو انجام می‌داد، مثلا واقعا باز کردن جعبه و امتحان تجربه‌ی کاربر در setup. اون تیم‌های QA هم در سطحی پایین‌تر از تیم‌های مهندسی بودن؛ استخدام غیررسمی با دستمزد کمتر چون اصلا جنس کارشون متفاوته. حتی خیلی دسترسی‌ها رو نداشتن و ما اذیت می‌شدیم یک image بهشون برسونیم تست کنن.منظور قطعا این نیست که کلا دوستان QA این سطح‌ان! مدل متفاوته. منظور اینه که بهتره بریم به سمت توانمندسازی تیم توسعه، و تست از توسعه جدا نشه مگر مجبوریم.یک مدل ناکارامد دیگه اینه که PM چون درگاه بین توسعه و کاربر دیده می‌شه، می‌شه مسؤل تست و QA. این درست نیست. اطمینان از رسیدن محصول متعالی به دست کاربر، وظیفه‌ی (همه و مخصوصا) تیم توسعه‌ست. PM درگیر اینه که محصول--که بی bug تحویل داده می‌شه--واقعا نیاز کاربر و بازار رو پاسخ بده.خلط مدیریت تیم و رهبری فنیاینجا مفهوم «مدیر تیم» و «رهبر پروژه» زیادی خلط می‌شه: گفته می‌شه کار مدیر یعنی جلو بردن پروژه‌ها! ولی یک مدل دیگه (که من ازش می‌آم) اینه که مدیر مهندسی (EM) و رهبری فنی (TL) دو نقش جداست. EM درگیر بُعد انسانی افراد (رشد دادن، تیم‌سازی، مدیریت عملکرد، …) و TL درگیر جهت‌دهی فنی به افراد و جلو بردن کار.این دو نقش، همکاری نزدیک دارن. EM بوق نیست، قطعا درگیر بُعد فنی هست و جزییات پروژه رو می‌فهمه، ولی از جنس «دنبال کردن» و نه از جنس «جهت‌دهی». نردبان (ladder) این دو هم متفاوته: EM بیشتر حولِ همون تیم‌سازی و غیره سنجیده می‌شه و ترفیع می‌گیره و TL حول جهت‌دهی و اجرای فنی.گاهی هم برخی تنشون می‌خاره (عموما به دلایل علاقه‌ی شخصی به جدا نشدن از بُعد فنی) و هر دو نقش رو به عهده می‌گیرن (TLM). من خودم این بودم و سخت بود. EM یا TL خالی، راحت‌تره. سیستم نردبان و ارزیابی جدید گوگل (از پارسال) هم به این سمت رفته که TLM کم و کمتر بشه.در ایران من اصلا EM خالی ندیدم. همه TLM هستن. برخی هم فقط TL. متوجه‌ام که برخی شرکت‌ها EM تعریف کردن ولی در واقع همون TLM هست.ضمنا TLMها مثل TLها و همکاران فردی (IC)، روی نردبان فنی‌ان. فقط در سطح‌های نردبان، یک بند کوچک هم هست که «اگر مدیر هم هستی، فلان انتظارات تیم‌سازی و غیره». وقتی اینجا همه TLMان، دو نردبان جداگانه‌ی IC و مدیر، خیلی معنی نداره.منظور این نیست که حتما مثل مدلی که توضیح دادم EM داشته باشیم، اون هم در این قحطی نیرو. ولی TLM و TL چرا: به TL اصالت بدیم. اگر فکر می‌کنیم «مدیر = مسؤل پیشبرد پروژه»، ساختار سازمانی خار در گلو خواهد شد. فصل بعدی رو ببینید. درباره‌ی ساختار سازمانی، نقش‌ها و رابطه‌ها در گوگل، این یادداشت بهتر توضیح می‌ده.سفت و سختیِ ساختار سازمانییک مساله که برای برخی شرکت‌ها مساله بوده اینه که ساختار سازمانی و روابط مدیر-کارمند خیلی اصالت داره؛ نه به معنی رییس‌بازی بلکه به معنی محدود شدن امکان همکاری دل‌به‌خواهیِ کارمندان. لزوما بد نیست، ولی بهتره مدل متفاوت (که در زیر گفته می‌شه) هم دیده بشه و تصمیم آگاهانه گرفته بشه.در ساختار سازمانی، تیم یعنی کسانی که زیر یک مدیر قرار می‌گیرن. یک مدل فکری هست که معتقده انجام پروژه‌ها باید همیشه یا حالا جز در موارد استثنایی، بر اساس این درخت باشه. یک مدل فکری هم هست که هر گروهی از افراد که خواستن (نامقید به درخت سازمانی) دور هم جمع بشن و کار انجام بدن.خوبی مدل اول اینه که منظم‌تره، برای مدیران ارشد روشن‌تره از کی چی بخوان، و برای مدیران میانی هم راحت‌تره دنبال کنن هر کسی داره خوب کار می‌کنه یا نه - چون تحت شخص خودشون کار می‌کنه. مشکل این مدل اینه که توی دست و پاست. سازمان رو، به ویژه اگر کار استارتاپی و نوآوری هست، فلج می‌کنه.در مدل دوم، یک ایده زده می‌شه (یا از بالا می‌آد)، و خیلی راحت‌تر از مدل اول انجام می‌شه. اصلا مهارت یک مهندس ارشد یا بالاتر اینه که بتونه دیگران رو برای این همکاری‌ها همراه کنه تا بتونن پروژه‌های بین تیمی انجام بدن. کارهای اثرگذارتر برای سازمان و با سرعت بیشتری انجام می‌شن. ولی در این مدل، نظم کمتره. یک یا چند نفر رهبر فنی (TL) پروژه می‌شن. ممکنه مدیر باشن یا نباشن. یک فرد می‌تونه تحت رهبری فنی کسی به جز مدیرش، کار کنه. بنابراین مدیر باید همیشه در جریان کارهای فرد با دیگران باشه تا بتونه اون رو مدیریت عملکرد کنه و در پایان فصل هم ارزیابی مستدل بنویسه: مثلا مرور کارها در جلسه‌های هفتگی ۱:۱ و هر از گاهی هم گپ با رهبر فنی مربوطه. ولی به هر حال اون مدیر، بخشی از اون پروژه نیست - و تمایلش هم همینه. کار اون مدیر از جنس در جریان بودن هست، نه جهت دادن. پاسخگوی پروژه نیست هرچند درش نیرو داره. در جلسات منظم هماهنگی پروژه شرکت نمی‌کنه.من با مدل دوم کار کردم و طرفدارشم، ولی تکرار می‌کنم به جنس کار شرکت بستگی داره. برای من، مدیرانم همیشه به کار با بقیه تشویقم کردن و خودم هم افراد تیمم رو. در اوایل مدیر شدنم، به عنوان یک «ایراد» به من گفته شد که بچه‌هات زیادی فقط با خودت کار می‌کنن و با رهبران دیگه کار نمی‌کنن. یک ایراد!خلاصه «ساختار سازمانی» و «ساختار تیم‌های برای پروژه‌ها»، دو درخت هستن که هم‌پوشانی زیادی دارن ولی خیلی جاها هم ندارن. به جای این که دومی (پروژه‌ای)، اولی (سازمانی) رو دنبال کنه، بهتره اولی، دومی رو دنبال کنه: یعنی اگر همکاری فرد با اون تیمِ دیگر، طولانی شد، رسما ببریمش اون تیم.چرا؟ ساختاری که برای پیشبرد پروژه ها شکل می‌گیره خیلی پویاست - باید هم پویا باشه و اصلا هدف همینه. ولی ما نمی‌تونیم ساختار سازمانی رو با این نرخ سریع، عوض کنیم و هر شش ماه یا یک سال مدیر افراد رو با تغییر پروژه‌ها تغییر بدیم. کل رشد فرد به این بستگی داره که مدیرش، ازش تاریخچه داره: طرف تو چه مسیری اومده جلو، و رشد در چه فاکتورهایی مونده. با عوض شدن مدیر، reset می‌شه. همچنین اون رابطه انسانی خاص که به مرور زمان بین فرد و مدیر شکل گرفته و خیلی مهمه، هر بار reset می‌شه.من گمان می‌کردم فقط گوگل/فیس‌بوک/پیروانشون، مدلِ شناورن («تیم سازمانی» کم‌رنگه) و مثلا در مایکروسافت تیم خیلی اصالت داره (بچه‌هاشون گفتن). ولی در همین توییتر از دوستان شنیدم که مثلا Azure (یک زیرسازمان جدیدشون) همون مدلِ شناوره. یعنی شاید قدیمی‌ترها هم دارن بازنگری‌هایی می‌کنن.الگوبرداری از شرکت‌های بزرگاین که شرکت‌های FAANG و MAMAA و اینا چه‌طور کار می‌کنن، زیاد ازش صحبت می‌شه و نکات آموزنده‌ای هم برای الگوبرداری داره (اگر جنبه‌ی cargo cult و تقلید کور رو بذاریم کنار). ولی یک نکته‌ی مهم که گاهی دیده نمی‌شه اینه که هر شرکتی از کجا می‌آد؛ جنسش چیه؛ دنبال چیه. چند مثال آموزنده:مثلا شرکت اَپل، قرارش بر مخفی‌کاریه. دسترسی به طبقاتشون برای خودشون هم کلی محدودیت داره (و این ما رو متعجب می‌کرد وقتی شرکت‌های همدیگه رو می‌گشتیم ولی به اَپل که می‌رسیدیم …). بنابراین این که ساختار سازمانی خیلی دست‌وپاگیرانه رعایت می‌شه (اگر تیم الف با تیم ب کار داره باید از زنجیره‌ی مدیریت بره بالا و بیاد پایین)، هرچند مدل سنتی و ناکارآمده، ولی برای این روحیه‌ی سازمانی (زیادی قاطی نشدن تیم‌ها) معنی پیدا می‌کنه. این شرکت اصالتا هم یک شرکت سخت‌افزاریه و برای همین برخی رویکردها درش متفاوته. این‌ها رو باید پیش از هر برداشتی در نظر داشت.یا مثلا در مایکروسافت، مفهوم «تیم» و «مدیر» به معنی کلاسیک، پررنگه. حتی خیلی مدیرانش «دفتر» دارن و در فضای باز نمی‌شینن (چیزی که در گوگل و فیس‌بوک عجیبه). یا بیش‌کاری ارزشه، یا حداقل «عیب» نیست؛ مثلا دیده بودم بعضیا ایمیل کاری رو تنظیم می‌کردن ۸ و ۹ شب فرستاده بشه که بگن تا شب کار کردن. اینجا باید دقت کنیم که این شرکت سن‌اش چه قدره و فرهنگش در چه دوره‌ای و تحت چه رهبری شکل گرفته. حالا الان بیل گیتس مهربون شده می‌گه پشیمونه ولی در دهه‌ی ۸۰ شِمری بوده. الان ولی جناب ساتیا گویا داره می‌ترکونه. قطعا تیم به تیم فرق داره و مثلا Azure که یک زیرسازمان جدیده فرق داره، من فقط یک تصویر کلی (و شاید نادقیق) گفتم.یا مثلا آمازون چرا اون آوازه‌ی بد رو درباره‌ی مسائل بین تیمی و تعاملات شرکت با کارمندانش داره؟ چون اصالتا از خرده‌فروشی/retail می‌آد و نه tech، و هنوز در حال پوست‌اندازیه. منظور، قضاوت شرکت‌ها نیست. واکاویِ اینه که چرا این شکلی‌ان - و هر برداشتی ازشون رو باید در کنار این پس‌زمینه‌ها دید.گوگل هم با یک ساختارشکنی‌هایی اومد و پیشروِ یک فرهنگ‌هایی شد ولی خودش بعدا فاصله گرفت ولی آیندگانش ادامه دادن - نزدیکترینش فیس‌بوک که از خیلی جهات پیشروتر هم شد (مسطح‌تر بودن ساختار سازمانی، سریع‌تر پیش رفتن کارها، …). خیلی شرکت‌های دیگر دره‌ی سیلیکون هم همین کارو کردن. خود گوگل ولی فاصله گرفت و در چند سال اخیر یک گردش به راست زده به سمت یک شرکت سنتی کلاسیک. مثلا خیلی شفافیت‌های درون‌سازمانی کمرنگ شده، پروژه‌های نظامی برداشته، فضای فکری شده زدن از هزینه‌ها (دیگه مثال نمی‌زنم آبروریزی نشه). اصطکاک‌های زیادی هم درون خود سازمان ایجاد کرده. کارهای نوآورانه سخت شده. سلسله مراتب پررنگ شده. مهمه که اگر برداشتی از گوگل داریم، هم اصلا ببینیم گوگل دنبال چیاست و ما چی، هم ببینیم آیا اصلا گوگل قدیم یا گوگل جدید.عقب بودن یک خوبی داره، این که جلویی‌ها رو می‌بینی و کلی سعی و خطا صرفه‌جویی می‌کنی. فقط کمی دقت و واکاوی لازمه. برداشت‌هایی که عرض شد بیشتر بر اساس اطلاعات دست دوم از دوستان و همکارانه و ممکنه اشتباه باشه. اگر موردی بود، اصلاح کنید یاد بگیریم.

چرا به ایران برگشتیم؟

Kian — Thu, 23 Mar 2023 00:46:36 +0330

خلاصه: تعلقاتی داریم. آمده‌ایم امتحان کنیم.این پرسش را فراوان می‌پرسند که چرا به ایران برگشتی، خیلی‌ها با تعجب و «همه دارن می‌رن» و «حتما مغزت ضربه خورده» و «حتما مجبورت کردن»، و شمارِ کمی هم با تبریک. پیش‌تر در سال ۹۴ هم یک بار مثلا برگشته بودم (به آن خواهم پرداخت). آن زمان هم برخی می‌پرسیدند چرا گوگل را رها کردی و برگشتی، ولی هم شمارِ خیلی کمتری می‌پرسیدند و هم من با اعتماد به نفس و حتی طلب‌کارانه پاسخ می‌دادم. این بار ولی نه، هم فراوان‌تر می‌پرسند و هم خودم با تعجب‌کنندگان همدل‌ترام.قضیه‌ی برگشتمدت‌ها برنامه‌ی بازگشت در ذهن داشتیم ولی عقب می‌انداختیم. بالاخره در سفری که در آذر سال گذشته (۱۴۰۱) به تهران داشتیم، هم با دیدن شادابی بیشترِ خودمان و (مخصوصا) فرزندمان در کنار خانواده‌ها، و هم با انجام گفتگوهایی با بازار کاری ایران، تصمیمان را نهایی کردیم. رفتیم از کار استعفا دادیم، خانه و وسایل را جمع کردیم و با بلیط یک‌سویه آمدیم ایران زندگی کنیم. چه کار سختی هم بود این جمع کردن زندگی!این بازگشت ما، تصمیم چندان شاخی هم نیست، چون اگر هم خیلی سخت افتاد، جمع می‌کنیم و دوباره می‌رویم. شرایط کاری‌ام شکرِ خدا خوب است و خواهان‌دار (به زعم خودم). یعنی با تکیه به این که پلِ پشت سر داریم، آمدیم. پس حتی مطمئن نیستم که «برگشتیم»، بلکه امتحانی آمده‌ایم. معمولا تا همینجای گپ، پاسخ نصف پرسندگان و تعجب‌کنندگان را می‌دهد. همچنین تنها پس از گفتگوهای مفصل با بازار کاری ایران و دلگرمی از حاشیه‌ی امن اقتصادی، آمدیم. اگر نبود، نمی‌آمدیم. سابقه‌ی کاری‌ام را در بازار مربوطه در ایران، خوب تحویل می‌گیرند، ولی این بار «شکرِ خدا» نه بلکه «شوربختانه». شرایط زندگی در کشورمان به جایی رسیده که حتی می‌مانیم-و-می‌سازیم‌ترین متخصصان میهن‌دوست هم آن آرمان را ناممکن یافته و به جریانِ کوچ پیوسته‌اند، چه رسد به این که جریان برعکسی برای آمدن و آوردن وجود داشته باشد. برای همین خوب تحویل می‌گیرند. امیدوارم ناامیدشان نکنم.خلاصه تصمیم شاخی نیست، و به معنی رو به راه بودن شرایط داخل کشور هم نیست (همین که برگشتن این‌قدر عجیب است که این یادداشت را می‌طلبد گواه است)، و شرایط ما هم قابل تعمیم یا مقایسه نیست. نه انبوهِ داخل‌نشینی که دنبال رفتن‌اند چیزی از میهن‌دوستی کم دارند و نه خارج‌نشینانی که برنگشتنی شدند. کسی که تا چند سال پیش با پس‌انداز دو ماهش لپتاپ می‌خرید و اکنون با پس‌انداز یک سالش هم نمی‌تواند، یا کسی که خانه‌دار شدن برایش حتی پس از سی سال پس‌انداز کردن و تنها نان و پیاز خوردن هم متصور نیست، باید هم برود. مقایسه نکنیم. (متوجه‌ام آنچه به کوچ وامی‌دارد تنها مشکلات اقتصادی نیست؛ اینجا صحبت صرفا از این یک جنبه است.)درباره‌ی خودمشانزده سال پیش از ایران رفتم، مستقیم پس از پایانِ دوره‌ی کارشناسی، برای درس خواندن و برگشتن؛ حتی فکر مهاجرت را هم نمی‌کردم. هدف متداولی بین «اَپلای‌»کنندگان نسل ما و پیش از ما بود، هرچند شاید امروزه نه. چند سالی درس خواندم (فوق و دکترا) و چند سالی کار کردم - در علوم و مهندسی کامپیوتر. در آخرین کارم، مدیر/TLM تیمی در سرویس نمایش تبلیغات گوگل بودم. احتمالا دست شستن از همین موقعیت شغلی هم نقشی در فراوانیِ پرسش «چرا برگشتی؟» دارد. (بگذریم که گوگل چندان تحفه‌ای هم نیست و حتی سال به سال افول کرده نسبت به آن تصویر معروفش.)یک خانواده‌ی کوچک سه نفره هستیم که در گوشه‌ای ساکت و آرام، زندگیِ حاشیه‌ی شهری می‌کردیم؛ پرنده تماشا می‌کردیم؛ کشاورزی می‌کردیم؛ مرغ داشتیم! اگر پی‌گیر صفحه‌ی اینستاگرامم بوده‌اید احتمالا آن‌ها را دیده‌اید. بازگشتمان هم یک تصمیم سه‌نفره و با حمایت همسر شجاعم است. اگر به خاطر من نبود، شاید او هم مانند همه‌ی بقیه‌ی منصرف‌شدگان-از-بازگشت می‌بود. حق هم داشت.چرا برگشتیمبرخی از آغاز برای همیشه رفتند، و برخی برای بازگشت ولی کوچِ موقتشان به مرور دائمی شد. خدا به همراهشان. کسی به خاطر محل تولدش که انتخابی هم در آن نداشته، مدیون کسی یا جایی نیست - باید بدیهی باشد ولی همچنان برخی به مهاجران احساس گناه و «پُشت کردی» می‌دهند. کوچ ما ولی دائمی نشد. از دلایلش، که زیاد پرسیده می‌شود، در ادامه خواهم گفت (که قابل حدس‌اند: خانواده و میهن) ولی خودِ دلایل، نکته‌ی خاصی ندارند: همین دلایل برگشتن، حتی برای کسانی که برنمی‌گردند هم وجود دارند. تنها وزن‌هایشان برایمان متفاوت‌اند. فضا صفر و صدی نیست. خودِ ما شاید با وجود همه‌ی دلیل‌هایی که برای بازگشت به ایران داشته و داریم (همان خانواده و میهن)، باز ول کنیم و برویم؛ گفتم که امتحانی آمده‌ایم.یعنی وقتی در ادامه با آب و تاب از فلان دلیل بازگشت حرف می‌زنم، صرفا دارم از یکی از دو کفه‌ی ترازو صحبت می‌کنم، نه این که کفه‌ی دیگر را انکار کنم. کفه‌ی دیگر، از نبودِ امنیت و آزادی و امید، از به-گروگان-گرفته-شدگی مملکت، تا محدودیت‌های اجتماعی و ارتباطی، تا تورم و آلودگی و ترافیک، نیازی به شکافتن ندارد و بنده هم ازشان ناآگاه نیستم. وزنه‌ی کمی هم نیستند و سال به سال هم سنگین‌تر شده‌اند.اما آن یکی کفه:۱. دوری از خانواده آسان نبوده، مخصوصا با بچه‌ی کوچک. هم تنهاییِ خودمان بوده—در این سال‌ها دوستانِ فوق‌العاده‌ای داشتیم ولی جای خالی خانواده همچنان بوده—هم عذاب وجدانِ ول کردنِ والدین سالخورده. امیدوارم هیچ کسی، عزیز از دست دادن در دوری را تجربه نکند. عذابش می‌ماند. نمی‌خواهیم بنشینیم و منتظر خبر بعدی باشیم. ولی البته باز بیشتر به خاطر خودمان است: ما و فرزندمان در کنار خانواده شادتر و آسوده‌تریم. (متوجه‌ام که شاید تجربه‌ی «سفر» و «زندگی» متفاوت باشد، و خوب حالا خواهیم دید.)۲. مشتاق بوده و هستم تا برای کشور مادری‌ام چرخی بچرخانم، گره‌ای باز کنم. این کار برایم اقناع‌کننده‌تر است تا مثلا کاراتَر کردن سرویس نمایش تبلیغات گوگل - نه این که دومی ایرادی داشته باشد بلکه بحث اقناع/fulfillment است. این اشتیاق، پیش‌تر شورِ «برمی‌گردیم می‌سازیم» بود ولی امروز شور چندانی نمانده. موج تخریب، حتی فقط با یک تصمیم یک‌شبه، قوی‌تر از موج ساختن امثال ماست. ولی این به معنی بی‌فایده بودنِ کارِ سازنده نیست.نخست، چرخاندن چرخی از اقتصاد مملکت یعنی دو نفر بیشتر، نان به سر سفره ببرند. (همین هدف کوتاه‌مدت، ارزش است، ولی هدف بلندمدت، آزادی و بهبود بلندمدت و «بقاپذیر» در اوضاع کشور هم، از همین مسیر می‌گذرد، ولی قصد باز کردن بحث‌های علوم اجتماعی آن هم در این فضای احساسی و رادیکال را ندارم.)دوم، حتی در همین اوضاع هم باید ساخت، هم برای امروز و هم (مخصوصا) برای فردا. ساخته‌ها می‌مانند. حاکمان می‌آیند و می‌روند ولی پیشرفت‌ها می‌مانند. ارج و پارس و مینو، ماندند. البته کار بنده، توسعه‌ی سیستم‌های نرم‌افزاری کجا و کارخانه‌ی ارج کجا، تقویت جامعه کجا! صرفا در حد وُسعم تلاشی می‌کنم - دو سطل آب سهم من در پر کردن این چاه.متوجه‌ام که اینترنت نیست، نیروی کار نیست، در عوض سنگ‌اندازی و باج‌خواهی هست، اوضاع فعلا رو به بهبود نیست. ولی با منفی‌ترین نگاه هم (که مطلقا نمی‌شود کاری کرد؛ که می‌شود)، در یک مثال دراماتیک: برای بیماری که رو به بهبود نیست، کنارش بودن و مثلا ناخن‌هایش را کوتاه کردن برای من اقناع‌کننده‌تر است تا رهایش کردن - یا از راه دور نسخه درمان‌های شبه‌علمی پیچیدن.۳. از زندگی در سرزمین مادری لذت می‌برم. همه‌ی مشکلاتش سرِ جا، ولی لذت هم می‌برم؛ از زبان فارسی؛ از جَو شلوغی نوروز؛ از آلبالو و گوجه سبز؛ از سفر به چهار گوشه‌ی ایران؛ از زندگی در میان کسانی که از یک جنس‌ایم. البته از زندگی در سرزمین نامادری هم لذت برده و از آن متشکرم. همچنین آگاهم که روی دیگرِ آلبالو و گوجه سبز، خِفت شدن به خاطر یک گوشی موبایل و فحش خوردن به خاطر یک ترمز و تحقیر شدن به خاطر متفاوت اندیشیدن است. ولی چنان‌که گفتم، داریم از وزنه‌های یکی از دو کفه‌ی ترازو حرف می‌زنیم.دو کفه‌ی بسیار سنگین هستند و اصلا تصمیم آسانی نبوده و نیست.چرا الان؟پس کی؟ هر وقت اوضاع درست شد - یا به قول معروف «آخوندا رفتن»؟ آخوندها فعلا جایی برو نیستند، فقط این عمر ماست که سال به سال می‌گذرد و پیر می‌شویم و آرزوی بودن با خانواده و میهن بر دلمان می‌ماند. حالا دست کم امتحانش می‌کنیم.این تصمیم، برای الان نیست. چندین بار عقب افتاد. همان سال ۹۴ هم که آمدم و پس از یک سال رفتم،‌ رفتم که مدتی بمانم و بُنیه را برای بازگشت دائمی قوی‌تر کنم و باز به ایران برگردم. روزگار چرخ زیاد خورد و خیلی چیزها هم برای ما و هم برای کشور عوض شد. برنامه‌ی ما هم کمی عوض شد. خلاصه‌اش این که از سنگر «برمی‌گردیم» رسیدیم به «امتحانی برمی‌گردیم».فیل در اتاقاوضاع کشورمان خوب نیست. بالاتر توضیح دادم که چرا در همین فضا هم باز باید ساخت. اما علاوه بر اوضاع کشور، اوضاع خودمان هم خوب نیست. فضا بسیار قطبی شده. عده‌ای واقعا معتقدند ساختن که هیچ، باید خراب و خراب‌تر کرد و گلوی ملت را فشرد تا فروپاشی شود و بلکه از آن خیری درآید؛ هر کمکی به بهبود چرخ اقتصاد و کیفیت زندگی ملت یعنی کمک به ادامه‌ی اوضاع کنونی؛ تنها راه خروج، له شدن بیشتر و بیشتر ملت! به همین پَرتی. (پس چه؟ پاسخ یک‌خطی نداریم ولی پرسش این‌قدر کلیدی هست که حوصله‌مان را زیاد کنیم و کمی از سرگذشت ملت‌هایی که رها شدند و نشدند، توسعه یافتند و نیافتند، بخوانیم، از آمریکای جنوبی تا آفریقا تا همین بیخ گوشمان. اگر حوصله تحقیق در انقلاب مصر و خواندن فوکویاما و عجم‌اوغلو نیست، شاید پادکست مختصر و مفید «دغدغه ایران» مفید باشد. قرار بود وارد بحث‌های سیاسی و علوم اجتماعی نشوم ولی اجتناب از فیل در اتاق، سخت است.)برگردیم به بحث: عده‌ای واقعا معتقدند کمک به کسب و کارهای ایرانی یعنی بقای ظلم (!) و شاید بازگشت ما به ایران را هم در همین راستا تعبیر کنند! عده‌ی دیگری واقعا معتقدند کشور رو به پیشرفت است (لابد به خاطر چهارتا موشک!) و شاید بازگشت ما را در آن راستا تعبیر کنند: ببینید نخبه‌ها (!) در حال بازگشت‌اند. کاش هر دو گروه بیدار شوند.سخن پایانیپیش‌تر، هم خودم ذوق بازگشت داشتم و هم اطرافیان را به این کار دعوت می‌کردم - بیایید بسازیم. بیایید نفری یک سطل آب بریزیم این چاه پر شود. اما فعلا که چاه در حال عمیق‌تر شدن است، رغبتی برای دعوت ندارم. فقط دوست دارم خودم به آنان که به همین هدف مشغول‌اند کمک کنم، حتی موقت. فعالیتم در فضای مجازی هم، اگر پی‌گیر کانال‌های بنده بوده‌اید، همین بوده. احتمالا به زودی در یک شرکت مشغول به کار شوم ولی علاقمندم در کنارش با ده‌ها شرکت دیگر هم مراوده و گفتگو داشته باشم، اگر برایشان آورده‌ای داشته باشد.شاید در پی بازگشت ما به ایران، حمله‌ها یا تهمت‌هایی زده شود. به علی شریفی بیچاره (سال‌بالایی ما در دوره‌ی کارشناسی بود و الان استاد همان دانشکده) که فقط گفته بود «به hiring manager فیس‌بوک گفتم می‌خوام ایران بمونم» زده شد، پس دور از ذهن نیست به بنده که مثلا «از گوگل برگشتم ایران» هم زده شود. امیدوارم این یادداشت کمکی به چنین سوءتفاهم‌هایی هم باشد: نه آقا ما نگفتیم اوضاع ایران خوب است، از قضا خیلی هم بد است، ما فقط خواستیم به تعلقات شخصی‌مان برسیم. هیچ‌یک از کسانی که رفته‌اند یا می‌روند هم را قضاوت نکرده و نمی‌کنیم و حتی توضیح دادم که چرا بازگشت ما نباید وسیله‌ای برای چنین قضاوتی باشد و شرایط هر کس متفاوت است. کسانی که می‌روند، حق دارند. من هم بودم (شرایط کنونی را نداشتم)، می‌رفتم. متاسفانه آن‌قدر فضا احساسی و پر از خشم است که باید چنین توضیح واضحاتی را پیش‌دستانه داد.پیوست: چند نظر متداولپایین‌تر توضیح می‌دهم چرا این پیوست را نوشتم.ولی همه‌ی شرکت‌هایی که در ایران فعال‌اند رانتی‌اند؛ اگر رانتی نبودند سرپا نبودند. بله بسیاری رانتی‌اند، و بسیاری هم نیستند. البته احتمالا باجِ زور ازشان گرفته شده یا خواهد شد، ولی «همه رانتی» ادعای گزافی‌ست. بسیاری هم هستند که آسه می‌روند و آسه می‌آیند و در حد وسع خودشان مقاومت هم می‌کنند و حداقلی می‌دهند. متوجه‌ام که سیستم معیوب است. ولی چه کنند؟ همه تعطیل کنند چون شهر در اختیار پدرخوانده‌هاست؟ چیزی عوض می‌شود؟‌ آن پدرخوانده‌ها خوشحال هم خواهند شد - بارها به این را به فعالان اکوسیستم یادآوری هم کرده‌اند («همه‌تان را جمع می‌کنیم»). سرویس‌هایی که می‌دهند هم، از تاکسی تا فروشگاه تا تبلیغات، به هر حال نیاز جامعه است. روزی مزیت رقابتی کشور هم خواهد شد، اگر این تنگ‌نظران شرّشان کم شود.فلانی عامل خودشان بود که برگشت پیششان، قبلا هم دستی در محدودسازی اینترنت داشته. درباره‌ی بازگشت یک‌ساله‌ام در سال ۹۴ پیش‌تر نوشته‌ام. خلاصه‌اش این که یکی از شرکت‌هایی که با آن همکاری کردم، چند سال بعد منسوب شد به نقش داشتن در کارهای ناصواب (تحلیل ترافیک و فیلترینگ) و این اتهام تعمیم داده شد به هر کسی که در هر برهه‌ای از زمان روی هر پروژه‌ای در آن شرکت کار کرده! فضای سال ۹۴ خیلی با امروز متفاوت بود، هم سال برجام و خوش‌بینی بود و هم برخی اتفاق‌هایی که بعدها و به ویژه از ۹۸ به بعد افتاد، نیفتاده بود. اگر امروز به سال ۹۴ برگردم از همان پروژه (که از قضا سازنده بود) و از هر پروژه‌ی دولتی دیگری هرچند خوب و مثبت، دوری می‌کنم. ولی به هر حال عده‌ای امروز سرشار از خشم سرگردان‌اند و دنبال یک گلو برای فشردن، با ربط یا بی‌ربط.در گوگل آینده‌ای نداشت / اخراج شده بود و برگشت. نه از جهت بزرگ کردن خود، بلکه از این جهت به این نظر می‌پردازم که مایلم این پیامِ بازگشت بنده (مخصوصا برای فعالین داخل کشور) تحریف نشود: «یک نفر که اوضاعش در گوگل خیلی هم خوب بود برگشت به ایران».به قیمت مقداری تعریف از خود (ببخشید): یک مدیر رهبر فنی/TLM در سطح ۶ (سطح ۵/senior یعنی تقریبا ۵۰٪ بالای گوگل و سطح ۶/staff یعنی ۱۰٪ بالا) و رو به رشد هم بودم و به گفته‌ی مدیرانم از سرآمدهای زیرسازمانمان. مشخصا وقتی قصدم برای جدایی از شرکت را با آن‌ها در میان گذاشتم سخنانی مانند «کسی که حتی به اندازه‌ی نصف تو خوب باشد هم پیدا نخواهیم کرد» و «رفتنت یک فقدان بزرگ برای زیرسازمان ما و کل گوگل خواهد بود» و (علی‌رغم تاکیدم که این یک تصمیم به دلایل شخصی و نه کاری و مالی‌ست) «چه کاری هست که بشود انجام داد تا تو تصمیمت را عوض کنی»، پاسخشان بود. لطف داشتند و برخی‌اش را در صفحه‌ی لینکه‌داینم هم نوشته‌اند. خیلی تعریف از خود شد، ببخشید، ولی گفتم چرا.من همچنان (در زمان نگارش این یادداشت) کارمند گوگل هستم، تا حدود سیزده‌به‌در. در مرخصی هستم و قرار است در روز آخر در دفتر دبی سر کار بروم - اجازه‌ی آوردن سخت‌افزار شرکت به ایران را نداریم. قصدم برای جدایی از گوگل تا پایان فصل را از همان آغاز فصل (ژانویه) اعلام کردم و بعد که تعدیل‌های گوگل پیش آمد و می‌توانست چندین ماه حقوق و مزایا برایم داشته باشد، درخواست و خیلی هم پی‌گیری کردم، ولی جور نشد. (اگر به موضوع تعدیل‌ها و اثرش در شرکت علاقمندید در هایلایت‌های صفحه‌ی اینستاگرامم هست.)مجبورت کرده‌اند برگردی / از خودشان هستی. اجباری از سوی جایی نبوده. حتی تشویق هم نبوده جز چند نفر تک و توک. علاقه شخصی بوده. در این سال‌ها به همه‌ی دوستانی که در سفرها به شرکتشان سری زده و گپ و گفتی داشتیم گفته بودم برمی‌گردیم. حتی پی‌گیری می‌کردند. آن طرف هم تکراری‌ترین شوخی رایج دوستانمان در این سال‌ها این بوده که تا آخر امسال ایران هستی دیگه؟ (چون می‌گفتم برمی‌گردیم.) اگر پی‌گیر فعالیت‌های فضای مجازی‌ام بوده‌اید هم احتمالا سرنخ انگیزه‌های بنده دستتان هست.اوضاع مملکت آن‌قدر خراب است که نه خواهی توانست کاری کنی و نه اگر بکنی فرقی می‌کند. توضیحش را در بخش «چرا برگشتیم» دادم. به زبان دیگری تکرار می‌کنم: اگر شرایط عوض شد، آنچه ساخته‌ایم سرمایه‌ی آینده‌ی روشنمان می‌شود و به جای صِفر از کمی جلوتر شروع می‌کنیم؛ اگر نشد، گره‌ای باز کرده‌ایم و چرخی چرخانده‌ایم و دغدغه‌ی نانی رفع کرده‌ایم و این خودش هم به تنهایی ارزش است و هم قطره‌ای در راستای عوض کردن شرایط.توضیحات بالا را برای همان هدف حفظ پیام و جلوگیری از تحریف که گفته شد، برای دوستانی که گوش شنوایی دارند دادم. وگرنه قضاوت برای عموم، آن هم در این فضای خشم‌آلود، آزاد است.

معرفی کانال ویدیوها

Kian — Wed, 08 Sep 2021 21:54:09 +0430

اگر پی‌گیر کانال ویرگولی بنده بوده‌اید، مخاطب این خبر هستید. پس از تقریبا یک سال از این برنامه‌ی امتحانیِ تبادل تجربه به شکل متن در ویرگول/توییتر، از مدتی پیش ادامه‌ی فعالیت بنده بیشتر در قالب ویدیو در یوتیوب/اینستاگرام جریان دارد‌ تا اینجا؛ تا ببینیم این یکی چه‌طور پیش می‌رود.چه فعالیتی؟ این معرفی را ببینید (و ورق بزنید).آدرس کانال‌ها:اینستاگرامیوتیوبهم‌گام‌اند، یعنی اگر تنها یکی را دنبال کنید کافی‌ست.

تجربه‌ی شکست‌خورده‌ای در پایشِ خطا

Kian — Fri, 06 Aug 2021 19:12:46 +0430

هر کدی پُر است از حالت‌های «نباید رخ دهد»: این ورودی تابع نباید null باشد؛ اندازه‌ی این لیست و آن لیست باید همیشه برابر باشد؛ ... برخی از این حالت‌ها معمول‌اند و خوش‌خیم، و برخی نه.مثال خوش‌خیم: در ورودی که از طرف کاربر می‌آید، هر چیزی ممکن است. برنامه تنها باید آن را هضم کند، مثلا رد کردن درخواست. چنین حالتی نشان‌گرِ bug در سیستم ما نیست.مثال بدخیم: در داده‌ای که سِرور الف از سرور ب می‌گیرد، شما که کُد الف را نوشته‌اید مطمئنید که فلان field داده، در هر شرایطی نوشته خواهد شد. پس نبودِ آن در ب، یعنی bugای در سیستم. یا مثلا «سازگاری» بین داده‌ها، مثلا اگر فلان متغیر بزرگتر از صفر است پس حتما باید فلان متغیر دیگر هم set شده باشد (چنین وابستگی‌هایی بسیار مکروه است)، قرار نیست به هم بخورد مگر bugای در جایی از سیستم باشد.برای این حالت‌های بدخیم، یعنی حالت‌های «منطقا هرگز نباید رخ دهد» چه می‌کنید؟ مشخصا این یادداشت درباره‌ی «کشف و خبررسانی» این حالت‌هاست، یعنی از پیش حالت خطا را پیش‌بینی و برایش در کُد چاره کرده‌اید (مثلا رد کردن درخواست)، ولی مهم است که از bug خبردار شوید تا به آن رسیدگی کنید. برای این بخش دوم چه می‌کنید؟آیا با مشت آهنین assert با آن‌ها برخورد می‌کنید تا jobها بمیرند و خبردار شوید؟ در ابزار (tool) شاید، ولی در یک سرویس سَرپا نه. سرورها باید همیشه زنده بمانند، وگرنه ممکن است همه «هم‌زمان» پایین بروند: تصور حالتی که ماشه‌ی چنین فاجعه‌ای را می‌چکاند سخت نیست.آیا log error می‌زنید؟ ولی log برای پایش (monitoring) نیست. log برای ذخیره‌ی اطلاعات اضافی است که اگر (و تنها اگر) به روش‌های دیگر از خطا باخبر شدید به آن مراجعه کنید؛ باید بدیهی باشد چرا. آیا exception می‌زنید؟ آن هم مانند log error.آیا در کنار log زدن، یک شاخص (metric) شمارنده هم می‌گذارید که به بیرون از سرور صادر شده و سپس سیستم پایش مثلا Prometheus آن را تجمیع کند و هر وقت بزرگتر از صفر شد هشدار دهد؟این آخری، تقریبا درست‌ترین کار است. ولی این روش به اندازه‌ی کافی «رادَست» نیست. باید کُدش را بنویسید و سپس در سیستم پایش برایش تجمیع و هشدار تعریف کنید در حالی که بیشترِ توسعه‌دهندگان اصلا بخش دوم را بلد نیستند و قرار هم نیست همه بلد باشند. همین باعث بی‌میلی و تنبلی افراد در این کار می‌شود و حالت‌های مهم خطا، مسکوت می‌ماندند؛ دست کم برای ما چنین بود.ما چه کردیمحل این یک مساله‌ی از دید تکونولوژی بسیار ساده است، ولی از دید رویه‌ای و فرایندی، نکته‌هایی دارد: هشداردهی درباره‌ی شرط‌هایی که نقضشان در کد حاکی از یک bug است در سیستمی با هزاران توسعه‌دهنده و ده‌ها تیم featureای و زیرساختی.ما آن را به این شکل مثلا حل کردیم: مشخصا حالت‌های «این فرض (invariant) هرگز نباید نقض شود و رخ دادنش ناموسی‌ست - درستیِ سرویس در خطر است و باید فورا رسیدگی شود» که مهم‌تر و حیاتی‌تر از بقیه‌ی حالت‌ها مانند «این فرض هرگز نباید نقض شود ولی حالا یکی دو بار اشکال ندارد» و «این فرض هرگز نباید نقض شود ولی حالا اتفاق خاصی هم نمی‌افتد» است جدا شد، و برای آن حالت ناموسی، کتابخانه‌ای و دفتر و دستکی تعریف شد به نام invariantها (به معنی پایا و دگرش‌ناپذیر). موارد کاربردش از نامش واضح است. برای استفاده، توسعه‌دهنده صرفا یک تابع فرامی‌خواند و شرطِ همیشه درست (مثلا برابری طول دو لیست که نقض این شرط حاکی از یک خطای ناموسی‌ست) و اطلاعات اضافی (برای پیغام خطا) و غیره را به آن می‌دهد و بقیه‌اش به عهده‌ی کتابخانه است - تجمیع در سامانه‌ی پایش و غیره. از نظر فنی، کتابخانه‌ی ساده‌ایست. پیچ و خمِ ماجرا، فرایندی است.یک: چنین چیزی باید بین صدها/هزاران توسعه‌دهنده جا می‌افتاد، ولی تمایزی که در بالا یاد شد (میانِ حالت‌های هرگز-نباید مهم و نامهم)، خیلی بدیهی نیست و نیازمند فکر عمیق از سوی توسعه‌دهنده است - و همین یعنی خطازایی.چنین چیزی از پیش توسط طراحان کتابخانه دیده شده بود، و مستندسازی‌های کافی و حتی یک شورای بازبینی (که اگر یک changelist کلا حاوی یک invariant بود حتما یک نفر از این شورا را به بازبینان/reviewerها در سیستم بازبینی کد (مثلا gerrit) اضافه شود) تعبیه شده بود تا فرهنگ این invariantها در سازمان جا بیفتد. فرهنگ یعنی چه؟ یعنی توسعه‌دهنده بفهمد که هر «نباید»ی لایق invariant بودن نیست؛ هر invariantای باید حاوی اطلاعات کافی برای واکنش از سوی شخص هشدارگیرنده باشد؛ و این دست استانداردها.دو: خواننده کنجکاو باید تا اینجا برایش سوال شده باشد که «هشدارها به چه کسی می‌روند؟». در یک سرویس کوچک و یک تیمِ همه با هم آشنا و همه به همه‌ی سیستم آگاه، مشکلی نیست اگر جعفر یک invariant بنویسد و هشدارش به هم‌تیمی‌اش کامبیز که گوش‌به‌زنگ (oncall) است برود. ولی در یک سیستم بزرگ و برساخته از چندین سرویس و ده‌ها تیمِ زیرساختی و محصولی چه؟فقط برخی تیم‌ها (تیم‌های زیرساختی‌ها بیشتر، تیم‌های محصولی کمتر) چرخه‌ی گوش‌به‌زنگ دارند. اگر من از تیمی که ندارد، یک invariant تعریف کردم، هشدارش به چه کسی برود؟ قرار شد به تیمِ نگهداری‌کننده‌ی سروری برود که کد روی آن اجرا می‌شود و invariant روی آن نقض شده - بی‌ربط هم نیست چون تیم‌های دیگر که در سرور الف کد اضافه می‌کنند همیشه توسط نگهدارندگان سرور الف بازبینی می‌شوند و نگهدارندگان الف کم و بیش در جریانند.بسیاری از invariantها در نقطه‌ی الف شکار می‌شوند ولی ناشی از یک bug در جای دیگری پیش از رسیدن به الف هستند. کجا؟ از پیش معلوم نیست. پس هشدار به چه کسی برود؟ چاره‌ای نیست جز نگهدارندگان الف.سه: تیم‌ها باید می‌پذیرفتند تا این تکنولوژی را در کدهایشان به کار گیرند. برخی تیم‌ها استقبال کرندند ولی برخی بی‌میل بودند؛ یا به کار گرفتند و سپس پشیمان شدند و در پیِ حذفش برآمدند. ولی خلاصه با حمایت و چانه‌زنی رهبران، در سازمان ماندنی شد.چرا شکست خوردهعلی‌رغم همه‌ی مستندسازی‌ها و شواری بازبینی و غیره، باز در ذهن توسعه‌دهندگان جا نیفتاد که invariantها صرفا یک سازوکارِ رادَست برای «خبررسانی» نیستند - یک ساز و کار برای «محافظت از سیستم» در برابر خطاهای مهم هستند. قرار نیست شما چون صرفا حدس می‌زنید فلان فرض نباید نقض شود، invariant تعریف کنید و با خود بگویید حالا اگر هم شد، شد و چه بهتر: شخص گوش‌به‌زنگشان خبر می‌شود و به من خبر می‌دهد. این تمایز در ذهن همه‌ی توسعه‌دهنده‌ها جا نیفتاد. آیا از آغاز معلوم بود که جا نمی‌افتد؟ نه چندان. به نظر این قدر سخت نمی‌رسید.برای برخی، تمایز جا افتاد، ولی نمی‌شد از پیش اهمیت یک حالت «نبایدی» را دقیق دانست. تعریف «فرضی که حتی یک بار هم نباید نقض شود» در تئوری شیک است ولی در عمل نمی‌توان تمایز آن با «هرگز نباید نقض شود ولی اگر تک و توک در هزاران درخواست بود، سیستم در خطر نیست» را از پیش دانست (یعنی هنگام نوشتن کد). آیا از آغاز معلوم بود که نمی‌توان؟ بله و نه. دودستگی بود؛ برخی می‌گفتیم «بابا نمی‌شه» و برخی (از جمله رهبران وقت) می‌گفتند «چرا می‌شه».نویسنده‌ی invariant و گیرنده‌ی هشدار، معمولا از دو تیم متفاوت‌اند. این هم در طراحی دیده شده بود و یکی از نکات مهم invariant نوشتن این بود که پیغام خطا حاوی اطلاعات لازم برای واکنش و debug باشد. ولی اصلا شدنی نبود که از پیش این اطلاعات را فرموله کرد. عمده‌ی پیغام خطاها بهتر از این نمی‌توانست باشد: «اگر این invariant نقض شد یعنی جایی پیش از این نقطه‌ی کد، یک اشکال هست»! آیا از آغاز معلوم بود که نمی‌شود اطلاعات debugی کافی را فرموله کرد؟ در برخی نمونه‌ها می‌شد و همان‌ها رهبران فنی را به سوی خوشبینی سودار/biased کرده بود.نهایتا invariantها از حالت «فوریتی» و «همیشه page کن» پایین آمدند چون نویزِ هشدارها خیلی بالا بود. شدند صرفا ticket. ولی در همین حالت هم، گوش‌به‌زنگ‌ها شاکی بودند و هستند چون کارشان شده صرفا یادآوری و پی‌گیری از تیمِ صاحب feature. یک وضعیت خراب.از طرفی همین invariantها با وجود این نابهینگی‌های فرایندی، کاملا هم بی‌خاصیت نبودند و مشکلات مهمی برای ما کشف شد که اگر سیریش شدنِ گوش‌به‌زنگ‌ها به تیم صاحب feature نبود شاید نمی‌شد. این شده که فعلا مانند ارّه‌ی گیرکرده هستند ولی چون قابل تحمل‌اند و خیلی درد ندارند، اصلاح این وضعیت بارها در جلسه‌های برنامه‌ریزی و OKR بحث شده و هر بار بی‌نصیب مانده.

دردسرهای مهاجرتِ فراتیمی بین سیستم‌ها

Kian — Sun, 01 Aug 2021 23:11:24 +0430

زیرشاخه‌ها و تیم‌های مهندسی گوگل نسبتا نامتمرکز و خودمختار کار می‌کنند، مانند مدل ایالتی آمریکا. تغییرات زیرساختی بزرگ در سطح کل شرکت را در نظر بگیرید، مثلا منسوخ کردن BigTable و رفتن به Spanner (دو تکنولوژی ذخیره‌سازی داده، یکی در الگوی NoSQL و یکی در الگوی جدید NewSQL). چنین تغییراتی، نیازمند بازنویسی‌ها و مهاجرت عمده‌ای از سوی تیم‌های client مثلا maps و search و ads و الخ است، گاه یک برنامه‌ی مهاجرت ۲ ۳ ساله که تیم‌ها باید از منابع انسانی‌شان خرج آن کنند، و خوب نمی‌کنند مگر این که واقعا ضرورتش جا افتاده باشد.مثلا در مثال بالا، تیم‌های زیرساختی مسؤل BigTable و Spanner می‌روند و با تیم‌های متاثر گفتگو می‌کنند و تخمینی از زحمت لازم به دست می‌آورند و همچنین دلایل این منسوخ‌سازی را توجیه می‌کنند (مثلا پیچیدگی نگهداری از دو سیستم موازی) و اگر واقعا ضروری باشد، یک تصمیم فراتیمی گرفته شود.یک مشکل اساسی که در این زمینه داریم، تعداد زیاد این تغییرات است؛ یک روز زیرساخت ذخیره‌ی فلان و یک روز سیستم مدیریت فلان و یک روز کتابخانه‌ی فلان و ... اصلا جوک-واقعیت معروف در گوگل این است که سیستم قبلی منسوخ (deprecate) شده در حالی که سیستم جدید آماده نیست.یک مشکل دیگر، افتادن هزینه به پای تیم‌های client است و نهایتا بسیاری از مهاجرت‌ها نصفه می‌مانند. مثلا از روزی که اینجا به یاد دارم (۹ سال پیش) قرار بوده تیم‌ها برای پایش از سیستمی به نام Borgmon (معادل Prometheus) به سیستم جدید پیشرفته‌تری به نام Monarch مهاجرت کنند، ولی هنوز برخی نکرده‌اند یا در حالت بینابینی مانده‌اند.یک قانون سرانگشتی برای حل این معضل این شده که در هنگام طراحی یک مهاجرت یا منسوخ‌سازی، ۸۰٪ کار باید متمرکز قابل انجام باشد، مثلا آماده کردن ابزار خودکارسازی یا APIهای میانی، و تنها ۲۰٪ روی دوش تیم‌ها.بسیاری مهاجرت‌ها هم با پیروزی انجام شده. ولی نهایتا هنوز در این زمینه اوضاعمان خراب است و در مواردی، برای سال‌ها سیستم‌های موازی داریم.

گرایندر و کولا، دو خرس محبوب ونکوور

Kian — Sun, 01 Aug 2021 23:08:10 +0430

در بالای کوه گراوس در ونکوور کانادا (جایی که بنده مدتی دانشجو بودم)، دو خرس گریزلی به نام‌های گرایندر و کولا در محوطه‌ای محصور زندگی می‌کنند. این دو در تولِگی یتیم شدند؛ مادر یکی را کامیون زده بوده و دیگری را یتیم و ضعیف در طبیعت یافته و نجات داده بودند (ولی نباید). اما هیچ باغ وحشی برایشان جا نداشت. گفتند به جای این که معدومشان کنیم چالش را به فرصت تبدیل کنیم و برایشان در کوه گراوس (که یک مقصد توریستی با تله‌کابین و جاذبه‌های دیگر است) یک پناهگاه زندگی ساختند. هم کمک شایانی به گردشگری این کوه می‌کند و هم فرصتی برای آموزش بازدیدکنندگان درباره‌ی همزیستی با حیات وحش است.خودم هم ۱۲ سال پیش مدتی آنجا کار داوطلبانه می‌کردم که جذاب‌ترین شغل عمرم بوده. حیف که گوگل پول بیشتری می‌دهد. از جالب‌ترین بخش‌هایش عسل دادن به خرس‌ها بود. آن موجودات با ابهت، از نزدیک فقط دو نوجوان بازیگوش بودند با کلی اَخ و تف و بوی گند دهان. الان البته ۲۰ سالشان شده و پیرند.خرس‌های گریزلی، همان که در فیلم «بازگشته» (Revenant) بود و دی‌کاپریو را جر داد، گونه‌ای بزرگ‌تر و تهاجمی‌تر از خرس‌های سیاه هستند که کوچکتر و ترسوترند و در آن منطقه با ساکنین شهر همزیستی دارند. خرس‌های گریزلی به نوعی هم فامیل دورِ خرس‌های ایران (خرس قهوه‌ای سوریه‌ای) هستند.چه در اینجا و چه در کوه‌های ایران اگر با خرس روبرو شدید، نخست باید جنس رویارویی را تشخیص دهید - آیا شما را تهدیدی برای توله‌هایش می‌بینید یا تهدیدی برای دسترسی به غذا یا به عنوان خودِ غذا. در دو حالت نخست، می‌توانید خود را به مردن بزنید ولی در حالت سوم (که نادرتر است) مطلقا نه! همچنین از حالت پنجه به خاک کشیدن و بخار از بینی دادن می‌توانید بفهمید که خرس در حالت تدافعی است و نه تهاجمی: پس عقب عقب حرکت کنید و هرگز به او پشت نکنید. مهم‌ترین کار این است که دست‌ها را بلند کنید و تکان دهید تا بزرگتر دیده شوید و با صدای بلند و محکم (نه لزران) سرش داد بزنید.از قضا سال‌ها پس از آن روزهای داوطلبی و تبلیغِ این نکات به بازدیدکنندگان، خودم در طبیعت با یک خرس گریزلی روبرو شدم که از لای شاخه‌ها بیرون آمد و من پس از لحظه‌ای شوک و برگ‌ریزان، همین کارها را کردم (و البته اسپری فلفل آماده‌ی شلیک) و او یک نگاهِ باشه بابا نمیری کرد و برگشت رفت.اگر چه اینجا و چه در کوه‌های ایران طبیعت‌گردی می‌کنید، از پیش به این سناریو فکر کنید. اگر رعایت کنید، رویارویی‌ها بی‌خطرند. همچنین هرگز برای حیات وحش غذا نریزید تا استقلالشان و ترسشان از انسان حفظ شود. اگر هم گذرتان به ونکوور افتاد، حتما سری به گرایندر و کولا بزنید.

درباره‌ی مخزن کُد گوگل

Kian — Sun, 01 Aug 2021 23:04:07 +0430

مخزن کدهای داخلی گوگل، git نیست بلکه یک سیستمی داخلیه. این مقاله به معرفی اون پرداخته که به طور خلاصه: همه در یک مخزن (repo) هستند با ۲ میلیارد خط کد و روزانه ۴۵ هزار commit. در ورای آب و تاب ژورنالیستی مقاله، شاید مرور چند نکته‌ی کاربردی مفید باشه:اصلی‌ترین نکته: ما که برای سرورهای مختلف در نمایش تبلیغات به طور روزانه یا هفتگی binary جدید می‌سازیم و منتشر/release می‌کنیم، از مثلا تیم protocol buffer، یک package در نسخه‌ی فلان تحویل نمی‌گیریم، بلکه همون کُدی که به طور زنده در مخزن مشترک هست، به binaryمون link می‌شه. هر تکه کدی که به مخزن commit می‌شه، از همون لحظه به سرتاسر گوگل منتشر/release شده. این نکته‌ی مهمیه. سود و زیان‌های این مدل یکپارچه در مقایسه با مدلی که تیم‌ها به هم package تحویل می‌دن (و مدیریت سازگاری/compatibility و الخ) قابل برشمردنه ولی به طور خلاصه و به تجربه‌ی شخصی در کار با هر دو مدل، مدل یکپارچه مانند گوگل، با اختلاف مدل بهتریه. بجویید trunk based development.در این مخزن، هم کدهای ++C هست، هم python، هم js، هم همه چیز. هر binary، مثلا اونی که در سرور الف در سرویس search می‌نشینه، فقط بخشی رو استفاده می‌کنه. همچنان گراف وابستگی‌ها بزرگه و باید مثلا چند صدهزار فایل compile بشن، که توزیع‌شده انجام می‌شه - روی همون ماشین‌هایی که دارن سرویس maps و gmail رو ارائه می‌دن یعنی یک زیرساخت مشترک برای انواع کارها در اولویت‌های مختلف. توسط سیستمی به نام Borg مدیریت می‌شه که نسخه‌ی بیرونیش Kubernetes است. سرویس عریض و طویلی هم برای build توزیع‌شده داریم، که اون هم به عنوان یک سرویس ابری به بیرون عرضه شده.سیستم مدیریت مخزن (معادل git)، یک سرویس داخلیه به نام Piper که در مقاله هم اشاره شده و ساده‌تر از git است. git یه کم الکی پیچیده‌ست و بدتر از اون اینه که با یک سوتی می‌تونید به خودتون خیلی ضرر بزنید. با Piper خیلی کمتر. مثلا snapshotها برای همیشه ذخیره می‌شن. مخزنی با دومیلیارد خط کد رو نمی‌شه روی کامپیوترتون بیارید. قدیم‌ترها به Piper می‌گفتیم فلان زیرشاخه‌ها رو بیار و بقیه (برای وابستگی‌های build) از مخزن اصلی بیان. الان سال‌هاست که منسوخ شده و همه چیز از جمله همون کپیِ محلیِ فایلی که من ویرایش می‌کنم دیگه روی کامپیوتر من نیست.سیستم Piper خیلی تنگاتنگ به سیستم بازبینی کد (code review) ما که نسخه‌ی open sourceاش Gerrit است وصله. شما هیچ‌وقت نمی‌تونید یک تکه کد رو به مخزن commit کنید تا وقتی یک بازبین (reviewer) کد شما رو نخونده و تایید نکرده باشه. درباره‌ی چرخه‌ی توسعه می‌شه بعدا مفصل‌تر حرف زد.شاخه نداریم (به جز یک حالت خاص خودکار برای انتشار). می‌تونید شاخه‌های محلی برای خودتون بسازید، ولی در مخزن مشترک تنها یک شاخه داریم.همه‌ی این‌ها درباره‌ی مخزن مشترک بود به نام google3 که بیشتر سرویس‌های گوگل روی اون هستن. ولی برخی پروژه‌ها روی اون نیستن، مثل Chrome.پرسش و پاسخ:در خصوص سلامت بودن دایرکتوری‌ها و تمیز نگه‌داشتنشون چه طور؟ مالکیت/ownership چطوری تقسیم می‌شه؟ خصوصا چیزایی که خارج از «‌سرویس‌های یک تیم» هست. مثلا کدهای مشترکی که برای کتابخانه rpc یا غیره زده شدن. یکی بره تغییرشون بده، changelist رو باید به کی بده؟ اگر در یک زیرشاخه، فایلی به نام OWNERS موجود باشه، هر changelistی که حاوی تغییری در اون زیرشاخه باشه باید به تایید یکی از کسانی که در اون فایل OWNERS (یا فایل OWNERS شاخه‌ی بالایی یا بالاتر) فهرست شدن برسه. این مکانیکشه. ولی برای تغییر کدهای دیگران یا کتابخانه‌های مشترک اگر تغییر کوچکه، صرفا changelist رو می‌نویسید و با یک توضیح مکفی می‌فرستید. ولی اگر تغییر کوچک نیست، معمولا باید از پیش با تیم صحبت کنید و ایده‌تون رو بگید و نظراتشون رو بشنوید و معمولا هم پس از رسیدن به توافق، یک PoC از اون تیم تعیین می‌شه که changelistها رو بهش بفرستید.دسترسی‌ها چطور اعمال میشه؟ وقتی سراسر کدهای شرکت در یک جا تجمیع شدن چه طور سطح دسترسی‌ها مشخص می‌شن؟ می‌شه زیرشاخه‌های خاصی رو «حفاظت‌شده» کرد و دسترسیش رو فقط به گروه خاصی داد، ولی این کار به ندرت و تنها برای زیرشاخه‌هایی که دارای اطلاعات سرّی هستن استفاده می‌شه. تقریبا همه‌ی کدهای همه‌ی سرویس‌های شرکت برای همه‌ی کارمندان در دسترسه. در مجموع جوّ اعتماده. ولی باز هم کُد در حد برنزه. داده‌ها و برخی مستندات در حد طلا و نقره هستن که بهتر محافظت می‌شن.

پرسش متداول در پایداری سرویس‌های نرم‌افزاری

Kian — Sun, 01 Aug 2021 22:53:53 +0430

«پایداری سرویس‌ها» از موضوع‌های معمول در گپ و گفت‌هایِ گه‌گاهی با همکاران در بازار ایران است. «اگر بخوایم یک نفر-فصل زمان بذاریم پایداریمونو بهتر کنیم رو چی بذاریم؟» پرسش آسان ولی نادرست است. همه می‌دانیم ولی برای دوستان تهِ سالنی، آقای ربیعی و حسنلو، دو نکته مرور کنیم:یک: کاربرِ دیروز به #سیستم_همیشه_بالا خیلی حساس نبود ولی کاربرِ امروز هست - منظورم گوگل نیست بلکه همان فروشگاه و تاکسی اینترنتی شماست. اگر هم گمان می‌کنید کاربر امروز همچنان آن‌قدر حساس نیست که به یکی دو بار پایین بودنِ شما به سیستم رقیب مهاجرت کند، بدانید که کاربرِ فردا هست.چرا بازگوییِ این بدیهیات؟ چون مهندسانِ باتجربه به اهمیت پایداری آگاهند ولی گاهی بالادستی‌ها (شاید شما) سرمایه‌گذاری اصلی را در feature می‌بینند و پایداری را جانبی، به ویژه چون تضادهایی دارند: پایداری یعنی کُند شدن سرعت توسعه. پس درکِ این که یک مزیت رقابتی مهم است، مهم است.دو: پایداری نه تنها وابسته به معماری سیستم و مدیریت بار و غیره است، وابسته به استانداردسازی و هردمبیلی‌زدایی در زنجیره‌ای از رویه‌هاست، از پیش از توسعه تا پس از استقرار، از سبْک کد و فرآیندهای توسعه و بازبینی و تست و CI تا انتشارِ ایمن و پایشِ فراگیر و هشدار و پاسخ به حادثه.درباره‌ی برخی پیش‌تر نوشتم، اینجا سیاهه می‌کنم برای دوستانی که بعدتر به ما پیوستند:مثالی از انتشار/پایش/تست/... یک سرویسفرایند توسعه و انتشارمدیریت بارپاسداری از سرورهاپایشمانور تاب‌آوریپاسخ به حادثهتحلیل حادثهفرایندمحوریخلاصه متوجه‌ام که منابع محدودند و کارها زیاد و «با هزینه‌ی محدود برای بهبود پایداری از کجا شروع کنم» پرسش آسان، ولی فهم درست از مولفه‌های پایداری و رویکرد درست به آن، مهم‌تر است.پ.ن. پایداری و مقیاس و کارایی، از موضوع‌های مورد علاقه‌ی بنده‌اند. موضوع‌های غیرفنی و سازمانی، کمتر. ولی گپ و گفت‌هایی که در آغاز عرض کردم، به این سمت دوم رفته که تخصصی هم ندارم و آن‌چه در یادداشت‌ها می‌بینید صرفا از مشاهده است. این پ.ن. برای متقاضیان گپ در آینده است.پ.ن. برای دوستانِ ناآشنا: آقای ربیعی و حسنلو در توییت نخست، تلمیح به اجرایی معروف از جواد یساری است. از افتخارات بنده این است که گویا با استاد بچه‌محل بودیم.

از بحث‌های توییتری گِردِ سگ‌گردانی، درس بگیریم

Kian — Sun, 01 Aug 2021 22:44:40 +0430

(این نوشته پیش‌تر به شکل رشته توییت نوشته شده بوده و سپس در ویرگول رونوشت شده. توییتر فارسی فضای بی‌منطق و خشنی‌ست و این یادداشت تنها ناظر بر این فضاست برای درس‌آموزی و نه ناظر بر کل جامعه.)مثال نخستاز بوی سیگار نفس‌تنگی می‌گیرم. وقتی شخص جلویی‌ام در پیاده‌رو سیگار می‌کشد، و کُند کردن سرعت هم سودی ندارد چون نفر بعدی هست، آرزو می‌کنم قوانین محدود کننده‌ی سیگار شامل پیاده‌روها هم می‌شد. ولی آیا باید می‌شد؟خوشحالم که این قوانین شامل کافه‌ها می‌شود (جایی که ما هستیم) و شامل خیلی مکان‌های سرباز و فاصله‌ی ۲۰ متری فلان و فلان. آیا باید همین قدر سخت‌گیرانه باشد؟ چند سال پیش نبود. تعادل کجاست؟ کاملا به این بستگی دارد که در جامعه چه کسری سیگاری و چه کسری سیگارگریزند. نسخه‌ی کلی نداریم.دقت کنید که تنها بحث سرطان‌زایی سیگار نیست؛ این قوانین درباره‌ی سیگار الکترونیکی هم صادقند. روشن است بحث چیست.مثال دومگاهی با دوچرخه به سر کار می‌رفتم. بخشی از مسیر، مسیر ویژه‌ی دوچرخه داشت و بخشی نداشت و اذیت می‌شدیم. آیا باید می‌داشت؟ اگر داشت، باعث افزایش ترافیک می‌شد، ولی خوب بشود - مهندسی شهری ماشین‌محور تا کِی؟ پس کدام کار را بکنیم؟ پاسخ به این بستگی دارد که چند نفر دوچرخه‌سوار داریم، تک و توک یا هزاران نفر؟اگر دوچرخه‌سواران، قوانین رانندگی در خیابان‌های مشترک را مرتب بشکنند و رانندگان ماشین‌ها (به حق) شاکی شوند، و وضعِ جریمه جمعش نکند و شهرداری دوچرخه‌رانی در خیابان‌های مشترک را ممنوع (و آن را تنها محدود به مسیرهای ویژه‌ی دوچرخه) کند، دوچرخه‌سواران آیا همه‌ی جوال‌دوزها را به شهرداری و رانندگان شاکی بزنند یا یک سر سوزن هم به قانون‌شکنان خودشان بزنند؟مشاهده‌ی امروزبحث قوانین سگ‌گردانی داغ شده. متوجه نگاه نادرستِ حاکمیتی به این مساله هستم و افسوس می‌خورم، اینجا ولی بحث بین شهروندان عادی‌ست و دغدغه‌هایشان. در دید محدود بنده از فضای بحث توییتر فارسی:یک سو حق‌به‌جانبانی‌اند که ترس از سگ یا چِندش از کثیفی آن را مسخره می‌کنند یا عقب‌ماندگی می‌دانند (دقت کنید عناد نه با قانون‌گذار بلکه با دغدغه‌ی شهروند عادی‌ست) یا «من سگم قلاده داره و مدفوعشو جمع می‌کنم» برایشان همه‌ی ماجراست.سوی دیگر، کسانی‌اند که از حضور سگ در پارک‌ها یا نزدیک کودکان یا آزاد چرخیدن و ادرار و مدفوعش شاکی‌اند و خواهان قوانین قلاده و تمیزی.دقت کنید که آن‌چه برشمردم، دو سر متقابل یک طیف نیست. یکی یک سر طیف و یکی وسط طیف است. سر دیگر طیف می‌شد «سگ می‌خوای برو روستا» یا «فرهنگ غربیه و رعایت بکنی نکنی غلطه» که دست کم بنده کمتر دیدم. حالا این نکته مهم نیست و فرعی‌ست.مشکل شهروندان با دغدغه‌های مختلف، تنها با یک قانون «قلاده ببند و مدفوعش را جمع کن» حل نمی‌شود. به این نیست. کلی جزییات هست. محدودیت‌ها و آزادی‌هایی هستند که قرار است محل گفتگوی سالم و پویا باشند: در یک فضای محدود اشتراکی، چه کنیم؟نکته‌ی نخستپارامتر محوری در این گفتگوها چیست؟ در مثال بالا آمده بود: چه کسری از جامعه سیگاری/دوچرخه‌سوارند.اگر فقط یک نفر در شهر سگ داشته باشد و بقیه از پارس سگ تروما بگیرند، یا اگر نصف شهر سگ داشته باشند و نصف دیگر بترسند، یا اگر نصف شهر سگ داشته باشند و نصف دیگر نترسند، یا اگر اکثر شهر سگ‌دوست باشند و اقلیتی بترسند، همه حالت‌های مختلف‌اند و این که آیا مثلا سگ‌گردانی در همه جا را آزاد کنیم و چند پارک خاص ممنوع برای رفاه آنانی که می‌ترسند، یا همه‌ی پارک‌ها ممنوع جز چند پارک خاص برای رفاه سگ‌دارها، یا همه‌جا مجاز کنیم ولی با قوانین سخت‌گیرانه، یا یا یا ... بستگی به توزیع جمعیتی دغدغه‌های جامعه دارد.صحبتی از این پارامتر مهم در گفتگوها می‌بینیم؟ من ندیدم. بیشتر، نسخه‌های مستقل از جامعه دیدم، فرقی ندارد برای شهروندان تهران است یا توکیو یا تورنتو. هر کس از خودش نظری برای اِعمال در جامعه دارد ولی نظر هیچ کس این نیست که «نظر جامعه چیست / از جَو جامعه داده جمع کنیم». توییت‌های نظرسنجی که نقل و نبات‌اند، در این مورد ندیدم. طبیعتا منظور رسیدن به دیکتاتوری اکثریت نیست ولی منظور روشن است.نظر همه باید از کانالِ «منطق من» رد شودنظرات، دغدغه‌ها و سلایق جامعه (چه علاقه به سگ و چه چندش از سگ)، از خودش اصالت و وزن دارد و منوط به تایید شما نیست. تعیین تکلیف برای دغدغه‌ی ملت مثل «بی‌خود از حیوان می‌ترسن» دقیقا از جنس «بی‌خود سگ‌بازی می‌کنن» است. این دو مثال را ببینید شاید روشن شدید:به پیش‌خدمت خارجی گفته بودید غذای گیاهی می‌خواهید و خودش بعدا پرسیده و برمی‌گردد به شما هشدار می‌دهد که سوپی که سفارش دادی درش آبِ گوشت هست اگر احیانا برایت مهم است. به رستوران‌دار ایرانی که همین را می‌گویی با شما بحث و کل‌کل می‌کند (!) که قرمه‌سبزی که گوشتش را جدا کنم را چرا قبول نداری و ای بابا ول کن - تازه در قالب مشتری‌مداری و دوستانه، وگرنه بسیار حق‌به‌جانب و قضاوت‌گرانه‌تر.جایی که ما در حال حاضر زندگی می‌کنیم ۲تا از هر ۳تا خانواده سگ دارند. یعنی سگ نداشتن، اقلیت است. ولی وقتی قدم می‌زنیم و طرف از روبرو با سگش می‌آید اگر سگ بازیگوش باشد او را به طرف دورترش می‌برد تا به شما نزدیک نشود، یه طناب قلاده‌اش را کوتاه می‌کند و سفت‌تر می‌گیرد، یا برای سگ‌های بزرگتر حتی گاهی می‌ایستد و به او می‌گوید «بنشین» تا شما بیایید و رد شوید و سپس دوباره راه می‌افتد. وظیفه‌اش نیست؛ لطفش است. اگر شما برای بازی با سگش پیش‌قدم شوید، خوشحال می‌شود ولی در غیر این صورت اگر سگش به طور تصادفی به شما نزدیک شود، عذرخواهی می‌کند.در مثال دوم دقت کنید که سگ‌دارها در اکثریت هستند و سگ‌گریزی نادر است (جامعه‌ای بسیار سگ‌دوست‌تر از جامعه‌ی ایران)، ولی حقِ دوست نداشتنِ سگ کاملا محترم است و کسی (به جز کاربران توییتر فارسی) نمی‌گوید «ترست واهی‌ست» و «من چه گناهی کردم که تو می‌ترسی» و این دست.نکته‌ی دومفرض کنید بدون دانستن نظر جعفر درباره‌ی مساله الف (مثلا سگ‌گردانی) و صرفا با دانستن نظر جعفر در یکی دو چیز بی‌ربط (مثلا درباره‌ی جواد ظریف) می‌توان نظر او درباره‌ی الف را از پیش و مستقل از واقعیات حدس زد. اشکالی ندارد و هر کس حق دارد نظرات خودش را داشته باشد و یک انسان تک‌بُعدی باشد.ولی اگر در مقیاس یک جامعه، جعفرها در اکثریت باشند، حالا حالاها دور خود خواهیم چرخید. از یک جامعه‌ی یک‌بعدی، و تازه در همان یک بعد هم قطبی، انتظار چه خروجی داریم؟ اصلاحش با کیست؟ با کسی از بیرون؟به زبان علوم داده (!): جامعه‌ی اندیشمند و پویا جامعه‌ایست که اگر نظر افراد درباره‌ی N موضوع گوناگون اجتماعی و سیاسی و اقتصادی را با نقطه‌هایی در فضای N بُعدی نمایش دهیم، با تکنیک‌های کاهش ابعاد «نشود» این فضا را با زیان/loss کم به تنها یکی دو بُعد کاهش داد.

حل مساله در دنیای آکادمی در برابر دنیای صنعت

Kian — Sun, 01 Aug 2021 21:46:38 +0430

از تفاوت‌های تعریف و حل مساله در دنیای آکادمی و دنیای صنعت، در کنار موارد مجمو‌عه‌ی پایین، اینه که در آکادمی به سادگی پر و بال مساله رو می‌زنید و می‌گید این تو حوزه نیست اون تو حوزه نیست: جمله‌ی کلیدی «outside the scope of this paper» رو حتما زیاد خوندید و نوشتید.منطقی هم هست؛ در ۱۰ صفحه که نمی‌شه به همه چیز پرداخت. آکادمی هم یعنی همین مقاله‌های کوتاه. اگر شما یک راه حل طلایی برای حل فلان مساله‌ی مرزدار می‌دید، به خوبی کارتون رو انجام دادید و تمام: از مسولیت مشکلات بیرون اون مرز، و از مسولیتِ استفاده شدن و نشدن راه حلتون، رها هستیید.برای ریزبینان: کاملا شیرتوشیر هم نیست و اگر اونی که گذاشتیدش بیرون مرز، خیلی تابلو «نشدنی» باشه، داوران ایراد خواهند گرفت ولی «نشدنی نبودن» کجا و «شدنی بودن» کجا. یا استفاده شدن راه حلتون خیلی هم براتون مهمه ولی در قالب ارجاع/citation گرفتن، که حُبابه.در صنعت مشکل متفاوتی هست: راه حل هرچند طلایی شما، تا نره و در عمل اثرگذار نباشه، هیچی نیست. یعنی اگر شاخ غول هم شکسته باشید، اولا باید به مشکلات گِرد به کار گیریش هم بپردازید - «outside the scope» و این قرتی‌بازی‌ها نداریم. دوما باید برید برای استفاده شدنش، چانه‌زنی‌ها کنید.مثال: فلان مشکل در سازمان وجود داره (مثلا در اتکاپذیری) و نیازمند ابداع یک راه حل کلیدی (مثلا سیستم الف) و به کار گیریش توسط تیم‌هاست. شما خیلی شیک، مشکل فَراتیمی رو شناسایی می‌کنید، ولی نمی‌تونید تنها روی الف تمرکز کنید و بگید بقیه‌ی کار با بقیه‌ست - برعکس آکادمی. ایده‌آل اینه که بتونید. یعنی شما برای الف پیش‌قدم شدید و تیم‌ها هم برای کاربست الف پیش‌قدم بشن. ولی تیم‌ها یک سر و هزار سودای خودشون رو دارن؛ اولویت‌ها همیشه ۱۰۰٪ هم‌سو نیست؛ مقدار خوبی خودمختاری وجود داره و نمی‌شه هم راحت رفت و فرمانِ بالا به پایین جور کرد و درستش هم همینه. نهایتا تیم‌ها نمی‌آن یهو بگن به به چه گل زیبایی و لایق دستِ چو من رعنایی و پس ما نفر می‌ذاریم استفاده‌ش کنیم. باید قانعشون کنید نفر بذارن (که احتمالا منطقی‌ان و می‌پذیرن ولی می‌گن ۶ ماه دیگه) یا باید خودتون از منابع محدودتون نفرساعت بذارید برای پیش‌بُرد و رسیدن به «اثرگذاری».حالا همه‌ی این‌ها می‌تونه توهم باشه و شاید اصلا الف درِپیته. ولی نه. قضیه اینجا روشن می‌شه که اگر از فلان تیم توی خود الف مشارکت کنن، کلا فرق می‌کنه! رهبران اون تیم، هم به کاربست الف اولویت بیشتری می‌دن و هم خودشون برای قانع کردن بقیه کمک می‌کنن. یعنی چی؟ یعنی کمی سیاست هم در این مدل نیمه‌خودمختار وجود داره.از مثال‌هاش می‌گذرم. خلاصه اینجا (دنیای صنعت) هم از سوی دیگری از بام افتاده - مساله‌ها «واقعی» هستن ولی نمی‌تونید تنها روی خود مساله تمرکز کنید.بدیهی: از یک مدل خاص --شرکت جاافتاده و محیط/تیم‌هایی با مقداری آزادی برای تعریف پروژه از درون-- حرف می‌زنیم و نه حالت کلی.مرتبط: خواندن یادداشت «نگاهی به دنیای متناقضِ پژوهش آکادمیک» توصیه می‌شود.

جذابیت چالشی کار، عاملی شانه به شانه‌ی حقوق و مزایا

Kian — Sun, 01 Aug 2021 21:40:26 +0430

(این نوشته پیش‌تر به شکل چند رشته توییت نوشته و سپس در ویرگول رونوشت شده)رشته‌ی ۱یکی از نیروهای تیمم دیروز گفت که مدتیه با مدیر تیم دیگه‌ای در صحبت بوده و حالا نهایی شده که بره اونجا. خیلی دستمون رو توی پوست گردو گذاشته با این کار ولی به هر حال طبیعتا از این تصمیمتش حمایت کردم و آرزوی موفقیت و اینا - فرهنگ سازمانه و باید بدیهی باشه چرا. صحبت می‌کردیم که تاریخ انتقالش رو کی بذاریم و مسولیت‌هاش کنونی‌ش رو چه کنیم.از مدتی پیش بهم گفته بود کارش اقناعش نمی‌کنه و از قضا (به زعم خودم) خیلی بهش حال داده بودم: برخلاف کارهای معمول، یک کار سطح بالای علوم داده‌ای براش تعریف کرده بودم و مدتی روش کار کرده بود؛ بعد هم روی یک پروژه‌ی جذاب دیگه با مساله‌های پایان-باز هم در سیستم‌های توزیع شده و هم در یادگیری ماشین؛ و همین فصل گذشته ارتقا شده بود به رهبر فنی (TL) همون پروژه‌ی مهم برای سازمان. یه کم کارش عجیب بود که الان رفت، ولی دیگه چه می‌شه کرد. از مدت‌ها پیش که از رضایتش گپ می‌زدیم بهش صادقانه گفته بودم که عدم اقناعت رو درک می‌کنم ولی این جنس کارهایی که داری --- که با عرق جبین بنده برای تعریف مساله‌ی جذاب+مهم و سپس چانه‌زنی برای تخصیص نیرو به دست اومده! --- آرزوی ۹۰٪ مهندسان شرکته - یا حتی کل صنعت. به علایقش شبیه هم بود.خلاصه. با احتساب برهه‌ی حساس کنونی (!) و پروژه‌ی حیاتی و ریسک شکست و اینا، مایل بودم تاریخ انتقالش پایان فصل یعنی ۳ ماه دیگه باشه، ولی کارگردان/directorمون (مدیر بنده و مدیر مدیر اون) گفت درست نیست، و به خودش هم گفته بود. حتی بحث کردم که این بابا برای همین فصل جاری حتی کارآموز گرفته (زمینه: راضی رفتنِ کارآموزها برای شرکت ما خیلی مهمه) و نمی‌شه کارآموزی که با وعده‌ی فلان کار MLی جذبش کردیم رو بذاریم سر یک کار گِل. تازه روی هوا موندن فلان پروژه‌ی مهم به کنار. ولی کارگردانمون توجیهم کرد که ۳ ماه نگه داشتن کسی که می‌خواد بره تیم دیگه، ضررش در طولانی‌مدت و در مقیاس کل شرکت، بیشتره. راست هم می‌گفت. حالا قراره برای پر کردن خلأش برنامه بدم (شامل چندین جابجایی)، و همچنین برنامه‌ریزی که همین هفته‌ی پیش برای نیم‌سال دوم بسته بودیم رو بریزیم دور و از نو.پرسش و پاسخ:بچه‌های تیم در خصوص رفتن کسی، فاز مسئولیت خواهی طور از کاراش برنمی‌دارن؟ نه چندان. معمولا برعکسشه. یه ناهار خداحافظی با هم‌تیمی‌ها و یک رشته ایمیل خداحافظی که همه می‌گن ناراحتیم که می‌ری و برات آرزوی موفقیت می‌کنیم و این تعارفا. تازه‌کارترها موقع رفتن فاز مرام برمی‌دارن که حالا بعدشم فلان کارو ادامه می‌دم تموم شه ولی بهشون می‌گیم برو و بقیه‌ش با ماست.این سبک برخورد و ارزش به آدمه برای همه و تو تمام شرایط صادقه؟ فرضا یکی که از نظر عملکردی ۲-۳ دوره پشت هم افت داشته هم باهاش همین برخورد می‌شه؟ از طرف رده بالاتری‌ها و مدیران معمولا بله ولی از طرف بقیه تعداد پاسخ به ایمیل خداحافظی کم می‌شه یا لحن خشک‌تر. مواردش رو داشتیم.در پاسخ به نظرات پیوامون حسادت به این فرهنگ سازمانی: همه جور خوب و بدِ رویه‌های کاری در شرکت‌ها هست، چه ایران و چه خارج - شخصا بودم و دیدم. در یادداشت‌های بنده که مشخصا از شرکت کنونیه، بدیهیه ولی مایلم یادآوری کنم هدف تبادل ایده‌ست؛ انتقال تجربه‌ی اندک خودم و آموختن از شما. چرا اینو می‌گم؟ مخاطب این نیم‌مثقال تجربه‌های بنده همکارانی‌اند که «تصمیم‌گیر»ند، مدیران و رهبران فنی و منابع‌انسانی‌ها. ولی متوجهم که شاید عمده‌ی مخاطبین این فضا، از اونا نیستن و برخی یادداشت‌ها براشون تاثیر عملی نخواهد داشت و حتی برای برخی ممکنه مایه‌ی رشک بشه. هدف این نیست. اینجا شبکه‌ی من و تو نیست. هدف روشنه. همچنین توجه کنید داریم از یک شرکت نسبتا خاص حرف می‌زنیم، باز در همون هم با سوگیری به خوبی‌هاش (چون نکته بیشتر داره) و باز با سوگیری از یکی از گوشه‌های بهترش که بنده یافتم و لنگرو انداختم.رشته‌ی ۲برای نیروگیری برای جای خالی اون دوستمون، با یکی مصاحبه‌ی تیم‌یابی می‌کردم، یعنی مصاحبه‌های فنی رو گذرونده و حالا صرفا گپ از زمینه‌های کار. می‌گفت دوست دارم کار علوم داده‌ای کنم! حالا از قضا برای کارهای مرتبط لازمش داریم ولی در حالت عادی پاسخش اینه که برو ته صف.مساله صرفا علوم داده نیست. چندی پیش هم نیرویی داشتیم که شل کار می‌کرد و بعد چند ماه ول کرد و رفت به یک استارتاپی که پایگاه داده‌ی توزیع شده می‌ساختن و چالش‌های big data.مساله، سخت‌پسند شدن نیروها از یک سو ولی همچنان دست کم گرفتن عنصر «جذابیت کار» برای رهبران از سوی دیگره. مثلا تخصیص نیرو به کارهای متفاوت و کمی جذاب‌تر، از بحث‌های همیشگی بنده با رهبران تیم مادره و به سختی پیش می‌برمش. یا در مورد همون شخص بالا، یکی از رهبران می‌گفت فلانی زیاده‌خواهه (اینو درست می‌گفت) و همین که الان گوگله باید خوشحال باشه (اینو درست نمی‌گفت). دنیا عوض شده.۱۰ ۱۵ سال پیش، مهندسی نرم‌افزار مهندسی نرم‌افزار بود و سخت‌گیری روی جنس کار هرچند مهم بود ولی در سطح دوم، پایین‌تر از حقوق و مزایا و نام شرکت. ولی الان افراد سخت‌گیرتر شدن. هرچند گوگل تبلیغ می‌کنه که ورود به گوگل از ورود به هاروارد سخت‌تره ولی از همکاران جوان‌تر شنیدم که جوّ امروز دانشگاه‌های خوب اینه که فقط شاگرد متوسط‌هاشون می‌آن به گوگل و امثالش. شاگرد خوب‌ها می‌رن استارتاپ. (نه این که استارتاپ بزنن، بلکه می‌رن استارتاپ. متوجهم که در ایران برخی کلا کار کردن برای یک شرکت حتی استارتاپ رو اُفت می‌دونن و صرفا دنبال freelancerی هستن.)این سخت‌گیری نیروها یک واقعیته و در آینده بیشتر هم می‌شه. برنامه‌ی شُمای مدیر چیه؟ پاسخ معمول اینه که کار تیم/شرکت ما خیلی درجه‌ی آزادی نداره، چیزهای مشخصی باید بسازیم و بیشتر کارها هم کار گِل هستن. این سخن درسته ولی خوب برای یک نیروی خوب تُنبان نمی‌شه - می‌ره جای دیگه. یا باید پذیرفت که کاندیداها محدودتر و ضعیف‌تر باشن، یا پول بیشتر داد، یا به عنصر «جذابیت» در اولویت‌بندی کارها وزن داد هرچند ظاهرا نابهینه - یعنی خودش یک ارزش. سر نسبت کار جذاب و گِل می‌شه بحث کرد ولی اگر اونو پیدا نکنی و نزنی تَنگ این، کوته‌بینی کردی و به حاشیه رونده می‌شی.پرسش و پاسخ:ایده خوبیه که اوایل ورود یک نیروی جدید، از کارهای گل دور نگه داشته بشه و کم کم واردش بشه؟ یا این که نه همون اول درگیر بشن و اگر خوششون نیومد رها کنن؟ پاسخ طلایی که نداره، همیشه موردیه. به هر حال طرف رو که نمی‌شه گول زد و اولش کار قشنگ داد و بعدش عوض کرد. مهم اینه که یک مسیر میان‌مدت و بلندمدت چیده بشه با توجه به علایقش. من مشخصا می‌پرسم که دنبال چی هستی، رشد سریع و ترفیع به سطح بعد یا فعلا جا افتادن در سطح خودت، کار مهندسی کد یا کار تحلیلی‌تر، کار سطح پایین یا بالا. قبلش هم می‌گم که لزوما قرار نیست عین علایقت پیدا بشه ولی قدری جای انتخاب هست.اگر مثلا گفت میخواهم زودتر ترفیع بگیرم، کار چالشی را بهش می‌دهید که محک بخورد؟ چرا یک آدم باید خودش بخواهد که کار سطح پایینی را انجام دهد؟ منظورم اینه که توی این سوالات احتمالا همه پاسخ‌های زود ترفیع گرفتن و ... را انتخاب نمی‌کنند؟ اتفاقا مسیر کار برای ترفیع و مسیرکار برای مساله‌های جذاب معمولا هم‌سو نیست، وگرنه که دیگه واقعا هیچ‌کس هیچ‌وقت کارهای گِل رو انجام نمی‌داد. مسیر ترفیع از کارهای اثرگذار (impactful) می‌گذره که پر از کارهای گِله. چند ماه کار گِل و یک اثر واقعی مثلا مهاجرت از فلان چیز به فلان چیز.

درباره‌ی ساختار سازمانی، نقش‌ها و رابطه‌ها در گوگل

Kian — Mon, 14 Jun 2021 18:09:33 +0430

ساختار سازمانی در گوگل، همان درخت استاندارد است، ولی تفسیرش یعنی نقش‌ها و رابطه‌ها، نه. همچنین دو کارراهه (career) مدیریت و مهندسی از هم جدا هستند، مانند بیشتر شرکت‌های بزرگ فناوری. ولی نه مدیر شدن، شرط رشد شغلی است و نه بودن در کارراهه/نردبان مدیریت، شرط مدیر شدن؛ خواهیم دید. به علاوه، رهبری فنی و مدیریت تیم معمولا مجزا هستند؛ نیز مدیر پروژه اگر نیاز به حضورش باشد.چرا سیستم هیأتی‌ست؟ فرق این نقش‌ها چیست و خوبی و بدی‌های این جداسازی‌های شناور چه‌اند؟ اصلا نردبان نَمَنه؟ مدیریت پروژه چه؟ ببینیم.بسیاری از این رویه‌های منعطف، امروزه در شرکت‌های مختلفی جاافتاده و گوگل در برابر بسیاری‌شان سنتی حساب می‌شود - اگر در شرکت شما چنین است این پایین بنویسید تا یاد بگیریم و استفاده کنیم. ولی در بسیاری شرکت‌ها هم نه، از جمله شرکت‌های گذشته‌ی خودم. (یعنی مقایسه‌های احتمالی در متن که «در گوگل فلان است و سنتی نیست» بر اساس این زمینه‌ست و منظور مقایسه‌ی عام و حلوا حلوا گوگل نیست.) همچنین مسلما رویه‌های گفته شده لزوما برای سازمان شما هم بهینه نیستند، بلکه هدف صرفا تبادل ایده برای ساختاربندی و مدیریت بهینه است.۱. ساختار سازمانی و آن‌چه معنی می‌دهد و نمی‌دهدساختار سازمانی را در نظر بگیرید: چند همکار فردی (ه.ف.) به یک مدیر گزارش می‌دهند، چند مدیر و ه.ف. به یک مدیر لایه بالاتر، و همین‌طور تا مدیر کل شرکت؛ ارتباط‌های خط‌چین (مدیر دوم برای فرد) هم داریم ولی نه شایع است و نه مهم. این درخت استاندارد را در ذهن نگه دارید و سراغ چند نکته برویم.۱. نه این ساختار، زنجیره‌ی فرمان است، و نه ارتباط نیرو با بقیه‌ی شرکت منوط به گذر از کانال مدیرش. خوشبختانه این نگاه امروزه در شرکت‌های فناوری بیشتر از گذشته جا افتاده.منظور از زنجیره‌ی فرمان نبودن یعنی وظایف و ایده‌ها و چالش‌ها لزوما از بالا به پایین جریان ندارد بلکه از پایین به بالا و در عرض و قطر و غیره هم جریان دارد؛ محدود کردن جریان ایده‌ها به یک قالب شابلونی خاص، رویکرد سنتی و ناکارایی‌ست. توجه کنید که این الگو کاملا به جنس کار تیم که چه میزان نوآورانگی دارد یا ندارد بستگی دارد.منظور از منوط به کانال مدیر نبودن یعنی اگر کسی ایده‌ای یا نظری یا اعتراضی برای مطرح کردن با مدیران لایه‌های بالاتر یا با تیم دیگر داشت، قرار نیست حتما از کانال مدیرش رد شود؛ اصلا لازم نیست قبلش به او بگوید مگر به کمکش نیاز باشد. این نکته باید بدیهی باشد ولی خوب خلافش را زیاد دیده‌ام.۲. در یک رسم رایج در بسیاری تیم‌ها، نیروها علاوه بر این که با مدیر مستقیم‌شان جلسه‌ی ۱:۱ هفتگی دارند، با مدیرِ مدیرشان هم جلسه‌ی ۱:۱ ماهیانه یا فصلی دارند (مثلا بنده اخیرا از مدیرم شنیدم فلان نیروی تیمم دغدغه‌ی فلان در کارش دارد که در جلسه ۱:۱شان به اون گفته بود و نشان از کم‌کاری بنده بود و باید حواسم بیشتر باشد)، یا اصلا با تیم‌های دیگر جلسه‌ها و تبادل‌ها دارند بدون دخالت مدیر.نکته‌ی فرعی: یکی از دلایل این ارتباط‌ها، به قول منابع انسانی‌ها «گرده‌افشانی» است. مثلا بنده با چندین نفر از تیم‌هایی که اصلا پروژه‌ی مشترک نداریم جلسه‌های دیر به دیر ولی منظم دارم. گپ می‌زنیم تا در جریان کار هم باشیم و ایده بزاییم.۳. ساختار کار کردن افراد با هم، لزوما محدود به ساختار سازمانی نیست. مثلا بنده در تیم پیشین با مدیر یک تیم دیگر بیشتر کار می‌کردم تا مدیر خودم، یا نیروهایی از تیم دیگر بیشتر با بنده کار می‌کردند. نمونه‌ها فراوانند. البته اگر قرار باشد در درازمدت (مثلا یک سال) چنین باشد، ساختار سازمانی بازبینی می‌شود تا نابهینگی‌ها کم شود، یعنی به نوعی ساختار سازمانی با ساختار کاری تطبیق داده می‌شود - مسلما منوط به ملاحظات سرشمار/headcount و غیره. خلاصه ساختار کاری، محدود سفت و سخت به ساختار سازمانی نیست؛ این رویکرد، سنتی و ناکاراست.نکته‌ی فرعی: این انعطاف، جدا از مقوله‌ی پروژه‌های ۲۰٪ای است. در آنجا نیرو می‌تواند ۲۰٪ از زمانش را صرف پروژه‌ی کاملا دلخواه و بی‌ربط کند و اصلا معمولا از زیرسازمانِ دیگر است.۴. بخش دیگری از اشتباه نگرفتن ساختار سازمانی با زنجیره‌ی فرمان، این است که (از شعارهای گوگل) هر کس می‌تواند هر کس در هر رده‌ای را (محترمانه) به چالش بکشد: درستی و نادرستیِ خودِ حرف مهم است و نه رده‌ی فرد گوینده و گیرنده. البته این شعار در عمل ملاحظاتی دارد و رده‌ها پشمِ پشم نیست، یعنی میزان بحث شما با هم‌تیمی‌تان با بحثتان با مدیر چند لایه بالاتر فرق دارد. ولی مثلا یک ناظر بیرونی در یک جلسه‌ی بحث احتمالا نتواندتشخیص دهد کدام‌یک زیردست و کدام بالادست است - این هم از سنّت‌شکنی‌هایی‌ست که شرکت‌های فناوری درش پیشرو بوده‌اند.مثال: بنده اخیرا با مدیر زیرسازمان‌مان (چند رده بالاتر از بنده) اختلاف نظر پیدا کردم و مشخصا توضیح دادم چرا اشتباه می‌کند، دو سه سری رفت و برگشت. این امکان، بخش پسندیده‌ای از فرهنگ سازمان است. ولی حالا در یک مورد حرف خودش را تکرار می‌کرد و بنده -- در تلاشی بین ایده‌آل‌گرایی و سیاست‌ورزی -- به جای افتادن در دور باطل بحث با این مدیر رده بالا که جالب نمی‌بود یا بی‌خیال شدن که برای سازمان بهینه نمی‌بود، از کارگردان (director) بالادستم که مدیر خودم هم هست خواستم تا به بحث ورود کند و حالا انشالله که طرف می‌پذیرد. البته چنین مواردی، معمول نیست و برای مثال عرض شد. حالا شاید هم نپذیرد. بخش دیگری از فرهنگ سازمانی، «مخالفم ولی متعهدم» (disagree but commit) است چون به هر حال گاهی پس از همه‌ی گفتگوها هم باز همه هم‌نظر نمی‌شوند و بالاخره باید یک تصمیم نهایی گرفته شود. ولی عرض کردم، در کمترِ موارد به اینجا می‌رسد.مثال: دوستی داشتم که (با خنده) تعریف می‌کرد در همان اوایل و به عنوان یک تازه‌کار، رفته بود در یک جلسه با رهبران ارشد آن حوزه، و کُل جلسه با آن‌ها کل‌کل می‌کرد که اشتباه می‌کنند. بعدتر چند بار این رفتار را تکرار کرده بود و از مدیرش بازخورد گرفته بود که نکن.مثال: نیروی تازه‌کاری داشتیم که خیلی شاخ بود و سر جزییات با بنده کل‌کل‌ها می‌کرد و حتی صدایش بالا می‌رفت. تمرین خوبی برای ساز و کار حل اختلاف (conflict resolution) بود و اگر فرصت بود و عُمری بود بعدا می‌نویسم.این رویه‌های فرهنگی برای خیلی شرکت‌ها بدیهی نیست و امیدوارم جرقه‌ای برای بازبینی باشد.۲. مدیر، همکار فردی (ه.ف.) و نردبان‌هابه کسی که مدیر کسان دیگری نیست، همکار فردی (individual contributor) گفته می‌شود یا به اختصار ه.ف.برای مدیر شدن باید از یک سطحی بالاتر بود ولی برعکسش نه، یعنی به ترجیح شخصی می‌شود تا سطح‌های بسیار بالا رفت ولی ه.ف. ماند و مدیر نشد - بالاترینش در گوگل جناب Sanjay Ghemawat است که شاید بشناسید. مدیر شدن، نه شرط لازم برای پیشرفت شغلی و ترفیع در نردبان است (امثال Sanjay در انواع رده‌ها فراوانند) و نه شرط کافی - گاهی حتی به ضرر پیشرفت است.نردبان چیست؟ جدولی‌ست که برای نیروهای هر سطح (مثلا «مهندس ارشد»)، رفتارها و انتظارها را تبیین می‌کند. نیروها بر اساس شایستگیِ قابل اثبات (نه بر اساس تعداد سال سابقه) ترفیع گرفته و از این نردبان بالا می‌روند. کلیدی‌ترین و محوری‌ترین معیار برای ارزیابی افراد، تعریف‌ها در نردبان است. جزییات بیشتر از نردبان: این یادداشت؛ از ارزیابی: این یادداشت. مفهوم نردبان را در ذهن نگه دارید.کارراهه مهندسی و مدیریت، دو نردبان جدا دارند. البته انتظارهای تعریف شده از سطح X در نردبان مهندسی با سطح X در نردبان مدیریت، هم‌پوشانی‌هایی دارند، مثل هدایت راهبردیِ تیم/زیرسازمان/سازمان، ولی متفاوت‌اند. مثلا از مدیرها مشخصا انتظارهایی برای هدایت و مربی‌گری نیروها برای رشد شغلی یا مدیریت پویایی تیمی (بالا و پایین‌های ارتباطات افراد و تیم‌ها) می‌رود، ولی از مهندسان، انتظارهایی در تعریف و رهبری پروژه‌ها.مهاجرت از نقش/نردبان مهندسی به نقش/نربان مدیریت، لازمه‌ی مدیر شدن «نیست». برخی مدیران (از جمله بنده)‌ ترجیح می‌دهند در نردبان مهندسی بمانند و با معیارهای این نردبان ارزیابی شوند و بالا روند. حتی هزینه‌ی اضافه دارد و شاید پیشرفت را کُنْد کند. پس چرا؟ برای دور نشدن از دنیای فنی. به قول تُرک‌ها «قان چَکیر».در درخت سازمانی، تا لایه‌های بالا هم ه.ف.ها (نامدیرها) هستند، یعنی در همه‌ی لایه‌های درخت، nodeهای برگ هست. آن‌ها عموما ه.ف.های ارشد به بالا هستند که (احتمالا علی‌رغم درخواست رهبری زیرسازمانشان) ترجیحشان ه.ف. ماندن است، و طبیعتا با توجه به سطح‌شان بیشتر درگیر مساله‌های راهبردی (هدف‌گذاری) هستند تا مساله‌های تاکتیکی (اجرای اهداف؛ طراحی و کُد). مثل Sanjay. خلاصه برخی افراد، قابلیت سرآمد شدن دارند ولی حوصله‌ی مسئولیت مدیریت ندارند و باید بتوان از ظرفیت‌های رشدشان استفاده کرد.۳. مدیریت و رهبری فنی از دیگر جداسازی‌های سودمند در گوگل، جدایی نقش رهبری فنی (TL) از نقش مدیریت است. گاهی این دو نقش دو شخص متفاوت‌اند و گاهی یک شخص (بنده این هستم و می‌توانم بعدا از خوبی‌ها و بدی‌های این انتخاب بنویسم)، که به او مدیر-رهبر فنی (TLM) گفته می‌شود. هر دو مدل شایع‌اند.خوبی این جداسازی چیست؟ مدیریت و رهبری فنی، هرچند هم‌پوشانی دارند، دو تمرکز متفاوت می‌طلبند. رهبری فنی یعنی نیاز به عمق و سرآمدیِ فنی و حل مساله و (در رده‌های بالاتر) بینش راهبردی و جهت‌دهی به تیم‌ها. اما مدیریت یعنی «تمرکز بر افراد»، مسائل پویایی تیم و چانه‌زنی برای کسب منابع (نیرو) - همچنین دلداری دادن‌هایی که در این یادداشت اشاره شد! بسیاری کارها هم مشترک انجام می‌شوند (مثل اولویت‌بندی و تخصیص نیرو)‌ و در بسیاری مواقع هم اصلا مرزها خاکستری‌اند، ولی امیدوارم تفاوت در تمرکز، روشن باشد.بدی این جداسازی چیست؟ هم‌پوشانی این دو نقش، کم نیست و نیازمند هم‌گامی نزدیک بین مدیر و رهبر فنی‌ست، که گاهی آسان نیست. همچنین جدایی مدیر از جزییات فنی، هرچند گاهی ناگزیر، ولی به هر حال ایده‌آل نیست و همه یک مدیرِ درگیر در جزییات فنی را ترجیح می‌دهند.در لایه‌های بالاتر، خوبی‌های این جداسازی روشن‌تر است. مثلا کارگردان (director) ما، در فضای مدیریت و روی نردبان مدیریت است و با ۱۰۰ نیروی زیر دست، تنها امکان درگیری حدودیِ فنی دارد و نه عمیق. ولی شخص دیگری هم‌سطح او در زیرسازمان ما هست که در فضای فنی‌ست و اصلا ه.ف. است (مدیر نیست) - و شخصی‌ست کاردرست که همه‌ی گوشه‌های مهم سیستم‌های پیچیده‌ی ما را می‌شناسد.در لایه‌های پایین‌تر و تیم‌های کوچک‌تر، خوبی‌های این جداسازی کم‌رنگ‌تر است. مثلا پیش‌تر، تیم ما یک مدیر داشت و دو رهبر فنی، و خوب نقش مدیر خیلی پررنگ نبود. اولا این جداسازی برای تیم آورده‌ی چندانی نداشت و کمی نابهینگی داشت؛ می‌توانید تصور کنید جلسه‌های هفتگی ۱:۱ نیروهای متوسط به پایین (که سرشان به یک کار خاص است) با مدیری که در عمق فنی نیست چگونه می‌گذرد: چیز خاصی ندارند جز «همه چی خوبه؟ آره خوبه. روی چی کار می‌کنی؟ روی فلان. کمی توضیح. خوب ایوَل. خداحافظ تا هفته‌ی بعد.». دوما برای خود مدیر هم ایده‌آل نیست: مدیرِ خالی برای تیمِ نه چندان بزرگ، به اندازه‌ی یک آدم تمام‌وقت کار نمی‌برد و حوصله‌اش سر می‌رود ولی در چه سطحی وارد کار فنی شود؟ پایین‌تر از رهبری فنی؟ موازی او؟ روشن نیست. (آن مدیر خاص هم خیلی تلاش کرد وارد کار فنی شود ولی چون از بیرون آمده بود و زیست‌بومِ زیرسازمان ما منحنیِ یادگیریِ تیز و طولانی دارد، نتوانست سری در سرها شود و افسرده شد و سر سال رفت به یک تیم دیگر.)در سازمان بزرگ ما، برای خود نقش رهبری فنی هم گونه‌هایی تعریف شده، مثلا رهبر فنیِ یک زمینه/محصول بزرگ و بالادستِ چند رهبر فنی دیگر، uber TL خوانده می‌شود و رهبر فنی یک حوزه‌ی بزرگ، area TL که بیشتر برای نقشش در تصمیم‌گیری‌ها مجزا شده. اگر سازمان کوچکی دارید به این قرتی بازی‌ها نیاز نخواهید داشت.مدیرانِ برآمده از خود تیم‌های مهندسی، عموما در موقعیت بهتری برای موفقیت و برای مقبولیت قرار دارند تا مدیرانِ از بیرون آمده - به تجربه‌ی خودم از هم مدیر داشتن و هم مدیر بودن عرض می‌کنم. حتی مثلا یک بار در یکی از جلسه‌های فراگیر دفتر ما این پرسش را مطرح شد که اصلا چرا از بیرون مدیر می‌آورید وقتی این همه نیرو با ظرفیت مدیر شدن در داخل هست. ولی پاسخ روشن است: سیستم بسته، سیستم محتوم به میرایی‌ست.۴. مدیر پروژه/برنامهاین فصل چندان ربطی به سه فصل پیش ندارد جز این که یک ر دارد ولی چون پرسش‌های مدیریت پروژه‌ای زیاد از دوستان گرفته‌ام، این ضمیمه‌ی کوچک را به تَنگ این مطلب زدم. scrum کار می‌کنیم؟ مدیر پروژه‌ی جداگانه داریم؟ چه کار می‌کند؟مدیریت پروژه نه تنها در گوگل بلکه در هر شرکت بزرگی که دیده یا شنیده‌ام، کاملا خودمختارانه است. منطقی هم هست. چرا اجبار به یک‌دست شدن؟! در گوگل هر تیمی به شکل دلخواه‌اش: یکی با kanban و یکی نمودار گانت (نامعمول) و یکی اصلا با دفتر کاغذی؛ یک تیم برای بیشتر کارها issue/ticket می‌زند (نامعمول) و یکی نه؛ یک تیم scrum کار می‌کند (نامعمول) و یکی نه. این رویکر بسیار کارآمدتر از اجبارِ سربارهای بوروکراتیک (حتما issue زدن و ...) یا دخیل کردن اشخاص/تیم‌ها/دُکان‌دارهای غیرفنی برای پی‌گیری پیشرفت است در حالی که ضروری نیست، رویه‌ای ناکارا که در برخی جاها دیده‌ام. مدیریت پروژه در سطح یکی دو تیم و ۱۰ ۲۰ نفر، توسط خود رهبران فنی انجام می‌شود.ولی در رده‌ی پروژه‌های بزرگ‌تر و به ویژه «بین تیمی»، نیاز به مسولیت تخصصی‌ست و نام این نقش در گوگل «مدیر [فنی] برنامه» (PgM/TPgM) است. مسولیت‌های این نقش --به جز پی‌گیری و پی‌گیری و پی‌گیری-- شامل:مدیریت ارتباطات درونی و بیرونی درباره‌ی پیشرفت،نوشتنِ نوشتنی‌ها (مثلا مستند‌ها و دستور/صورت جلسه‌های برنامه‌ریزی) و کشیدنِ کشیدنی‌ها (مثلا جدول و نمودارهای مربوط به برنامه‌ریزی)،تشخیص موانعِ پیشرفت و پیدا کردن مسول/صاحب و پی‌گیری،(مهم) اطمینان از گم نشدن کارها در فاصله‌ی بین تیم‌ها،(مهم) کشف deadlockها (مثلا این منتظر آن است و آن منتظر این) و حل آن‌ها،کمک به مهندسان و رهبران فنی برای رهبری پروژه در مقیاس تیم خودشان (مثلا نوشتن برنامه‌ی عمل از روی OKRها)،و این دست است. برای همین کار هم هر گوشه یک شکل است؛ یکی با smartsheet و یکی صرفا با spreadsheet سنتی.توضیح: وقتی گفتم این کارها توسط خود رهبران فنی انجام می‌شود، اشتباه برداشت نشود که مدیر پروژه‌ها (به قول ما: مدیر برنامه‌ها) تخصص خاصی ندارند و هر کس به طور پیش‌فرض توانا به عهده‌داریِ این مسولیت‌هاست. این مهارت‌ها مهم‌اند و یکی از عامل‌های تعریف‌کننده‌ی مدیریت خوب. منظور این بود که جداسازی این وظایف از رهبری فنی، هزینه و فایده دارد --از یک سو مدیریت کارهای بالا توسط کسی که فنی نیست و از یک سو محدودیت وقت و بینش مهندسان فنی-- و صرفا مرز ما برای پرداخت هزینه‌اش کمی بالاتر از جاهای دیگری‌ست که دیدم.تکرار پایانی: مسلما منظور این نیست که این رویه‌ها لزوما خوبند یا برای سازمان شما هم بهینه‌اند. صرفا چند نقطه‌داده برای تبادل ایده است و قضاوت‌ها هم از دید محدود بنده‌اند.

به بهانه‌ی فاجعه‌ی آزار جنسی در دیجی‌کالا: همه مرام‌نامه دارند، شما چه طور؟

Kian — Sat, 29 May 2021 18:02:12 +0430

ادعاهای مزاحمت و سواستفاده توسط یکی از مدیران دیجی‌کالا -- و عدم برخورد با آزارگر و در عوض برخورد با آزاردیده -- را به تازگی دیدم. چه قدر تلخ. برای اصلاح این فضا، جای خیلی چیزها خالی‌ست و یکی از پایه‌ای‌ترین ستون‌ها، مقوله‌ی «مرام‌نامه» (code of conduct) شرکت است. آیا در شرکت شما / شرکت‌های ایرانی که می‌شناسید تعریف شده؟آموزش مرام‌نامه از آموزش‌های سالانه‌ی گوگل برای کارکنان است که علاوه بر محتوا، مثال‌های فراوانی هم به شکل تعاملی و کوییز مانند دارد، البته نه برای نمر بلکه برای جا افتادن مطلب. از این دستند که یک سناریوی عملی یا مکالمه‌ی نمونه است و می‌پرسه آیا اشکالی می‌بینید؟ و مشخصا موردهایی که پاسخ درست «نه»ست هم هستند. داستان خانم نیتفیلد که در این یادداشت خلاصه شده، نمونه‌ی نقض این مرام‌نامه است.افزون بر خود مرام‌نامه، اصل «عدم تلافی» هم باید وجود داشته باشد تا مرام‌نامه کشک نباشد. یعنی اگر کسی نقض مرام‌نامه را گزارش داد و پی‌گیری کرد، مثلا علیه مدیریت، عملی علیه آن شخص از سوی مدیران یا شرکت صورت نگیرد. این امر در خود گوگل هم لزوما به درستی اجرا نمی‌شود (رشته‌ی نقل شده در بالا را بخوانید) و همچنین ذاتا خطا و جای سواستفاده (کولی‌بازی و امتیاز گرفتن) دارد. ولی یک راه حل پویا و پیوسته بازبینی شده با مقداری خطا، بسیار بهتر از نداشتن راه حل و امثال قضیه‌ی دیجی‌کالاست.اگر شرکت‌های مرام‌نامه‌دار می‌شناسید این‌جا بنویسید تا (به درستی) برایشان تبلیغ شود - «این‌جا» یعنی کلا فضای مجازی. اگر مرام‌نامه ندارند و مخالفت می‌کنند هم بنویسید و هزینه‌ی روابط عمومی ایجاد کنید. هنگام مصاحبه شدن، از مرام‌نامه‌ی شرکت بپرسید. (ایراد «نفست از جای گرم بلند می شود» احتمالا وارد است ولی پیشنهادها همچنان غیرمنطقی نیستند.)داشتن و اِعمال مرام‌نامه، هم برای خود شرکت ارزش است -- هم مزیت رقابتی و هم کاهش ریسک رسوایی -- و هم برای ما به عنوان انسان و به ویژه با فرهنگی که «غیرت» درش ارزش است: احساس ناامنی کردن افراد به ویژه بانوان که به اندازه‌ی کافی از حاکمیت و جامعه ناامنی می‌گیرند قرار است برایمان پذیرفتنی نباشد.نکته‌ی بدیهی: معیار مرام‌نامه، در کنار آن‌چه اصلا دودش به چشم خود کسب و کار می‌رود، نظام ارزشی مقبول جامعه‌ و همان افرادی که شرکت با آن‌ها سر و کار دارد است. هدف نه بازتاب ارزش‌های دیکته‌ای حاکمیتی‌ست و نه کپی کورکورانه از جای دیگر - و نگرانی از گیرهای احتمالی توییتری و امثالش! مثلا «حیا» یا «غیرت»ی که گفته شد، هرچند از ظرفیت‌های فرهنگ ما (پس از غبار زدایی) است و نه مفهومش مشکل دارد و نه واژه‌اش، به هر حال هدفِ گیرهای و جوسازی‌های گروهی خواهد بود که این مفاهیم را اَخ اَخ می‌دانند و در عوض چشم‌به‌راه بازتولید آن‌ها با برَند متفاوت مثل no means no و سپس بَه بَه هستند. یا مثلا از پیش می‌دانیم که اگر مرام‌نامه‌ی گوگل را هم کپی کنید ایرادهای اغراق‌آمیزی خواهند گرفت که «وزارت ارشاد راه انداختن» و خوب بله همه‌ی شرکت‌های بزرگ دنیا به شکلی راه انداخته‌اند؛ مساله ممنوع کردن رفتار الف و ب «در شرکت» یا «مرتبط با شرکت» یا «آوردن اثرش به شرکت» است. خلاصه فضای خاصی‌ست و تا جایی باید اهمیت داد و بازخورد آموزنده گرفت و از یک جایی به بعد نه. بدیهی‌ست ولی شاید یادآوری‌اش لازم.مساله‌ی دیجی‌کالا با صِرف وجود مرام‌نامه حل نمی‌شد. ولی بدون مرام‌نامه هرگز حل نخواهد شد. مرام‌نامه اولا برای حذف/کاهش عامل «حسی و شکمی بودن» در مرزبندی رفتارِ پذیرفته و ناپذیرفته است، و دوما برای یادآوری پیوسته به کارکنان که خودبه‌خود باعث می‌شود حواسشان/حواسمان باشد.شما هم اگر تجربه یا نظر آموزنده‌ای از مرام‌نامه داشتن یا نوشتن دارید، بنویسید و منتشر کنید.پ.ن. در این مطلب تنها به جنبه‌ی مزاحمت پرداختیم ولی مرام‌نامه خیلی کلی‌تر و شامل اصول رفتاری دیگر (تبعیض و ...) هم هست.

اندر علوم داده (data science)

Kian — Sat, 29 May 2021 17:55:21 +0430

زمینه‌ی کاری «علوم داده» (data science) الان داغه و دوستان می‌پرسن منبع خوب چیه یا از کجا آغاز کنن، که نمی‌دونم. صرفا پرسش رو این‌جا (و پیش‌تر در در توییتر) بازتاب می‌دم تا اگر شما پیشنهادی دارید بنویسید بلکه به درد کسی بخوره. لطفا اگر لینک گذاشتید برای خواننده توضیح مختصری هم بدید که مطالب چه‌اند.پراکنده‌ی خودم: «دیتاساینس» الان داغه چنان‌که «بیگ‌دیتا» چند سال پیش بود، و متاسفانه این امر فضا رو نویزی می‌کنه و ادعاها رو زیاد. خودِ این رشته‌سازی و نام‌گذاری، امریست پسندیده و باعث پیشرفت، ولی به عنوان یک شغل مجرد از دانش‌هایی در بقیه‌ی علوم کامپیوتر، جای صحبت داره. یعنی کاراییِ یک دانشمند داده (data scientist)---فرض کنید قراره داده‌های رفتار کاربران رو بکاوه---بدون آشنایی حداقلی و داشتن «شهود» از آمار و احتمال و الگوریتم و یادگیری ماشین و پایگاه داده، جای صحبت داره. البته احتمالا همچنان ارزشمنده، ولی مثلا بنده برای تیمم نخواهم گرفت. هدف البته مانیفست دادن نیست بلکه دید دادن (به نظر سلیقه‌ایِ بنده) درباره‌ی این زیرشاخه‌ایست که به چشم یک تازه وارد شاید «همه چیز هست و هیچ چیز نیست» دیده بشه. در پاسخ به «از کجا آغاز کنم»: از «صورت مساله‌ها»، سپس به سوی «چی یاد بگیرم»، نه برعکس، به ویژه در مورد «ابزار».در شرکت ما چه شکلیه؟ عنوان جداگانه‌ی «دانشمند داده» خیلی در ادبیات داخلی گوگل جا نیفتاده و مثل خیلی تخصص‌های دیگه این‌طوریه که همه مهندس نرم‌افزارن و برخی تخصص تحلیل داده یا مدل‌سازی یا ... دارن - حتی درباره‌ی کل مقوله‌ی پژوهش/research هم (به جز یک دو زمینه‌ی خاص) همینه، مثلا بیشتر پژوهش‌گران دنیای آکادمی که می‌آن، همون مهندس نرم‌افزارن ولی کارهای پژوهشی‌تر می‌کنن، مانند تیم سابق بنده. البته با عنوان «دانشمند داده» استخدام داریم ولی خیلی تخصصی‌ست و (دست کم ما) به عنوان سابق یعنی «تیم‌های statistican» می‌شناسیمشون. شرکت خیلی بزرگه و شاید در سوی دیگری ادبیات‌ها فرق کنه. خلاصه نام‌ها و عنوان‌ها خیلی مهم نیستن، به ویژه «پس از» استخدام. تخصص‌ها مهمن.از ابزارها خواهم گفت، ولی دقت کنید که ابزار، فرعی‌ست؛ مهم «شهود روی روش‌ها‌» است.مثال از کار علوم داده‌ای نزدیک به یادگیری ماشین: مساله‌ی سوم در این یادداشت (یا این رشته توییت).مثال از کار علوم داده‌ای نزدیک به الگوریتم: برای تحلیل داده‌ی بزرگی که نیازمد مرتب‌سازی‌ست، نخستین چیزی که به ذهنتون می‌رسه چیه؟ نوشتن یک خط لوله برای distributed sort؟ یا رفتن سوی ایده‌ی ساده‌ی گسسته‌سازی و bucket sort؟ (باید دومی اول به ذهن بیاد و اولی تنها اگر لازم شد.) می‌تونید خطای تخمینتون رو کران‌دار کنید؟مثال از کار علوم داده‌ای نزدیک به آمار: اگر قراره با تحلیل داده‌های فوتبال، یک فرضیه مثلا «احتمال کارت گرفتن بازیکنان رنگین‌پوست بیشتره» رو تایید یا رد کنید، درک مفاهیم p-value و بازه‌ی اطمینان و حساسیت‌سنجی (sensitivity analysis) در فضای N بُعدی پارامترها مهم هستن.هدف از این مثال‌ها توضیح مفوم «شهود» بود، مشخصا برای مقابله با خطای «چکش داشتن و همه چیز رو میخ دیدن» که در موضوع‌هایی که داغ می‌شن و عجله برای مطرح شدن درشون زیاده، خیلی خیلی شایعه. نهایتا دوتا از پایه‌ای‌ترین ابزارهای ما در کارهای داده‌ای:یکی Colab، ابزاری که query برای داده‌های بزرگ رو با برنامه‌نویسی پایتون و سپس جدول و نمودار و غیره کشیدن و حتی فرم تعاملی ساده ساختن ترکیب می‌کنه. ابزاری بسیار ساده ولی گام نخست در بیشتر کارهای تحلیل داده‌ای. بجویید Google Colab. گویا معادل دیگری هم به نام Jupyter داره.یکی Flume، همون MapReduce سابق، برای نوشتن انواع خط لوله‌های پردازشی (حتی اگر خیلی هم به مدل functional زیرش نیازی نباشه)، که کم و بیش برابر Apache Beam است.پوزش بابت پراکندگی و عدم انسجام.پ.ن. هدف اصلی، درخواستیه که در آغاز مطرح شد؛ لطفا معرفی بفرمایید برای دیگران.پ.ن. منظور از مثال‌ها ترساندن نیست بلکه باز کردن فکره که مثلا برای فوق‌لیسانس معمولا نخست نیاز به لیسانسه.

نیک‌ورزی، بخشی از فرهنگ سازمانی گوگل

Kian — Sat, 15 May 2021 18:37:36 +0430

فرهنگ نیک‌ورزی خوشبختانه در شرکت ما جایگاه خوبی دارد. چند مورد از جمله نمونه‌ی ماه رمضانی‌اش را ببینیم. البته این نه برای تبرئه‌ی گوگل از چندین و چند شر دیگر، و نه برای پُز و فخر، بلکه برای گسترش این بخش از فرهنگ سازمانی و تشویق شما به الگوبرداری در شرکتتان است.یک: شرکت، خیراتی که کارکنان می‌کنند را جفت می‌کند، یعنی بنده ۱۰۰ دلار به خیریه‌ی مورد علاقه‌ام می‌دهم (یا خودم می‌دهم یا می‌گویم از حقوقم برداشته شود)، سپس در یک سایت داخلی شرکت اعلام می‌کنم و شرکت هم ۱۰۰ دلار دیگر به همان خیریه می‌دهد. البته خیریه‌های ثبت شده. خیریه‌هایی که برای کودکان محروم ایران فعالیت کنند هم وجود دارند.دو: در اواخر سال پویشی داریم به نام هفته‌ی اهدا، که اثر کمک‌ها نه تنها 2x بلکه 3x می‌شود: کارکنان داوطلب، بودجه‌ی شخصی گذاشته و پویش‌هایی راه می‌اندازند که اگر به آن‌ها کمک کنید، کمک شما هم از سوی شرکت و هم از سوی پویش جفت می‌شود (و خود بودجه‌ی پشتِ پویش هم از طرف شرکت جفت می‌شود). در هفته‌ی اهدا، صدها از این پویش‌ها به راه می‌افتند.سه: در پایان سال، شرکت چند صد دلار به هر کس «هدیه‌ی اهدا» می‌دهد: اهدا از طرف شرکت به خیریه‌ی انتخابی شما. البته تاریخچه‌ی این هدیه این است که پیش‌تر که شرکت کوچک‌تر بود، برای کریسمس به خود کارکنان هدیه می‌داد (مثلا گوشی‌های پیکسل) و وقتی شرکت زیادی بزرگ شد و هزینه زیاد، هدیه منتفی نشد بلکه تبدیل شد به هدیه‌ی اهدا.چهار: ما دو سه روز در سال مرخصی با حقوق برای «کار داوطلبانه» داریم. هفته‌ی مشخصی هم هست که پویش‌هایش به راه می‌افتند. مثلا یک تیم جمع می‌شوند و همگی دو روز برای پروژه‌ی خانه‌سازی برای محرومین (مثل اردوهای جهادی در ایران) می‌روند یا برای ماهی ریختن در فلان رودخانه برای احیای زیست‌بوم یا غیره. مشارکت هم خیلی تبلیغ می‌شود. برای تصویر شرکت در جامعه هم سودمند است.پنج: یکی از پویش‌هایی که هر سال در ماه رمضان سازمان‌دهی می‌شود، fast-a-thon (ترکیب «روزه» و «ماراتن») است که در یکی دو روز مشخص، هم کمک جمع می‌شود و هم افراد، مسلمان و غیر مسلمان، به شکلی که دوست دارند روزه می‌گیرند و در پایان روز دور هم جمع می‌شوند و افطار می‌کنند - البته طبیعتا ما مسلمانان کمی بیشتر صبر می‌کنیم تا غروب. کمک‌های خوبی هم جمع می‌شود.پ.ن.: کسری از (مثلا یک سوم) هزینه‌هایی که شرکت صرف نیک‌ورزی می‌کند، برای شرکت در قالب معافیت مالیاتی برمی‌گردند، ولی بقیه‌اش (مثلا دو سوم) همچنان از جیب شرکت رفته.پ.ن. یکی از تفاوت‌های فرهنگی بین گوگل و آمازون که در این یادداشت معروفِ یکی از مدیران پیشینِ آمازون و کنونیِ گوگل آمده، در همین راستای بالاست. یادداشتی‌ست با مایه‌ی طنز و همچنین نکته‌های آموزنده درطراحی سیستم‌ها و خواندنش خالی از لطف نیست.

در شبکه‌های اجتماعی چه ببینیم: خودتان انتخاب کنید؛ نگذارید شبکه انتخاب کند

Kian — Tue, 11 May 2021 06:42:45 +0430

(این نوشته پیش‌تر به شکل رشته توییت نوشته شده بوده و سپس در ویرگول رونوشت شده.)این که در timeline توییترتون چی ببینید دو گونه داره و شما حق انتخاب دارید: آخرین توییت‌ها یا توییت‌های برتر/top. به نظر می‌آد که تقریبا همه روی گونه‌ی دوم هستن - شمار دنبال‌شوندگان (followingها) در bioها عموما «صدها»ست. آیا با خطرهای این انتخاب آشنا هستید؟#دالان_پژواکگونه‌ی دوم (توییت‌های برتر) یعنی کارگردانِ این که من چه‌ها ببینم، مدل‌های یادگیری ماشینی هستند که توییتر ازعلایق من ساخته. در ظاهر اشکالی نداره و خیلی هم خوبه؛ من که وقت ندارم «همه‌ی» توییت‌های ۴۰۰ نفری که دنبال می‌کنم رو بخونم و یکی باید برام انتخاب کنه. ولی بر چه اساسی؟این مدل‌های یادگیری برای چه هدفی بهینه‌سازی شدن؟ افزایش دانش من؟ گسترده شدن دید من؟ نه، برای بیشینه کردن درگیری (engagement) کاربر پای صفحه. روز به روز هم بهتر می‌شن: در هر شرکت از جمله شرکت بنده زیرساخت‌های عریض و طویل تجربه و آزمایش الف/ب (A/B experiment) وجود داره و صدها ایده آزموده می‌شن تا هر کدوم که باعث بهبود «شاخص‌ها» می‌شن به سیستم افزوده بشن و یک گروهی سرش ترفیع بگیرن و رشد شغلی کنن. در سوی ما البته این «شاخص‌ها» بیشتر از جنس کلیک خوردن تبلیغ یا گرویدن (conversion) کاربر به کسب و کار مقصده. در شبکه‌های اجتماعی: درگیری پای صفحه.خلاصه یعنی توییت‌هایی برای شما انتخاب می‌شن که به احتمال بیشتری پای توییتر نگهتون می‌داره - برای دیدن تبلیغ بیشتر. خوب باز اشکالش چیه؟ وقتم پای توییتر تلف می‌شه؟ به خودم مربوطه! نه، اشکال‌های بزرگ‌تری داره.یک: اگر دیدگاهتون در موضوع الف و ب، فلان و فلانه، مطالب نزدیک به همین دیدگاه‌ها دورتون رو می‌گیره و هر روز بیشتر در دالان پژواک (echo chamber) خودتون حل می‌شید. کم کم براتون حجت می‌شه که طرف مقابل چه قدر باید نفهم (مزدور/خودباخته/...) باشه که این (به زعم من) بدیهیات رو نفهمه!دو: بخش بزرگی از محتوایی که می‌بینیم، جهت‌دهی مهندسی شده‌ست، یا مستقیم یا غیرمستقیم (بسیاری چارخط/hashtagها که داغ می‌شن). یک گروه/نهاد/دولت، X دلار هزینه می‌ذاره وافکار گروه مخاطبان مورد نظرش رو کمی به سمتی که می‌خواد سوق می‌ده. اصلا شرکت‌هایی هستن که کار و شعارشون همینه.این که فضا در سال‌های اخیر به طور فزاینده‌ای قطبی شده، اولا تنها برای ایران نیست، و دوما یکی از دلیل‌های اصلیش همین دو اثر بالاست. طبیعتا یک آدم خبیث که داره گربه‌شو ناز می‌کنه و خنده‌های شیطانی می‌کنه پشت این قضیه ننشسته، بلکه «سود»، خود به خود سیستم‌ها رو به این سمت برده.مستند معروف «معمای اجتماعی» که خلاصه‌اش رو برای کسانی که دسترسی ندارند پیش‌تر در این یادداشت نوشته بودم، این خطرها رو خیلی بهتر توضیح داده، کمی دراماتیک ولی حرف‌هایی که مهندسان توییتر و گوگل و غیره درش می‌زنن درسته.توصیه‌هایی که مهندسان همین شبکه‌ها در پایان مستند می‌کنن جالبه، بخونید. یکیش اینه که خودتون انتخاب کنید چی ببینید، نذارید شبکه براتون انتخاب کنه. دست کم بین دو گزینه‌ی «توییت‌های اخیر» و «توییت‌های برتر» که در آغاز این رشته توییت گفته شد، آگاهانه انتخاب کنید.

درباره‌ی پاسخ به حادثه - بخش دوم

Kian — Tue, 11 May 2021 06:35:11 +0430

(این نوشته پیش‌تر به شکل رشته توییت نوشته شده بوده و سپس در ویرگول رونوشت شده.)پیش‌تر در این یادداشت کمی به مساله‌ی پاسخ به حادثه پرداختیم. به بهانه‌ی حادثه‌ی اخیر آروان، کمی بیشتر از پاسخ به حادثه (incident response) گپ بزنیم.پاسخ به حادثه‌های بزرگ نه تنها از جهت فنی سخت و حساسه---بیشتر حادثه‌های بزرگ جدید و بی‌سابقه‌اند و مهارشون تا چندین شبانه روز می‌کشه---بلکه از جهت مدیریت فرایند و ارتباطات بیرونی هم بَل حساس‌تر.نخست، فرایند پاسخ «تیمی» به حادثه نیاز به از پیش فکر شدن و آموزش و مانور آمادگی داره، تا افراد دور خودشون نچرخن یا کارها لابه‌لای ارتباطات گم نشه یا کار تکراری یا (بدتر) کار اشتباهی انجام نشه. نرخ اشتباه در تب و تاب پاسخ به حادثه به شکل تعجب‌آوری بالاست - ادعای آماری نیست بلکه صرفا به آن‌چه به تجربه دیدم عرض می‌کنم. کار تیمی بهینه، از اون بدتر. در گوگل، از فرایند پاسخ به حادثه‌ی آتش‌نشان‌ها اقتباس شده با نقش‌ها و وظیفه‌های مشخص. جزییات بیشتر را این‌جا بخوانید.مسلما به خوندن یک فصل کتاب نیست، نیاز به بحث و تمرین داره. مثلا هر کسی هر نقشی رو به عهده نمی‌گیره؛ مهمه که برای عوض کردن شیفت برنامه باشه (مثل راننده‌های سیر و سفر)؛ کارهای انجام شده ردگیری بشه برای تمیزکاری بعد؛ داده برای کالبدشکافی (postmortem) نوشتن جمع بشه؛ حتی به افرادِ درگیر به ویژه تازه‌کارترها یادآوری بشه پا شن برن هوا بخورن.دوم، ارتباطات بیرونی (بیرون از تیم فنی) حساب و کتاب و قالب داره، مثلا هر N ساعت یک به‌روزرسانی منتشر می‌شه - اگر هم چیز جدیدی نمی‌دونیم می‌گیم چیز جدیدی نمی‌دونیم. مهم‌تر، ارتباط افراد با بیرون شرکت درباره‌ی حادثه تقریبا ممنوعه، به ویژه برای حادثه‌هایی که روشون توجه هست. تاکید می‌شه که اگر هم ازمون سوال شد یا باید فقط ارجاع بدیم به روابط عمومی یا چیزی بیش‌تر از اون‌چه پیش‌تر به طور عمومی منتشر نشده نگیم، حتی به نزدیکان، چه برسه به صحبت در شبکه‌های اجتماعی. این بخش تنها درباره‌ی پاسخ به حادثه نیست بلکه آموزش عمومی شرکته.اگر برای تدوین پاسخ به حادثه در شرکتتون سوالی داشتید بگید گپ بزنیم.پ.ن. اشاره‌ی آغاز به حادثه‌ی آروان تنها بهانه‌ی نوشت این توییت‌ها بود. چیزی درباره‌ی حادثه یا پاسخ‌شون نمی‌دونم. ولی شب عید پای کارِ شبانه‌روزی پاسخ به حادثه بودن حتما عذابه و به بچه‌هاشون خسته نباشید می‌گم.

احترام به شرکت رقیب

Kian — Tue, 11 May 2021 06:29:02 +0430

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