این کتاب راهنمایی است در مورد اینکه ما چگونه در بیسکمپ توسعه محصول را انجام میدهیم. همچنین یک جعبه ابزار پر از تکنیکهاست که شما میتوانید آنها را به روش خودتان در فرآیندهای خودتان به کار ببرید.
خواه شما یک بنیانگذار، مدیر ارشد فناوری (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 وجود دارد.
شما اینجا هستید 👈 ۰. مقدمه
