https://virgool.io/feed/@masoudsharifi masoudsharifipour.ir fa 2026-06-17 03:13:40 https://files.virgool.io/upload/users/195953/avatar/2FzYuT.png?height=120&width=120 https://virgool.io/@masoudsharifi https://virgool.io/@masoudsharifi/%D8%A7%DA%AF%D8%B1-%D8%AA%DB%8C%D9%85-%D9%85%D8%A7-%D8%B1%D8%B3%D8%AA%D9%88%D8%B1%D8%A7%D9%86-%D8%AF%D8%A7%D8%B4%D8%AA-p1wqh9zldaxm در دنیای نرم‌افزارها، همه‌چیز قرار بود ساده‌تر، سریع‌تر و قابل‌فهم‌تر باشه. اما به نظر می‌رسه هر روز بیشتر از کاربر واقعی فاصله می‌گیریم. توی بعضی تیم‌های محصول و طراحی، تمرکز دیگه روی حل مسئله نیست — روی ساخت «چیزی باحال» یا «قابل ارائه» توی پرزنت بعدیه.برای اینکه بدونیم بعضی از تصمیم‌هایی که می‌گیریم چقدر می‌تونن از واقعیت دور، بی‌منطق یا حتی خنده‌دار باشن، بیاید ی استعاره براتون بگم:اگر تیم ما به جای ساختن محصول، یه رستوران راه می‌نداخت، چی می‌شد؟KPISما برای کی طراحی می‌کنیم؟هر تیم محصولی، یه جایی باید این سؤال رو از خودش بپرسه:"ما دقیقاً داریم برای کی طراحی می‌کنیم؟"برای کاربری که نیاز داره یه مسئله رو ساده حل کنه؟یا برای اسلاید گزارش ماهانه؟یا شاید برای سلیقه مدیرمون یا مدیرعامل، که عاشق فیچرهای پیچیده‌ست؟وقتی کاربر واقعی از میز تصمیم‌گیری حذف می‌شه، اتفاقات عجیب و گاهی مسخره‌ای می‌افته — تصمیم‌هایی که اگه توی دنیای واقعی اجرا بشن، احتمالاً خودمون هم بهشون می‌خندیم.برای درک بهتر این ماجرا، بیاید این استعاره رو جدی بگیریم:تصور کنید تیم محصول ما یه رستوران افتتاح کرده...اگر تیم ما رستوران داشت...صحنه اول: ورود مشتری = ثبت‌نام اجباری!مشتری وارد رستوران می‌شه. گرسنه‌ست. دنبال یه غذای ساده‌ست.ولی مسئول پذیرش با لبخند می‌گه:«سلام! قبل از هرچیز لطفاً فرم ثبت‌نام رو پر کنید. بعدش می‌تونید منو رو ببینید.»مشتری: «من فقط یه میرزاقاسمی می‌خوام!»مسئول: «درک می‌کنم، ولی ما سیاست‌های تجربه مشتریمون اینطوریه. ایمیل، شماره موبایل، نوع گوشی و محل سکونت لطفاً!»بعد از کلی فرم و OTP و تأییدیه، تازه وارد سالن می‌شه.صحنه دوم: دیدن منو فقط با اشتراک!مشتری می‌پرسه: «خب حالا چی دارید؟»گارسون: «بستگی داره! شما توی کدوم پلن هستید؟»پلن رایگان: نون تست و آب ولرمپلن نقره‌ای: سوپ بدون افزودنیپلن طلایی: غذاهای اصلی، با نوبت سه‌روزهپلن VIP: غذای داغ، میز پنجره، بدون تبلیغ!مشتری: «من فقط یه غذا می‌خوام. این همه پیچیدگی چرا؟»گارسون: «شما آزادی انتخاب دارید :)»صحنه چهارم: لغو اشتراک؟ فراموشش کن!بعد از اولین وعده، مشتری تصمیم می‌گیره که دیگه نیاد.ولی وقتی می‌خواد اشتراک رو لغو کنه:باید دلیل لغو رو بنویسهاز فرم پشتیبانی استفاده کنهمنتظر بررسی بشهو تا پایان ماه همچنان پول بده!گارسون با افتخار می‌گه:«ما خروج سخت طراحی کردیم تا نرخ از دست دادن شما بره بالا :)»صحنه پنجم: تیم محصول از خودش راضیه!پشت‌صحنه این رستوران، تیمی نشسته که غرق در آمار و نمودارهای رشدن:نرخ ثبت‌نام: ۷۳٪ رشدتعامل با منو: ۴۸٪ افزایشنرخ ماندگاری ماه اول: بالاتر از حد میانگین!اما هیچ‌کس نمی‌پرسه:آیا کسی واقعاً سیر شد؟ آیا کسی راضی بود؟مشکل از کجاست؟حالا بیاید از این استعاره برگردیم به واقعیت. چرا چنین رفتارهایی توی تیم‌های محصول شکل می‌گیره؟ چرا بعضی تیم‌ها از کاربر جدا می‌شن و به سمت تصمیم‌هایی می‌رن که از بیرون مسخره به‌نظر می‌رسن؟۱. چون KPI از کاربر مهم‌تر شدهوقتی معیار موفقیت، فقط عدد باشه (مثل ثبت‌نام، نرخ فعال‌سازی)، دیگه تجربه انسانی گم می‌شه.۲. چون طراحی با پرزنت اشتباه گرفته شدهفیچرهایی ساخته می‌شن که فقط «توی اسلاید» جذابن، نه در استفاده‌ی واقعی.۳. چون خودمون دیگه کاربر نیستیمما به محصول عادت می‌کنیم. پیچیدگی‌ها برامون عادی می‌شن. اما یه کاربر تازه؟ فقط گیج می‌شه.۴. چون خروج کاربر، تهدید تلقی می‌شهبه‌جای اینکه بفهمیم چرا کاربر می‌ره، مسیر رفتنش رو سخت می‌کنیم. این یعنی ترس از واقعیت.ویلای بدون در | یک استعاره ساده برای درک تجربه کاربرفرض کنید شما یه تیم طراحی و محصول هستید که با کلی انرژی، هزینه، و خلاقیت، یک ویلا طراحی کردید.همه چیز فوق‌العاده‌ست:نور زیاد و طبیعیطراحی داخلی چشم‌نوازمبلمان عالی، امکانات رفاهی کاملفضای باز برای استراحت، منظره بی‌نظیراز بیرون که نگاه می‌کنید، واقعاً به خودتون افتخار می‌کنید:«چه محصولی ساختیم! واقعاً کامل و زیباست.»اما یک چیز کوچک رو فراموش کردید:درِ ورودی ویلا وجود نداره.کاربر باید برای ورود به این ویلای رویایی، از روی دیوار بالا بره.باید نردبون پیدا کنه. شاید به کمک کسی نیاز داشته باشه.شاید اصلاً زورش نرسه.یا حوصله‌ش نکشه.یا همون اول منصرف بشه و بره.و حالا سؤال مهم:شما به‌عنوان طراح این ویلا، کِی آخرین بار از بیرون، از توی کوچه، وایسادید و سعی کردید وارد بشید؟اصلاً تست کردید مسیر ورود چقدر راحته؟ یا فقط محو زیبایی داخل ویلا شدید؟تجربه کاربری همینه.ممکنه اپلیکیشن شما ده‌ها قابلیت عالی داشته باشهممکنه طراحی UI شما بی‌نقص باشهممکنه حتی سیستم هوش مصنوعی پشت محصول کار خفن انجام بدهاما اگه کاربر نتونه به راحتی وارد بشه، ثبت‌نام کنه، شروع کنه، یا بفهمه چطوری استفاده کنه — همه اون ویژگی‌ها بی‌فایده‌ست.گاهی باید بیایم توی کوچه وایسیم.گاهی باید از زاویه‌ی دید کاربر، از جایی که هیچ‌چی درباره ما نمی‌دونه، به محصول‌مون نگاه کنیم:اگه من الان برای اولین بار اومدم اینجا، چی می‌بینم؟می‌تونم بدون گیج شدن وارد بشم؟مسیر ورود من مثل دره یا دیواره؟کار طراحی، فقط ساختن فضای داخلی نیست — ساختن مسیر ورود، حتی مهم‌تره.جمع‌بندی این بخش:کاربر اول باید وارد ویلا بشه، بعد حالش از دیدن منظره خوب می‌شه.اگه نتونه بیاد تو، فرقی نمی‌کنه شما تو ویلا چی گذاشتید.بیاید هر از چند وقت، از محصولمون بیایم بیرون.تو کوچه بایستیم.از صفر سعی کنیم واردش بشیم.شاید متوجه بشیم...ما درِ محصولمون رو فراموش کردیم.نتیجه‌گیری: کاربر، گرسنه‌ست — ما باید غذا بدیم، نه فرم ثبت‌نام!تجربه کاربری خوب، مثل غذای خوبه.نباید نیاز به راهنما، پلن اشتراک، یا پشتیبانی برای فهمش باشه.ما محصول نمی‌سازیم برای KPI.ما محصول می‌سازیم برای یک انسان واقعی، با یک نیاز واقعی، که باید بدون دردسر، به یک راه‌حل ساده و انسانی برسه.بیاید تجربه رو ساده کنیم.انسانی طراحی کنیم.و هیچ‌وقت فراموش نکنیم:رضایت، از سادگی میاد؛ نه از پیچیدگی‌هایی که کاربر رو گم می‌کنن. مسعود شریفی پور مسعود شریفی پور Wed, 31 Dec 2025 17:18:36 +0330 https://virgool.io/@masoudsharifi/%D8%A2%DB%8C%D8%A7-%D8%A8%D8%A7-%D9%88%D8%AC%D9%88%D8%AF-ai-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%A7%D9%86%D8%AA%D8%B8%D8%A7%D8%B1-%D8%A8%D9%87%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%A7%D9%84%D8%A7-%D8%B1%D8%A7-%D8%AF%D8%A7%D8%B4%D8%AA-gtf53hhqeswi ما امروز در دنیای فناوری و مهندسی، شاهد موجی تازه از هیجان هستیم؛ موجی که نامش «هوش مصنوعی» است. سازمان‌ها این موج را می‌بینند و احساس می‌کنند اگر بخواهند عقب نمانند، باید سوارش شوند. وعده‌های هوش مصنوعی وسوسه‌انگیز است: سرعت بیشتر، کیفیت بهتر، و تصمیم‌گیری دقیق‌تر. طبیعی است که همه انتظار داشته باشند این فناوری به‌طور مستقیم به افزایش بهره‌وری منجر شود.اما واقعیت کمی پیچیده‌تر است. ما در حال ورود به یک نسل جدید از کار و همکاری هستیم؛ نسلی که صرفاً جایگزین نسل قبلی نمی‌شود، بلکه نیاز به یادگیری، جذب، و پرورش دارد. پرسش مهم اینجاست: آیا نیروهای قدیمی‌تر و ساختارهای تثبیت‌شده می‌توانند با این موج جدید سازگار شوند و خودشان را بازتعریف کنند؟از نگاه من، بله—ما باید انتظار بهره‌وری بالاتر را داشته باشیم. اما این بهره‌وری همیشه به معنای تولید بیشتر یا کارهای کاملاً جدید نیست؛ گاهی همان کارهای گذشته را سریع‌تر و با کیفیت بهتر انجام می‌دهیم، و در نتیجه زمان آزاد بیشتری برای توسعه ویژگی‌های نو، کدهای بهتر یا حتی رویکردهای تازه به‌دست می‌آوریم.به بیان ساده: هوش مصنوعی موتور افزایش بهره‌وری است، اما برای روشن شدن این موتور، نسل جدیدی از مهارت‌ها و ذهنیت‌ها را باید بپذیریم و پرورش بدیم.بهره‌وری در عصر هوش مصنوعی — بازتعریف، فرصت و ریسکبهره‌وری همچنان مفهوم «خروجی بر ورودی» را داره، اما در اقتصاد دانشی امروز باید ابعاد دیگری هم به آن اضافه کنیم: سرعت تصمیم‌گیری، کیفیت تصمیم، توان حل مسئله و ظرفیت خلق نوآوری. هوش مصنوعی در این ابعاد تأثیر عمیق میزاره — سرعت انجام کارها را بالا می‌بره، کیفیت تحلیل‌ها را ارتقا میده و گاهی ظرفیت یک فرد را به اندازه دو نفر زیاد می‌کند.وقتی یک نفر با کمک AI بتونه کار دو نفر را انجام بده، احتمال دارد فشار روی ساختارهای سازمانی برای کاهش نیرو یا بازطراحی سریع نقش‌ها افزایش پیدا کنه. اگر افراد نتونن خودشون رو در تعریف جدید نقش‌ها ببینند — یعنی نگیرند که «من هنوز برای این کار ارزش دارم» — این تکنولوژی برای آن‌ها دردسرساز میشه، نه فرصت. بنابراین بهره‌وریِ واقعی تنها حاصلِ تواناییِ ابزار نیست؛ حاصلِ سازگاریِ انسان‌ها، بازتعریف نقش‌ها و پرورشِ نسل جدیدی از مهارت‌هاست.نظره مسعود : باید انتظار افزایش بهره‌وری داشت، ولی این افزایش خودکار و بدون هزینه اجتماعی نیست. اگر سازمان‌ها صرفاً سرعت را بالا ببرند بدون اینکه نقش‌ها، آموزش و سیاست‌های حمایتی را بازسازی کنند، نتیجه می‌تواند تعدیل نیرو و نابرابری بیشتر باشد — نه بهره‌وری پایدار.از اینترنت تا هوش مصنوعی؛ تکرار یک موج تاریخی با تفاوت‌های تازهدر ابتدای دهه ۲۰۰۰، ورود اینترنت به زندگی روزمره و محیط‌های کاری یک «عصر تازه» را رقم زد. سرعت دسترسی به اطلاعات افزایش یافت، ارتباطات جهانی شد و مدل‌های کسب‌وکار سنتی دگرگون شدند. بسیاری از سازمان‌ها تلاش کردند از این موج بهره‌وری بسازند؛ بعضی موفق شدند و بعضی دیگر جا ماندند. نگاهی به همان دوران نشان می‌دهد که چگونه شرکت‌های نوپایی مانند آمازون، گوگل و فیسبوک توانستند ارزش‌های میلیارددلاری خلق کنند، در حالی که بسیاری از غول‌های سنتی یا نابود شدند یا به حاشیه رانده شدند.امروز، هوش مصنوعی در جایگاهی مشابه قرار دارد. همان‌طور که اینترنت فرصت‌های بی‌سابقه‌ای برای خلق ارزش به وجود آورد، AI هم می‌تواند دریچه‌ای تازه به روی نوآوری و بهره‌وری باز کند. تفاوت اما در سرعت تغییرات است: اگر اینترنت در یک بازه ۱۰ تا ۱۵ ساله توانست صنایع مختلف را متحول کند، هوش مصنوعی تنها در چند سال اخیر بسیاری از بخش‌ها را زیر و رو کرده است.با این حال، همان‌طور که اینترنت تنها برای سازمان‌هایی ارزش آفرید که توانستند مدل‌های کسب‌وکارشان را بازتعریف کنند، AI نیز فقط برای سازمان‌هایی سودمند خواهد بود که به جای افزودن یک ابزار روی ساختار قدیمی، فرآیندها و نقش‌ها را متناسب با این موج بازطراحی کنند.من اگر بخوام نظرمو بگمدرست مثل اینترنت، هوش مصنوعی هم هم‌زمان فرصت و تهدید است.سازمان‌هایی که فقط به کاهش هزینه‌ها یا تعدیل نیرو فکر کنند، بهره‌وری کوتاه‌مدت می‌گیرند ولی مزیت رقابتی بلندمدت را از دست خواهند داد.در مقابل، کسانی که نگاهشان به خلق ارزش‌های جدید باشد — محصول تازه، تجربه بهتر مشتری، مدل‌های کسب‌وکار نو — می‌توانند «آمازون» یا «گوگل» نسل AI شوند.در نهایتهوش مصنوعی یک امکان فوق‌العاده برای افزایش بهره‌وریه، اما هیچ تضمینی برای تحقق آن وجود نداره. تفاوت اصلی میان سازمان‌هایی که از AI بهره‌وری واقعی می‌گیرند و اونهایی که فقط اسیر «مد روز» میشن، در نحوه به‌کارگیری این فناوری پنهان شده.در نهایت، بهره‌وری آینده بیشتر از آنکه وابسته به خود تکنولوژی باشه، وابسته به انسان‌ها، فرهنگ سازمانی و توانایی تطبیق ما با تغییراته. پرسشی که باقی میمونه این هستش که:آیا ما آماده‌ایم از این ابزار برای ساخت آینده‌ای بهره‌ورتر استفاده کنیم، یا فقط سرعت درجا زدنمون بیشتر کرده‌ایم؟ مسعود شریفی پور مسعود شریفی پور Sun, 19 Oct 2025 10:19:05 +0330 https://virgool.io/@masoudsharifi/%D8%A8%D9%87-%D8%AC%D8%A7%DB%8C-%DA%86%D9%82%D8%AF%D8%B1-%D8%B7%D9%88%D9%84-%D9%85%DB%8C-%DA%A9%D8%B4%D9%87-%D8%A8%D9%BE%D8%B1%D8%B3%DB%8C%D9%85-%DA%86%DB%8C-%D9%82%D8%B1%D8%A7%D8%B1%D9%87-%D8%A8%D8%B3%D8%A7%D8%B2%DB%8C%D9%85-qzidwogja08e در دنیای توسعه محصول، یکی از رایج‌ترین سؤالاتی که تیم‌ها با آن روبه‌رو میشن اینه که:«این تسک چقدر زمان می‌بره؟»در ظاهر، سؤال بی‌خطری به نظر می‌رسه. اما پاسخ‌دادن سریع و بدون زمینه، معمولاً ما را وارد چرخه‌ای از توقعات اشتباه، استرس، و بازنگری‌های پرهزینه می‌کنه.مشکل از جایی شروع میشه که ما به جای درک واقعی از مسئله، به‌سرعت وارد فاز برنامه‌ریزی می‌شویم. در حالی که اغلب، هنوز دقیق نمیدونیم چی میخوایم:چه چیزی قرار است ساخته شود؟با چه موانعی روبه‌رو هستیم؟و اصلاً این تسک، در کجای مسیر رشد محصول قرار می‌گیرد؟به‌جای تخمین زدن، ابتدا بفهمیمما نیاز داریم پیش از برنامه‌ریزی، ابتدا «سطح درک تیم» از مسئله را بسنجیم. آیا تیم آمادهٔ تخمین‌زدن هست؟ یا هنوز باید کشف یا بررسی بیشتری انجام بشه؟در تجربهٔ ما، اغلب تسک‌ها در یکی از این سه دسته قرار می‌گیرند:1. تسک‌هایی که می‌توان دقیق تخمین زد:مشکل و راه‌حل روشن است.تیم با دامنه آشناست.وابستگی‌ها و ریسک‌ها کم است.مثال: اصلاح یک باگ در سیستم شناخته‌شده.2. تسک‌هایی که نمی‌توان فعلاً تخمین زد:هنوز هدف مبهم است.تکنولوژی جدید است.نیاز به هماهنگی بیرونی دارد.مثال: طراحی یک سیستم قیمت‌گذاری جدید برای فروش محصول تازه لانچ شده.3. تسک‌هایی که فاز اول آن‌ها، فقط برای تخمین‌زدن است:نیاز به Discovery دارد.قرار است ابتدا نمونه‌سازی یا تحلیل اولیه انجام شود.مثال: بررسی امکان پشتیبانی از یک نوع جدید پرداخت با تأمین‌کنندهٔ خارجی.درک، پایهٔ اعتماد استوقتی به‌جای فشار برای عدد دادن، به تیم کمک کنیم که «درک» خود را از مسئله بسنجند، دو اتفاق خوب میفته:تصمیم‌گیری‌ها دقیق‌تر می‌شود، چون دید ما واقعی‌تر است.تیم احساس امنیت و مشارکت بیشتری می‌کند، چون از او توقع حدس‌زدن بی‌پشتوانه نداریم.مثال واقعیفرض کنیم تیم قراره ویژگی «پشتیبانی از پلن پرداخت اقساطی» رو به پلتفرم اضافه کنه. در ظاهر، این فقط اضافه‌کردن یک گزینه جدید در فرم پرداخت به نظر می‌رسه. اما وقتی با دید درک عمیق‌تر جلو بریم، متوجه می‌شیم:وضوح هدف پایین: هنوز دقیق نمی‌دونیم اقساط قراره چطور محاسبه بشن. آیا سود داره؟ بازه‌هاش چطوریه؟وابستگی فنی بالا: نیاز به اتصال به درگاه بانکی جدید یا شرکت اعتبارسنجی هست.نیاز به هماهنگی بیرونی: تیم حقوقی باید قوانین جدید قراردادها رو بررسی کنه.آشنایی پایین: تیم قبلاً روی چنین قابلیتی کار نکرده.هماهنگی بین‌تیمی: تیم‌های مالی، مارکتینگ و پشتیبانی هم باید در جریان تغییرات باشن.نتیجه؟این تسک در ابتدا قابل تخمین نیست. ما نیاز به یک فاز کشف (Discovery) داریم:جمع‌آوری نیازمندی‌ها از تیم حقوقی و مالیبررسی محدودیت‌های فنی در اتصال به API جدیدطراحی اولیه تجربه کاربریسنجش پیچیدگی اجرا با کمک مهندسی فنیبعد از این مرحله، تازه می‌تونیم بفهمیم واقعاً چقدر کار داریم، و آیا تخمین دقیق ممکنه یا نه.جمع‌بندیما معمولاً میدونیم که هر تسکی یکی از سه حالت زیر را داره:قابل تخمین دقیقغیرقابل تخمین (در حال حاضر)نیازمند فاز اولیه برای کشف و سپس تخمیناگر تیم به این طبقه‌بندی فکر کنه، همکاری‌های واقعی‌تری شکل می‌گیره، توقعات بهتر مدیریت می‌شود و خروجی نهایی باکیفیت‌تر خواهد بود.پرسیدن این سؤال ساده در شروع هر پروژه می‌تواند نقطهٔ تفاوت باشه:«آیا می‌دانیم قراره چی بسازیم؟ یا هنوز باید بفهمیم؟» مسعود شریفی پور مسعود شریفی پور Sun, 27 Jul 2025 11:45:13 +0330 https://virgool.io/@masoudsharifi/%DA%86%D8%B7%D9%88%D8%B1-%D8%AA%DB%8C%D9%85%D9%85-%D8%B1%D8%A7-%D8%B3%D8%A7%D8%AE%D8%AA%D9%85-%D9%86%D9%87-%D9%81%D9%82%D8%B7-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%D8%AD%D9%88%DB%8C%D9%84-%DA%A9%D8%A7%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AE%D9%84%D9%82-%D8%A7%D8%B1%D8%B2%D8%B4-lc5ljrc79bdt در اولین روزهایی که وارد این مسیر شدم، وقتی مسئولیت رو گرفتم، با فضایی روبه‌رو بودم که نیاز به بازتعریف، انسجام و ساختار تازه داشت — جایی که باید تیمی شکل می‌گرفت که نه‌فقط کار انجام بده، بلکه معنا خلق کنه. همه‌چیز باید از اول، از پایه ساخته می‌شد — اما نه فقط برای تحویل کار. برای من، ساختن یعنی خلق ارزش، ساختن فضا، معنا، و مسیر برای رشد.من تلاش نکردم فقط یک تیم جمع کنم که کارها را تحویل بده؛ تلاش کردم تیمی بسازم که با من فکر کنند، تصمیم بگیرند، و رشد کنند.ساختن یعنی معنا دادن، نه فقط برنامه‌ریزیوقتی میگیم "ساختن"، شاید بعضی‌ها تصور کنند از ساختن ساختمان ده‌طبقه حرف می‌زنم. اما گاهی ساختن یعنی چادر زدن، یعنی شروع از هیچ.برای من، ساختن یعنی معنا دادن؛ یعنی بدون اینکه فریاد بزنم "باید برسیم"، بتونیم بگیم "چرا باید برسیم".هر عضوی که به تیم اضافه می‌شد، برایش توضیح می‌دادم که چرا این تیم وجود دارد، چه ارزشی قرار است خلق شود، و چگونه قرار است دو سال آینده‌مان را بسازیم. برای من مهم بود که آدم‌ها فقط در تیم «باشند» نه برای اجرا، بلکه برای ساختن.تیم برای خلق ارزش، نه فقط برای اجرااز اول دغدغه‌ام تحویل وظایف نبود. دنبال این بودم بفهمم کسی که وارد تیم می‌شود، چقدر با فکر من هم‌مسیر است؟ چقدر می‌تواند در کنارم باشد، نه فقط در مقابل تسک‌ها، بلکه در مسیر ساختن.بخشی از مسائل فنی را خودم کمک می‌کردم؛ اما مسئله‌ام فنی نبود، انسانی بود. تیم قرار بود صرفاً برای سازمان کار نکند، بلکه برای خودش، برای رشد، برای ساختن چیزی بزرگ‌تر از خودش معنا پیدا کند.ساختار درست قدردانی و فیدبکقدردانی، تشکر و فیدبک برای من جزئی از ساختار تیم بود، نه کارهای جانبی.بارها پیش آمد که در سکوت، فقط یک جمله می‌گفتم:"دیدم چقدر تلاش کردی. شاید کامل نبود، ولی مسیرت درسته . ادامه بده، من کنارت هستم."فیدبک فقط اصلاح مسیر نیست. فیدبک یعنی همراهی. یعنی دیدن تلاش، نه فقط نتیجه.در مسیر رشد، کنار هم ایستادنقبلاً فکر می‌کردم آدم‌ها باید زیر فشار رشد کنند.(جمله معروفی که تو باید رشد کنی :)) )من همیشه میگفتم تو چرا رشد نمیکنی ؟ چرا نمیخوای رشد کنی ؟ بشین این کارو بکن این دوره رو برو این کتاب بخون.اشتباه بود فهمیدم و زودم فهمیدم.امروز فهمیدم رشد با فشار اتفاق نمی‌افتد، با حمایت، با امنیت، با درک متقابل اتفاق می‌افتد.وقتی اشتباهی دیدم، تلاش نکردم فشار بیارم؛ تلاش کردم کنار آدم بایستم و بگم:"این تجربه منه . اگر می‌خواهی رشد کنی، من کنارت هستم. تصمیم با توست.در مسیر همراهیت میکنم"این همدلی و همراهی، ریشه‌ای‌ترین بخش رشد واقعی در تیم شد.معنا دادن به‌جای فشار آوردنمن به جای اینکه چیزی را فشار بدم که به نتیجه برسه، سعی کردم یاد بدم که چرا باید برسه.وقتی آدم‌ها بفهمند چرا کاری مهم است، چرا مسیری ارزش دارد، خودشان جلو میرن — نه با ترس، بلکه با انگیزه.حالا همیشه هم اینطور نیست خیلی فکر نکنید چه خبر بوده تو تیم و فضا چقدر عرفانی بوده =))خلق انگیزه درونی، قوی‌تر از هر پیگیری بیرونیه. برای همین سعی کردم همیشه سؤال را بسازم، نه اجبار رو .ساختن با صداقت، اما نه همیشه با پاسخدر تمام این مسیر، تلاش کردم با صداقت جلو بروم. رابطه انسانی بسازم.اما گاهی هم، با تمام شفافیت و صداقت، بازخوردی که گرفتم خنثی بود. نه همراهی، نه مخالفت. فقط سکوت.و این شاید سخت‌ترین بخش رهبری بود. جایی که فهمیدم:قرار نیست همیشه برای هر صداقتی، پاسخی هم‌سطح بگیری.بعضی وقت‌ها باید بسازی، حتی اگر هنوز نشانه‌ای از تاثیرش ندیدی.جمع‌بندیساختن تیم، از نظر من یعنی ساختن فضای معنا، رشد، و انسانیت.اگر تیمی فقط برای اجرا شکل بگیرد، دیر یا زود می‌پاشد. اما اگر برای خلق ارزش، برای باهم‌بودن، برای رشد مشترک ساخته شود، می‌تواند حتی فراتر از یک سازمان برود.من هنوز در مسیرم. تیمم هم هنوز در حال ساختن است.این روزها که دارم اینو مینویسم دارم از نوع میسازم.اما امروز بیشتر از همیشه مطمئنم که:تیم، فقط برای تحویل کار نیست.تیم، یعنی جایی که انسان‌ها جمع می‌شوند تا باهم چیزی بزرگ‌تر از خودشان را بسازند.اگر می‌خواهی تیمی بسازی که فقط کار نکند، بلکه اثر بگذارد، از ساختن معنا شروع کن — نه فقط ساختن ساختار. مسعود شریفی پور مسعود شریفی پور Wed, 09 Jul 2025 12:28:59 +0330 https://virgool.io/@masoudsharifi/commitment-tittli5gjkmz در دنیایی که هر روز ابزارهای جدیدی معرفی میشن، تکنولوژی با سرعت سرسام‌آوری رشد می‌کنه، و رقابت برای تحویل سریع‌تر و ارزان‌تر شدت گرفته، یک چیز انگار داره کمرنگ‌تر میشه: تعهد.منظورم فقط تعهد به انجام وظیفه نیست. اتفاقاً من در سال‌های اخیر آدم‌هایی زیادی دیدم که کارشون رو انجام میدن. اما چیزی که جاش خالیه ، تعهدی از یه جنس دیگس: تعهد به ساختن. تعهد به اجرا کافی نیستما معمولاً در نقش‌های فنی و مدیریتی، از تیم‌ها «تحویل» می‌خواهیم. می‌پرسیم: این تسک کی آماده میشه؟ این فیچر کی می‌ره روی پروداکشن؟ و گاهی با ددلاین و فشار، به اجرا تعهد می‌سازیم. اما این مدل از تعهد، اگرچه لازم است، کافی نیست.تعهد به اجرا یعنی من وظیفه‌ام را انجام می‌دهم، چون قراری گذاشته‌ایم، یا چون قرارداد داریم. اما این تعهد، سطحی‌ترین شکل مشارکت است.تعهد به ساختن یعنی چی؟تعهد به ساختن یعنی:من فقط کدی که بهم سپرده شده نمی‌نویسم، بلکه به این فکر می‌کنم که این سیستم چطور باید رشد کنه.من فقط یه تسک رو تحویل نمی‌دم، بلکه حواسم به آدم‌هایی هست که دارن این مسیر رو با من میان.وقتی کسی کاری رو بلد نیست، به‌جای قضاوت، بهش کمک می‌کنم یاد بگیره.رشد آدم‌ها، هم‌تیمی‌ها و حتی خودم، برام یه وظیفه‌ست، نه لطف.تعهد به ساختن یعنی بفهمیم مسئولیت ما فقط روی خروجی نیست، بلکه روی آدم‌هایی هم هست که قراره اون خروجی رو خلق کنن.نقش رهبری در ساختن تعهدرهبران واقعی نه با زور، نه با ترس، بلکه با الهام دادن و معنا بخشیدن به کار، تعهد ایجاد می‌کنن.رهبری یعنی: اول خودت متعهد باشی و بعد از دیگران انتظارش رو داشته باشی. تیم رو فقط مدیریت نکنی، بلکه هدایتش کنی. به جای تمرکز روی کنترل، روی اعتماد سرمایه‌گذاری کنی.یک رهبر باید شعلهٔ انگیزه را در دل تیم روشن نگه داره. باید چشم‌اندازی ترسیم کنه، که تیم بخواد با انگیزه به سمتش حرکت کند. چون تعهد واقعی از درون به جوش میاد، نه اینکه از بیرون تحمیل بشه. ما باید تعهد رو آموزش بدیمشاید یکی از اشتباه‌های رایج اینه که فکر می‌کنیم آدم متعهد خودش باید این ویژگی رو داشته باشه. اما مثل هر مهارت دیگه‌ای، تعهد هم آموختنیه. تعهد با فشار و چک‌لیست ساخته نمی‌شه، با الگو بودن، گفتگو، اعتماد و فضای رشد ساخته میشه.باید به آدم‌ها یاد بدیم که متعهد بودن فقط یه ویژگی شغلی نیست؛ یه ویژگی انسانیه. کسی که در زندگی شخصی‌اش آدم متعهدیه، در تیم هم همینه. برعکسش هم صادقه.ما باید نشون بدیم که تعهد داشتن فقط به مدیر پروژه نیست، به خودته، به هم‌تیمیهات، به چیزی که می‌سازیم، به کاربر نهایی، به آینده.اشتباه مرگبار: تلاش برای ساختن آدم‌هایی شبیه خودمونحتماً شنیدید یا خودتون گفتید: اگه یکی مثل خودم داشتم، همه چی حل بود!این جمله اگر کنترل نشه، به یکی از سمی‌ترین باورها تبدیل میشه. چون ما ناخودآگاه شروع می‌کنیم به مقایسه کردن دیگران با خودمون. کسی که مثل ما فکر نمی‌کنه، کسی که کندتره، کسی که سبک یادگیری متفاوتی داره، به چشم "ضعیف" دیده میشه.اما ما قرار نیست آدم‌هایی مثل خودمون بسازیم. ما قراره به آدم‌ها کمک کنیم نسخهٔ بهتری از خودشون باشن. نه کپی ما. نه تکرار ما. چون تیمی که همه شبیه ما باشن، رشد نمی‌کنه. تیم واقعی، تیمیه که توش تفاوت هست، ولی تعهد مشترکه. ساختن یعنی روشن کردن مسیراگر قراره تعهد به ساختن جا بیفته، باید مسیر رو روشن کنیم. تیم باید بدونه قراره چی بسازه. باید حس کنه بخشی از اون ساختنه. وقتی آدم‌ها ندونن خروجی کارشون به کجا ختم میشه، یا حس نکنن کاری که می‌کنن معنا داره، دلیلی برای متعهد بودن نمی‌مونه.تعهد یعنی بگیم:این کاری که داریم انجام می‌دیم، فقط یه فیچر نیست، یه قدم به سمت آینده‌ست.این تکه از کد، ممکنه فقط چند خط باشه، ولی روی تجربهٔ هزاران کاربر تأثیر می‌ذاره.تو فقط مسئول تحویل نیستی، مسئول ساختنی.تعهد، انگیزه‌ای برای بهتر بودنآدم‌هایی که تعهد به ساختن دارند، معمولاً درونی‌ترین انگیزه‌ها رو دارن. اون‌ها از تغییر نمی‌ترسن، بلکه به استقبالش میرن. چون می‌دونن قراره چیزی بهتر خلق کنن؛ برای خودشون، تیمشون، و دنیا.اگر می‌خوای پیشرفت کنی، اول از خودت بپرس:من به چی متعهدم؟ آیا فقط برای گذروندن روزها کار می‌کنم؟ یا برای ساختن چیزی که ارزش بموندن داشته باشه؟پایان: تعهد به ساختن یعنی تعهد به انسان بودناگر قراره نرم‌افزار بسازیم، باید اول آدم بسازیم. آدم‌هایی که بلدن به خودشون متعهد باشن، به تیمشون، به چیزی که خلق می‌کنن.تعهد به ساختن، یعنی ساختن تیم‌هایی که فقط برای زنده موندن کد نمی‌زنن، بلکه برای معنا دادن به کارشون تلاش می‌کنن. تیم‌هایی که اگر روزی از هم جدا بشن، چیزی که بینشون ساخته شده باقی می‌مونه: احترام، رشد، انسانیت.و این، چیزی نیست که با ددلاین به‌دست بیاد. این، فقط با تعهد ساخته میشه.یک نکتهٔ مهم و شاید کمی شخصی:کلمهٔ تعهد خودش ترسناک هم هست. چون بار مسئولیت زیادی داره. چون گاهی ما رو یاد محدودیت می‌ندازه. یاد ترس از شکست، ترس از قضاوت، ترس از خالی شدن.ولی این دقیقاً همون‌جاییه که باید صادق باشیم: تعهد واقعی، اول از همه با خودمون شروع میشه. و این یعنی گاهی لازمه از خودمون بپرسیم:آیا من آماده‌ام که به چیزی متعهد باشم که هنوز کامل نیست؟ به تیمی که هنوز جا برای رشد داره؟ به محصولی که هنوز در ابتدای راهه؟تعهد همیشه زیبا نیست، اما همیشه اصیله.و این نوشته هم، شاید بیشتر از اونکه یه توصیه باشه، یه یادآوری برای خودم بود. یه پنج‌دقیقه‌ی دونفره‌ی ذهنی، بین من و کسی که داره اینو می‌خونه. مسعود شریفی پور مسعود شریفی پور Tue, 06 May 2025 11:35:36 +0330