Kian
Kian
خواندن ۱۴ دقیقه·۷ ماه پیش

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

بخش عمده‌ی مشکلاتِی که با همکاران در شرکت‌های مختلف درباره‌شان گپ زده‌ایم، (به زعم بنده)‌ یک سرشان برمی‌گشته به نداشتن نردبان شغلی مناسب و ساز و کار اِعمال آن (برای ارزیابی و ترفیع‌/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 تفاوت دارد.

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

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