https://virgool.io/feed/@amin.mahmudian توسعه‌دهنده محصول fa 2026-06-17 05:38:18 https://files.virgool.io/upload/users/1201355/avatar/avatar.png?height=120&width=120 https://virgool.io/@amin.mahmudian https://virgool.io/@amin.mahmudian/%D8%B1%D8%B4%D8%AF-%D8%A7%D8%AC%D8%A8%D8%A7%D8%B1%DB%8C-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%A7%D9%86%DB%8C-%DA%A9%D9%87-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%D9%86%DA%A9%D8%B1%D8%AF%D9%87-%D8%A7%D9%86%D8%AF-%D8%A8%DB%8C%D8%B2%DB%8C%D9%86%D8%B3-%D9%87%D8%A7%DB%8C%DB%8C-%DA%A9%D9%87-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%D9%86%D8%B4%D8%AF%D9%87-%D8%A7%D9%86%D8%AF-hlu2fgzz1gbe قطعی اینترنت در ایران دیگر اتفاق عجیبی نیست. تقریبا همه می‌دانیم با هر موج اختلال یا محدودیت دسترسی به سرویس‌های بین‌المللی چه سناریوی تکراری‌ای اجرا می‌شود: کاربران، ناخواسته و از سر اجبار، به سمت نسخه‌های داخلی سرویس‌های آشنا می‌روند. این جابه‌جایی معمولا سریع است، گسترده است و از بیرون، خیلی شبیه یک «فرصت طلایی» برای بیزنس‌های داخلی به نظر می‌رسد.معمولا وقتی درباره قطعی اینترنت حرف می‌زنیم، بحث‌ها می‌رود سمت سیاست، نارضایتی کاربران، یا آسیب‌های اجتماعی و اقتصادی. اما یک اثر دیگر هم هست که کمتر درباره‌اش صحبت می‌شود. اثری که نه خیلی سیاسی است و نه احساسی، بلکه کاملا بیزنسی است. اثری که می‌تواند حتی خود بیزنس‌های داخلی را هم به تصمیم‌های اشتباه بکشاند.در این مقاله قرار است دقیقا روی همین نقطه مکث کنیم، این‌که چرا رشد ناگهانی در دوران قطعی اینترنت، اغلب آن چیزی نیست که به نظر می‌رسد، چطور می‌تواند توهم موفقیت بسازد و یک بیزنس مستقل چطور می‌تواند بدون از دست دادن فرصت، از این موج عبور کند.وقتی رشد، دیگر معنای همیشگی‌اش را ندارددر حالت عادی، وقتی کاربران فعال روزانه (DAU) بالا می‌رود، ثبت‌نام‌ها بیشتر می‌شود یا ترافیک رشد می‌کند، معمولا همه خوشحال می‌شوند. فرض ساده این است که کاربر انتخاب کرده، مانده و احتمالا محصول دارد کارش را درست انجام می‌دهد.اما قطعی اینترنت این رابطه ساده را به‌هم می‌ریزد. در چنین شرایطی، تقریبا همه می‌دانند که دلیل ورود کاربر جدید، خود محصول نیست، بلکه نبود گزینه‌های دیگر است. با این حال، فشار کار، حجم بالای درخواست‌ها و حس اضطراری «الان وقت تصمیم‌گیری است» باعث می‌شود همین واقعیت بدیهی در عمل نادیده گرفته شود.اینجاست که عددها همچنان بزرگ می‌شوند، اما معنایشان عوض می‌شود. داده‌ها دیگر بازتاب کشش واقعی بازار نیستند، بلکه نتیجه یک فشار بیرونی و موقتی‌اند. اگر بیزنسی این تغییر context را در نظر نگیرد، عملا دارد تصمیم‌های بلندمدت را بر اساس داده‌هایی می‌گیرد که برای این نوع تفسیر ساخته نشده‌اند.توهم موفقیت، جایی که داستان خطرناک می‌شودمشکل اصلی این رشدهای اجباری، خود رشد نیست. تفسیر آن است. وقتی در مدت کوتاه تعداد کاربران چند برابر می‌شود، سرورها زیر بار می‌روند و اسم سرویس بیشتر شنیده می‌شود، طبیعی است که این حس ایجاد شود: «بالاخره گرفت!».اما در خیلی از موارد، این فقط یک نشانه کاذب است. عامل رشد، بیرونی و موقتی است، ولی تصمیم‌هایی که بر اساسش گرفته می‌شود، کاملا درونی و بلندمدت‌اند. اسکیل تیم، بالا بردن نرخ مصرف نقدینگی (Burn Rate)، خرج سنگین برای زیرساخت یا حتی رفتن سراغ جذب سرمایه، همه می‌توانند روی داده‌هایی انجام شوند که خیلی زود بی‌اعتبار می‌شوند.وقتی اینترنت برمی‌گردد، بخش بزرگی از این رشد هم برمی‌گردد سر جای اولش. اما هزینه تصمیم‌ها سر جایش می‌ماند.متریک‌ها را چطور ببینیم که گول‌مان نزنند؟در دوره‌های اختلال، بیزنس‌هایی که می‌خواهند سالم بمانند، ناچارند نگاه‌شان به داده را عوض کنند. اینجا دیگر وقت متریک‌گذاری تهاجمی نیست، یعنی تمرکز روی بزرگ‌تر نشان دادن عددها، رشدهای لحظه‌ای و خوش‌بینی بیش از حد. برعکس، این دوره نیازمند متریک‌گذاری دفاعی است، متریک‌هایی که قرار است ما را از تصمیم غلط محافظت کنند، نه این‌که فقط حس خوب بدهند.سؤال مهم در این دوره‌ها این نیست که «چند نفر آمدند»، بلکه این است که «چند نفر ماندند و چرا». این‌که بعد از بازگشت اینترنت، چه درصدی از کاربران همچنان به استفاده ادامه می‌دهند، یکی از مهم‌ترین نشانه‌هاست. این عدد، تخمینی از استفاده‌ای است که از سر اختیار اتفاق افتاده، یعنی کاربری که حالا گزینه‌های دیگر هم دارد، اما باز هم سرویس را نگه می‌دارد.در کنار آن، سرعت و الگوی ریزش کاربران هم معنا‌دار است. اگر بلافاصله بعد از عادی شدن شرایط، کاربران با شیب تند از سرویس خارج شوند، پیامش روشن است: بخش بزرگی از این جذب، صرفا واکنشی به محدودیت بوده. بررسی رفتار کاربران در سطح فیچرها هم اهمیت دارد، مثلا این‌که آیا فقط وارد سرویس شده‌اند یا واقعا از یک ویژگی مشخص و ارزش‌ساز استفاده کرده‌اند.این متریک‌ها معمولا هیجان‌انگیز نیستند، اما دقیقا به همین دلیل نجات‌دهنده‌اند.MVPها و ترافیک انفجاری، فرصتی که می‌تواند بسوزدواقعیت این است که خیلی از سرویس‌های داخلی، به خاطر اقبال محدود کاربران در شرایط عادی، عملا در حد MVP یا کمی فراتر از آن باقی مانده‌اند. این لزوما ایراد نیست، اما وقتی ترافیک ناگهانی وارد می‌شود، می‌تواند به مشکل جدی تبدیل شود.اگر معماری زیرساخت برای Scale آماده نباشد، مثلا دیتابیس‌ها تحمل Connection بالا را نداشته باشند، Queueها به‌درستی تنظیم نشده باشند یا مانیتورینگ و Alerting کافی وجود نداشته باشد یا دیگر دردسترس نباشند، فشار ناگهانی خیلی زود به اختلال می‌رسد. از سمت تیم هم، نداشتن تجربه مدیریت در مقیاس بالا، تصمیم‌گیری را سخت‌تر می‌کند.از طرف دیگر، کاربران جدید که از اول هم با انگیزه قوی نیامده‌اند، اولین تجربه کندی، خطا یا ناپایداری، می‌تواند نه‌تنها باعث خروج‌شان شود، بلکه شانس بازگشت‌شان را حتی بعد از بهبود شرایط از بین ببرد. به این ترتیب، ترافیک اجباری به‌جای این‌که فرصت رشد باشد، می‌تواند تنها فرصت مواجهه با بخش بزرگی از بازار را بسوزاند.مدیریت ترافیک ناگهانی، بدون افتادن در دام اسکیل دائمینکته مهم این است که راه‌حل، نادیده گرفتن این موج نیست. مسئله این است که چطور از آن عبور کنیم، بدون این‌که آن را با رشد پایدار اشتباه بگیریم.در این شرایط، زیرساخت‌های ابری مقیاس‌پذیر اگر درست استفاده شوند، می‌توانند نقش ضربه‌گیر را بازی کنند. Auto-Scaling (مقیاس‌دهی خودکار) با سقف منابع مشخص، بازه زمانی محدود و سیاست بازگشت، کمک می‌کند سرویس Down نشود، بدون این‌که بیزنس به هزینه دائمی قفل شود.هم‌زمان، پذیرفتن افت کنترل‌شده کیفیت معمولاً عاقلانه‌تر از تلاش برای حفظ تجربه ایده‌آل است. کم کردن کیفیت، خاموش کردن موقت قابلیت‌های غیرحیاتی یا صف‌بندی درخواست‌ها شاید خوشایند نباشد، اما خیلی بهتر از فروپاشی کامل سرویس است.در کنار این‌ها، ابزارهایی مثل CDN (Content Delivery Network – شبکه توزیع محتوا)، Cache لایه‌ای و Rate Limiting کمک می‌کنند شوک ترافیک جذب شود و تیم بتواند زمانی برای تصمیم درست، نه اسکیل عجولانه بخرد.externality منفی، هزینه‌ای که در عددها دیده نمی‌شوداگر کمی عقب‌تر بایستیم و در سطح کلان نگاه کنیم، این چرخه یک externality منفی (اثر جانبی منفی) هم ایجاد می‌کند. وجود سرویس‌های داخلی قابل استفاده باعث می‌شود هزینه عملیاتی و اجتماعی قطعی اینترنت، حداقل در ظاهر، کمتر به چشم بیاید. همین موضوع می‌تواند تکرار این تصمیم‌ها را ساده‌تر کند.این به این معنا نیست که بیزنس‌ها آگاهانه در حال همراهی یا سود بردن از این وضعیت‌اند. اما در سطح سیستمی، نتیجه این است که فشار اصلی قطعی اینترنت به‌جای این‌که حل شود، پخش می‌شود. بیزنس‌ها رشد کوتاه‌مدت را تجربه می‌کنند، اما در بلندمدت در اکوسیستمی فعالیت می‌کنند که دسترسی پایدار، رقابت واقعی و امکان نوآوری در آن هر بار سخت‌تر می‌شود.به بیان ساده‌تر، بخشی از هزینه تصمیمی که در سطح کلان گرفته شده، ناخواسته روی دوش همان بیزنس‌هایی می‌افتد که تصور می‌شود «برنده» این وضعیت بوده‌اند.سالم عبور کردن، مهم‌تر از بزرگ شدنرشد ناشی از قطعی اینترنت، اگر درست خوانده نشود، می‌تواند از نبود رشد هم خطرناک‌تر باشد. بیزنس‌هایی که در این شرایط متریک‌ها را با احتیاط تفسیر می‌کنند، اسکیل را مهار می‌کنند و تجربه کاربری را قربانی عددها نمی‌کنند، شاید قهرمان این موج نشوند، اما شانس خیلی بیشتری برای بقا و رشد واقعی در شرایط عادی دارند.در نهایت، رشد واقعی همیشه جایی اتفاق می‌افتد که کاربر حق انتخاب داشته باشد. امین محمودیان امین محمودیان Fri, 23 Jan 2026 15:08:33 +0330 https://virgool.io/@amin.mahmudian/dora-2025-%D8%B3%D9%87-%D8%AF%D8%B1%D8%B3-%D8%A8%D8%B2%D8%B1%DA%AF-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%D8%A7%D9%86-%D9%85%D8%AD%D8%B5%D9%88%D9%84-ugqtr7mcfk9s جشنواره جوایز DORA 2025 گوگل کلود برگزار شد و مثل همیشه پر از نکتههای کاربردی بود. چیزی که برای من جالب بود اینه که با وجود هیاهوی زیاد درباره AI و ابزارهای جدید، پیام اصلی همچنان به سه نکته ساده و بنیادی برمیگرده: هوش مصنوعی مسئولانه، چرخههای کوتاه و فرهنگ تیمی.به عنوان یک مدیر محصول، این سه محور به نظرم ستونهای اصلی هستن برای اینکه محصولی پایدار، باکیفیت و ارزشمند بسازیم. بذارید هر کدوم رو مرور کنیم:۱. هوش مصنوعی باید مسئولانه و نامرئی باشههوش مصنوعی هر روز بیشتر وارد چرخه توسعه نرمافزار میشه. اما چیزی که DORA روی اون تاکید داشت، اینه که AI باید به شکل نامرئی و مسئولانه استفاده بشه؛ یعنی کمککننده باشه بدون اینکه تیمها حس کنن کنترل از دستشون خارج شده. مثال خوبش Wayfair بود. اونها از هوش مصنوعی برای کاهش خطا و تسریع فرآیند تست استفاده کردن و نتیجه این شد که کیفیت محصول بالا رفت بدون اینکه سرعت توسعه قربانی بشه. این نگاه مسئولانه باعث شد AI به جای اینکه یه «فانتزی تکنولوژیک» باشه، واقعا ارزش تجاری تولید کنه.پیام برای ما؟ AI ابزار توانمندسازه، نه جایگزین تیم. باید جوری ازش استفاده کنیم که تیم حس کنه کنترل همچنان دست خودشه.۲. چرخههای کوتاه و انتشارهای کمریسکدرس دوم DORA درباره چهار متریک اصلی (Lead Time، Deployment Frequency، MTTR و Change Failure Rate) بود. شرکتهایی که تونستن این متریکها رو بهبود بدن، همه روی کوتاه کردن چرخه بازخورد تمرکز داشتن. Moloco نمونه جالبیه: اونها با تغییر معماری و بهبود فرآیند انتشار، زمان آمادهسازی تغییرات رو ۹۰٪ کاهش دادن. Delivery Hero هم نشون داد وقتی بازه انتشارها کوتاهتر میشه، ریسک شکست به طرز چشمگیری کم میشه و تیمها سریعتر یاد میگیرن.این یعنی ارزش محصول نه با یک «بیگ بنگ» بزرگ، بلکه با انتشارهای کوچک و مستمر به دست کاربر میرسه.۳. فرهنگ تیمی؛ قلب واقعی تحولو نهایتا شاید مهمترین بخش گزارش: فرهنگ تیمی.TBC Bank تونست فرکانس استقرار رو ۶۰۰٪ افزایش بده و زمان تحویل رو از شش ماه به فقط ۴.۵ روز برسونه. چنین جهشی بدون تیمهای مستقل و فرهنگی که بر اعتماد و همکاری بنا شده باشه، ممکن نبود. Commerzbank هم نشون داد تغییرات کوچک روی بستر فرهنگ درست، نتایج بزرگی دارن: زمان بررسی کد در تیمهاشون ۵۰٪ کاهش پیدا کرد و پوشش تست از ۴۷٪ به ۷۵٪ رسید. حتی LiveRamp که با اتوماسیون در یک فصل بیش از ۷۴۰ ساعت زمان آنکالی حذف کرد، این موفقیت رو مدیون فرهنگی بود که اختیار تصمیمگیری رو به تیمها داده بود.پس پیام روشنه: AI و اتوماسیون میتونن شتابدهنده باشن، اما اگر تیم حس مالکیت، اعتماد و استقلال نداشته باشه، خروجی در بهترین حالت کوتاهمدت خواهد بود.جمعبندیسه نکته DORA 2025 برای مدیران محصول چیزی فراتر از یک گزارش سالانهست. اینها در واقع نقشه راه هستن:AI مسئولانه: برای توانمندسازی، نه کنترل.چرخههای کوتاه: برای کاهش ریسک و تحویل مداوم ارزش.فرهنگ تیمی: زیربنای همه تغییرات پایدار.در نهایت ابزارها میان و میرن، اما فرهنگی که تیمها رو به حرکت درمیاره، چیزیـه که آینده محصول رو میسازه.لیست برندگان و دستهبندیهاArchitecting for the Future with AI: ElasticsearchAugmenting Human Expertise with AI: IKS HealthDeveloper Productivity and Velocity: ExabeamEmbracing Artificial Intelligence: Wayfair and BuildkiteEnterprise-Scale Transformation: HoneywellGoing Beyond the Four Keys: MolocoImproving Developer Experience: Delivery HeroLeveraging Loosely Coupled Teams: TBC BankNurturing Team Culture: Commerzbank AGOperational Excellence and Automation: LiveRampScaling AI Transformation: VodafoneScaling Improvement Throughout Your Organization: VismaUnleashing the Full Power of the Cloud: Buildertrend امین محمودیان امین محمودیان Wed, 03 Sep 2025 13:09:02 +0330 https://virgool.io/@amin.mahmudian/%D8%AE%D8%AF%D8%A7%D8%AD%D8%A7%D9%81%D8%B8%DB%8C-%D8%A8%D8%A7-%D9%87%D9%85-%D8%AA%DB%8C%D9%85%DB%8C-qnwpndgob3wx حتما شما هم تا حالا مطالب زیادی رو در مورد این که چطور سازمان فعلی‌تون رو ترک کنین و چه کارهایی رو برای خروج حرفه‌ای باید انجام بدین خوندین یا در شبکه‌های اجتماعی دیدین. در این دست مطالب تمرکز بیشتر روی ما به عنوان فرد در حال ترک سازمان و مسائل مربوط به اونه.مطالب دیگه‌ای که اغلب در مورد خروج از سازمان می‌بینیم، به بحث‌های HRی این قضیه می‌پردازن. مخصوصا «مصاحبه خروج» (که به نظر می‌رسه در اغلب سازمان‌ها هنوز در سطوح لاکچری طوره، حداقل من تا حالا تجربه‌اش نکردم). این نگاه بیشتر معطوف به سازمان و مدیریت منابع و سرمایه‌های انسانیه. ولی چیزی که من کمتر دیدم در موردش صحبت بشه، نحوه تعامل «تیم» با خروج یکی از اعضاشه. مخصوصا در تیم‌هایی با دغدغه‌های چابکی که به سمت خود-مدیریتی حرکت می‌کنن.چطور باید با رفتن یک هم‌تیمی مواجه بشیم؟متاسفانه، اغلب مواقع وقتی کسی که دانشی رو خلق کرده سازمان رو ترک می‌کنه، انتقال دانش به خوبی اتفاق نمیوفته و احتمالا برای مدتی یک فاصله و گپ در سطح دانسته‌های افراد وجود خواهد داشت که باعث سختی یا بلاک شدن انجام کارها میشه.دیروز که بعد از یک ارائه آنلاین سایت ارائه‌دهنده رو چک می‌کردم دیدم بومی به نام «بوم بدرود» طراحی کرده و مطلب جالبی هم در مورد نحوه استفاده ازش نوشته.چطور میشه از این بوم استفاده کرد؟بعد از این که خبر رفتن هم‌تیمی‌تون رو شنیدین (اگه خوش شانس باشین سه چهار هفته قبل از رفتنش) از «بوم بدرود» میشه برای شروع گفتگو در این مورد استفاده کرد. بوم ۶ بخش داره که بخش‌های ۱،۲،۴ و ۵ رو فردی که تیم رو ترک می‌کنه، و بخش‌های ۳ و ۶ رو باقی اعضای تیم تکمیل می‌کنن.برای گرفتن بهترین نتیجه از این بوم، یک جلسه برای کل تیم و فردی که داره می‌ره تنظیم کنین. برای داشتن یک جلسه مؤثر و کنش محور، می‌تونین بخش های یک تا چهار رو قبل از جلسه پر کنین.ساختار یه جلسه یک ساعته می‌تونه این‌طوری باشه:ریو کردن بخش‌های ۱ تا ۴؛ ۱۰ دقیقهمشخص کردن حوزه‌های حیاتی و مشخص کردن اکشن برای رسیدگی به اون‌ها؛ ۳۰ دقیقهصحبت در مورد بخش‌های ۵ و ۶؛ ۱۰ دقیقهتصمیم‌گیری در مورد پی‌گیری‌ها و نحوه انجام اکشن‌ها؛ ۱۰ دقیقهدر جلسه نکته‌ها رو مد نظر داشته باشین:۱. روی حیاتی‌ترین حوزه‌های دانش تمرکز کنین. زمان انتقال دانش محدوده و داشتن تمرکز می‌تونه نتیجه بهتری به شما بده.۲. فعالیت‌های حیاتی که باعث میشه انجام بدون وقفه کارها تضمین بشن رو هماهنگ کنین.۳. فضایی برای ابراز نیازها، نگرانی‌ها، تردیدها و مشکلات بیان نشده ایجاد کنین، مسلما الان به همه اون‌ها رسیدگی نمی‌کنین ولی ویژوال کردنشون قدم مثبت خوبی برای شروع کاره.۴. آدما وقتی در حال ترک تیم هستن نظراتشون رو بازتر و صادقانه‌تر به اشتراک می‌گذارن. این جلسه رو صرف انتقاد شدید از همدیگه نکنین، گفتن چند نکته که باعث پیش‌رفت تیم بشه کمک بهتری می‌کنه.۵. لحظات خوبی که با همکارتون داشتین رو مرور کنین و قدردان باشین.۶. همه یه مورد مثبت در مورد کسی که در حال ترک تیمه بگن، چه چیزی رو در موردش تحسین می‌کردین.خیلی ضروریه که مطمئن بشین صحبت‌ها به اکشن منجر بشن. هر اکشن باید یک مسئول مشخص داشته باشه. اون مسئول، اکشن رو هدایت می‌کنه، اما لزوما تمام کار رو به تنهایی انجام نمیده.مهمه که تو این جلسه خیلی وارد جزییات نشین. این جلسه‌ها برای حل مشکلات نیستن، بلکه برای ایجاد یه برنامه عملیاتی برای انتقال دانش و رفع نگرانی‌ها هستن. اگر در پایان جلسه بین ۳ تا ۵ اکشن داشته باشین در مسیر خوبی هستین.در هر صورت مستقل از این که آیا از این بوم استفاده کنیم یا نه، مهمه که رفتن آدم‌ها از تیم‌هامون رو بپدیریم و در مواجه باهاش فعالانه عمل کنیم و از همکارمون به خاطر مسیری که با ما بودن قدردان باشیم تا خاطره خوبی برای همه بمونه. شما چه تجربه‌ای در این موضوع دارین؟https://nomad8.com/articles/so-your-team-member-is-leaving امین محمودیان امین محمودیان Fri, 28 Jun 2024 03:17:51 +0330 https://virgool.io/@amin.mahmudian/%D8%A8%D8%A7%D8%B2%D8%B1%D8%B3%DB%8C-%D9%88-%D8%A8%DA%A9-%D9%84%D8%A7%DA%AF-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D8%A8%D8%A7%D8%B2%DA%AF%D8%B4%D8%AA-%D8%A8%D9%87-%D8%A8%D9%86%DB%8C%D8%A7%D9%86-%D9%87%D8%A7%DB%8C-%DA%86%D9%87%D8%A7%D8%B1%DA%86%D9%88%D8%A8-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-fxxzviesaord اسکرام بر مبنای کنترل فرایند‌ تجربه‌گرا بنا شده که «بازرسی» یک از سه ستون آن به حساب میاد.هر کدام از مصنوعات اسکرام برای تشخیص ناسازگاری‌های نامطلوب، در حداقل یکی از رخدادهای اسکرام مورد بازرسی قرار می‌گیرد. اگر احساس می‌کنید چیزی مطابق انتظار اجرا نمی‌شود، برای این که ببینید علت چیست با همراهی تیم‌تان نگاهی به مصنوعات بندازید.هدف از بازرسی کشف ناسازگاری‌های غیر مطلوب در مسیر پیشرفت به سمت اهداف توافق شده است.به عنوان مثال بیایید بک‌لاگ اسپرینت را در نظر بگیریم. بک‌لاگ اسپرینت حداقل در طول جلسه اسکرام روزانه مورد بازرسی قرار می‌گیرد تا ناساز‌گاری‌ها در مسیر حرکت به سمت هدف اسپرینت کشف شوند. پاسخ به سوال‌هایی مثل «الان کجا قرار داریم؟»، «موقعیت فعلی چطور با هدف اسپرینت که به آن متعهد شده بودیم ارتباط پیدا می‌کند؟» یا «وضعیت اقدام‌ها بهبودی (improvement actions) که تعهد داده‌ایم چطور است؟» به این بازرسی کمک می‌کند.معمولا، توسعه‌دهندگان تیم اسکرام هستند که این بازرسی را انجام می‌دهند.بک‌لاگ اسپرینت حاوی آیتم‌هایی است که تا کنون شناسایی شده‌اند و تیم احساس ‌می‌کند برای رسیدن به هدف اسپرینت الزامی هستند. اگر این آیتم‌ها را به خوبی بررسی کنیم، برای بازرسی وضعیت پیشرفت نسبت به هدف، تیم می‌تواند این پرسش‌ها را مطرح کند؛ آیا این آیتم‌ها واقعا باعث رسیدن به هدف اسپرینت می‌شوند؟ چه کمبودهایی وجود دارد؟ و چه چیزی برای رسیدن به هدف اسپرینت واقعا لازم نیست؟آیا در مسیر پیشرفت به سمت ارائه هدف اسپرینت در قالب یک فرآورده تکمیل‌شده (Done Increment)، بک‌لاگ اسپرینت‌تان را برای شناسایی ناسازگاری‌های نامطلوب بازرسی می‌کنید؟براساس مطلب آقای Steven Deneir در وب‌لاگ scrum.org امین محمودیان امین محمودیان Sat, 25 Sep 2021 19:00:02 +0330 https://virgool.io/@amin.mahmudian/%D9%87%D8%B4%D8%AA-%D8%B1%D8%A7%D9%87-%D9%85%D8%AE%D8%AA%D9%84%D9%81-%D9%85%D8%B1%D8%AA%D8%A8-%DA%A9%D8%B1%D8%AF%D9%86-%D8%A8%DA%A9-%D9%84%D8%A7%DA%AF-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AF%D8%A7%D8%B4%D8%AA%D9%86-%D8%AA%D8%A7%D8%AB%DB%8C%D8%B1-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1-xnq7axkqodkv ما اغلب بک‌لاگ‌های محصولات‌مون رو به چالش نمی‌کشیم، اون‌ها لیستی از چیزهایی هستند که ما امیدواریم، امکان داره یا دوست داریم که انجام بدیم. ولی آیا این چیزها همیشه باید به صورت یک لیست ارائه بشن؟جف پاتون وقتی نقشه داستان کاربر (User Story Mapping) رو ساخت (و بعدتر کتابش رو هم نوشت) از اولین افرادی بود که مفهوم یک بک‌لاگ خطی رو به چالش کشید. ولی واقعا یک بک‌لاگ خطی معمولا چیز بدی هم نیست، به‌خصوص در ابتدای چرخه حیات محصول (وقتی که محصول در دوران نوزادی خودشه و به احتمال زیاد تیم کوچکه، تعدادکاربران‌تون محدوده و عمل‌کردشون سریع و ساده است. در نتیجه احتمالا بک‌لاگ‌تون فقط چند آیتم محدود رو شامل می‌شه)اون روزها روزهای خوبی بودن :)با گذر زمان و با فرض اینکه محصول‌تون موفق بوده، پیچیدگی محصول شروع به رشد می‌کنه (فیچرها اضافه شدن، تعداد کاربران الان در مقیاس صدها هزار یا شاید میلیونه). حالا بک‌لاگ شما داره یواش یواش شبیه صف شله نذری روز عاشورا میشه. مسائلی که سعی می‌کنین کشف کنین متعدد هستند و انواع مختلف آیتمی که دارین(بیش‌تر به عنوان «کلاس‌های کاری» هم شناخته می‌شن) از کل آیتم‌هایی که زمانی در بک‌لاگ داشتین بیش‌تر شده! (مثلا ایرادات، بهبود UI، کشف فضاهای مشکل‌ساز، ایده‌های نو خلاقانه برای امتحان کردن، آزمایش‌ها، فیچرهای جدید، بهینه کردن فیچرهای موجود، بدهی‌های فنی، امنیت و …).مسلط ماندن روی همه‌ی این‌ها کار یک ابر انسانه، که متاسفانه ما نیستیم! برای همینه که بک‌لاگ‌ها به لقب‌هایی مثل «جایی که ایده‌ها می‌میرن» هم معروف شدن.بازنگری چگونگی سازمان‌دهی بک‌لاگ به صورت منظم ضروریه. این کار تفاوت این که بک‌لاگ شما تبدیل به انبار ایده‌های مرده بشه یا یک ابزار مؤثر باشه که محصول‌تون رو قدرت‌مند می‌کنه رو مشخص می‌کنه.پس این هشت روش مختلف ساختار دادن به بک‌لاگه برای آتیش کردن خلاقیت درونی‌تون و غلبه بر هرگونه احساس افسردگی بک‌لاگی که ممکنه داشته باشین.۱. نقشه داستان کاربر«نقشه داستان کاربر» که شاید پرطرفدارترین بک‌لاگ غیر خطی باشه، توسط جف پاتن ساخته و تبدیل به ستاره شد. خواندن کتابش برای هر مدیر محصولی ضروریه!جف پیشنهاد می‌کنه به جای داشتن یک بک‌لاگ خطی، بک‌لاگ رو حول کاربرتون بسازید. به صورت مشخص‌تر، حول سفر(journey) کاربرتون، و این که چطور محصول از کاربران در رسیدن به کارها و اهدافشون حمایت می‌کنه.مزیت مورد علاقه من که از ارائه بک‌لاگ به این صورت به دست میاد دید کلی‌ایه که شما نسبت به بک‌لاگ‌تون پیدا می‌کنید، این که هر آیتم کجا قرار می‌گیره و چطور در موفقیت «کاری که باید انجام شود (Job-to-be-done)» در سفر مشتری کمک می‌کنه.نقشه‌های داستان کاربر روشی عالی در ساختن بک‌لاگ برای اولین باره، هم‌چنین ابزار قدرت‌مندی برای برنامه‌ریزی انتشار هم هستند.برای محصولات بالغ‌تر اغلب من نقشه داستان کاربرم رو براساس نوع مشتری، JTBD، اهداف (objectives) و حتی فضا‌های مسأله تقسیم می‌کنم؛ بسته به اینکه کدوم منطقی‌تر به نظر میاد.۲. بک‌لاگ قیف ایدهیک «قیف» به معنی واقعی کلمه! روشی عالی برای مصور کردن بکلاگ‌تون و واقعا محدود کردن تعداد آیتم‌های بک‌لاگ محصول که در «بالا» (خب «راست»!) بک‌لاگ قرار می‌گیرن به صورت فیزیکی!این شکل بک‌لاگ برای کمک به اولویت‌بندی و تمرکز عالیه در عین حال همه چیز رو بدون ساختار یا سربار زیاد، سیال نگه می‌داره.می‌تونین قیف‌تون رو به مرحله‌های مختلف بشکنید، یا مثل یک نقشه راه باهاش رفتار کنین (حتی یک «اکنون-بعدی-بعدا» ساده هم خیلی خوب کار می‌کنه) بک‌لاگ قیف یه ترکیب از نقشه راه و بک‌لاگ هست. بهترین قسمتش اینه که به جای نگه‌داری دو مصنوع فقط باید مواظب یکی باشیم!۳. بک‌لاگ فرصتروش دیگه‌ای از آقای جف پاتون، این یکی وقتی از رویکرد «مسیر دوگانه (Dual Track)»اش استفاده میشه محبوبیت داره. در دنیای مسیر دوگانه، شما بک‌لاگ‌تون رو به دو بخش تقسیم می‌کنین یکی برای ارائه و دلیور کردن دیگری برای کشف و دیسکاور کردن.این جاست که بک‌لاگ فرصت وارد می‌شه، می‌شه بخش دیسکاوری بک‌لاگ شما. تمام ایده‌ها، فضاهای مسأله و فرصت‌ها اینجا ریخته می‌شن، اگه به عنوان ایده خوب تأیید شدن وارد بک‌لاگ دلیوری می‌شن. در این جاست که چیزها از فضای مسأله به فضای راه‌حل منتقل می‌شن، که در نهایت ما اون‌ها رو می‌سازیم و ارائه می‌کنیم و ازشون یاد می‌گیریم. این یادگیری ما رو به سمت فرصت‌های بیشتر هدایت می‌کنه و که دوباره راهشون رو به بک‌لاگ فرصت پیدا می‌کنن و این چرخه توسعه محصوله!۴. کلاس‌های کاری (Classes of work)یکی از کارهایی که بک‌لاگ فرصت، که اشاره شد، می‌کنه اینه که اساساً بک‌لاگ‌تون رو به کلاس‌های کاری می‌شکنه. اغلب می‌بینم مدیران محصولی که باهاشون کار می‌کنم الان هم این کار رو با استفاده از ابزارهایی انجام می‌دن. اکثراً ابزارهای مثل جیرا و … کمک‌شون می‌کنه که روی آیتم‌ها تگ بزارن، تایپ‌های مختلف بسازن یا حتی لیبل بزنن.اتفاقی که بیش‌تر وقت‌ها می‌افته اینه که بک‌لاگشون رشد می‌کنه و برای پی‌گیری همه چیز مجبور می‌شن به صورت دیوانه‌واری لیبل بزنن و تمام بک‌لاگ رو پر از تگ کنن. کاری که اون‌ها عملاً انجام می‌دن تقسیم بک‌لاگ‌شون به چند بک‌لاگ‌ کوچک‌تر براساس کلاس‌های کاری مختلفه. بک‌لاگ بدهی فنی، بک‌لاگ بهبود رابط‌کاربری، یک بک‌لاگ فیچر و … وجود خواهد داشت. اگرچه استفاده از برچسب‌ها برای دستیابی به این امر ذاتاً بد نیست، راه‌های دیگه‌ای هم برای ارائه بک‌لاگتون بدون اینکه گرفتار لیبیل‌های بسیار زیاد بشیم وجود داره. ساده‌ترین کاری که می‌شه انجام داد اینه که به معنی واقعی کلمه جداشون کنیم. اکثر ابزارها به شما اجازه رسیدن به این هدف رو با ویو‌های مختلف و فیلترها می‌دن در عین حالی که می‌تونین در یک ویو هم چیزهایی مثل بک‌لاگ اسپرینت رو به صورت یک‌پارچه ببینین.۵. بک‌لاگ درختیپیچیدگی روزافزون فن‌آوری و توانایی نمایش دیداری روابط متقابل و مسیرهای جایگزین رسیدن به یک فیچر، باعث ایجاد درخت فن‌آوری (Technology Tree) شد.درخت‌های فن‌آوری برای محصولات پیچیده و دارای انواع مختلف فیچرها مناسب هستن. نمایش بک‌لاگ‌تون به این روش یک راه عالیه برای به تصویر کشیدن روابط متقابل فیچرهای مختلف و نشون دادن این که چطور می‌تونیم یک عملکرد خاص رو ساده شروع کنیم و به تدریج بهبود بدیم.بهترین استفاده از بک‌لاگ درختی که من تا به حال دیده‌ام نقشه‌راه یک نئو بانک (neo-bank) استرالیایی به نام Up است که اخیراً به صورت عمومی منتشر شده، خارق‌العاده است! تعاملی و از نظر دیداری زیبا!یک رویکرد محبوب دیگه در استفاده از بک‌لاگ درختی استفاده برای سازمان دادن به بک‌لاگ فرصت‌تونه. روشی به نام درخت راه‌حل فرصت (Opportunity Solution Tree) که توسط ترزا تورس ساخته شده، یک راه بسیار قدرت‌مند برای مجسم‌کردن و فکر کردن در مورد وظایف دیسکاوری برای تیم‌هاست. حتما بررسی‌اش کنید نحوه‌ی فکر کردن و انجام دادن کارهای مربوط به دیسکاوری محصول رو در شما به خوبی تغییر می‌ده!۶. بک‌لاگ نقشه تأثیرنقشه تأثیر هم از نظر این که شاخه شاخه می‌شه مشابه درخت فن‌آوری کار می‌کنه. اگر چه برخلاف درخت فن‌آوری هر مرحله در شاخه یک آیتم دیگه بک‌لاگ نیست بلکه یک مرحله از مسیر «چرا -> چه کسی -> چه چیزی -> چطور» رو در نقشه تأثیر نشون میده.نقشه‌های تأثیر برای ایده‌پردازی راه‌های جایگزین مختلف رسیدن به یک نتیجه مشخص عالی هستن. نمایش بک‌لاگ‌تون به این صورت برای نتیجه‌محور نگه داشتن همه چیز عالیه. ولی بک‌لاگ‌های نقشه مسیر برای نمایش بقیه کلاس‌های کاری مثل بدهی فنی، باگ‌ها و … خیلی مناسب نیستن.۷. بک‌لاگ دایره‌ایبعضی وقت‌ها فقط لازمه که خلاق باشیم و دقیقاً به همین دلیله که من عاشق بک‌لاگ‌های دایره‌ای هستم! یک چیزی در شکستن الگوها وجود داره که خلاقیت رو در وجود آدما بیدار می‌کنه. وقتی صحبت از بک‌لاگ دایره‌ای می‌شه همه جور ایده‌های خلاقانه دیده‌ام: بک‌لاگ‌های شبیه تخته دارت یا حتی بک‌لاگ مارپیچ که آیتم‌های بک‌لاگ به تدریج به سمت مرکز در حرکتند.بک‌لاگ‌های دایره‌ای برای ساختن برش‌هایی از دسته‌بندی‌های کار شما بسیار مناسبه در عین حالی که یک نمای کلی رو هم نگه می‌داره. حتی می‌تونین خلاق‌تر باشین و برش‌هایی با اندازه متفاوت داشته باشید، یک راه عالی برای محدود کردن فیزیکی «کار در حال انجام یا (WIP)»!بک‌لاگ‌های دایره‌ای برای مواقعی که یک بک‌لاگ از چند بک‌لاگ خوراک می‌گیره یا بخوایم بک‌لاگ رو براساس فیچر، اپیک، تم، کلاس‌های کاری و … دسته‌بندی کنیم عالی هستن. همین‌طور شبیه به بک لاگ قیفی می‌تونن هم‌زمان نقش بک‌لاگ و نقشه‌راه رو بازی کنن.۸. بک‌لاگ قیف تبدیل(Conversion)وقتی استفاده ازش منطقی باشه، این محبوب‌ترین نوع بک‌لاگ برای منه. برای محصولاتی که کانورژن‌های شفافی دارن، مثل یک محصول ای‌کامرس، ساختن بک‌لاگ حول قیف‌(های) کانورژن‌‌تون ایده‌آله. این کار دو گونه اطلاعات مهم رو کنار هم میاره: داده‌های کَمّی پیرامون دراپ‌آف‌ها/پین‌پوینت‌های بلقوه در قیف شما و همین‌طور بک‌لاگ آیتم‌ها/محل‌های فرصت. من همیشه از کار با این نوع بک‌لاگ لذت می‌برم، چون اولویت‌بندی رو به یک رؤیا تبدیل می‌کنه! اگه یک دراپ‌آف مشخص در یک نقطه خاص وجود داره پس حالا همه چیز در اون بخش بک‌لاگ بالاترین اولویت شماست. عمیقا متمرکز می‌شین، اونقدر روی اون بخش از بک‌لاگ تمرکز می‌کنید تا اعداد بهبود پیدا کنن یا یک دلیل متقاعد کننده‌ای برای تمرکز روی چیز دیگه پیدا کنید.بک‌لاگ‌های قیف تبدیل برای مراحل ابتدایی و رشد محصول عالی هستن چون شما رو روی عامل‌های کلیدی مثل تبدیل (conversion)، حفظ (retention) و بازگشت (referral) متمرکز می‌کنه. ولی همین‌طور می‌تونن برای محصولات بالغ‌تری که نیاز به اصلاح دارن هم قدرتمند باشند. اغلب بک‌لاگ‌ها جوری رشد می‌کنن و رشد می‌کنن که ته‌شون معلوم نمی‌شه، مدیریت کردن‌شون تبدیل می‌شه به یک کابوس. این‌جا جاییه که بک‌لاگ‌های قیف تبدیل می‌تونن کمک کنن به خاطر این که تمرکز روی یک نقطه بخصوص در قیف باعث میشه به جای ۲۰۰ چیز ۱۰ چیز را اولویت‌بندی کنید، خیلی ساده‌تره!شما چه روش‌های دیگه‌ای برای ارائه بک‌لاگ محصولتون دارین؟۹۹٪ مطلب بالا ترجمه‌ای بود از مقاله آقای انتونی مورفی در سایت productcoalition.com امین محمودیان امین محمودیان Sat, 18 Sep 2021 23:41:10 +0430