https://virgool.io/feed/@alikarimi علی هستم. توی توسعه محصول فعالیت میکنم. fa 2026-06-16 14:28:17 https://files.virgool.io/upload/users/9304/avatar/mnbCzD.jpg?height=120&width=120 https://virgool.io/@alikarimi https://virgool.io/@alikarimi/%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-%DA%86%D8%B7%D9%88%D8%B1%DB%8C-%D8%AF%D9%88%D8%B1-%D8%AE%D9%88%D8%AF%D9%85%D9%88%D9%86-%D9%86%DA%86%D8%B1%D8%AE%DB%8C%D9%85-%D9%88-%D8%A8%D8%B1%DB%8C%D9%85-%D8%B3%D8%B1%D8%A7%D8%BA-%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%A7%D8%B5%D9%84%DB%8C-%D9%88-%D8%A8%D8%A7-%D8%A7%D9%87%D9%85%DB%8C%D8%AA-u7iysngp8vsi این کتاب چیه و به درد کیا می‌خوره؟این کتاب یه جورایی مثل نقشه‌ی راه برای توسعه محصول توی شرکت Basecamp هستش. یعنی بهتون نشون می‌ده که توی Basecamp چجوری محصول رو توسعه می‌دن. اما فقط این نیست؛ یه جعبه‌ابزار پر از تکنیک‌های کاربردیه که می‌تونید هر کدوم رو به روش خودتون توی شرکت یا تیمتون به کار ببرید. کلاً، هدف اصلی این کتاب اینه که بهتون یه زبان جدید بده تا بتونید ریسک‌ها، چالش‌ها و ناشناخته‌های دنیای توسعه محصول رو بهتر بشناسید و باهاشون کنار بیاید. اینجا خبری از روش‌های قدیمی مثل Waterfall یا Scrum نیست، بلکه یه رویکرد کاملاً متفاوت و نتیجه‌ی ۱۵ سال آزمون و خطا توی Basecamp رو نشون می‌ده.حالا چرا اصلاً به همچین کتابی نیاز پیدا شد؟ خب، تیم‌های نرم‌افزاری وقتی بزرگ می‌شن، با یه سری چالش‌های مشترک روبرو می‌شن. مثلاً اعضای تیم حس می‌کنن پروژه‌ها بی‌انتها کش میان و تمومی ندارن. یا مدیران محصول فرصت نمی‌کنن به استراتژی‌های بزرگ‌تر فکر کنن. حتی گاهی اوقات بنیان‌گذارا از خودشون می‌پرسن "چرا دیگه مثل اوایل نمی‌تونیم سریع فیچر جدید بدیم بیرون؟". Basecamp هم خودش این مشکلات رو وقتی از یه تیم ۴ نفره به بالای ۵۰ نفر رسید، تجربه کرده. این کتاب در واقع برای حل این مشکلات نوشته شده؛ یعنی کمک می‌کنه تا توی کار گیر نکنید، توی کارای قدیمی غرق نشید و وقتتون بابت مشکلات غیرمنتظره تلف نشه. هدفش اینه که بهتون یاد بده چجوری توانایی تحویل به‌موقع رو دوباره به دست بیارید.پس، این کتاب یه سری ایده‌های اصلی و اساسی داره که حسابی به دردتون می‌خوره: یکی از مهم‌ترین‌هاش، "سیکل‌های شش هفته‌ای" هستش. شش هفته هم اونقدر طولانیه که بشه یه چیز معنی‌دار رو از صفر تا صد ساخت و هم اونقدر کوتاهه که همه حس کنن ددلاین نزدیکه و وقتشون رو هدر ندن. بعدش، بحث "شکل‌دهی کار" (Shaping) مطرح می‌شه. یعنی قبل از اینکه کار رو بدید دست تیم، یه گروه کوچیک و باتجربه، جزئیات اصلی راه‌حل رو تعریف می‌کنن. اینجا دیگه دنبال تخمین زدن نیستیم، بلکه می‌پرسیم "چقدر حاضریم برای این ایده وقت بذاریم؟" که بهش "اشتها" (Appetite) می‌گن. یه مفهوم باحال دیگه، "دادن مسئولیت کامل به تیم"های کوچیک از طراح‌ها و برنامه‌نویس‌هاست که خودشون وظایفشون رو تعریف می‌کنن و اسکوپ رو تنظیم می‌کنن. همچنین، برای مدیریت ریسک، پروژه‌هایی که روی اونها "شرط‌بندی" می‌کنیم، سقف زمانی شش هفته‌ای دارن که بهش "مدارشکن" (Circuit Breaker) می‌گن؛ یعنی اگه تو این زمان تموم نشد، دیگه تمدید نمی‌شه. و در نهایت، با ابزاری مثل "هیل چارت" (Hill Chart) یاد می‌گیرید که چجوری وضعیت کار رو نه بر اساس انجام شدن یا نشدن تسک‌ها، بلکه بر اساس "مشخص بودن" یا "نامشخص بودن" کارها نشون بدید و با "اسکوپ همرینگ" (Scope Hammering) مرتباً اسکوپ رو می‌کوبید تا تو زمان مقرر جا بشه.نکته مهم درباره این ترجمه:بچه‌ها، این ترجمه‌ای که دارید می‌خونید، با کمک هوش مصنوعی انجام شده. پس طبیعیه که ممکنه بهترین و بی‌نقص‌ترین ترجمه‌ی ممکن نباشه. هدف اصلی من از این کار این بوده که این متد خیلی کاربردی و باارزش رو برای همه، کمی آسون‌تر و قابل‌دسترس‌تر کنم. اگه جایی رو خوندید و حس کردید می‌تونه ترجمه بهتری داشته باشه یا گنگ بود، حتماً بهم بگید. خوشحال می‌شم بازخوردتون رو بشنوم تا بتونیم با هم این متن رو بهتر و کامل‌تر کنیم. ممنون از همراهیتون!فهرست کتاب: ۰. پیشگفتار جیسون فراید۰. مقدمه (Acknowledgements)۰. مقدمه ۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:56:49 +0330 https://virgool.io/@alikarimi/%DB%B1%DB%B5-%D9%86%D8%AA%DB%8C%D8%AC%D9%87-%DA%AF%DB%8C%D8%B1%DB%8C-conclusion-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-tnfnb38ghytq مفاهیم کلیدی (Key concepts)متد Shape Up که توی این کتاب ارائه شده، خیلی به هم تنیده است. ممکنه نیاز به کمی فکر و آزمایش داشته باشه تا بخش‌های مناسب رو ازش بیرون بکشید و اون‌ها رو با تیم خودتون تطبیق بدید.چه تیم شما بتونه این متد رو یکجا پیاده کنه و چه نه، امیدوارم زبان و مفاهیمی که در این کتاب اومده، نکاتی رو برای استفاده فوری بهتون داده باشه:• کار شکل‌گرفته (Shaped work) در مقابل کار شکل‌نگرفته (unshaped work)• تعیین اشتها (appetites) به جای تخمین‌ها (estimates)• طراحی در سطح مناسب انتزاع (abstraction)• ایده‌پردازی (Concepting) با برد بوردها (breadboards) و اسکچ‌های ماژیک ضخیم (fat marker sketches)• شرط‌بندی کردن (Making bets) با ریسک محدود (capped downside) (همون circuit breaker) و وفادار موندن به اون‌ها با زمان بدون وقفه• انتخاب طول سیکل (cycle length) مناسب (شش هفته)• یک دوره استراحت (cool-down period) بین سیکل‌ها• خُرد کردن پروژه‌ها به اسکوپ‌ها (scopes)• کار سراشیبی (Downhill work) در مقابل کار سربالایی (uphill work) و ارتباط گرفتن درباره ناشناخته‌ها• اسکوپ همرینگ (Scope hammering) برای جدا کردن بایدها (must-haves) از خوب‌ها (nice-to-haves)در تماس باشید (Get in touch)مایلیم نظر شما رو بشنویم تا بتونیم متد Shape Up رو برای پیاده‌سازی راحت‌تر کنیم. چی رو از قلم انداختیم؟ چی هنوز واضح نیست؟ دوست داشتید در مورد چی صحبت می‌کردیم که نکردیم؟ همینطور، مایلیم درباره موفقیت‌ها و چالش‌هاتون در پیاده‌سازی این متد در تیم‌ها و پروژه‌هاتون بشنویم.به این آدرس ایمیل بزنید: shapeup@basecamp.com.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:54:11 +0330 https://virgool.io/@alikarimi/14-%D9%BE%DB%8C%D8%B4-%D8%A8%D8%B1%DB%8C%D8%AF-move-on-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-chpvxecglvch بذارید طوفان بگذرهتحویل محصول (Shipping) اگه مراقب نباشید، در واقع می‌تونه کارهای جدیدی ایجاد کنه. انتشار فیچرها (Feature releases) درخواست‌های فیچر (feature requests) جدیدی رو به دنبال دارن. مشتری‌ها می‌گن: «خب، عالیه، اما اون چیز دیگه‌ای که می‌خواستیم چی شد؟». باگ‌ها (Bugs) پیدا می‌شن. پیشنهاداتی برای بهبودها دریافت می‌شه. همه روی چیز جدید تمرکز دارن و بهش واکنش نشون می‌دن.فیدبک (Feedback) می‌تونه مخصوصاً شدید باشه اگه فیچری که شما تحویل دادین، جریان‌های کاری (workflows) موجود رو تغییر بده. حتی تغییرات صرفاً بصری هم گاهی اوقات باعث مقاومت شدید می‌شن. یه اقلیت کوچکی از مشتری‌ها ممکنه بیش از حد واکنش نشون بدن و چیزایی مثل «خرابش کردید! برگردونیدش!» بگن.مهمه که خونسرد باشید و از واکنش‌های عجولانه (knee-jerk reactions) پرهیز کنید. چند روزی بهش زمان بدید و بذارید فروکش کنه. قاطع باشید و یادتون باشه چرا اصلاً این تغییر رو ایجاد کردید و این تغییر به چه کسی کمک می‌کنه.بدهکار نمونید (Stay debt-free)وسوسه‌انگیزه که در پاسخ به فیدبک، متعهد به ایجاد تغییرات بشیم، اما اینطوری دیگه برای سیکل (cycle) بعدی یک صفحه تمیز (clean slate) ندارید. یادتون باشه: این‌ها فقط ایده‌های خام (raw ideas) هستن که دارن میان. روش مدیریت اون‌ها اینه که با یک «نه» ملایم برخورد کنید. گفتن «نه» به این معنی نیست که دیگه نمی‌تونید بهشون فکر کنید و شاید اون‌ها رو به پروژه‌های آینده شکل بدید. از اون طرف، گفتن «بله» آزادی شما رو در آینده سلب می‌کنه. این مثل گرفتن دِین (debt) هست.یادتون باشه، چیزی که شما همین الان تحویل دادید (shipped)، یک «شرط شش هفته‌ای» (six-week bet) بود. اگه این بخش از محصول به زمان بیشتری نیاز داره، پس نیازمند یک «شرط» جدید هست. اجازه بدید درخواست‌ها یا باگ‌هایی که تازه به وجود اومدن، در «میز شرط‌بندی» (betting table) بعدی با همه چیزهای دیگه رقابت کنن تا مطمئن بشید که از نظر استراتژیک مهم هستن.فیدبک باید شکل داده بشهاینجا ما به نقطه اول برمی‌گردیم. ایده‌های خامی که تازه از فیدبک مشتری اومدن، هنوز قابل اجرا (actionable) نیستن. اون‌ها باید شکل داده بشن (shaped). اون‌ها همون ورودی‌های خامی هستن که در مرحله اول فرآیند شکل‌دهی (shaping process)، یعنی «تعیین محدودیت‌ها» (Set Boundaries)، در موردشون صحبت کردیم.اگه یک درخواست واقعاً مهمه، می‌تونید اون رو در سیکل بعدی به بالاترین اولویت در مسیر شکل‌دهی (shaping track) تبدیل کنید. روی چیز دیگه‌ای برای ساخت توسط تیم‌ها شرط‌بندی کنید و از اون زمان برای شکل دادن صحیح ایده جدید استفاده کنید. بعد، وقتی شش هفته تموم شد، می‌تونید در میز شرط‌بندی (betting table) دفاع کنید و نسخه شکل‌گرفته (shaped version) پروژه رو برای بیشترین شانس موفقیت برنامه‌ریزی کنید.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:53:38 +0330 https://virgool.io/@alikarimi/%DB%B1%DB%B3-%D8%AA%D8%B5%D9%85%DB%8C%D9%85-%D8%A8%DA%AF%DB%8C%D8%B1%DB%8C%D8%AF-%DA%86%D9%87-%D8%B2%D9%85%D8%A7%D9%86%DB%8C-%D9%85%D8%AA%D9%88%D9%82%D9%81-%D8%B4%D9%88%DB%8C%D8%AF-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-bwlh3l1mvaes وقتی به پایان یک چرخه نزدیک می‌شویم، تکنیک‌هایی که تا اینجا پوشش دادیم، تیم را در موقعیت خوبی قرار می‌دهند تا کار را تمام کرده و آن را عرضه (ship) کنند. کار شکل‌گرفته (shaped work) به آنها guard rails داد تا از گمراه شدنشان جلوگیری کند. آنها هر scope را به صورت جداگانه یک به یک ادغام کردند تا کار نیمه‌تمام روی زمین نماند. و همه مهم‌ترین مشکلات حل شده‌اند، چون آنها آن ناشناخته‌ها (unknowns) را هنگام توالی‌بندی کار، اولویت‌بندی کردند.با این حال، همیشه کار بیشتر از زمان است. عرضه به موقع (shipping on time) به معنای عرضه کردن چیزی ناقص است. همیشه دلشوره (queasiness) دارید وقتی به کارتان نگاه می‌کنید و از خودتان می‌پرسید: آیا این به اندازه کافی خوب است؟ آیا این آماده عرضه (release) است؟.مقایسه با بیس‌لاین (baseline)طراحان و برنامه‌نویسان همیشه می‌خواهند بهترین کار خود را انجام دهند. فرقی نمی‌کند که دکمه در مرکز صفحه فرود (landing page) باشد یا دو صفحه پایین‌تر در صفحه تنظیمات (settings screen)، طراح بهترین توجه خود را به آن معطوف خواهد کرد. و بهترین برنامه‌نویسان می‌خواهند که کد بیس (code base) مانند یک کل منسجم (cohesive whole) باشد، که کاملاً از نظر منطقی سازگار بوده و تمام اج کیس (edge case)ها را پوشش دهد.غرور نسبت به کار برای کیفیت و روحیه مهم است، اما باید آن را به سمت هدف درست هدایت کنیم. اگر به دنبال یک طراحی ایده‌آل و بی‌نقص باشیم، هرگز به آن نخواهیم رسید. در عین حال، نمی‌خواهیم استانداردهای خود را پایین بیاوریم. چگونه تصمیم بگیریم (make the call) که آنچه داریم به اندازه کافی خوب است و به جلو حرکت کنیم؟.جابجایی نقطه مقایسه کمک کننده است. به جای مقایسه با ایده‌آل (comparing up)، به سمت بیس‌لاین (baseline) مقایسه کنید—یعنی واقعیت فعلی برای مشتریان. مشتریان امروز، بدون این فیچر (feature)، چگونه این مشکل را حل می‌کنند؟. چه راه‌حل موقتی (workaround) آزاردهنده‌ای وجود دارد که این فیچر آن را از بین می‌برد؟. مشتریان چقدر دیگر باید چیزی را که کار نمی‌کند تحمل کنند یا منتظر راه حلی باشند، فقط به این دلیل که ما مطمئن نیستیم آیا طراحی A بهتر از طراحی B است؟.دیدن اینکه کار ما تا اینجای کار بهتر از جایگزین‌های فعلی است، باعث می‌شود احساس بهتری نسبت به پیشرفتمان داشته باشیم. این ما را ترغیب می‌کند تا در مورد چیزهایی که سرعت ما را کم می‌کنند، تصمیم بگیریم. کمتر به خودمان مربوط است و بیشتر به ارزش برای مشتری. این تفاوت بین "هرگز به اندازه کافی خوب نیست" و "بهتر از آن چیزی است که اکنون دارند" است. می‌توانیم بگوییم: "خب، این کامل نیست، اما قطعاً کار می‌کند و مشتریان احساس خواهند کرد که این یک پیشرفت بزرگ برای آنهاست".کاهش اسکوپ (scope) با مقایسه به سمت بیس‌لاین به جای مقایسه با یک ایده‌آل کاملمحدودیت‌ها، ترید-آف (trade-off)ها را تحریک می‌کنندبه یاد بیاورید که "شرط شش هفته‌ای" (six-week bet) یک سرکیت بریکر (circuit breaker) دارد—اگر کار انجام نشود، پروژه اتفاق نمی‌افتد.این تیم را مجبور به انجام ترید-آف (trade-off) می‌کند. وقتی کسی می‌گوید "آیا بهتر نیست اگر..." یا یک اج کیس (edge case) دیگر پیدا می‌کند، ابتدا باید از خود بپرسد: آیا برای این کار زمان هست؟. بدون یک ددلاین (deadline)، آنها به راحتی می‌توانند پروژه را برای تغییراتی که واقعاً شایسته زمان اضافی نیستند، به تأخیر بیندازند.ما از تیم‌هایمان انتظار داریم که به طور فعالانه ترید-آف انجام دهند و اسکوپ (scope) را زیر سوال ببرند، به جای اینکه کارها را به زور و با فشار تمام کنند. ما خودمان کار را برای خودمان ایجاد می‌کنیم. ما باید هر کار جدیدی را که پیش می‌آید، قبل از پذیرفتن آن به عنوان یک ضرورت، زیر سوال ببریم.اسکوپ (scope) مثل چمن رشد می‌کنداسکوپ (scope) به طور طبیعی رشد می‌کند. اسکوپ کریپ (Scope creep) (افزایش ناخواسته اسکوپ) تقصیر مشتریان بد، مدیران بد، یا برنامه‌نویسان بد نیست. پروژه‌ها در مقیاس ماکرو (macro scale) مبهم هستند. تا زمانی که وارد کار نشوید، نمی‌توانید تمام جزئیات ریز (micro-details) یک پروژه را ببینید. سپس نه تنها پیچیدگی‌هایی را که پیش‌بینی نمی‌کردید کشف می‌کنید، بلکه انواع چیزهایی را نیز می‌بینید که می‌توانند رفع شوند یا بهتر از وضعیت فعلی‌شان شوند.هر پروژه‌ای پر از اسکوپ است که به آن نیاز نداریم. هر بخش از یک محصول نیازی نیست که به یک اندازه برجسته (prominent)، سریع و صیقلی (polished) باشد. هر یوز کیس (use case) به یک اندازه رایج (common)، حیاتی (critical)، یا هم‌راستا با بازاری که قصد فروش به آن را داریم، نیست.اوضاع اینگونه است. به جای تلاش برای متوقف کردن رشد اسکوپ، ابزارها، اختیار و مسئولیت را به تیم‌ها بدهید تا آن را دائماً کاهش دهند.کاهش اسکوپ (scope) به معنای کاهش کیفیت نیستانتخاب و گزینش اینکه چه چیزهایی را اجرا کنیم و تا چه اندازه پیش ببریم، حفره‌ای در محصول ایجاد نمی‌کند. تصمیم‌گیری، محصول را بهتر می‌کند. محصول را در برخی چیزها بهتر می‌کند، نه در همه چیز. سخت‌گیری در مورد اسکوپ، محصول را متفاوت می‌کند. متمایز کردن هسته از اجزای فرعی، ما را در فضای رقابتی حرکت می‌دهد و باعث می‌شود نسبت به سایر محصولاتی که انتخاب‌های متفاوتی داشته‌اند، شباهت یا تفاوت بیشتری پیدا کنیم.وریبل اسکوپ (variable scope) به معنای فدا کردن کیفیت نیست. ما در مورد کیفیت کد، طراحی بصری، متن‌های (copy) موجود در اینترفیس (interface)هایمان، و پرفورمنس (performance) تعاملاتمان، بسیار سخت‌گیر هستیم. ترفند این است که از خودمان بپرسیم چه چیزهایی واقعاً مهم هستند، چه چیزهایی تاثیرگذارند (move the needle)، و چه چیزهایی برای یوز کیس‌های اصلی که قصد حل آنها را داریم، تفاوت ایجاد می‌کنند..همرینگ (Scope hammering)مردم اغلب در مورد "کم کردن" اسکوپ (scope) صحبت می‌کنند. ما از کلمه‌ای حتی قوی‌تر—همرینگ (hammering) (کوبیدن)—استفاده می‌کنیم تا قدرت و نیرویی را که برای بارها و بارها کوبیدن اسکوپ لازم است تا در تایم باکس (time box) جا بگیرد، منعکس کنیم.همانطور که در طول یک پروژه به چیزهایی برای اصلاح، اضافه کردن، بهبود یا طراحی مجدد می‌رسیم، از خود می‌پرسیم:• آیا این برای فیچر (feature) جدید یک "ماست-هَو (must-have)" (باید-داشته-باشیم) است؟• آیا می‌توانیم بدون این، محصول را عرضه (ship) کنیم؟• چه اتفاقی می‌افتد اگر این کار را انجام ندهیم؟• آیا این یک مشکل جدید است یا یک مشکل از قبل موجود که مشتریان قبلاً با آن زندگی می‌کنند؟• چقدر احتمال دارد این مورد یا شرایط اتفاق بیفتد؟• وقتی این مورد اتفاق می‌افتد، کدام مشتریان آن را می‌بینند؟ آیا اصلی است—که توسط همه استفاده می‌شود—یا بیشتر یک اج کیس (edge case) است؟• در صورت وقوع این مورد یا شرایط، تأثیر واقعی آن چیست؟• وقتی چیزی برای یک یوز کیس (use case) خاص خوب کار نمی‌کند، آن یوز کیس چقدر با مخاطبان مورد نظر ما هم‌راستا است؟ددلاین (deadline) ثابت ما را به پرسیدن این سوالات ترغیب می‌کند. وریبل اسکوپ (variable scope) ما را قادر می‌سازد تا بر اساس آنها عمل کنیم. با تراشیدن و همرینگ (hammering) کردن اسکوپ، ما فقط روی کارهایی که برای عرضه چیزی موثر و قابل افتخار در پایان تایم باکس (time box) نیاز داریم، متمرکز می‌مانیم.در طول چرخه، از تیم‌هایمان خواهید شنید که هنگام کشف کارها در مورد ماست-هَو (must-have)ها و نایس-تو-هَو (nice-to-have)ها صحبت می‌کنند. ماست-هَوها به عنوان تسک (task)ها روی اسکوپ ثبت می‌شوند. اسکوپ تا زمانی که آن تسکها تمام نشوند، "انجام‌شده" (done) تلقی نمی‌شود. نایس-تو-هَوها می‌توانند پس از اتمام اسکوپ روی آن باقی بمانند. آنها با یک علامت تیلده (~) در جلو مشخص می‌شوند. این تسکها کارهایی هستند که اگر تیم در پایان زمان اضافی داشت انجام می‌شوند و در غیر این صورت حذف می‌شوند. معمولاً هرگز ساخته نمی‌شوند. عمل علامت‌گذاری آنها به عنوان یک نایس-تو-هَو، همان همرینگ اسکوپ (scope hammering) است.یک اسکوپ تکمیل شده با یک نایس-تو-هَو (که با "˜" مشخص شده) که هرگز به اتمام نرسیدQA (کیفیت سنجی) برای اج‌ها (edges) استدر اندازه فعلی Basecamp (میلیون‌ها کاربر و حدود دوازده نفر در تیم محصول)، ما یک نفر مسئول کیو اِی (QA) داریم. آنها در اواخر چرخه وارد می‌شوند و به دنبال اج کیس (edge case)هایی خارج از عملکرد اصلی (core functionality) می‌گردند.کیو اِی می‌تواند توجه خود را به اج کیسها محدود کند زیرا طراحان و برنامه‌نویسان مسئولیت کیفیت اولیه کار خود را بر عهده می‌گیرند. برنامه‌نویسان تست‌های خود را می‌نویسند و تیم با هم کار می‌کند تا اطمینان حاصل کند که پروژه طبق آنچه شکل گرفته (shaped) عمل می‌کند. این ناشی از دادن مسئولیت کل پروژه به تیم است، به جای اختصاص تسک (task)های فردی به آنها (به فصل ۹، "واگذاری مسئولیت" مراجعه کنید).سال‌ها ما یک نقش کیو اِی نداشتیم. سپس پس از اینکه پایگاه کاربری (user base) ما به اندازه مشخصی رشد کرد، دیدیم که اج کیسهای کوچک شروع به تأثیرگذاری بر صدها یا هزاران کاربر به صورت مطلق (in absolute numbers) کردند. اضافه کردن مرحله کیو اِی اضافی به ما کمک کرد تا تجربه آن کاربران را بهبود بخشیم و بار نامتناسبی را که برای تیم پشتیبانی ایجاد می‌کردند، کاهش دهیم.بنابراین، ما کیو اِی را به عنوان یک "ارتقاء" (level-up) می‌بینیم، نه یک دروازه (gate) یا نقطه بازرسی (check-point) که همه کارها باید از آن عبور کنند. با کیو اِی وضعیت ما بسیار بهتر از بدون آن است. اما ما برای عرضه فیچر (feature)های با کیفیت که طبق انتظار کار می‌کنند، به کیو اِی وابسته نیستیم.کیو اِی تسک (task)های کشف شده‌ای را ایجاد می‌کند که به طور پیش‌فرض همگی نایس-تو-هَو (nice-to-have) هستند. تیم طراح-برنامه‌نویس آنها را تریاژ (triage) می‌کند و بسته به شدت و زمان موجود، برخی از آنها را به ماست-هَو (must-have) ارتقاء می‌دهد. دقیق‌ترین روش برای انجام این کار این است که مسائل ورودی کیو اِی را در یک لیست کارهای جداگانه (to-do list) جمع‌آوری کنید. سپس، اگر تیم تصمیم گرفت که یک مسئله ماست-هَو است، آن را به لیست مربوط به اسکوپ (scope)ای که تحت تأثیر قرار می‌دهد، منتقل می‌کنند. این به تیم کمک می‌کند تا ببیند که اسکوپ تا زمانی که مسئله برطرف نشود، تمام نشده است.ما کد ریویو (code review) را نیز به همین روش در نظر می‌گیریم. تیم می‌تواند بدون انتظار برای کد ریویو، محصول را عرضه (ship) کند. هیچ چک-پوینت (check-point) رسمی (formal) وجود ندارد. اما کد ریویو کارها را بهتر می‌کند، بنابراین اگر زمان باشد و منطقی به نظر برسد، یک نفر ارشد ممکن است کد را بررسی کرده و بازخورد دهد. این بیشتر در مورد بهره‌برداری از یک فرصت آموزشی است تا ایجاد یک مرحله در فرآیند ما که هر بار باید اتفاق بیفتد.چه زمانی یک پروژه را تمدید کنیمدر موارد بسیار نادر، پروژه‌ای را که از ددلاین (deadline) خود گذشته است، برای چند هفته تمدید می‌کنیم. چگونه تصمیم می‌گیریم چه زمانی یک پروژه را تمدید کنیم و چه زمانی اجازه دهیم سرکیت بریکر (circuit breaker) کار خود را انجام دهد؟.اولاً، تسک (task)های باقی‌مانده باید ماست-هَو (must-have)های واقعی باشند که در برابر هر تلاشی برای همرینگ اسکوپ (scope hammer) کردنشان مقاومت کرده‌اند.ثانیاً، کار باقی‌مانده باید کاملاً "سرازیری" (all downhill) باشد. هیچ مشکل حل‌نشده؛ هیچ سوال بی‌جوابی. هر کار "سربالایی" (uphill work) در پایان چرخه به یک نادیده‌گرفتن (oversight) در شکل‌دهی (shaping) یا یک نقص (hole) در مفهوم اشاره دارد. ناشناخته‌ها برای شرط‌بندی (bet) بسیار پرخطر هستند. اگر کار سربالایی است، بهتر است در چرخه بعدی کار دیگری انجام دهیم و پروژه مشکل‌دار را به مرحله شکل‌دهی (shaping) بازگردانیم. اگر راه حل مناسبی برای رفع نقص پیدا کردید، می‌توانید در آینده دوباره روی آن زمان بیشتری سرمایه‌گذاری (bet) کنید.حتی اگر شرایط برای تمدید پروژه فراهم باشد، ما همچنان ترجیح می‌دهیم منظم باشیم و "اشتها" (appetite) تعیین شده برای بیشتر پروژه‌ها را اجرا کنیم. کول‌داون (cool-down) دو هفته‌ای معمولاً فضای کافی (slack) را برای تیمی که کمی ماست-هَو بیش از حد دارد، فراهم می‌کند تا قبل از شروع چرخه بعدی، محصول را عرضه (ship) کند. اما این نباید به عادت تبدیل شود. رسیدن به کول‌داون (یعنی استفاده از زمان کول‌داون برای اتمام پروژه) یا به مشکلی در فرآیند شکل‌دهی (shaping) اشاره دارد یا به مشکل عملکردی (performance problem) در تیم.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:52:46 +0330 https://virgool.io/@alikarimi/%DB%B1%DB%B2-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA-%D8%B1%D8%A7-%D9%86%D8%B4%D8%A7%D9%86-%D8%AF%D9%87%DB%8C%D8%AF-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-bdoercmlcgyl مدیران با نیت خوب، تمایلی به پرسیدن وضعیت کارها ندارند. این کار ناخوشایند است، شبیه به غر زدن به نظر می‌رسد، و وقتی مجبور می‌شوند سوالات پیگیری بپرسند تا کاملاً از وضعیت مطلع شوند، حتی بدتر هم می‌شود.مدیران ترجیح می‌دهند بتوانند خودشان هر زمان که نیاز دارند وضعیت را مشاهده کنند. در فصل گذشته دیدیم که چگونه سازماندهی To-doها به Scopes به تیم کمک می‌کند تا بر کار مسلط بماند. اما این به طور مستقیم به مدیر کمک نمی‌کند. چند مشکل در To-doها وجود دارد که باعث می‌شود برای قضاوت وضعیت کافی نباشند.وظایفی که وجود ندارندلیستی را تصور کنید که چند مورد تکمیل شده و هیچ مورد ناتمامی در آن باقی نمانده است. این می‌تواند به معنای اتمام کل کار باشد. اما همچنین می‌تواند به این معنی باشد که تیم می‌داند کار بیشتری وجود دارد اما هنوز وظایف را تعریف نکرده است.گاهی اوقات یک تیم در اوایل پروژه یک Scope را تعریف می‌کند بدون اینکه آن را با وظایف پر کند. این نشان می‌دهد که کاری باید انجام شود اما وظایف واقعی هنوز کشف نشده‌اند.یا به انجام QA (کنترل کیفیت) در پایان یک Scope فکر کنید. تمام وظایف انجام شده‌اند. چیز دیگری برای انجام دادن نیست. سپس عمل تست، Scope را با وظایف جدید برای مشکلات یافت شده پر می‌کند.این به مفهوم وظایف تصوری در مقابل وظایف کشف شده برمی‌گردد. در تصور ساده‌لوحانه ما از لیستی که از قبل برنامه‌ریزی شده، کسی آن را با مواردی پر می‌کند که به تدریج تیک می‌خورند. در واقعیت، مسائل با درگیر شدن در مشکل کشف می‌شوند. این بدان معناست که لیست‌های To-do در واقع با پیشرفت تیم رشد می‌کنند.اگر در زمان t2 سعی می‌کردیم قضاوت کنیم که پروژه چقدر پیش رفته است، گمراه می‌شدیم. از دید یک شخص بیرونی (outsider)، هیچ راهی برای دانستن اینکه آیا تعداد وظایف باقیمانده کم می‌شود یا زیاد، وجود ندارد. برای دانستن این موضوع، به بستر و جزئیات بیشتری از کار در داخل Scope نیاز دارید تا بفهمید انجام آن وظایف خاص چه معنایی دارد و آیا وظایف دیگری ممکن است هنوز در راه باشند.تخمین‌ها عدم قطعیت را نشان نمی‌دهندبرخی از تیم‌ها تلاش می‌کنند تخمین‌هایی را به وظایف یا Scopes خود پیوست کنند تا وضعیت را گزارش دهند. مشکل تخمین‌ها این است که بسته به ماهیت کاری که تخمین زده می‌شود، معنای بسیار متفاوتی دارند.فرض کنید دو وظیفه دارید که هر دو تخمین زده شده‌اند چهار ساعت زمان ببرند. اگر یکی از وظایف چیزی باشد که تیم ده بار در گذشته انجام داده است، می‌توانید به تخمین اطمینان داشته باشید. فرض کنید وظیفه دیگر چیزی است که تیم هرگز قبلاً انجام نداده است، یا وابستگی‌های مبهمی دارد. این کار ممکن است در صورت پیش رفتن همه چیز به خوبی، چهار ساعت طول بکشد، اما به دلیل ناشناخته‌های موجود در آن، ممکن است تا دو یا سه روز به طول انجامد. نوشتن «۴ ساعت، یا شاید ۳ روز» به عنوان تخمین، معنی‌دار نیست.با درک این موضوع، ما راهی برای مشاهده وضعیت پروژه بدون شمارش وظایف و بدون تخمین‌های عددی ابداع کردیم. ما این کار را با تغییر تمرکز از آنچه انجام شده یا انجام نشده، به آنچه ناشناخته است و آنچه حل شده است، انجام می‌دهیم. برای امکان‌پذیر ساختن این تغییر، از استعاره "تپه" استفاده می‌کنیم.فرایند کار شبیه به تپه استهر قطعه کار دو فاز دارد. ابتدا فاز "سربالایی" است که در آن رویکردمان و کاری که قرار است انجام دهیم را مشخص می‌کنیم. سپس، زمانی که می‌توانیم تمام کار درگیر را ببینیم، فاز "سرازیری" یا همان اجرای کار است.بیایید از یک مثال روزمره استفاده کنیم تا حس تپه را درک کنیم.فرض کنید در حال برنامه‌ریزی برای میزبانی یک مهمانی شام هستید. تاریخ را تعیین کرده‌اید، اما هنوز چند هفته مانده و شما هنوز به این فکر نکرده‌اید که چه چیزی بپزید. هیچ ایده‌ای ندارید که نوع غذای مهمانی چه خواهد بود یا چه غذایی را باید درست کنید. این شما را در ابتدای تپه، در پایین سمت چپ، قرار می‌دهد.سپس به این فکر می‌کنید که چه کسانی حضور دارند و متوجه می‌شوید که چند نفر گیاهخوار هستند. این برخی گزینه‌ها (مانند کباب کردن) را حذف می‌کند اما هنوز گزینه‌های زیادی باقی می‌گذارد. هم غذای ایتالیایی و هم هندی را در نظر می‌گیرید. فکر می‌کنید غذای هندی ممکن است برای پخت و پز لذت‌بخش‌تر باشد، با گزینه‌های گیاهخواری جذاب‌تر. بنابراین تصمیم می‌گیرید به دنبال دستور پخت‌های هندی بگردید.در این مرحله، سوال «پروژه چند درصد تکمیل شده است؟» حتی معنی هم نمی‌دهد. و اگر کسی از شما بپرسد که خرید و آماده‌سازی چقدر طول می‌کشد، شما نمی‌توانستید پاسخ دهید زیرا هنوز غذایی را انتخاب نکرده‌اید. پاسخ این خواهد بود: «کمی کار برای مشخص کردن نوع غذا انجام داده‌ام، اما هنوز آن را به یک غذای خاص محدود نکرده‌ام». ما می‌توانیم این را با قرار دادن شما در نیمه راه بخش «در حال فهمیدن» (figuring it out) تپه نشان دهیم.سپس کمی جستجو آنلاین انجام می‌دهید و کتاب‌های دستور پخت خود را مرور می‌کنید. می‌خواهید دستوری را پیدا کنید که جالب باشد اما نیازی به مواد اولیه خیلی سخت پیدا کردن نداشته باشد. روی یک دستور پخت به توافق می‌رسید و لیست خرید را آماده می‌کنید.اکنون شما در موقعیتی بسیار متفاوت از قبل قرار دارید. حس شما از «هنوز مطمئن نیستم دارم چه می‌کنم» به «اکنون می‌دانم چه کاری باید انجام دهم» تغییر می‌کند. شما در بالای تپه هستید.از این نقطه دید، می‌توانید تمام مراحل باقیمانده را ببینید. حتی منطقی است که تخمین بزنید کل کار چقدر طول می‌کشد («ببینم… یک ساعت برای خرید خواربار، ۳۰ دقیقه آماده‌سازی، ۴۵ دقیقه پخت…»).روز قبل از مهمانی شام، به فروشگاه می‌روید و مواد اولیه را می‌خرید. این شما را به سمت سرازیری حرکت می‌دهد. به اتمام کار نزدیک‌تر شده‌اید.سپس نوبت کار آماده‌سازی و پخت غذا می‌رسد.پس از اتمام غذا، فقط کمی کار باقی مانده است: تمیزکاری.توجه کنید که چگونه تپه نشان می‌دهد کار در مراحل مختلف چه حسی دارد. فاز سربالایی پر از عدم قطعیت، ناشناخته‌ها و حل مسئله است. فاز سرازیری با قطعیت، اعتماد به نفس، دیدن همه چیز و دانستن اینکه چه کاری باید انجام داد، مشخص می‌شود.Scopes روی تپهمی‌توانیم تپه را با مفهوم Scopes از فصل قبل ترکیب کنیم. Scopes زبان پروژه («پیدا کردن»، «پاسخ دادن») را به ما می‌دهند و تپه وضعیت هر Scope را توصیف می‌کند («سربالایی»، «سرازیری»).برای مشاهده وضعیت Scopes، می‌توانیم هر یک را با رنگی متفاوت روی تپه نمایش دهیم.این یک نمای کلی از پروژه‌ای برای پیاده‌سازی رویدادهای تکرارشونده در Basecamp است. در اینجا، «Future-applying edits» یک Scope است که هنوز در حال کار روی آن است و ناشناخته‌های قابل توجهی برای حل کردن دارد. دو Scope دیگر هیچ ناشناخته معناداری ندارند و «Global recurring events» به اتمام نزدیک‌تر است.وضعیت بدون پرسیدنما یک قابلیت انحصاری برای Basecamp ساختیم تا نمودارهای تپه (hill charts) را ایجاد و با چند کلیک آن‌ها را به‌روزرسانی کند. اعضای تیم، که درک کاملی از وضعیت کار دارند، به طور خودکار Scopes را به موقعیت مورد نظر می‌کشند و یک به‌روزرسانی جدید ذخیره می‌کنند که در پروژه ثبت می‌شود (برای جزئیات بیشتر به «چگونه Shape Up را در Basecamp پیاده‌سازی کنیم» مراجعه کنید).برای مدیران، قابلیت مقایسه وضعیت‌های گذشته، قابلیت برجسته (killer feature) است. این نه تنها وضعیت کار را نشان می‌دهد، بلکه نحوه حرکت کار را نیز نمایش می‌دهد.با این دیدگاه ثانویه، مدیران می‌توانند قضاوت کنند که چه چیزی در حال حرکت است و چه چیزی گیر کرده است. آن‌ها می‌توانند ببینند تیم کدام مشکلات را برای حل انتخاب کرده و چقدر زمان در هر مرحله از ناشناخته به شناخته شده و سپس به اتمام، صرف کرده است.این گزارش به اولین مقصد مدیر تبدیل می‌شود، هر زمان که در مورد یک پروژه احساس نگرانی می‌کنند. از آنجایی که این یک ابزار Self-serve (خودخدمتی) است، نیازی به قطع کردن کار تیم با سوالات ناخوشایند وضعیت نیست. و در مواردی که چیزی درست به نظر نمی‌رسد، مدیر می‌تواند مستقیماً وارد گفتگو درباره بخش مربوطه از کار شود. «به نظر می‌رسد ‘Autosave’ مدتی است که در حال سربالایی بوده. ناشناخته‌ای که جلوی آن را گرفته چیست؟». مدیر می‌تواند روی این بخش خاص از پروژه کارگاه برگزار کند بدون اینکه ابتدا مجبور باشد آن را از سایر مواردی که طبق انتظار پیش می‌روند، جدا کند.هیچ‌کس نمی‌گوید «نمی‌دانم»هیچ‌کس نمی‌خواهد دست خود را بلند کند و به مدیریت بگوید «من نمی‌دانم چگونه این مشکل را حل کنم». این باعث می‌شود تیم‌ها عدم قطعیت را پنهان کرده و ریسک را انباشته کنند. لحظاتی که کسی گیر کرده یا درجا می‌زند، محل بزرگترین ریسک‌ها و فرصت‌هاست. اگر این لحظات را زود تشخیص دهیم، می‌توانیم با کمک یک فرد ارشد یا با بازنگری مفهوم، آن‌ها را برطرف کنیم. اگر آن‌ها را تشخیص ندهیم، مشکلات حل نشده می‌توانند تا جایی در چرخه باقی بمانند که پروژه را به خطر بیندازند.نمودار تپه به همه اجازه می‌دهد تا ببینند کسی ممکن است گیر کرده باشد، بدون اینکه او واقعاً آن را بیان کند. یک نقطه که حرکت نمی‌کند، عملاً یک دست بلند شده است: «ممکن است مشکلی اینجا وجود داشته باشد».هنگامی که این موضوع شناسایی شد، زبان سربالایی/سرازیری، گفتگو را تسهیل می‌کند. کمتر در مورد شخص است (به نظر می‌رسد گیر کرده‌ای!) و بیشتر در مورد کار است. سوال این است: چه چیزی را می‌توانیم حل کنیم تا آن را از تپه عبور دهیم؟.انگیزه‌هایی برای Refactor کردن Scopes (بازسازی محدوده‌ها)گاهی اوقات بررسی یک Scope گیر کرده نشان می‌دهد که اصلاً گیر نکرده است. مشکل در نحوه ترسیم خطوط Scope بوده است.در اینجا موردی را می‌بینید که Scope «Notify» برای مدت طولانی روی تپه گیر کرده بود.وقتی با تیم صحبت کردیم، معلوم شد که کار به خوبی پیش می‌رفته است. مشکل این بود که «Notify» یک چیز واحد نبود. این شامل سه بخش مختلف بود: طراحی یک ایمیل، ارسال ایمیل در Back-end، و نمایش اعلان در یک منوی درون‌برنامه‌ای (in-app menu). تیم عمدتاً کد مربوط به ارسال ایمیل را به پایان رسانده بود. طراحی ایمیل تقریباً مشخص شده بود. اما آن‌ها کار روی نمایش درون‌برنامه‌ای را شروع نکرده بودند. نمی‌شد گفت که آیا «Notify» به طور کلی از تپه عبور کرده یا نه، زیرا بخش‌هایی از آن عبور کرده بودند و بخش‌هایی نه.راه حل در چنین مواردی این است که Scope را به Scopes کوچکتر تقسیم کنیم که بتوانند مستقل حرکت کنند.اکنون تیم می‌تواند هر نقطه را حرکت دهد تا به طور دقیق نشان دهد کار در چه وضعیتی قرار دارد.مزیت در سطح دوم (second order) ظاهر می‌شود. با تفکیک Scopes، آن‌ها می‌توانند به طور مستقل در طول زمان حرکت کنند. اکنون تیم می‌تواند پیشرفت بیشتری را با دفعات بیشتری نسبت به قبل نشان دهد.مسیر سربالایی خود را با ساختن طی کنیدبرخی از تیم‌ها هنگام استفاده اولیه از نمودار تپه با "عقب‌گرد" (backsliding) مشکل دارند. آن‌ها یک Scope را حل شده می‌دانند، آن را به بالای تپه منتقل می‌کنند، و بعداً مجبور می‌شوند آن را به عقب برگردانند وقتی یک ناشناخته غیرمنتظره کشف می‌کنند.وقتی این اتفاق می‌افتد، اغلب به این دلیل است که کسی کار سربالایی را با سر خود (ذهنی) به جای دستان خود (عملی) انجام داده است. ابداع یک رویکرد در ذهن شما فقط اولین گام سربالایی است. ما اغلب یک نظریه در مورد نحوه حل چیزی داریم—«من فقط از آن API استفاده خواهم کرد»—و سپس واقعیت پیچیده‌تر از آب درمی‌آید. خوب است که یک‌سوم اول سربالایی را به معنای «من به این موضوع فکر کرده‌ام»، یک‌سوم دوم را به معنای «رویکرد خود را تأیید کرده‌ام»، و یک‌سوم نهایی تا قله را به معنای «آنقدر با آنچه ساخته‌ام پیش رفته‌ام که باور ندارم ناشناخته دیگری وجود داشته باشد» در نظر بگیرید.با ترتیب درست حل کنیدعلاوه بر دیدن وضعیت کار، می‌توانیم از نمودار تپه برای اولویت‌بندی کارها استفاده کنیم—اینکه کدام مشکلات را به چه ترتیبی حل کنیم.برخی Scopes پرخطرتر از دیگران هستند. دو Scope را تصور کنید: یکی شامل Geocoding (کدگذاری جغرافیایی) داده‌هاست—چیزی که تیم هرگز قبلاً انجام نداده است. دیگری طراحی و پیاده‌سازی یک اعلان ایمیلی است. هر دو ناشناخته دارند. هر دو از پایین تپه شروع می‌شوند. اینجا جایی است که تیم از خود می‌پرسد: اگر در پایان چرخه زمان کم بیاوریم، کدام یک از این‌ها را می‌توانیم به راحتی — علیرغم ناشناخته‌ها — به سرعت آماده کنیم، و کدام یک ممکن است سخت‌تر از آنچه فکر می‌کنیم باشد؟.این تیم را ترغیب می‌کند تا پرخطرترین کار را ابتدا به سمت سربالایی حرکت دهد. هنگامی که به سربالایی رسیدند، آن را همانجا رها می‌کنند و به دنبال هر چیز بسیار مهم دیگری می‌گردند قبل از اینکه کار سرازیری را به اتمام برسانند. بهتر است چند Scope حیاتی را در اوایل پروژه به بالای تپه برسانید و «ریزه‌کاری‌ها» (screw-tightening) را برای بعد بگذارید.کار برای پر کردن زمان موجود گسترش می‌یابد. اگر تیم ابتدا با قالب ایمیل شروع کند، به راحتی می‌توانند هفته‌ها را صرف تکرار روی متن یا ایجاد بهترین طراحی ایمیل ممکن کنند. اما آن‌ها نیازی به انجام این کار ندارند. نسخه‌ای از قالب ایمیل وجود دارد که می‌تواند در یک روز در هفته آخر آماده شود و کافی خواهد بود. از طرف دیگر، Geocoder ممکن است مشکلات جدیدی را ارائه دهد که تیم بتواند برای هفته‌ها با آن‌ها دست و پنجه نرم کند. آن‌ها نمی‌خواهند این غافلگیری در پایان چرخه رخ دهد.روزنامه‌نگاران مفهومی به نام «هرم معکوس» (inverted pyramid) دارند. ایده این است که مقالات آن‌ها با ضروری‌ترین اطلاعات در بالا شروع می‌شوند، سپس جزئیات و اطلاعات پس‌زمینه را به ترتیب اهمیت کمتر اضافه می‌کنند. این به طراحان روزنامه‌های چاپی اجازه می‌دهد تا بخش حیاتی داستان را در صفحه اول قرار دهند و در صورت نیاز بخش پایانی را بدون از دست دادن هیچ چیز ضروری حذف کنند.تیم‌های کارآمد به همین شیوه، حل مسئله خود را اولویت‌بندی می‌کنند. آن‌ها ابتدا مهم‌ترین مشکلات را با بیشترین ناشناخته‌ها انتخاب می‌کنند، آن‌ها را به بالای تپه می‌رسانند و کارهایی را که روزمره یا کمترین نگرانی را دارند، برای آخر می‌گذارند.با نزدیک شدن به پایان چرخه، تیم‌ها باید کارهای مهم را به پایان رسانده و مجموعه‌ای از «مواردی که خوب است داشته باشیم» (nice to haves) و «شایدها» را باقی بگذارند. این ما را به فصل بعدی، یعنی تصمیم‌گیری درباره زمان توقف، می‌رساند.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:52:10 +0330 https://virgool.io/@alikarimi/%DB%B1%DB%B1-%D9%86%D9%82%D8%B4%D9%87-%D8%A8%D8%B1%D8%AF%D8%A7%D8%B1%DB%8C-scope%D9%87%D8%A7-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-mgc1zpyufsri در فصل قبل، پروژه را با اتمام یک برش یکپارچه در اوایل کار شروع کردیم. این روش بخشی از یک تکنیک کلی‌تر است که تیم می‌تواند در طول پروژه از آن استفاده کند.سازماندهی بر اساس ساختار، نه شخصوقتی از افراد خواسته می‌شود که وظایف یک پروژه را سازماندهی کنند، اغلب کار را بر اساس شخص یا نقش تفکیک می‌کنند: آنها لیستی برای طراحان و لیستی برای برنامه‌نویسان ایجاد می‌کنند. این کار منجر به مشکلی می‌شود که در فصل قبل درباره آن صحبت کردیم – افراد وظایف را تکمیل می‌کنند، اما این وظایف به اندازه کافی زود به یک بخش تمام شده از پروژه تبدیل نمی‌شوند.برای مثال خارج از حوزه نرم‌افزار، فرض کنید کسی در حال سازماندهی یک رویداد جمع‌آوری کمک مالی است. او می‌تواند لیستی از وظایف برای هر یک از سه داوطلب خود ایجاد کرده و کار را از آن طریق پیگیری کند. اما در این صورت، هیچ راهی برای دیدن تصویر کلی از اینکه رویداد چطور پیش می‌رود – چه چیزی در سطح کلان انجام شده و چه چیزی انجام نشده – وجود نخواهد داشت. در عوض، آنها باید لیست‌هایی را بر اساس ساختار پروژه ایجاد کنند – یعنی چیزهایی که می‌توانند مستقل از یکدیگر کار شوند و به اتمام برسند. برای این کار، آنها لیست‌هایی برای "فهرست غذا"، "چیدمان محل برگزاری"، و "نور و صدا" ایجاد می‌کنند. سپس سازمان‌دهنده به راحتی می‌تواند ببیند کدام حوزه‌ها تکمیل شده‌اند و کدام حوزه‌ها کار ناتمام دارند.در توسعه محصول، دسته‌بندی‌ها از پیش برای ما آماده نیستند. ما معمولاً چیزهایی را می‌سازیم که هرگز قبلاً نساخته‌ایم. هر پروژه قلمرویی بکر است که باید قبل از اینکه بتوانیم نقشه‌ای برای آن بکشیم، آن را بپیماییم. با عمیق شدن در کار، ما متوجه می‌شویم وابستگی‌های متقابل کجا هستند، چگونه چیزها به هم متصل‌اند، و چه چیزی را می‌توانیم از هم جدا کنیم.همانطور که در فصل قبل دیدیم، برش‌های کاری، وظایف Front-end و Back-end را یکپارچه می‌کنند. این به ما اجازه می‌دهد تا یک برش از پروژه واقعی را به پایان برسانیم و قطعاً به مرحله بعدی برویم. این رویکرد بهتر از داشتن قطعات زیادی است که – به امید آنکه – قرار است تا پایان چرخه به هم متصل شوند.ما این برش‌های یکپارچه پروژه را Scope می‌نامیم. ما Scope کلی (مفرد) پروژه را به Scopeهای جداگانه (جمع) تقسیم می‌کنیم که می‌توانند مستقل از یکدیگر به اتمام برسند. در این فصل، خواهیم دید که تیم چگونه پروژه را به Scopeها تقسیم کرده و تک به تک به آنها رسیدگی می‌کند.نقشه Scopeیک نمای بالا از پروژه را تصور کنید. در ابتدا، فقط یک طرح کلی از کار شکل‌دهی که مقدم بر پروژه بوده، وجود دارد. هنوز هیچ وظیفه یا Scopeای وجود ندارد.وقتی اعضای تیم پروژه را تحویل می‌گیرند، شروع به کشف وظایف می‌کنند. وظایف نقطه شروعی طبیعی هستند زیرا ملموس و جزء به جزء هستند. برای سازماندهی آنها در دسته‌بندی‌های سطح بالاتر هنوز زود است. تلاش برای گروه‌بندی خودسرانه آنها مصنوعی خواهد بود. در ابتدا، صرفاً ثبت انواع چیزهایی که باید اتفاق بیفتند، کافی است.اما ما نمی‌خواهیم برای مدت طولانی با این تصویر بمانیم. این تصویر بیش از حد در سطح پایین است. از دید بالا چیزی قابل مشاهده نیست.همین که تیم شروع به انجام کار واقعی بر روی پروژه می‌کند، یاد می‌گیرد که وظایف چگونه به هم مرتبط هستند و ساختار واقعی پروژه چگونه است. سپس آنها قادر می‌شوند پروژه را به Scopeها تفکیک کنند. این کار مانند تقسیم نقشه پروژه به سرزمین‌های جداگانه است.Scopeها بخش‌های معنادار مسئله را منعکس می‌کنند که می‌توانند مستقل و در مدت زمان کوتاهی – چند روز یا کمتر – تکمیل شوند. آنها از وظایف بزرگ‌ترند اما از کل پروژه بسیار کوچک‌ترند.نقشه یک تصویر ذهنی است. در عمل، ما Scopeها را به عنوان لیست‌های To-do تعریف و پیگیری می‌کنیم. هر Scope متناظر با نام یک لیست است. سپس هر وظیفه مربوط به آن Scope در آن لیست قرار می‌گیرد.زبان پروژهScopeها چیزی بیش از برش‌ها هستند. آنها به زبان پروژه در سطح کلان تبدیل می‌شوند. وقتی قابلیت "مشتریان در پروژه‌ها" را می‌ساختیم، تیم از زبان Scopeها به این صورت استفاده می‌کرد: "بعد از اینکه Bucket Access انجام شد، می‌توانیم Invite Clients را پیاده‌سازی کنیم. سپس وقتی افراد شرکت Visibility Toggle را فعال کنند، ما Update Recording Visibility را انجام خواهیم داد".هنگامی که زمان گزارش وضعیت فرا می‌رسد، تیم از زبان Scopeها برای توضیح اینکه چه چیزی انجام شده و چه چیزی انجام نشده است، استفاده می‌کند. داشتن مکالمه در سطح بالا و اشاره به قطعات نرم‌افزاری تکمیل شده رضایت‌بخش‌تر است، به جای اینکه وارد جزئیات و پیچیدگی‌های کار شویم و اهداف و وضعیت وظایف ناتمام فردی را توجیه کنیم. (در فصل بعدی بیشتر در مورد نحوه گزارش‌دهی Scopeها با استفاده از Hill Chart خواهیم دید).مطالعه موردی: پیش‌نویس پیام‌هایک طراح و یک برنامه‌نویس در حال ساخت قابلیتی برای ایجاد و ذخیره پیش‌نویس پیام‌ها در یک اپلیکیشن جدید بودند. پس از جلسه آغاز پروژه (kick-off)، آنها انبوهی از وظایف را شناسایی کردند که باید در مقطعی انجام می‌دادند.با نزدیک شدن به پایان هفته اول، آنها برخی از وظایف را تکمیل کرده بودند، اما هیچ چیز قابل عرضه‌ای از کارشان وجود نداشت. با رویکرد "انجام دادن یک بخش کامل"، آنها بر روی یک تعامل کلیدی تمرکز کردند که می‌توانستند آن را یکپارچه کنند: ایجاد یک پیش‌نویس جدید.آنها Scope جدید را "Start New" نامیدند، لیستی از To-doها برای آن ایجاد کردند و To-doها را به آن منتقل کردند. تنها یک وظیفه طراحی برای آنها باقی مانده بود تا این Scope را تکمیل شده تلقی کنند.پس از اتمام آن وظیفه طراحی، Scope کامل شد.وظایف Unscoped باقی‌مانده نشان‌دهنده تمام کارهای باقیمانده نیستند. وظایف بیشتری با شروع کار بر روی هر یک از آنها کشف خواهند شد. با این حال، تنوع کافی در کار وجود دارد تا بتوان Scopeهای بیشتری را از آن بیرون کشید. تیم در این مرحله انگیزه داشت که Scopeها را تفکیک کند، زیرا می‌دانستند که می‌خواهند تلاش‌هایشان به زودی به یک بخش قابل مشاهده دیگر منجر شود.با نگاهی به وظایف باقی‌مانده، آنها تصمیم گرفتند وظایف مربوط به یافتن پیش‌نویس‌ها را در Scope جدیدی به نام "Locate" و وظیفه حذف را در Scopeای به نام "Trash" قرار دهند. به نظر می‌رسید تمام کارهای باقی‌مانده مربوط به ذخیره و ویرایش پیش‌نویس بود، بنابراین آن را "Save/Edit" نامیدند.به Scope "Locate" نگاه کنید. در حال حاضر فقط یک وظیفه در آن وجود دارد. اما مطمئناً کارهای بیشتری غیر از صرفاً طراحی فهرست وجود خواهد داشت. وقتی وظایف پیاده‌سازی وجود داشته باشند، در آنجا قرار خواهند گرفت.طراح مقداری کار روی "Locate" را شروع کرد در حالی که برنامه‌نویس روی "Save/Edit" تمرکز کرد. همین که او عمیق‌تر وارد کار شد، متوجه شد که می‌تواند چند بخش را جدا کند تا پیشرفت قابل مشاهده‌تری ایجاد شود. در واقع سه Scope در آن وجود داشت.او ابتدا کار مربوط به ارسال پیام پیش‌نویس را تفکیک کرد. او آن را "Send" نامید.سرانجام، برخی از وظایف باقیمانده "Save/Edit" مربوط به ذخیره‌سازی اطلاعات بودند و یکی دیگر در واقع نامرتبط بود – این یک مورد خاص برای مدیریت پیش‌نویس‌ها هنگام پاسخ دادن به پیام دیگری بود. او این‌ها را به دو Scope جدید تقسیم کرد: "Store" و "Reply".در این مرحله، تیم ناگهان احساس کرد که می‌تواند کل پروژه را در سطح بالا ببیند. تمام بخش‌های اصلی در سطح کلان به عنوان Scopeها قابل مشاهده بودند. هیچ یک از آنها آنقدر بزرگ نبود که وظایف مهم یا چالش‌برانگیز بتوانند در داخل آنها نادیده گرفته شوند.در همین حال، طراح روی "Locate" پیشرفت کرده بود. پس از کمی تنظیمات اولیه (wiring)، آنها توانستند آن را به عنوان انجام شده علامت بزنند. وظایف روی "Send" و "Store" نیز در حال انجام بودند.پس از اینکه "Send" و "Store" به پایان رسیدند، تنها چند وظیفه برای "Trash" و "Reply" باقی ماند.و سپس پروژه به اتمام رسید.کشف Scopeهانقشه‌برداری Scope برنامه‌ریزی نیست. شما باید زمین را بپیمایید قبل از اینکه بتوانید نقشه بکشید. Scopeهای درست ترسیم شده، گروه‌بندی‌های دلخواه یا دسته‌بندی‌ها صرفاً برای مرتب‌سازی نیستند. آنها حقیقت واقعی آنچه را که می‌تواند به طور مستقل انجام شود منعکس می‌کنند – یعنی وابستگی‌های متقابل و روابط زیربنایی در مسئله.Scopeها از وابستگی‌های متقابل ناشی می‌شوند. نحوه وابستگی بخش‌ها به یکدیگر تعیین می‌کند که چه زمانی می‌توانید بگویید یک بخش مشخص از کار "تمام شده" است. شما از پیش نمی‌دانید که کار و وابستگی‌های متقابل واقعاً چه هستند. ما قبلاً در مورد وظایف تصور شده در مقابل وظایف کشف شده صحبت کردیم. همین اصل در مورد Scopeها نیز صدق می‌کند. Scopeها باید با انجام کار واقعی و دیدن اینکه چگونه چیزها به هم متصل هستند یا نیستند، کشف شوند.به همین دلیل، در آغاز یک پروژه، انتظار نداریم Scopeهای دقیقی را ببینیم. احتمالاً آنها را در پایان هفته اول یا ابتدای هفته دوم، پس از اینکه تیم فرصت انجام کار واقعی را داشته و خطوط تقسیم‌بندی طبیعی در ساختار مسئله را پیدا کرده است، خواهیم دید.همچنین، طبیعی است که در ابتدا شاهد مقداری جابجایی و بی‌ثباتی در Scopeها باشیم. خطوط بازسازی می‌شوند یا Scopeها تغییر نام می‌دهند تا تیم محل واقعی مرزها را درک کند، مانند مثال بالا. تیم بر روی مشکلات خاص ذخیره و ویرایش پیش‌نویس‌ها تمرکز کرده بود، بنابراین شناسایی آن Scope در اوایل کار آسان‌تر بود. تنها زمانی که آنها وارد جزئیات و پیچیدگی‌های کار شدند، متوجه شدند که وظایفی به طور خاص مربوط به ارسال پیش‌نویس وجود دارد و آن را به یک Scope جداگانه تبدیل کردند.چگونه بفهمیم Scopeها درست هستندScopeهای خوب ساخته شده، ساختار (آناتومی) پروژه را نشان می‌دهند. وقتی در بدن خود دردی احساس می‌کنید، لازم نیست سوال کنید که آیا در بازوهایتان است یا پاهایتان یا سرتان. شما بخش‌ها و نام‌های آنها را می‌دانید تا بتوانید توضیح دهید درد کجاست. به همین ترتیب، هر پروژه یک ساختار طبیعی دارد که از طراحی مورد نظر شما، سیستمی که در آن کار می‌کنید، و وابستگی‌های متقابل مشکلاتی که باید حل کنید، ناشی می‌شود.سه نشانه نشان می‌دهد که Scopeها درست هستند:• شما احساس می‌کنید که می‌توانید کل پروژه را ببینید و هیچ چیز مهمی که شما را نگران می‌کند در جزئیات پنهان نیست.• مکالمات در مورد پروژه روان‌تر می‌شوند زیرا Scopeها زبان مناسبی را به شما می‌دهند.• وقتی وظایف جدیدی پیش می‌آید، می‌دانید کجا باید آنها را قرار دهید. Scopeها مانند سطل‌هایی عمل می‌کنند که به راحتی می‌توانید وظایف جدید را به آنها اضافه کنید.از سوی دیگر، این سه نشانه نشان می‌دهد که Scopeها باید بازطراحی شوند:• گفتن اینکه یک Scope چقدر "تمام شده" است، دشوار است. این اغلب زمانی اتفاق می‌افتد که وظایف داخل Scope بی‌ارتباط هستند. اگر مشکلات داخل Scope بی‌ارتباط باشند، اتمام یکی شما را به اتمام دیگری نزدیک‌تر نمی‌کند. در این حالت خوب است به دنبال چیزی باشید که بتوانید آن را تفکیک کنید، مانند مثال پیش‌نویس‌ها.• نام Scope خاص پروژه نیست، مانند "front-end" یا "bugs". ما اینها را "کیسه‌های شلوغ" (grab bags) و "کشوی خرت و پرت" (junk drawers) می‌نامیم. این نشان می‌دهد که شما به اندازه کافی یکپارچه‌سازی نمی‌کنید، بنابراین هرگز نمی‌توانید یک Scope را مستقل از بقیه "تکمیل شده" علامت بزنید. برای مثال، در مورد باگ‌ها، بهتر است آنها را تحت یک Scope خاص دسته‌بندی کنید تا بتوانید بدانید که آیا، برای مثال، Scope "Send" تمام شده است یا اینکه باید قبل از فراموش کردن آن، چند باگ را برطرف کنید.• Scope برای اتمام زودهنگام خیلی بزرگ است. اگر یک Scope بیش از حد بزرگ شود، با وظایف بسیار زیاد، مانند یک پروژه مستقل با تمام نقص‌های یک لیست To-do اصلی طولانی می‌شود. بهتر است آن را به بخش‌هایی تقسیم کنید که در زمان کمتری قابل حل هستند، تا پیروزی‌هایی در طول مسیر و مرزهایی بین مشکلاتی که باید حل شوند، وجود داشته باشد.بیایید این فصل را با چند نکته برای مقابله با انواع مختلف وظایف و Scopeهایی که پیش خواهند آمد، به پایان برسانیم.کیک‌های لایه‌ای (Layer cakes)بیشتر پروژه‌های نرم‌افزاری به مقداری طراحی UI و یک لایه نازک کد در زیر آن نیاز دارند. به یک اپلیکیشن پایگاه داده فکر کنید که در آن تنها کاری که باید انجام دهید وارد کردن اطلاعات، ذخیره آن و نمایش مجدد آن است. کاری مانند این شبیه یک کیک لایه‌ای به نظر می‌رسد: می‌توانید کار را بر اساس مساحت سطح UI قضاوت کنید زیرا کار Back-end کم و به طور یکنواخت توزیع شده است. در این موارد، می‌توانید تمام وظایف طراحی و برنامه‌نویسی را با هم در یک Scope یکپارچه کنید. این یک پیش‌فرض خوب برای بیشتر اپلیکیشن‌های نوع "سیستم اطلاعاتی" است.اما گاهی اوقات کار Back-end به طور قابل توجهی بیشتر از کار UI است و بالعکس. به عنوان مثال، یک قابلیت جدید که تنها به ارسال یک فرم نیاز دارد، ممکن است برای بازگرداندن پاسخ صحیح به منطق تجاری (business logic) بسیار پیچیده‌ای نیاز داشته باشد. این نوع کار مانند یک کوه یخ (iceberg) است.برای کوه‌های یخ، می‌تواند کمک‌کننده باشد که UI را به عنوان یک Scope کاری جداگانه تفکیک کنید (با فرض اینکه UI به پیچیدگی Back-end وابسته نیست). اگر Back-end به اندازه کافی پیچیده باشد، می‌توانید آن را به دغدغه‌های جداگانه تقسیم کنید و سپس آنها را نیز به Scope تبدیل کنید. هدف در چنین مواردی این است که چیزهای مختلفی را تعریف کنید که بتوانید آنها را در مراحل مختلف به اتمام رسانده و یکپارچه کنید، به جای اینکه تا دقیقه نود با امید اینکه همه چیز به هم متصل شود، منتظر بمانید.شما گاهی اوقات کوه‌های یخ وارونه را نیز مشاهده می‌کنید، جایی که حجم زیادی از پیچیدگی UI با پیچیدگی Back-end کمتری وجود دارد. به عنوان مثال، مدل داده برای یک تقویم پیچیده نیست، اما تعامل برای نمایش یک رویداد چند روزه و پیچاندن آن در سلول‌های Grid می‌تواند زمان زیادی و حل مسئله زیادی را ببرد.هم برای کوه‌های یخ Back-end و هم Front-end، ما همیشه قبل از پذیرش آنها به عنوان یک واقعیت، آنها را زیر سوال می‌بریم. آیا این پیچیدگی واقعاً ضروری و غیرقابل تقلیل است؟ آیا به آن UI فانتزی نیاز داریم؟ آیا راه دیگری برای ساخت آن فرآیند Back-end وجود دارد تا وابستگی‌های متقابل کمتری با بقیه سیستم داشته باشد؟چاوْدِر (Chowder)تقریباً همیشه چند مورد وجود دارد که در هیچ Scope‌ای جای نمی‌گیرند. ما به خودمان اجازه می‌دهیم یک لیست "Chowder" برای وظایف پراکنده‌ای که در هیچ‌جا جا نمی‌شوند، داشته باشیم. اما همیشه با نگاهی شکاک به آن نگاه می‌کنیم. اگر تعداد موارد آن از سه تا پنج مورد بیشتر شود، چیزی مشکوک است و احتمالاً یک Scope باید در جایی ترسیم شود.مشخص کردن موارد "اگر وقت شد خوب است" با علامت ~وظایف جدید دائماً با عمیق‌تر شدن شما در یک مسئله ظاهر می‌شوند. شما کدی را پیدا خواهید کرد که می‌توان آن را مرتب کرد، موارد خاص (edge cases) را برای رسیدگی، و بهبودهایی را در قابلیت‌های موجود. یک راه خوب برای مقابله با تمام این بهبودها این است که آنها را به عنوان وظایف در Scope ثبت کنید اما در ابتدای آنها یک علامت ~ قرار دهید. این به همه اعضای تیم اجازه می‌دهد تا به طور مداوم موارد ضروری (must-haves) را از موارد "اگر وقت شد خوب است" (nice-to-haves) جدا کنند.در دنیایی بدون مهلت، می‌توانستیم همه چیز را برای همیشه بهبود بخشیم. اما در یک بازه زمانی محدود (fixed time box)، ما به یک شمشیر (machete) در دستمان نیاز داریم تا Scope که دائماً در حال رشد است را کاهش دهیم. علامت ~ در ابتدای یک مورد، یا حتی یک Scope کامل، بهترین ابزار ما برای این کار است. ما به این تکنیک وقتی در مورد کاهش Scope در فصل ۱۴، "تصمیم بگیرید چه زمانی متوقف شوید"، صحبت کنیم، باز خواهیم گشت. علی کریمی علی کریمی Fri, 08 Aug 2025 17:51:38 +0330 https://virgool.io/@alikarimi/%DB%B1%DB%B0-%DB%8C%DA%A9-%D8%AA%DA%A9%D9%87-%D8%B1%D8%A7-%D8%AA%D9%85%D8%A7%D9%85-%DA%A9%D9%86%DB%8C%D8%AF-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-avxggadwmghu همزمان که تیم در حال جهت‌گیری و شروع به کار است، شروع به کشف و ردیابی وظایفی می‌کند که برای ساخت پروژه نیاز دارد. در این مرحله اولیه، خیلی مهم است که یک نقشه جامع از بخش‌هایی که باید در لحظه آخر کنار هم قرار بگیرند، ایجاد نکنند. اگر تیم کارهای زیادی را انجام دهد اما «یک چیز» قابل کلیک و تست کردن وجود نداشته باشد، احساس پیشرفت سخت است. یک تیم می‌تواند کارهای زیادی انجام دهد اما احساس ناامنی کند چون هنوز چیزی واقعی برای نمایش ندارد. خیلی چیزها «انجام شده‌اند» اما هیچ‌چیز واقعاً «تمام نشده» است.در عوض، آن‌ها باید هدفشان این باشد که چیزی ملموس و قابل دمو (Demoable) را زود – در همان هفته اول یا حدوداً – بسازند. این کار مستلزم ادغام عمودی روی یک تکه کوچک از پروژه است به جای اینکه لایه‌های افقی را کم‌کم انجام دهند.یک بخش را ادغام کنید.ما می‌توانیم پروژه‌ها را در دو لایه اصلی تصور کنیم: فرانت-اند (Front-end) و بک-اند (Back-end)، یا طراحی و کد. اگرچه از لحاظ فنی لایه‌های بیشتری وجود دارد، اما این دو چالش اصلی ادغام در بیشتر پروژه‌ها هستند. فرض کنید پروژه با طراحی زیادی شروع می‌شود. تیم می‌تواند صفحه‌های متنوعی را طراحی کند و حتی آن‌ها را به عنوان قالب (templates) یا نما (views) پیاده‌سازی کند. اما تا زمانی که آن‌ها به یک بک-اند متصل نشوند، هیچ‌چیزی کار نمی‌کند. کار فرضی و حدسی باقی می‌ماند.همین‌طور در مورد بک-اند. کارهای زیادی می‌توانند تیک بخورند، اما بدون هیچ رابط کاربری (UI) – چه کاری می‌توانید با آن انجام دهید؟ چطور قضاوت می‌کنید که کار روی یک تکه خاص از منطق کسب‌وکار (Business logic) واقعاً درست است بدون اینکه با آن تعامل داشته باشید؟آنچه ما در عوض می‌خواهیم این است که یک برش (slice) از پروژه را انتخاب کرده و آن را ادغام کنیم. سپس وقتی این کار انجام شد، تیم چیزی ملموس دارد که اثبات کرده‌اند کار می‌کند (یا کار نمی‌کند و باید بازنگری شود). هر کسی می‌تواند روی تعامل (interaction) کلیک کند و ببیند که آیا ویژگی (feature) کاری که باید را انجام می‌دهد و آیا کاری که می‌کند، همان چیزی است که آن‌ها می‌خواهند.مطالعه موردی:مشتریان در پروژه‌ها ما یک ویژگی در Basecamp 3 ساختیم که به شرکت‌های خدماتی اجازه می‌داد مشتریان را به پروژه‌هایشان دعوت کنند و اسناد، پیام‌ها یا لیست کارهای انتخاب شده را با آن‌ها به اشتراک بگذارند. مفهوم، که در طرح اولیه (pitch) تعریف شده بود، قسمت‌های متحرک مختلفی داشت:• دسترسی مشتری (Client Access): قبل از این ویژگی، مدل دسترسی Basecamp همه یا هیچ بود. ما به راهی نیاز داشتیم تا برخی افراد را دعوت کنیم تا فقط بخش‌هایی از یک پروژه را ببینند. این موضوع پیامدهای بزرگی برای بک-اند و کشینگ (caching) داشت.• مدیریت مشتری (Client Management): ما به راهی برای اضافه کردن مشتریان به پروژه‌ها و قابلیت مدیریت مشتریان به صورت جداگانه از اعضای تیم نیاز داشتیم.• سوئیچ دیداری (Visibility Toggle): هر بخش از محتوا در یک پروژه باید یک توگل (toggle) برای نمایش آن به مشتریان یا عدم نمایش آن داشته باشد.تیم متشکل از یک طراح و یک برنامه‌نویس بود. پس از اینکه آن‌ها جهت‌گیری کردند و با نحوه کار کد موجود آشنا شدند، طراح سوئیچ دیداری را به عنوان بهترین نقطه برای ادغام اولیه انتخاب کرد.این مرکزی‌ترین بخش رابط کاربری (UI) در پروژه بود. این همان چیزی بود که در ویدئوهای دمو ظاهر می‌شد و تعاملی بود که مشتریان بیشتر از آن استفاده می‌کردند. طراح یک ماک‌آپ (mockup) پیکسل به پیکسل (pixel-perfect) نساخت. در عوض، او با نشانه‌های تعاملی (affordances) و جایگاه‌های مختلف در قالب‌های HTML برنامه آزمایش کرد. آیا توگل باید دو دکمه رادیویی باشد، یک چک‌باکس، یا یک دکمه سفارشی که وضعیت خود را تغییر می‌دهد؟ در همین حین، برنامه‌نویس منتظر نماند. او از طرح اولیه (pitch) راهنمایی کافی برای شروع به بررسی مدل دسترسی (access model) داشت.به محض اینکه طراح در جهت‌گیری اصلی رابط کاربری (UI) اطمینان پیدا کرد، به برنامه‌نویس پیام داد و توگل ابتدایی (stubbed toggle) را به او نشان داد. برنامه‌نویس برای مدتی از مشکل دسترسی فاصله گرفت و توگل را به اندازه‌ای متصل (wired) کرد که روی تمام انواع محتوای پشتیبانی شده ظاهر شود، هنگام کلیک وضعیتش تغییر کند، و وضعیتش را در پایگاه داده (database) ذخیره کند.در این مرحله، توگل در واقع قابلیت دید محتوا را تغییر نمی‌داد. اما از دیدگاه شرکت خدماتی کار می‌کرد. طراح می‌توانست روی آن کلیک کند، آن را حس کند، و قضاوت کند که چقدر خوب با داده‌های زنده روی یک سرور استیجینگ (staging server) کار می‌کند. هنوز کارهای طراحی بیشتری روی توگل وجود داشت. اما برنامه‌نویس دیگر نیازی به درگیر شدن نداشت. با متصل شدن نشانه‌های تعاملی (affordance)، طراح می‌توانست به آزمایش با کپی (copy)، جایگذاری، رنگ، رندر (rendering) در نمای موبایل و موارد دیگر ادامه دهد. در همین حال، برنامه‌نویس می‌توانست به مدل دسترسی یا هر چیز مهم دیگری که باید انجام می‌شد، بازگردد.حدود سه روز پس از شروع پروژه، طراح توگل کارا را به یک مدیر نمایش داد (دمو کرد). مکالمه آن‌ها به چند تنظیمات (tweaks) بیشتر منجر شد و سپس آن‌ها توانستند توگل را «تمام شده» اعلام کنند. یک تکه مهم از پروژه طراحی، پیاده‌سازی، دمو و قطعی شد. تیم از نمایش پیشرفت ملموس احساس خوبی داشت. و تیم و مدیریت هر دو با دیدن یک بخش کارا، اعتماد به پروژه پیدا کردند.با کلیک کردن روی یک تعامل اصلی (core interaction) در مراحل اولیه، آن‌ها توانستند تأیید کنند که آنچه امیدوار بودند در تئوری منطقی باشد، در عمل نیز درست به نظر می‌رسید و منطقی بود.این مثال کوتاه چند نکته را در مورد نحوه ادغام تیم‌ها در دوره‌های کوتاه برای اتمام یک بخش از پروژه در هر بار، نشان می‌دهد.برنامه‌نویسان نیازی به انتظار ندارند.چون بخش‌های متحرک مهم قبلاً در فرآیند شکل‌دهی (shaping process) تعریف شده بودند، برنامه‌نویسان نیازی نیست هنگام شروع پروژه بیکار بمانند و منتظر طراحی باشند. راهنمایی کافی در طرح اولیه (pitch) برای آن‌ها وجود دارد تا از همان ابتدا روی مشکلات بک-اند کار کنند. آن‌ها نمی‌توانند یک تکه از قابلیت (functionality) را بدون دانستن اینکه در فرانت-اند به کجا منجر می‌شود، به اتمام برسانند، اما باید اطلاعات کافی در طرح اولیه برای تصمیمات مدل‌سازی اساسی (foundational modeling decisions) وجود داشته باشد.نشانه‌های تعاملی (Affordances) قبل از صفحه‌های پیکسل به پیکسل (pixel-perfect).برنامه‌نویسان برای شروع پیاده‌سازی نیازی به یک طراحی پیکسل به پیکسل ندارند. تنها چیزی که نیاز دارند، نقاط پایانی (endpoints) هستند: عناصر ورودی (input elements)، دکمه‌ها، مکان‌هایی که داده‌های ذخیره شده باید ظاهر شوند. این نشانه‌های تعاملی، هسته طراحی رابط کاربری هستند.سوالات در مورد فونت، رنگ، فاصله (spacing) و چیدمان (layout) می‌توانند پس از قرار گرفتن و اتصال (hooked up) نشانه‌های تعاملی خام در کد حل شوند. کپی‌رایتینگ (Copywriting)، نشانه‌های تعاملی اساسی و مقداری سیم‌کشی (wiring) تنها چیزی است که برای امتحان یک نسخه کارا و زنده در مرورگر یا روی دستگاه نیاز داریم. سپس می‌توانیم به سوالات اساسی در مراحل اولیه پاسخ دهیم: آیا منطقی است؟ آیا قابل درک است؟ آیا کاری که می‌خواهیم را انجام می‌دهد؟ این بدان معناست که اولین رابط کاربری که یک طراح به یک برنامه‌نویس می‌دهد، می‌تواند بسیار ابتدایی به نظر برسد، مانند مثال زیر. بیشتر شبیه یک برد بورد (breadboard) است تا یک طراحی بصری یا یک ماک‌آپ صیقلی.این اسکرین‌شات از یک برنامه ثبت‌نام برای دوره‌های چندروزه است. طراح آن را به صورت دستی در HTML ساخت. به سختی هیچ استایلی (style) وجود دارد – فقط به اندازه کافی سلسله‌مراتب بصری (visual hierarchy) برای اطمینان از اینکه چیدمان قابل استفاده است و برای لایه‌های آینده استایل‌دهی آماده است. در حالی که طراحی ساده به نظر می‌رسد، تصمیمات زیادی در آن منعکس شده است.• تصمیم برای درخواست زمان ورود اما نه زمان خروج، از بحث‌های دقیق در مورد منطق کسب‌وکار و مدل قیمت‌گذاری (pricing model) گرفته شده است.• گزینه‌های خاص در لیست کشویی (pulldown) زمان ورود، با قوانینی مطابقت دارند که باید در مورد زمان شارژ برای وعده‌های غذایی و اقامت شبانه تدوین می‌شد.• طراحی‌های اولیه طراح از یک انتخاب‌گر تاریخ (date picker) به سبک تقویم برای روزهای ورود و خروج استفاده می‌کرد. اما این به مشکلات تجربه کاربری (UX) منجر شد. برخی دوره‌ها طولانی بودند (چند هفته) با فازهای مختلف. در یک انتخاب‌گر تاریخ استاندارد به سبک تقویم، فضایی برای برچسب‌گذاری فازها روی جعبه‌های روز وجود نداشت. با یک لیست کشویی (pulldown)، او می‌توانست از گروه‌های گزینه (option groups) برای برچسب‌گذاری گروه‌های تاریخ در صورت نیاز استفاده کند. به این ترتیب کاربران نیازی به مراجعه به یک برنامه زمان‌بندی در جای دیگر نداشتند تا مطمئن شوند که تاریخ‌های درستی را انتخاب می‌کنند.در اینجا یک مثال دیگر آورده شده است. این اولین بخش کارا از یک برنامه برای گرفتن داده از مصاحبه‌های مشتری است.در این مرحله اولیه، نام پروژه (Basecamp) و موضوع مصاحبه (Jan) هاردکد (hard-coded) شده بودند و بیشتر لینک‌ها به جایی نمی‌رفتند. ببینید این طراحی چقدر خام (raw) است. اقدامات (actions) لینک‌های متنی ساده با رنگ‌های پیش‌فرض آبی و بنفش مرورگر هستند. جعبه‌های حاوی نقاط داده (data points) به سختی با حاشیه‌های سیاه ساده استایل داده شده‌اند.با این حال، همین طراحی خام، برخی از تبادلات مهم را آزمایش می‌کند. طراح انتخاب کرد که تا آنجا که ممکن است داده‌ها را در قسمت بالایی صفحه (above the fold) نشان دهد تا بررسی مصاحبه‌ها آسان باشد. این کار فضای کافی در هر بخش برای رابط کاربری (UI) برای اضافه کردن، ویرایش یا حذف نقاط داده باقی نگذاشت.این باعث شد طراح صفحه‌های جداگانه برای اضافه کردن و ویرایش داده‌ها در هر بخش ایجاد کند. این اولین طراحی برای اضافه کردن و ویرایش «پول‌ها» (pulls) – نوعی داده در این تکنیک مصاحبه – است. باز هم، ببینید چقدر خام است.فقط به اندازه کافی طراحی در اینجا وجود دارد تا به سرعت آن را متصل (wire up) کرده و آزمایش کنید. تیم می‌تواند روی این کلیک کند تا قضاوت کند که آیا ناوبری (navigating) به یک صفحه جداگانه برای ثبت داده‌ها قابل قبول است یا خیر. اگر کار کند، می‌توانند استایل‌دهی اضافی را بعداً اضافه کنند. اگر کار نکند، زمان زیادی را صرف پیاده‌سازی یک طراحی پیکسل به پیکسل نکرده‌اند.هم‌ترازی (alignment) زیبا، رنگ‌ها و تایپوگرافی (typography) در مرحله اول اهمیت ندارند. استایل‌دهی بصری در محصول نهایی مهم است، نه در مراحل اولیه. بزرگترین عدم قطعیت‌ها در مورد این است که آیا کار خواهد کرد، آیا منطقی خواهد بود، و پیاده‌سازی آن چقدر سخت خواهد بود. پس از اتصال عناصر، می‌توان آن‌ها را دوباره مرتب کرد (rearranged)، دوباره استایل داد (restyled)، و دوباره رنگ کرد (repainted) تا کار انجام شده بهبود یابد. اول کاری کنید که کار کند، سپس آن را زیبا کنید.فقط به اندازه کافی برای مرحله بعد برنامه‌نویسی کنید.همین امر در مورد کار بک-اند نیز صدق می‌کند. لازم نیست همه یا هیچ باشد. گاهی اوقات یک طراح فقط به یک اسکلت‌بندی (scaffolding) نیاز دارد – چند فیلد که داده‌ها را ذخیره می‌کنند یا مقداری کد برای ناوبری از یک صفحه ابتدایی (stubbed screen) به دیگری. در مواقع دیگر، او نیاز دارد تا یک متغیر را در قالب (template) با مجموعه‌ای از داده‌های واقعی پر کند تا بتواند روی نمایش‌های مختلف (ردیف‌ها، ستون‌ها، جعبه‌های رسانه و غیره) تکرار (iterate) کند تا بهترین طراحی را پیدا کند. کار اولیه بک-اند می‌تواند به صورت استراتژیک پراکنده (patchy) باشد.ممکن است یک کنترلر (controller) برای رندر (render) قالب‌ها وجود داشته باشد اما مدلی (model) نباشد. یا یک کنترلر و بخش‌هایی از یک مدل با داده‌های ساختگی (mock data) اما بدون پشتیبانی برای ایجاد یا به‌روزرسانی داده‌ها. صفحه‌هایی که هنوز متصل نیستند، می‌توانند حداقل با مسیرها (routes) برای ناوبری بین آن‌ها متصل شوند.هنگامی که زمان تست اولین تکه از برنامه مصاحبه رسید، تیم می‌دانست که داده‌های حساسی از مصاحبه‌های واقعی وارد آن خواهد شد. آن‌ها نیاز داشتند که آن را با نوعی احراز هویت (authentication) محافظت کنند. به جای ساخت پشتیبانی کامل از نام کاربری و رمز عبور – یا حتی ادغام یک راهکار شخص ثالث – آن‌ها فقط از HTTPAuth ساده برای هاردکد کردن یک رمز عبور استفاده کردند.این به تیم اجازه داد تا افزودن داده‌ها از مصاحبه‌های واقعی را خیلی زود در چرخه کاری امتحان کند، بدون اینکه برای اتصال کد احراز هویتی که هیچ‌چیزی در مورد مشکلاتی که سعی در حل آن داشتند به آن‌ها یاد نمی‌داد، کند شوند. نکته اصلی این است که یک تعامل رفت و برگشتی (back-and-forth) بین طراحی و برنامه‌نویسی روی یک تکه از محصول ایجاد کنید. به جای یک تحویل بزرگ، به نوبت افزودن تدریجی نشانه‌های تعاملی، کد، و سبک‌دهی بصری را انجام دهید. گام به گام، روی ویژگی واقعی در حال پیشرفت (feature-in-progress) کلیک کنید تا قضاوت کنید که چگونه پیش می‌رود و قدم بعدی چیست.از میانه (وسط) شروع کنید.در مثال‌های بالا، تیم ابتدا لاگین (log in) را نساخت. آن‌ها قبل از حل مشکل اضافه کردن داده‌های مصاحبه، راهی برای ایجاد یک پروژه مصاحبه و یک موضوع مصاحبه نساختند. آن‌ها مستقیماً به میانه (وسط) پریدند، جایی که مشکل جالب بود، و همه چیزهای دیگر را موقتی (stubbed) کردند تا به آن برسند.برای بسط این موضوع، سه معیار برای انتخاب اینکه چه چیزی را اول بسازید، در نظر بگیرید:اول، باید اصلی (core) باشد. سوئیچ دیداری (visibility toggle) در مفهوم «مشتریان در پروژه‌ها» اصلی بود. بدون آن، کارهای دیگر بی‌معنی می‌شدند. این را با یک جنبه جانبی‌تر از پروژه مقایسه کنید، مانند قابلیت تغییر نام مشتری. هر دو «مورد نیاز» بودند، اما یکی مرکزی‌تر و مهم‌تر بود که در مراحل اولیه چرخه کاری اثبات شود. در برنامه مصاحبه، ثبت داده‌های مصاحبه اصلی‌تر – بیشتر در میانه – از راه‌اندازی یک پروژه تحقیقاتی جدید بود.دوم، باید کوچک (small) باشد. اگر اولین بخش کار به اندازه کافی کوچک نباشد، فایده زیادی در جدا کردن آن از بقیه وجود ندارد. هدف این است که چیزی معنادار را در چند روز به پایان برسانید و شتاب ایجاد کنید – داشتن چیزی واقعی برای کلیک کردن که نشان دهد تیم در مسیر درست است.سوم، باید نوآورانه (novel) باشد. اگر دو بخش از پروژه هم اصلی (core) و هم کوچک (small) هستند، چیزی را ترجیح دهید که هرگز قبلاً انجام نداده‌اید. در ویژگی «مشتریان در پروژه‌ها»، رابط کاربری (UI) برای اضافه کردن مشتریان تقریباً مشابه رابط کاربری برای اضافه کردن کاربران عادی بود. شروع با آن پروژه را به جلو می‌برد، اما به تیم چیزی یاد نمی‌داد. عدم قطعیت را از بین نمی‌برد. شروع با سوئیچ دیداری اعتماد همه را بالا برد زیرا ثابت کرد که یک ایده جدید کار خواهد کرد. علی کریمی علی کریمی Fri, 08 Aug 2025 17:51:05 +0330 https://virgool.io/@alikarimi/%DB%B9-%D9%88%D8%A7%DA%AF%D8%B0%D8%A7%D8%B1%DB%8C-%D9%85%D8%B3%D8%A6%D9%88%D9%84%DB%8C%D8%AA-hand-over-responsibility-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-a4p8fxorrogb ما شرط‌هایمان را بستیم و اکنون زمان آن است که چرخه بعدی را آغاز کنیم. تیم چگونه شروع به کار می‌کند؟پروژه‌ها را واگذار کنید، نه وظایف (tasks)ما با واگذاری وظایف (tasks) به کسی شروع نمی‌کنیم. هیچ‌کس نقش «وظیفه دهنده» یا «معمار» را بازی نمی‌کند که پروژه را برای اجرا توسط دیگران به قطعات تقسیم کند.تقسیم پروژه به وظایف (tasks) از ابتدا، مانند این است که طرح (pitch) را از یک کاغذ خردکن رد کنید. همه فقط قطعات جدا شده را دریافت می‌کنند. ما می‌خواهیم پروژه در طول کل فرآیند «کامل» باقی بماند تا هرگز تصویر بزرگتر را از دست ندهیم.در عوض، ما به تیم اعتماد می‌کنیم که کل پروژه را بر عهده بگیرد و در محدوده طرح (pitch) کار کند. تیم وظایف (tasks) و رویکرد خود را برای کار تعریف خواهد کرد. آن‌ها استقلال کامل خواهند داشت و از قضاوت خود برای اجرای طرح (pitch) به بهترین شکل ممکن استفاده خواهند کرد.تیم‌ها عاشق آزادی بیشتر برای پیاده‌سازی یک ایده به روشی هستند که خودشان بهترین می‌دانند. افراد با استعداد دوست ندارند مانند «code monkeys» یا مسئولین تیکت رفتار شوند.پروژه‌ها همچنین زمانی بهتر پیش می‌روند که به تیم مسئولیت مراقبت از کل کار داده شود. هیچ‌کس نمی‌تواند در ابتدای یک پروژه پیش‌بینی کند که دقیقاً چه کاری باید انجام شود تا همه قطعات به درستی در کنار هم قرار گیرند. آنچه روی کاغذ کار می‌کند تقریباً هرگز دقیقاً همانطور که در عمل طراحی شده، کار نمی‌کند. طراحان و برنامه‌نویسانی که کار واقعی را انجام می‌دهند در بهترین موقعیت برای اعمال تغییرات و تنظیمات یا تشخیص قطعات گم‌شده هستند.هنگامی که وظایف (tasks) فردی به تیم‌ها واگذار می‌شود، هر فرد می‌تواند قطعه کوچک خود را بدون احساس مسئولیت برای قضاوت در مورد اینکه چگونه همه قطعات با هم هماهنگ می‌شوند، اجرا کند. برنامه‌ریزی از پیش شما را نسبت به واقعیت در طول مسیر کور می‌کند.به یاد داشته باشید: ما به تیم‌ها آزادی مطلق برای ابداع یک راه‌حل از صفر را نمی‌دهیم. ما شکل‌دهی (shaping) را انجام داده‌ایم. ما مرزها را تعیین کرده‌ایم. اکنون قرار است به تیم اعتماد کنیم تا طرح کلی (outline) از طرح (pitch) را با تصمیمات واقعی طراحی و پیاده‌سازی پر کند.اینجاست که تلاش‌های ما برای تعریف پروژه در سطح انتزاعی مناسب – بدون جزئیات زیاد – نتیجه می‌دهد. با استعداد و دانش خود از جزئیات، تیم به محصول نهایی بهتری دست خواهد یافت تا آنچه ما می‌توانستیم با تلاش برای تعیین فرم نهایی از پیش به دست آوریم.اتمام کار به معنای استقرار (deployed) استدر پایان چرخه، تیم کار خود را استقرار (deploy) خواهد داد. در مورد یک تیم Small Batch با چند پروژه کوچک برای چرخه، آن‌ها هر یک را به صلاحدید خود تا زمانی که قبل از پایان چرخه اتفاق بیفتد، استقرار (deploy) خواهند داد.این محدودیت ما را به شرط‌بندی‌هایمان وفادار نگه می‌دارد و به Circuit Breaker احترام می‌گذارد. پروژه باید در زمان بودجه‌بندی شده ما انجام شود؛ در غیر این صورت، تمایل و بودجه ما بی‌معنی خواهد بود.این همچنین بدان معنی است که هرگونه آزمایش و QA (کنترل کیفیت) باید درون چرخه اتفاق بیفتد. تیم با محدود کردن (scoping off) ضروری‌ترین جنبه‌های پروژه، به پایان رساندن آن‌ها زودتر، و هماهنگی با QA این را فراهم خواهد کرد. (بیشتر در این باره بعداً توضیح داده خواهد شد.)برای اکثر پروژه‌ها، ما در مورد زمان‌بندی مستندات راهنما، به‌روزرسانی‌های بازاریابی، یا اطلاعیه‌ها به مشتریان سخت‌گیر نیستیم و انتظار نداریم که این‌ها در طول چرخه اتفاق بیفتند. این‌ها از منظر ریسک «دم-نازک» (thin-tailed) هستند (یعنی هرگز 5 برابر بیشتر از آنچه فکر می‌کنیم طول نمی‌کشند) و عمدتاً توسط تیم‌های دیگر مدیریت می‌شوند. ما اغلب به این به‌روزرسانی‌ها رسیدگی می‌کنیم و یک اطلاعیه درباره ویژگی جدید را در طول Cool-down پس از چرخه منتشر می‌کنیم.شروع کار (Kick-off)ما پروژه را با ایجاد یک پروژه Basecamp جدید و اضافه کردن تیم به آن آغاز می‌کنیم. سپس اولین کاری که انجام می‌دهیم، ارسال مفهوم شکل‌دهی شده (shaped concept) به تابلوی پیام (Message Board) است. ما یا طرح (pitch) اصلی یا یک نسخه خلاصه‌شده (distilled) از آن را ارسال خواهیم کرد.اولین چیز در پروژه Basecamp یک پیام با مفهوم شکل‌دهی شده (shaped concept) استاز آنجایی که تیم‌های ما از راه دور هستند، ما از اتاق چت در پروژه Basecamp برای ترتیب دادن یک تماس شروع کار (kick-off call) استفاده می‌کنیم.ترتیب دادن یک تماس با تیم برای مرور کار شکل‌دهی شده (shaped work)این تماس به تیم فرصت می‌دهد تا هرگونه سؤال مهمی که از متن نوشته شده (write-up) واضح نیست را بپرسد. سپس، با درک تقریبی از پروژه، آن‌ها آماده شروع کار هستند.آشنایی با محیط (Getting oriented)کار در چند روز اول شبیه «کار» نیست. هیچ‌کس وظایف (tasks) را علامت نمی‌زند. چیزی استقرار (deployed) نمی‌شود. هیچ خروجی (deliverables) برای مشاهده وجود ندارد. اغلب حتی ارتباط زیادی بین اعضای تیم در چند روز اول وجود ندارد. ممکن است نوع عجیبی از سکوت رادیویی وجود داشته باشد.چرا؟ زیرا هر فردی سر خود را پایین انداخته و در تلاش است تا بفهمد سیستم موجود چگونه کار می‌کند و کدام نقطه شروع بهترین است. همه مشغول یادگیری اوضاع و آشنایی با محیط هستند.تیم در حال یافتن نقطه شروعبرای مدیران مهم است که به این مرحله احترام بگذارند. تیم‌ها نمی‌توانند بلافاصله وارد یک پایگاه کد (code base) شوند و شروع به ساخت قابلیت‌های جدید کنند. آن‌ها باید با کد مربوطه آشنا شوند، طرح (pitch) را با دقت بررسی کنند و برخی از بن‌بست‌های کوتاه را طی کنند تا یک نقطه شروع پیدا کنند. دخالت کردن یا درخواست وضعیت (status) از آن‌ها خیلی زود به پروژه آسیب می‌زند. این کار زمانی را از تیم می‌گیرد که برای یافتن بهترین رویکرد به آن نیاز دارند. کاوش به هر حال باید اتفاق بیفتد. درخواست پیشرفت قابل مشاهده تنها آن را به زیرزمین می‌برد. بهتر است به تیم قدرت دهیم تا صراحتاً بگویند «هنوز دارم می‌فهمم چگونه شروع کنم» تا مجبور نباشند این کار مشروع را پنهان یا disguised کنند.به طور کلی، اگر سکوت پس از سه روز شروع به شکستن نکرد، آن زمان مناسبی است که وارد عمل شوید و ببینید چه خبر است.وظایف (tasks) فرضی در مقابل وظایف (tasks) کشف شدهاز آنجایی که به تیم پروژه و نه وظایف (tasks) داده شده است، آن‌ها باید خودشان وظایف (tasks) را ابداع کنند. در اینجا ما به تفاوت مهمی بین وظایفی که فکر می‌کنیم در ابتدای یک پروژه باید انجام دهیم و وظایفی که کشف می‌کنیم در حین انجام کار واقعی باید انجام دهیم، اشاره می‌کنیم.تیم به طور طبیعی با برخی وظایف (tasks) فرضی شروع می‌کند – آنهایی که صرفاً با فکر کردن به مشکل، فرض می‌کنند باید انجام دهند. سپس، با شروع کار عملی، انواع چیزهای دیگری را کشف می‌کنند که از قبل نمی‌دانستیم. این جزئیات غیرمنتظره بدنه اصلی پروژه را تشکیل می‌دهند و گاهی اوقات سخت‌ترین چالش‌ها را به وجود می‌آورند.تیم‌ها با انجام کار واقعی وظایف (tasks) را کشف می‌کنند. برای مثال، طراح یک دکمه جدید روی رابط دسکتاپ اضافه می‌کند اما سپس متوجه می‌شود که جای واضحی برای آن در نسخه وب‌ویو موبایل وجود ندارد. آن‌ها یک وظیفه (task) جدید ثبت می‌کنند: فهمیدن چگونگی نمایش دکمه در موبایل. یا اولین نسخه از طراحی دارای سلسله مراتب بصری خوبی است، اما سپس طراح متوجه می‌شود که نیاز به متن توضیحی بیشتری در مکانی دارد که طرح (layout) را به هم می‌زند. دو وظیفه (task) جدید: تغییر طرح (layout) برای جای دادن متن توضیحی؛ نوشتن متن توضیحی.اغلب یک وظیفه (task) در فرآیند انجام کاری نامرتبط ظاهر می‌شود. فرض کنید یک برنامه‌نویس در حال کار بر روی مهاجرت پایگاه داده (database migration) است. هنگام نگاه کردن به مدل (model) برای درک ارتباطات (associations)، ممکن است با یک متد (method) مواجه شود که نیاز به به‌روزرسانی برای قسمت دیگری از پروژه در آینده دارد. او می‌خواهد یک وظیفه (task) برای به‌روزرسانی آن متد (method) بعداً یادداشت کند.راه واقعی برای فهمیدن اینکه چه کاری باید انجام شود، شروع به انجام کار واقعی است. این به معنای آن نیست که تیم‌ها با ساخت هر چیزی شروع می‌کنند. آن‌ها باید ابتدا چیزی معنادار برای ساخت انتخاب کنند. چیزی که مرکزی برای پروژه باشد و در عین حال به اندازه کافی کوچک باشد تا به صورت end-to-end – با UI (رابط کاربری) کارآمد و کد کارآمد – در چند روز انجام شود.در فصل‌های بعدی به این خواهیم پرداخت که تیم چگونه آن هدف را انتخاب می‌کند و با هم کار می‌کند تا یک spike کاملاً یکپارچه (integrated) را به مرحله اجرا برساند. علی کریمی علی کریمی Fri, 08 Aug 2025 17:50:11 +0330 https://virgool.io/@alikarimi/%DB%B8-%D8%B4%D8%B1%D8%B7-%D8%A8%D9%86%D8%AF%DB%8C-%D9%87%D8%A7%DB%8C%D8%AA%D8%A7%D9%86-%D8%B1%D8%A7-%D8%A7%D9%86%D8%AC%D8%A7%D9%85-%D8%AF%D9%87%DB%8C%D8%AF-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-bo21kywps9mm جایگاه خود را بشناسیدبسته به اینکه در حال بهبود یک محصول موجود هستیم یا در حال ساخت محصولی جدید، انتظارات متفاوتی در مورد آنچه در طول چرخه شش هفته‌ای اتفاق می‌افتد، خواهیم داشت.این موضوع ما را به تأمل در جایگاه خود در مسیر توسعه محصول دعوت می‌کند تا بر اساس آن، تصمیم‌گیری کنیم.محصولات موجودهنگامی که قابلیت‌های جدیدی را به یک محصول موجود اضافه می‌کنیم، فرآیند استاندارد Shape Up را دنبال می‌کنیم: شکل‌دهی به کار، شرط‌بندی (تخصیص زمان و منابع) بر روی آن، و سپردن آن به یک تیم برای ساخت. انتظار داریم تیم تا پایان چرخه، نسخه‌ای از کار شکل‌دهی شده را تکمیل و عرضه کند.در مورد یک محصول موجود، تمام کد و طراحی موجود که قرار نیست تغییر کند، نوعی فضای خالی را تعریف می‌کند که قابلیت جدید در آن جای خواهد گرفت. شکل‌دهی و ساخت در این حالت، شبیه به ساختن یک قطعه مبلمان برای خانه‌ای است که از قبل ساخته شده است.محصولات جدیدمحصولات جدید متفاوت هستند. در حالی که اضافه کردن به یک محصول موجود مانند خرید یک کاناپه برای اتاقی با ابعاد ثابت است، توسعه محصول جدید مانند کشف محل قرارگیری دیوارها و فونداسیون است تا ساختمان بتواند سرپا بماند.ما سه فاز کاری را هنگام ساخت یک محصول جدید از ابتدا مشاهده کرده‌ایم. در هر فاز، نحوه شکل‌دهی و انتظارات ما در مورد نحوه کار تیمی در طول چرخه، متفاوت است. این فازها در طول چندین چرخه اتفاق می‌افتند، اما ما همچنان فقط یک چرخه را در هر بار شرط‌بندی (تخصیص زمان و منابع) می‌کنیم.حالت R&D (تحقیق و توسعه)در اولین مراحل یک محصول جدید، ایده ما فقط یک نظریه یا یک جرقه است. ما نمی‌دانیم آیا مجموعه قابلیت‌هایی که تصور می‌کنیم در واقعیت منسجم خواهند بود یا خیر، و تصمیمات فنی در مورد نحوه مدل‌سازی آن‌ها در کد، حتی کمتر روشن هستند.این به معنای وجود مقدار زیادی کار ضایعاتی است. ممکن است در نیمه راه پیاده‌سازی یک قابلیت تصمیم بگیریم که آن چیزی نیست که می‌خواهیم و به جای آن رویکرد دیگری را امتحان کنیم.به عبارت دیگر، ما نمی‌توانیم به طور قابل اعتماد از قبل آنچه را می‌خواهیم شکل‌دهی کنیم و بگوییم: "این چیزی است که ما می‌خواهیم. انتظار داریم پس از شش هفته آن را عرضه کنیم.". ما باید با ساختن آن یاد بگیریم که چه می‌خواهیم.ما این مرحله را حالت R&D می‌نامیم و به سه روش آن را تنظیم می‌کنیم.• به جای شرط‌بندی (تخصیص زمان و منابع) بر روی یک pitch (پیشنهاد) به خوبی شکل‌دهی شده، عمدتاً زمان را برای اسپایکینگ (بررسی و نمونه‌سازی اولیه) برخی از قطعات کلیدی ایده محصول جدید شرط‌بندی (تخصیص) می‌کنیم. شکل‌دهی در این مرحله بسیار مبهم‌تر است زیرا انتظار داریم با ساختن یاد بگیریم.• به جای واگذاری کار به یک تیم ساخت جداگانه، افراد ارشد ما تیم را تشکیل می‌دهند. دیوید (CTO) نقش برنامه‌نویسی را بر عهده می‌گیرد و با جیسون (CEO و طراح) یا یک طراح ارشد با راهنمایی جیسون کار می‌کند. این موضوع به دو دلیل ضروری است. اولاً، وقتی خودتان نمی‌دانید چه می‌خواهید، نمی‌توانید کار را به دیگران واگذار کنید. ثانیاً، تصمیمات معماری تعیین‌کننده آنچه در آینده محصول امکان‌پذیر خواهد بود هستند – آن‌ها "سوراخ‌هایی" را تعریف می‌کنند که قابلیت‌های آینده در آن‌ها جای می‌گیرند. در این فاز، تیم باید دیدگاه محصول را حفظ کند و بتواند تأثیرات بلندمدت تصمیمات طراحی را ارزیابی کند.• در نهایت، انتظار نداریم در پایان یک چرخه R&D چیزی را عرضه کنیم. هدف اسپایکینگ (بررسی و نمونه‌سازی اولیه) است، نه عرضه. در بهترین حالت، مقداری UI (رابط کاربری) و کد خواهیم داشت که به عنوان پایه‌ای برای کارهای بعدی عمل می‌کند. هدف این است که یاد بگیریم چه چیزی کار می‌کند تا بتوانیم به یک ساختار باربر (load-bearing structure) متعهد شویم: تصمیمات اصلی کد و UI که فرم محصول را در آینده تعریف خواهند کرد.ما نمی‌توانیم تنها با یک چرخه کار R&D چیزی را به مشتریان عرضه کنیم. اما همچنان بیش از یک چرخه را در یک زمان متعهد نمی‌شویم. ممکن است از چرخه اول متوجه شویم که هنوز آماده پرداختن به محصول نیستیم. یا ممکن است کشف کنیم که شهود ما درست بوده و محصول در حال شکل‌گیری است. بسته به اینکه چگونه پیش می‌رود، چرخه به چرخه تصمیم می‌گیریم که آیا زمان غیررسمی را در حالت R&D ادامه دهیم یا خیر.حالت Production (تولید)اگر پس از چند چرخه R&D همچنان "گرم‌تر" (نزدیک‌تر به موفقیت) شویم، در نهایت به نقطه‌ای می‌رسیم که مهم‌ترین تصمیمات معماری اتخاذ شده‌اند. محصول آن چند کار اساسی را که آن را تعریف می‌کنند، انجام می‌دهد، و پایه و اساس برای ده‌ها کار دیگری که باید قبل از عرضه به مشتریان انجام دهیم، گذاشته شده است.با وجود این ساختار، تیم ارشد می‌تواند افراد دیگری را برای مشارکت وارد کند. این همان تغییر به حالت Production (تولید) است، جایی که در چرخه‌های رسمی با فازهای شکل‌دهی، شرط‌بندی و ساخت مشخص کار می‌کنیم. حالت Production مانند کار بر روی یک محصول موجود است: سابقه تعیین شده توسط کار R&D به مشارکت‌کنندگان جدید امکان می‌دهد تا تشخیص دهند که عملکرد جدید در کجا قرار می‌گیرد و چگونه با کل سیستم هماهنگ می‌شود.در حالت Production:• شکل‌دهی دوباره عمدی است. کار شکل‌دهی شده آنچه را که انتظار داریم در پایان چرخه ببینیم، توصیف می‌کند.• تیمی که پروژه‌ها را می‌سازد دیگر به گروه ارشد محدود نمی‌شود. امکان شرط‌بندی (تخصیص زمان و منابع) بر روی چندین تیم به طور موازی (اگر در دسترس باشند) و پوشش دادن زمینه‌های بیشتر فراهم می‌شود.• عرضه (shipping) هدف است، نه اسپایکینگ (spiking). اما چون محصول هنوز به صورت عمومی برای مشتریان در دسترس نیست، "عرضه" را متفاوت تعریف می‌کنیم. عرضه به معنای ادغام (merging) در پایگاه کد (codebase) اصلی و انتظار عدم نیاز به تغییر مجدد آن است.از آنجایی که ما در پایان هر چرخه به مشتریان چیزی عرضه نمی‌کنیم، گزینه حذف قابلیت‌ها از نسخه نهایی قبل از راه‌اندازی را حفظ می‌کنیم. این بدان معناست که ما هنوز می‌توانیم تجربی عمل کنیم. می‌توانیم شش هفته را برای یک قابلیت شرط‌بندی (تخصیص زمان) کنیم بدون اینکه بدانیم آیا آن را در محصول نهایی می‌خواهیم یا خیر. این مشکلی نیست تا زمانی که انتظارات را برای تیم ساخت تنظیم کنیم: ما نمی‌توانیم پیش‌بینی کنیم که در نسخه نهایی چه چیزی می‌خواهیم، و حاضریم این چرخه را به خطر بیندازیم تا بهترین تلاش خود را برای ایده انجام دهیم.حالت Cleanup (پاکسازی)در مرحله نهایی قبل از راه‌اندازی محصول جدید، ما تمام ساختار را کنار می‌گذاریم. ما این را حالت Cleanup (پاکسازی) می‌نامیم. این یک حالت بی‌قید و بند است (free-for-all). ما به اندازه کافی محصولات جدید ساخته‌ایم تا یاد بگیریم که همیشه چیزهایی هستند که فراموش می‌کنیم، چیزهایی که از دست می‌دهیم، جزئیاتی که درست نیستند، و باگ‌هایی که در طول چرخه‌های R&D و Production نفوذ می‌کنند.چیزی در مورد قرار دادن انگشت روی دکمه راه‌اندازی وجود دارد که مو را به تن سیخ می‌کند. همه چیز ناگهان "واقعی" می‌شود. چیزهایی که قبلاً نادیده می‌گرفتیم، با اهمیت جدیدی برایمان خودنمایی می‌کنند.به همین دلیل ما مقداری ظرفیت را در انتها برای موارد پیش‌بینی نشده در نظر می‌گیریم. در حالت Cleanup:• هیچ شکل‌دهی‌ای (shaping) وجود ندارد. این چرخه از نظر ماهیت به "حل سریع اشکالات" (bug smash) که در فصل قبلی ذکر شد، نزدیک‌تر است. رهبری در طول چرخه در رأس کار قرار می‌گیرد، توجه را به آنچه مهم است جلب می‌کند و حواس‌پرتی‌ها را از بین می‌برد.• مرزهای تیمی مشخصی وجود ندارد. همه برای کمک هر طور که می‌توانند، وارد عمل می‌شوند.• کار به طور مداوم و در کوچکترین قطعات ممکن "عرضه" (به پایگاه کد اصلی ادغام) می‌شود.انضباط همچنان مهم است. ما باید خودمان را کنترل کنیم تا مطمئن شویم روی موارد ضروری (must-have) کار می‌کنیم، نه فقط روی تردیدهایمان که ما را به تأخیر در راه‌اندازی ترغیب می‌کنند. Cleanup نباید بیشتر از دو چرخه طول بکشد.Cleanup همچنین مرحله‌ای است که رهبری تصمیمات "نسخه نهایی" را می‌گیرد. سطح (surface area) کوچکتر در یک V1 (نسخه اول) به معنای سوالات کمتر برای پاسخگویی، پشتیبانی کمتر، و تعهد کمتر برای نگهداری نامحدود است. گاهی اوقات لازم است همه قابلیت‌ها را به صورت یکپارچه ببینیم تا قضاوت کنیم که بدون چه چیزی می‌توانیم زندگی کنیم و چه چیزی ممکن است قبل از عرضه به مشتریان نیاز به بررسی عمیق‌تر داشته باشد.مثال‌هاتقویم Dot Gridما تقویم Dot Grid (به فصل 2 مراجعه کنید) را برای Basecamp، که یک محصول موجود است، ساختیم. پروژه را شکل‌دهی کردیم، شش هفته برای آن شرط‌بندی (تخصیص زمان) کردیم، یک تیم آن را ساخت، و سپس مستقیماً آن را به مشتریان عرضه کردیم.یک محصول جدید: HEYدر سال 2020، پس از دو سال توسعه، یک اپلیکیشن و سرویس ایمیل جدید به نام HEY را راه‌اندازی کردیم. HEY برای سال اول توسعه خود در حالت R&D قرار داشت. تیمی متشکل از سه نفر، جیسون (CEO)، دیوید (CTO) و یوناس (طراح ارشد)، طیف گسترده‌ای از ایده‌ها را قبل از استقرار بر روی هسته اصلی بررسی کردند. نزدیک به یک سال چرخه‌های حالت Production (تولید) دنبال شد، جایی که تمام تیم‌های Basecamp مجموعه قابلیت‌های HEY را تکمیل کردند. ما با دو چرخه Cleanup (پاکسازی) به پایان رسیدیم و به طور قابل توجهی مجموعه قابلیت‌ها را برای راه‌اندازی در جولای 2020 کاهش دادیم.به طور دقیق، همپوشانی بین حالت R&D و Production پس از آن سال اول وجود داشت. Basecamp به اندازه کافی شرکت بزرگی بود که تیم ارشد می‌توانست پروژه‌های حالت Production را در بخش‌هایی از برنامه که تثبیت شده بودند، شکل‌دهی و واگذار کند، در حالی که خودشان به کشف قلمروهای جدید در حالت R&D ادامه می‌دادند.هر شرط‌بندی (تخصیص زمان و منابع) بر روی HEY به صورت تک به تک انجام شد. "میز شرط‌بندی" (گروه تصمیم‌گیرنده) در طول آن چند چرخه اولیه R&D نمی‌دانست که قرار است دو سال روی HEY کار کند. به تدریج آن‌ها اعتماد به نفس در ایده پیدا کردند و "اشتهای" (میل و تمایل به سرمایه‌گذاری) بزرگ‌تری برای اینکه چند چرخه حاضرند روی HEY صرف کنند، پیدا کردند. اما هیچ تعهد مشخصی در مورد آنچه در آن چرخه‌ها قرار می‌گرفت، ندادند. و برگرداندن توجه به Basecamp، محصول موجود ما، همیشه روی میز بود.یک قابلیت آزمایشی: Hill Chartsمثال سوم یک منطقه خاکستری را نشان می‌دهد. وقتی قابلیت Hill Charts را در Basecamp ساختیم (به فصل 13 مراجعه کنید)، هیچ ایده‌ای نداشتیم که آیا کارساز خواهد بود یا خیر. Basecamp یک محصول موجود بود، و شرط‌بندی (تخصیص زمان و منابع) بر روی عرضه این قابلیت آزمایشی به مشتریان، بیش از حد خطرناک به نظر می‌رسید. بنابراین پروژه را بیشتر شبیه یک شرط‌بندی (تخصیص) در حالت Production بر روی یک محصول جدید چارچوب‌بندی کردیم. ما یک نسخه اولیه را شکل‌دهی کردیم که فقط به اندازه کافی برای استفاده خودمان کارآمد بود. انتظار نداشتیم آن را بدون انجام یک چرخه اضافی، به مشتریان عرضه کنیم. این یک ریسک بود: ما یک چرخه را شرط‌بندی (تخصیص) کردیم، نه دو چرخه. اگر کارساز نبود، آن را کنار می‌گذاشتیم. اگر چیز مهم‌تری پیش می‌آمد، ممکن بود هرگز چرخه دوم را برنامه‌ریزی نکنیم. اما در نهایت پس از چرخه اول احساس اطمینان کردیم. پروژه‌ای را برای تکمیل آن شکل‌دهی کردیم، تصمیم گرفتیم یک چرخه دیگر شرط‌بندی (تخصیص) کنیم، و سپس آن را به مشتریان عرضه کردیم.سوالاتی که باید پرسیددر اینجا برخی از سوالات رایجی که ممکن است از افراد در "میز شرط‌بندی" (گروه تصمیم‌گیرنده) بشنوید، زمانی که در مورد اینکه کدام پروژه‌ها را باید انتخاب کرد بحث می‌کنند، آورده شده است:آیا مشکل اهمیت دارد؟درست مانند نگارش pitch (پیشنهاد پروژه)، ما همیشه دقت می‌کنیم که مشکل و راه‌حل را از هم جدا کنیم. اگر مشکل ارزش حل کردن نداشته باشد، راه‌حل مهم نیست.البته، هر مشکلی که مشتریان را تحت تأثیر قرار دهد، اهمیت دارد. اما ما باید انتخاب‌هایی انجام دهیم زیرا همیشه مشکلات بیشتری نسبت به زمان برای حل آن‌ها وجود خواهد داشت. بنابراین، مشکلات را در برابر یکدیگر می‌سنجیم. آیا این مشکل در حال حاضر مهم‌تر از آن مشکل است؟نحوه قضاوت مشکلات توسط افراد حاضر در "میز" (گروه تصمیم‌گیرنده) به دیدگاه، نقش و دانش آن‌ها بستگی دارد. به عنوان مثال، یک مشکل ممکن است بخش کوچکی از مشتریان را تحت تأثیر قرار دهد اما بار نامتناسبی را بر پشتیبانی تحمیل کند. بسته به میزان مواجهه شما با پشتیبانی و اینکه بر کدام جنبه از کسب‌وکار تمرکز دارید، ممکن است این موضوع را متفاوت ارزیابی کنید.گاهی اوقات یک راه‌حل که بیش از حد پیچیده یا گسترده است، ممکن است سوالاتی را در مورد مشکل ایجاد کند. آیا واقعاً باید این همه تغییر در سراسر برنامه ایجاد کنیم؟ آیا مشکل را به اندازه کافی دقیق درک کرده‌ایم؟ شاید راهی برای محدود کردن آن وجود داشته باشد تا 80% سود را از 20% تغییر به دست آوریم.آیا اشتها (زمان و منابع تخصیص‌یافته) مناسب است؟خوب است که ما یک راه‌حل شکل‌دهی شده در یک بازه زمانی معقول، مانند دو یا شش هفته، داشته باشیم. اما ممکن است همچنان در مورد اینکه آیا ارزش آن زمان را دارد، بحث کنیم. فرض کنید یک ذینفع (stakeholder) می‌گوید علاقه‌ای به صرف شش هفته برای یک pitch (پیشنهاد) خاص ندارد. مذاکره می‌تواند از آنجا به چند جهت پیش برود:• شاید مشکل به اندازه کافی خوب بیان نشده باشد، و اطلاعاتی وجود دارد که شکل‌دهنده (shaper) می‌تواند همین الان به گفتگو اضافه کند تا نظر را تغییر دهد. به عنوان مثال، "بله، اغلب اتفاق نمی‌افتد، اما وقتی اتفاق می‌افتد، مردم به قدری در مورد آن صحبت می‌کنند که واقعاً وجهه ما را خدشه‌دار می‌کند." یا "شاید پیش پا افتاده به نظر برسد، اما پشتیبانی باید 11 مرحله زمان‌بر را طی کند تا به راه‌حل برسد."• گاهی اوقات گفتن "نه" به تعهد زمانی، در واقع گفتن نه به چیز دیگری است. شاید چیزی در مورد راه‌حل یا پیاده‌سازی فنی وجود دارد که آن‌ها دوست ندارند. پرسیدن "اگر می‌توانستیم آن را در دو هفته انجام دهیم چه حسی داشتید؟" می‌تواند نشان دهد که مسئله آنقدرها هم به زمان مربوط نیست. CTO ممکن است پاسخ دهد، "من نمی‌خواهم وابستگی دیگری را به آن بخش از برنامه وارد کنم."• اگر علاقه خیلی کم باشد، شکل‌دهنده (shaper) ممکن است ایده را رها کند.• شکل‌دهنده (shaper) ممکن است به میز طراحی (drawing table) بازگردد و یا روی یک نسخه کوچکتر (برای اشتهای کمتر) کار کند و یا تحقیقات بیشتری انجام دهد اگر معتقد است مشکل قانع‌کننده است اما به اندازه کافی برای ارائه آن آماده نبوده است.آیا راه‌حل جذاب است؟ممکن است مشکل مهم و "اشتها" (زمان و منابع تخصیص‌یافته) نیز مناسب باشد، اما درباره راه‌حل اختلاف‌نظر وجود داشته باشد.به عنوان مثال، اضافه کردن عناصر رابط کاربری به صفحه، هزینه‌ای نامرئی دارد: از دست دادن "فضای واقعی" (real estate). یک دکمه در گوشه صفحه اصلی ممکن است مشکل را کاملاً حل کند. اما آن فضای واقعی ارزشمند است. اگر اکنون آن را واگذار کنیم، در آینده نمی‌توانیم از آن استفاده کنیم. آیا ما آن را برای حل این مشکل خاص خیلی ارزان می‌فروشیم؟اگر کسی یک راه‌حل طراحی فوری ارائه دهد، مانند "چطور است آن دکمه را به جای آن به یک منوی اقدام منتقل کنیم،" ممکن است در مورد آن بحث کنیم. اما به طور کلی، ما از انجام کارهای طراحی یا بحث در مورد راه‌حل‌های فنی برای بیش از چند لحظه در "میز شرط‌بندی" (گروه تصمیم‌گیرنده) اجتناب خواهیم کرد. اگر متوجه شویم که بیش از حد در جزئیات (in the weeds) وقت می‌گذرانیم، به خودمان یادآوری می‌کنیم "خب، ما اینجا طراحی نمی‌کنیم" و به سطح بالا بازمی‌گردیم.آیا زمان مناسب است؟نوع پروژه‌ای که می‌خواهیم در مرحله بعد انجام دهیم، می‌تواند به پروژه‌هایی که اخیراً انجام داده‌ایم بستگی داشته باشد. شاید مدت زیادی است که با یک قابلیت جدید، خبری مهمی منتشر نکرده‌ایم. یا شاید قابلیت‌های جدید زیادی ساخته‌ایم و احساس می‌کنیم که زمان رفع برخی درخواست‌های مشتریان دیرینه فرا رسیده است. یا اگر تیم‌ها دو چرخه اخیر را در یک بخش از برنامه گذرانده‌اند، اگر ما پروژه دیگری از همان نوع کار را برنامه‌ریزی کنیم، روحیه آن‌ها ممکن است افت کند.همه این‌ها دلایلی هستند که ممکن است یک پروژه را رد کنیم، حتی اگر به خوبی شکل‌دهی شده و ارزشمند باشد. پروژه عالی است؛ فقط زمان مناسب نیست.آیا افراد مناسب در دسترس هستند؟به عنوان بخشی از فرآیند شرط‌بندی (تخصیص زمان و منابع)، ما به طور خاص انتخاب می‌کنیم که چه کسی چه نقشی را در هر تیم ایفا خواهد کرد. یعنی، یک پروژه را با یک تیم کوچک خاص متشکل از یک طراح و یک یا دو برنامه‌نویس جفت می‌کنیم. ما یک تیم "محصول اصلی" (Core Product) متشکل از طراحان و برنامه‌نویسان داریم و هنگام برنامه‌ریزی تیم‌ها برای هر چرخه از آن مجموعه انتخاب می‌کنیم. تیم برای کل چرخه با یکدیگر کار خواهد کرد و سپس چرخه بعدی می‌تواند ترکیبی متفاوت از افراد باشد.پروژه‌های مختلف به تخصص‌های متفاوتی نیاز دارند. شاید برای این یکی به برنامه‌نویسی فرانت‌اند (front-end) بیشتری نیاز داشته باشیم. یا این یکی دیگر قرار است باعث "افزایش دامنه" (scope creep) زیادی شود، بنابراین به کسی نیاز داریم که در "محدود کردن دامنه" (scope hammer) خوب باشد.نوع کاری که هر شخص انجام داده است نیز عامل دیگری است. کسی که رشته طولانی از پروژه‌های "بچ کوچک" (small batch) را انجام داده است، ممکن است ترجیح دهد یک "بچ بزرگ" (big batch) را به عهده بگیرد، یا برعکس.و در نهایت، همیشه کمی "تقویم تتریس" (Calendar Tetris - برنامه‌ریزی پیچیده بر اساس زمان‌بندی افراد) با در دسترس بودن افراد وجود دارد. تعطیلات یا مرخصی‌های بلندمدت (sabbaticals) بر پروژه‌هایی که می‌توانیم در چرخه آینده برنامه‌ریزی کنیم، تأثیر می‌گذارد.ما دیده‌ایم که برخی شرکت‌های دیگر از مدلی متفاوت استفاده می‌کنند که به جای اختصاص پروژه‌ها به افراد، به اعضای تیم اجازه می‌دهند پروژه‌هایی را که می‌خواهند روی آن‌ها کار کنند، انتخاب کنند. از نظر فرهنگی، ما بیش از حد از جلسات گریزان هستیم که این مرحله اضافی را انجام دهیم. اما شنیده‌ایم که برای برخی تیم‌ها می‌تواند به خوبی کار کند زیرا تیم‌های پروژه کمی بیشتر "با انگیزه" (buy-in) هستند.پیام شروع را منتشر کنیدپس از انجام شرط‌بندی‌ها (تصمیم‌گیری‌ها)، یکی از اعضای "میز شرط‌بندی" (گروه تصمیم‌گیرنده) پیامی می‌نویسد که به همه می‌گوید برای چرخه بعدی روی کدام پروژه‌ها شرط‌بندی کرده‌ایم و چه کسانی روی آن‌ها کار خواهند کرد.تصویر: جیسون (Jason) تصمیمات گرفته شده برای چرخه‌ی بعدی را با یک پیام Basecamp اعلام می‌کند.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:49:31 +0330 https://virgool.io/@alikarimi/%DB%B7-%D9%85%DB%8C%D8%B2-%D8%B4%D8%B1%D8%B7%D8%A8%D9%86%D8%AF%DB%8C-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-asqckpqb5hmw حالا که تعدادی شرط‌بندی (bets) بالقوه خوب در قالب «پیشنهاد» (pitches) داریم، زمان آن رسیده است که در مورد اینکه کدام پروژه‌ها را برنامه‌ریزی کنیم، تصمیم بگیریم.چرخه‌های شش هفته‌ایتعهد دادن زمان و نیروی انسانی دشوار است اگر نتوانیم به راحتی تعیین کنیم چه کسی و برای چه مدت در دسترس است. هنگامی که افراد به دلیل پروژه‌های هم‌پوشاننده در زمان‌های مختلفی در دسترس هستند، برنامه‌ریزی پروژه به یک بازی آزاردهنده «تتریس تقویمی» (Calendar Tetris) تبدیل می‌شود. کار کردن در چرخه‌ها این مشکل را به شدت ساده می‌کند. یک چرخه به ما یک اندازه استاندارد برای پروژه، هم برای شکل‌دهی (shaping) و هم برای برنامه‌ریزی (scheduling) می‌دهد.برخی شرکت‌ها از چرخه‌های دو هفته‌ای (که به آن‌ها "اسپرینت" (sprints) نیز می‌گویند) استفاده می‌کنند. ما دریافتیم که دو هفته برای انجام هر کار معناداری خیلی کوتاه است. بدتر از آن، چرخه‌های دو هفته‌ای به دلیل سربار (overhead) برنامه‌ریزی، فوق‌العاده پرهزینه هستند. میزان کاری که در دو هفته انجام می‌دهید، ارزش ساعت‌های جمعی صرف شده در اطراف میز برای "برنامه‌ریزی اسپرینت" یا هزینه فرصت (opportunity cost) شکستن شتاب (momentum) همه برای تجدید قوا را ندارد.این ما را به امتحان چرخه‌های طولانی‌تر سوق داد. ما چرخه‌ای می‌خواستیم که به اندازه کافی طولانی باشد تا یک پروژه کامل، از ابتدا تا انتها، به پایان برسد. در عین حال، چرخه‌ها باید به اندازه‌ای کوتاه باشند که بتوان پایان را از ابتدا دید. افراد نیاز دارند احساس کنند که ضرب‌الاجل (deadline) در حال نزدیک شدن است تا بتوانند تعویض‌ها (trade-offs) را انجام دهند. اگر ضرب‌الاجل در ابتدا خیلی دور و انتزاعی باشد، تیم‌ها به طور طبیعی سرگردان می‌شوند و زمان را به طور ناکارآمدی استفاده می‌کنند تا زمانی که ضرب‌الاجل شروع به نزدیک شدن و واقعی شدن کند.پس از سال‌ها آزمایش، ما به شش هفته رسیدیم. شش هفته به اندازه کافی طولانی است تا کاری معنادار را به پایان برسانیم و هنوز هم به اندازه کافی کوتاه است تا بتوانیم پایان را از ابتدا ببینیم.Cool-down (دوره استراحت)اگر چرخه‌های شش هفته‌ای را پشت سر هم اجرا می‌کردیم، هیچ زمانی برای نفس کشیدن و فکر کردن درباره کارهای بعدی وجود نداشت. پایان یک چرخه بدترین زمان برای ملاقات و برنامه‌ریزی است؛ زیرا همه بیش از حد مشغول نهایی کردن پروژه‌ها و گرفتن تصمیمات دقیقه آخری برای ارسال به موقع هستند.بنابراین، پس از هر چرخه شش هفته‌ای، ما دو هفته را برای cool-down برنامه‌ریزی می‌کنیم. این دوره‌ای است که هیچ کار برنامه‌ریزی شده‌ای ندارد و در آن می‌توانیم نفس بکشیم، در صورت نیاز ملاقات کنیم و در مورد کارهای بعدی فکر کنیم.در طول cool-down، برنامه‌نویسان و طراحان در تیم‌های پروژه آزادند که روی هر چیزی که می‌خواهند کار کنند. پس از تلاش سخت برای ارسال پروژه‌های شش هفته‌ای خود، آن‌ها از داشتن زمانی که تحت کنترلشان است، لذت می‌برند. آن‌ها از این زمان برای رفع باگ‌ها (bugs)، کشف ایده‌های جدید، یا امتحان کردن امکانات فنی جدید استفاده می‌کنند.اندازه تیم و پروژهعلاوه بر استانداردسازی طول چرخه‌هایمان، ما نوع پروژه‌ها و تیم‌هایی را که روی آن‌ها شرط‌بندی می‌کنیم نیز تقریباً استاندارد می‌کنیم.تیم‌های پروژه ما شامل یک طراح و دو برنامه‌نویس یا یک طراح و یک برنامه‌نویس هستند. یک نفر QA (کنترل کیفیت) که تست‌های یکپارچه‌سازی (integration testing) را در اواخر چرخه انجام می‌دهد، به آن‌ها می‌پیوندد.این تیم‌ها یا کل چرخه را روی یک پروژه کار خواهند کرد، یا در طول چرخه روی چندین پروژه کوچکتر کار خواهند کرد. تیمی را که کل چرخه را روی یک پروژه می‌گذراند، تیم "دسته بزرگ" (big batch team) و تیمی را که روی مجموعه‌ای از پروژه‌های کوچکتر کار می‌کند، تیم "دسته کوچک" (small batch team) می‌نامیم. پروژه‌های دسته کوچک معمولاً هر کدام یک یا دو هفته طول می‌کشند. پروژه‌های دسته کوچک به صورت جداگانه برنامه‌ریزی نمی‌شوند. این به عهده تیم دسته کوچک است که چگونگی مدیریت کار را طوری بیابد که همه آن‌ها قبل از پایان چرخه ارسال شوند.حالا که یک روش استاندارد برای فکر کردن درباره ظرفیت داریم، می‌توانیم در مورد چگونگی تصمیم‌گیری برای برنامه‌ریزی صحبت کنیم.میز شرط‌بندی (The betting table)میز شرط‌بندی، جلسه‌ای است که در طول cool-down برگزار می‌شود و در آن ذینفعان (stakeholders) تصمیم می‌گیرند در چرخه بعدی چه کاری انجام دهند. شرط‌بندی‌های بالقوه برای بررسی، یا پیشنهادهای جدیدی (new pitches) هستند که در شش هفته گذشته شکل گرفته‌اند، یا احتمالاً یک یا دو پیشنهاد قدیمی‌تر که کسی مشخصاً تصمیم به احیای آن‌ها گرفته است. همانطور که در فصل گذشته گفتیم، هیچ "پاکسازی" (grooming) یا بک‌لاگ (backlog) برای سازماندهی وجود ندارد. فقط چند گزینه خوب شکل‌گرفته برای بررسی وجود دارد.میز شرط‌بندی ما در Basecamp متشکل از مدیرعامل (CEO) (که در مورد محصول حرف آخر را می‌زند)، مدیر ارشد فناوری (CTO)، یک برنامه‌نویس ارشد، و یک استراتژیست محصول (خودم) است.زمان مدیران ارشد (C-level) فقط در قطعات کوچک در دسترس است، بنابراین فضایی از "وقت را هدر ندهید" حاکم است و جلسه به ندرت بیش از یک یا دو ساعت طول می‌کشد. همه از قبل فرصت داشته‌اند که پیشنهادها را در زمان خود بررسی کنند. گفتگوهای یک به یک (one-on-one) اتفاقی در هفته‌های قبل نیز معمولاً مقداری زمینه (context) فراهم می‌کنند. به محض شروع تماس، همه چیز به بررسی گزینه‌هایی که به میز رسیده‌اند و گرفتن تصمیمات مربوط می‌شود.خروجی این تماس، یک برنامه چرخه (cycle plan) است. بین همه افراد حاضر، دانش در مورد اینکه چه کسی در دسترس است، اولویت‌های کسب‌وکار کدامند، و اخیراً چه نوع کاری انجام داده‌ایم، وجود دارد. همه اینها به فرآیند تصمیم‌گیری درباره اینکه چه کاری انجام شود و چه کسی برنامه‌ریزی شود (در ادامه بیشتر در مورد آن صحبت خواهیم کرد) کمک می‌کند.بالاترین افراد در شرکت حضور دارند. هیچ "گام دومی" برای اعتبارسنجی برنامه یا گرفتن تأیید وجود ندارد. و هیچ کس دیگری نمی‌تواند پس از آن وارد عمل شود تا در کار برنامه‌ریزی شده دخالت یا وقفه ایجاد کند.این "buy-in" از بالاترین سطوح برای چرخش صحیح چرخه‌ها ضروری است. جلسه کوتاه است، گزینه‌ها به خوبی شکل گرفته‌اند و تعداد نفرات کم است. وقتی این معیارها برآورده شوند، میز شرط‌بندی به مکانی برای اعمال کنترل بر جهت محصول تبدیل می‌شود، به جای نبردی برای منابع یا درخواستی برای اولویت‌بندی. با چرخه‌هایی به اندازه کافی طولانی برای پیشرفت معنادار و کاری که به طور واقع‌بینانه ارسال خواهد شد، میز شرط‌بندی به مدیران ارشد (C-suite) احساس "کنترل داشتن" را می‌دهد که از روزهای اولیه نداشته‌اند.معنای یک شرط‌بندی (bet)ما در مورد "شرط‌بندی" به جای "برنامه‌ریزی" صحبت می‌کنیم، زیرا انتظارات متفاوتی را ایجاد می‌کند.اول، شرط‌بندی‌ها پرداخت (payout) دارند. ما فقط یک بازه زمانی (time box) را با وظایف پر نمی‌کنیم تا پر شود. ما دو هفته را صرف یک قابلیت (feature) نمی‌کنیم و امیدوار به پیشرفت افزایشی نیستیم. ما عمداً کار را در یک جعبه شش هفته‌ای شکل می‌دهیم تا در پایان چیزی معنادار به پایان برسد. "پیشنهاد" (pitch) یک پرداخت مشخص را تعریف می‌کند که شرط‌بندی را ارزشمند می‌کند.دوم، شرط‌بندی‌ها تعهد (commitments) هستند. اگر شش هفته شرط‌بندی کنیم، متعهد می‌شویم که کل شش هفته را به تیم اختصاص دهیم تا منحصراً روی آن چیز بدون وقفه کار کند. ما سعی نمی‌کنیم هر ساعت از زمان یک برنامه‌نویس را بهینه کنیم. ما به حرکت بزرگتر پیشرفت در کل محصول پس از شش هفته نگاه می‌کنیم.سوم، یک شرط‌بندی هوشمند حداکثر ضرر (cap on the downside) دارد. اگر روی چیزی شش هفته شرط‌بندی کنیم، بیشترین چیزی که می‌توانیم از دست بدهیم شش هفته است. ما به خودمان اجازه نمی‌دهیم وارد وضعیتی شویم که برای چیزی که ارزش آن قیمت را ندارد، چندین برابر تخمین اولیه را صرف کنیم.بیایید این دو نکته آخر را دقیق‌تر بررسی کنیم.زمان بی‌وقفه (Uninterrupted time)اگر بگوییم شش هفته اختصاص می‌دهیم اما بعد اجازه دهیم یک تیم برای کار روی چیز دیگری کنار گذاشته شود، واقعاً یک شرط‌بندی نیست.وقتی شرط‌بندی می‌کنید، به آن احترام می‌گذارید (honor it). ما اجازه نمی‌دهیم تیم متوقف شود یا برای انجام کارهای دیگر کنار گذاشته شود. اگر افراد با درخواست‌ها تیم را متوقف کنند، تعهد ما شکسته می‌شود. ما دیگر کل شش هفته را به تیمی که کارش برای شش هفته زمان شکل داده شده بود، نمی‌دهیم.وقتی افراد "فقط چند ساعت" یا "فقط یک روز" را درخواست می‌کنند، فریب نخورید. شتاب (Momentum) و پیشرفت (progress) چیزهای مرتبه دومی هستند، مانند رشد یا شتاب. نمی‌توانید آن‌ها را با یک نقطه توصیف کنید. به یک منحنی بی‌وقفه از نقاط نیاز دارید. وقتی کسی را برای یک روز برای رفع باگ یا کمک به تیمی دیگر کنار می‌گذارید، فقط یک روز را از دست نمی‌دهید. شتابی را که آن‌ها ایجاد کرده بودند و زمانی را که برای بازگرداندن آن لازم است، از دست می‌دهید. از دست دادن ساعت اشتباه می‌تواند یک روز را از بین ببرد. از دست دادن یک روز می‌تواند یک هفته را از بین ببرد.اگر در طول آن شش هفته چیزی پیش آمد چه؟ ما همچنان تیم را متوقف نمی‌کنیم و تعهد را نمی‌شکنیم. حداکثر زمانی که باید صبر کنیم، شش هفته است قبل از اینکه بتوانیم روی مشکل یا ایده جدید اقدام کنیم. اگر چرخه بگذرد و آن چیز هنوز مهم‌ترین کار باشد، می‌توانیم برای آن چرخه روی آن شرط‌بندی کنیم. به همین دلیل بسیار مهم است که فقط یک چرخه جلوتر شرط‌بندی کنیم. این کار گزینه‌های ما را برای پاسخگویی به این مسائل جدید باز نگه می‌دارد. و البته، اگر یک بحران واقعی باشد، همیشه می‌توانیم ترمز را بکشیم. اما بحران‌های واقعی بسیار نادر هستند.Circuit breaker (قطع‌کننده مدار)ما این زمان بی‌وقفه را با یک سیاست دشوار اما فوق‌العاده قدرتمند ترکیب می‌کنیم. تیم‌ها باید کار را در مدت زمان تعیین شده به پایان برسانند. اگر آن‌ها تمام نکردند، به طور پیش‌فرض پروژه تمدید نمی‌شود. ما عمداً یک ریسک ایجاد می‌کنیم که پروژه — همانطور که پیشنهاد شده بود — اتفاق نخواهد افتاد. این سخت به نظر می‌رسد اما برای همه افراد درگیر بسیار مفید است.اول، خطر پروژه‌های خارج از کنترل را از بین می‌برد. ما در ابتدا وقتی پروژه شکل گرفت و پیشنهاد شد، اشتهای خود را تعریف کردیم. اگر پروژه فقط شش هفته ارزش داشت، صرف دو، سه یا ده برابر آن احمقانه خواهد بود. تعداد بسیار کمی از پروژه‌ها از نوع "به هر قیمتی" هستند و باید فوراً اتفاق بیفتند. ما این را مانند یک قطع‌کننده مدار (circuit breaker) می‌بینیم که تضمین می‌کند یک پروژه سیستم را اضافه بار (overload) نمی‌کند. یک پروژه‌ای که بیش از حد طول می‌کشد، هرگز ما را متوقف نمی‌کند یا جلوی پروژه‌های جدیدی که ممکن است مهم‌تر باشند را نمی‌گیرد.دوم، اگر یک پروژه در شش هفته به پایان نرسد، به این معنی است که ما در مرحله شکل‌دهی اشتباهی مرتکب شدیم. به جای سرمایه‌گذاری زمان بیشتر در یک رویکرد بد، قطع‌کننده مدار ما را وادار می‌کند تا مشکل را دوباره چارچوب‌بندی کنیم (reframe). می‌توانیم از مسیر شکل‌دهی (shaping track) در شش هفته بعدی برای ارائه یک راه‌حل جدید یا بهتر استفاده کنیم که از هر "چالشی" (rabbit hole) که در تلاش اول گرفتار آن شدیم، جلوگیری کند. سپس پیشنهاد جدید را در میز شرط‌بندی بررسی خواهیم کرد تا ببینیم آیا واقعاً شانس موفقیت ما را تغییر می‌دهد، قبل از اینکه شش هفته دیگر را به آن اختصاص دهیم.در نهایت، قطع‌کننده مدار تیم‌ها را تشویق می‌کند تا مالکیت بیشتری بر پروژه‌های خود داشته باشند. همانطور که در فصل بعدی خواهیم دید، تیم‌ها مسئولیت کامل اجرای پروژه‌ها را بر عهده می‌گیرند. این شامل تصمیم‌گیری در مورد جزئیات پیاده‌سازی و انتخاب اینکه کجا دامنه (scope) را کاهش دهند می‌شود. نمی‌توانید بدون تصمیم‌گیری‌های دشوار در مورد اینکه کجا متوقف شوید، کجا مصالحه کنید، و چه چیزی را حذف کنید، چیزی را ارسال کنید. یک مهلت سخت و شانس عدم ارسال، تیم را تشویق می‌کند تا به طور منظم سوال کند که چگونه تصمیمات طراحی و پیاده‌سازی آن‌ها بر دامنه تأثیر می‌گذارد.با باگ‌ها (bugs) چه کنیم؟اگر تیم‌ها در چرخه شش هفته‌ای متوقف نمی‌شوند، چگونه با باگ‌هایی که پیش می‌آیند کنار بیاییم؟اول باید عقب‌نشینی کنیم و فرضیات خود را در مورد باگ‌ها زیر سوال ببریم.هیچ چیز خاصی در مورد باگ‌ها وجود ندارد که آن‌ها را به طور خودکار از هر چیز دیگری مهم‌تر کند. صرف اینکه چیزی یک باگ است، به ما بهانه‌ای برای قطع کار خود یا دیگران نمی‌دهد. تمام نرم‌افزارها باگ دارند. سوال این است: شدت آن‌ها چقدر است؟ اگر در یک بحران واقعی باشیم – داده‌ها از بین می‌روند، برنامه متوقف می‌شود، یا بخش بزرگی از مشتریان چیز اشتباهی را می‌بینند – آنگاه همه چیز را رها می‌کنیم تا آن را رفع کنیم. اما بحران‌ها نادر هستند. اکثریت قریب به اتفاق باگ‌ها می‌توانند شش هفته یا بیشتر صبر کنند، و بسیاری از آن‌ها حتی نیازی به رفع شدن ندارند. اگر سعی کنیم هر باگ را از بین ببریم، هرگز تمام نخواهیم شد. اگر مجبور باشید اول تمام دنیا را درست کنید، نمی‌توانید چیز جدیدی ارسال کنید.با این حال، هیچ کس باگ را دوست ندارد. ما همچنان راه‌هایی برای برخورد با آن‌ها می‌خواهیم. سه استراتژی برای ما کارساز بوده است.از cool-down استفاده کنید. از هر برنامه‌نویسی بپرسید که آیا چیزهایی هست که ای کاش می‌توانست به عقب برگردد و آن‌ها را درست کند، و آن‌ها لیستی برای نشان دادن به شما خواهند داشت. دوره cool-down بین چرخه‌ها به آن‌ها زمان می‌دهد تا دقیقاً همین کار را انجام دهند. شش هفته زمان زیادی برای انتظار برای اکثر باگ‌ها نیست، و دو هفته در هر شش هفته در واقع به زمان زیادی برای رفع آن‌ها اضافه می‌شود.آن را به میز شرط‌بندی بیاورید. اگر یک باگ برای رفع شدن در طول cool-down خیلی بزرگ باشد، می‌تواند برای منابع در میز شرط‌بندی رقابت کند. فرض کنید یک فرآیند بک‌اند (back-end process) برنامه را کند می‌کند و یک برنامه‌نویس می‌خواهد آن را از یک گام همزمان (synchronous) به یک کار ناهمزمان (asynchronous job) تغییر دهد. برنامه‌نویس می‌تواند برای رفع آن استدلال کند و راه‌حل را در یک پیشنهاد (pitch) شکل دهد. سپس به جای قطع کردن کار دیگر، افراد حاضر در میز شرط‌بندی می‌توانند یک تصمیم عمدی بگیرند. زمان همیشه باید به صورت استراتژیک استفاده شود. تفاوت بزرگی بین تأخیر انداختن در کار دیگر برای رفع یک باگ در مقابل تصمیم‌گیری از پیش اینکه باگ ارزش زمان صرف شده برای رفع آن را دارد، وجود دارد.یک "Bug Smash" برنامه‌ریزی کنید. سالی یک بار – معمولاً در حدود تعطیلات – ما یک چرخه کامل را به رفع باگ‌ها اختصاص می‌دهیم. ما آن را "Bug Smash" می‌نامیم. تعطیلات زمان خوبی برای این کار است زیرا انجام یک پروژه عادی دشوار است وقتی افراد در سفر هستند یا مرخصی می‌گیرند. تیم می‌تواند به صورت خودسازمان‌دهنده (self-organize) عمل کند تا مهم‌ترین باگ‌ها را انتخاب کرده و مسائل طولانی‌مدت در فرانت‌اند (front-end) یا بک‌اند را حل کند.سطح را پاک نگه دارید (Keep the slate clean)کلید مدیریت ظرفیت، دادن یک سطح پاک به خود در هر چرخه است. این به معنای فقط شرط‌بندی یک چرخه در هر بار و هرگز منتقل نکردن تکه‌های کار قدیمی بدون اینکه ابتدا آن‌ها را شکل داده و به عنوان یک شرط‌بندی بالقوه جدید در نظر بگیریم، است.حداکثرسازی گزینه‌های ما در آینده بسیار حیاتی است. ما نمی‌دانیم در شش هفته آینده چه اتفاقی خواهد افتاد. ما نمی‌دانیم چه ایده درخشانی ظاهر خواهد شد یا چه درخواست فوری ممکن است پدیدار شود.حتی اگر نوعی نقشه راه (road map) در ذهنمان در مقیاس زمانی بالاتر از چرخه‌ها داشته باشیم، آن را در ذهنمان و در بحث‌های فرعی (side-channel discussions) نگه می‌داریم. هر شش هفته ما می‌آموزیم که چه چیزی کار می‌کند و چه چیزی کار نمی‌کند، چه چیزی مهم است و چه چیزی نیست. نگه داشتن گزینه باز هیچ ضرری ندارد و از در دسترس بودن برای اقدام بر روی چیزهای غیرمنتظره سود کلانی به دست می‌آید.در مورد پروژه‌هایی که نمی‌توانند در یک چرخه انجام شوند چه؟ در آن صورت ما همچنان فقط شش هفته در هر بار شرط‌بندی می‌کنیم. فرض کنید ما قابلیتی را تصور می‌کنیم که دو چرخه طول می‌کشد تا ارسال شود. ما ریسک خود را با شکل‌دهی یک هدف شش هفته‌ای مشخص، با چیزی که کاملاً ساخته شده و در پایان آن شش هفته کار می‌کند، به شدت کاهش می‌دهیم. اگر اینطور که انتظار می‌رود پیش رفت، احساس خوبی خواهیم داشت که شش هفته بعدی را همانطور که در ذهنمان تصور کرده بودیم، شرط‌بندی کنیم. اما اگر اینطور نشد، می‌توانیم پروژه بسیار متفاوتی را تعریف کنیم. یا می‌توانیم کار چند چرخه‌ای را متوقف کنیم و کار فوری که پیش آمده را انجام دهیم. نکته مهم این است که ما همیشه مشخص می‌کنیم که پایان آن چرخه چگونه به نظر می‌رسد و گزینه‌های خود را برای تغییر مسیر باز نگه می‌داریم. علی کریمی علی کریمی Fri, 08 Aug 2025 17:48:19 +0330 https://virgool.io/@alikarimi/%DB%B6-%D8%B4%D8%B1%D8%B7-%D8%A8%D9%86%D8%AF%DB%8C-%D9%86%D9%87-%D8%A8%DA%A9-%D9%84%D8%A7%DA%AF-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-uzocfb8jtfpe حالا که یک پیشنهاد (pitch) نوشتیم، کجا می‌رود؟ به بک‌لاگ (backlog) نمی‌رود.بدون بک‌لاگبک‌لاگ‌ها بار سنگینی هستند که نیازی به حمل آن‌ها نداریم. ده‌ها و در نهایت صدها تسک (task) روی هم انباشته می‌شوند که همه می‌دانیم هرگز برای آن‌ها وقت نخواهیم داشت. انباشته شدن فزاینده آن‌ها به ما احساسی می‌دهد که گویی همیشه عقب هستیم، در حالی که اینطور نیست. فقط به این دلیل که کسی یک ایده را سه ماه پیش مهم می‌دانست، به این معنی نیست که باید بارها و بارها به آن نگاه کنیم.بک‌لاگ‌ها اتلاف‌کننده‌های بزرگ زمان نیز هستند. زمانی که صرف بازبینی، سازماندهی و پالایش مداوم ایده‌های قدیمی می‌شود، همه را از پیشرفت در پروژه‌های به موقع که واقعاً اکنون اهمیت دارند، بازمی‌دارد.چندین شرط‌بندی (bet) بالقوهپس به جای آن چه کار می‌کنیم؟ قبل از هر چرخه شش هفته‌ای، یک میز شرط‌بندی (betting table) برگزار می‌کنیم که در آن ذینفعان (stakeholders) تصمیم می‌گیرند در چرخه بعدی چه کاری انجام دهند. در میز شرط‌بندی، آن‌ها به پیشنهادهایی (pitches) از شش هفته گذشته نگاه می‌کنند — یا هر پیشنهادی که کسی عمداً آن را احیا کرده و دوباره برای آن لابی کرده باشد.چیز دیگری روی میز نیست. هیچ لیست غول‌آسایی از ایده‌ها برای بازبینی وجود ندارد. هیچ زمانی صرف سازماندهی یک بک‌لاگ از ایده‌های قدیمی نمی‌شود. تنها چند گزینه خوب شکل‌گرفته و کم‌ریسک برای بازبینی وجود دارد. پیشنهادها، شرط‌بندی‌های بالقوه هستند.با وجود تنها چند گزینه و یک چرخه شش هفته‌ای، این جلسات کم‌تعداد، کوتاه و به شدت پربار هستند.اگر تصمیم بگیریم روی یک پیشنهاد شرط‌بندی کنیم، آن وارد چرخه بعدی برای ساخت می‌شود. اگر این کار را نکنیم، آن را رها می‌کنیم. چیزی برای پیگیری یا نگه داشتن نداریم.اگر پیشنهاد عالی بود، اما زمان مناسب نبود چه؟ هر کسی که می‌خواهد دوباره از آن حمایت کند، به سادگی آن را به طور مستقل — به شیوه خود — پیگیری می‌کند و سپس شش هفته بعد برای آن لابی می‌کند.لیست‌های غیرمتمرکزما مجبور نیستیم بین یک بک‌لاگ پرزحمت و به خاطر نسپردن هیچ چیز از گذشته، یکی را انتخاب کنیم. هر کسی همچنان می‌تواند پیشنهادها (pitches)، باگ‌ها (bugs)، درخواست‌ها یا کارهایی را که می‌خواهد انجام دهد، به طور مستقل و بدون یک بک‌لاگ مرکزی پیگیری کند.• تیم پشتیبانی می‌تواند لیستی از درخواست‌ها یا مسائلی که بیشتر از بقیه پیش می‌آیند، نگه دارد.• تیم محصول ایده‌هایی را پیگیری می‌کند که امیدوارند در چرخه‌های آتی بتوانند آن‌ها را شکل دهند.• برنامه‌نویسان لیستی از باگ‌هایی را که مایلند در صورت داشتن وقت، آن‌ها را رفع کنند، نگهداری می‌کنند.هیچ بک‌لاگ یا لیست مرکزی واحدی وجود ندارد و هیچ یک از این لیست‌ها ورودی مستقیم به فرآیند شرط‌بندی (betting process) نیستند.جلسات منظم اما کم‌تعداد یک به یک (one-on-one) بین دپارتمان‌ها به تبادل ایده‌ها (cross-pollinate) برای کارهای بعدی کمک می‌کند. به عنوان مثال، پشتیبانی می‌تواند به تیم محصول درباره مسائل اصلی که مشاهده می‌کنند، اطلاع دهد، که تیم محصول سپس می‌تواند آن را به طور مستقل به عنوان پروژه‌های بالقوه برای شکل‌دهی پیگیری کند. شاید تیم محصول تنها یکی از آن مسائل اصلی را برای کار در حال حاضر انتخاب کند. سپس، در یک جلسه یک به یک آتی، پشتیبانی می‌تواند دوباره برای چیزی که هنوز توجهی به آن نشده، لابی کند.این رویکرد مسئولیت اولویت‌بندی و پیگیری کارها را پخش می‌کند و آن را قابل مدیریت می‌سازد. افراد از دپارتمان‌های مختلف می‌توانند از هر چیزی که به نظرشان مهم است دفاع کنند و از هر روشی که برایشان کارآمد است برای پیگیری آن چیزها استفاده کنند — یا نکنند. به این ترتیب گفتگو همیشه تازه است. هر چیزی که بازگردانده می‌شود، با یک زمینه (context)، توسط یک شخص و با یک هدف بازگردانده می‌شود. همه چیز مرتبط، به موقع و مربوط به لحظه است.ایده‌های مهم بازمی‌گردنداغراق در ارزش ایده‌ها آسان است. حقیقت این است که ایده‌ها ارزان هستند. آن‌ها همیشه ظاهر می‌شوند و به صورت انبوه جمع می‌شوند.ایده‌های واقعاً مهم به شما بازخواهند گشت. آخرین باری که یک ایده واقعاً عالی و الهام‌بخش را فراموش کردید، کی بود؟ و اگر خیلی جالب نباشد — شاید یک باگ (bug) که مشتریان گهگاه با آن مواجه می‌شوند — زمانی که مشتری دوباره شکایت کند یا مشتری جدیدی به آن برخورد کند، دوباره به توجه شما بازخواهد گشت. اگر آن را یک بار بشنوید و دیگر هرگز نشنوید، شاید واقعاً مشکلی نبوده است. و اگر مدام درباره آن بشنوید، انگیزه پیدا می‌کنید تا راه حلی برای آن شکل دهید و برای زمان شرط‌بندی (betting time) روی آن در چرخه بعدی، پیشنهاد دهید. علی کریمی علی کریمی Fri, 08 Aug 2025 17:47:35 +0330 https://virgool.io/@alikarimi/%DB%B5-%D9%BE%DB%8C%DA%86-%D8%B1%D8%A7-%D8%A8%D9%86%D9%88%DB%8C%D8%B3%DB%8C%D8%AF-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-p7p3c2kts6xj ما اکنون عناصر یک راه‌حل را در اختیار داریم و مفهوم خود را تا جایی ریسک‌زدایی (de-risked) کرده‌ایم که اطمینان داریم گزینه خوبی برای ارائه به یک تیم است. اما این مفهوم هنوز در ذهن ما یا در برخی طراحی‌های دشوار برای خواندن روی وایت‌بورد یا دفترچه‌مان باقی مانده است. اکنون باید این مفهوم را به شکلی درآوریم که دیگران بتوانند آن را درک، هضم و پاسخ دهند.اینجاست که می‌گوییم "بسیار خوب، این آماده است تا به عنوان یک پیچ (pitch) نوشته شود". در این فصل، مؤلفه‌های یک پیچ را بررسی کرده و نمونه‌های کاملاً توسعه‌یافته‌ای از پروژه‌های واقعی در بیس‌کمپ (Basecamp) را نشان خواهیم داد.هدف از پیچ، ارائه یک "شرط بالقوه خوب" (good potential bet) است. این اساساً یک ارائه (presentation) است. مؤلفه‌های آن شامل تمام چیزهایی است که هم برای ثبت کارهای انجام‌شده تا کنون نیاز داریم و هم برای ارائه آن‌ها به شکلی که افرادی که پروژه‌ها را برنامه‌ریزی می‌کنند، بتوانند یک "شرط آگاهانه" (informed bet) ببندند.پنج مؤلفه وجود دارد که همیشه می‌خواهیم در یک پیچ گنجانده شود:• مشکل (Problem) — ایده خام، یک مورد استفاده (use case)، یا چیزی که دیده‌ایم و ما را به کار بر روی آن سوق می‌دهد.• میل و زمان‌بندی (Appetite) — چه مقدار زمان می‌خواهیم صرف کنیم و این چگونه راه‌حل را محدود می‌کند.• راه‌حل (Solution) — عناصر اصلی که به آن‌ها رسیده‌ایم، به شکلی ارائه شده‌اند که مردم بتوانند فوراً آن‌ها را درک کنند.• گودال خرگوش (Rabbit holes) — جزئیاتی درباره راه‌حل که ارزش اشاره دارند تا از مشکلات جلوگیری شود.• ممنوعه‌ها (No-gos) — هر چیزی که به طور خاص از مفهوم حذف شده است: عملکرد یا موارد استفاده‌ای که عمداً برای تطابق با زمان‌بندی یا قابل مدیریت کردن مشکل پوشش نمی‌دهیم.مؤلفه ۱. مشکلارائه همزمان مشکل و راه‌حل از اهمیت حیاتی برخوردار است. این نکته‌ای آشکار به نظر می‌رسد، اما تعجب‌آور است که تیم‌ها – حتی تیم‌های خود ما – اغلب با فرض اینکه دلیل ساخت یک چیز واضح است، مستقیماً به سراغ راه‌حل می‌روند.شیرجه زدن مستقیم به "چه چیزی بسازیم" – یعنی راه‌حل – خطرناک است. بدون مشکل، شما هیچ مبنایی برای بحث در مورد خوب یا بد بودن این راه‌حل ایجاد نمی‌کنید. "اضافه کردن تب به برنامه iPad" ممکن است برای طراحان UI جذاب باشد، اما چه چیزی مانع از تبدیل شدن بحث به یک مناظره طولانی درباره رویکردهای مختلف UI می‌شود؟ بدون یک مشکل خاص، هیچ آزمونی برای ارزیابی مناسب بودن وجود ندارد تا قضاوت شود کدام راه‌حل بهتر از دیگری است.تعریف مشکل به ما امکان می‌دهد بعداً، زمانی که وقت پیچ کردن ایده یا شرط بستن (betting) روی آن فرا می‌رسد، مکالمه‌ای واضح‌تر داشته باشیم. راه‌حل ممکن است بی‌نقص باشد، اما اگر مشکل فقط برای مشتریانی رخ دهد که به عنوان نامناسب برای محصول شناخته شده‌اند، چه؟ ممکن است شش هفته را صرف یک راه‌حل مبتکرانه کنیم که فقط به درصد کمی از مشتریان که نرخ حفظ پایینی دارند، سود می‌رساند. ما می‌خواهیم بتوانیم آن بحث مربوط به تقاضا را جدا کنیم تا زمان را صرف یک راه‌حل خوب که به افراد مناسب سود نمی‌رساند، نکنیم.اینکه تا چه حد باید مشکل را توضیح دهید، بستگی به میزان زمینه‌ی مشترک (context) شما با افرادی دارد که متن را می‌خوانند. بهترین تعریف مشکل شامل یک داستان خاص و منفرد است که نشان می‌دهد چرا وضعیت موجود کار نمی‌کند. این به شما یک مبنا (baseline) می‌دهد تا مناسب بودن را در برابر آن آزمایش کنید. افراد قادر خواهند بود راه‌حل را در برابر این مشکل خاص – یا راه‌حل‌های دیگر در صورت بروز بحث – بسنجند و قضاوت کنند که آیا آن داستان با راه‌حل جدید، نتیجه بهتری خواهد داشت یا خیر.مؤلفه ۲. میل و زمان‌بندی (Appetite)می‌توانید "میل و زمان‌بندی" (appetite) را به عنوان بخش دیگری از تعریف مشکل در نظر بگیرید. ما نه تنها می‌خواهیم این مورد استفاده را حل کنیم، بلکه می‌خواهیم راهی برای انجام آن در شش هفته، نه سه ماه، یا – در مورد یک پروژه دسته کوچک (small batch project) – دو هفته، نه تمام شش هفته، پیدا کنیم.بیان زمان‌بندی در پیچ از مکالمات غیرسازنده جلوگیری می‌کند. همیشه یک راه‌حل بهتر وجود دارد. سؤال این است که اگر ما فقط به اندازه کافی برای صرف دو هفته زمان برای این کار در حال حاضر اهمیت می‌دهیم، این راه‌حل خاص چگونه به نظر می‌رسد؟هر کسی می‌تواند راه‌حل‌های گران و پیچیده پیشنهاد دهد. رسیدن به یک ایده ساده که در یک جعبه زمانی کوچک (small time box) جای می‌گیرد، نیازمند کار و بینش طراحی است. بیان زمان‌بندی و پذیرش آن به عنوان یک محدودیت، همه را در این فرآیند شریک می‌کند.مؤلفه ۳. راه‌حلمانند راه‌حل‌های بدون مشکل، گاهی اوقات شرکت‌ها روی مشکلاتی شرط می‌بندند که راه‌حلی ندارند. مثلاً: "واقعاً باید پیدا کردن چیزها را در بخش پیام‌ها آسان‌تر کنیم. مشتریان از آن شکایت دارند".این برای پیچ کردن یا شرط بستن آماده نیست. یک مشکل بدون راه‌حل، کاری "شکل‌نیافته" (unshaped) است. دادن آن به یک تیم به معنای سوق دادن تحقیق و کاوش به سطح اشتباه است، جایی که مجموعه‌ی مهارت‌ها (skillsets)، محدودیت زمانی و پروفایل ریسک (ریسک کم در مقابل ریسک بالا/پر دنباله - thin vs. heavy tailed) همه ناهماهنگ هستند.اگر راه‌حل وجود ندارد، کسی باید برگردد و کار شکل‌دهی (shaping work) را در مسیر شکل‌دهی (shaping track) انجام دهد. فقط زمانی برای شرط بستن آماده است که مشکل، زمان‌بندی (appetite) و راه‌حل با هم جمع شوند. سپس می‌توانید تناسب بین مشکل و راه‌حل را بررسی کرده و قضاوت کنید که آیا این یک شرط خوب است یا خیر.به آن‌ها کمک کنید تا ببیننددر مرحله "عناصر"، مهم بود که ایده‌ها را در سطح مناسبی از انتزاع (abstraction) ترسیم کنیم تا سرعت کار کاهش نیابد و هیچ یک از ایده‌هایی که در گوشه‌های ذهن و نوک زبانمان ظاهر می‌شدند، از دست نروند.هنگام نوشتن پیچ نیز باید با سطح مناسبی از جزئیات ترسیم کنیم. در اینجا چالش کمی متفاوت است. ما زمان داریم تا سرعت خود را کم کنیم و یک ارائه مناسب آماده کنیم. باید در سطح بالا (high level) بمانیم، اما کمی ملموس‌تر (concreteness) از زمانی که تنها یا با یک همکار کار می‌کردیم، جزئیات اضافه کنیم. افرادی که پیچ را می‌خوانند و به نقاشی‌ها نگاه می‌کنند، بدون زمینه زیاد، باید ایده را "درک کنند".ما به ملموس‌تر شدن نیاز داریم، اما نمی‌خواهیم طراحی را با وایرفریم‌ها (wireframes) یا ماکاپ‌های با جزئیات بالا (high-fidelity mocks) بیش از حد مشخص کنیم. این‌ها طراحانی را که بعداً کار را انجام می‌دهند، محدود خواهند کرد (box in). همچنین خطر منحرف شدن بحث (side-tracking) به موضوعاتی مانند رنگ، نسبت‌ها یا طرح‌بندی وجود دارد که هیچ ربطی به کار شکل‌دهی واقعی که انجام داده‌ایم، ندارند.در عین حال، نمودارهای اولیه دستی (hand-written breadboards) کیفیتی دارند که "شما باید آنجا می‌بودید تا درک کنید". برای افرادی که مرحله به مرحله توسعه نمودار اولیه دستی را ندیده‌اند، ممکن است شبیه به آش درهم‌برهمی از کلمات و فلش‌ها به نظر برسد.بنابراین، ما به تکنیک‌هایی نیاز داریم تا به مردم کمک کنیم ایده را ببینند، در حالی که بیش از حد وارد جزئیات بی‌ربط نمی‌شویم.اسکچ‌های جاسازی‌شده (Embedded sketches)فرض کنید نمودار اولیه دستی (breadboard) شما از جلسه شکل‌دهی به این شکل بوده است:ممکن است مردم در تجسم اینکه این قابلیت‌های جدید (affordances) کجا روی داشبورد (Dashboard) قرار می‌گیرند، مشکل داشته باشند. می‌توانیم یک کادر جدید روی داشبورد ترسیم کنیم تا آن را واضح‌تر کنیم:اما ما هنوز از مردم می‌خواهیم بیش از حد تصور کنند. ارزشش را دارد که یک مرحله پایین‌تر رفته و جزئیات با ماژیک ضخیم (fat-marker detail) را اضافه کنیم:این کار دیدن عناصر و ارزیابی وضوح نمایش ویژگی در داشبورد را آسان‌تر می‌کند. نکته منفی این است که ما وارد برخی تصمیمات طرح‌بندی (layout decisions) شده‌ایم که بهتر بود از آن‌ها اجتناب می‌کردیم. طراحان باید در پیدا کردن طرحی متفاوت از کادر تقسیم‌شده با خط عمودی، آزاد باشند. ما در اینجا در پیچ، سلب مسئولیتی اضافه می‌کنیم که به طراحان یادآوری می‌کند که چه میزان آزادی عمل دارند.این نمونه‌ای از انتخاب جزئیات بصری بیشتر است زیرا برای "فروختن مفهوم" به آن نیاز داریم. خوشبختانه، در سایر بخش‌های مفهوم، نیازی به تصمیمات بصری زیادی نخواهیم داشت. این یک "نقطه کلیدی" (linchpin) در طراحی بود که همه باید آن را به طور ملموس می‌دیدند تا آن را "درک کنند".اسکچ‌های ماژیک ضخیم حاشیه‌نویسی شده (Annotated fat marker sketches)گاهی اوقات ایده‌ها ذاتاً بصری هستند یا کمی پیچیده‌تر از آنند که در یک نمودار اولیه دستی شماتیک (schematic breadboard) بیان شوند. اسکچ‌های ماژیک ضخیم می‌توانند در یک پیچ بسیار مؤثر باشند؛ فقط باید بیشتر دقت کنید که آن‌ها را به طور واضح برچسب‌گذاری کنید.ترسیم مجدد اسکچ روی iPad – همچنان با اندازه قلم ضخیم – خوب عمل می‌کند. می‌توانید از رنگ‌های مختلف برای جدا کردن برچسب‌ها از بخش‌های اصلی اسکچ استفاده کنید.یا ممکن است برخی "توضیحات فراخوان" (call-outs) را اضافه کنید تا امکان بحث در مورد عناصر خاص را فراهم کنید.مؤلفه ۴. گودال خرگوش (Rabbit holes)گاهی اوقات پرداختن به یک "گودال خرگوش" (rabbit hole) فقط به چند خط متن نیاز دارد. به عنوان مثال، در پروژه فرم پرداخت فوق، "شکل‌دهندگان" (shapers) می‌خواستند یک راه‌حل خاص برای نحوه ایجاد URLها را مشخص کنند. URLها هرگز برای نسخه ۱ پروژه روی دامنه‌های سفارشی قرار نمی‌گرفتند. این نوعی از چیزهاست که برای مفهوم اصلی حیاتی نیست، اما توضیح دادن آن یک "گودال خرگوش" بالقوه را برطرف می‌کند.مؤلفه ۵. ممنوعه‌ها (No Gos)در نهایت، اگر چیزی وجود دارد که ما در این مفهوم انجام نمی‌دهیم، خوب است که در اینجا به آن اشاره کنیم. در مورد پروژه فرم پرداخت، تیم از قبل تصمیم گرفت که هیچ نوع ویرایش WYSIWYG (آنچه می‌بینید همان چیزی است که دریافت می‌کنید) را برای فرم مجاز ندانند. کاربران فقط می‌توانستند یک لوگو ارائه دهند و متن هدر را در یک صفحه "سفارشی‌سازی" جداگانه شخصی‌سازی کنند. WYSIWYG ممکن است از نظر برخی افراد بهتر باشد، اما با توجه به زمان‌بندی (appetite)، مهم بود که این مورد را به عنوان "ممنوعه" (no-go) علامت‌گذاری کنیم.نمونه‌هادر اینجا دو نمونه از پیچ های واقعی آورده شده است.این پیچ برای گروه‌بندی تسک‌ها (to-dos) با نشان دادن راهکاری که مردم در طراحی فعلی استفاده می‌کنند، آغاز می‌شود. سپس تمام ایده‌های اصلی برای فعال کردن گروه‌بندی اختیاری تسک‌ها را ترسیم می‌کند.این پیچ برای تغییر نحوه کار نوتیفیکیشن‌ها با دو ویدئو برای نشان دادن مشکل شروع می‌شود. کادرهای سیاه در انتها تجسمی از داده‌های رفتار کاربر هستند که از یک تصمیم در پیچ پشتیبانی می‌کند.آماده برای ارائهگام بعدی این خواهد بود که اثبات کنیم این پیچ یک "شرط ارزشمند" (bet worth making) را توصیف می‌کند. این می‌تواند به چند روش اتفاق بیفتد.ما به طور پیش‌فرض ارتباط نامتقارن (asynchronous communication) را ترجیح می‌دهیم و تنها در صورت لزوم به زمان واقعی (real-time) ارتقا می‌دهیم. این به هر کس حداکثر زمان تحت کنترل خود را برای انجام کار واقعی می‌دهد. این بدان معناست که اولین قدم برای ارائه یک پیچ، ارسال متن کامل با تمام مؤلفه‌های فوق در مکانی است که ذینفعان بتوانند آن را در زمان خود بخوانند. این کار "میز تصمیم‌گیری" (betting table) را کوتاه و پربار نگه می‌دارد. در شرایط ایده‌آل، همه زمان کافی برای خواندن پیچ را از قبل دارند. و اگر در برخی موارد این امکان‌پذیر نباشد، پیچ آماده است تا برای یک فروش سریع زنده (live sell) ارائه شود.ما چگونه آن را در بیس‌کمپ انجام می‌دهیمما پیچ ها را به عنوان پیام‌ها (Messages) در بیس‌کمپ ارسال می‌کنیم. ما یک "دسته پیام" (Message Category) با عنوان "پیچ" ایجاد کرده‌ایم تا بتوانیم به راحتی آن‌ها را پیدا کنیم. پیچ ها در یک "تیم" (Team) به نام "استراتژی محصول" (Product Strategy) پست می‌شوند که افراد حاضر در "میز تصمیم‌گیری" (betting table) می‌توانند به آن دسترسی داشته باشند.هنگامی که نیاز به گنجاندن یک اسکچ ماژیک ضخیم در یک پیچ داریم، آن را روی iPad (با استفاده از Notability) ترسیم کرده و یک اسکرین‌شات می‌گیریم.ویرایشگر متن بیس‌کمپ وارد کردن تصاویر و افزودن کپشن به آن‌ها را آسان می‌کند تا در جریان پیچ معنی پیدا کنند.افراد به طور نامتقارن (asynchronously) روی پیچ نظر می‌دهند. نه برای "بله" یا "خیر" گفتن – این در "میز تصمیم‌گیری" اتفاق می‌افتد – بلکه برای یافتن ایرادات یا کمک به اطلاعات از دست رفته.مدیر ارشد فنی ما (CTO) با افکار فنی خود به پیچ پاسخ می‌دهددر فصل بعدی، فرآیند "شرط‌بندی" (betting process) را با جزئیات بیشتری بررسی خواهیم کرد تا ببینیم پیچ ها به کجا می‌روند و چگونه آن‌ها را به پروژه‌های برنامه‌ریزی‌شده تبدیل می‌کنیم.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:47:01 +0330 https://virgool.io/@alikarimi/%DB%B4-%D8%B1%DB%8C%D8%B3%DA%A9-%D9%87%D8%A7-%D9%88-%D9%85%D8%B4%DA%A9%D9%84%D8%A7%D8%AA-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-rabbit-holes-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-nay5jrugmpxn به یاد داشته باشید که ما کار را برای یک بازه زمانی مشخص (fixed time window) شکل می‌دهیم. ممکن است از تجربه خود اطمینان داشته باشیم که عناصری که در فصل قبلی به آن‌ها پرداختیم، در محدوده "اشتها" یا "بازه" (شش هفته) قابل ساخت هستند. اما باید دقیق‌تر نگاه کنیم، چون تنها یک نقص در مفهوم (hole in the concept) می‌تواند کل پروژه را از مسیر خارج کند. فرض کنید روی پروژه شرط‌بندی می‌کنیم و یک تیم آن را به عهده می‌گیرد. اگر آن‌ها با یک مشکل پیش‌بینی نشده (unanticipated problem) روبرو شوند که حل آن دو هفته طول بکشد، یک سوم از بودجه را از دست داده‌اند!حتی بدتر، گاهی اوقات با مشکلاتی روبرو می‌شوید که نه تنها پروژه را به تأخیر می‌اندازند، بلکه راه‌حل مشخصی هم ندارند. ما یک بار روی پروژه‌ای شرط‌بندی کردیم تا نحوه نمایش پروژه‌ها به مشتریان در صفحه اصلی Basecamp را بازطراحی کنیم. ما فرض کردیم طراح آن را حل خواهد کرد؛ در فاز شکل‌دهی (shaping phase) کاری نکردیم تا تأیید کنیم که یک رویکرد عملی (viable approach) وجود دارد. وقتی پروژه شروع شد، معلوم شد که مشکل بسیار سخت‌تر از آن چیزی بود که انتظار داشتیم. هیچ‌کدام از ما نتوانستیم یک راه‌حل طراحی مناسب را در شش هفته‌ای که بودجه‌بندی کرده بودیم، پیدا کنیم. در نهایت مجبور شدیم پروژه را رها کرده و بعداً دوباره در مورد آن فکر کنیم.البته همیشه ناشناخته‌هایی وجود خواهند داشت. به همین دلیل است که ما بسیاری از روش‌های بخش سه را به کار می‌گیریم تا تیم‌ها مشکلات صحیح را به ترتیب صحیح حل کنند و فضایی برای موارد پیش‌بینی نشده باقی بگذارند. اما این به این معنی نیست که نباید به دنبال دام‌هایی (pitfalls) باشیم که می‌توانیم از قبل پیدا کنیم و آن‌ها را قبل از شرط‌بندی روی پروژه از بین ببریم. قبل از اینکه یک پروژه شکل‌گرفته را برای شرط‌بندی ایمن تلقی کنیم، باید تا حد امکان عاری از نقص (free of holes) باشد.دسته‌بندی‌های مختلف ریسکاز نظر ریسک، یک کار به خوبی شکل‌گرفته (well-shaped work) شبیه یک توزیع احتمال باریک‌دُم (thin-tailed probability distribution) به نظر می‌رسد. شانس کمی وجود دارد که یک هفته بیشتر طول بکشد، اما فراتر از آن، عناصر راه‌حل به اندازه کافی تعریف شده و آشنا هستند که دلیلی برای طولانی‌تر شدن آن وجود ندارد.تصویر ۱: نمودار احتمال زمان اتمام پروژه برای کار به خوبی شکل‌گرفته (نموداری که در محور افقی "زمان تا تحویل (هفته)" و در محور عمودی "احتمال" را نشان می‌دهد، با یک پیک باریک در حدود ۶ هفته)با این حال، اگر در مرحله شکل‌دهی (shaping) هر گونه Rabbit Hole (مشکلات پیچیده و عمیق) وجود داشته باشد – ناشناخته‌های فنی، مشکلات طراحی حل نشده، یا وابستگی‌های متقابل بدفهمیده شده – پروژه می‌تواند چندین برابر زمان اولیه مورد انتظار طول بکشد تا تکمیل شود. در این حالت، دم سمت راست نمودار کشیده می‌شود.تصویر ۲: نمودار احتمال زمان اتمام پروژه با وجود Rabbit Hole ها (نموداری شبیه به تصویر ۱، اما با یک "دم" کشیده شده به سمت راست که نشان‌دهنده احتمال تأخیر ۳ برابری یا بیشتر است)ما می‌خواهیم ناشناخته‌ها و مشکلات دشوار را از پروژه حذف کنیم تا توزیع احتمال ما تا حد امکان باریک‌دُم باشد. این به معنای پروژه‌ای است با بخش‌های مستقل و به خوبی درک شده که به روش‌های شناخته شده‌ای با هم ترکیب می‌شوند.به دنبال Rabbit Hole ها باشیدپرداختن به جزئیات عناصر راه‌حل، یک فرآیند سریع و اکتشافی بود. بیشتر جنبه وسعت را داشت تا عمق. در این مرحله، ما سرعت را کم می‌کنیم و به صورت انتقادی به آنچه ارائه کرده‌ایم نگاه می‌کنیم. آیا چیزی را از قلم انداخته‌ایم؟ آیا فرضیات فنی‌ای داریم که منطقی نیستند؟یکی از راه‌های تجزیه و تحلیل راه‌حل این است که یک مورد استفاده (use case) را به صورت حرکت آهسته بررسی کنیم. با توجه به راه‌حلی که طراحی کرده‌ایم، کاربر دقیقاً چگونه از نقطه شروع به نقطه پایان می‌رسد؟ کند کردن و اجرای این سناریو می‌تواند شکاف‌ها یا بخش‌های گم‌شده‌ای را که نیاز به طراحی دارند، آشکار کند.سپس باید قابلیت اجرایی هر بخشی را که فکر می‌کنیم حل کرده‌ایم، زیر سوال ببریم. از خودمان سوالاتی می‌پرسیم مانند:• آیا این کار نیازمند تلاش فنی جدیدی است که قبلاً هرگز انجام نداده‌ایم؟• آیا در مورد نحوه کنار هم قرار گرفتن اجزا فرضیاتی داریم؟• آیا فرض می‌کنیم یک راه‌حل طراحی وجود دارد که خودمان نتوانسته‌ایم آن را ارائه دهیم؟• آیا تصمیم دشواری وجود دارد که باید از قبل آن را مشخص کنیم تا تیم را به مشکل نیندازد؟مطالعه موردی: ترمیم یک نقص (Patching a Hole)به عنوان مثال، زمانی که پروژه "To-Do Groups" را تعریف کردیم، ایده جداکننده‌ها (dividers) را در فهرست کارها معرفی کردیم:تصویر ۳: طراحی اولیه با جداکننده‌ها برای کارهای Loose و Grouped (تصویری که نشان می‌دهد چگونه آیتم‌های To-Do می‌توانند به صورت "Loose" (آزاد) یا "Grouped" (گروه بندی شده با جداکننده‌ها) نمایش داده شوند)ما ایده جداکننده‌ها را دوست داشتیم و منطق "Loose" در مقابل "Grouped" برای ما قابل درک بود. اما وقتی دقیق‌تر نگاه کردیم، متوجه شدیم که به نحوه نمایش آیتم‌های تکمیل شده (completed items) نپرداخته‌ایم. در طراحی موجود، چند آیتم آخر تکمیل شده در زیر لیست نمایش داده می‌شدند. آیا اکنون باید آیتم‌های تکمیل شده را به جای انتهای لیست، در انتهای هر گروه رندر کنیم؟ یا باید نمایش آیتم‌های تکمیل شده را در پایین لیست ادامه دهیم و همان مجموعه جداکننده‌ها را در بخش آیتم‌های تکمیل شده تکرار کنیم؟ آیا باید نحوه رسیدگی به آیتم‌های تکمیل شده را به طور کامل بازنگری کنیم؟این یک نقص در مفهوم (hole in the concept) بود. اگر به آن نمی‌پرداختیم، یک مشکل طراحی عمیق را به تیم منتقل می‌کردیم و به طور غیرمنطقی از آن‌ها می‌خواستیم که راه‌حلی تحت فشار ضرب‌الاجل پیدا کنند. مسئولانه نیست که یک گره درهم‌تنیده‌ای از وابستگی‌های متقابل را به تیم بدهید و سپس از آن‌ها بخواهید که آن را در یک بازه زمانی کوتاه و مشخص باز کنند.ما از تجربه می‌دانستیم که تغییر نحوه رندر شدن کارهای تکمیل شده (completed to-dos) پیامدهای پیچیده‌ای در تجربه کاربری (UX)، مسیریابی (navigation) و عملکرد (performance) دارد. برای از بین بردن عدم قطعیت در پروژه، تصمیم گرفتیم یک راه‌حل را در مفهوم شکل‌گرفته دیکته کنیم. ما آیتم‌های تکمیل شده را دقیقاً همانطور که قبلاً کار می‌کردند، باقی می‌گذاشتیم. به جای گروه‌بندی یا تقسیم‌بندی آن‌ها، فقط نام گروه را به هر آیتم تکمیل شده اضافه می‌کردیم. این شاید کمی نامرتب به نظر می‌رسید، اما ما این بده‌بستان (trade-off) را توجیه کردیم: این کار مشکل را به شدت ساده می‌کرد و ما همچنان می‌توانستیم آیتم‌های تکمیل شده یک گروه را در صفحه جزئیات گروه نمایش دهیم.تصویر ۴: راهکار نهایی برای نمایش آیتم‌های تکمیل شده (تصویری که نشان می‌دهد فقط آیتم‌های "outstanding" (در حال انجام) در گروه‌ها نمایش داده می‌شوند و آیتم‌های تکمیل شده (با تیک) در زیر لیست اصلی قرار می‌گیرند و برچسب گروهشان کنار آن‌ها اضافه می‌شود)این از آن دست بده‌بستان‌هایی است که وقتی تحت فشار در حال کار در چرخه هستید، تصمیم‌گیری در مورد آن دشوار است. دلایل زیادی وجود دارد که چرا یک طراحی متفاوت یا بازنگری عمیق‌تر در مورد کارهای تکمیل شده می‌تواند به صورت عینی بهتر باشد. چرا امتحان نکنیم که آن‌ها را در هر گروه رندر کنیم؟ یک طراح ممکن است به درستی فکر کند: "شاید اگر کمی بیشتر با سبک‌بندی‌ها آزمایش کنم، بتوانم آن‌ها را بهتر ترکیب کنم". آن‌ها به راحتی می‌توانند چند روز از چند هفته‌ی کمی که در اختیار دارند را در یک بن‌بست هدر دهند.به عنوان شکل‌دهنده (shapers)، ما کمتر به طراحی نهایی و بیشتر به کیفیت اساسی و ریسک فکر می‌کنیم. با مفهوم سازش‌یافته (compromised concept)، ما تمام عناصری را که پروژه را ارزشمند می‌کردند – یعنی گروه‌های آیتم‌های ناتمام – حفظ می‌کنیم و بخش بزرگی از ریسک را از بین می‌بریم.در مرحله بعدی، هنگامی که طرح اولیه (pitch) این پروژه را می‌نویسیم، این "وصله" (patch) خاص را به عنوان بخشی از مفهوم برجسته خواهیم کرد. به این ترتیب، هیچ کس در مراحل بعدی درگیر آن نخواهد شد.اعلام موارد خارج از محدوده (Declare Out of Bounds)از آنجایی که همه اعضای تیم می‌خواهند بهترین کار خود را انجام دهند، البته به دنبال پوشش تمام موارد استفاده (use cases) خواهند بود و آن‌ها را ضروری تلقی می‌کنند. با افزایش آشنایی تیم با کنترل دامنه (scope hammering) (به بخش "تصمیم بگیرید چه زمانی متوقف شوید" مراجعه کنید)، این موضوع بهبود می‌یابد. اما هنوز هم ایده خوبی است که مواردی را که صراحتاً پشتیبانی نمی‌کنید، مشخص کنید تا پروژه کاملاً در محدوده "اشتها" (بازه زمانی) باقی بماند.برای مثال، ما روی ایده‌ای برای اطلاع‌رسانی به گروه‌هایی از افراد در Basecamp کار کردیم. به جای انتخاب تیک پنج برنامه‌نویس به صورت تک به تک، می‌توانستید فقط روی "Programmers" کلیک کنید و آن‌ها برای اطلاع‌رسانی انتخاب می‌شدند. همانطور که به محصول نگاه کردیم، مکان‌های زیادی را دیدیم که این نوع رفتار ممکن است منطقی باشد. اگر به شما اجازه می‌دهیم هنگام ارسال پیام یک گروه را انتخاب کنید، چرا هنگام اختصاص یک کار (to-do) یا منشن کردن افراد در اتاق چت این امکان نباشد؟ما برای هدف این پروژه تصمیم گرفتیم که ارزش اصلی، محدود کردن افرادی بود که باید در مورد یک پیام مطلع شوند. ما صراحتاً موارد دیگر را به عنوان "خارج از محدوده (out of bounds)" برای پروژه مشخص کردیم و بر روی هدفی که می‌خواستیم تمرکز کردیم: یک جریان سریع‌تر برای ارسال پیام.کاهش (Cut Back)ممکن است بخش‌هایی از راه‌حل وجود داشته باشند که در مرحله طراحی اولیه (sketching phase) درباره آن‌ها هیجان‌زده شدیم اما واقعاً ضروری نیستند. هنگامی که ویژگی "To-Do Groups" را طراحی کردیم، فکر کردیم که کدگذاری رنگی گروه‌ها (color-code groups) عالی خواهد بود. شکی نیست که صفحه با برچسب‌های گروهی کدگذاری شده با رنگ، جالب‌تر به نظر می‌رسید و این ویژگی ممکن بود مفیدتر نیز باشد. اما ما تصمیم گرفتیم این را به عنوان غیر ضروری علامت‌گذاری کرده و آن را از هسته پروژه حذف کنیم. می‌توانستیم آن را به عنوان یک "خوب است که داشته باشیم (nice-to-have)" به تیم یادآوری کنیم، اما همه باید با این فرض شروع کنند که این ویژگی بدون آن نیز ارزشمند است.ارائه به متخصصان فنی (Present to Technical Experts)تا این مرحله، شکل‌دهی یک فعالیت پشت درهای بسته (closed-door activity) بوده است. قبل از اینکه آماده شوید ایده را برای اشتراک‌گذاری گسترده‌تر بنویسید، ممکن است به ورودی در مورد برخی بخش‌های مفهوم که کاملاً از آن‌ها مطمئن نیستید، نیاز داشته باشید. ممکن است یک فرض فنی (technical assumption) وجود داشته باشد که نیاز دارید با کسی که کد را بهتر می‌فهمد، تأیید کنید. یا شاید می‌خواهید مطمئن شوید که داده‌های کاربری (usage data) با فرضیه‌ای که در مورد رفتار فعلی مشتری دارید، در تضاد نیست.این زمان خوبی است که چند متخصص فنی را جمع کرده و ایده را با آن‌ها در میان بگذارید. به آن‌ها بگویید که این فقط یک ایده است. این چیزی است که شما به عنوان یک شرط‌بندی بالقوه (potential bet) در حال شکل‌دهی آن هستید، نه چیزی که هنوز در حال اجراست. حال و هوا دوستانه-همدست است: "این چیزی است که من به آن فکر می‌کنم... اما هنوز آماده نیستم که به کسی نشان دهم... شما چه فکر می‌کنید؟"از سوال ساده "آیا این ممکن است؟" برحذر باشید. در نرم‌افزار، همه چیز ممکن است اما هیچ چیز رایگان نیست. ما می‌خواهیم بدانیم آیا این کار در محدوده "اشتها" (بازه زمانی) که برای آن شکل‌دهی می‌کنیم، ممکن است یا خیر. به جای پرسیدن "آیا X را می‌توان انجام داد؟"، بپرسید "آیا X در ۶ هفته ممکن است؟". این یک سوال بسیار متفاوت است.در مورد محدودیت‌هایی که این راه‌حل را با توجه به "اشتها" خوب می‌کند صحبت کنید، تا آن‌ها در حفظ اندازه پروژه مد نظر شما شریک باشند. و تأکید کنید که به دنبال ریسک‌هایی هستید که می‌توانند پروژه را منفجر کنند. این فقط یک مکالمه "شما چه فکر می‌کنید" نیست – ما واقعاً به دنبال بمب‌های ساعتی هستیم که ممکن است پروژه را پس از تعهد به یک تیم، منفجر کنند.سعی کنید "خاک رس را مرطوب نگه دارید". به جای نوشتن یک سند یا ایجاد یک اسلایدشو، آن‌ها را به یک تخته وایت‌برد دعوت کنید و عناصر را همانطور که قبلاً کار کرده‌اید، دوباره ترسیم کنید و مفهوم را از ابتدا بسازید. کاملاً به مفهومی که قبلاً کار کرده‌اید پایبند باشید تا بازخورد روی کاری که قبلاً انجام داده‌اید، دریافت کنید. سپس پس از اینکه کار انجام شده خود را پوشش دادید، آن را باز کنید و از آن‌ها دعوت کنید تا بازبینی‌هایی را پیشنهاد دهند. با دیدن این مفهوم، آیا آن‌ها بینشی در مورد چگونگی ساده‌سازی شدید یا رویکرد متفاوت به مشکل دارند؟بسته به نحوه پیشرفت مکالمه، ممکن است رویکرد خود را تأیید کرده باشید یا مشکلاتی را کشف کرده باشید که شما را به دور دیگری از شکل‌دهی بازمی‌گرداند.ریسک‌زدایی شده و آماده برای مستندسازیدر پایان این مرحله، ما عناصر راه‌حل، وصله‌ها (patches) برای Rabbit Hole های احتمالی، و حصارهایی در اطراف مناطقی که خارج از محدوده (out of bounds) اعلام کرده‌ایم، داریم. ما از یک راه‌حل تقریباً شکل‌گرفته با ریسک بالقوه به یک ایده محکم رسیده‌ایم که اکنون امیدواریم در آینده روی آن شرط‌بندی کنیم.این بدان معناست که ما آماده انتقال از شکل‌دهی خصوصی و دریافت بازخورد از حلقه داخلی (inner-circle) به ارائه ایده در میز شرط‌بندی (betting table) هستیم. برای انجام این کار، ما آن را در قالبی می‌نویسیم که مرزها را مشخص کرده و راه‌حل را به وضوح بیان می‌کند تا افراد با آگاهی کمتر نیز بتوانند آن را درک و ارزیابی کنند. این "طرح اولیه (pitch)" سندی خواهد بود که از آن برای لابی کردن برای منابع، جمع‌آوری بازخورد گسترده‌تر در صورت لزوم، یا صرفاً ثبت ایده برای زمانی که زمان مناسب‌تر است در آینده، استفاده خواهیم کرد.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:46:09 +0330 https://virgool.io/@alikarimi/%DB%B3-%D8%B9%D9%86%D8%A7%D8%B5%D8%B1-%D8%B1%D8%A7-%D8%A8%DB%8C%D8%A7%D8%A8%DB%8C%D8%AF-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-t7tgy3p6pjsp حالا که محدودیت‌های مربوط به تمایلات (appetite) و مشکلی که در حال حل آن هستیم را مشخص کرده‌ایم، وقت آن رسیده که از یک ایده صرفاً کلامی به عناصر یک راه‌حل نرم‌افزاری برسیم. ممکن است ده‌ها راه مختلف برای رویکرد به حل یک مشکل وجود داشته باشد. بنابراین، مهم است که بتوانیم سریع حرکت کنیم و ایده‌های مختلف زیادی را پوشش دهیم، بدون اینکه در جزئیات گرفتار شویم.با سرعت مناسب حرکت کنیددو چیز ما را قادر می‌سازد تا در این مرحله با سرعت مناسب حرکت کنیم.اولاً، باید افراد مناسب – یا هیچ‌کس – را در اتاق داشته باشیم. یا به تنهایی کار می‌کنیم یا با یک شریک قابل اعتماد که می‌تواند همگام با ما پیش برود. کسی که بتوانیم با او به صورت مختصر و مفید صحبت کنیم، پیش‌زمینه دانش مشابهی داشته باشد، و بتوانیم هنگام پرش بین ایده‌ها با او صریح باشیم.ثانیاً، باید از پرداختن به جزئیات نامناسب در طراحی‌ها و اسکچ ها پرهیز کنیم. اگر با وایرفریم‌ها یا طرح‌بندی‌های بصری خاص شروع کنیم، درگیر جزئیات غیرضروری می‌شویم و نمی‌توانیم به گستردگی لازم ایده‌ها را بررسی کنیم.چالش اینجا این است که به اندازه‌ای شفاف و ملموس باشیم که در مورد یک راه‌حل خاص پیشرفت کنیم، بدون اینکه درگیر جزئیات ریز شویم. سوالاتی که تلاش می‌کنیم به آن‌ها پاسخ دهیم عبارتند از:• چیز جدید در کجای سیستم فعلی قرار می‌گیرد؟• چگونه به آن دسترسی پیدا می‌کنید؟• اجزا یا تعاملات کلیدی کدامند؟• شما را به کجا می‌برد؟برای حفظ سطح مناسب جزئیات و ثبت افکارمان به همان سرعتی که به ذهن می‌رسند، به صورت دستی با استفاده از دو تکنیک نمونه‌سازی کار می‌کنیم: بردبوردینگ (Breadboarding) و اسکچ‌های با ماژیک ضخیم (Fat Marker Sketches). این روش‌ها به ما اجازه می‌دهند تا به سرعت نسخه‌های مختلفی از جریان‌های کاری کامل را طراحی کنیم تا بتوانیم جوانب مثبت و منفی هر رویکرد را مورد بحث قرار دهیم و در طول مسیر با آنچه در مورد آن صحبت می‌کنیم، هماهنگ بمانیم.بردبوردینگما مفهومی را از مهندسی برق وام می‌گیریم تا به ما در طراحی در سطح مناسب انتزاع کمک کند. بردبورد یک نمونه اولیه مهندسی برق است که تمام اجزا و سیم‌کشی یک دستگاه واقعی را دارد، اما طراحی صنعتی (ظاهری) ندارد.تصمیم‌گیری برای قرار دادن یک چراغ نشانگر و یک دستگیره چرخشی، بسیار متفاوت است از بحث در مورد جنس بدنه، اینکه دستگیره باید سمت چپ چراغ باشد یا راست، گوشه‌ها چقدر باید تیز باشند و غیره.به همین ترتیب، ما می‌توانیم اجزا و اتصالات کلیدی یک ایده رابط کاربری را بدون تعیین یک طراحی بصری خاص، اسکچ بزنیم و در مورد آن‌ها بحث کنیم. برای این کار، می‌توانیم از یک شورت‌هند ساده استفاده کنیم. سه چیز اساسی وجود دارد که ما آن‌ها را ترسیم می‌کنیم:• مکان‌ها (Places): این‌ها چیزهایی هستند که می‌توانید به آن‌ها ناوبری کنید، مانند صفحه‌ها، دیالوگ‌ها یا منوهای بازشونده.• افوردنس‌ها (Affordances): این‌ها چیزهایی هستند که کاربر می‌تواند روی آن‌ها عمل کند، مانند دکمه‌ها و فیلدها. ما متن رابط کاربری را نیز یک افوردنس در نظر می‌گیریم. خواندن آن عملی است که اطلاعاتی برای اقدامات بعدی به کاربر می‌دهد.• خطوط اتصال (Connection lines): این‌ها نشان می‌دهند که چگونه افوردنس‌ها کاربر را از مکانی به مکان دیگر می‌برند.ما برای همه چیز به جای تصاویر از کلمات استفاده خواهیم کرد. موارد مهم، اجزایی هستند که شناسایی می‌کنیم و اتصالات آن‌ها. آن‌ها به ما اجازه می‌دهند تا یک ایده را اجرا کرده و قضاوت کنیم که آیا توالی اقدامات به مورد استفاده (use case) که قصد حل آن را داریم، خدمت می‌کند یا خیر.مثالفرض کنید محصول ما یک ابزار فاکتوردهی است. ما در حال بررسی افزودن یک ویژگی جدید به نام «پرداخت خودکار» (Autopay) هستیم تا مشتریانِ مشتریانمان بتوانند فاکتورهای آتی را به صورت خودکار پرداخت کنند.چگونه پرداخت خودکار را فعال می‌کنید؟ چه چیزهایی درگیر هستند؟ می‌توانیم یک نقطه شروع را انتخاب کنیم و بگوییم که مشتری به یک فاکتور رسیده است. این مکان اول ماست. ما آن را با نوشتن نام مکان و کشیدن یک خط زیر آن ترسیم می‌کنیم.روی فاکتور، ما فکر می‌کنیم می‌توانیم یک دکمه جدید برای «فعال کردن پرداخت خودکار» اضافه کنیم. این یک افوردنس است. افوردنس‌ها زیر خط قرار می‌گیرند تا نشان دهند که در آن مکان یافت می‌شوند.آن دکمه به کجا می‌رود؟ به محلی برای تنظیم پرداخت خودکار. لازم نیست مشخص کنیم که آیا این یک صفحه جداگانه است یا یک مودال پاپ‌آپ یا چه چیزی. از دیدگاه اتصالات (topology)، همه آن‌ها یکسان هستند. بیایید یک خط اتصال از دکمه به صفحه «تنظیم پرداخت خودکار» رسم کنیم.حالا می‌توانیم در مورد محتوای آن صفحه صحبت کنیم. آیا در اینجا اطلاعات کارت اعتباری را درخواست می‌کنیم؟ آیا کارتی از قبل در پرونده وجود دارد؟ در مورد روش‌های پرداخت دیگر مانند ACH چطور؟فقط با نوشتن کلمات زیر خط، بحث‌ها و مناقشاتی درباره اینکه چه چیزی باید ساخته شود، شکل می‌گیرد.همانطور که به آن فکر می‌کنیم، تصمیم می‌گیریم که جزئیات کارت اعتباری را در اینجا درخواست کنیم و لوگوی موسسه مالی (جنبه‌ای از دامنه در این محصول خاص) را نشان دهیم.بسیار ساده به نظر می‌رسد. اما صبر کنید – آیا فاکتور اصلی را واقعاً پرداخت کرده‌ایم یا خیر؟ هممم. حالا هم سوالات کاربردی (functional) و هم سوالات رابط کاربری (interface) داریم. فعال کردن پرداخت خودکار دقیقاً چه کاری انجام می‌دهد؟ آیا فقط برای آینده اعمال می‌شود یا اینکه پرداخت با پرداخت خودکار برای اولین بار، فاکتور فعلی را نیز تسویه می‌کند؟ و کجا این رفتار را توضیح دهیم؟. ما به دلیل چند کلمه و فلش در بردبورد، شروع به طرح سوالات و بحث‌های عمیق‌تری کرده‌ایم.از آنجا که ما از یک نشانه گذاری بسیار سبک استفاده می‌کنیم و درگیر وایرفریم‌ها نیستیم، می‌توانیم به سرعت در اطراف پرش کنیم و احتمالات مختلف را بررسی کنیم.می‌توانیم یک گزینه به صفحه تنظیمات اضافه کنیم…اما حالا مسئولیت‌های صفحه تایید را پیچیده می‌کنیم. اگر الان مانده حساب را پرداخت کنید، باید یک رسید نشان دهیم. آیا صفحه تأیید باید شرطی داشته باشد که گاهی اوقات رسید مبلغی که تازه پرداخت شده را نشان دهد؟یک رویکرد کاملاً متفاوت چطور؟ به جای شروع از یک فاکتور، پرداخت خودکار را به عنوان یک گزینه هنگام انجام پرداخت در نظر بگیریم. به این ترتیب هیچ ابهامی در مورد اینکه آیا مبلغ فعلی پرداخت می‌شود وجود ندارد. می‌توانیم یک فراخوانی اضافی "پرداخت خودکار فعال شد" را به صفحه تأیید پرداخت موجود اضافه کنیم.ترسیم این طرح به ما یادآوری کرد که فرم پرداخت فعلی علاوه بر کارت اعتباری، از ACH نیز پشتیبانی می‌کند. ما بحث کرده و تأیید می‌کنیم که می‌توانیم از ACH نیز استفاده کنیم.بعد از فعال شدن پرداخت خودکار چه می‌شود؟ چگونه مشتری آن را غیرفعال می‌کند؟. تا این نقطه، بسیاری از مشتریان در سیستم نام کاربری یا رمز عبور نداشتند. آن‌ها از طریق لینک‌های توکنیزه‌شده فاکتورها را یکی یکی پرداخت می‌کردند. ممکن است به طور طبیعی تصور شود که اکنون که مشتری چیزی مانند پرداخت خودکار را فعال کرده است، به نام کاربری و رمز عبور و محلی برای مدیریت آن نیاز دارد.در این مورد، تیم تصمیم گرفت که اضافه کردن جریان‌های نام کاربری/رمز عبور برای "تمایلات" (appetite) آن‌ها در آن زمان بیش از حد از محدوده پروژه (scope) بود. با تفکر استراتژیک در مورد آنچه از مشتریان خود می‌دانستند، به این نتیجه رسیدند که اگر مشتریان فاکتوردهنده مجبور باشند با فاکتوردهنده تماس بگیرند و از او بخواهند پرداخت خودکار را غیرفعال کند، مشکلی پیش نخواهد آمد. در این صورت، می‌توانیم یک گزینه واحد برای غیرفعال کردن پرداخت خودکار را در صفحه جزئیات مشتری که از قبل به فاکتوردهندگان ارائه می‌کردیم، اضافه کنیم. ما جریان را اینگونه طراحی کردیم:این مثال، سطح تفکر و سرعت حرکتی را که باید در مرحله بردبوردینگ هدف قرار دهیم، نشان می‌دهد. نوشتن جریان‌ها ما را با سوالاتی روبرو می‌کند که در ابتدا به آن‌ها فکر نکرده بودیم و ایده‌های طراحی را تحریک می‌کند، بدون اینکه ما را با انتخاب‌های بصری بی‌اهمیت منحرف کند.هنگامی که به جایی می‌رسیم که مورد استفاده را اجرا می‌کنیم و جریان مناسب به نظر می‌رسد، عناصر مورد نیاز برای شروع تعریف روشن‌تر پروژه را در دست داریم. ما در حال ملموس‌تر شدن هستیم، در حالی که هنوز مقدار زیادی از جزئیات را کنار گذاشته‌ایم.اسکچ های با ماژیک ضخیمگاهی اوقات ایده‌ای که در ذهن داریم، یک ایده بصری است. بردبوردینگ در این حالت به درستی هدف را نمی‌رساند زیرا آرایش دوبعدی عناصر مشکل اساسی است. در این حالت، ما همچنان نمی‌خواهیم وقت خود را با وایرفریم‌ها یا دقت غیرضروری هدر دهیم. در عوض، از اسکچ های با ماژیک ضخیم استفاده می‌کنیم.یک اسکچ با ماژیک ضخیم، اسکچی است که با ضربات قلمی آنقدر پهن کشیده می‌شود که اضافه کردن جزئیات دشوار یا غیرممکن است. ما در ابتدا این کار را با ماژیک‌های شارپی با نوک بزرگتر روی کاغذ انجام می‌دادیم. امروزه این کار را روی آی‌پد با تنظیم اندازه قلم روی قطر بزرگ نیز انجام می‌دهیم.در اینجا یک مثال آورده شده است. ما اغلب در لیست‌های وظایف (to-do lists) بیس‌کمپ (Basecamp) خود، وظایف ساختگی ایجاد می‌کردیم که به عنوان جداکننده عمل می‌کردند. ما یک آیتم مانند "--- نیاز به تست ---" ایجاد می‌کردیم و آیتم‌ها را زیر آن قرار می‌دادیم. ایده داشتیم که نوعی ویژگی جداکننده رسمی را در ابزار وظایف خود ایجاد کنیم تا این راهکار موقت را به یک عملکرد درجه یک در لیست‌های وظایف تبدیل کنیم.باید پیامدهای اضافه کردن یک جداکننده را بررسی می‌کردیم. به ایده تقریبی رسیدیم که افزودن یک جداکننده، لیست را به وظایف «آزاد» در بالای جداکننده و وظایف «گروه‌بندی شده» در پایین تقسیم می‌کند. افزودن جداکننده‌های بعدی، گروه‌های بیشتری را در زیر آیتم‌های «آزاد» در بالا اضافه می‌کند.می‌توانستیم آیتم‌ها را از طریق یک افوردنس در هر گروه، از جمله گروه «آزاد» در بالا، اضافه کنیم.کمی نگران بودیم که دکمه‌های «اضافه کردن» ممکن است انسجام لیست را به هم بزنند، و گروه‌ها ممکن است بیش از حد از لیست‌های موجود در صفحه جدا شوند. در مورد امکان قرار دادن افوردنس «اضافه کردن» در منویی که قبلاً در سمت چپ هر آیتم وظیفه داشتیم، صحبت کردیم.این نشانه گذاری بسیار کمتر از بردبوردها محدودکننده است، که البته معایبی هم دارد. ممکن است یک نوار کناری (sidebar) را ترسیم کنیم و به یک عنصر طرح‌بندی مانند آن وابسته شویم، حتی اگر یک عنصر اصلی نباشد. اما تا زمانی که مراقب این موضوع باشیم، همچنان وضعیتمان بسیار بهتر از زمانی است که با ایجاد زودهنگام وایرفریم‌ها، در جزئیات گرفتار شویم.ممکن است کمی مضحک به نظر برسد که اسکچ های با ماژیک ضخیم را یک تکنیک یا ابزار بنامیم. دلیل نام بردن از آن‌ها این است که ما به راحتی به سطح نامناسبی از دقت (fidelity) می‌پریم. نام‌گذاری این مرحله اولیه و خشن و استفاده از یک ابزار خاص برای آن، به ما کمک می‌کند تا فرآیند خلاقیت خود را تقسیم‌بندی کنیم و مطمئن شویم که به جزئیات یک ایده خاص نپریده‌ایم، در حالی که هنوز میدان را به اندازه کافی بررسی نکرده‌ایم.عناصر، خروجی هستنددر مورد مثال پرداخت خودکار، ما به چند عنصر مشخص رسیدیم:• یک چک‌باکس جدید "استفاده از این برای پرداخت خودکار؟" در صفحه موجود "پرداخت یک فاکتور".• یک گزینه "غیرفعال کردن پرداخت خودکار" در سمت فاکتوردهنده.برای پروژه "گروه‌های وظایف" (To-Do Groups)، عناصر عبارت بودند از:• وظایف "آزاد" (loose) بالای گروه اول مستقیماً به والد تعلق دارند.• وظایف "گروه‌بندی شده" (grouped) در زیر وظایف آزاد ظاهر می‌شوند.• ما می‌خواهیم یک افوردنس "اضافه کردن" را در هر بخش امتحان کنیم، اما اگر از نظر بصری کار نکرد، مشکلی نداریم که برای قرار دادن وظایف در موقعیت مورد نظر، به منوی اقدام (action menu) تکیه کنیم.به همین ترتیب، هنگامی که راه‌حل ساده شده برای نمایش رویدادها در یک شبکه تقویم را طراحی کردیم، از رویکرد ماژیک ضخیم استفاده کردیم.این کار ما را قادر ساخت تا عناصر اصلی راه‌حل را مشخص کنیم:• یک شبکه تقویم ماهانه ۲-تایی (۲ ماه در کنار هم).• نقطه‌ها برای رویدادها، بدون نشانگرهای کشیده (spanned pills).• یک لیست رویدادها به سبک تقویم (agenda-style) در زیر که با لمس یک نقطه، رویداد مربوطه را به نمایش در می‌آورد.این لیست عناصر در مقایسه با عبارت "تقویم ماهانه" بسیار محدود و خاص است. دقیقاً همان نوع محدودسازی که امیدواریم از طریق فرآیند شکل‌دهی (shaping) به آن دست یابیم.فضایی برای طراحانبعداً، زمانی که نوبت به مشارکت یک طراح می‌رسد، نمی‌خواهید مجبور باشید بگویید "می‌دانم که اینطور ترسیم کردم، اما این را نادیده بگیرید...". صرف نظر از آنچه می‌گویید، هر گونه ماکت (mockup) خاص، کاری را که دیگران پس از شما انجام می‌دهند، تحت تأثیر قرار می‌دهد – به خصوص اگر در موقعیت بالاتری نسبت به آن‌ها باشید. آن‌ها هر جزئیات در ماکت‌های اولیه را به عنوان جهت‌دهی تلقی خواهند کرد، حتی اگر شما چنین قصدی نداشته باشید.کار کردن در "سطح انتزاع" مناسب نه تنها تضمین می‌کند که با سرعت مناسب حرکت می‌کنیم، بلکه این فضای مهم برای خلاقیت را در مراحل بعدی نیز باقی می‌گذارد.با حذف جزئیات، روش‌های بردبورد و ماژیک ضخیم فضایی برای طراحان در مراحل بعدی پروژه ایجاد می‌کنند.این یک تم (theme) در فرآیند شکل‌دهی (shaping) است. ما پروژه را خاص‌تر و ملموس‌تر می‌کنیم، اما همچنان فضای زیادی را برای تصمیم‌گیری‌ها و انتخاب‌ها در آینده باقی می‌گذاریم. این یک مشخصات (spec) نیست. بیشتر شبیه مرزها و قوانین یک بازی است. وقتی زمان بازی فرا برسد، می‌تواند به روش‌های بی‌شماری پیش برود.هنوز قابل تحویل نیستاین مرحله از شکل‌دهی هنوز به طور کامل در حوزه خصوصی شما قرار دارد. طبیعی است که محصولات این مرحله – روی دیوار یا در دفترچه یادداشت شما – برای هر کسی که با شما نبوده، کم و بیش ناخوانا باشد.ما از یک ایده مبهم، مانند "پرداخت خودکار" یا "گروه‌های وظایف"، به یک رویکرد خاص و تعدادی عناصر ملموس رسیده‌ایم. اما شکلی که در دست داریم هنوز بسیار خام و عمدتاً در حد یک طرح کلی است.کاری که ما انجام داده‌ایم، رسیدن به یک رویکرد برای حل مشکل است. اما ممکن است برخی ناشناخته‌های قابل توجه یا چیزهایی وجود داشته باشند که باید قبل از اینکه این را برای تیم جهت ساخت با موفقیت ایمن بدانیم، به آن‌ها بپردازیم.گام بعدی انجام آزمایش تنش (stress-testing) و کاهش ریسک (de-risking) است. ما می‌خواهیم شکاف‌ها و چالش‌هایی را بررسی کنیم که می‌توانند پروژه را از ارسال در "محدودیت زمانی" (fixed time appetite) که برای آن در نظر گرفته‌ایم، بازدارند.پس از آن، خواهیم دید که چگونه مفهوم شکل‌گرفته (shaped concept) را در یک نوشتار برای ارائه (pitching) جمع‌بندی کنیم.بدون خط مونتاژ (No conveyor belt)همچنین به خاطر داشته باشید که در این مرحله، می‌توانیم پروژه را رها کنیم. ما روی آن شرط نبسته‌ایم. هیچ تعهد یا قولی در مورد آن نداده‌ایم. کاری که انجام داده‌ایم، افزودن ارزش به ایده خام با عملیاتی‌تر کردن آن است. ما به یک گزینه خوب نزدیک‌تر شده‌ایم که بعداً می‌توانیم هنگام تخصیص منابع، برای آن لابی کنیم.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:45:18 +0330 https://virgool.io/@alikarimi/%DB%B2-%D8%AA%D8%B9%DB%8C%DB%8C%D9%86-%D9%85%D8%B1%D8%B2%D9%87%D8%A7-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-bq4jcranygqo اولین قدم در شکل‌دهی، تعیین مرزها برای کاری است که قصد انجامش را داریم. مکالمات ما کاملاً متفاوت خواهد بود اگر افراد تصور کنند که ما در مورد یک بهبود کوچک صحبت می‌کنیم یا یک بازطراحی بزرگ.بحث در مورد ساخت یک قابلیت همیشه با یک ایده خام شروع می‌شود، مثلاً «مشتریان درخواست نوتیفیکیشن‌های گروهی دارند.» قبل از اینکه همگی وارد بحث‌های مفصل و بی‌پایان برای راه‌حل‌ها شویم، باید ابتدا شرایط کلی گفتگو را تعیین کنیم تا مثمر ثمر باشد.تعیین اشتها (Appetite)گاهی اوقات یک ایده بلافاصله ما را هیجان‌زده می‌کند. در این صورت، باید این هیجان را با بررسی اینکه آیا واقعاً می‌توانیم زمانی را به آن اختصاص دهیم یا خیر، تعدیل کنیم. اگر برای تفکر در مورد ارزش ایده توقف نکنیم، ممکن است همه به سرعت یا به تخصیص منابع متعهد شویم یا وارد بحث‌های طولانی در مورد راه‌حل‌های بالقوه‌ای شویم که به جایی نمی‌رسند.ایده‌های دیگر کمتر هیجان‌انگیز هستند و بیشتر شبیه یک چالش ناخواسته به نظر می‌رسند. مشتری یک تقویم می‌خواهد؛ ما واقعاً تمایلی به ساخت آن نداریم، اما احساس می‌کنیم باید کاری در مورد این درخواست انجام دهیم.چه مشتاق باشیم و چه تمایلی به شروع نداشته باشیم، تعیین صریح اینکه این موضوع چقدر از زمان و توجه ما را می‌طلبد، کمک‌کننده است. آیا این موضوع ارزش یک راه‌حل سریع را دارد، اگر بتوانیم آن را مدیریت کنیم؟ آیا این یک ایده بزرگ است که ارزش یک چرخه (Cycle) کامل را دارد؟ آیا برای جای دادن آن، آنچه را که داریم بازطراحی خواهیم کرد؟ آیا فقط در صورتی آن را در نظر می‌گیریم که بتوانیم آن را به عنوان یک تغییر کوچک پیاده‌سازی کنیم؟ما این را اشتها (Appetite) می‌نامیم. می‌توانید اشتها را به عنوان یک بودجه زمانی برای یک تیم با اندازه استاندارد در نظر بگیرید. ما معمولاً اشتها را در دو اندازه تعیین می‌کنیم:• دسته‌بندی کوچک (Small Batch): این پروژه‌ای است که یک تیم شامل یک طراح و یک یا دو برنامه‌نویس می‌تواند در یک یا دو هفته بسازد. ما اینها را با هم در یک چرخه شش هفته‌ای دسته‌بندی می‌کنیم (جزئیات بیشتر بعداً).• دسته‌بندی بزرگ (Big Batch): این پروژه برای تیمی با همین اندازه، شش هفته کامل زمان می‌برد.در موارد نادری که دامنه (Scope) آنقدر بزرگ است که یک پروژه شش هفته‌ای قابل تصور نیست، تلاش می‌کنیم با محدود کردن تعریف مسئله، آن را کوچک‌تر کنیم. اگر باز هم نتوانیم دامنه را کوچک کنیم، بخش معناداری از پروژه را جدا خواهیم کرد که می‌توانیم آن را متناسب با اشتهای شش هفته‌ای شکل دهیم.زمان ثابت، دامنه متغیر (Fixed Time, Variable Scope)اشتها (Appetite) کاملاً با تخمین (Estimate) متفاوت است. تخمین‌ها با یک طراحی شروع می‌شوند و با یک عدد به پایان می‌رسند. اشتهاها با یک عدد شروع می‌شوند و با یک طراحی به پایان می‌رسند. ما از اشتها به عنوان یک محدودیت خلاقانه در فرآیند طراحی استفاده می‌کنیم.این اصل، که «زمان ثابت، دامنه متغیر» نامیده می‌شود، کلید موفقیت در تعریف و ارائه پروژه‌ها است. این کتاب را به عنوان مثال در نظر بگیرید. ارائه یک کتاب دشوار است وقتی همیشه می‌توانید مطالب بیشتری اضافه کنید، بیشتر توضیح دهید یا آنچه را که از قبل وجود دارد بهبود بخشید. وقتی مهلت (Deadline) دارید، ناگهان مجبور به تصمیم‌گیری می‌شوید. با یک هفته باقی مانده، می‌توانم بین رفع غلط‌های املایی یا افزودن بخش جدیدی به یک فصل، یکی را انتخاب کنم. این همان کشش بین زمان، کیفیت و دامنه است. من نمی‌خواهم کتابی با غلط‌های املایی شرم‌آور منتشر کنم، بنابراین انتخاب می‌کنم دامنه را با حذف بخش اضافی کاهش دهم. بدون فشار مهلت ثابت، من این بده بستان را انجام نمی‌دادم. اگر دامنه متغیر نبود، مجبور بودم بخش اضافی را اضافه کنم. در این صورت، وقتی برای رفع مشکلات کیفی باقی نمی‌ماند.ما این اصل را در هر مرحله از فرآیند، از شکل‌دهی پروژه‌های بالقوه گرفته تا ساخت و ارائه آنها، به کار می‌بریم. اولاً، اشتها تعیین می‌کند که چه نوع راه‌حلی را در طول فرآیند شکل‌دهی طراحی کنیم. بعداً، وقتی کار را به یک تیم واگذار می‌کنیم، زمان‌بندی ثابت (Time Box) آنها را وادار می‌کند تا در مورد اینکه چه چیزی برای پروژه اصلی است و چه چیزی جانبی یا غیرضروری، تصمیم‌گیری کنند.«خوب» نسبی استهیچ تعریف مطلقی برای «بهترین» راه‌حل وجود ندارد. بهترین، نسبی و وابسته به محدودیت‌های شماست. بدون محدودیت زمانی، همیشه یک نسخه بهتر وجود دارد. شاید بهترین غذا یک شام ده قسمتی باشد. اما وقتی گرسنه و عجله دارید، یک هات‌داگ عالی است.میزان زمانی که برای اشتهای خود تعیین می‌کنیم، ما را به راه‌حل‌های متفاوتی هدایت خواهد کرد. ما می‌توانیم در نسخه پیشرفته، یک مجموعه کامل از ستون‌های پایگاه داده را مدل‌سازی کنیم، یا فقط یک فیلد متنی ساده در نسخه ساده ارائه دهیم. می‌توانیم صفحه اصلی (Landing Page) را برای جای دادن یک قابلیت جدید بازطراحی کنیم، یا آن را به صفحه‌ای با محدودیت‌های طراحی کمتر منتقل کنیم. ما تنها می‌توانیم «راه‌حل خوب» را در چارچوب میزان زمان و اهمیتی که می‌خواهیم صرف کنیم، قضاوت کنیم.پاسخ به ایده‌های خامپاسخ پیش‌فرض ما به هر ایده‌ای که مطرح می‌شود باید این باشد: «جالب است. شاید روزی...». به عبارت دیگر، یک «نه» بسیار ملایم که همه گزینه‌های ما را باز نگه می‌دارد. ما آن را در بک‌لاگ (Backlog) قرار نمی‌دهیم. به آن فضا می‌دهیم تا بتوانیم بفهمیم آیا واقعاً مهم است و چه چیزی را ممکن است در بر داشته باشد.گفتن «بله» یا «خیر» در اولین برخورد خیلی زود است. حتی اگر هیجان‌زده باشیم، نباید تعهدی را بپذیریم که هنوز آن را درک نکرده‌ایم. باید روی ایده کار کنیم قبل از اینکه به اندازه کافی شکل بگیرد تا بتوانیم منابع را روی آن شرط‌بندی کنیم. اگر همیشه به درخواست‌های دریافتی «بله» بگوییم، در نهایت با کوهی از کار روبرو خواهیم شد که فقط بزرگ‌تر می‌شود.مهم است که خونسرد و کمی بی‌تفاوت (Poker Face) باشیم. نمی‌خواهیم ایده‌ای را که درک نمی‌کنیم، رد کنیم. ممکن است فردا اطلاعات جدیدی به دستمان برسد که باعث شود آن را متفاوت ببینیم. از سوی دیگر، نشان دادن شور و اشتیاق زیاد بلافاصله می‌تواند انتظاراتی را ایجاد کند که این اتفاق خواهد افتاد. ممکن است نتوانیم به آن متعهد شویم پس از اینکه آن را در بستر سایر کارهایی که می‌خواهیم انجام دهیم، قرار دادیم.محدود کردن مشکلعلاوه بر تعیین اشتها، معمولاً باید درک خود از مشکل را محدودتر کنیم.یک بار مشتری از ما قوانین دسترسی پیچیده‌تری درخواست کرد. ساخت تغییری که او می‌خواست به راحتی می‌توانست شش هفته طول بکشد. به جای پذیرش درخواست به ظاهر، عمیق‌تر کاوش کردیم. معلوم شد که شخصی فایلی را آرشیو کرده بود بدون اینکه بداند این فایل برای سایر کاربران سیستم ناپدید می‌شود. به جای ایجاد قانونی برای جلوگیری از آرشیو کردن توسط برخی افراد، متوجه شدیم می‌توانیم یک اخطار روی خود عملیات آرشیو قرار دهیم که تأثیر آن را توضیح دهد. این یک تغییر یک روزه است به جای یک پروژه شش هفته‌ای.مثال دیگر، «نمای تقویم» از فصل قبلی است. همه می‌دانند نمای تقویم چیست. اما باز کردن آن، تعداد زیادی ناشناخته و تصمیماتی را آشکار کرد که می‌توانست به شدت بر دامنه تأثیر بگذارد. اگر فقط می‌خواهیم شش هفته به جای شش ماه برای ساخت یک تقویم عظیم صرف کنیم، چگونه آن را محدود می‌کنیم؟در این حالت، از پرسیدن «چه چیزی می‌توانیم بسازیم؟» به «چه چیزی واقعاً مشکل دارد؟» تغییر مسیر می‌دهیم. مسلماً، یک تقویم خوب به نظر می‌رسد. اما چه چیزی این درخواست را هدایت می‌کند؟ دقیقاً در کدام نقطه، جریان کاری فعلی فرد بدون این چیزی که درخواست می‌کند، دچار مشکل می‌شود؟مطالعه موردی: تعریف «تقویم»در مورد درخواست تقویم، با مشتری که این قابلیت را خواسته بود، تماس گرفتیم. به جای پرسیدن اینکه چرا یک تقویم می‌خواهد و چه شکلی باید باشد، از او پرسیدیم چه زمانی به یک تقویم نیاز پیدا کرد. او مشغول چه کاری بود که فکر درخواست تقویم به ذهنش رسید؟او به ما گفت که در دفتری کار می‌کند که یک تقویم بزرگ روی دیوار تخته سیاه کشیده شده بود. همکارانش زمان ملاقات با مشتریان در چند اتاق جلسه را روی تقویم علامت‌گذاری می‌کردند. یک روز او از خانه کار می‌کرد. یک مشتری تماس گرفت و از او خواست که جلسه‌ای را برنامه‌ریزی کند. او مجبور شد به دفتر رانندگی کند تا تقویم دیواری را ببیند. ترافیک در مسیر وحشتناک بود و در نهایت هیچ فضای خالی‌ای که برای مشتری‌اش مناسب باشد، وجود نداشت. اگر می‌توانست از طریق کامپیوترش در خانه، نقاط خالی روی تقویم را بررسی کند، می‌توانست یک ساعت از ترافیک و بسیاری از ناامیدی‌ها را صرفه‌جویی کند.بینش (Insight) این نبود که «تقویم را کامپیوتری کنیم»—این بدیهی است. آنچه ما آموختیم این بود که «دیدن فضاهای خالی» نکته مهم برای این مورد استفاده (Use Case) بود، نه «انجام هر کاری که یک تقویم انجام می‌دهد». این داستان و داستان‌های مشابه آن، یک خط مبنای مشخص برای طراحی به ما داد. Basecamp یک نمای دستور کار (Agenda View) برای رویدادها داشت. برای فهرست کردن مهلت‌ها و نقاط عطف اصلی کار می‌کرد، اما برای برنامه‌ریزی منابع مناسب نبود زیرا نمی‌توانستید فضاهای خالی را در آن ببینید. ما نیاز را از «انجام هر کاری که یک تقویم انجام می‌دهد» به «کمک به من برای دیدن فضاهای خالی تا بتوانم بفهمم چه زمانی چیزی را برنامه‌ریزی کنم» محدود کردیم.هنوز راه‌حلی نداشتیم. اما حالا احساس می‌کردیم مشکلی داریم که به اندازه کافی مشخص است تا ایده‌ای را جرقه بزند که بتواند در اشتهای ما جای بگیرد. این ما را به مفهوم ساده‌تر «شبکه نقطه‌ای (Dot Grid)» از فصل گذشته هدایت کرد.اگر نتوانیم یک نقطه درد (Pain Point) مشخص یا مورد استفاده را کشف کنیم، چه می‌شود؟ اشتهای ما همچنین می‌تواند به ما بگوید چقدر تحقیق ارزشمند است. اگر در حال حاضر حیاتی نیست و نمی‌توانیم مشکل را درک کنیم، از آن صرف نظر می‌کنیم و روی چیز دیگری کار می‌کنیم. شاید در آینده یک درخواست یا داستان جدید ظاهر شود که بینش بهتری نسبت به مشکل به ما بدهد.مراقب «کیسه محتویات متفرقه» باشیدوقتی صحبت از ایده‌های نامشخص می‌شود، بدترین موارد «بازطراحی‌ها (Redesigns)» یا «بازسازی‌ها (Refactorings)» هستند که با یک مشکل یا مورد استفاده واحد هدایت نمی‌شوند. وقتی کسی چیزی شبیه «بازطراحی بخش فایل‌ها» را پیشنهاد می‌کند، این یک کیسه محتویات متفرقه (Grab-Bag) است، نه یک پروژه. فهمیدن اینکه به چه معناست، از کجا شروع می‌شود و کجا به پایان می‌رسد، بسیار دشوار خواهد بود. اینجا یک نقطه شروع پربارتر است: «باید بخش فایل‌ها را بازنگری کنیم زیرا اشتراک‌گذاری چندین فایل مراحل زیادی را می‌طلبد.». حالا می‌توانیم بپرسیم: چه چیزی کار نمی‌کند؟ در چه زمینه‌ای مراحل زیادی وجود دارد؟ کدام بخش‌های طراحی موجود می‌توانند دست نخورده باقی بمانند و کدام بخش‌ها نیاز به تغییر دارند؟یک نشانه آشکار از یک کیسه محتویات متفرقه، برچسب «2.0» است. ما در گذشته اشتباه کردیم و یک پروژه «فایل‌ها 2.0» را بدون در نظر گرفتن واقعی معنای آن شروع کردیم. هیجان ما برای بهبود بخش بزرگی از برنامه، بر ما غلبه کرد. می‌دانستیم قابلیت فایل‌های ما مشکلات زیادی دارد، اما از خودمان نپرسیدیم که دقیقاً قرار است چه کاری انجام دهیم. پروژه آشفته از آب درآمد چون نمی‌دانستیم «تکمیل شده» چه شکلی است. ما با تقسیم پروژه به پروژه‌های کوچک‌تر، مانند «پیش‌نمایش‌های بهتر فایل» و «رنگ‌های سفارشی پوشه»، بهبود یافتیم. ما برای هر پروژه اشتها و انتظارات روشنی تعیین کردیم و آنها را با موفقیت ارائه دادیم.مرزها در جای خودوقتی هر سه مورد را داشته باشیم—یک ایده خام، یک اشتها، و یک تعریف محدود از مشکل—آماده‌ایم تا به مرحله بعدی برویم و عناصر یک راه‌حل را تعریف کنیم.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:44:37 +0330 https://virgool.io/@alikarimi/1-%D8%A7%D8%B5%D9%88%D9%84-%D8%B4%DA%A9%D9%84-%D8%AF%D9%87%DB%8C-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-vfmebvgfikmf زمانی که کار را شکل می‌دهیم (shape)، باید آن را در سطح مناسبی از انتزاع انجام دهیم: نه خیلی مبهم و نه خیلی ملموس. مدیران محصول اغلب در یکی از این دو افراط اشتباه می‌کنند.وایرفریم‌ها بیش از حد ملموس هستندزمانی که رهبران طراحی مستقیم سراغ وایرفریم‌ها یا ماکاپ‌های با جزئیات بالا می‌روند، جزئیات زیادی را خیلی زود تعریف می‌کنند. این کار فضایی برای خلاقیت طراحان باقی نمی‌گذارد. یکی از دوستان این موضوع را این‌گونه بیان کرد:من یک وایرفریم به طراح می‌دهم و بعد به او می‌گویم: «می‌دانم که داری به این نگاه می‌کنی، اما این چیزی نیست که می‌خواهم طراحی کنی. می‌خواهم آن را دوباره فکر کنی!» انجام این کار وقتی داری یک چیز ملموس به آن‌ها می‌دهی، سخت است.مشخص کردن بیش از حد طراحی همچنین منجر به خطاهای برآورد می‌شود. هرچند ممکن است غیرمنتظره به نظر برسد، اما هرچه کار مشخص‌تر باشد، برآورد آن سخت‌تر می‌شود. این به این دلیل است که دقیقاً انجام دادن یک رابط کاربری ممکن است نیازمند حل پیچیدگی‌های پنهان و جزئیات پیاده‌سازی باشد که در ماکاپ قابل مشاهده نبوده‌اند. وقتی دامنه کار (scope) متغیر نباشد، تیم نمی‌تواند تصمیم طراحی‌ای را که معلوم می‌شود هزینه‌اش بیشتر از ارزشش است، بازنگری کند.کلمات بیش از حد انتزاعی هستنددر سوی دیگر طیف، پروژه‌هایی که بیش از حد مبهم هستند نیز کار نمی‌کنند. وقتی یک پروژه در چند کلمه تعریف می‌شود، هیچ‌کس نمی‌داند دقیقاً به چه معناست. عباراتی مانند «ساخت یک نمای تقویم» یا «اضافه کردن اعلان‌های گروهی» معقول به نظر می‌رسند، اما دقیقاً چه چیزی را شامل می‌شوند؟ اعضای تیم اطلاعات کافی برای تصمیم‌گیری در مورد مبادلات (trade-offs) را ندارند. آن‌ها نمی‌دانند چه چیزی را شامل کنند یا چه چیزی را کنار بگذارند. یک برنامه‌نویس که در چنین وضعیتی کار کرده بود، گفت:شما دارید مشکلی را بدون هیچ زمینه‌ای حل می‌کنید. باید ذهن‌خوان باشید. انگار که: «وقتی ببینیم، می‌فهمیم چیست.»در مورد برآورد، پروژه‌هایی که به درستی مشخص نشده‌اند به طور طبیعی از کنترل خارج می‌شوند، زیرا هیچ مرز مشخصی برای تعیین آنچه خارج از دامنه (out of scope) است، وجود ندارد.مطالعه موردی: تقویم نقطه‌ای (Dot Grid)بیایید به مثالی نگاه کنیم که چگونه یک پروژه را در سطح مناسبی از جزئیات شکل دهیم.ما نسخه سوم بیس‌کمپ (Basecamp) را بدون قابلیت تقویم راه‌اندازی کردیم. این نسخه یک ویژگی «برنامه (schedule)» داشت که فقط رویدادها را یکی پس از دیگری بدون هیچ نوع شبکه ماهانه، هفتگی یا روزانه فهرست می‌کرد.اندکی پس از راه‌اندازی، مشتریان شروع به درخواست «اضافه کردن تقویم» به بیس‌کمپ کردند. ما قبلاً تقویم ساخته بودیم و می‌دانستیم که چقدر پیچیده هستند. ساخت یک تقویم مناسب به راحتی می‌تواند شش ماه یا بیشتر طول بکشد.این‌ها از جمله مواردی هستند که یک تقویم را پیچیده می‌کنند:• کشیدن و رها کردن رویدادها بین سلول‌ها برای جابجایی آن‌ها• پیچیدن رویدادهای چندروزه به دور لبه صفحه نمایش• نماهای مختلف برای مقیاس‌های زمانی ماهانه، هفتگی یا روزانه• کشیدن لبه یک رویداد برای تغییر مدت زمان آن• کدگذاری رنگی رویدادها برای دسته‌بندی‌های مختلف• مدیریت انتظارات مختلف برای تعاملات دسکتاپ در مقابل موبایلنسخه‌های قبلی بیس‌کمپ تقویم داشتند، و تنها حدود ۱۰ درصد از مشتریان از آن‌ها استفاده می‌کردند. به همین دلیل ما تمایلی به صرف شش ماه روی تقویم نداشتیم. از طرف دیگر، اگر می‌توانستیم کاری انجام دهیم تا آن دسته از مشتریانی که به ما نامه می‌نوشتند را در یک چرخه شش هفته‌ای راضی کنیم، آماده بودیم آن را انجام دهیم.با تنها شش هفته زمان کاری، ما می‌توانستیم تنها حدود یک‌دهم آنچه مردم وقتی می‌گویند «تقویم» به آن فکر می‌کنند را بسازیم. سوال این شد: کدام یک‌دهم؟ما تحقیقاتی انجام دادیم (که در فصل بعدی مورد بحث قرار می‌گیرد) و یک مورد استفاده (use case) را که می‌خواستیم حل کنیم، محدود کردیم. در نهایت به یک مفهوم امیدوارکننده رسیدیم که از تقویم‌های روی تلفن‌ها الهام گرفته شده بود. ما می‌توانستیم یک نمای شبکه‌ای دوماهه و فقط خواندنی بسازیم. هر روزی که رویدادی داشت، برای هر رویداد یک نقطه (dot) خواهد داشت. لیستی از رویدادها زیر تقویم ظاهر می‌شد و با کلیک روی روزی که نقطه داشت، رویدادهای آن روز به نمایش درمی‌آمدند. ما آن را شبکه نقطه‌ای (Dot Grid) نامیدیم.شبکه نقطه‌ای یک تقویم با تمام قابلیت‌ها نبود. ما اجازه کشیدن رویدادها بین روزها را نمی‌دادیم. رویدادهای چندروزه را در سراسر شبکه گسترش نمی‌دادیم؛ فقط نقاط را تکرار می‌کردیم. هیچ کدگذاری رنگی یا دسته‌بندی برای رویدادها وجود نداشت. ما با تمام این مبادلات (trade-offs) راحت بودیم، زیرا درک کاملی از مورد استفاده داشتیم.این سطح از جزئیات بود که ما برای تعریف راه‌حل استفاده کردیم:[تصویر: طرح اولیه مفهوم Dot Grid که بسیار ساده و شامل خطوط و نقاط است]توجه کنید که طرح چقدر اولیه است و چه جزئیات زیادی حذف شده‌اند. طراح فضای زیادی برای تفسیر نحوه ظاهر و حس این طرح داشت.در عین حال، توجه کنید که ایده چقدر خاص است. بسیار واضح است که چگونه کار می‌کند، چه چیزی باید ساخته شود، چه چیزی شامل می‌شود و چه چیزی حذف می‌شود.در پایان پروژه، کار تکمیل‌شده‌ای که طراحان و برنامه‌نویسان ایجاد کردند، این‌گونه به نظر می‌رسید:[تصویر: اسکرین‌شات Dot Grid در زمان راه‌اندازی که شامل نمای تقویم دو ماهه با نقاط و لیست رویدادها در پایین است]این مثال کوچک چند ویژگی کار شکل‌یافته را برجسته می‌کند.ویژگی ۱: خام و اولیه استکار در مرحله شکل‌دهی خام و اولیه است. هر کسی با نگاه کردن به آن می‌تواند تشخیص دهد که ناتمام است. آن‌ها می‌توانند فضاهای باز را ببینند که کمک‌هایشان در آنجا قرار خواهد گرفت. کاری که خیلی ریزبینانه و زودتر از موعد باشد، همه را به جزئیات اشتباه متعهد می‌کند. طراحان و برنامه‌نویسان به فضای کافی نیاز دارند تا قضاوت و تخصص خود را هنگام شروع کار و کشف تمام مبادلات واقعی که پدیدار می‌شوند، به کار گیرند.ویژگی ۲: حل شده استبا وجود خام و ناتمام بودن، کار شکل‌یافته به طور کامل مورد تفکر قرار گرفته است. تمام عناصر اصلی راه‌حل در سطح کلان وجود دارند و به یکدیگر متصل می‌شوند. کار تا سطح وظایف فردی مشخص نشده است، اما راه‌حل کلی به طور کامل توضیح داده شده است. در حالی که ممکن است همچنان غافلگیری‌هایی رخ دهد و مشکلات پنهانی (icebergs) ظاهر شوند، جهت‌گیری واضحی وجود دارد که نشان می‌دهد چه کاری باید انجام شود. هر گونه سوال باز یا مسیرهای فرعی (rabbit holes) که از ابتدا قابل پیش‌بینی بودند، حذف شده‌اند تا خطر پروژه کاهش یابد.ویژگی ۳: محدود شده استدر نهایت، کار شکل‌یافته نشان می‌دهد که چه کاری نباید انجام شود. به تیم می‌گوید کجا متوقف شود. یک اشتها یا سقف زمانی مشخص (appetite) وجود دارد – میزان زمانی که تیم مجاز به صرف آن روی پروژه است. تکمیل پروژه در این مدت زمان ثابت، نیازمند محدود کردن دامنه (scope) و حذف موارد خاص است.در مجموع، خام بودن کار، فضایی برای تیم باقی می‌گذارد تا تمام جزئیات را حل و فصل کند، در حالی که راه‌حل و مرزها مانند نرده‌های محافظ عمل می‌کنند. آن‌ها خطر را کاهش می‌دهند و تلاش‌های تیم را هدایت می‌کنند، و اطمینان می‌دهند که آن‌ها بیش از حد نمی‌سازند، سرگردان نمی‌شوند یا گیر نمی‌کنند.چه کسی شکل‌دهی می‌کند؟شکل‌دهی کاری خلاقانه و یکپارچه‌ساز است. این کار نیازمند ترکیب ایده‌های رابط کاربری با امکانات فنی و اولویت‌های کسب‌وکار است. برای انجام این کار، باید خودتان این مهارت‌ها را به عنوان یک متخصص همه‌کاره داشته باشید یا با یک یا دو نفر دیگر همکاری کنید.شکل‌دهی در درجه اول کار طراحی است. مفهوم شکل‌یافته، یک طراحی تعاملی (interaction design) است که از دیدگاه کاربر دیده می‌شود. این کار مشخص می‌کند که ویژگی چه کاری انجام می‌دهد، چگونه کار می‌کند و کجا در جریان‌های موجود قرار می‌گیرد.برای شکل‌دهی نیازی نیست برنامه‌نویس باشید، اما باید سواد فنی داشته باشید. باید بتوانید قضاوت کنید چه چیزی ممکن است، چه چیزی آسان است و چه چیزی سخت. دانش در مورد نحوه عملکرد سیستم به شما کمک می‌کند فرصت‌ها یا موانع پیاده‌سازی ایده خود را ببینید.این کار همچنین کاری استراتژیک است. تعیین سقف زمانی و ارائه یک راه‌حل مستلزم این است که در مورد مشکل منتقدانه فکر کنید. چه مشکلی را می‌خواهیم حل کنیم؟ چرا اهمیت دارد؟ چه چیزی موفقیت محسوب می‌شود؟ کدام مشتریان تحت تأثیر قرار می‌گیرند؟ هزینه انجام این کار به جای کار دیگر چقدر است؟شکل‌دهی یک فرآیند خلاقانه و پشت درهای بسته است. ممکن است تنها باشید و روی کاغذ طرح بزنید یا در کنار یک همکار صمیمی جلوی وایت‌بورد باشید. نمودارهای اولیه و نامفهوم در مقابل شما خواهند بود که هیچ‌کس خارج از اتاق قادر به تفسیر آن‌ها نخواهد بود. هنگام کار با یک همکار، سریع حرکت می‌کنید، رک و راست صحبت می‌کنید و از یک موقعیت امیدوارکننده به دیگری می‌پرید. این نوع کار خصوصی، اولیه و خام است.دو مسیرنمی‌توان کار شکل‌دهی را واقعاً زمان‌بندی کرد، زیرا ذاتاً کار شکل‌نگرفته پرخطر و ناشناخته است. به همین دلیل ما دو مسیر جداگانه داریم: یکی برای شکل‌دهی و دیگری برای ساخت. در هر چرخه شش هفته‌ای، تیم‌ها کاری را می‌سازند که قبلاً شکل گرفته است و شکل‌دهندگان روی کارهایی کار می‌کنند که تیم‌ها احتمالاً در چرخه‌های آینده خواهند ساخت. کار در مسیر شکل‌دهی خصوصی نگه داشته می‌شود و با تیم گسترده‌تر به اشتراک گذاشته نمی‌شود مگر اینکه تعهد به سرمایه‌گذاری (bet) روی آن انجام شده باشد. این امر به شکل‌دهندگان این امکان را می‌دهد که کار در حال انجام را کنار بگذارند یا زمانی که نتیجه نمی‌دهد، آن را رها کنند.مراحل شکل‌دهیشکل‌دهی چهار مرحله اصلی دارد که در چهار فصل بعدی به آن‌ها خواهیم پرداخت.• تعیین مرزها. ابتدا مشخص می‌کنیم که ایده خام چقدر زمان می‌ارزد و چگونه مشکل را تعریف کنیم. این کار مرزهای اساسی را برای شکل‌دهی به ما می‌دهد.• عناصر را به صورت اولیه طرح‌ریزی کنید. سپس کار خلاقانه طرح‌ریزی یک راه‌حل می‌آید. این کار را در سطح انتزاعی بالاتری نسبت به وایرفریم‌ها انجام می‌دهیم تا سریع حرکت کنیم و طیف وسیعی از امکانات را بررسی کنیم. خروجی این مرحله، ایده‌ای است که مشکل را در محدوده سقف زمانی (appetite) حل می‌کند، اما بدون تمام جزئیات دقیق.• خطرات و مسیرهای فرعی را بررسی کنید. هنگامی که فکر کردیم راه‌حلی داریم، با دقت آن را بررسی می‌کنیم تا حفره‌ها یا سوالات بی‌پاسخی را پیدا کنیم که می‌توانند تیم را به مشکل بیندازند. راه‌حل را اصلاح می‌کنیم، چیزهایی را از آن حذف می‌کنیم، یا جزئیات را در نقاط دشوار خاص مشخص می‌کنیم تا از گیر افتادن یا اتلاف وقت تیم جلوگیری کنیم.• پیشنهاد (Pitch) را بنویسید. هنگامی که فکر کردیم آن را به اندازه کافی برای احتمال سرمایه‌گذاری شکل داده‌ایم، آن را با یک نوشته رسمی به نام پیشنهاد (pitch) بسته‌بندی می‌کنیم. این پیشنهاد مشکل، محدودیت‌ها، راه‌حل، مسیرهای فرعی و محدودیت‌ها را خلاصه می‌کند. پیشنهاد برای بررسی به میز سرمایه‌گذاری (betting table) می‌رود. اگر پروژه انتخاب شود، پیشنهاد می‌تواند در شروع پروژه (kick-off) برای توضیح پروژه به تیم مجدداً استفاده شود.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:43:07 +0330 https://virgool.io/@alikarimi/%D9%85%D9%82%D8%AF%D9%85%D9%87-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-pzbbsv0s6wrv این کتاب راهنمایی است در مورد اینکه ما چگونه در بیس‌کمپ توسعه محصول را انجام می‌دهیم. همچنین یک جعبه ابزار پر از تکنیک‌هاست که شما می‌توانید آن‌ها را به روش خودتان در فرآیندهای خودتان به کار ببرید.خواه شما یک بنیان‌گذار، مدیر ارشد فناوری (CTO)، مدیر محصول، طراح یا توسعه‌دهنده باشید، احتمالاً به خاطر چالش‌های رایجی که همه شرکت‌های نرم‌افزاری با آن‌ها روبرو هستند، اینجا هستید.دردسرهای رشدبا شروع رشد تیم‌های نرم‌افزاری، برخی مشکلات رایج پدیدار می‌شوند:• اعضای تیم احساس می‌کنند پروژه‌ها بی‌وقفه ادامه می‌یابند و پایانی برایشان متصور نیست.• مدیران محصول نمی‌توانند زمانی برای تفکر استراتژیک در مورد محصول پیدا کنند.• بنیان‌گذاران از خود می‌پرسند: "چرا نمی‌توانیم ویژگی‌ها را مانند دوران اولیه به سرعت عرضه کنیم؟"ما این چالش‌ها را در بیس‌کمپ از نزدیک تجربه کردیم، وقتی که از چهار نفر به بیش از پنجاه نفر رسیدیم.بیس‌کمپ در سال ۲۰۰۳ به عنوان ابزاری که برای خودمان ساختیم، شروع به کار کرد. در آن زمان ما یک شرکت مشاوره‌ای بودیم که وب‌سایت‌هایی را برای مشتریان طراحی می‌کردیم. اطلاعات در بازی "تلفن خراب" بین مشتری، طراح و فرد مدیریت‌کننده پروژه گم می‌شد. ما می‌خواستیم بیس‌کمپ یک مکان متمرکز باشد که همه طرف‌ها بتوانند کار را ببینند، در مورد آن بحث کنند و بدانند گام بعدی چیست. معلوم شد که شرکت‌های زیادی مشکل "از دست رفتن اطلاعات در شکاف‌ها" را داشتند. امروزه میلیون‌ها نفر در انواع صنایع به بیس‌کمپ به عنوان منبع واحد و معتبر اطلاعات خود اعتماد می‌کنند.اولین نسخه را سه نفر از ما ساختیم. جیسون فرید، بنیان‌گذار بیس‌کمپ، رهبری طراحی را بر عهده داشت. دیوید هاینمایر هانسون، هم‌بنیان‌گذار او، آن را برنامه‌نویسی کرد (و چارچوب وب مشهور روبی آن ریلز را به عنوان محصول جانبی ایجاد کرد). در آن زمان من یک طراح وب با تمرکز بر قابلیت استفاده و رابط‌های کاربری بودم. من مسیر طراحی جیسون را برای ویژگی‌های کلیدی اپلیکیشن اجرا می‌کردم و با او برای تکمیل جزئیات مفهوم همکاری می‌کردم.از اولین نمونه‌های اولیه در جولای ۲۰۰۳ تا راه‌اندازی در فوریه ۲۰۰۴، دیوید فقط ده ساعت در هفته کار می‌کرد. ما می‌دانستیم که با آن ده ساعت برنامه‌نویسی به جایی نمی‌رسیم، مگر اینکه از آن‌ها بسیار آگاهانه استفاده کنیم. تمرکز شدید ما بر "فشردن" محدوده پروژه برای جای گرفتن در یک بودجه زمانی مشخص، تحت این محدودیت‌ها متولد شد.با رشد کسب‌وکار، من شروع به گسترش مهارت‌هایم کردم. کار با دیوید و روبی آن ریلز دنیای برنامه‌نویسی را برایم قابل دسترس کرد. من تکنیک‌هایی را که برنامه‌نویسان برای مهار پیچیدگی استفاده می‌کنند، آموختم: چیزهایی مانند فاکتورگیری، سطوح انتزاع، و جداسازی دغدغه‌ها. با یک پا در دنیای طراحی و یک پا در دنیای برنامه‌نویسی، از خودم پرسیدم که آیا می‌توانیم این اصول توسعه نرم‌افزار را در نحوه طراحی و مدیریت محصول به کار ببریم.اولین آزمایش این ایده در سال ۲۰۰۹ اتفاق افتاد. تا آن زمان ما چند برنامه‌نویس دیگر را استخدام کرده بودیم و چهار محصول جداگانه نرم‌افزار به عنوان سرویس (SaaS) را ارائه می‌دادیم. ما می‌خواستیم محصولات را در یک مجموعه یکپارچه با ورود تک‌صلاحیتی (single-sign-on) و صورتحساب یکپارچه دسته‌بندی کنیم. این یک کار فنی عظیم با جریان‌های کاربری (user-facing flows) پرمخاطره بود. علاوه بر درست کردن معماری زیربنایی، ما باید مشتریان را هنگام ورود به محصول متوقف می‌کردیم و آن‌ها را مجبور می‌کردیم نام کاربری و رمز عبور خود را به دلایلی که توضیح آن‌ها آسان نبود، تغییر دهند. من در این پروژه کلاه‌های طراح و مدیر محصول را بر سر داشتم و تکنیک‌های بریدبوردینگ و نقشه‌برداری محدوده (scope mapping) که در این کتاب توضیح داده شده‌اند را برای مدیریت پیچیدگی نمونه‌سازی کردم.ما نتایج بسیار خوبی به دست آوردیم، به طوری که تصمیم گرفتیم همین تکنیک‌ها را دوباره در سال ۲۰۱۲ به کار بگیریم، زمانی که بیس‌کمپ را برای نسخه ۲.۰ از نو طراحی کردیم. باز هم سطح گسترده‌ای برای مدیریت وجود داشت و باز هم فرآیند به طرز شگفت‌آوری روان بود.تا سال ۲۰۱۵، ما یک تیم اصلی داشتیم که این تجربه‌ها را پشت سر گذاشته بود و به گام‌های چشمگیری دست یافته بود. اما توضیح آنچه انجام می‌دادیم به استخدام‌های جدید دشوار بود. تیم محصول ما چهار برابر شده بود و همه از راه دور کار می‌کردند. این امر انتقال بینش‌های ما را دشوار می‌کرد. ما به زبانی برای توصیف آنچه انجام می‌دادیم و ساختار بیشتری برای ادامه کار در مقیاس جدیدمان نیاز داشتیم.برای مدیریت این ظرفیت جدید، ما از طول پروژه‌های موقت (ad-hoc) به چرخه‌های تکراری تغییر دادیم. (مدتی آزمایش طول کشید تا طول چرخه مناسب را پیدا کنیم: شش هفته. در ادامه بیشتر در این مورد صحبت خواهیم کرد.) ما فرآیندهای ارائه پروژه (pitching) و شرط‌بندی (betting) خود را رسمی کردیم. نقش من دوباره تغییر کرد، از طراحی و مدیریت محصول به استراتژی محصول. من به زبان جدیدی نیاز داشتم، مانند کلمه "شکل‌دهی" (shaping)، برای توصیف کار طراحی اولیه که برای تعیین مرزها و کاهش ریسک پروژه‌ها قبل از سپردن آن‌ها به تیم‌ها انجام می‌دادیم.درست زمانی که ما در توضیح شیوه کارمان به خودمان بهتر می‌شدیم، بیشتر و بیشتر دوستان و همکارانمان شروع به پرسیدن نحوه کارمان از ما کردند. سرانجام جیسون یک روز مرا کنار کشید و گفت: "فکر می‌کنم باید در مورد این یک کتاب بنویسی".این نتیجه است. شما می‌توانید این را به عنوان دو کتاب در یک کتاب در نظر بگیرید. اولاً، این یک کتاب از حقایق اساسی است. من می‌خواهم که آن به شما زبان بهتری بدهد تا ریسک‌ها، عدم قطعیت‌ها و چالش‌هایی که هر زمان که توسعه محصول انجام می‌دهید، پیش می‌آیند را توصیف و با آن‌ها مقابله کنید. ثانیاً، این کتاب فرآیندهای خاصی را که ما برای دستیابی به پیشرفت معنادار در محصولاتمان در مقیاس فعلی‌مان استفاده می‌کنیم، تشریح می‌کند.در اینجا یک مرور کوتاه از ایده‌های اصلی کتاب آورده شده است.چرخه‌های شش هفته‌ایاول، ما در چرخه‌های شش هفته‌ای کار می‌کنیم. شش هفته به اندازه کافی طولانی است تا چیزی معنادار را از ابتدا تا انتها بسازیم و به اندازه کافی کوتاه است که همه از همان ابتدا حس کنند ضرب‌الاجل نزدیک است، بنابراین از زمان به صورت هوشمندانه استفاده می‌کنند. اکثر قابلیت‌های جدید ما در یک چرخه شش هفته‌ای ساخته و منتشر می‌شوند.تصمیمات ما بر اساس پیشبرد محصول در شش هفته آینده است، نه مدیریت خرد زمان. ما ساعت‌ها را نمی‌شماریم یا اینکه روزهای هر فرد چگونه سپری می‌شود را زیر سوال نمی‌بریم. ما جلسات روزانه نداریم. ما نقشه راهمان را هر دو هفته یک بار دوباره بررسی نمی‌کنیم. تمرکز ما در سطح بالاتری است. ما به خودمان می‌گوییم: "اگر این پروژه بعد از شش هفته عرضه شود، ما واقعاً خوشحال خواهیم شد. احساس خواهیم کرد زمانمان به خوبی صرف شده است." سپس شش هفته را متعهد می‌شویم و تیم را به حال خود رها می‌کنیم تا کار را انجام دهد.شکل‌دهی کاردوم، ما کار را قبل از دادن آن به یک تیم، شکل می‌دهیم. یک گروه کوچک از افراد ارشد به موازات تیم‌های چرخه کار می‌کنند. آن‌ها عناصر کلیدی یک راه حل را قبل از اینکه پروژه‌ای را آماده "شرط‌بندی" (تعهد) در نظر بگیریم، تعریف می‌کنند. پروژه‌ها در سطح انتزاعی مناسبی تعریف می‌شوند: به اندازه کافی مشخص که تیم‌ها بدانند چه کاری باید انجام دهند، اما به اندازه کافی انتزاعی که فضا برای کار بر روی جزئیات جالب خودشان داشته باشند.هنگام شکل‌دهی، ما کمتر روی تخمین‌ها تمرکز می‌کنیم و بیشتر روی "اشتهای" خودمان. به جای پرسیدن اینکه انجام کاری چقدر زمان می‌برد، می‌پرسیم: چقدر زمان می‌خواهیم صرف کنیم؟ این ایده چقدر ارزش دارد؟ این وظیفه شکل‌دهی است: محدود کردن مشکل و طراحی طرح کلی یک راه حل که در محدودیت‌های "اشتهای" ما جای می‌گیرد.مسئولیت دادن به تیم‌هاسوم، ما مسئولیت کامل را به یک تیم کوچک و یکپارچه از طراحان و برنامه‌نویسان می‌دهیم. آن‌ها وظایف خود را تعریف می‌کنند، تغییراتی در محدوده ایجاد می‌کنند، و با هم کار می‌کنند تا برش‌های عمودی از محصول را یکی یکی بسازند. این کاملاً متفاوت از روش‌شناسی‌های دیگر است، جایی که مدیران کار را قطعه قطعه می‌کنند و برنامه‌نویسان مانند بلیط‌گیرندگان عمل می‌کنند.این مفاهیم با هم، یک چرخه مثبت را تشکیل می‌دهند. هنگامی که تیم‌ها مستقل‌تر هستند، افراد ارشد می‌توانند زمان کمتری را صرف مدیریت آن‌ها کنند. با صرف زمان کمتر در مدیریت، افراد ارشد می‌توانند پروژه‌های بهتری را شکل دهند. وقتی پروژه‌ها بهتر شکل گرفته‌اند، تیم‌ها مرزهای واضح‌تری دارند و بنابراین می‌توانند مستقل‌تر کار کنند.هدف‌گیری ریسکدر هر مرحله از فرآیند، ما یک ریسک خاص را هدف قرار می‌دهیم: ریسک عدم عرضه به موقع. این کتاب در مورد ریسک ساختن چیز اشتباه نیست. کتاب‌های دیگری می‌توانند در این زمینه به شما کمک کنند (ما کتاب رقابت با شانس را توصیه می‌کنیم). بهبود فرآیند کشف شما باید پس از بازیابی توانایی شما برای عرضه محصول انجام شود. شما می‌توانید بهترین استراتژی دنیا را داشته باشید، اما اگر نتوانید بر اساس آن عمل کنید، چه فایده‌ای دارد؟این کتاب در مورد ریسک گیر افتادن، ریسک گرفتار شدن در کارهای سه ماهه گذشته، هدر دادن زمان بر روی مشکلات غیرمنتظره، و آزاد نبودن برای انجام آنچه می‌خواهید فردا انجام دهید است.ما ریسک را در فرآیند شکل‌دهی با حل سوالات باز قبل از اینکه پروژه را به یک جعبه زمانی متعهد کنیم، کاهش می‌دهیم. ما پروژه‌ای را به تیمی نمی‌دهیم که هنوز مسائل بی‌نتیجه (rabbit holes) یا وابستگی‌های درهم‌پیچیده (tangled interdependencies) دارد.ما ریسک را در فرآیند برنامه‌ریزی با محدود کردن "شرط‌های" (bet) خود به شش هفته کاهش می‌دهیم. اگر پروژه‌ای طولانی‌تر شود، به طور پیش‌فرض تمدید نمی‌شود. این "قطع‌کننده مدار" (circuit breaker) تضمین می‌کند که ما چندین برابر "اشتهای" اولیه را روی مفهومی که ابتدا نیاز به بازنگری دارد، سرمایه‌گذاری نمی‌کنیم.و در نهایت، ما ریسک را در فرآیند ساخت با ادغام زودهنگام طراحی و برنامه‌نویسی کاهش می‌دهیم. به جای ساختن بسیاری از قسمت‌های جدا از هم و امید به اینکه در آخرین لحظه با هم سازگار شوند، ما یک بخش معنادار از کار را از ابتدا تا انتها زودتر می‌سازیم و سپس تکرار می‌کنیم. تیم کار را از ناشناخته‌ترین بخش‌ها تا کمترین بخش‌های نگران‌کننده توالی‌بندی می‌کند و با ادغام هر چه سریع‌تر، یاد می‌گیرد چه چیزی کار می‌کند و چه چیزی کار نمی‌کند.این کتاب چگونه سازماندهی شده استبخش اول تماماً درباره شکل‌دهی (Shaping) است — کار مقدماتی که ما روی پروژه‌ها انجام می‌دهیم، قبل از اینکه آن‌ها را آماده برنامه‌ریزی در نظر بگیریم. هر فصل یک مرحله خاص از فرآیند را توضیح می‌دهد، از تعیین "اشتها" برای یک ایده خام، تا ترسیم طرح کلی یک راه حل، تا نوشتن یک "پیچ" (معرفی) که پروژه بالقوه را ارائه می‌دهد. در طول مسیر، شما تکنیک‌های خاصی — مانند بریدبوردینگ و اسکچینگ با ماژیک ضخیم (fat-marker sketching) — را یاد خواهید گرفت تا طراحی را در سطح انتزاعی مناسبی نگه دارید.بخش دوم درباره شرط‌بندی (Betting) است — اینکه چگونه از میان پروژه‌های ارائه شده انتخاب می‌کنیم و تصمیم می‌گیریم که در هر شش هفته چه کاری انجام دهیم.بخش سوم درباره ساخت (Building) است — انتظاراتی که از تیم‌ها داریم و شیوه‌های خاصی که برای کشف آنچه باید انجام دهند استفاده می‌کنند. ما به این خواهیم پرداخت که تیم‌ها چگونه بفهمند چه کاری انجام دهند، چگونه طراحی و برنامه‌نویسی را ادغام کنند، چگونه آنچه شناخته شده و ناشناخته است را پیگیری کنند، و در نهایت چگونه تصمیمات دشوار را برای اتمام به موقع پروژه بگیرند.در نهایت، پیوست به شما کمک‌هایی را برای زمانی که می‌خواهید در شرکت خود تغییراتی ایجاد کنید، ارائه می‌دهد. در آن توصیه‌هایی در مورد نحوه امتحان اولین آزمایش شش هفته‌ای خود، نکاتی در مورد تنظیم روش‌ها با اندازه شرکت شما، و راهنمایی‌های خاصی برای نحوه پیاده‌سازی متدولوژی Shape Up با استفاده از Basecamp وجود دارد.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)شما اینجا هستید 👈 ۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:42:15 +0330 https://virgool.io/@alikarimi/%D9%85%D9%82%D8%AF%D9%85%D9%87-acknowledgements-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-ru8q5ytd0cks نحوه کار یک تیم، تأثیر فوق‌العاده‌ای بر آنچه می‌تواند انجام دهد، دارد. فرآیند، روش‌ها، شیوه‌ها، رویکرد، نظم، اعتماد، سبک ارتباطات، سرعت. نحوه کار – آن «چگونه» – اساسی و بنیادی است.اغلب می‌شنوید که مردم می‌گویند «اجرا همه چیز است»، اما این کاملاً درست نیست. در واقع، اغلب کاملاً اشتباه است.وقتی صحبت از کار پروژه، و به طور خاص توسعه نرم‌افزار، می‌شود، اجرای کاری به شیوه غلط می‌تواند روحیه را از بین ببرد، تیم‌ها را فرسوده کند، اعتماد را خدشه‌دار کند، چرخ‌دنده‌ها را خرد کند و ماشین پیشرفت بلندمدت را نابود کند. خب بله، «انجام شده»، اما به چه قیمتی؟ با انجام دادن، چه بلایی سر خودمان آورده‌ایم؟ آیا واقعاً باید این کار را بارها و بارها، ماه به ماه، سال به سال تکرار کنیم؟در چند پروژه شرکت داشته‌اید که مایل بودید دوباره از نو شروع کنید؟ چند پروژه طولانی شده‌اند، در انتها انباشته شده‌اند و افراد را خسته کرده‌اند؟ چند پروژه اساساً مجموعه‌ای از انتظارات غیرمنطقی بودند؟ چند پروژه تیم‌ها را در برابر یکدیگر قرار دادند، همه را از سازنده گرفته تا ذی‌نفع ناامید کردند، و در نهایت بهتر بود که بمیرند تا اینکه تحویل داده شوند؟گاهی اوقات اجرا همه چیز است – همه چیز اشتباه است. پس اجرای درست چگونه است؟طی چند سال گذشته، کنجکاوی زیادی در مورد نحوه کار ما در Basecamp وجود داشته است. مردم اغلب از ما می‌پرسند که چگونه با چنین تیم کوچکی، این همه کار را با سرعت و کیفیت بالا انجام می‌دهیم. و چگونه تیم‌هایمان را سال‌ها کنار هم نگه می‌داریم.اول اینکه، ما به waterfall یا agile یا scrum علاقه‌ای نداریم. دوم اینکه، ما دیوارها را با Post-it notes نمی‌پوشانیم. سوم اینکه، ما daily stand ups، design sprints، development sprints یا هر چیزی که به استعاره‌ای از خستگی و فرسودگی در انتها گره خورده باشد را انجام نمی‌دهیم. هیچ backlogی، هیچ Kanbanی، هیچ velocity trackingای، هیچ یک از این‌ها.ما رویکرد کاملاً متفاوتی داریم. رویکردی که طی نزدیک به ۱۵ سال آزمون و خطای مداوم، یادداشت‌برداری، تکرار، دقیق‌تر کردن و بهبود، در انزوا توسعه یافته است. ما راه خودمان را شکل داده‌ایم.پست‌های وبلاگ، کارگاه‌ها و گفتگوهای گاه به گاه در کنفرانس‌ها تصاویری اجمالی از فرآیند منحصر به فرد ما ارائه کرده‌اند، اما هرگز آن را برای دیدن همه، آشکار نکرده‌ایم. این کتاب دقیقاً همین کار را می‌کند.حالا که فرآیند ما کاملاً شکل گرفته، مستند شده و آماده استفاده است، ما اینجا هستیم تا آن را با همه کسانی که به اندازه کافی کنجکاو هستند تا به روشی جدید برای انجام کارها گوش دهند، به اشتراک بگذاریم. کاشفان، پیشگامان، کسانی که اهمیتی نمی‌دهند دیگران چه می‌کنند. کسانی که می‌خواهند بهتر از دیگران کار کنند.این را به عنوان یک کتاب در نظر نگیرید. آن را به عنوان یک چراغ قوه در نظر بگیرید. شما و تیمتان به اندازه کافی در تاریکی دست و پا زده‌اید. حالا چیزی روشن و قدرتمند در اختیار دارید که به شما کمک می‌کند راه جدیدی پیدا کنید.امیدواریم آن را جالب، روشنگر و مهم‌تر از همه، مفید بیابید.ممنون که خواندید.فهرست کتاب:معرفی کتاب و بلاگ پست اول۰. پیشگفتار جیسون فرایدشما اینجا هستید 👈 ۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:41:05 +0330 https://virgool.io/@alikarimi/%D9%BE%DB%8C%D8%B4%DA%AF%D9%81%D8%AA%D8%A7%D8%B1-%D8%AC%DB%8C%D8%B3%D9%88%D9%86-%D9%81%D8%B1%D8%A7%DB%8C%D8%AF-%DA%A9%D8%AA%D8%A7%D8%A8-shape-up-xg3vkvukhhnu جیسون فراید و دیوید هینمیر هانسون، بنیان‌گذاران Basecamp، بسیاری از بذرهای این کتاب را کاشته‌اند. این کتاب بر اساس ارزش‌های آن‌ها، فرهنگ Basecamp و پانزده سال آزمون و خطای مشارکتی شکل گرفته است.باب موستا و کریس اسپیک مشارکت‌های محوری داشتند. این کتاب بدون کمک آن‌ها به سرانجام نمی‌رسید.سخنرانی‌های یانیر بار-یام در New England Complex Systems Institute به من در ساختاربندی این متد کمک کرد.طراحان و برنامه‌نویسان خبره در Basecamp این تکنیک‌ها را در طول سال‌ها امتحان، آزمایش و بهبود بخشیدند تا پروژه‌های واقعی را تحویل دهند. تلاش‌های آن‌ها باعث شده که این کتاب، حاصل تجربه عملی باشد، نه صرفاً تئوری.فهرست کتاب:معرفی کتاب و بلاگ پست اولشما اینجا هستید 👈 ۰. پیشگفتار جیسون فراید۰.مقدمه (Acknowledgements)۰. مقدمه۱. اصول شکل‌دهی۲. تعیین مرزها۳. عناصر را بیابید۴. ریسک‌ها و مشکلات پیچیده (Rabbit Holes)۵. پیچ (pich) را بنویسید۶. شرط بندی، نه بک لاگ۷. میز شرطبندی۸. شرط بندی هایتان را انجام دهید۹. واگذاری مسئولیت (Hand Over Responsibility)۱۰. یک تکه را تمام کنید۱۱. نقشه‌برداری Scopeها۱۲. پیشرفت را نشان دهید۱۳. تصمیم بگیرید چه زمانی متوقف شوید۱۴.پیش برید (Move On)۱۵. نتیجه‌گیری (Conclusion) علی کریمی علی کریمی Fri, 08 Aug 2025 17:39:47 +0330 https://virgool.io/@alikarimi/problem-mapping-niixlm3rqqp5 توی رول های مختلف یک کسب و کار مثل مدیر محصول، مدیر کسب و کار یا مدیر یک تیم، معمولا زیاد پیش میاد که آدم ها به یک مشکل بر بخورن و قصد پیدا کردن راه حل براش رو داشته باشند. اما این خطا خیلی رایج هست که گاهی اوقات، برای یک مشکل، دلایل اشتباه پیدا می کنیم و به همون خاطر سراغ راه حل های اشتباهی هم میریم. یا حداقل اگه دلایل رو هم درست پیدا کنیم، ممکنه نتونیم درست اولویت بندی کنیم. اولویت بندی نکردن درست یا پیدا نکردن درست راه حل همانا و هدر رفتن فرصت و منابع همانا. سلام! این مطلب ترجمه ای از یک مقاله هست تحت عنوان: Why Is Problem Mapping So Powerful? .به نظرم این مقاله خیلی مختصر و مفید اومده یک نگاه نسبتا کلی داشته به این موضوع که چطوری می تونیم یک مشکل رو دقیق تر تشخیص بدیم و در نهایت نقشه راه بهتر و اصولی تری برای حل کردنش داشته باشیم. Problem Mapping یک تکنیک هست برای اینکه بتونیم مسائل پیچیده رو تحلیل کنیم. اصلی ترین کاری که توی این تکنیک انجام میدیم، تقسیم مسئله به اجزای کوچک تر و شناسایی ارتباط بین این اجزا و بصری سازی و در نهایت انتخاب اولویت بندی اجزا برای شروع حل مسئله هست. همونطور که یک معمار بدون داشتن نقشه، شروع به کار نمیکنه، یک مدیر محصول هم نباید بدون داشتن یک نقشه و دید درست نسبت به اتفاقی که داره توی اون مشکل رخ میده، شروع به انجام یکسری کار بکنه. پرابلم مپینگ کمک می کنه تا چالش های غیر منتظره رو شناسایی کنید، روابط علّی که شاید در نگاه اول پیدا نباشه رو براتون پررنگ تر می کنه. به شما کمک میکنه تا مسیر شفاف تری برای توسعه محصول داشته باشید و از بروز مشکلات احتمالی جلوگیری میکنه که همه و همه باعث میشه شانس موفقیت محصول شما بالاتر بره. “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” — Albert Einsteinدر اصل ما توی Problem Mapping داریم با این دیدگاه جلو میریم. مثال فرضی: BeatStreamفرض کنید BeatStream که یک پلتفرم پخش موسیقی هست، متوجه میشه که متریک تعامل کاربران در چند وقت اخیر، کاهش قابل توجهی داشته. میشه دوتا رویکرد برای حل این مسئله داشت. اولی اینکه خیلی فوری بریم سراغ دلیل و بگیم بروزرسانی های اخیر یا تغییرات در الگوریتم باعث شده این اتفاق رخ بده که معمولا نرخ خطای این مدل علت یابی ها بالاست، یا اینکه از روش Problem Mapping استفاده کنیم. بررسی دلیل کاهش قابل توجه تعامل کاربران از نگاه محصولی، مستلزم یک تحلیل دقیق هست. نظرشخصی: شاید اینطور به نظر برسه که این رویکرد در نقطه مقابل رویکرد اجایل هست. شاید تا حدودی درست باشه و بشه با Shape کردنش مانع کند شدن فرایند کل توسعه شد. اما این موضوع غیر قابل انکاره که اگه صورت مسئله رو به درستی ندیده باشیم هم عملا رویکرد اجایلمون بدرد نمیخوره.اگه بخواهیم از مسیر Problem Mapping بریم، احتمالا به این صورت میشه: مشکلات فنی اپلیکیشن: ممکن هست که کاربرها بعد از بروزرسانی فنی با مشکل مواجه شده باشند. تغییرات الگوریتم: ممکن هست که تغییرات اخیر الگوریتم، با ترجیحات کاربر ها همخوانی نداشته باشه.رابط کاربری غیرموثر: تغییرات در رابطه کاربر باعث شده که اپلیکیشن برای کاربر گیج کننده شده باشه و کاربر رو دلسرد کرده باشه.رقبا: ممکن هست که رقبا فیچرهای بهتری رو اخیرا ارائه داده باشند که همین موضوع باعث شده باشه که کاربرهای ما ترجیح به استفاده از اپلیکیشن رقبا رو داشته باشند. هرکدوم از این زیر مسائل می تونه تبدیل به یک قطه از پازل بشه که با در کنار هم قرار گرفتن به ما درک جامع تری از مسئله موجود ارائه بده“Are you solving the right problems? If you’re not working on the right problems, it doesn’t matter how well you solve them.” — Thomas Wedell-Wedellsborg, the author of ‘What’s Your Problem?’با انجام این کار، حالا دید شفاف تری نسبت به دلیل و یا دلایلی که سبب کاهش تعامل کاربرها شده پیدا می کنیم و ضمنا این امکان رو به ما میده تا بتونیم یک رویکرد جامع تری رو نسبت به حل مسئله داشته باشیم. Problem Mapping در مدیریت محصول نقش مدیر محصول معمولا در چند وظیفه مختلف و به طور همزمان تعریف میشه. از رسیدگی به بازخورد مشتریان گرفته و ارزیابی روندهای بازار تا مدیریت داینامیک های تیم و برنامه ریزی بهبود ویژگی ها. براساس مثال فرضی BeatStream که با کاهش تعامل کاربر روبرو هست. استفاده از نقشه برداری مسئله می تونه شناسایی مسائل کلیدی رو برای ما ساده تر بکنه. داشتن یک شمای بصری ممکنه به ما نشان بده که خرابی های اپلیکیشن، عامل اصلی نارضایتی کاربرها هست. حالا با این درک می تونیم تلاش های تیم رو معطوف به این بخش خاص کنیم و این رویکرد به ما کمک می کنه تا از مسیرهای اشتباه فاصله بگیریم و کل تمرکزمون رو بذاریم روی این مسیر و این مشکل اصلی.نقشه‌برداری مسئله محدود به حل مشکلات فوری نیست.این روش به عنوان یک سازوکار پیش بینی کننده هم می تونه عمل کننه و می تونه به ما در شناسایی چالش های احتمالی آینده و آمادگی برای مقابله با اون ها کمک بکنه. این رویکرد پیشگیرانه می تونه در زمینه هایی مثل مدیریت محصول که ما از قبل باید برای پاسخ به اتفاقات آینده آماده باشیم بسیار حیاتی باشه. مهمه که توجهه داشته باشیم که این روش پیشنهادی هست و هدف اون تسهیل یک رویکرد ساختارمند برای حل مسئله در زمینه مدیریت محصول هست. چه اتفاقی برای توییتر افتادپ.ن: این بخشی مربوط به توییتر در زمان جک دورسی و مشکلاتی زیادی که داشت میشه. در اون زمان انتقادات بسیار زیادی به توییتر بود از این بابت که این پلتفرم نمی تونه مدیریت درستی در برابر توییت های نفرت آمیز اتخاذ بکنه و همین موضوع، برای توییتر تبدیل به یک بحران اساسی شد. شاید استفاده از problem mapping می تونستد تا حد خوبی به مدیریت این مسئله و همینطور پیشبینی این مسئله کمک بکنه. اگر توییتر پیشبینی کرده بود که افزایش ناگهانی کاربرهاش می تونه این چالش های نظارتی رو براش به همراه داشته باشه، می تونست خیلی زودتر به فکر راهکارهایی مثل فیلترینگ پیشرفته محتوا و یا الگوریتم های مبتنی بر هوش مصنوعی برای مدیریت محتوای نفرت پراکنی می افتاد.در سال ۲۰۱۸، جک دورسی، مدیرعامل توییتر، اعتراف کرد که آنها برای این مسائل آمادگی نداشتند و گفت:«ما آن‌قدر بر جنبه‌ی آنی بودن سرویس متمرکز بودیم که نتوانستیم گامی لازم به عقب برداریم و پیامدهای آن را بررسی کنیم.»چطوری Problem Mapping انجام بدیم؟ برای اینکه بتونیم به خوبی پرابلم مپینگ انجام بدیم، چند مرحله سیستماتیک رو باید طی کنیم. هر مرحله به ما کمک می کنه تا درک بهتری از مسئله داشته باشیم، وضوح و جزئیات بیشتری از تصویر کلی مسئله ای که در تلاش برای حل اش هستیم به دست بیاریم. مرحله اول: شناسایی مسئلهاین مرحله، اساس نقشه مسئله شما رو تشکیل میده. در این گام هدفمون این هست که مسئله رو به طور واضح و مشخص شناسایی و تعریف کنیم. در نگاه اول به نظر میاد که این مرحله خیلی ساده باشه اما برعکس، خیلی از پروژه ها به خاطر ناتوانی توی تعریف دقیق مسئله ای که باهاش روبرو هستند شکست می خورند. در مثال فعلی یعنی BeatStream مسئله اینطور تعریف میشه: «کاهش قابل توجه تعامل کاربران پس از بروزرسانی اخیر.»مرحله دوم: طوفان فکری برای پیدا کردن زیرمسائلبعد از اینکه مسئله کلی تعریف شد، حالا باید تماغم علت های بالقوه ای که به موضوع اصلی دامن می زنند رو شناسایی کنیم. توی این مرحله تمام احتمالات و موضوعاتی که میتونه زیر مسئله مشکل اصلی باشه رو گردآوری می کنیم، حتی اگه در نگاه اول بی اهمیت به نظر برسند. در سناریو فرضی ما، زیر مسائل می تونند شامل مشکلات فنی در اپلیکیشن، تغییرات نامطلوب در الگوریتم پلی لیست و همینطور بازار رقابتی باشند. مرحله سوم: تعریف روابطحالا که زیر مسائل هم مشخص شد، وقت اون رسیده که ببینیم هر کدوم از این مسائل چطور به یکدیگر می تونند مرتبط باشند و همینطور ارتباطشون با مسئله اصلی به چه صورت هست. برای مثال، خرابی های اپلیکیشن ممکنه تجربه کاربری رو خراب بکنه که همین موضوع هم می تونه به تعامل کاربر آسیب بزنه. یا تغییرات الگوریتم ممکنه توی پیدا کردن موسیقی مورد علاقه، کاربرها رو دچار دردسر کنه که همین هم باز بر تعامل کاربرها با اپلیکیشن تاثیر گذار هست. مرحله چهارم: تجریه و تحلیل نقشه مسئله: حالا بهتره که یک قدم عقب تر بایستیم و به نقشه کلی نگاه کنیم. توی این مرحله باید الگوها رو پیدا کنیم و ببنیم کدوم مسائل حیاتی هستند و بیشترین تاثیر رو روی مشکل اصلی دارند میگذارند. در مثال BeatStream ممکنه به این نتیجه برسیم که خرابی های اپلیکیشن یک الگوی تکرارشونده هست و روی اکثر زیر مسائل داره تاثیر میگذاره. مرحله پنجم: اولویت بندی مشکلات:بعد از تحلیل حالا وقت اون رسیده که درمورد اولویت بندی ها تصمیم بگیریم. باید ببینیم کدوم یک از مشکلات نیاز به توجه فوری دارند. برای اولویت بندی کردن می تونیم به عواملی مثل میزان تاثیر حل شدن اون مسئله، قابلیت اجرایی راه حلی که براش ارائه میدیم و همینطور اهمیت استراتژيک این مسئله توجه کنیم. بر اساس این عوامل، در سناریوی BeatStream، رفع خرابی های اپلیکیشن ممکنه اولویت اول رو داشته باشه. مرحله ششم: بازبینی و بروزرسانی نقشه: این مرحله خیلی اغلب نادیده گرفته میشه. نقشه مسئله یک چیز ثابت نیست. بلکه یک سند پویاست که با یادگیری های جدید ما، کامل میشه. مثل یک رودمپ محصولی اجایل. اینکه به صورت منظم بازبینی انجام بدیم روی این نقشه، باعث میشه که این اطمینان رو داشته باشیم که درک خوبی از مسئله داریم و تصمیماتی که در رابطه با اون میگیریه، تصمیمات آگاهانه ای هست. تکنیک ها، ابزارها و تله هافرایند ایجاد کردن این نقشه، به سادگی یا پیچیدگی مسئله ای که باهاش روبرو هسید بستگی داره. می تونه خیلی ساده با یک طراحی روی تخته باشه یا یک سری یادداشت استیکی نوت روی دیوار، یا اینکه یک نقشه دیجیتال با کمک نرم افزارهای تخصصی. تکنیک هایی مثل نقشه ذهنی یا همون Mind Mappin یا Fishbone Diagram میتونه به ساختار دهی به مسئله کمک کنه. مایند مپ می تونه از مسئله اصلی شروع کنه و به زیر مسئله ها گسترش پیدا کنه. Fishbone Diagram یا Ishikawa diagram هم یک ابزار علت و معلولی هست که علل بالقوه و مشکل اصلی رو مشخص می کنه. این میون ابزارهایی مثل Miro هم هستند که داشبوردهای خوبی توی این زمینه می تونند به شما ارائه بدن. و اما تله ها:تله اول: The One-Time Activity Trap:باید در نظر داشته باشید که Problem Mapping یک فرایند یک باره نیست که انجامش بدید و بعد یک مدت هم به کل فراموش اش کنید. نقشه مسئله یک فرایند پویا هست و با پیدا کردن اطلاعات جدید و یا تغییر شرایط، این نقشه هم باید بروزرسانی بشه و تغییرات جدید داخلش منعکس بشه. تله دوم: The Lone Wolf Trap:این کار یک وظیفه فردی نیست و شما قرار نیست که به تنهایی اون رو انجام بدید. مهمه که دیدگاه های متفاوت و متنوع در ساختن این نقشه وجود داشته باشه و این مهمه که اطمینان حاصل کنید که همه ذی نفعان درگیر این موضو هستند. با اینکار شما هم کیفیت نقشه رو بهبود می بخشید و هم باعث میشید که کل تیم برای اجرای اون حمایت گر باشند و فرایند بسیار روان تر جلو بره. آینده Problem Mapping: این ابزار در حال حاضر، یک ابزار بسیار قوی هست و در آینده با پیشرفت تکنولوژی می تونه قوی تر هم بشه. هوش مصنوعی و یادگیری ماشین دارند تمام صنعت رو تحت تاثیر قرار میدند و نقشه مسئله هم از این قاعده مستثنی نیست. فرض کنید که سیستم های هوش مصنوعی بتونند پترن مشکلات رو بر اساس داده های تاریخی پیش بینی بکنند. به عنوان مثال، الگوریتم های یادگیری ماشین می تونند حجم زیادی از بازخوردهای کاربران رو جمع آوری و مرتب بکنند تا از طریق اونها الگوهای رایج مشکلات رو پیدا بکنند و با تصویر سازی داده بتونند به صورت واضح و مختصر، مشکل رو ارائه کنند. اینطوری کار مدیر محصول توی پیدا کردن مشکل اصلی، بسیار ساده تر و سریع تر میشه و میشه گفت از این طریق Problem Mapping می تونه کارآمدتر، دقیق تر و پیشبینی کننده تر از قبل بشه. با تصویر سازی داده ها، نقشه های مسئله می تونند تبدیل به داستان های داده محوری بشند که درک و تصمیم گیری درمورد مشکلات رو بهتر بکنند. این موضوع می تونه کمک بکنه تا مدیران محصول بتونند روی بخش خاصی از مشکل تمرکز بکنند و همبستگی ها رو شناسایی کنند و در لحظه تغییرات رو نظارت بکنند. در مجموع با کمک پیشرفت فناوری، ما توی دنیایی که پرجوش و خروش، نامطمئن، پیچیده و مبهم تر از قبل هست، می تونیم به Problem Mapping به چشم یک ابزار اصلی هر مدیر محصول نگاه کنیم. ابزاری که قراره بهمون کمک کنه تا در چشم اندازهای پیچیده محصول حرکت کنیم و همینطور برای چالش های پیش رو آماده تر باشیم. نتیجه گیری: Problem Mapping در اصل یکی از ابزارهای مدیر محصول هست. این ابزار فرایند تصمیم گیری رو ساده تر می کنه و ریسک ها رو پیش بینی پذیر تر می کنه و در نهایت کمک می کنه تا حل مسائل ساده تر باشه. با پیشرفت فناوری، این ابزار میتونه ارشمندتر هم بشه. لینک منبع: Why Is Problem Mapping So Powerful? علی کریمی علی کریمی Thu, 05 Dec 2024 15:08:31 +0330