📇 سلسلهمراتب مهندسی نرمافزار و ساختار سازمانی (بخش اول)
📇 سلسلهمراتب مهندسی نرمافزار و ساختار سازمانی (بخش اول)
سلسلهمراتب مهندسی نرمافزار موضوع مهمیه، هم برای سازمان که بخواد با ساختار مناسب به اهداف و برنامههاش برسه و بهرهوریاش رو بهبود بده؛ هم افراد انگیزه برای رشد و یادگیری و رقابت داشته باشن. پس داشتن یه ساختار سازمانی درست + ساز و کار ارزیابی و رشد سرمایهانسانی، نه تنها حیاتیه، بلکه یه چالش بُرد-بُرد برای سازمان و افراده.
قبل از توضیح در مورد انواع سلسلهمراتب مهندسی نرمافزار، باید بدونیم » چجوری ساختار سازمانی مناسب رو انتخاب کنیم؟
آیا هر چی گوگل، اپل، متا یا... داره رو کپی کنیم؟ یا هر کاری هزاردستان و اسنپ و دیجیکالا کردن رو کپی کنیم؟ (حتی لحن سوالم نشون میده فقط یکی از انواع مدیران جواگره چنین کاری رو میکنه 😁)
موارد زیر تنها تعدادی از مولفههای مورد بررسی برای طراحی ساختار سازمانی مهندسی نرمافزاره، برای هر کدوم دو مورد مثال ذکر میکنم.
توجه داشته باشید که هم مولفههای بیشتری دخیله، هم مثالهای متنوعتری میشه از انواع هر مولفه زد که از حوصله پست تلگرامی خارجه.
۱. اندازه شرکت
*️⃣استارتاپها: ساختار مسطح (Flat) با نقشهای چندوجهی.
*️⃣شرکتهای بزرگ: سلسلهمراتب واضح با تخصصیسازی نقشها.
۲. پیچیدگی محصول
*️⃣سیستمهای پیچیده: نیاز به نقشهای تخصصی (مثل مهندس بهینهسازی یا مهندس MLOps یا...).
*️⃣محصولات ساده: ساختار عمومیتر.
۳. فرهنگ سازمانی
*️⃣ساختار مبتنی بر نوآوری با آزادی عمل بالا برای مهندسان.
*️⃣ساختار متمرکز بر مشتری با تیمهای مستقل (Squads).
۴. اهداف رشد
*️⃣اگر هدف توسعه سریعه: ساختار Agile با تیمهای Scrum/کانبان.
*️⃣اگر هدف پایداریه: ساختار سلسلهمراتبی با فرآیندهای دقیق (CMMI).
❓حالا چجوری نیازهای سازمان رو تشخیص بدیم؟
۱. نیازسنجی (Gap Analysis):
*️⃣چه مهارتهایی در تیم موجود نیست؟
*️⃣آیا ارتباط بین تیمها کُنده؟
*️⃣آسیبشناسی محصول و تیم چی بهمون میگه؟
۲. مقایسه با شرکتهای مشابه (Benchmarking):
*️⃣بررسی ساختار شرکتهایی با اندازه و حوزه فعالیت مشابه که «شرایط، بضاعت و استعداد مشابه دارن». طبیعتا اگر شرکتمون ۲۰۰ نفره و سیستم اداری تولید میکنه، اینکه بگردیم یه شرکت ۲۰۰ نفره نوآور در آمریکا یا ژاپن رو الگو کنیم منطقی نیست (گرچه خیلیها این کار رو میکنن و بعد میبینیم staff engineer شون رفته مرخصی تا امتحان مدار منطقیاش رو نیوفته 😁)
۳. تعریف نقشه راه (Roadmap):
*️⃣باید نقشهراه کوتاهمدت، میانمدت و چشمانداز بلندمدت خوبی از کسبوکار و محصول داشته باشیم. یا اینکه هر وقت تغییر کردن بشینیم و ساختار سلسلهمراتب و سازمانمون رو مرور کنیم ببینیم هنوز متناسبه؟! مثلا اگر هدف تبدیل شدن به یک شرکت مبتنی بر داده است، نقشهایی شاید اضافه کنیم، یا اگر قراره شرکت رشد بزرگی کنه، سلسهمراتبمون تغییر میکنه و نقشهای جدیدی اضافه میشن. نقشه راه باید منطبق با واقعیتها باشه، منطقی و قابل حصول باشه (به بیان ساده به قد و قوارهمون بیاد و با توان و شرایط جور باشه)
۴. انعطافپذیری:
*️⃣ساختار باید قابلیت تطابق با تغییرات بازار یا فناوری رو در خودش پیادهسازی کنه. آیه نازل نشده شرکت از روز اول ساختار ابدی و ثابت داشته باشه، ساختار باید در خدمت اهداف و بضاعت و استعداد مجموعه باشه. حالا شما برای تیم ۳ نفره CTO نداشته باشی هم میشه، ایشالا شدی ۱۰ تا تیم اونوقت CTO بگیر.
این بخش اول بود، لازم بود توضیح بدم که نقشها و انواع سلسه مراتبی که در قسمت بعدی معرفی خواهم کرد، فقط نمونههاییه که سازمانهای مختلف بر اساس نیاز و شرایطشون ایجاد کردن. مثلا Distinguished Engineer یا Developer Advocate نقشهایی است که برخی سازمانها بنا به ضرورت، اهداف و نیازشون ایجاد کردن و دارن، دلیل نمیشه همه داشته باشن.
از اون طرف اگر ما نقشها و مسئولیتها رو درست نشناسیم در انتخاب مسیر شغلی شاید انتخابهای غیر بهینهای کنیم. پس افراد باید بدونن مسیر رشدهای مختلف چیه تا هم نقشه رشدشون رو ترسیم کنن هم سازمان متناسب رو برای کار کردن انتخاب کنن. از طرفی سازمانها هم باید تکلیفشون مشخص باشه تا بتونن چرخه تربیت و رشد سرمایهانسانی رو ترسیم و اجرا کنن. شما برای تربیت نیروی انسانی باید افرادی رو داشته باشی که «بلد باشن و شایستگی» هدایت نیروی انسانی رو داشته باشن. نه اینکه هر وقت مدیر رفت نفر بعدی رو مدیر کنی! یا هر کی شوآف بیشتری داشت ارتقاء بدی!
🌱 لطفا دقت شود: «هدایت» با «راهنمایی» بسیار فرق داره! هدایت یعنی من دست شما رو بگیرم ببرمتون به مقصد مشخص برسونم. ولی راهنمایی یعنی بهتون آدرس رو بگم. لیدرشیپ نوعی از هدایت است، وگرنه راهنمایی توی اینترنت زیاده!
دوست دارید ادامه بدم و قسمت دوم و بعدترش رو داشته باشیم؟
💬 نظر؟ تجربه؟ سوال؟