مقدمه مترجم
با پررنگ شدن استارتاپ ها و محصولات نرمافزاری در ایران، مسئله مدیریت محصول، مدیریت پروژه و طراحی محصول بیش از پیش اهمیت خود را نشان داد. امروزه بیشتر شرکت های نرمافزاری در ایران از رویکرد مدیریت نرم افزار چابک (agile) و اسکرام برای توسعه محصول خود استفاده میکنند. آیا اسکرام نیاز های ما را در توسعه محصول نرمافزاری به خوبی برطرف میکند؟
یکی از انتقادات اساسی به رویکرد اسکرام، مبحث طراحی محصول است. تطبیق دادن رویکرد های طراحی محصول مانند Design Thinking با اسکرام کاری سخت و تا حد زیادی ناممکن است. محصول نرمافزاری پویا است و نیاز های مشتری دائما در حال تغییر می باشند. تعریف User Story در رویکرد اسکرام به تنهایی برای توصیف دقیق User Flow کافی نیست. از طرفی در این رویکرد تا حد زیادی فرآیند طراحی محصول و فرآیند توسعه از یکدیگر جدا هستند. هماهنگی میان محصول، سازمان و تیم توسعه نیازمند هزینه زیاد از جلمه جلسات طولانی، مکرر و خسته کننده است.
ایراد دیگر رویکرد اسکرام در تیم های بزرگ تر خود را نشان میدهد. اگر سازمان شما بیش از 15 نیرو در بخش توسعه داشته باشد و بخواهید آن ها را در تیم های 5 نفری بر اساس فیچرهای مختلف گروه بندی کنید، با توجه به سایز فیچرها و سرعت متفاوت در تیم ها، هماهنگی میان اسپرینت تیم های مختلف کاری طاقت فرسا خواهد بود. ممکن است نیاز پیدا کنید، با توجه به فیچر، برای هر تیم زمان اسپرینت مجزا در نظر بگیرید، و در این صورت وابستگی میان اعضای تیم فنی که در تیم های مختلف پخش شده اند و تقسیم زمان مشترک برای کار کردن روی فیچر های مشترک ناممکن خواهد بود. از طرفی ممکن است فیچری چنان بزرگ طراحی شود که نیازمند چندین اسپرینت برای تیم بوده و تبدیل به یک چرخه طولانی و بدون خروجی شود. اسکرام آزمون خود را برای تیم های کوچک به خوبی پس داده است. ولی تطبیق آن با تیم های بزرگ کاری پر چالش است. تا کنون رویکرد ها متنوعی برای ترکیب و تطبیق متدلوژی های چابک ارائه شده اند اما هر کدام نیازمند تغییرات و شخصی سازی های زیادی هستند تا بتوانند با فرآیند های جاری یک سازمان تطبیق پیدا کنند. این شخصی سازی ها نیازمند زمان، هزینه و آزمون و خطای بسیاری هستند.
طبق گفته رایان در این کتاب زمانی که یک تیم نرم افزاری شروع به بزرگ شدن میکند، مشکلات به خصوصی پدیدار میشوند:
- اعضای تیم احساس میکنند پروژه همواره ادامه دارد و هیچوقت قرار نیست تمام شود.
- مدیر محصول نمیتواند زمانی برای تفکر استراژیک درباره محصول پیدا کند.
- مدیران از خود سوال میپرسند : چرا نمیتوانیم فیچر های جدید را مانند قبل سریع تولید و منتشر کنیم؟
کتاب پیش رو شامل رویکردی است که تیم basecamp در 17 سال گذشته برای مدیریت محصول و پروژه خود از آن استفاده کرده است. این کتاب راه حلی مناسب برای مسائلی که مطرح شد به شما ارائه خواهد داد. با مطالعه این کتاب متوجه خواهید شد چگونه محصول خود را با توجه به منابع محدود طراحی و مدیریت کنید؛ چگونه آن را به نحو احسن به تیم فنی ارائه کنید؛ چگونه ریسک هایی که منجر به تاخیر در توسعه و اشتباه در انتقال اطلاعات وجود دارد را کم کرده و در کوتاه ترین زمان ممکن با منابع محدود، محصولی قابل ارائه به مشتری را توسعه دهید.
یک دلیل به شما میدهم که عاشق این کتاب شوید :
ما بر اساس چرخههای ششهفتهای کار میکنیم. شش هفته برای ساختن یک چیز معنیدار از ابتدا تا انتها به اندازه کافی طولانی است و از طرفی برای اینکه همه از ابتدا ددلاین را احساس کنند، به اندازه کافی کوتاه است. بنابراین همه از زمان هوشمندانه استفاده میکنند. اکثر فیچرهای جدید ما در چرخه ششهفتهای ساخته و عرضه میشوند. تصمیمگیریهای ما بر اساس پیش بردن محصول در شش هفته آینده است، نه زمانهای خرد و ریز. ما ساعتها را محاسبه نمیکنیم یا از هر فرد نمیپرسیم امروز مشغول چه کاری بودی. ما جلسات روزانه نداریم. هر دو هفته در نقشهراه (roadmap) بازنگری نمیکنیم. ما روی سطح بالاتر تمرکز میکنیم. به خودمان میگوییم: «اگر این پروژه بعد از شش هفته به سرانجام برسد واقعاً خوشحال خواهیم شد؛ در این صورت میدانیم که از زمان به خوبی استفاده شده است.» پس از آن، شش هفته بعد را به تیم میسپاریم و آنها را به حال خود رها میکنیم تا کارها را انجام دهند.
این تنها گوشه ای از رویکردی است که این کتاب برای طراحی و توسعه محصول نرمافزاری به شما پیشنهاد میدهد.
من محمد تکلو هستم. فارغالتحصیل رشته روانشناسی از دانشگاه فردوسی مشهد. از ابتدا به دنیای تکنولوژی علاقه داشتم و در حوزه های مرتبط با محصولات نرمافزاری و هنر فعالیت میکردم. سابقه من را میتوانید در لینکدین من مشاهده کنید. هدف من از ترجمه این کتاب کمکی هرچند کوچک به اکوسیستم استارتاپی ایران است. به امید روزی که یونیکورن های ایرانی در سطح جهان شروع به تاختن کنند. این مقدمه را به مرور زمان کامل تر خواهم کرد. شما را به مطالعه این کتاب دعوت میکنم.
توضیح: بسیاری از کلمات مانند شیپینگ (shaping) قابل ترجمه به فارسی نبودند. زیرا معادل فارسی آن ها نمیتواند به درستی مفهوم مورد انتظار آن کلمه را به مخاطب برساند و حتی منجر به کج فهمی و برداشت نادرست از مطلب شود. از این رو در ترجمه این کتاب سعی شده است برخی از کلمات خاص به صورت فینگلیش بازگردانی شده و از معادل سازی فارسی آن خودداری شود.