💡 واقعا نیازه تا به Rust جدی فکر کنیم؟

چند وقته توی کامیونیتی توصیفات عجیب و غریبی توسط جَواگِره عزیز (جمع مکسر جوگیر) راجع به Rust می‌بینیم. گویی که «امروزه، عصر Rustنویسی است و مابقی کدها شایسته‌ی لعنت کائنات» (همینو در مورد چیزهای دیگه هم می‌بینیم، ولی باشه برای پست‌های بعدی 😁)

خیلی مهمه که بدونیم «چرا» لینوکس، ویندوز، اندروید و کلی پروژه مهم دیگه در حال بازنویسی برخی کدهای موجود و توسعه برخی کدهای جدیدشون با Rust هستن؟
مثلا توی کرنل ویندوز یک سال و نیمه که راست به صورت رسمی وجود داره (System32\win32kbase_rs.sys) یا لینوکس کرنل ۶.۱۳ که این هفته ریلیز شد علاوه بازهم بخش‌های جدیدتری رو با راست بازنویسی کرده (البته خیلی وقته برخی درایورهاش رو با راست نوشتن) و...

با اینکه فریم‌ورک وب و دسکتاپ و... برای راست می‌بینیم، حتی جایگزین برای الکترون و.. هم داره، باید قبل از افتادن توی حباب، ببینیم «چه مسئله» ای رو قراره برامون حل کنه!

علی‌ای‌حال؛ اگر خواستید بیشتر باهاش آشنا شید (برای یادگیری مفاهیم طراحی زبان، روش‌های مدیریت هم‌زمانی و حافظه و... مایکروسافت به عنوان یکی از اعضاء جدی و مهم بنیاد راست، مستندات خیلی خوبی ویژه‌ی توسعه‌دهندگان دات‌نت که قصد مهاجرت یا یادگیری Rust دارن، توسعه داده که می‌تونید به عنوان یک رفرنس عالی ازش استفاده کنید)

https://microsoft.github.io/rust-for-dotnet-devs/latest/

👨‍💻 وقتی دیتابیس سرور شلوغه!!

✅ قابلیت WAIT_AT_LOW_PRIORITY
تاحالا شده موقع ساخت یا بازسازی ایندکس روی سروری که کاربرهای هم‌زمان زیادی داره دچار مشکل شید و lockها جلو کارتون رو بگیرن؟ اگر پاسخ مثبته پوستر رو بخونید 😊

✅ قابلیت RESUMABLE
حالا یه سوال دیگه؟ تا حالا شده بخواهید روی یک جدول بزرگ ایندکس / کلید اصلی بسازی یا ایندکس بازسازی کنی ولی حجم فعالیت سنگین باشه و آرزی کنی ای کاش می‌شد تا اینجا رو pause کنم، بقیه‌اش رو بعدن ادامه بدم؟ اگر پاسخ مثبته، این چند کد رو که توی نسخه ۲۰۲۲ کار می‌کنه ببین لطفا:

ALTER TABLE table1
ADD CONSTRAINT PK_Constrain PRIMARY KEY CLUSTERED (a)
WITH (ONLINE = ON, MAXDOP = 2, RESUMABLE = ON, MAX_DURATION = 240);


ALTER TABLE table2
ADD CONSTRAINT PK_Constrain UNIQUE CLUSTERED (a,b)
WITH (ONLINE = ON, MAXDOP = 2, RESUMABLE = ON, MAX_DURATION = 240);

✨ یک توصیه دوستانه: اگر حتی از دور و بر دیتابیس (حالا هر دیتابیسی، از PostgreSQL و MySQL و Oracle و MS SQL Server تا MongoDB و...) رد می‌شید، «حتما» ایندکس‌ها رو عمیقا یاد بگیرید و مسلط باشید.

این موضوع اینقدر مهمه که اگر فکر می‌کنید در درک صحیح و عمیق ایندکس مشکل دارید، با ری‌اکشن ⚙️ برای برگزار کردن کلاس آنلاین اعلام کنید (به ۳۰ تا برسه حداقل ۳ جلسه آنلاین روش خواهیم داشت)

این ویدیو از دکتر شهشهانی عزیز چند وقته زیاد دست‌به‌دست می‌شه.
از اونجایی که نظام آموزشی ما مشکلات ساختاری زیادی داره، احتمالا اینکه «این درس‌ها مثل ریاضی و معادلات دیف و محاسبات عددی و... به چه درد می‌خوره/می‌خورد» سوال خیلی‌ها خصوصا جوان‌ترها باشه، زیاده.

چیزی که می‌نویسم، ترکیبی از پاسخیه که تقریبا جمله‌به‌جمله‌اش بعد از این همه سال یادم مونده و بخش زیادیش توی این ویدیو تکرار شده + درک و شهود خودم.

هدف نظام آموزشی اصلی (چیزی که توی ایران صرفا از نظر شکلی کپی شده) از مدارج تحصیلی اینه:

- تکنسین (فوق دیپلم): فرد، یک سری مهارت مشخص رو برای انجام کارهای مشخص یاد بگیره؛ بیشتر، نه!

- مهندسی (لیسانس): فرد، به «دانش عام حل مسئله» برسه، یعنی روش‌ها و زاویه نگاه‌های مختلف رو برای بررسی مسائل یاد بگیره، و بدونه چه نوع مسئله‌ای از طریق چه روشی قابل حل است.

- مهندسی (فوق لیسانس): فرد علاوه بر «دانش عام به حل مسائل» روی یک تیپ «مسئله مشخص» تمرکز می‌کنه و روی یکی از روش‌های حل اون مسئله، «بهینگی» ایجاد می‌کنه.

- مهندسی (دکترا): فرد روی تیپ مسئله مشخصی که قبلا دانشش رو تعمیق کرده، «یک روش حل مسئله جدید» ارائه می‌کنه به جهان.

❓عارضه‌یابی نظام آموزشی مهندسی:

*️⃣ کتب درسی، یک‌به‌یک «وارد» و «تدریس» می‌شن؛ ولی ارتباط بینشون وارد نشده! مثل قطعات مختلف یک ماشین که جدا جدا وارد کردیم، ولی یادمون رفته دستورالعمل مونتاژ ماشین رو بیاریم!! به بچه‌های مردم قطعات جدا جدا می‌فروشیم، بدون اینکه وصل شده باشن به هم!

*️⃣ صنعت و دانشگاه باید مثل یک مدار «سری» بسته بشن، نه «موازی»! توی ایران فرم غالب، موازی است.

*️⃣ «دوره دانشگاهی» در خدمت «هدف» فرد نیست؛ بلکه «هدف افراد» در خدمت «تحصیل دانشگاهی» است. تا اینجا مشکل ۳۰ درصده، ۷۰ درصد مشکل وقتی کامل میشه که جایی که «باید» هدف برای افراد شکل بگیره هم کارش رو درست انجام نمی‌ده!!
همین عارضه متوجه خود دانشگاه هم هست، یعنی هدف تاسیس خیلی دانشگاه‌ها عملا آمار تعدادی و اشتغال‌زایی برای کارکنان دانشگاه بوده؛ همین بلا رو هم با «تعداد» مقاله و مفهوم چرندی مثل «تولید علم» آوردن.

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

ببخشید اگر غیر مرتبط با مطالب کانال بود... 😊🌱

💡 بالاخره MongoDB یا SQL Server؟ RDBMS یا NoSQL؟

سال‌هاست که توی کامیونیتی، یه عده از جواگره عزیز یه جوری در مورد NoSQL صحبت می‌کنن که گویی دوای درد هر نوع نرم‌افزاریه! یا گاها طوری وانمود می‌کنن که انگار NoSQL نسل بعدی دیتابیس‌ها پس از دوران RDBMSهاست!! بحمدلله و المنه MEAN stack (MongoDB, Express, Angular, Node) هم بهشون کمک کرده تا مثال‌های سریع و قشنگ رو کنن. از اون طرف هم سوگند خورده‌های Oracle و SQL Server از بیخ NoSQL رو حتی بعد از این همه سال حباب و مُد زودگذر می‌دونن!! ولی واقعیت اینه که هر کدوم برای حل مسائل خاص خودشون طراحی شدن.


در واقع MongoDB یک پلتفرم عالی برای داده‌های با ساختار منعطف و مقیاس‌پذیری افقیه. مثلاً وقتی داده‌هاتون ساختار ثابتی نداره، یا نیاز دارید به سرعت تغییرات اسکیما اعمال کنید. یا سناریوهایی که حجم write بالاست و eventual consistency قابل قبوله.

از اون طرف، SQL Server (و Oracle) غول باتجربه‌ایه که ACID transactions، روابط پیچیده و کوئری‌های سنگین رو به خوبی مدیریت می‌کنه. توی سیستم‌های مالی، بانکی و هر جا که consistency داده حیاتیه، همچنان پادشاهی می‌کنه و البته امکانات انترپرایز امنیتی و پایداری و توزیع‌پذیری داره.

انتخاب تکنولوژی فقط به قابلیت‌های فنی محدود نمیشه. تجربه تیم، اکوسیستم ابزارها، هزینه‌های نگهداری و مهم‌تر از همه "مسئله‌ای که قراره حل کنیم" توی تصمیم‌گیری موثرن.

شروع سریع با MongoDB
مقایسه جزئی‌تر از زبان مونگو
محصول رقیب مایکروسافت (Cosmos DB)

🤖 آخرش AI باعث بیکاری ما خواهد شد؟

لابلای اخبار کلی مطلب می‌بینیم در مورد اینکه هوش مصنوعی تا فلان سال (اکثرا بین ۳ تا ۱۰ سال رو پیش‌بینی می‌کنن) فلان درصد از آدم‌ها رو بیکار می‌کنه و دیگه مهندس‌های نرم‌افزار باید غازهاشون رو صبح به صبح به چَرا ببرن و...

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

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

من هوش مصنوعی فعلی رو چیزی فراتر از تحولات بالا نمی‌دونم، روزی که برنامه‌نویس‌ها توی vim کدنویسی می‌کردن، آیا اومدن IDEها و ادیتورهای مدرن که autocomplete و کلی ابزار قوی که سرعت و سهولت رو به توسعه میداد، حتی اومدن low-codeها no-codeها ما رو بیکار کرد؟
آیا اومدن روبات‌ها به صنایع خودروسازی باعث بیکاری سراسری شد؟

جواب هر دو سوال: هم بله است هم خیر. جنس بیکار کردن AI از جنس بیکار کردن سیر جاری پیشرفت تکنولوژی است. تایپیستی که زرنگار و بعدتر ورد یاد نگرفت، و بعدترش از speech-to-text استفاده نکرد و مهارتش رو به ویراستاری ارتقاء نداد، مثل برنامه‌نویسی که روی ابزارهای جدید مهاجرت نکرد و به‌روز نموند شغلش یا حس پویایی‌اش نابود شد.

در دنیای مدرن مابه‌ازای تولید هر ۱۰۰۰ خودرو، بین ۵ تا ۱۰ نفر شاغل می‌شن (با وجود روبات‌ها و ابزارهای خودکار پیشرفته)، در ایران، این عدد ۷۰ تا ۱۵۰ نفر است!!! آیا اگر تویوتا یا تسلا در ایران کارخونه بزنن یا همین کارخونه‌ها رو تصاحب کنن، نباید تعداد زیادی آدم غیربهره‌ور اخراج شن؟ همین رو به نرم‌افزار تعمیم بدیم؛ آیا با وجود کوپایلوت و ابزارهای مدرن؛ برنامه‌نویسی که هنوز نرم‌افزار CRUD می‌نویسه، و به کاربرش و سازمان بهره‌بردار از نرم‌افزار، امکانات مبتنی بر AI برای بهره‌وری بیشتر نمی‌ده، نباید حذف شه؟ یا اگر حذف نشه، نباید درجا بزنه و رشد نکنه؟
برنامه‌نویسی که امکانات مدرن به محصولش نیاره، مثل شرکت‌هایی هستن که به خودروسازهای داخلی ما امکانات رباتیک هوشمند و بهره‌ور ندادن، هم مشتری‌شون (خودروساز) رو غیربهره‌ور کردن هم خودشون عقب‌موندن. حالا فرق AI در نرم‌افزار اینه که که چون امکانات فیزیکی مثل کارخونه‌ و روبات‌های بزرگ و... نیاز نداره و شما از هر جای دنیا می‌تونی از یک مدل در جایی دیگر از جهان استفاده کنید، مهاجرت و اثرگذاری سریع‌تری خواهد داشت.

از نگاه ایران: متاسفانه در زمانه‌ای که کشورها سر تحولات بزرگ هوش‌مصنوعی و دسترسی به تراشه‌ رقابت دارن، دیپ‌سیک چینی در عرض چند روز حتی توی آمریکا به بالای لیست میاد؛ ایران درگیر فیلتر بودن یا نبودن بدیهیات و اینترنت طبقاتی و... است. لذا با تاسف و تألم عمیق، بعید می‌دونم تغییرات در ایران وسعت و عمق زیادی داشته باشه. دلایلم وسیع و بیانش زمان‌بره ولی اگر از چند شرکت پیشرو عبور کنیم، معدل بقیه‌ی جامعه نرم‌افزاری کشور، بسیار پایینه. پیشنهاد می‌کنم دیدگاه کلان داشته باشیم و کل جامعه نرم‌افزاری رو ببینیم نه چند شرکتی که روز به روز هم کوچکتر و کُندتر می‌شن (مهاجرت نیروی متخصص، شرایط اقتصادی، انزوای تکنولوژیک، سیاست‌های کشور و...). همین جامعه نرم‌افزاری ایران سهم مهمی از شرایط دولت داشته که به جای ۱۵ تا ۲۵ نفر کارمند به ازای هر ۱۰۰۰ نفر، ۳۰ تا ۳۵ کارمند با بهره‌وری «برو فردا بیا؛ برو هفته دیگه بیا» داره؛ در حقیقت نرم‌افزارهایی توسعه دادن که شفافیت، business observability و integrity رو به سخره گرفتن!

لذا درست مثل زمانی که IDEهای مدرن اومدن، AI رو به مثابه ابزاری ببینیم که قراره به ما کمک کنه تا محصولات «امروزی» تری بسازیم، مشتریانمون رو توانمندتر و بهره‌ورتر کنیم و دانشمون رو ارتقاء بدیم. به جای حباب‌ها رو هیجانات هم روی تعمیق و گسترش دانشمون کار کنیم...

نظرتون رو بگید لطفا 😊🌱

🤪 ۷ نوع از جواگره و رفقای ادایی!

⚠️ این پست، فنی نیست، فقط شوخی و تخیلی است!

«حالا که چند بار کلمه جواگره که جمع مکسر جوگیر است رو به کار بردم لازمه تا انواعشون رو برشماریم»

۱. فن‌بوی/فن‌گرل (Fanboy)
اینا به‌شدت به یک برند یا تکنولوژی خاص وفادار هستن و اغلب به‌طور غیرمنطقی ازش دفاع می‌کنن (مثلاً طرفدارای اپل یا پی‌اچ‌پی یا جاوا، دقت کنین که دات‌نت و گو فَن‌بوی ندارن، همه از بیخ جنتلمن، لیدی و فهیم و منطقی هستن چون کسی حق نداره در مورد حضور ابرو در سمت فوقانی چشمشون صحبت کنه! حالا خود دانید؛ اصلنشم فن‌بوی خودتونید و ۷... ).
رفتار: مخالفت شدید با هر محصول یا تکنولوژی رقیب. از زمره‌ی خطرناک‌ترین جواگره.


۲. ترول (Troll)
کسایی که عمداً بحث‌ها و مباحثات رو خراب می‌کنن تا دیگران رو تحریک کنن.
رفتار: نظر دادن‌های بی‌ربط یا بحث‌برانگیز، صرفاً برای جلب توجه یا ایجاد دعوا. حداکثر اصطکاک با سطح مُخ رو دارند. اساتید whataboutism در مباحثات. اینا اگر توی کامیونیتی نرم‌افزاری‌ها چرند نبافن، حتمن در اون ساعت و لحظه، توی گفتگوی ویژه خبری تلویزیون دارن روان ۸۰ میلیون نفر رو سیقل می‌دن، مثلا با طرح دلایل متقن! در مورد تاثیر فیلترینگ بر شادابی پوست و افزایش طول عمر!


۳. فومو (FOMO: Fear of Missing Out)
افرادی که به دلیل ترس از جا موندن از فناوری‌های جدید، همیشه به دنبال خرید یا تجربه آخرین محصولات و تکنولوژی‌ها هستن.
رفتار: خرید فوری هر محصول جدید یا ثبت‌نام توی سرویس‌های تازه معرفی‌شده. اینا حقوقشون به پنجم ماه بیشتر قد نمی‌ده. از سابسکریپشن هوش‌مصنوعی تا تمام سرویس‌های موسیقی، تا هزاران گیگ ویدیو آموزشی تمام تکنولوژی‌های جهان رو دارن. عموما از شدت استرس عقب موندن از موج اتفاقات، مجبورن شب‌ها ماینوکسیدیل ۹۰ درصد، گل ختمی و جوشونده خارشتر به سرشون بمالن.


۴. هایپ رایدر، هایپ‌مستر (Hype Rider)
کسایی که فقط به دلیل "مد شدن" یا "حواشی" سراغ یک تکنولوژی می‌رن.
رفتار: مثلاً هوش مصنوعی رو فقط به خاطر ترند بودن، بدون علاقه واقعی، بلغور می‌کنن. اینا حتی وبلاگشون که هنوز متون lorem ipsum و «سلام دنیا، این اولین پست وردپرس است» توشه رو «باید» روی کوبرنتیز بیارن بالا. این گونه از جواگره، دانششون دریایی به عمق ۱ سانتیمتره و پارسال با عینک اپل‌ویژن در سطح خیابونا زیاد دیده شدن. در پاسخ «چرا» عموما به سقف یا گاهن به سمت افق خیره می‌شن.


۵. میم‌باز تکنولوژی (Tech Meme Lord)
کسایی که علاقه دارن مسائل تکنولوژی رو در قالب میم مطرح کنن.
رفتار: اینا حرف نمی‌زنن، تایپ نمی‌کنن، فقط میم می‌فرستن. هر جا دکمه submit یا send داشته باشه جوک‌های فنی و میم می‌فرستن. این گونه‌از جواگره بعد از مدتی به درجه‌ای از بی‌مزگی و تکرار می‌رسن که نیازی ندارن تا همسر برادر همسرشون تست بارداری بده، چون «قطعا» شوهرعمه شدن!

۶. نوستالژی‌باز (Tech Nostalgic):
اینا مدام از گذشته تکنولوژی تعریف می‌کنند و معتقدن همه چیز قبلاً بهتر بود.
رفتار: ساعت کاسیو اف۹۱ دستشونه، گوشی نوکیا دارن هنوز (با چراغ‌قوه فعال)، عینک طرح مرحوم هویدا می‌زنن، باور دارن دلفی و SQL Server 2000 هنوزم کافیه و بهترین استک است، تنها مشکلشون اینه که مشتری‌هاشون باید ویندوز XP اونم ۳۲ بیتی نصب کنن.

۷. اسنوب فناوری (Tech Snob):
اینا فقط گرون‌ترین و جدیدترین گجت‌ها رو قبول دارن و به انتخاب‌های دیگران با تحقیر نگاه می‌کنن.
رفتار: هر کس اندروید داره و آیفونش قدیمی‌تر از ۱۶ است، اُمُل، کَدی، و حتی اًزگَل به شمار میاد. ویندوز دارها مستحق سوزانده شدن در کوره آجرپزی هستن و مَک تنها پاسخگوی نیازهای این بزرگوارانه، چرا؟ چون با «زبان برنامه‌نویسی» HTML و CSS پروژه‌های سنگینشون باید پردازش شه. اینا عموما یه کلیه ندارن، مسابقات ملی چارقاپ شپش‌ها انتهای جیبشون برگزار می‌شه ولی در عوض پشت یَک یَک گجت‌هاشون یک سیب گاز زده است.

💬 کدومشون رو بیشتر دور و برتون داشتید و بابت رفتارهاش آماده‌ی سر سپردن به حکم قاضی و حبس تعزیری بودید؟ 😅

⚙️ مطلب بعدی...

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

💬 سوالات و دغدغه‌ها رو بدونم روی ابهام‌ها بیشتر توضیح خواهم داد... 😊

📇 سلسله‌مراتب مهندسی نرم‌افزار و ساختار سازمانی (بخش اول)

سلسله‌مراتب مهندسی نرم‌افزار موضوع مهمیه، هم برای سازمان که بخواد با ساختار مناسب به اهداف و برنامه‌هاش برسه و بهره‌وری‌اش رو بهبود بده؛ هم افراد انگیزه برای رشد و یادگیری و رقابت داشته باشن. پس داشتن یه ساختار سازمانی درست + ساز و کار ارزیابی و رشد سرمایه‌انسانی، نه تنها حیاتیه، بلکه یه چالش بُرد-بُرد برای سازمان و افراده.

قبل از توضیح در مورد انواع سلسله‌مراتب مهندسی نرم‌افزار، باید بدونیم » چجوری ساختار سازمانی مناسب رو انتخاب کنیم؟

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

موارد زیر تنها تعدادی از مولفه‌های مورد بررسی برای طراحی ساختار سازمانی مهندسی نرم‌افزاره، برای هر کدوم دو مورد مثال ذکر می‌کنم.
توجه داشته باشید که هم مولفه‌های بیشتری دخیله، هم مثال‌های متنوع‌تری میشه از انواع هر مولفه زد که از حوصله پست تلگرامی خارجه.

۱. اندازه شرکت
*️⃣استارتاپ‌ها: ساختار مسطح (Flat) با نقش‌های چندوجهی.
*️⃣شرکت‌های بزرگ: سلسله‌مراتب واضح با تخصصی‌سازی نقش‌ها.

۲. پیچیدگی محصول
*️⃣سیستم‌های پیچیده: نیاز به نقش‌های تخصصی (مثل مهندس بهینه‌سازی یا مهندس MLOps یا...).
*️⃣محصولات ساده: ساختار عمومی‌تر.

۳. فرهنگ سازمانی
*️⃣ساختار مبتنی بر نوآوری با آزادی عمل بالا برای مهندسان.
*️⃣ساختار متمرکز بر مشتری با تیم‌های مستقل (Squads).

۴. اهداف رشد
*️⃣اگر هدف توسعه سریعه: ساختار Agile با تیم‌های Scrum/کانبان.
*️⃣اگر هدف پایداریه: ساختار سلسله‌مراتبی با فرآیندهای دقیق (CMMI).

❓حالا چجوری نیازهای سازمان رو تشخیص بدیم؟

۱. نیازسنجی (Gap Analysis):
*️⃣چه مهارت‌هایی در تیم موجود نیست؟
*️⃣آیا ارتباط بین تیم‌ها کُنده؟
*️⃣آسیب‌شناسی محصول و تیم چی بهمون می‌گه؟

۲. مقایسه با شرکت‌های مشابه (Benchmarking):
*️⃣بررسی ساختار شرکت‌هایی با اندازه و حوزه فعالیت مشابه که «شرایط، بضاعت و استعداد مشابه دارن». طبیعتا اگر شرکتمون ۲۰۰ نفره و سیستم اداری تولید می‌کنه، اینکه بگردیم یه شرکت ۲۰۰ نفره نوآور در آمریکا یا ژاپن رو الگو کنیم منطقی نیست (گرچه خیلی‌ها این کار رو می‌کنن و بعد می‌بینیم staff engineer شون رفته مرخصی تا امتحان مدار منطقی‌اش رو نیوفته 😁)

۳. تعریف نقشه راه (Roadmap):
*️⃣باید نقشه‌راه کوتاه‌مدت، میان‌مدت و چشم‌انداز بلندمدت خوبی از کسب‌وکار و محصول داشته باشیم. یا اینکه هر وقت تغییر کردن بشینیم و ساختار سلسله‌مراتب و سازمانمون رو مرور کنیم ببینیم هنوز متناسبه؟! مثلا اگر هدف تبدیل شدن به یک شرکت مبتنی بر داده است، نقش‌هایی شاید اضافه کنیم، یا اگر قراره شرکت رشد بزرگی کنه، سلسه‌‌مراتبمون تغییر می‌کنه و نقش‌های جدیدی اضافه می‌شن. نقشه راه باید منطبق با واقعیت‌ها باشه، منطقی و قابل حصول باشه (به بیان ساده به قد و قواره‌مون بیاد و با توان و شرایط جور باشه)

۴. انعطاف‌پذیری:
*️⃣ساختار باید قابلیت تطابق با تغییرات بازار یا فناوری رو در خودش پیاده‌سازی کنه. آیه نازل نشده شرکت از روز اول ساختار ابدی و ثابت داشته باشه، ساختار باید در خدمت اهداف و بضاعت و استعداد مجموعه باشه. حالا شما برای تیم ۳ نفره CTO نداشته باشی هم می‌شه، ایشالا شدی ۱۰ تا تیم اونوقت CTO بگیر.

این بخش اول بود، لازم بود توضیح بدم که نقش‌ها و انواع سلسه مراتبی که در قسمت بعدی معرفی خواهم کرد، فقط نمونه‌هاییه که سازمان‌های مختلف بر اساس نیاز و شرایط‌شون ایجاد کردن. مثلا Distinguished Engineer یا Developer Advocate نقش‌هایی است که برخی سازمان‌ها بنا به ضرورت، اهداف و نیازشون ایجاد کردن و دارن، دلیل نمی‌شه همه داشته باشن.

از اون طرف اگر ما نقش‌ها و مسئولیت‌ها رو درست نشناسیم در انتخاب مسیر شغلی شاید انتخاب‌های غیر بهینه‌ای کنیم. پس افراد باید بدونن مسیر رشدهای مختلف چیه تا هم نقشه رشدشون رو ترسیم کنن هم سازمان متناسب رو برای کار کردن انتخاب کنن. از طرفی سازمان‌ها هم باید تکلیفشون مشخص باشه تا بتونن چرخه تربیت و رشد سرمایه‌انسانی رو ترسیم و اجرا کنن. شما برای تربیت نیروی انسانی باید افرادی رو داشته باشی که «بلد باشن و شایستگی» هدایت نیروی انسانی رو داشته باشن. نه اینکه هر وقت مدیر رفت نفر بعدی رو مدیر کنی! یا هر کی شوآف بیشتری داشت ارتقاء بدی!

🌱 لطفا دقت شود: «هدایت» با «راهنمایی» بسیار فرق داره! هدایت یعنی من دست شما رو بگیرم ببرمتون به مقصد مشخص برسونم. ولی راهنمایی یعنی بهتون آدرس رو بگم. لیدرشیپ نوعی از هدایت است، وگرنه راهنمایی توی اینترنت زیاده!

دوست دارید ادامه بدم و قسمت دوم و بعدترش رو داشته باشیم؟
💬 نظر؟ تجربه؟ سوال؟

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش دوم, گوگل!)

خب حالا که فهمیدیم انتخاب ساختار سازمانی بستگی به نیازها و شرایط داره، بریم سراغ یه نمونه واقعی: گوگل!
گوگل یکی از شرکت‌هاییه که ساختار مهندسی مدون و تعریف‌شده‌ای داره و خیلی‌ها تو مسیر شغلی‌شون دوست دارن بدونن که این مسیر رشد توی گوگل چطوره. البته دوباره تأکید کنم: ساختار گوگل برای گوگل خوبه! کپی کردنش بدون توجه به اندازه، اهداف، و فرهنگ سازمانی شما مثل این میمونه که کت و شلوار سایز ۳XL بخری ولی قدت ۱۲۰ باشه! 😁

۱. سطح Software Engineer I (L3)
📌 تجربه و دانش: معمولاً تازه‌واردها، فارغ‌التحصیلان دانشگاه یا کسانی که صفر تا دو سال تجربه دارن
❓ مسئولیت‌ها:
➖ پیاده‌سازی تسک‌های ساده و متوسط تحت نظر مهندسان ارشد
➖ یادگیری استانداردهای گوگل، سیستم‌ها و بهترین شیوه‌های کدنویسی
➖ توسعه ویژگی‌های کوچک (مثلاً یک دکمه جدید در جیمیل)

✅ مهارت‌ها:
➖ تسلط به یک زبان برنامه‌نویسی (مثلاً پایتون یا جاوا)
➖ آشنایی با مفاهیم پایه الگوریتم و داده

۲. سطح Software Engineer II (L4)
📌 تجربه و دانش: معمولاً چند سال (۲ تا ۵ سال) تجربه کاری در پروژه‌های واقعی
❓ مسئولیت‌ها:
➖ طراحی و پیاده‌سازی ویژگی‌های متوسط (مثلاً بهبود سرعت بارگذاری یوتیوب)
➖ مشارکت در طراحی‌های کوچک و همکاری نزدیک‌تر با تیم‌های دیگه (تیم‌های کراس‌فانکشنال)
➖ کمک به تازه‌واردها برای درک بهتر فرآیندهای مهندسی و مشارکت در تصمیم‌گیری‌های فنی

✅مهارت‌ها:
➖ تسلط به طراحی سیستم‌های توزیع‌شده
➖ توانایی رفع باگ‌های پیچیده

۳. سطح Senior Software Engineer (L5)
📌 تجربه و دانش: معمولاً ۵ تا ۱۰ سال تجربه، فرد باید بتونه راه‌حل‌های فنی جامع و بهینه ارائه بده؛ یا کل پروژه رو از صفر تا صد هدایت کنه
❓ مسئولیت‌ها:
➖ رهبری پروژه‌های فنی بزرگ‌تر (مثلاً توسعه قابلیت‌های جدید در Google Maps)
➖ تصمیم‌گیری‌های فنی و ارائه راه‌حل برای چالش‌های پیچیده (مثلاً سیستم کش‌سازی پیشرفته)
➖ کمک به رشد مهندسان جوان‌تر (منتورینگ L3 و L4ها)

✅ مهارت‌ها:
➖ تسلط به معماری ابری (مثلاً Google Cloud)
➖ توانایی حل مسائل مقیاس‌پذیر (Scale)

۴. سطح Staff Software Engineer (L6)
📌 تجربه و دانش: معمولاً بالای ۱۰ سال تجربه، کسی که بتونه تصمیمات کلیدی فنی بگیره
❓ مسئولیت‌ها:
➖ هدایت تیم‌های مهندسی در مسیر درست و رهبری فنی چندین تیم (مثلاً هماهنگی بین تیم‌های جستجو و تبلیغات).
➖ طراحی معماری و تعیین استراتژی فنی سیستم‌های بزرگ و پیچیده. (مثلاً بهبود الگوریتم‌های جستجو)
➖ ارتباط بین تیم‌های مختلف و اطمینان از یکپارچگی سیستم (مثلاً یکپارچه‌سازی AI در محصولات مختلف)

✅ مهارت‌ها:
➖ دید کلان به چالش‌های سازمان
➖ توانایی تاثیرگذاری روی مدیران ارشد

۵. سطح Senior Staff Engineer (L7)
📌 تجربه و دانش: ۱۵+ سال تجربه، این سطح برای متخصصین عمیق در یک حوزه فنی در نظر گرفته شده (مهندسینی که در صنعت شناخته شده‌اند)
❓ مسئولیت‌ها:
➖ تعریف استراتژی‌های فنی برای تیم‌های مختلف
➖ طراحی سیستم‌های حیاتی یا راه‌حل‌هایی که مقیاس‌پذیری و کارایی بالایی دارن (مثلاً زیرساخت‌های امنیتی گوگل)
➖ تعامل مستقیم با VPها و C-Levelها برای شکل‌دهی به نقشه راه فنی
➖ انتشار مقالات تحقیقاتی یا ثبت پتنت

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Machine Learning یا Distributed Systems).
➖ رهبری بدون اختیار رسمی (Influence بدون Title).

۶. سطح Principal Engineer (L8)
📌 تجربه و دانش: عموما ۲۰+ سال تجربه و سطحی که فقط تعداد کمی از مهندسان بهش می‌رسن
❓ مسئولیت‌ها:
➖ تصمیم‌گیری‌های استراتژیک در مقیاس شرکت
➖ راهنمایی چندین تیم بزرگ و پروژه‌های بین‌سازمانی
➖ بررسی و حل مشکلاتی که روی عملکرد کل گوگل تأثیر دارن

۷. سطح Distinguished Engineer / Google Fellow (L9 - L10)
📌 تجربه و دانش: یکی از بالاترین جایگاه‌های مهندسی که فقط تعداد محدودی بهش می‌رسن
❓ مسئولیت‌ها:
➖ تعیین مسیر فنی کلان برای گوگل یا توسعه فناوری‌های تأثیرگذار در صنعت (مثلاً تصمیم به توسعه TensorFlow)
➖ نمایندگی گوگل در کنفرانس‌های جهانی (مثلاً Google I/O)
➖ هدایت نوآوری‌های انقلابی (مثلاً پروژه‌های کوانتومی)
➖ تعامل با مدیران اجرایی (مثل CTO) برای نوآوری و آینده‌نگری

✅ مهارت‌ها:
➖ بینش استراتژیک در سطح صنعت
➖ شبکه ارتباطی قوی با دانشگاه‌ها و مراکز تحقیقاتی
💡 نکته مدیریتی: L8ها مشاوران اصلی ساندار پیچای (مدیرعامل گوگل) هستن!

جمع‌بندی:
سلسله‌مراتب گوگل برای شرکتی با ۱۷۰ هزار کارمند و محصولات جهانی طراحی شده. اگر سازمان شما ۵۰ نفر است، دنبال استخدام L8 نباشید! 😂
موفقیت در گوگل (و هر شرکتی) به تاثیرگذاری (Impact) وابسته است، نه صرفاً سال‌های تجربه. پس به جای تقلید کورکورانه، ساختاری طراحی کنید که متناسب با قد و بالای سازمان شما باشه!

💬 شرکت بعدی چی باشه؟ (کامنت کنید)
بوکینگ؟ مایکروسافت؟ اپل؟ Miro؟ ING؟ Meta؟ Ayvens؟

اگر مثال شرکت‌های دیگه رو ادامه بدم، ری‌اکشن: ⚙️
اگر این بحث کافیه، ری‌اکشن: 🤪

✨🚀 تفاوت output، outcome و impact

مقدمه: یکی از چالش‌های متعدد و اساسی جامعه ما اینه که «سوال نداریم» خصوصا «سوال خوب»!! شاید روزی مفصل نوشتم در موردش... فعلا بگذریم...
امروز یک سوال «خوب» در مورد مطلب قبلی طرح شد؛ ممنون از آقا یا خانم NaN که پرسیدن:

❓ «یکم بیشتر توضیح میدین منظورتون از Impact چیه؟»

به احترام پرسش خوب ایشون سعی می‌کنم در حد بضاعت پست تلگرامی توضیح بدم.

توی مباحث لیدرشیپ فنی، ۳ تا کلمه داریم که دونستن معانی اون‌ها مهمه:

💡 در مورد Output (خروجی)

تعریف: خروجی، محصول مستقیم و قابل‌اندازه‌گیری فعالیت‌ها یا وظایفه. درواقع، ماحصل بلافصل کاریه که انجام می‌دهیم؛ مثلاً کدنویسی، طراحی، مستندسازی یا تولید نسخه اولیه نرم‌افزار. عملا فعالیت‌ها یا محصولات ملموسی که تیم تولید می‌کند.

⚙️ مثال:
➖ تعداد خطوط کد نوشته‌شده، یا ماژول‌های تکمیل‌شده
➖ ویژگی (Feature) جدیدی که به محصول اضافه شده
➖ مستندات فنی یا طراحی رابط کاربری

✅ ویژگی: خروجی معمولاً به‌راحتی قابل‌شمارش یا اندازه‌گیریه؛ مثلاً با شمارش تسک‌های انجام‌شده یا تعداد فیچرهای ارائه شده در هر اسپرینت.

===========================

💡 در مورد Outcome (نتیجه)

تعریف: نتیجه به تأثیرات و تغییراتی اشاره داره که به واسطهٔ یک خروجی در رفتار یا وضعیت کاربران، کسب‌وکار یا فرایندهای داخلی به وجود می‌یاد. Outcome معمولاً روی «ارزش» تمرکز داره؛ اینکه خروجی تولیدشده چه مشکلی را حل کرده یا چه بهبودی ایجاد کرده.

⚙️ مثال:
➖ افزایش رضایت کاربران به‌دلیل اضافه شدن یک قابلیت مهم در نرم‌افزار
➖ کاهش زمان پاسخ‌گویی سرور پس از بهینه‌سازی کد
➖ بهبود نرخ تبدیل (Conversion Rate) یا رشد کاربران فعال روزانه (DAU)

✅ ویژگی: نتیجه معمولاً به معنای دستیابی به بهبود یا حل مشکل مشخصی است. اندازه‌گیری اون اغلب به شاخص‌های عملکردی (KPIs) یا داده‌های تحلیلی وابسته است (مثلاً بررسی نرخ ریزش کاربران قبل و بعد از اضافه‌شدن فیچر جدید).

===========================

💡 در مورد Impact (تأثیر یا اثرگذاری کلان)

تعریف: Impact سطحی کلان‌تر از «نتیجه» است که نشون می‌ده تغییرات ایجادشده چه اثرات عمیق یا پایدار در جامعه، بازار، استراتژی کلان شرکت یا حتی صنعتی که شرکت توش فعالیت می‌کنه، داشته است. Impact فراتر از یک «دوره کوتاه» یا «مقیاس کوچک» است و غالباً در بلندمدت ارزیابی می‌شود.

⚙️ مثال:
➖ تغییر جایگاه شرکت در بازار نرم‌افزار (مثلاً تبدیل شدن به یکی از پیشروان صنعت)
➖ تأثیر مثبت بر جامعه: ایجاد اشتغال، بهبود زندگی مشتریان یا حل یک مشکل فراگیر اجتماعی
➖ تحول فرایندهای یک سازمان بزرگ که مشتری شرکت شماست (مثلاً یک سیستم سازمانی که کیفیت خدمات دولتی رو ارتقا داده است)

✅ ویژگی: تأثیر کلان ممکن است با معیارهای مالی (نظیر افزایش چشمگیر درآمد یا ارزش سهام) یا با شاخص‌های غیرمالی (مثل ارتقای آگاهی جمعی، تغییر رفتار اجتماعی) سنجیده بشه. گاهی برای سنجش دقیق Impact نیاز به گذر زمان و بررسی ابعاد گوناگون نتایج است.

===========================

⚙️ اینم بگم که گاهی ما تصور می‌کنیم فجایع و چرندیاتی که تولید کردیم impact یا outcome یا output بوده! اکثریت غالب شرکت‌های نرم‌افزاری‌ای که تپه‌ی سالم توی صنایع مختلف و سازمان‌های دولتی، بانک‌ها، و... باقی نگذاشتن، معتقدند که تاثیر عمیق و بسزایی با محصولات بی‌کیفیت و گاها آشغالشون گذاشتن، اینکه نتیجه بد شده، از کاهلی و وضع بد دیگران بوده!

لذا این خیلی خیلی مهمه که «ملاک سنجش و ارزش‌گذاری» عملکردمون «استاندارد و جهانی» باشه... وگرنه: «خود گویی و خود خندی... عجب مرد هنرمندی!»

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش سوم, مایکروسافت!)

حالا که گوگل رو مرور کردیم، و مفهوم impact در سازمان رو دیدیم، بنا به نظر و پیشنهاد شما، بریم سراغ مایکروسافت ۲۲۸هزار کارمند داره که متناسب با ساختار و نیازهاش، نردبان شغلی خاص خودش رو داره:

۱. سطح L59 - Software Development Engineer I (SDE I)

📌 تجربه و دانش: فارغ‌التحصیل‌های تازه‌کار یا ۰ تا ۲ سال تجربه.
❓ مسئولیت‌ها:
➖ پیاده‌سازی تسک‌های مشخص‌شده تحت نظر مهندسان ارشد
➖ یادگیری ابزارها و سیستم‌های داخلی مایکروسافت
➖ شرکت در Code Reviewها و مستندسازی ساده
➖ رفع باگ‌های جزئی و تست کد

✅ مهارت‌ها:
➖ آشنایی با #C یا ++C
➖ فهم پایه از مفاهیم شیءگرایی

۲. سطح L60 - Software Development Engineer II (SDE II)

📌 تجربه و دانش: معمولاً ۲ تا ۵ سال تجربه، کسی که بتونه مشکلات فنی پیچیده‌تر و پروژه‌های کوچیک رو حل کنه.
❓ مسئولیت‌ها:
➖ توسعه ویژگی‌های جدید و بهینه‌سازی‌های بزرگ‌تر (مثلاً بهبود سرعت اجرای Azure Functions)
➖ شروع به گرفتن تصمیمات طراحی در پروژه‌ها
➖ همکاری با تیم‌های دیگر برای یکپارچه‌سازی سیستم‌ها

✅ مهارت‌ها:
➖ تسلط به طراحی APIها
➖آشنایی با Azure یا سرویس‌های ابری.

۳. سطح L61-L62 - Senior Software Engineer (SSE)

📌 تجربه و دانش: معمولاً بالای ۵ سال تجربه، کسی که بتونه استقلال بیشتری در تصمیم‌گیری‌های فنی داشته باشه
❓ مسئولیت‌ها:
➖هدایت فنی پروژه‌های مهم (مثلاً توسعه قابلیت‌های جدید در Microsoft 365)
➖ارائه راه‌حل‌های بهینه برای مشکلات پیچیده.
➖طراحی معماری سیستم‌های توزیع‌شده (مثلاً بهبود زیرساخت Azure)
➖منتورینگ و کمک به SDEهای سطح پایین‌تر.

✅ مهارت‌ها:
➖ تخصص در حوزه‌هایی مثل ابر، AI یا امنیت
➖توانایی حل مسائل مقیاس سازمانی

۴. سطح L63-L64 - Principal Software Engineer

📌 تجربه و دانش: معمولاً ۸-۱۲ سال تجربه، فردی که می‌تونه چند تیم رو از نظر فنی هدایت کنه.
❓ مسئولیت‌ها:
➖ طراحی سیستم‌های با مقیاس بالا
➖ رهبری تیم‌های فنی و ایجاد هماهنگی بین تیم‌های مختلف (مثلاً هماهنگی بین تیم‌های Xbox و کلود)
➖ تعیین استراتژی فنی برای محصولات استراتژیک (مثلاً توسعه NET Core.)
➖ نظارت بر روند توسعه و تأثیرگذاری در تصمیم‌گیری‌های کلان محصول.

✅ مهارت‌ها:
➖ دید کلان به چالش‌های کسب‌وکار و فناوری
➖توانایی مذاکره با مدیران ارشد (مثل VPها)

۵. سطح L65-L66 - Partner Software Engineer

📌 تجربه و دانش: یکی از بالاترین سطوح مهندسی فنی در مایکروسافت، معمولاً ۱۲+ سال تجربه.
❓ مسئولیت‌ها:
➖تصمیم‌گیری‌های استراتژیک برای کل محصولات یا سرویس‌های بزرگ مایکروسافت.
➖ارتباط مستقیم با مدیران ارشد
➖هدایت چندین تیم مهندسی در راستای اهداف کلان.
➖طراحی سیستم‌های حیاتی (مثلاً معماری جدید Azure AI).

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Distributed Systems یا Quantum Computing).

۶. سطح L67 - Distinguished Engineer

📌 تجربه و دانش: افرادی که تأثیر مستقیمی روی کل صنعت دارن، تعداد این افراد خیلی کمه (مثال: دیوید فولر)
❓ مسئولیت‌ها:
➖مشارکت در تعیین استراتژی‌های بلندمدت مایکروسافت
➖هدایت تحقیقات پیشرفته و توسعه فناوری‌های آینده
➖تعامل با مدیران اجرایی و تأثیرگذاری در مسیر کلی شرکت
➖انتشار مقالات یا ثبت اختراعات کلیدی.

✅ مهارت‌ها:
➖ تخصص عمیق در یک حوزه (مثلاً Distributed Systems یا Quantum Computing).
➖رهبری بدون نیاز به عنوان رسمی (با Influence و Respect).

۷. سطح L68+ - Microsoft Technical Fellow

📌 تجربه و دانش: بالاترین سطح فنی در مایکروسافت! این افراد تأثیرگذارترین چهره‌های تکنولوژی شرکت هستن (اینقدر که مدخل ویکی‌پدیا دارن!)
❓ مسئولیت‌ها:
➖نوآوری‌های کلان در فناوری
➖ارائه راهبردهای تکنولوژیکی در سطح جهانی
➖ارتباط مستقیم با CEO و تعیین مسیر استراتژیک شرکت
➖هدایت نوآوری‌های انقلابی (مثلاً پروژه‌های کوانتومی یا HoloLens)

✅ مهارت‌ها:
➖ بینش استراتژیک در سطح صنعت
➖شبکه ارتباطی با دانشگاه‌ها و دولت‌ها


🔀 مایکروسافت دو مسیر مجزا برای پیشرفت داره:
➖مسیر فنی (IC - Individual Contributor) که از SDE I تا Technical Fellow میره.
➖مسیر مدیریتی که از Engineering Manager تا VP of Engineering ادامه پیدا می‌کنه.

➖ برخلاف گوگل که سلسله‌مراتبش با L3, L4, … مشخصه، در مایکروسافت عناوینش از SDE I تا Technical Fellow سازماندهی شدن.
➖همون‌طور که توی گوگل دیدیم، توی مایکروسافت هم هر چی بالاتر می‌ری، مهارت‌های غیر فنی مثل لیدرشیپ و تصمیم‌گیری استراتژیک اهمیت بیشتری پیدا می‌کنن.

💬 بحث؟ نظر؟
➖ قسمت بعدی و پایانی این بحث، یک شرکت کوچک و متوسط رو به صورت کلی توضیح می‌دم.

📇 سلسله‌مراتب مهندسی نرم‌افزار (بخش چهارم و پایانی, شرکت‌های SME!)

🛠 چرا سلسله‌مراتب مهندسی برای شرکت‌های کوچک و متوسط مهمه؟
شرکت‌های کوچک و متوسط (SMEs) معمولاً چابک‌تر از غول‌هایی مثل گوگل و مایکروسافت هستن، ولی اگر نقش‌ها شفاف نباشه، افراد جای رشد نداشته باشن و سازمان فاقد ساختار منطقی باشه، انگیزه تیم پایین میاد و رشد شرکت متوقف می‌شه. آدم‌ها می‌رن یا فسیل می‌شن! و دیگه نقطه قوت چابکی تبدیل می‌شه به اسباب درجا زدن...

👨‍💻 هدف از طراحی نردبان شغلی اینه که:
✅ مسیر پیشرفت مشخص باشه
✅ افراد بدونن برای ارتقا به چه مهارت‌هایی نیاز دارن و پوزیشن‌ها سلیقه‌ای پخش نشده
✅ شرکت بتونه استعدادها رو پرورش بده، نه فقط استخدام و اخراج کنه
✅ هم رشد فردی اتفاق بیفته، هم رشد سازمانی

🔹 سلسله‌مراتب پیشنهادی برای یک شرکت پویا و مقیاس‌پذیر

۱. سطح Junior Software Engineer 👶

📌 ویژگی‌ها: ۰ تا ۲ سال تجربه، تسلط روی اصول برنامه‌نویسی و یکی دو تکنولوژی
🔹 مسئولیت‌ها:
✅ یادگیری استانداردهای کدنویسی و فرآیندهای شرکت
✅ توسعه تسک‌های کوچک تحت نظر افراد ارشد
✅ نوشتن تست‌های ساده و رفع باگ‌های سطحی
🎯 شرایط ارتقا: تسلط به ابزارهای توسعه شرکت، بهبود درک معماری نرم‌افزارها

۲. سطح Software Engineer 👨‍💻 (مهندس نرم‌افزار)

📌 ویژگی‌ها: ۲ تا ۵ سال تجربه، توانایی توسعه ویژگی‌های مستقل
🔹 مسئولیت‌ها:
✅ پیاده‌سازی و بهینه‌سازی بخش‌های اصلی اپلیکیشن
✅ مشارکت در طراحی‌های کوچک و کدنویسی با کیفیت بالا
✅ همکاری با تیم‌ها یا نقش‌های دیگه مثل QA و DevOps
🎯 شرایط ارتقا: ارائه راه‌حل‌های بهینه‌تر (نه شوآف!) و درک بهتر از طراحی سیستم‌ها

۳. سطح Senior Software Engineer 🔥 (مهندس نرم‌افزار ارشد)

📌 ویژگی‌ها: ۵ تا ۸ سال تجربه، مهارت در حل مشکلات پیچیده
🔹 مسئولیت‌ها:
✅ معماری و طراحی سیستم‌های قابل مقیاس
✅ هدایت کد ریویوها و منتورینگ اعضای تازه‌کار
✅ بهینه‌سازی عملکرد و افزایش کیفیت کد
🎯 شرایط ارتقا: توانایی تصمیم‌گیری‌های فنی مهم، رهبری پروژه‌های بزرگ‌تر

۴. سطح Lead Engineer / Tech Lead 🚀 (رهبر فنی تیم)

📌 ویژگی‌ها: ۷ تا ۱۰ سال تجربه، تخصص در طراحی و راهبری سیستم‌های پیچیده
🔹 مسئولیت‌ها:
✅ راهبری تیم‌های توسعه از نظر فنی
✅ تصمیم‌گیری در انتخاب تکنولوژی‌ها و معماری‌های نرم‌افزار
✅ تعامل با مدیران محصول و تضمین اجرای درست پروژه‌ها
🎯 شرایط ارتقا: تجربه کافی در مدیریت تیم‌های مهندسی، درک استراتژی فنی

۵. سطح Software Architect 🏛 (معمار نرم‌افزار)

📌 ویژگی‌ها: ۱۰+ سال تجربه، توانایی طراحی سیستم‌های بزرگ و توزیع‌شده
🔹 مسئولیت‌ها:
✅ طراحی معماری نرم‌افزار و مستندسازی راهکارهای فنی
✅ مشاوره به تیم‌های مهندسی برای اتخاذ بهترین شیوه‌ها
✅ حل چالش‌های مقیاس‌پذیری و بهینه‌سازی سیستم‌ها
🎯 شرایط ارتقا: داشتن دیدگاه کلان و استراتژیک به سیستم‌های نرم‌افزاری

۶. سطح Engineering Manager 🎯 (مدیر مهندسی)

📌 ویژگی‌ها: مهارت در هم مدیریت افراد، هم درک فنی سیستم‌ها
🔹 مسئولیت‌ها:
✅ مدیریت و هدایت تیم‌های توسعه و تخصیص منابع
✅ تسهیل همکاری بین تیم‌های مختلف (مثلاً محصول، DevOps، QA)
✅ اجرای فرآیندهای رشد و ارتقای مهندسان نرم‌افزار
🎯 شرایط ارتقا: اثبات توانایی در هدایت چند تیم و موفقیت در اجراهای استراتژیک

۷. سطح CTO (Chief Technology Officer) 🏆 (مدیر ارشد فناوری)

📌 ویژگی‌ها: بالاترین سطح فنی، توانایی هدایت کل دپارتمان مهندسی
🔹 مسئولیت‌ها:
✅ تعیین مسیر فنی و تکنولوژیک شرکت
✅ تصمیم‌گیری در مورد فناوری‌های آینده و رشد تیم مهندسی
✅ ارتباط با سایر مدیران اجرایی و سرمایه‌گذاران برای هم‌راستا کردن استراتژی فنی با کسب‌وکار
🎯 شرایط ارتقا: تجربه گسترده در رهبری فناوری و ایجاد محصولات موفق

✨ چند نکته خیلی مهم برای اجرای این مدل در شرکت‌های کوچک و متوسط:
🔹 انعطاف‌پذیری حفظ بشه! یه استارتاپ ۱۰ نفره قطعاً نیازی به CTO یا چندین سطح از روز اول نداره، ولی وقتی رشد کنه، نیازش ایجاد می‌شه.
🔹 جایگاه‌های میانی حذف نشن! بین یه Junior و یه Senior باید مسیر رشد منطقی باشه، وگرنه انگیزه تیم کم می‌شه.
🔹 فرهنگ یادگیری و رشد ایجاد بشه! مسیر پیشرفت افراد نباید صرفاً روی «سال‌های تجربه» باشه، بلکه توانایی و خروجی مهم‌تره.
🔹 وقتی برخی پوزیشن‌ها رو به هر دلیلی ندارید، هیچ اشکالی نداره از مشاور «شایسته» استفاده کنید، خیلی بهتر از اینه که چون کسی رو ندارید بهش برچسب سنیور یا معمار یا کوفت بچسبونیم.
🔹 پوزیشن‌های لیدرشیپ، فقط مهارت فنی نیاز ندارن، باید بتونه تعامل سازنده و مناسب با سایرین داشته باشن و کمک به رشد بقیه کنن

💎 برای بار شونصدم: سیبی که زود چیده بشه تا ابد کال و غیرقابل استفاده می‌مونه! عین آدمی که زودتر از موعد جایگاه بالاتر بگیره.

😊 پایان این بحث
خوشحال می‌شم فیدبک بدید 🌱

🧪مقایسه دو مکتب معروف Unit Testing یعنی کلاسیک (Detroit) و لندن (Mockist)

1️⃣ تست «پیاده‌سازی» در مقابل تست «قرارداد»

🎩 کلاسیک: تست «فقط خروجی و رفتار نهایی» رو مورد ارزیابی قرار می‌ده؛ نیازی به دونستن جزئیات داخلی نیست. مثلاً اگر کد توابع کمکی رو تغییر بدیم ولی نتیجه نهایی تغییر نکنه، تست‌ها تغییر نخواهند کرد و فقط اگه Assertمون پاس شه، تست پاس شده.

🎡 لندن: تست‌ها بر اساس نحوه‌ی فراخوانی وابستگی‌ها و جزئیات پیاده‌سازی دقیق نوشته می‌شن. این یعنی تغییرات جزئی در داخل کلاس (حتی بدون تغییر در خروجی نهایی) ممکنه باعث شکست تست‌ها بشه؛ حتی اگه مثلا مقدار برگشتی یک متد دقیقا همونی باشه که قبلا بوده.

2️⃣مکان‌یابی باگ

🎩 کلاسیک: ممکنه چند تست باهم شکست بخورن چون وابستگی‌ها واقعی هستند. در نتیجه پیدا کردن مشکل ممکنه کمی زمان بیشتری ببره.

🎡 لندن: چون تست‌ها به صورت دقیق تعاملات کلاس‌ها رو چک می‌کنن، در صورت خطا معمولا به سرعت متوجه می‌شیم که مشکل کجاست.

3️⃣ مدیریت وابستگی‌های پیچیده

🎩 کلاسیک: برای تست‌های واقعی باید تمامی وابستگی‌ها پیاده‌سازی بشن که اگر تعدادشون زیاد باشه کار زمان‌بر میشه؛ ولی از طرفی این موضوع می‌تونه نشونه‌ای از طراحی پیچیده یا ناسالم سیستم باشه.

🎡 لندن: با استفاده از Mock‌ها می‌شه وابستگی‌های «سطح اول» رو شبیه‌سازی کرد بدون اینکه لازم باشه کل گراف وابستگی‌ها رو راه‌اندازی کنیم.


🤔 اگر کنجکاوی که با کد هم تفاوتش رو ببینی: ری‌اکشن ⚙️

به احترام ⚙️ گذارهای عزیز 😁 کد مثال با 📱 و 📱 رو در کامنت مطلب قرار دادم.

💬 کامنت نظر و تجربه داری بیا بحث کنیم 😉