https://virgool.ir/feed/@masoudsharifimasoudsharifipour.irfa2026-11-11 19:11:01https://files.virgool.ir/upload/users/195953/avatar/2FzYuT.pnghttps://virgool.ir/@masoudsharifihttps://virgool.ir/@masoudsharifi/چطور-وابستگی-تیم-به-خودم-رو-کم-کردم-m055i3upxzcjوقتی برای اولین بار مسئولیت Engineering Manager یک Tribe با چندین تیم و بیزینس رو بر عهده گرفتم، شروع کردم به بررسی موضوعاتی که روی Delivery، Impact و Outcome تیم‌ها تأثیر می‌ذاشتن.حالا نه اینکه در زمان ورود سریع افتادم دنبال این چیزا، داستان های اولیه رو اینطور پیش بردم که مسیرو بشناسم، بیزینس بشناسم،جلسات متعددی با استیک هولدر گذاشتم که اولویت هاشو ببینم استراتژی و رودمپ ریوایز کردم ولاسیتی تیم نسبت به خروجی های گذشته بررسی کردم. من از بعد از این داستان ها برای شما شروع کردم مقاله رو نوشتن :D .یکی از چیزهایی که توجهم رو جلب کرد، این بود که با وجود تلاش افراد و انجام شدن تسک‌ها، خروجی تیم همیشه به اندازه‌ای که انتظار می رفت، به نتیجه و ارزش ملموس برای بیزینس تبدیل نمی‌شد.شروع کردم به بررسی فرایندها، نحوه تصمیم‌گیری‌ها و تعامل بین تیم‌ها. کم‌کم متوجه شدم بخش قابل‌توجهی از کارها برای پیش رفتن، به تصمیم یا تأیید مدیر تیم وابسته است؛ از تصمیم‌های فنی مثل انتخاب یک Package تا هماهنگی با تیم‌های دیگه، مدیریت وابستگی‌ها و حتی صحبت کردن با بعضی از افراد.اما چیزی که بیشتر از خود این وابستگی ذهنم رو درگیر کرد، رفتار افراد نسبت به نتیجه کارشون بود.چرا بعضی از افراد بعد از Done شدن تسک، مسئولیت خودشون رو تمام‌شده می‌دونستن؟ چرا برای پیگیری نتیجه، هماهنگی با تیم‌های وابسته یا پیش بردن یک تصمیم، همچنان باید مدیر وارد ماجرا می‌شد؟ و چرا با وجود اینکه افراد کارشون رو انجام می‌دادن، احساس مسئولیت نسبت به خروجی نهایی و ارزشی که ایجاد می‌کرد، همیشه به همون اندازه نبود؟به این نتیجه رسیدم که مسئله فقط فرایندهای کند یا تعداد زیاد تأییدها نیست. بخشی از مشکل به مدلی برمی‌گرده که در اون، مدیر به نقطه عبور تصمیم‌ها تبدیل شده و افراد فرصت یا اختیار کافی برای به عهده گرفتن کل ماجرا رو ندارن.برای من، سؤال اصلی این شد: چطور می‌تونم این وابستگی رو کم کنم، به شکلی که هم Delivery و نتیجه بهتری داشته باشیم، هم افراد رشد کنن و هم Ownership واقعی در تیم شکل بگیره؟این موضوع فقط سرعت انجام کارها رو پایین نمی‌آورد؛ به‌مرور باعث شده بود مدیر به یک Bottleneck تبدیل بشه و تیم برای پیش بردن کارها، بیشتر از چیزی که لازم بود به اون وابسته بمونه.البته مسیری که برای رسیدن به این هدف طی کردم، صرفاً واگذاری کارها نبود؛ چون Delegation اگر بدون مرزبندی و سازوکار مناسب انجام بشه، خودش می‌تونه به مسئله جدیدی تبدیل بشه.ی داستان بگم :Dروزهای اولی که به تیم اضافه شده بودم، توی یکی از جلسه‌های Review شرکت کردم. تیم به‌شدت تحت فشار Delivery بود و وقتی نوبت به دمو کردن فیچرها می‌رسید، معمولاً جواب این بود:«متأسفانه نرسیدیم.»Product سعی می‌کرد مسیر انجام کار رو بررسی کنه تا بفهمیم کجای کار مشکل داشته و چرا به نتیجه نرسیدیم. اما یکی از اعضای تیم در جواب گفت:«من که بک‌اندش رو رسونده بودم؛ مشکل یه جای دیگه‌ست.»این جمله برای من خیلی عجیب بود. نه به این خاطر که لزوماً اون فرد مسئول نرسیدن فیچر بود، بلکه چون به نظر می‌رسید از نگاهش، وقتی بخش خودش رو تحویل داده، دیگه مسئولیتی نسبت به نتیجه نهایی کار نداره.اون لحظه سؤالی توی ذهنم شکل گرفت: چطور ممکنه اعضای یک تیم برای انجام کارهاشون تلاش کنن، اما وقتی خروجی نهایی به نتیجه نمی‌رسه، هرکدوم فقط به بخشی که خودشون تحویل دادن نگاه کنن؟واقعاً روزهای سختی بود. باید می‌فهمیدم چه چیزی باعث شده بود چنین نگاهی شکل بگیره و چطور می‌شد تغییرش داد. چون مسئله برای من فقط نرسیدن یک فیچر نبود؛ مسئله این بود که چطور می‌تونیم از تیمی که هرکس مسئول بخش خودش رو می‌دونه، به تیمی برسیم که نسبت به نتیجه نهایی کار هم احساس مسئولیت می‌کنه.مسئله فقط سرعت Delivery نبودوقتی تصمیم‌ها و هماهنگی‌ها به یک نفر وابسته باشن، حتی اگر اون فرد سریع و توانمند باشه، ظرفیت پیشرفت تیم در نهایت به ظرفیت همون شخص محدود می‌شه.از طرف دیگه، وقتی بخش زیادی از مسئولیت‌های اجرایی در اختیار مدیر باشه، افراد فرصت کمتری پیدا می‌کنن که تصمیم بگیرن، با ریسک مواجه بشن و مسئولیت نتیجه تصمیم‌هاشون رو بپذیرن.من نمی‌خواستم صرفاً کسی باشم که کارها رو سریع‌تر تأیید می‌کنه یا مشکلات رو زودتر حل می‌کنه. می‌خواستم شرایطی ایجاد کنم که تیم بتونه بخش بیشتری از مسائل رو بدون نیاز به دخالت من پیش ببره.برای من، این تغییر از جایی شروع می‌شد که به‌جای تمرکز روی انجام دادن کارها، روی توانمند کردن آدم‌ها برای تصمیم‌گیری و مسئولیت‌پذیری تمرکز کنم.از واگذاری تسک تا Ownershipبه‌نظرم یکی از تفاوت‌های مهم بین انجام دادن یک تسک و داشتن Ownership، اینه که در حالت اول، ممکنه مسئولیت فرد با Done شدن تسک تموم بشه؛ اما در حالت دوم، فرد خودش رو نسبت به نتیجه کار مسئول می‌دونه.در تجربه‌ای که داشتم، برام عجیب بود که گاهی وقتی کاری Done می‌شد، فرد احساس مسئولیت چندانی نسبت به خروجی نهایی نداشت. انگار با تمام شدن پیاده‌سازی، کار هم تموم شده بود.درحالی‌که از نظر من، بخش مهمی از مسئولیت تازه از همین‌جا شروع می‌شه.آیا کار به Release رسیده؟ آیا تیم‌های وابسته در جریان بودن؟ آیا ریسک‌های تصمیم بررسی شده بودن؟ آیا Product از تغییرات و پیامدهاش اطلاع داشت؟ اصلاً خروجی‌ای که تولید کردیم، ارزشی برای مشتری ایجاد کرده؟می‌خواستم این نگاه به‌تدریج در تیم شکل بگیره؛ اینکه افراد فقط مجری تصمیم‌های گرفته‌شده نباشن، بلکه نسبت به کاری که انجام می‌دن و ارزشی که ایجاد می‌کنن، مطالبه‌گر باشن.برای رسیدن به این نقطه، لازم بود انتظارات و حدود مسئولیت‌ها شفاف بشن، به افراد فرصت تصمیم‌گیری داده بشه و وقتی اشتباهی اتفاق می‌افته، به‌جای اینکه اولین واکنش گرفتن اختیار از فرد باشه، از اون برای یادگیری استفاده کنیم.وقتی تیم خودش کار رو از ابتدا تا انتها پیش می‌برهبرای من، یکی از نشانه‌های این تغییر زمانی بود که فردی مسئله‌ای رو شناسایی می‌کرد، وابستگی‌های اون رو می‌فهمید و بدون اینکه منتظر من بمونه، با تیم‌های مرتبط وارد گفت‌وگو می‌شد.فقط مسئله رو مطرح نمی‌کرد؛ به تیم‌های وابسته کمک می‌کرد راه‌حل رو پیدا کنن، درباره نحوه اجرا مشورت می‌داد، با Product در مورد ریسک تصمیم صحبت می‌کرد و تلاش می‌کرد قبل از Release، افراد مرتبط رو از کاری که قراره انجام بشه مطلع کنه.در نهایت هم مسئولیت ماجرا رو از ابتدا تا انتها بر عهده می‌گرفت.نکته مهم این بود که قبلاً بخش زیادی از این کارها، به‌جز خود Implementation، بر عهده مدیر بود.برای من، این تغییر فقط به معنی کمتر شدن تعداد سؤال‌هایی نبود که از من پرسیده می‌شد. مهم‌تر از اون، این بود که فرد از مرحله فهم مسئله تا هماهنگی، تصمیم‌گیری، مدیریت ریسک و پیگیری نتیجه، خودش رو مسئول می‌دونست.اینجا بود که می‌شد تفاوت بین واگذاری یک تسک و ایجاد Ownership رو بهتر دید.اما آیا هرچقدر Delegation بیشتر باشه، بهتره؟نه لزوماً.به‌نظرم این یکی از ریسک‌های مهم این مسیره که کمتر بهش توجه می‌شه.وقتی تصمیم می‌گیریم وابستگی تیم به مدیر رو کم کنیم، ممکنه در نقطه مقابل، با مسئله دیگه‌ای مواجه بشیم: همه می‌خوان تصمیم‌گیرنده باشن، همه می‌خوان نظر خودشون رو اجرا کنن و در نهایت، تصمیم‌های متناقض و ناهماهنگی بین افراد و تیم‌ها بیشتر می‌شه.ممکنه تعداد اشتباه‌ها بالا بره، افراد به‌اندازه کافی به نظرات هم گوش ندن یا برای تصمیم‌هایی که نیاز به توافق جمعی دارن، هرکس مسیر خودش رو پیش بگیره.اینجا دیگه مسئله کمبود اختیار نیست؛ مسئله اینه که اختیارها و مرز تصمیم‌گیری به‌درستی تعریف نشدن.Delegation به این معنی نیست که مدیر از تمام تصمیم‌ها کنار بره یا هر فردی بدون توجه به اثر تصمیمش روی بقیه، هر کاری که می‌خواد انجام بده.بعضی تصمیم‌ها باید در سطح فرد گرفته بشن، بعضی‌ها نیاز به هماهنگی با تیم‌های وابسته دارن و بعضی تصمیم‌ها هم به هم‌راستایی بین چند تیم یا مشارکت مدیر نیاز دارن.مرز بین این‌ها همیشه ساده نیست و نمی‌شه با یک قانون ثابت برای همه موقعیت‌ها تعیینش کرد.به همین دلیل، این مسیر به توجه و بازبینی مداوم نیاز داره. باید هم‌زمان با افزایش اختیار افراد، مطمئن بشیم که انتظارات روشن هستن، افراد اثر تصمیم‌هاشون رو روی بقیه درک می‌کنن و سازوکار مناسبی برای تصمیم‌گیری‌های مشترک وجود داره.هدف این نیست که همه مستقل از هم کار کنن؛ هدف اینه که افراد مستقل‌تر تصمیم بگیرن و در عین حال، بتونن هماهنگ با هم کار کنن.نقش مدیر با رشد تیم تغییر می‌کنهبه‌نظرم وقتی از یک نقش اجرایی وارد Engineering Manager می‌شیم، یکی از تغییرات مهم اینه که باید یاد بگیریم همیشه خودمون مسئله رو حل نکنیم.گاهی کمک کردن به تیم، به معنی دادن جواب درست نیست؛ به معنی ایجاد شرایطیه که افراد بتونن مسئله رو بفهمن، گزینه‌ها رو بررسی کنن، تصمیم بگیرن و مسئولیت نتیجه رو بپذیرن.البته این به معنی حذف نقش مدیر نیست. مدیر همچنان مسئول شفاف کردن انتظارات، تعیین مرزهای تصمیم‌گیری، ایجاد هم‌راستایی و حمایت از تیم در موقعیت‌های دشواره.اما قرار نیست تمام تصمیم‌ها از اون عبور کنن.برای من، کاهش وابستگی تیم به خودم فقط راهی برای افزایش Delivery نبود. این تغییر کمک می‌کرد افراد فرصت بیشتری برای رشد داشته باشن، مسئولیت‌پذیرتر بشن و نسبت به نتیجه کارشون حساسیت بیشتری پیدا کنن.در نهایت، فکر می‌کنم یکی از نشانه‌های رشد یک مدیر اینه که تیمش برای پیش بردن کارها، کمتر به حضور مستقیم اون نیاز داشته باشه؛ نه به این دلیل که مدیر نقش کم‌اهمیت‌تری پیدا کرده، بلکه به این دلیل که توانایی بیشتری در تیم ایجاد کرده.قرار نیست همیشه خودمون موتور حرکت تیم باشیم. گاهی مهم‌ترین کاری که می‌تونیم انجام بدیم، ساختن تیمیه که بدون وابستگی به ما هم بتونه تصمیم بگیره، حرکت کنه و نتیجه بسازه.مسعود شریفی پورمسعود شریفی پورSun, 18 Oct 2026 09:02:50 +0330https://virgool.ir/@masoudsharifi/وقتی-تیم-engineering-خیلی-خوب-کار-می-کند-ولی-هیچ-اتفاق-مهمی-نمی-افتد-jecuujbq8q5wیه تیم Engineering رو تصور کنید که تقریباً همه‌چیزش خوبه.Sprintها به موقع تموم میشن.Featureها سر وقت Release میشن.Bugها کنترل شده‌ان.Velocity تیم خوبه.حتی اگر Jira رو هم باز کنید، احتمالاً نمودارها وضعیت قابل قبولی دارن.اگر Engineering Manager اون تیم باشید، احتمالاً در نگاه اول حس خوبی دارید.تیم داره کار می‌کنه.اما یک سؤال ساده وجود داره:این همه کاری که انجام شده، دقیقاً چه چیزی رو بهتر کرده؟ممکنه جواب این سؤال خیلی واضح نباشه.و اینجا دقیقاً جاییه که به نظرم تفاوت بین یک تیم Engineering که فقط خوب Delivery می‌کنه و تیمی که واقعاً Impact ایجاد می‌کنه، مشخص میشه.به نظرم خوب ساختن با چیز درست ساختن فرق داردیکی از دام‌هایی که به نظرم تیم‌های Engineering خیلی راحت داخلش می‌افتن اینه که موفقیت رو با چیزی اندازه بگیرن که اندازه‌گیریش آسونه.تعداد Ticketهای بسته‌شده.تعداد Featureهای Release‌شده.Velocity.Cycle Time.تعداد Pull Requestها.همه این‌ها اطلاعات مفیدی میدن، ولی یک مشکل دارن:هیچ‌کدوم به تنهایی نمی‌گن آیا کار درستی انجام دادیم یا نه.فرض کنید یک تیم در یک فصل ۲۰ Feature منتشر کرده.همه هم به موقع.ولی بعد از سه ماه:Conversion تغییری نکرده.Retention بهتر نشده.هزینه عملیاتی پایین نیومده.رضایت کاربر هم تغییری نکرده.حتی ممکنه بعضی از Featureها اصلاً استفاده نشده باشن.در این حالت، آیا تیم Engineering شکست خورده؟نه.تیم احتمالاً کار خودش رو خیلی خوب انجام داده.ولی شاید مسئله جای دیگه بوده.تیم یک چیز را خیلی خوب ساخته، اما شاید آن چیزی نبوده که واقعاً باید ساخته می‌شده.نقش تو به عنوان Engineering Manager باید خودشو اینجا نشون بده ;به نظرم یکی از تغییرات مهم در نقش Engineering Manager اینه که مسئولیت ما نباید فقط از جایی شروع بشه که یک Ticket وارد Backlog میشه.اگر Product میگه:«این Feature رو بسازیم.»سؤال Engineering فقط نباید این باشه که:«چطور بسازیمش؟»گاهی باید قبل از اون پرسید:چرا؟چرا این Feature؟چه مشکلی رو حل می‌کنه؟این مشکل چقدر مهمه؟از کجا می‌دونیم واقعاً وجود داره؟اگر این Feature موفق بشه، دقیقاً چه چیزی باید تغییر کنه؟و مهم‌تر از همه:از کجا می‌فهمیم موفق شدیم؟این به معنی دخالت Engineering در Product نیست.اتفاقاً برعکس.به نظرم تیم‌های خوب Product و Engineering جایی به هم نزدیک میشن که هر دو درباره مسئله مشترک صحبت می‌کنن، نه اینکه یکی مسئله رو تعریف کنه و دیگری فقط وظیفه داشته باشه آن را پیاده کند.یک مثال سادهفرض کنید مشکل اینه که تعداد زیادی از کاربران در مرحله پرداخت Order رو نیمه‌کاره رها می‌کنن.یک راه برخورد با این مسئله اینه که چند Ticket بسازیم:تغییر UIاضافه کردن یک Payment Methodبهینه کردن APIکاهش زمان Responseاضافه کردن Retryتغییر Error Messageبعد هم یکی‌یکی همه رو Deliver کنیم.از نظر Engineering احتمالاً اتفاقات خوبی افتاده.اما هنوز یک سؤال باقیه:آیا دراپ در Payment کم شد؟اگر جواب نه باشه، شاید تیم شش ماه خیلی خوب کار کرده باشه و در نهایت تقریباً هیچ اتفاق مهمی برای کسب‌وکار نیفتاده باشه.در مقابل، اگر تیم از ابتدا بدونه هدف مثلاً کاهش Payment Drop-off از ۱۸٪ به ۱۲٪ بوده، تعریف موفقیت کاملاً عوض میشه.ممکنه Feature اول جواب نده.Iteration دوم لازم بشه.حتی ممکنه بعد از دو هفته بفهمیم فرض اولیه اشتباه بوده و باید مسیر رو عوض کنیم.از دید Delivery شاید این اتفاق چندان جذاب نباشه.اما از دید Outcome، دقیقاً داریم یاد می‌گیریم.یک مشکل دیگر: Output خیلی راحت اندازه‌گیری می‌شودقسمت خطرناک ماجرا اینه که Output خیلی ملموسه.می‌تونیم بگیم:«این ماه ۳۵۰ Ticket بستیم.»ولی گفتن اینکه:«این ماه رفتار کاربران X درصد تغییر کرد»خیلی سخت‌تره.چون Outcome معمولاً فقط در اختیار Engineering نیست.به Product، Marketing، Operations، Design، Pricing، رفتار کاربران و ده‌ها عامل دیگه وابسته است.بنابراین من فکر نمی‌کنم درست باشه که بگیم:Engineering Manager باید مسئول تمام Business Outcome یا تغییرات اساسی در تیم تک باشد.اما به نظرم یک Engineering Manager خوب باید حداقل بدونه تیمش برای چه Outcomeای داره تلاش می‌کنه.اگر تیم نمی‌دونه چرا چیزی رو می‌سازه، احتمالاً خیلی راحت تبدیل میشه به یک Feature Factory.ورودی:Ticketخروجی:Featureو بعد Ticket بعدی.تا جایی که همه خیلی مشغولن، ولی کسی دقیقاً نمی‌دونه داریم به کجا می‌ریم.و حالا AI این مسئله را جدی‌تر کردهقبلاً برای ساختن Software یک محدودیت طبیعی داشتیم:زماناگر ساختن یک Feature دو هفته طول می‌کشید، حداقل یک اصطکاک طبیعی وجود داشت که باعث می‌شد قبل از ساختن آن کمی بیشتر فکر کنیم.حالا با ابزارهای AI این اصطکاک کمتر شده.می‌تونیم سریع‌تر Code تولید کنیم.سریع‌تر Refactor کنیم.سریع‌تر Test بنویسیم.سریع‌تر Prototype بسازیم.و این اتفاق واقعاً ارزشمنده.اما یک خطر هم داره:اگر مسئله را اشتباه انتخاب کرده باشیم، فقط سریع‌تر به مقصد اشتباه می‌رسیم.در واقع ممکنه مسئله اصلی Engineering در بعضی تیم‌ها از «چقدر سریع می‌تونیم بسازیم؟» به «اصلاً چی باید بسازیم؟» منتقل بشه.وقتی هزینه تولید Output پایین میاد، ارزش تصمیم درست بیشتر میشه.پس باید Velocity را کنار بگذاریم؟به نظرم نه.Velocity، Cycle Time، Deployment Frequency، Quality Metrics و چیزهای مشابه همچنان مهمن.مشکل وقتی شروع میشه که این‌ها رو با Impact اشتباه بگیریم.من دوست دارم این دو سؤال رو از هم جدا کنم:آیا تیم ما خوب کار می‌کند؟وآیا تیم ما روی مسئله درستی کار می‌کند؟اولی درباره Engineering Executionه.دومی درباره Direction.و یک تیم واقعاً خوب باید هر دو رو داشته باشه.شاید یک تغییر کوچک کافی باشدگاهی حتی یک سؤال ساده قبل از شروع یک پروژه می‌تونه کمک بزرگی باشه:اگر این پروژه موفق بشه، چه چیزی باید در دنیای واقعی تغییر کنه؟مثلاً:نه اینکه:«Payment Flow جدید رو Release کنیم.»بلکه:«می‌خوایم نرخ موفقیت پرداخت رو از X به Y برسونیم.»نه:«سیستم Search جدید رو بسازیم.»بلکه:«می‌خوایم کاربران سریع‌تر به چیزی که دنبالشن برسن و Search Conversion رو افزایش بدیم.»نه:«یک سیستم Notification جدید پیاده کنیم.»بلکه:«می‌خوایم کاربران بیشتری اقدام موردنظر رو بعد از Notification انجام بدن.»در این حالت Feature هنوز مهمه.اما دیگه هدف نیست.Feature تبدیل میشه به یکی از ابزارهای رسیدن به هدف.در نهایتبه نظرم تیم Engineering موفق لزوماً تیمی نیست که بیشترین Feature رو Release می‌کنه.حتی لزوماً تیمی نیست که بیشترین Velocity رو داره.تیم موفق تیمیه که:مسئله درستی رو پیدا می‌کنه،راه‌حل مناسبی می‌سازه،سریع یاد می‌گیره که آیا راه‌حلش جواب داده یا نه،و اگر جواب نداده، حاضر میشه مسیرش رو عوض کنه.چون در نهایت مهم نیست چند Ticket بستیم.مهم نیست چند Feature Release کردیم.حتی مهم نیست چقدر سریع کد نوشتیم.سؤال سخت‌تر اینه:بعد از تمام این کارها، چه چیزی واقعاً بهتر شد؟شاید این سؤال ساده، یکی از مهم‌ترین سؤال‌هایی باشه که یک Engineering Manager می‌تونه از تیم خودش بپرسه.نه فقط:What did we ship?بلکه:What changed because we shipped it?از دوست و همکاری که مسئله ship کردن بهم یاد تشکر میکنم و قدردانشم که چقدر به موضوعات درست نگاه میکرد.هنوز در مسیر یادگیری هستم برای ساختن،برای ship کردن تیم با کیفیت.مسعود شریفی پورمسعود شریفی پورMon, 12 Oct 2026 08:58:12 +0330https://virgool.ir/@masoudsharifi/آیا-engineering-manager-باید-هنوز-کد-بزند-g1zoor3vzejsمن هنوز کد زدن رو دوست دارم. خیلی زیاد.گاهی وسط یه روز کاری که پره از جلسه، جلسه‌های یک‌به‌یک، مصاحبه، برنامه‌ریزی، هماهنگی با محصول، حل مشکلات تیم و هزار تا کار دیگه، دلم میخواد همه اینا رو بذارم کنار و برم سراغ کد.IDE رو باز کنم، یه پروژه رو بالا بیارم، چند تا فایل رو بررسی کنم، بفهمم مشکل کجاست، کد بزنم و یه Pull Request باز کنم.اون حس خوبی که آخرش با خودت میگی:«خب، اینو خودم درست کردم.»برای کسی که سال‌ها مهندس نرم‌افزار بوده، این حس خیلی آشناست. (تعریف از خودم نباشه 😁)یه حس خوبیه که یادت میندازه از کجا اومدی و هنوز هم ازش لذت می‌بری.اما هرچی بیشتر درگیر کارم به عنوان Engineering Manager شدم، بیشتر به این سؤال فکر کردم:آیا من هنوز باید کد بزنم؟و هرچی بیشتر بهش فکر می‌کنم، به نظرم سؤال درست این نیست.سؤال درست اینه:«من چرا دارم کد می‌زنم؟»وقتی Software Engineer بودموقتی Software Engineer بودم، کدنویسی کار اصلی من بود.قبلاً اگر ازم می‌پرسیدی:«امروز چیکار کردی؟»جواب خیلی راحت بود:کد زدم، Feature ساختم، Bug حل کردم، Code Review کردم، یه سیستم رو تغییر دادم.آخر روز هم معمولاً یه چیزی داشتم که می‌تونستم نشونتون بدم.اما وقتی مسیر Engineering Manager رو پیش می‌گیری، بازی عوض میشه.دیگه قرار نیست ارزش تو با تعداد Featureهایی که خودت تحویل دادی سنجیده بشه.قرارِ تیمی که باهاش کار می‌کنی بهتر کار کنه.بچه‌های تیم باید رشد کنن.تصمیم‌های فنی بهتری گرفته بشه.مشکلات زودتر دیده بشن.و تیم بتونه بدون اینکه برای هر تصمیمی بیاد سراغ تو، کارش رو جلو ببره.این تغییر برای من یکی از سخت‌ترین بخش‌های Manager شدن بوده.چون انجام دادن کار، خیلی وقت‌ها راحت‌تر از کمک کردن به دیگرانه که خودشون اون کار رو انجام بدن.کدنویسی برای اینکه فقط Feature تحویل بدیاین قسمت به نظرم جای خطرناک ماجراست.نه اینکه همیشه بد باشه، ولی خیلی راحت میتونه تبدیل بشه به یه عادت بد.فرض کنیم یکی از مهندس‌های تیم مرخصی رفته و یه Feature نیمه‌کاره مونده.منم می‌دونم این Feature چطوری باید پیاده بشه.خب طبیعیه که با خودم بگم:«بذار خودم جمعش کنم.»یا مثلاً یه مشکل فنی داریم که مدت‌هاست کسی وقت نکرده بره سراغش.منم وقت دارم.میشینم پاش، کدش رو می‌نویسم، PR می‌زنم.حس خوبی هم داره.ولی یه سؤال مهم وجود داره:آیا این واقعاً بهترین استفاده از وقت من بوده؟خیلی وقت‌ها جوابش «نه» است.چون من EM هستم و هفته‌ام اصلاً قابل پیش‌بینی نیست.ممکنه دو ساعت وقت برای یه کار کنار گذاشته باشم، ولی وسطش یه Incident اتفاق بیفته، یه مصاحبه داشته باشم، یه 1:1 جدی پیش بیاد، محصول یه موضوع فوری داشته باشه، مدیرم یه کار فوری بخواد یا یه Escalation از سمت مشتری برسه.حالا من یه PR ساخته‌ام که باید جلو بره.Commentها باید جواب داده بشن.Review باید انجام بشه.PR باید Merge بشه.ولی من دیگه وقت ندارم.در نتیجه چیزی که قرار بود کمک کنه، خودش تبدیل میشه به یه Dependency.و این دقیقاً چیزیه که یه EM نباید درگیرش بشه.البته اینجا هم مثل خیلی چیزهای دیگه، یه جواب قطعی وجود نداره.بستگی داره به اینکه موضوع چیه، تیم چه شرایطی داره، بیزنس چه فشاری روشه، چه Stakeholderهایی درگیرن و کلی چیز دیگه.اتفاقاً اینکه بتونی همین شرایط رو ببینی و تشخیص بدی الان باید خودم وارد بشم یا نه، خودش یکی از Skillهای مهم یه EMـه.ممکنه جلوی رشد تیم رو هم بگیریاین قسمت رو خودم خیلی جدی می‌گیرم.گاهی یه کاری رو برمی‌دارم چون می‌دونم خودم سریع‌تر انجامش میدم.مثلاً کاری که برای من دو ساعت زمان می‌بره، شاید برای یکی از بچه‌های تیم یه روز کامل طول بکشه.طبیعیه که مغزم بگه:«خب خودت انجامش بده دیگه، چرا وقت تیم رو می‌گیری؟»ولی شاید اون یه روز برای یکی از بچه‌های تیم خیلی ارزشمندتر از اون دو ساعت برای من باشه.چون توی اون یه روز یه چیزی یاد می‌گیره که بعداً می‌تونه خودش انجامش بده.این یکی از سخت‌ترین تغییرات ذهنی برای Manager شدنه:همیشه سریع‌ترین آدم برای انجام یه کار، بهترین آدم برای انجام اون کار نیست.گاهی بهترین کاری که من می‌تونم انجام بدم اینه که کاری رو که خودم بلدم، به یکی دیگه یاد بدم تا خودش انجامش بده.حتی اگر بدونم احتمالاً اولش خراب‌کاری هم می‌کنه.بخشی از کار من دیگه فقط حل کردن مسئله نیست.ساختن آدم‌هاییه که بتونن مسئله رو حل کنن.یه خاطره بگمیه خاطره از همین موضوع دارم که فکر می‌کنم خوبه اینجا تعریفش کنم.یه Feature داشتیم که توی Planning به یکی از بچه‌های تیم داده شد.تازه وارد تیم شده بود و هنوز خیلی با سیستم آشنا نبود، ولی چیزی که ازش دوست داشتم، پشتکار و انگیزه‌اش بود.خودم هم در جذبش نقش داشتم و از همون اول حس خوبی نسبت بهش داشتم.وقتی Feature رو بهش دادیم، اوایل کار کنارش بودم.کمکش کردم مسئله رو تحلیل کنه، Dependencyها رو بشناسه، بفهمه از کجا باید شروع کنه و چه مسیری رو برای پیاده‌سازی بره.ولی یه جایی عمداً رهاش کردم.نه اینکه دیگه برام مهم نباشه.اتفاقاً برعکس.بهش اعتماد کرده بودم.می‌خواستم خودش مسیر رو پیدا کنه.به نظرم این یکی از جاهایی بود که اگر خودم وارد کار می‌شدم، شاید Feature سریع‌تر جلو می‌رفت، ولی اون آدم چیزی که باید یاد می‌گرفت رو یاد نمی‌گرفت.Feature پیاده شد و رفت برای تست.QA هم تستش کرد و همه‌چیز ظاهراً درست بود.ولی بعد از اینکه Feature رفت بالا، یه مشتری یه باگ جالب گزارش کرد.سناریو این بود که مثلاً من به عنوان کارشناس فروش، برای یه مشتری یه لینک پرداخت می‌فرستم.مشتری لینک رو باز می‌کنه و پرداخت رو انجام میده.قرار بود اعتبار حساب مشتری شارژ بشه.ولی چیزی که اتفاق می‌افتاد این بود که اعتبار حساب کارشناس فروش که لینک رو ساخته و فرستاده بود، شارژ می‌شد!یعنی به جای اینکه شناسه مشتری رو در نظر بگیریم، شناسه کسی که درخواست لینک رو ایجاد کرده بود وارد فرآیند شده بود.طبیعتاً باگ مهمی بود.اینجا هم می‌تونستم خیلی راحت وارد بشم و بگم:«خب، این Feature رو من درست می‌کنم.»یا حتی بدتر:«چطور همچین چیزی رو ندیدی؟»ولی واقعاً هیچ‌کدوم اینا کمکی به رشد اون آدم نمی‌کرد.پس دوباره سعی کردم کنارش باشم، ولی نه اینکه مسئله رو براش حل کنم.کمکش کردم مسئله رو درست بفهمه، سؤال‌های درست ازش پرسیدم و گذاشتم خودش مسیر پیدا کردن مشکل رو بره.خیلی سریع متوجه شد مشکل کجاست.Fix رو انجام داد.تست شد و موضوع حل شد.اینجا یه نکته برای خودم خیلی مهم بود.من به این آدم اعتماد کرده بودم.حالا قرار نبود با اولین اشتباه، اون اعتماد رو پس بگیرم.اشتباه اتفاق افتاده بود.Feedback لازم هم بهش داده شد.مشخص شد چه چیزی باید بهتر می‌شد، مخصوصاً توی تحلیل سناریوها و تست کردن حالت‌های مختلف.ولی تصمیم نگرفتم چون یه اشتباه اتفاق افتاده، از این به بعد خودم همه‌چیز رو کنترل کنم.اتفاقاً برعکس.سعی کردم همچنان پاش بایستم.و نتیجه خیلی جالب بود.بعد از اون اتفاق، برای این آدم یه مسیر رشد جدی شروع شد.کم‌کم مسئولیت‌های بیشتری گرفت، اعتمادبه‌نفسش بیشتر شد، سیستم رو بهتر شناخت و در نهایت تبدیل شد به یکی از بهترین Engineerهای تیم.اگر اون روز من Feature رو ازش گرفته بودم، احتمالاً باگ هم سریع‌تر حل می‌شد.ولی شاید یه چیز مهم‌تر رو از دست می‌دادیم:فرصت رشد یه آدم.این برای من یکی از مهم‌ترین تفاوت‌های Engineer بودن و Engineering Manager بود.وقتی Engineer هستی، طبیعیه که تمرکزت روی حل کردن مسئله باشه.ولی وقتی Manager میشی، باید کم‌کم یاد بگیری که همیشه قرار نیست خودت مسئله رو حل کنی.گاهی وظیفه تو اینه که کنار آدم بایستی، کمکش کنی مسئله رو بفهمه، مسیر رو نشونش بدی و بعد اجازه بدی خودش بره و حلش کنه.حتی اگر احتمال داشته باشه اشتباه کنه.حتی اگر خودت بتونی سریع‌تر انجامش بدی.چون هدف فقط این نیست که این Feature امروز درست بشه.هدف اینه که آدمی بسازی که فردا بتونه Feature بعدی رو خودش درست کنه.پس یعنی مدیر نباید کد بزنه؟نه، اصلاً.به نظرم اینم یکی دیگه از اون جواب‌های صفر و یکیه که برای این موضوع زیاد می‌بینیم.من اگر EM هستم، هنوز باید فنی بمونم.باید بفهمم سیستم چطوری کار میکنه.باید بدونم تیم با چه مشکلاتی درگیره.باید بتونم درباره Architecture، Performance، Reliability، Deployment و Technical Debt حرف بزنم.اگر یکی از بچه‌های تیم بگه:«این تغییر خیلی ساده نیست.»نباید فقط بگم:«خب چند روز زمان می‌خواد؟»باید بتونم بفهمم چرا ساده نیست.اگر Deploymentها ۴۰ دقیقه طول میکشن و هر چند وقت یه بار هم Fail میشن، برای من مهمه بفهمم مشکل کجاست.اگر یه تست مدام Flaky میشه، خوبه که بدونم چرا.اگر تیم از یه Service خاص متنفره، باید بدونم چرا.برای همین من فکر می‌کنم EM باید داخل کد باشه، ولی لزوماً کدنویس اصلی تیم نباشه.کدنویسی برای فهمیدن با کدنویسی برای تحویل دادن فرق دارهاین بخش برای من خیلی جذابه.گاهی لازم نیست یه Feature کامل بسازم.میتونم یه Bug رو Debug کنم.میتونم Pipeline مربوط به Deployment رو بررسی کنم.میتونم یه Service رو که خوب نمی‌شناسم از روی کد بخونم.میتونم با یکی از بچه‌ها Pair بشم.میتونم برم ببینم چرا یه تست خاص مدام Fail میشه.حتی میتونم یه تغییر کوچیک بدم که قرار نیست هیچ‌کس براش Sprint Planning داشته باشه.هدف اینجا تحویل Feature نیست.هدف Understandingـه.میخوام اونقدر نزدیک به سیستم بمونم که وقتی تیم درباره یه Technical Constraint، یه تخمین، یه Trade-off یا یه مشکل معماری صحبت میکنه، واقعاً بفهمم چی میگن.نه اینکه فقط سرم رو تکون بدم و بگم:«بله، بله، Technical Debt.»این به نظرم یکی از خطرناک‌ترین حالت‌های EM شدنه.مدیری که دیگه واقعاً Engineering رو نمی‌فهمه، ولی همچنان درباره Engineering تصمیم می‌گیره.AI این داستان رو یه مقدار تغییر دادهتا چند وقت پیش، یکی از مشکلات اصلی این بود که کدنویسی جدی Focus می‌خواست.اگر قرار بود واقعاً یه چیزی بسازم، باید چند ساعت وقت خالی داشتم.برای EM این تقریباً یه شوخیه.چون ممکنه ساعت ۹ صبح برنامه داشته باشم که روی یه موضوع فنی کار کنم و ساعت ۹:۱۵ اولین جلسه برنامه‌ریزی‌نشده‌ام شروع بشه!ولی AI یه مقدار این قضیه رو تغییر داده.الان میتونم یه Agent رو بفرستم دنبال یه موضوع.مثلاً:«برو بررسی کن چرا Deployment ما اینقدر طول میکشه.»بعد خودم برم سراغ یه جلسه.بین دو جلسه نتیجه رو ببینم.به Agent جهت بدم.بعد بذارم Implementation اولیه رو انجام بده.و در نهایت خودم Review کنم.این به نظرم یه استفاده خیلی خوب از AI برای EMـه.چون میتونم برم سراغ چیزهایی که تیم شاید مدت‌هاست میخواد انجام بده، ولی هیچ‌وقت واقعاً توی اولویت قرار نمی‌گیره.مثلاً بررسی Technical Debt، بهبود Observability، بررسی Pipeline، یه Flaky Test یا حتی فهمیدن اینکه یه Service قدیمی دقیقاً چه کاری انجام میده.ولی AI یه مشکل جدید هم آوردهAI خیلی راحت‌تر از قبل بهم اجازه میده مفید باشم.ولی یه مشکل وجود داره:خیلی راحت‌تر هم میتونم فکر کنم مفیدم، در حالی که دارم مزاحم تیم میشم.این دوتا با هم فرق دارن.فرض کن تیم داره روی یه Feature کار میکنه.منم با Claude چند ساعت کار میکنم و یه PR آماده میکنم.کلی کد تولید شده.تست هم نوشته شده.PR هم مرتب و تمیزه.از بیرون همه‌چیز عالیه.ولی شاید اصلاً نباید من این کار رو انجام میدادم.شاید یکی از Engineerهای تیم باید این کار رو انجام میداد.شاید دارم یه تصمیم فنی رو از تیم می‌گیرم.شاید فردا تیم باید ساعت‌ها وقت بذاره تا بفهمه من چی ساختم.یا بدتر:شاید خودم تبدیل شدم به Critical Path.برای تصمیم گرفتن سه تا سؤال دارمبرای همین اخیراً اگر بخوام یه کار فنی رو خودم بردارم، سعی میکنم سه تا سؤال از خودم بپرسم.۱. اگر من انجامش ندم، یکی از بچه‌های تیم خودش سراغش میره؟اگر جواب بله باشه، احتمالاً بهتره خودم انجامش ندم.چون اگر یکی از Engineerهای تیم بالاخره وقت پیدا میکنه و میره سراغش، چرا باید فرصت رو ازش بگیرم؟ولی اگر جواب اینه که:«نه، احتمالاً هیچ‌وقت انجام نمیشه، چون همیشه چیزهای مهم‌تری داریم.»اون وقت قضیه فرق میکنه.مثلاً یه Technical Debt قدیمی که همه میدونن باید حل بشه، ولی هیچ‌وقت توی اولویت قرار نمی‌گیره.این میتونه جای خوبی باشه که خودم برم سراغش.۲. اگر وسط کار متوقف بشم، مشکلی پیش میاد؟این سؤال خیلی مهمه.من واقعاً نباید خودم رو بذارم روی Critical Path.چون احتمال اینکه برنامه‌ام به هم بخوره خیلی زیاده.ممکنه امروز فکر کنم سه ساعت وقت دارم، ولی یهو یه Incident بیاد.یا یه جلسه اضطراری پیش بیاد.یا یه موضوع مدیریتی مهم اتفاق بیفته.اگر کاری که برداشتم بدون من متوقف میشه، احتمالاً انتخاب خوبی نبوده.۳. آیا این کار میتونه برای یکی از مهندس‌های تیم یه فرصت یادگیری باشه؟این یکی یه مقدار سخت‌تره.چون همیشه از قبل نمیشه فهمید.ولی باید حواسم باشه که یکی از مهم‌ترین مسئولیت‌های من، رشد دادن آدم‌های تیمه.اگر هر کار جالبی رو خودم بردارم، عملاً دارم فرصت‌های یادگیری رو از بچه‌ها می‌گیرم.ممکنه توی کوتاه‌مدت تیم سریع‌تر کار کنه.ولی توی بلندمدت چی؟ممکنه یه تیم داشته باشم که کلی کار تحویل داده، ولی آدم‌هاش رشد نکردن.به نظرم این معامله خوبی نیست.من فکر میکنم باید برای کدنویسی وقت مشخص داشته باشمبا همه این حرف‌ها، اینکه EM کلاً کدنویسی رو کنار بذاره هم به نظرم اشتباهه.خودم دوست دارم چند ساعت در هفته رو عمداً برای کار فنی کنار بذارم.نه برای اینکه دوباره Developer بشم.برای اینکه Technical بمونم.حتی یه لیست از چیزهایی که درست نمی‌فهمم هم میتونه خیلی کمک کنه.هر وقت وسط یه بحث فنی متوجه شدم دارم سر تکون میدم ولی واقعاً نمیفهمم طرف مقابل چی میگه، اون موضوع باید بره توی لیستم.بعداً میرم سراغش.مثلاً اخیراً اگر بخوام عمیق‌تر روی موضوعاتی مثل ، Observability یا ابزارهایی مثل NER (Named-entity recognition) کار کنم، اتفاقاً AI کمک خیلی بزرگیه.میتونم یه موضوع رو بردارم و از چند زاویه بررسیش کنم.سؤال بپرسم.مثال بخوام.حتی روی یه نمونه واقعی از سیستم خودمون بررسیش کنم.این به نظرم خیلی ارزشمنده.هدف این نیست که دوباره Engineer بشمفکر میکنم این مهم‌ترین قسمت کل ماجراست.من قرار نیست دوباره برگردم به همون Software Engineer چند سال پیش.قرار نیست بیشترین کد تیم رو من بنویسم.قرار نیست بهترین Technical Decisionها حتماً از من بیاد.قرار نیست هر PR مهمی رو خودم باز کنم.هدف چیز دیگه‌ایه.میخوام اونقدر فنی بمونم که وقتی تیم درباره یه مشکل حرف میزنه، بفهمم مشکل چیه.وقتی یکی یه تخمین میده، بتونم سؤال درست بپرسم.وقتی دو تا راه‌حل فنی داریم، بتونم Trade-offهاشون رو بفهمم.وقتی تیم میگه:«این کار سه روزه نیست.»بتونم بفهمم چرا.و مهم‌تر از همه، وقتی تیم یه تصمیم فنی میگیره، بتونم تشخیص بدم که آیا واقعاً تصمیم خوبیه یا نه.هر خط کدی که نمیفهمی، یه بدهیهیه جمله‌ای هست که خیلی دوستش دارم:هر خط کدی که نمیفهمی، یه بدهیه که بالاخره باید با سودش پس بدی.به نظرم این برای Managerها حتی مهم‌تره.لازم نیست همه کد رو بفهمم.واقعاً هم نمیشه.ولی اگر قسمت‌های مهم سیستم رو نفهمم، دیر یا زود این ناآگاهی خودش رو نشون میده.یه روز تیم درباره یه مشکل حرف میزنه و من نمیفهمم.یه روز یه تصمیم معماری گرفته میشه و من نمیتونم درست Challenge کنم.یه روز یه تخمین اشتباه داده میشه و من نمی‌تونم تشخیص بدم.اون موقع هزینه فاصله گرفتنم از Engineering رو پرداخت میکنم.پس بالاخره EM باید کد بزنه یا نه؟اگر بخوام خیلی کوتاه جواب بدم:بله.ولی نه برای اینکه ثابت کنه هنوز Engineerه.کد بزن برای اینکه بفهمی.Debug کن برای اینکه سیستم رو بهتر بشناسی.Pair کن تا با تیم نزدیک بمونی.روی Technical Debtهایی کار کن که هیچ‌کس وقت رسیدگی بهشون رو نداره.با AI تحقیق کن.کد بخون.سیستم رو بشناس.ولی حواست باشه خودت رو تبدیل به Developer اصلی تیم نکنی.چون از یه جایی به بعد، بیشتر کد زدن دیگه لزوماً نشونه Technical بودن نیست.ممکنه فقط نشونه این باشه که هنوز نتونستی از نقش قبلیت دل بکنی.من هنوز وقتی یه مسئله فنی جالب میبینم، دلم میخواد خودم برم سراغش.احتمالاً این حس هیچ‌وقت کامل از بین نمیره.ولی الان قبل از اینکه دست به کد بشم، سعی میکنم یه سؤال از خودم بپرسم:«این کاری که الان میخوام انجام بدم، واقعاً به تیم کمک میکنه، یا فقط خودم رو خوشحال میکنه؟»به نظرم برای یه Engineering Manager، جواب همین سؤال خیلی چیزها رو مشخص میکنه.شاید وقتی Engineer بودم، موفقیت برای من این بود که خودم مسئله رو حل کنم.ولی امروز، بخش مهم‌تری از موفقیت برای من اینه که آدم‌هایی داشته باشم که خودشون بتونن مسئله رو حل کنن.و فکر میکنم این یکی از بزرگ‌ترین تفاوت‌های Engineer بودن و Engineering Manager بودنه.حرف آخرو . . . و. . . و… 😄یکم از این نوشته‌هایی که تایتل‌وار و خط‌به‌خط نوشته شدن فاصله بگیریم.بعضی قسمت‌های این مقاله رو سعی کردم فنی بنویسم، بعضی جاها عامیانه‌تر حرف زدم، بعضی جاها هم شاید یکم کتابی شده باشه. در واقع چیزی بوده که توی ذهنم بوده و سعی کردم همون رو تبدیل کنم به کلمه و با شما به اشتراک بذارم.یه بخش‌هایی از این حرف‌ها هم طبیعتاً از مقاله‌ها و نوشته‌های دیگه‌ای که خوندم اومده. ولی در نهایت چیزی که اینجا می‌خونید فقط ترجمه یا خلاصه یک مقاله نیست. ترکیبیه از چیزهایی که خوندم، چیزهایی که تجربه کردم، خاطراتی که داشتم و مهم‌تر از همه، چیزی که خودم بهش رسیدم.ولی اگر بخوام همه این مقاله رو توی یک چیز خلاصه کنم، برای من اینه:به نظرم یکی از مهم‌ترین مهارت‌های یک EM اینه که بتونه ۳۶۰ درجه به ماجرا نگاه کنه.فقط تیم خودش رو نبینه.بتونه تیمش رو ببینه، Stakeholderهاش رو ببینه، بیزینس رو ببینه، Customer رو ببینه و حتی جایی که داره سرویس می‌ده و تأثیری که تصمیم‌هاش اونجا می‌ذاره رو هم ببینه.باید بتونی وقتی یک تصمیم جلوت قرار می‌گیره، خیلی سریع بفهمی این تصمیم چه اثری روی تیمت داره، روی این Stakeholder چه اثری داره، روی اون یکی Stakeholder چی، روی Customer چه تأثیری می‌ذاره و اصلاً آیا داری یک مانع رو از سر راه تیم برمی‌داری یا خودت داری یک مانع جدید درست می‌کنی.و برای اینکه بتونی همچین نگاهی داشته باشی، باید سیستم رو بشناسی.نمی‌تونی از Engineering فاصله بگیری و انتظار داشته باشی همچنان بتونی درباره Engineering تصمیم‌های درست بگیری.پس آیا EM باید کد بزنه؟به نظرم آره. چرا که نه؟چرا نباید کد بزنه؟فقط باید حواسش باشه که برای چی داره کد می‌زنه.قرار نیست با کدنویسی ثابت کنیم هنوز Engineer هستیم.قرار نیست جای بچه‌های تیم رو بگیریم.قرار نیست همه Featureها رو خودمون بزنیم.گاهی باید کد بزنیم تا سیستم رو بهتر بفهمیم، گاهی Debug کنیم، گاهی Pair بشیم، گاهی یک Technical Debt قدیمی رو جمع کنیم و گاهی هم با AI بریم سراغ چیزهایی که مدت‌هاست می‌دونیم باید بفهمیم یا درستشون کنیم.این مقاله برای من خلاصه‌ای بود از کلی مقاله و نوشته‌ای که خوندم، چیزهایی که توی مسیر Engineering Manager شدن یاد گرفتم، تجربه‌هایی که داشتم و البته یک‌سری حس و فکر شخصی که مدت‌ها توی ذهنم بود.دوست داشتم همه این‌ها رو یک‌جا با شما به اشتراک بذارم.امیدوارم دوستش داشته باشید. ❤️مسعود شریفی پورمسعود شریفی پورSat, 29 Aug 2026 22:07:51 +0330https://virgool.ir/@masoudsharifi/اگر-تیم-ما-رستوران-داشت-p1wqh9zldaxmدر دنیای نرم‌افزارها، همه‌چیز قرار بود ساده‌تر، سریع‌تر و قابل‌فهم‌تر باشه. اما به نظر می‌رسه هر روز بیشتر از کاربر واقعی فاصله می‌گیریم. توی بعضی تیم‌های محصول و طراحی، تمرکز دیگه روی حل مسئله نیست — روی ساخت «چیزی باحال» یا «قابل ارائه» توی پرزنت بعدیه.برای اینکه بدونیم بعضی از تصمیم‌هایی که می‌گیریم چقدر می‌تونن از واقعیت دور، بی‌منطق یا حتی خنده‌دار باشن، بیاید ی استعاره براتون بگم:اگر تیم ما به جای ساختن محصول، یه رستوران راه می‌نداخت، چی می‌شد؟KPISما برای کی طراحی می‌کنیم؟هر تیم محصولی، یه جایی باید این سؤال رو از خودش بپرسه:"ما دقیقاً داریم برای کی طراحی می‌کنیم؟"برای کاربری که نیاز داره یه مسئله رو ساده حل کنه؟یا برای اسلاید گزارش ماهانه؟یا شاید برای سلیقه مدیرمون یا مدیرعامل، که عاشق فیچرهای پیچیده‌ست؟وقتی کاربر واقعی از میز تصمیم‌گیری حذف می‌شه، اتفاقات عجیب و گاهی مسخره‌ای می‌افته — تصمیم‌هایی که اگه توی دنیای واقعی اجرا بشن، احتمالاً خودمون هم بهشون می‌خندیم.برای درک بهتر این ماجرا، بیاید این استعاره رو جدی بگیریم:تصور کنید تیم محصول ما یه رستوران افتتاح کرده...اگر تیم ما رستوران داشت...صحنه اول: ورود مشتری = ثبت‌نام اجباری!مشتری وارد رستوران می‌شه. گرسنه‌ست. دنبال یه غذای ساده‌ست.ولی مسئول پذیرش با لبخند می‌گه:«سلام! قبل از هرچیز لطفاً فرم ثبت‌نام رو پر کنید. بعدش می‌تونید منو رو ببینید.»مشتری: «من فقط یه میرزاقاسمی می‌خوام!»مسئول: «درک می‌کنم، ولی ما سیاست‌های تجربه مشتریمون اینطوریه. ایمیل، شماره موبایل، نوع گوشی و محل سکونت لطفاً!»بعد از کلی فرم و OTP و تأییدیه، تازه وارد سالن می‌شه.صحنه دوم: دیدن منو فقط با اشتراک!مشتری می‌پرسه: «خب حالا چی دارید؟»گارسون: «بستگی داره! شما توی کدوم پلن هستید؟»پلن رایگان: نون تست و آب ولرمپلن نقره‌ای: سوپ بدون افزودنیپلن طلایی: غذاهای اصلی، با نوبت سه‌روزهپلن VIP: غذای داغ، میز پنجره، بدون تبلیغ!مشتری: «من فقط یه غذا می‌خوام. این همه پیچیدگی چرا؟»گارسون: «شما آزادی انتخاب دارید :)»صحنه چهارم: لغو اشتراک؟ فراموشش کن!بعد از اولین وعده، مشتری تصمیم می‌گیره که دیگه نیاد.ولی وقتی می‌خواد اشتراک رو لغو کنه:باید دلیل لغو رو بنویسهاز فرم پشتیبانی استفاده کنهمنتظر بررسی بشهو تا پایان ماه همچنان پول بده!گارسون با افتخار می‌گه:«ما خروج سخت طراحی کردیم تا نرخ از دست دادن شما بره بالا :)»صحنه پنجم: تیم محصول از خودش راضیه!پشت‌صحنه این رستوران، تیمی نشسته که غرق در آمار و نمودارهای رشدن:نرخ ثبت‌نام: ۷۳٪ رشدتعامل با منو: ۴۸٪ افزایشنرخ ماندگاری ماه اول: بالاتر از حد میانگین!اما هیچ‌کس نمی‌پرسه:آیا کسی واقعاً سیر شد؟ آیا کسی راضی بود؟مشکل از کجاست؟حالا بیاید از این استعاره برگردیم به واقعیت. چرا چنین رفتارهایی توی تیم‌های محصول شکل می‌گیره؟ چرا بعضی تیم‌ها از کاربر جدا می‌شن و به سمت تصمیم‌هایی می‌رن که از بیرون مسخره به‌نظر می‌رسن؟۱. چون KPI از کاربر مهم‌تر شدهوقتی معیار موفقیت، فقط عدد باشه (مثل ثبت‌نام، نرخ فعال‌سازی)، دیگه تجربه انسانی گم می‌شه.۲. چون طراحی با پرزنت اشتباه گرفته شدهفیچرهایی ساخته می‌شن که فقط «توی اسلاید» جذابن، نه در استفاده‌ی واقعی.۳. چون خودمون دیگه کاربر نیستیمما به محصول عادت می‌کنیم. پیچیدگی‌ها برامون عادی می‌شن. اما یه کاربر تازه؟ فقط گیج می‌شه.۴. چون خروج کاربر، تهدید تلقی می‌شهبه‌جای اینکه بفهمیم چرا کاربر می‌ره، مسیر رفتنش رو سخت می‌کنیم. این یعنی ترس از واقعیت.ویلای بدون در | یک استعاره ساده برای درک تجربه کاربرفرض کنید شما یه تیم طراحی و محصول هستید که با کلی انرژی، هزینه، و خلاقیت، یک ویلا طراحی کردید.همه چیز فوق‌العاده‌ست:نور زیاد و طبیعیطراحی داخلی چشم‌نوازمبلمان عالی، امکانات رفاهی کاملفضای باز برای استراحت، منظره بی‌نظیراز بیرون که نگاه می‌کنید، واقعاً به خودتون افتخار می‌کنید:«چه محصولی ساختیم! واقعاً کامل و زیباست.»اما یک چیز کوچک رو فراموش کردید:درِ ورودی ویلا وجود نداره.کاربر باید برای ورود به این ویلای رویایی، از روی دیوار بالا بره.باید نردبون پیدا کنه. شاید به کمک کسی نیاز داشته باشه.شاید اصلاً زورش نرسه.یا حوصله‌ش نکشه.یا همون اول منصرف بشه و بره.و حالا سؤال مهم:شما به‌عنوان طراح این ویلا، کِی آخرین بار از بیرون، از توی کوچه، وایسادید و سعی کردید وارد بشید؟اصلاً تست کردید مسیر ورود چقدر راحته؟ یا فقط محو زیبایی داخل ویلا شدید؟تجربه کاربری همینه.ممکنه اپلیکیشن شما ده‌ها قابلیت عالی داشته باشهممکنه طراحی UI شما بی‌نقص باشهممکنه حتی سیستم هوش مصنوعی پشت محصول کار خفن انجام بدهاما اگه کاربر نتونه به راحتی وارد بشه، ثبت‌نام کنه، شروع کنه، یا بفهمه چطوری استفاده کنه — همه اون ویژگی‌ها بی‌فایده‌ست.گاهی باید بیایم توی کوچه وایسیم.گاهی باید از زاویه‌ی دید کاربر، از جایی که هیچ‌چی درباره ما نمی‌دونه، به محصول‌مون نگاه کنیم:اگه من الان برای اولین بار اومدم اینجا، چی می‌بینم؟می‌تونم بدون گیج شدن وارد بشم؟مسیر ورود من مثل دره یا دیواره؟کار طراحی، فقط ساختن فضای داخلی نیست — ساختن مسیر ورود، حتی مهم‌تره.جمع‌بندی این بخش:کاربر اول باید وارد ویلا بشه، بعد حالش از دیدن منظره خوب می‌شه.اگه نتونه بیاد تو، فرقی نمی‌کنه شما تو ویلا چی گذاشتید.بیاید هر از چند وقت، از محصولمون بیایم بیرون.تو کوچه بایستیم.از صفر سعی کنیم واردش بشیم.شاید متوجه بشیم...ما درِ محصولمون رو فراموش کردیم.نتیجه‌گیری: کاربر، گرسنه‌ست — ما باید غذا بدیم، نه فرم ثبت‌نام!تجربه کاربری خوب، مثل غذای خوبه.نباید نیاز به راهنما، پلن اشتراک، یا پشتیبانی برای فهمش باشه.ما محصول نمی‌سازیم برای KPI.ما محصول می‌سازیم برای یک انسان واقعی، با یک نیاز واقعی، که باید بدون دردسر، به یک راه‌حل ساده و انسانی برسه.بیاید تجربه رو ساده کنیم.انسانی طراحی کنیم.و هیچ‌وقت فراموش نکنیم:رضایت، از سادگی میاد؛ نه از پیچیدگی‌هایی که کاربر رو گم می‌کنن.مسعود شریفی پورمسعود شریفی پورWed, 31 Dec 2025 18:18:36 +0330https://virgool.ir/@masoudsharifi/آیا-با-وجود-ai-باید-انتظار-بهروری-بالا-را-داشت-gtf53hhqeswiما امروز در دنیای فناوری و مهندسی، شاهد موجی تازه از هیجان هستیم؛ موجی که نامش «هوش مصنوعی» است. سازمان‌ها این موج را می‌بینند و احساس می‌کنند اگر بخواهند عقب نمانند، باید سوارش شوند. وعده‌های هوش مصنوعی وسوسه‌انگیز است: سرعت بیشتر، کیفیت بهتر، و تصمیم‌گیری دقیق‌تر. طبیعی است که همه انتظار داشته باشند این فناوری به‌طور مستقیم به افزایش بهره‌وری منجر شود.اما واقعیت کمی پیچیده‌تر است. ما در حال ورود به یک نسل جدید از کار و همکاری هستیم؛ نسلی که صرفاً جایگزین نسل قبلی نمی‌شود، بلکه نیاز به یادگیری، جذب، و پرورش دارد. پرسش مهم اینجاست: آیا نیروهای قدیمی‌تر و ساختارهای تثبیت‌شده می‌توانند با این موج جدید سازگار شوند و خودشان را بازتعریف کنند؟از نگاه من، بله—ما باید انتظار بهره‌وری بالاتر را داشته باشیم. اما این بهره‌وری همیشه به معنای تولید بیشتر یا کارهای کاملاً جدید نیست؛ گاهی همان کارهای گذشته را سریع‌تر و با کیفیت بهتر انجام می‌دهیم، و در نتیجه زمان آزاد بیشتری برای توسعه ویژگی‌های نو، کدهای بهتر یا حتی رویکردهای تازه به‌دست می‌آوریم.به بیان ساده: هوش مصنوعی موتور افزایش بهره‌وری است، اما برای روشن شدن این موتور، نسل جدیدی از مهارت‌ها و ذهنیت‌ها را باید بپذیریم و پرورش بدیم.بهره‌وری در عصر هوش مصنوعی — بازتعریف، فرصت و ریسکبهره‌وری همچنان مفهوم «خروجی بر ورودی» را داره، اما در اقتصاد دانشی امروز باید ابعاد دیگری هم به آن اضافه کنیم: سرعت تصمیم‌گیری، کیفیت تصمیم، توان حل مسئله و ظرفیت خلق نوآوری. هوش مصنوعی در این ابعاد تأثیر عمیق میزاره — سرعت انجام کارها را بالا می‌بره، کیفیت تحلیل‌ها را ارتقا میده و گاهی ظرفیت یک فرد را به اندازه دو نفر زیاد می‌کند.وقتی یک نفر با کمک AI بتونه کار دو نفر را انجام بده، احتمال دارد فشار روی ساختارهای سازمانی برای کاهش نیرو یا بازطراحی سریع نقش‌ها افزایش پیدا کنه. اگر افراد نتونن خودشون رو در تعریف جدید نقش‌ها ببینند — یعنی نگیرند که «من هنوز برای این کار ارزش دارم» — این تکنولوژی برای آن‌ها دردسرساز میشه، نه فرصت. بنابراین بهره‌وریِ واقعی تنها حاصلِ تواناییِ ابزار نیست؛ حاصلِ سازگاریِ انسان‌ها، بازتعریف نقش‌ها و پرورشِ نسل جدیدی از مهارت‌هاست.نظره مسعود : باید انتظار افزایش بهره‌وری داشت، ولی این افزایش خودکار و بدون هزینه اجتماعی نیست. اگر سازمان‌ها صرفاً سرعت را بالا ببرند بدون اینکه نقش‌ها، آموزش و سیاست‌های حمایتی را بازسازی کنند، نتیجه می‌تواند تعدیل نیرو و نابرابری بیشتر باشد — نه بهره‌وری پایدار.از اینترنت تا هوش مصنوعی؛ تکرار یک موج تاریخی با تفاوت‌های تازهدر ابتدای دهه ۲۰۰۰، ورود اینترنت به زندگی روزمره و محیط‌های کاری یک «عصر تازه» را رقم زد. سرعت دسترسی به اطلاعات افزایش یافت، ارتباطات جهانی شد و مدل‌های کسب‌وکار سنتی دگرگون شدند. بسیاری از سازمان‌ها تلاش کردند از این موج بهره‌وری بسازند؛ بعضی موفق شدند و بعضی دیگر جا ماندند. نگاهی به همان دوران نشان می‌دهد که چگونه شرکت‌های نوپایی مانند آمازون، گوگل و فیسبوک توانستند ارزش‌های میلیارددلاری خلق کنند، در حالی که بسیاری از غول‌های سنتی یا نابود شدند یا به حاشیه رانده شدند.امروز، هوش مصنوعی در جایگاهی مشابه قرار دارد. همان‌طور که اینترنت فرصت‌های بی‌سابقه‌ای برای خلق ارزش به وجود آورد، AI هم می‌تواند دریچه‌ای تازه به روی نوآوری و بهره‌وری باز کند. تفاوت اما در سرعت تغییرات است: اگر اینترنت در یک بازه ۱۰ تا ۱۵ ساله توانست صنایع مختلف را متحول کند، هوش مصنوعی تنها در چند سال اخیر بسیاری از بخش‌ها را زیر و رو کرده است.با این حال، همان‌طور که اینترنت تنها برای سازمان‌هایی ارزش آفرید که توانستند مدل‌های کسب‌وکارشان را بازتعریف کنند، AI نیز فقط برای سازمان‌هایی سودمند خواهد بود که به جای افزودن یک ابزار روی ساختار قدیمی، فرآیندها و نقش‌ها را متناسب با این موج بازطراحی کنند.من اگر بخوام نظرمو بگمدرست مثل اینترنت، هوش مصنوعی هم هم‌زمان فرصت و تهدید است.سازمان‌هایی که فقط به کاهش هزینه‌ها یا تعدیل نیرو فکر کنند، بهره‌وری کوتاه‌مدت می‌گیرند ولی مزیت رقابتی بلندمدت را از دست خواهند داد.در مقابل، کسانی که نگاهشان به خلق ارزش‌های جدید باشد — محصول تازه، تجربه بهتر مشتری، مدل‌های کسب‌وکار نو — می‌توانند «آمازون» یا «گوگل» نسل AI شوند.در نهایتهوش مصنوعی یک امکان فوق‌العاده برای افزایش بهره‌وریه، اما هیچ تضمینی برای تحقق آن وجود نداره. تفاوت اصلی میان سازمان‌هایی که از AI بهره‌وری واقعی می‌گیرند و اونهایی که فقط اسیر «مد روز» میشن، در نحوه به‌کارگیری این فناوری پنهان شده.در نهایت، بهره‌وری آینده بیشتر از آنکه وابسته به خود تکنولوژی باشه، وابسته به انسان‌ها، فرهنگ سازمانی و توانایی تطبیق ما با تغییراته. پرسشی که باقی میمونه این هستش که:آیا ما آماده‌ایم از این ابزار برای ساخت آینده‌ای بهره‌ورتر استفاده کنیم، یا فقط سرعت درجا زدنمون بیشتر کرده‌ایم؟مسعود شریفی پورمسعود شریفی پورSun, 19 Oct 2025 11:19:05 +0330https://virgool.ir/@masoudsharifi/به-جای-چقدر-طول-می-کشه-بپرسیم-چی-قراره-بسازیم-qzidwogja08eدر دنیای توسعه محصول، یکی از رایج‌ترین سؤالاتی که تیم‌ها با آن روبه‌رو میشن اینه که:«این تسک چقدر زمان می‌بره؟»در ظاهر، سؤال بی‌خطری به نظر می‌رسه. اما پاسخ‌دادن سریع و بدون زمینه، معمولاً ما را وارد چرخه‌ای از توقعات اشتباه، استرس، و بازنگری‌های پرهزینه می‌کنه.مشکل از جایی شروع میشه که ما به جای درک واقعی از مسئله، به‌سرعت وارد فاز برنامه‌ریزی می‌شویم. در حالی که اغلب، هنوز دقیق نمیدونیم چی میخوایم:چه چیزی قرار است ساخته شود؟با چه موانعی روبه‌رو هستیم؟و اصلاً این تسک، در کجای مسیر رشد محصول قرار می‌گیرد؟به‌جای تخمین زدن، ابتدا بفهمیمما نیاز داریم پیش از برنامه‌ریزی، ابتدا «سطح درک تیم» از مسئله را بسنجیم. آیا تیم آمادهٔ تخمین‌زدن هست؟ یا هنوز باید کشف یا بررسی بیشتری انجام بشه؟در تجربهٔ ما، اغلب تسک‌ها در یکی از این سه دسته قرار می‌گیرند:1. تسک‌هایی که می‌توان دقیق تخمین زد:مشکل و راه‌حل روشن است.تیم با دامنه آشناست.وابستگی‌ها و ریسک‌ها کم است.مثال: اصلاح یک باگ در سیستم شناخته‌شده.2. تسک‌هایی که نمی‌توان فعلاً تخمین زد:هنوز هدف مبهم است.تکنولوژی جدید است.نیاز به هماهنگی بیرونی دارد.مثال: طراحی یک سیستم قیمت‌گذاری جدید برای فروش محصول تازه لانچ شده.3. تسک‌هایی که فاز اول آن‌ها، فقط برای تخمین‌زدن است:نیاز به Discovery دارد.قرار است ابتدا نمونه‌سازی یا تحلیل اولیه انجام شود.مثال: بررسی امکان پشتیبانی از یک نوع جدید پرداخت با تأمین‌کنندهٔ خارجی.درک، پایهٔ اعتماد استوقتی به‌جای فشار برای عدد دادن، به تیم کمک کنیم که «درک» خود را از مسئله بسنجند، دو اتفاق خوب میفته:تصمیم‌گیری‌ها دقیق‌تر می‌شود، چون دید ما واقعی‌تر است.تیم احساس امنیت و مشارکت بیشتری می‌کند، چون از او توقع حدس‌زدن بی‌پشتوانه نداریم.مثال واقعیفرض کنیم تیم قراره ویژگی «پشتیبانی از پلن پرداخت اقساطی» رو به پلتفرم اضافه کنه. در ظاهر، این فقط اضافه‌کردن یک گزینه جدید در فرم پرداخت به نظر می‌رسه. اما وقتی با دید درک عمیق‌تر جلو بریم، متوجه می‌شیم:وضوح هدف پایین: هنوز دقیق نمی‌دونیم اقساط قراره چطور محاسبه بشن. آیا سود داره؟ بازه‌هاش چطوریه؟وابستگی فنی بالا: نیاز به اتصال به درگاه بانکی جدید یا شرکت اعتبارسنجی هست.نیاز به هماهنگی بیرونی: تیم حقوقی باید قوانین جدید قراردادها رو بررسی کنه.آشنایی پایین: تیم قبلاً روی چنین قابلیتی کار نکرده.هماهنگی بین‌تیمی: تیم‌های مالی، مارکتینگ و پشتیبانی هم باید در جریان تغییرات باشن.نتیجه؟این تسک در ابتدا قابل تخمین نیست. ما نیاز به یک فاز کشف (Discovery) داریم:جمع‌آوری نیازمندی‌ها از تیم حقوقی و مالیبررسی محدودیت‌های فنی در اتصال به API جدیدطراحی اولیه تجربه کاربریسنجش پیچیدگی اجرا با کمک مهندسی فنیبعد از این مرحله، تازه می‌تونیم بفهمیم واقعاً چقدر کار داریم، و آیا تخمین دقیق ممکنه یا نه.جمع‌بندیما معمولاً میدونیم که هر تسکی یکی از سه حالت زیر را داره:قابل تخمین دقیقغیرقابل تخمین (در حال حاضر)نیازمند فاز اولیه برای کشف و سپس تخمیناگر تیم به این طبقه‌بندی فکر کنه، همکاری‌های واقعی‌تری شکل می‌گیره، توقعات بهتر مدیریت می‌شود و خروجی نهایی باکیفیت‌تر خواهد بود.پرسیدن این سؤال ساده در شروع هر پروژه می‌تواند نقطهٔ تفاوت باشه:«آیا می‌دانیم قراره چی بسازیم؟ یا هنوز باید بفهمیم؟»مسعود شریفی پورمسعود شریفی پورSun, 27 Jul 2025 11:45:13 +0330https://virgool.ir/@masoudsharifi/چطور-تیمم-را-ساختم-نه-فقط-برای-تحویل-کار-برای-خلق-ارزش-lc5ljrc79bdtدر اولین روزهایی که وارد این مسیر شدم، وقتی مسئولیت رو گرفتم، با فضایی روبه‌رو بودم که نیاز به بازتعریف، انسجام و ساختار تازه داشت — جایی که باید تیمی شکل می‌گرفت که نه‌فقط کار انجام بده، بلکه معنا خلق کنه. همه‌چیز باید از اول، از پایه ساخته می‌شد — اما نه فقط برای تحویل کار. برای من، ساختن یعنی خلق ارزش، ساختن فضا، معنا، و مسیر برای رشد.من تلاش نکردم فقط یک تیم جمع کنم که کارها را تحویل بده؛ تلاش کردم تیمی بسازم که با من فکر کنند، تصمیم بگیرند، و رشد کنند.ساختن یعنی معنا دادن، نه فقط برنامه‌ریزیوقتی میگیم "ساختن"، شاید بعضی‌ها تصور کنند از ساختن ساختمان ده‌طبقه حرف می‌زنم. اما گاهی ساختن یعنی چادر زدن، یعنی شروع از هیچ.برای من، ساختن یعنی معنا دادن؛ یعنی بدون اینکه فریاد بزنم "باید برسیم"، بتونیم بگیم "چرا باید برسیم".هر عضوی که به تیم اضافه می‌شد، برایش توضیح می‌دادم که چرا این تیم وجود دارد، چه ارزشی قرار است خلق شود، و چگونه قرار است دو سال آینده‌مان را بسازیم. برای من مهم بود که آدم‌ها فقط در تیم «باشند» نه برای اجرا، بلکه برای ساختن.تیم برای خلق ارزش، نه فقط برای اجرااز اول دغدغه‌ام تحویل وظایف نبود. دنبال این بودم بفهمم کسی که وارد تیم می‌شود، چقدر با فکر من هم‌مسیر است؟ چقدر می‌تواند در کنارم باشد، نه فقط در مقابل تسک‌ها، بلکه در مسیر ساختن.بخشی از مسائل فنی را خودم کمک می‌کردم؛ اما مسئله‌ام فنی نبود، انسانی بود. تیم قرار بود صرفاً برای سازمان کار نکند، بلکه برای خودش، برای رشد، برای ساختن چیزی بزرگ‌تر از خودش معنا پیدا کند.ساختار درست قدردانی و فیدبکقدردانی، تشکر و فیدبک برای من جزئی از ساختار تیم بود، نه کارهای جانبی.بارها پیش آمد که در سکوت، فقط یک جمله می‌گفتم:"دیدم چقدر تلاش کردی. شاید کامل نبود، ولی مسیرت درسته . ادامه بده، من کنارت هستم."فیدبک فقط اصلاح مسیر نیست. فیدبک یعنی همراهی. یعنی دیدن تلاش، نه فقط نتیجه.در مسیر رشد، کنار هم ایستادنقبلاً فکر می‌کردم آدم‌ها باید زیر فشار رشد کنند.(جمله معروفی که تو باید رشد کنی :)) )من همیشه میگفتم تو چرا رشد نمیکنی ؟ چرا نمیخوای رشد کنی ؟ بشین این کارو بکن این دوره رو برو این کتاب بخون.اشتباه بود فهمیدم و زودم فهمیدم.امروز فهمیدم رشد با فشار اتفاق نمی‌افتد، با حمایت، با امنیت، با درک متقابل اتفاق می‌افتد.وقتی اشتباهی دیدم، تلاش نکردم فشار بیارم؛ تلاش کردم کنار آدم بایستم و بگم:"این تجربه منه . اگر می‌خواهی رشد کنی، من کنارت هستم. تصمیم با توست.در مسیر همراهیت میکنم"این همدلی و همراهی، ریشه‌ای‌ترین بخش رشد واقعی در تیم شد.معنا دادن به‌جای فشار آوردنمن به جای اینکه چیزی را فشار بدم که به نتیجه برسه، سعی کردم یاد بدم که چرا باید برسه.وقتی آدم‌ها بفهمند چرا کاری مهم است، چرا مسیری ارزش دارد، خودشان جلو میرن — نه با ترس، بلکه با انگیزه.حالا همیشه هم اینطور نیست خیلی فکر نکنید چه خبر بوده تو تیم و فضا چقدر عرفانی بوده =))خلق انگیزه درونی، قوی‌تر از هر پیگیری بیرونیه. برای همین سعی کردم همیشه سؤال را بسازم، نه اجبار رو .ساختن با صداقت، اما نه همیشه با پاسخدر تمام این مسیر، تلاش کردم با صداقت جلو بروم. رابطه انسانی بسازم.اما گاهی هم، با تمام شفافیت و صداقت، بازخوردی که گرفتم خنثی بود. نه همراهی، نه مخالفت. فقط سکوت.و این شاید سخت‌ترین بخش رهبری بود. جایی که فهمیدم:قرار نیست همیشه برای هر صداقتی، پاسخی هم‌سطح بگیری.بعضی وقت‌ها باید بسازی، حتی اگر هنوز نشانه‌ای از تاثیرش ندیدی.جمع‌بندیساختن تیم، از نظر من یعنی ساختن فضای معنا، رشد، و انسانیت.اگر تیمی فقط برای اجرا شکل بگیرد، دیر یا زود می‌پاشد. اما اگر برای خلق ارزش، برای باهم‌بودن، برای رشد مشترک ساخته شود، می‌تواند حتی فراتر از یک سازمان برود.من هنوز در مسیرم. تیمم هم هنوز در حال ساختن است.این روزها که دارم اینو مینویسم دارم از نوع میسازم.اما امروز بیشتر از همیشه مطمئنم که:تیم، فقط برای تحویل کار نیست.تیم، یعنی جایی که انسان‌ها جمع می‌شوند تا باهم چیزی بزرگ‌تر از خودشان را بسازند.اگر می‌خواهی تیمی بسازی که فقط کار نکند، بلکه اثر بگذارد، از ساختن معنا شروع کن — نه فقط ساختن ساختار.مسعود شریفی پورمسعود شریفی پورWed, 09 Jul 2025 12:28:59 +0330https://virgool.ir/@masoudsharifi/commitment-tittli5gjkmzدر دنیایی که هر روز ابزارهای جدیدی معرفی میشن، تکنولوژی با سرعت سرسام‌آوری رشد می‌کنه، و رقابت برای تحویل سریع‌تر و ارزان‌تر شدت گرفته، یک چیز انگار داره کمرنگ‌تر میشه: تعهد.منظورم فقط تعهد به انجام وظیفه نیست. اتفاقاً من در سال‌های اخیر آدم‌هایی زیادی دیدم که کارشون رو انجام میدن. اما چیزی که جاش خالیه ، تعهدی از یه جنس دیگس: تعهد به ساختن. تعهد به اجرا کافی نیستما معمولاً در نقش‌های فنی و مدیریتی، از تیم‌ها «تحویل» می‌خواهیم. می‌پرسیم: این تسک کی آماده میشه؟ این فیچر کی می‌ره روی پروداکشن؟ و گاهی با ددلاین و فشار، به اجرا تعهد می‌سازیم. اما این مدل از تعهد، اگرچه لازم است، کافی نیست.تعهد به اجرا یعنی من وظیفه‌ام را انجام می‌دهم، چون قراری گذاشته‌ایم، یا چون قرارداد داریم. اما این تعهد، سطحی‌ترین شکل مشارکت است.تعهد به ساختن یعنی چی؟تعهد به ساختن یعنی:من فقط کدی که بهم سپرده شده نمی‌نویسم، بلکه به این فکر می‌کنم که این سیستم چطور باید رشد کنه.من فقط یه تسک رو تحویل نمی‌دم، بلکه حواسم به آدم‌هایی هست که دارن این مسیر رو با من میان.وقتی کسی کاری رو بلد نیست، به‌جای قضاوت، بهش کمک می‌کنم یاد بگیره.رشد آدم‌ها، هم‌تیمی‌ها و حتی خودم، برام یه وظیفه‌ست، نه لطف.تعهد به ساختن یعنی بفهمیم مسئولیت ما فقط روی خروجی نیست، بلکه روی آدم‌هایی هم هست که قراره اون خروجی رو خلق کنن.نقش رهبری در ساختن تعهدرهبران واقعی نه با زور، نه با ترس، بلکه با الهام دادن و معنا بخشیدن به کار، تعهد ایجاد می‌کنن.رهبری یعنی: اول خودت متعهد باشی و بعد از دیگران انتظارش رو داشته باشی. تیم رو فقط مدیریت نکنی، بلکه هدایتش کنی. به جای تمرکز روی کنترل، روی اعتماد سرمایه‌گذاری کنی.یک رهبر باید شعلهٔ انگیزه را در دل تیم روشن نگه داره. باید چشم‌اندازی ترسیم کنه، که تیم بخواد با انگیزه به سمتش حرکت کند. چون تعهد واقعی از درون به جوش میاد، نه اینکه از بیرون تحمیل بشه. ما باید تعهد رو آموزش بدیمشاید یکی از اشتباه‌های رایج اینه که فکر می‌کنیم آدم متعهد خودش باید این ویژگی رو داشته باشه. اما مثل هر مهارت دیگه‌ای، تعهد هم آموختنیه. تعهد با فشار و چک‌لیست ساخته نمی‌شه، با الگو بودن، گفتگو، اعتماد و فضای رشد ساخته میشه.باید به آدم‌ها یاد بدیم که متعهد بودن فقط یه ویژگی شغلی نیست؛ یه ویژگی انسانیه. کسی که در زندگی شخصی‌اش آدم متعهدیه، در تیم هم همینه. برعکسش هم صادقه.ما باید نشون بدیم که تعهد داشتن فقط به مدیر پروژه نیست، به خودته، به هم‌تیمیهات، به چیزی که می‌سازیم، به کاربر نهایی، به آینده.اشتباه مرگبار: تلاش برای ساختن آدم‌هایی شبیه خودمونحتماً شنیدید یا خودتون گفتید: اگه یکی مثل خودم داشتم، همه چی حل بود!این جمله اگر کنترل نشه، به یکی از سمی‌ترین باورها تبدیل میشه. چون ما ناخودآگاه شروع می‌کنیم به مقایسه کردن دیگران با خودمون. کسی که مثل ما فکر نمی‌کنه، کسی که کندتره، کسی که سبک یادگیری متفاوتی داره، به چشم "ضعیف" دیده میشه.اما ما قرار نیست آدم‌هایی مثل خودمون بسازیم. ما قراره به آدم‌ها کمک کنیم نسخهٔ بهتری از خودشون باشن. نه کپی ما. نه تکرار ما. چون تیمی که همه شبیه ما باشن، رشد نمی‌کنه. تیم واقعی، تیمیه که توش تفاوت هست، ولی تعهد مشترکه. ساختن یعنی روشن کردن مسیراگر قراره تعهد به ساختن جا بیفته، باید مسیر رو روشن کنیم. تیم باید بدونه قراره چی بسازه. باید حس کنه بخشی از اون ساختنه. وقتی آدم‌ها ندونن خروجی کارشون به کجا ختم میشه، یا حس نکنن کاری که می‌کنن معنا داره، دلیلی برای متعهد بودن نمی‌مونه.تعهد یعنی بگیم:این کاری که داریم انجام می‌دیم، فقط یه فیچر نیست، یه قدم به سمت آینده‌ست.این تکه از کد، ممکنه فقط چند خط باشه، ولی روی تجربهٔ هزاران کاربر تأثیر می‌ذاره.تو فقط مسئول تحویل نیستی، مسئول ساختنی.تعهد، انگیزه‌ای برای بهتر بودنآدم‌هایی که تعهد به ساختن دارند، معمولاً درونی‌ترین انگیزه‌ها رو دارن. اون‌ها از تغییر نمی‌ترسن، بلکه به استقبالش میرن. چون می‌دونن قراره چیزی بهتر خلق کنن؛ برای خودشون، تیمشون، و دنیا.اگر می‌خوای پیشرفت کنی، اول از خودت بپرس:من به چی متعهدم؟ آیا فقط برای گذروندن روزها کار می‌کنم؟ یا برای ساختن چیزی که ارزش بموندن داشته باشه؟پایان: تعهد به ساختن یعنی تعهد به انسان بودناگر قراره نرم‌افزار بسازیم، باید اول آدم بسازیم. آدم‌هایی که بلدن به خودشون متعهد باشن، به تیمشون، به چیزی که خلق می‌کنن.تعهد به ساختن، یعنی ساختن تیم‌هایی که فقط برای زنده موندن کد نمی‌زنن، بلکه برای معنا دادن به کارشون تلاش می‌کنن. تیم‌هایی که اگر روزی از هم جدا بشن، چیزی که بینشون ساخته شده باقی می‌مونه: احترام، رشد، انسانیت.و این، چیزی نیست که با ددلاین به‌دست بیاد. این، فقط با تعهد ساخته میشه.یک نکتهٔ مهم و شاید کمی شخصی:کلمهٔ تعهد خودش ترسناک هم هست. چون بار مسئولیت زیادی داره. چون گاهی ما رو یاد محدودیت می‌ندازه. یاد ترس از شکست، ترس از قضاوت، ترس از خالی شدن.ولی این دقیقاً همون‌جاییه که باید صادق باشیم: تعهد واقعی، اول از همه با خودمون شروع میشه. و این یعنی گاهی لازمه از خودمون بپرسیم:آیا من آماده‌ام که به چیزی متعهد باشم که هنوز کامل نیست؟ به تیمی که هنوز جا برای رشد داره؟ به محصولی که هنوز در ابتدای راهه؟تعهد همیشه زیبا نیست، اما همیشه اصیله.و این نوشته هم، شاید بیشتر از اونکه یه توصیه باشه، یه یادآوری برای خودم بود. یه پنج‌دقیقه‌ی دونفره‌ی ذهنی، بین من و کسی که داره اینو می‌خونه.مسعود شریفی پورمسعود شریفی پورTue, 06 May 2025 11:35:36 +0330