https://virgool.ir/feed/@bahar.behniafa2026-11-10 15:10:25https://files.virgool.ir/upload/users/4510800/avatar/tCtTjh.jpghttps://virgool.ir/@bahar.behniahttps://virgool.ir/@bahar.behnia/از-قهرمان-محوری-تا-تیم-های-مستقل-چطور-مدل-مهندسی-اسنپ-پی-را-بازطراحی-کردیم-enj8b6kd70wcرشد یک سازمان مهندسی فقط به معنای افزایش تعداد افراد، تیم‌ها و پروژه‌ها نیست. با بزرگ‌تر شدن سازمان، پیچیدگی تصمیم‌گیری، هماهنگی بین تیم‌ها و مدیریت وابستگی‌ها هم افزایش پیدا می‌کند. ساختارها و روش‌هایی که در مقیاس کوچک‌تر به‌خوبی کار می‌کردند، ممکن است در مقیاس بزرگ‌تر دیگر همان کارایی را نداشته باشند.یکی از چالش‌های مهم در این مسیر این است که رشد سازمان لزوماً به معنای مقیاس‌پذیرتر شدن آن نیست. گاهی تعداد تیم‌ها بیشتر می‌شود، اما دانش، اختیار و تصمیم‌گیری همچنان در چند نقطه متمرکز باقی می‌ماند. در چنین شرایطی، سازمان به‌جای اینکه با اضافه شدن افراد توانمندتر شود، با وابستگی‌های بیشتر و گلوگاه‌های جدید روبه‌رو می‌شود.اسنپ‌پی هم در چند سال گذشته رشد قابل‌توجهی داشته است. با بزرگ‌تر شدن شرکت و گسترش تیم‌های مهندسی، ما هم با بخشی از همین چالش‌ها مواجه شدیم.ساختاری که در مقیاس کوچک‌تر به‌خوبی جواب می‌داد، با رهبری مبتنی بر تخصص‌های جداگانه، لایه‌های متعدد هماهنگی و تصمیم‌گیری‌هایی که حول چند فرد کلیدی متمرکز بود، دیگر به‌راحتی قابل گسترش نبود.به‌تدریج برایمان روشن شد که اگر می‌خواهیم سازمان مهندسی هم‌زمان با رشد کسب‌وکار مقیاس‌پذیر شود، صرفاً اضافه کردن افراد یا تیم‌های جدید کافی نیست. مدل عملیاتی مهندسی ما (Engineering Operating Model) هم باید تکامل پیدا می‌کرد.برای همین، از خودمان یک سؤال ساده اما اساسی پرسیدیم:چطور می‌توانیم سازمان مهندسی‌ای بسازیم که به سیستم‌های قدرتمند متکی باشد، نه به چند فرد قهرمان؟سازمانی که در آن مسئولیت‌پذیری، دانش و تصمیم‌گیری بین تیم‌های توانمند توزیع شده باشد و رشد سازمان، وابستگی به چند فرد کلیدی را بیشتر نکند.همین سؤال مسیر بازطراحی مدل عملیاتی مهندسی در اسنپ‌پی را شکل داد و مبنای تدوین SnappPay Engineering Charter شد.این Charter اصول عملیاتی، مسئولیت‌های رهبری و استانداردهای اجرای کار در مهندسی اسنپ‌پی را مشخص می‌کند و چارچوب مشترکی برای فعالیت Podها، Squadها و تیم‌های چندتخصصی در سه حوزه‌ی اصلی Architecture، Delivery و Reliability فراهم می‌کند.اما هدف ما صرفاً تدوین یک سند یا تغییر ساختار سازمانی نبود. می‌خواستیم این اصول در تصمیم‌های روزمره‌ی تیم‌ها، نحوه‌ی همکاری، مسئولیت‌پذیری و کیفیت تحویل کارها دیده شوند.در ادامه، هفت اصلی را مرور می‌کنم که مدل جدید مهندسی اسنپ‌پی را بر اساس آن‌ها شکل دادیم؛ اصولی که همچنان در حال یادگیری و تکامل آن‌ها هستیم.۱. سیستم بسازیم، نه قهرماناگر حرکت یک تیم به چند فرد کلیدی وابسته باشد، با بزرگ‌تر شدن سازمان این وابستگی هم بیشتر می‌شود.برای همین، یکی از مهم‌ترین تغییرات ما این بود که به‌جای متمرکز کردن رهبری و مسئولیت‌پذیری، آن‌ها را بین تیم‌ها توزیع کنیم.ما لایه‌ی Chapter Lead را حذف کردیم و رهبری را به تیم‌ها نزدیک‌تر کردیم. هر تیم توسط یک Engineering Manager و یک Tech Lead هدایت می‌شود و Technical Delivery Management نیز از هماهنگی بین تیم‌ها و قابل‌پیش‌بینی بودن تحویل پشتیبانی می‌کند.‎Engineering Manager (EM)‎ : مسئول رشد افراد، سلامت تیم، اجرای کارها و تحویل، برنامه‌ریزی ظرفیت تیم و برطرف کردن موانع سازمانی است.‎Tech Lead (TL)‎ : مسئول جهت‌گیری فنی، معماری سیستم، نیازمندی‌های غیرعملکردی و ارتقای کیفیت مهندسی است.‎Technical Delivery Manager (TDM)‎ : مسئول هماهنگی بین تیم‌ها، پیگیری وابستگی‌های بین Podها، کاهش ریسک‌ها و قابل‌پیش‌بینی بودن تحویل نقاط عطف پروژه‌ها است.ما آگاهانه این مسئولیت‌ها را تفکیک کردیم تا مدیریت افراد، هدایت فنی، اجرای کار و هماهنگی تحویل، هرکدام مالک مشخص و تمرکز لازم را داشته باشند؛ بدون اینکه مسئولیت بیش‌ازحد روی دوش یک نفر قرار بگیرد.هدف این است که تیم‌ها شناخت، اختیار، مسئولیت‌پذیری و رهبری لازم را برای پیش بردن کارهایشان داشته باشند، بدون اینکه به چند فرد کلیدی وابسته باشند.افراد توانمند باید سیستم را قوی‌تر کنند، نه اینکه خودشان به سیستم تبدیل شوند.۲. تصمیم را به شناخت مسئله نزدیک کنیمبه‌جای اینکه با رشد سازمان لایه‌های مدیریتی بیشتری اضافه کنیم، آن‌ها را کمتر کردیم.Triad Partnership: تیم‌های Engineering، Product و Business از همان ابتدای تعریف مسئله، در کنار هم و به‌صورت یکپارچه همکاری می‌کنند. به این ترتیب، نیازهای Business، اولویت‌های Product، محدودیت‌های فنی و Trade-offهای تصمیم‌گیری از همان ابتدا با مشارکت هر سه حوزه بررسی می‌شوند.Documentation Precedes Implementation: تصمیم‌های مهم معماری، تغییرات ساختار پایگاه داده و قابلیت‌های با تأثیر بالا، پیش از شروع پیاده‌سازی در قالب ‎RFC (Request for Comments)‎ مستند می‌شوند.Async-First Consensus: تیم‌ها تا حد امکان بررسی، ارائه‌ی نظر و بحث درباره‌ی راهکارها را به‌صورت غیرهم‌زمان (Async) و از طریق مستندات انجام می‌دهند. جلسه‌ها برای نهایی کردن اختلاف‌نظرها و تصمیم‌هایی برگزار می‌شوند که نمی‌توان آن‌ها را به‌صورت غیرهم‌زمان به نتیجه رساند.مهندسان فقط دریافت‌کننده‌ی نیازمندی‌ها نیستند. آن‌ها دلیل پشت نیازمندی‌ها را درک می‌کنند، فرضیات را به چالش می‌کشند و در شکل دادن به راهکار نقش دارند.تصمیم‌های بهتر جایی گرفته می‌شوند که شناخت عمیق‌تری از مسئله وجود دارد؛ و مستندسازی کمک می‌کند این دانش بین افراد به اشتراک گذاشته شود.۳. مسئول نتیجه باشیم، نه فقط انجام کارما در حال فاصله گرفتن از مرزبندی‌های سخت‌گیرانه‌ی Backend، Frontend و QA هستیم.تخصص مهم است، اما نباید مرز مسئولیت‌پذیری افراد را تعیین کند.می‌خواهیم افراد، فارغ از تخصصشان، خود را Software Engineerهایی در نقش IC بدانند که مسئول نتیجه‌ی نهایی کارند، نه صرفاً بخشی از کار که با تخصصشان مطابقت دارد..Product-Minded Problem Solvers: مهندسان نسبت به تجربه‌ی End-to-End کاربر و صحت عملیات مالی مسئولیت‌پذیرند، نه فقط نسبت به بخش‌هایی از سیستم که خودشان توسعه داده‌اند. آن‌ها مسئله را درک می‌کنند، فرضیات را به چالش می‌کشند، در طراحی راهکار مشارکت دارند و برایشان مهم است که خروجی واقعاً به نتیجه‌ی موردنظر برسد.این یعنی همکاری بین تخصص‌های مختلف، کمک کردن به یکدیگر فراتر از مسئولیت‌های فردی و سنجیدن موفقیت بر اساس نتیجه‌ای که با هم به دست می‌آوریم، نه صرفاً کارهایی که انجام داده‌ایم.کیفیت یک مرحله نیست، ذات مهندسی است.ما نقش مجزایی به نام QA نداریم؛ نقش همه ما Software Engineer با مالکیت تمام‌عیار بر محصول است. فرستادن کد ناپخته به امید اینکه شخص دیگری باگ‌های آن را پیدا کند، ضدِ استاندارد مهندسی در اسنپ‌پی است.مهندسی که یک قابلیت را طراحی و پیاده‌سازی می‌کند، مسئول طراحی تست‌ها، پایداری و صحت عملکرد آن نیز هست. هیچ قابلیتی «کامل» تلقی نمی‌شود مگر اینکه تست‌های خودکار لازم برای آن نوشته شده باشند، یکپارچگی و عملکرد صحیح آن در سیستم تأیید شده باشد، در محیط عملیاتی مستقر شده باشد و وضعیت سلامت و عملکرد آن از طریق داشبوردها و هشدارهای مناسب قابل پایش باشد. اگر تستش نکرده‌ای و در پروداکشن مانیتورش نمی‌کنی، هنوز ساخته نشده است.وقتی هرکس فقط مسئول بخش خودش باشد، در نهایت هیچ‌کس مسئول کل خروجی نیست.۴. تمرکز را حفظ کنیم، نه برنامه را به هر قیمتهر تیم فصل را با یک مسیر مشخص شروع می‌کند؛ OKRهای مشترک، اولویت‌های روشن و نقشه راهی که همه را روی موضوعات مهم هم‌راستا نگه می‌دارد.این مسیر مشخص، از تیم‌ها در برابر تغییر مداوم اولویت‌ها محافظت می‌کند. اما به این معنا نیست که نسبت به اتفاقات اطرافمان بی‌توجه باشیم.در طول فصل، تیم‌های Engineering، Product و Business به‌طور منظم کنار هم قرار می‌گیرند تا پیشرفت کارها، ریسک‌ها، وابستگی‌ها و تغییرات شرایط کسب‌وکار را بررسی کنند.در بیشتر مواقع، نقشه راه از تمرکز ما محافظت می‌کند. اما وقتی تغییر مهمی اتفاق می‌افتد، اولویت‌ها را بر اساس اصل Zero-Sum Scope Adjustments بازبینی می‌کنیم؛ یعنی هر تغییر استراتژیک در میانه‌ی مسیر باید با یک تصمیم آگاهانه درباره‌ی اولویت‌ها همراه باشد. اگر یک موضوع مهم جدید وارد محدوده‌ی کار شود، باید یک اقدام هم‌ارزش دیگر به‌صورت رسمی از اولویت خارج شود.در سطح اجرا، از رویکرد Continuous Flow استفاده می‌کنیم؛ یعنی کارها را بر اساس نقاط عطف قابل‌تحویل سازمان‌دهی می‌کنیم، نه بازه‌های زمانی ثابت و دلخواهِ دو هفته‌ای.حفظ این جریان مستمر، به ثبات نسبی ترکیب تیم‌ها هم نیاز دارد.ما از تمرکز تیم محافظت می‌کنیم، اما قرار نیست برنامه را در برابر واقعیت غیرقابل‌تغییر نگه داریم.۵. بسازیم و مسئولش بمانیمبرای ما مسئولیت‌پذیری پیش از نوشته شدن اولین خط کد آغاز می‌شود و تا مدت‌ها پس از استقرار در محیط عملیاتی ادامه دارد.Full-Lifecycle Engineering: مهندسان در بررسی و اعتبارسنجی فرضیات PRD، طراحی راهکار و Test Strategy، پیاده‌سازی و تست، انجام Deployment و پایش وضعیت سرویس پس از Release مشارکت فعال دارند.با عبور کار از مراحل مختلف، مسئولیت آن به فرد یا تیم دیگری منتقل نمی‌شود. تیم از ابتدا تا انتها، قبل از توسعه، حین آن و بعد از تحویل، نسبت به نتیجه‌ی نهایی پاسخ‌گو باقی می‌ماند.Telemetry as a First-Class Citizen: کد بدون لاگ‌های ساختاریافته ‎(Structured Logging)‎، بررسی سلامت سرویس ‎(Health Checks)‎، رهگیری توزیع‌شده ‎(Distributed Tracing)‎، هشدارهای قابل‌اقدام ‎(Actionable Alerts)‎ و داشبوردهای لازم، آماده‌ی استقرار در Production نیست. Observability بخشی از کیفیت مهندسی است، نه موضوعی که بعداً به آن فکر کنیم.Production Ownership: مهندسانی که یک سرویس را طراحی و منتشر می‌کنند، همچنان مسئول دسترس‌پذیری ‎(Uptime)‎، بودجه‌ی خطا ‎(Error Budget)‎ و پایداری عملیاتی آن هستند. آن‌ها وضعیت Production را پایش می‌کنند، مشکلات را بررسی می‌کنند و در برنامه‌های نوبتی On-call برای کمک به رفع رخدادها در صورت نیاز مشارکت دارند.تیم SRE رسیدگی به رخدادهای عملیاتی در حوزه‌ی مسئولیت خود را بر عهده دارد و در مواردی که مشکل مربوط به خود سرویس باشد و به بررسی یا اقدام بیشتری نیاز داشته باشد، موضوع را به تیم مالک سرویس ارجاع می‌دهد.Reliability Standards: تیم‌ها به‌صورت فعال صدک‌های Latency مانند p95 و p99 را پایش می‌کنند و بدهی فنی، عملکرد و پایداری سیستم را به‌اندازه‌ی قابلیت‌های محصول جدی می‌گیرند.تو فقط مسئول ساختن بخش خودت نیستی؛ مسئول نتیجه‌ای هم هستی که از آن به وجود می‌آید.۶. ریسک‌ها را زود بگوییم، غافلگیر نشویممشکل پیش می‌آید؛ اما نباید غافلگیر شویم.به‌محض شناسایی یک ریسک مهم، تأخیر احتمالی، وابستگی حیاتی یا مشکل معماری که می‌تواند مانع پیشرفت کار شود، موضوع را مطرح می‌کنیم.Early Escalation Protocol: شناسایی و مطرح کردن زودهنگام وابستگی‌های حیاتی، انحراف از زمان‌بندی یا ریسک‌های معماری، نشانه‌ی رهبری مهندسی قوی است. مطرح کردن یک مشکل شکست نیست؛ سکوت کردن درباره‌ی آن می‌تواند برای سازمان هزینه‌ساز باشد.بعد از آن، مسیر ساده است:Communicate → Mitigate → Learn → Automateزود اطلاع‌رسانی می‌کنیم، سریع برای کاهش اثر مشکل اقدام می‌کنیم، بررسی می‌کنیم چه اتفاقی افتاده و آموخته‌هایمان را به بهبودهای ماندگار و تا حد امکان خودکار تبدیل می‌کنیم.Blameless Postmortems: قطعی‌ها و رخدادهای مهم باید ظرف ۴۸ تا ۷۲ ساعت در قالب بررسی پس از رخداد، بدون سرزنش افراد، تحلیل شوند. تمرکز این بررسی‌ها بر شناسایی ضعف‌ها و الگوهای شکست سیستمی است.اقدامات پیشگیرانه بر اساس میزان ریسک و تأثیرشان اولویت‌بندی می‌شوند و اقدامات مورد توافق، در صورت امکان، برای نقطه عطف بعدی برنامه‌ریزی می‌شوند.هدف پیدا کردن فرد مقصر نیست؛ هدف مقاوم‌تر کردن سیستم است.غافلگیر نشدن یعنی اطلاعات و درک مشترک را آن‌قدر زود ایجاد کنیم که هنوز فرصت اقدام داشته باشیم.۷. فرایند را در خدمت تحویل قرار دهیمما مراسم و روال‌های سنتی Scrum را کنار گذاشته‌ایم و به‌جای آن، از یک مدل سبک‌تر و مبتنی بر تحویل مستمر از طریق Execution Podها و با هماهنگی TDM استفاده می‌کنیم.نه به این دلیل که Scrum بد است؛ Scrum در مرحله‌ای از رشد سازمان به ما کمک کرد.اما دیگر نمی‌خواهیم صرفاً چون یک چارچوب کاری برگزاری جلسات و مراسم مشخصی را توصیه می‌کند، آن‌ها را برگزار کنیم.Execution Podهای ما Engineering و Product را کنار هم قرار می‌دهند تا درباره‌ی اجرا هم‌راستا شوند، موانع را برطرف کنند و تحویل کارها را پیش ببرند. TDMها نیز از هماهنگی بین تیم‌ها، مدیریت وابستگی‌ها، کاهش ریسک و قابل‌پیش‌بینی بودن تحویل نقاط عطف پشتیبانی می‌کنند.ما از اصول Async-First پیروی می‌کنیم و مستندسازی و همکاری غیرهم‌زمان را روش پیش‌فرض قرار می‌دهیم. جلسه‌ها را برای گفت‌وگوها و تصمیم‌هایی نگه می‌داریم که واقعاً به جلسه نیاز دارند.به‌جای سنجش موفقیت بر اساس پایبندی به جلسات و روال‌های ثابت یا بازه‌های زمانی دلخواه، روی نتایج قابل‌اندازه‌گیری تحویل تمرکز می‌کنیم؛ از جمله Lead Time، Deployment Frequency، Change Failure Rate و Milestone Predictability.هدف این است که سرعت، کیفیت و قابلیت پیش‌بینی تحویل را به‌صورت مستمر بهبود دهیم.هدف این نیست که فرایندها را بهتر اجرا کنیم؛ هدف این است که بهتر تحویل بدهیم.مسیری که هنوز ادامه داردما این تحول را در حالی پیش بردیم که تحویل کارها متوقف نشد؛ نقش‌ها را تغییر دادیم، ساختار تیم‌ها را بازطراحی کردیم، شیوه‌ی تصمیم‌گیری را تغییر دادیم و ذهنیت‌هایی را به چالش کشیدیم که طی سال‌ها شکل گرفته بودند.و تأثیر آن را دیده‌ایم: تمرکز بیشتر، سرعت و کیفیت بهتر در تحویل، روحیه‌ی بهتر تیم‌ها و وابستگی بسیار کمتر به افراد.اما کامل شدن این تحول به معنای ثابت ماندن مدل نیست.ما معتقد نیستیم که یک مدل عملیاتی باید برای همیشه ثابت و تغییرناپذیر بماند.همچنان به تیم‌هایمان گوش می‌دهیم، از چیزهایی که خوب پیش می‌روند و چیزهایی که جواب نمی‌دهند یاد می‌گیریم و هم‌زمان با رشد سازمان، سیستم را بهبود می‌دهیم.چون ساختن یک سازمان مهندسی مقیاس‌پذیر فقط به معنای طراحی ساختار درست برای امروز نیست؛ بلکه به معنای ساختن سیستمی است که بتواند فردا هم تکامل پیدا کند.ما سیستم‌هایی می‌سازیم که ماندگارند، تیم‌هایی که با استقلال و اختیار تصمیم می‌گیرند و نرم‌افزاری که برای مقیاس‌پذیری مهندسی شده است.bahar behniabahar behniaSat, 17 Oct 2026 17:36:37 +0330