ویرگول
ورودثبت نام
علی کریمی
علی کریمیعلی هستم. توی توسعه محصول فعالیت میکنم.
علی کریمی
علی کریمی
خواندن ۳ دقیقه·۴ ماه پیش

کتاب Shape Up - چطوری دور خودمون نچرخیم و بریم سراغ کارهای اصلی و با اهمیت

این کتاب چیه و به درد کیا می‌خوره؟

این کتاب یه جورایی مثل نقشه‌ی راه برای توسعه محصول توی شرکت 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)

توسعه محصولهوش مصنوعی
۰
۰
علی کریمی
علی کریمی
علی هستم. توی توسعه محصول فعالیت میکنم.
شاید از این پست‌ها خوشتان بیاید