این کتاب راهنمایی برای چگونگی توسعه محصول در بیس‌کمپ است. همچنین، جعبه ابزاری پر از تکنیک‌هایی است که می‌توانید به شیوه خودتان در فرآیندتان به کار بگیرید.
فرقی نمی‌کند یک بنیان‌گذار، مدیر فناوری، مدیر محصول، طراح یا توسعه‌دهنده باشید، احتمالاً به خاطر چالش‌های مشترکی که همه شرکت‌های نرم‌افزاری با آن روبرو هستند، اینجا هستید.
درد رشد
وقتی تیم‌های نرم‌افزاری شروع به رشد می‌کنند، مشکلاتی مشترک پدیدار می‌شود:
• اعضای تیم احساس می‌کنند پروژه‌ها بی‌پایان هستند و به نتیجه نمی‌رسند.
• مدیران محصول نمی‌توانند زمانی برای تفکر استراتژیک در مورد محصول پیدا کنند.
• بنیان‌گذاران از خود می‌پرسند: “چرا دیگر نمی‌توانیم امکانات جدید را مثل روزهای اول به سرعت ارائه دهیم؟”
ما این چالش‌ها را از نزدیک در بیس‌کمپ تجربه کردیم، زمانی که از یک تیم چهار نفره به بیش از پنجاه نفر رشد کردیم.
بیس‌کمپ در سال ۲۰۰۳ به عنوان ابزاری برای خودمان راه‌اندازی شد. در آن زمان، ما یک شرکت مشاوره‌ای بودیم که برای مشتریان وب‌سایت طراحی می‌کردیم. اطلاعات در جریان کار بین مشتری، طراح و مدیر پروژه گم می‌شد. ما بیس‌کمپ را به عنوان یک محل متمرکز ساختیم که همه طرفین می‌توانند کارها را ببینند، درباره آن‌ها بحث کنند و بدانند گام بعدی چیست. خیلی زود متوجه شدیم که بسیاری از شرکت‌ها هم مشکل «گم شدن اطلاعات» را دارند. امروز میلیون‌ها نفر در صنایع مختلف به بیس‌کمپ به عنوان منبع معتبر مشترک تکیه می‌کنند.
سه نفری نسخه اول بیس‌کمپ رو ساختیم. جیسون فرید، بنیان‌گذار بیس‌کمپ، طراحی کرد. هم‌بنیان‌گذارش دیوید هاینمیر هانسون برنامه‌نویسی رو انجام داد (و به عنوان یه محصول فرعی، فریم‌ورک معروف Ruby on Rails رو ساخت). اون موقع من یه طراح وب بودم که بیشتر روی قابلیت استفاده و رابط کاربری تمرکز داشتم. من طراحی جیسون رو برای ویژگی‌های کلیدی اپلیکیشن پیاده کردم و باهاش همکاری کردم تا جزئیات رو تکمیل کنیم.
از نمونه‌های اولیه در جولای ۲۰۰۳ تا زمان عرضه در فوریه ۲۰۰۴، دیوید فقط ده ساعت در هفته روی پروژه کار می‌کرد. می‌دونستیم با اون ده ساعت برنامه‌نویسی به جایی نمی‌رسیم، مگر اینکه خیلی هدفمند ازشون استفاده کنیم. تمرکز شدید ما روی قضیه‌ی “چکش زدنِ دامنه پروژه” برای اینکه کار رو برسونیم، از همین محدودیت‌ها به‌وجود اومد.
با رشد کسب‌وکار، من شروع به گسترش مهارت‌هام کردم. کار کردن با دیوید و Ruby on Rails باعث شد که دنیای برنامه‌نویسی برام قابل دسترس بشه. یاد گرفتم چطور از تکنیک‌هایی که برنامه‌نویس‌ها برای مهار پیچیدگی استفاده می‌کنن بهره ببرم؛ چیزایی مثل تجزیه، سطوح انتزاع، و تفکیک مسئولیت‌ها. با یک پا در دنیای طراحی و یک پا در دنیای برنامه‌نویسی، به این فکر افتادم که آیا می‌تونیم این اصول توسعه نرم‌افزار رو توی طراحی و مدیریت محصول هم به کار ببریم؟
اولین آزمایش این ایده در سال ۲۰۰۹ بود. تا اون موقع، چند برنامه‌نویس دیگه هم استخدام کرده بودیم و چهار محصول مختلف تحت عنوان سرویس (SaaS) داشتیم. می‌خواستیم این محصولات رو به یک مجموعه یکپارچه با ورود یک‌باره و سیستم پرداخت مشترک تبدیل کنیم. این یه پروژه فنی بزرگ و با مسیرهای کاربری پیچیده بود. علاوه بر اینکه باید معماری زیرساختمون رو درست می‌کردیم، مجبور بودیم مشتری‌ها رو وسط کار مجبور کنیم نام کاربری و رمز عبورشون رو تغییر بدن، اونم به دلایلی که خیلی راحت نمی‌شد توضیح داد. من همزمان نقش طراح و مدیر محصول رو داشتم و از تکنیک‌های نمونه‌سازی سریع و تعریف محدوده کار (که توی این کتاب توضیح داده میشه) استفاده کردم تا این پیچیدگی رو مدیریت کنم.
نتایج کار انقدر خوب بود که تصمیم گرفتیم دوباره همون تکنیک‌ها رو در سال ۲۰۱۲ به کار بگیریم، زمانی که بیس‌کمپ رو از پایه برای نسخه ۲.۰ بازطراحی کردیم. باز هم کلی بخش مختلف برای مدیریت داشتیم و باز هم روند کار به طرز عجیبی روان پیش رفت.
تا سال ۲۰۱۵، ما یه تیم اصلی داشتیم که از دل این تجربه‌ها گذشته بود و واقعاً در کارشون پیشرفت کرده بودن. اما فهمیدیم که انتقال چیزی که بهش رسیده بودیم به نیروهای جدید خیلی سخته. تیم محصول ما چهار برابر شده بود و همه از راه دور کار می‌کردن. این موضوع انتقال طرزفکرها و تجربه‌ها رو مشکل کرده بود. نیاز به یه زبانی داشتیم که بتونیم چیزایی که یاد گرفته بودیم رو توصیف کنیم و به یه ساختار بهتر برای ادامه کار توی این مقیاس جدید برسیم.
برای مدیریت این ظرفیت جدید، از پروژه‌هایی با مدت زمان نامنظم به چرخه‌های تکراری و ثابت تغییر کردیم. (یه مدت طول کشید تا طول چرخه درست رو پیدا کنیم: شش هفته. بعداً بیشتر در موردش توضیح میدم.) ما فرآیندهای پیشنهادی و شرط‌بندی خودمون رو رسمی کردیم. نقش من دوباره تغییر کرد، از طراح و مدیر محصول به استراتژیست محصول. نیاز داشتم زبان جدیدی پیدا کنم، کلمات جدیدی مثل “شکل‌دهی”، برای توصیف کارهای طراحی مقدماتی که انجام می‌دادیم تا پروژه‌ها رو قبل از اینکه به تیم‌ها بسپاریم، محدود و قابل پیش‌بینی کنیم.
درست همون موقع که داشتیم کارهایی که می‌کردیم رو برای خودمون بهتر توضیح می‌دادیم، دوستان و همکارای بیشتری می‌اومدن پیش ما تا بپرسن چطور کارها رو انجام میدیم. آخرش یه روز جیسون منو کنار کشید و گفت: فکر کنم باید یه کتاب درباره این بنویسی.
و نتیجه‌اش شد این کتاب. می‌تونی این کتاب رو مثل دو تا کتاب در یک کتاب در نظر بگیری. اولی، یه کتاب درباره واقعیت‌های پایه‌ای. می‌خوام زبون بهتری بهت بدم تا بتونی با ریسک‌ها، عدم قطعیت‌ها و چالش‌هایی که توی توسعه محصول بهشون برخورد می‌کنی کنار بیای. دوم، کتاب روندهای مشخصی رو توضیح می‌ده که ما داریم استفاده می‌کنیم تا توی مقیاس فعلی‌مون، پیشرفت معناداری توی محصولاتمون ایجاد کنیم.
این‌ها خلاصه‌ای از ایده‌های اصلی این کتاب هستند:
چرخه‌های شش هفته‌ای
اول اینکه، ما توی چرخه‌های شش هفته‌ای کار می‌کنیم. شش هفته به اندازه کافی طولانیه که بتونیم یه چیز ملموس رو از اول تا آخر بسازیم و به اندازه کافی کوتاهه که از همون اول همه حس کنن زمان داره تموم میشه و از وقتشون خوب استفاده کنن. اکثر ویژگی‌های جدیدمون توی یه چرخه شش هفته‌ای ساخته و منتشر می‌شن.
تصمیم‌های ما بر اساس جلو بردن محصول توی شش هفته بعدیه، نه میکرومدیریت زمان. ما ساعت‌های کاری رو نمی‌شماریم و کاری به اینکه هر روز اعضا چطوری گذشت نداریم. هر روز جلسه نداریم. هر دو هفته یه بار نمیایم دوباره به نقشه راه فکر کنیم. تمرکز ما در سطح بالاتریه. به خودمون می‌گیم: “اگه این پروژه بعد از شش هفته ارائه بشه، خیلی خوشحال می‌شیم و حس می‌کنیم از وقتمون به درستی استفاده کردیم.” بعد اون شش هفته رو به تیم واگذار می‌کنیم و ولشون می‌کنیم تا کارشون رو انجام بدن.
شکل‌دهی کار
دوم اینکه، ما کار رو قبل از اینکه به تیم واگذار کنیم، بهش شکل میدیم. یه گروه کوچک از افراد با تجربه همزمان با تیم‌های چرخه‌ای کار می‌کنن. اون‌ها عناصر کلیدی یک راه‌حل رو مشخص می‌کنن قبل از اینکه بگیم این پروژه آماده شرط‌بندیه. پروژه‌ها در سطح مناسب انتزاع تعریف می‌شن: به اندازه کافی مشخص که تیم‌ها بدونن چه کاری باید انجام بدن، اما به اندازه کافی انتزاعی که فضایی برای مانور روی جزئیات جالب داشته باشن.
وقتی داریم شکل‌دهی می‌کنیم، بیشتر از اینکه رو تخمین‌ها تمرکز کنیم، به اندازه شوقی که برای کار داریم اهمیت میدیم. به جای اینکه بپرسیم چقدر زمان می‌بره تا یه کاری رو انجام بدیم، از خودمون می‌پرسیم: چقدر زمان می‌خوایم صرفش کنیم؟ این ایده چقدر می‌ارزه؟ این وظیفه‌ی شکل‌دهیه: محدود کردن مساله و طراحی چارچوب یک راه‌حل که در محدودیت‌های اشتیاقمون جا بگیره.
مسئولیت دادن به تیم‌ها
سوم اینکه، ما مسئولیت کامل رو به یک تیم کوچک از طراحان و برنامه‌نویسان میدیم. اون‌ها وظایف خودشون رو تعریف می‌کنن، به محدوده کار تغییرات لازم رو میدن و با هم کار می‌کنن تا به صورت عمودی بخش‌های مختلف محصول رو یکی یکی بسازن. این کاملاً متفاوت از روش‌های دیگه‌ست، روشی که در اون مدیران کار رو تقسیم می‌کنن و برنامه‌نویسان مثل بلیط‌گیرها عمل می‌کنن.
همه‌ی این‌ها با هم، یه حلقه ارزشمند تشکیل میدن. وقتی تیم‌ها مستقل‌تر می‌شن، افراد با تجربه می‌تونن زمان کمتری رو صرف مدیریت اون‌ها کنن. با وقت کمتر روی مدیریت، افراد با تجربه می‌تونن پروژه‌های بهتری رو شکل بدن. وقتی پروژه‌ها بهتر شکل‌دهی می‌شن، تیم‌ها مرزهای روشنی دارن و بنابراین می‌تونن مستقل‌تر کار کنن.
هدف گرفتن ریسک‌ها
در هر مرحله از فرایند، ما به یه ریسک خاص توجه می‌کنیم: ریسک عدم تحویل به‌موقع. این کتاب درباره ریسک ساختن چیز اشتباه نیست. کتاب‌های دیگه‌ای می‌تونن به این موضوع بپردازن (ما کتاب Competing Against Luck رو پیشنهاد می‌کنیم). اینکه بتونیم کشفیات و راه‌حل‌های بهتری داشته باشیم مهارتیه که بعد از مهارت تحویل دادن کار مطرح میشه. شما ممکنه بهترین استراتژی رو داشته باشید، اما اگه نتونید از روی اون عمل کنید، چه فایده‌ای داره؟
این کتاب درباره ریسک گیر کردن، ریسک غرق شدن با کارهای گذشته و اتلاف وقت روی مشکلات غیرمنتظره و عدم آزادی برای انجام کارهایی که فردا می‌خواید انجام بدید، صحبت می‌کنه.
ما ریسک رو در فرایند شکل‌دهی کاهش میدیم. چطور؟ با حل سوالات باز قبل از اینکه پروژه رو زمان‌بندی کنیم. ما پروژه‌ای رو به تیم نمی‌دیم که هنوز سوالات دشواری داره یا وابستگی‌های پیچیده.
ما ریسک رو در فرایند برنامه‌ریزی با محدود کردن شرط‌های خود به شش هفته کاهش میدیم. اگه پروژه‌ای بیشتر از حدش طول بکشه، به‌طور پیش‌فرض تمدید نمی‌شه. این “مدار شکن” تضمین می‌کنه که ما چند برابر اشتیاق اولیه روی مفهومی که نیاز به بازنگری داره سرمایه‌گذاری نمی‌کنیم.
و در نهایت، ما ریسک رو در فرایند ساخت با ادغام طراحی و برنامه‌نویسی از ابتدا کاهش میدیم. به جای اینکه بخش‌های غیرمتصل زیادی بسازیم و امیدوار باشیم که در دقیقه آخر به هم بچسبند، ما از ابتدا یک بخش معنادار از کار رو به‌طور کامل می‌سازیم و سپس این روند رو تکرار می‌کنیم. تیم کار رو از شناخته‌شده‌ترین بخش‌ها به سمت کمتر شناخته‌شده‌ها ترتیب می‌ده و با “ترکیب کردن اون‌ها در اسرع وقت”، می‌فهمه که چی کار می‌کنه و چی کار نمی‌کنه.
و امّا ساختار این کتاب
قسمت اول درباره شکل‌دهی‌ست — مقدماتی که ما روی پروژه‌ها انجام میدیم قبل از اینکه اون‌ها رو زمان‌بندی کنیم. هر فصل کتاب یک مرحله خاص از این فرایند رو توضیح می‌ده، از تعیین میزان اشتیاق برای یک ایده خام گرفته تا طراحی یک راه‌حل و نوشتن یک پیشنهاد که پروژه‌ی احتمالی رو ارائه می‌ده. در طول این مسیر، شما تکنیک‌های خاصی رو یاد می‌گیرید — مثل تخته‌چوبی و طراحی با ماژیک چاق — تا طراحی رو در سطح مناسب انتزاع نگه دارید.
قسمت دوم درباره شرط‌بندی‌ست — اینکه چطور بین پروژه‌های پیشنهادی انتخاب می‌کنیم و تصمیم می‌گیریم چه کاری رو در هر شش هفته انجام بدیم.
قسمت سوم درباره ساخت هست — انتظاراتی که از تیم‌ها داریم و روش‌های خاصی که اون‌ها برای یافتن کارهایی که باید انجام بدن استفاده می‌کنن. ما به این موضوع می‌پردازیم که تیم‌ها چطور متوجه می‌شن که چه کارهایی باید انجام بدن، چطور طراحی و برنامه‌نویسی رو ادغام می‌کنن، چطور آنچه رو که می‌دونن در مقابل آنچه رو که نمی‌دونن ردیابی می‌کنن، و در نهایت چطور تصمیمات سخت رو برای اتمام به‌موقع پروژه می‌گیرن.
در نهایت، بخش ضمائم زمانی که وقت ایجاد تغییرات در شرکت‌تون می‌رسه به شما کمک می‌کنه. نکاتی درباره اینکه چطور اولین آزمایش شش‌هفته‌ای‌تون رو امتحان کنید، نکاتی برای تنظیم روش‌ها با اندازه شرکت‌تون، و راهنمایی‌های خاص برای چگونگی پیاده‌سازی شکل‌دهی با استفاده از Basecamp.
پاسخ‌ها (0 )