بخش چهارم این کتاب (شامل فصول ۹، ۱۰ و ۱۱) در واقع «موتورخانه» اسکرام است. بسیاری از مالکان محصول (Product Owners) تصور میکنند این بخشها فقط مخصوص اسکرام مسترها یا تیم توسعه است، اما درک عمیق این مفاهیم برای مدیریت موثر محصول حیاتی است.
برداشتی از بخش چهارم کتاب “The Professional Product Owner”
به عنوان یک مالک محصول، احتمالاً بارها شنیدهاید که “اسکرام فقط یک چارچوب است”. اما آیا واقعاً میدانید این چارچوب چگونه به شما کمک میکند تا ارزش (Value) بیشتری به مشتری تحویل دهید؟ در بخش چهارم کتاب The Professional Product Owner، نویسندگان ما را به سفری در دل مکانیسمهای اسکرام میبرند. بیایید فصول ۹، ۱۰ و ۱۱ را با هم مرور کنیم و ببینیم چگونه میتوانیم از آنها در دنیای واقعی استفاده کنیم.
اولین چیزی که مکگریل و یوکام در فصل ۹ بر آن تاکید دارند، مفهوم تجربیگرایی (Empiricism) است. در مدیریت محصول سنتی، ما سعی میکردیم همه چیز را از قبل پیشبینی کنیم (مثل یک نقشه دقیق). اما در توسعه نرمافزار و محصولات پیچیده، ما با ناشناختهها سروکار داریم.
اسکرام بر پایه سه ستون اصلی بنا شده است که یک مالک محصول باید آنها را زندگی کند:
شفافیت (Transparency): همه چیز باید واضح باشد. وضعیت واقعی محصول نباید پنهان شود.
بازرسی (Inspection): بررسی مداوم اینکه آیا به سمت هدف میرویم یا خیر.
تطبیق (Adaptation): تغییر مسیر در صورت نیاز.
تصور کنید شما مالک محصول یک اپلیکیشن مسیریاب (مثل Waze) هستید.
رویکرد سنتی: نقشهای را چاپ میکنید و طبق آن حرکت میکنید. اگر جاده بسته باشد، در نقشه شما تغییری ایجاد نمیشود و شما به بنبست میخورید.
رویکرد اسکرام (تجربی): شما حرکت میکنید، شفافیت دارید (موقعیت لحظهای را میبینید)، وضعیت ترافیک را بازرسی میکنید، و اگر تصادفی رخ داده باشد، مسیر خود را تطبیق میدهید.
اسکرام به شما اجازه میدهد تا فرضیات خود را سریعتر شکست دهید و بر اساس شواهد واقعی تصمیم بگیرید، نه بر اساس حدس و گمان.
در فصل ۱۰، کتاب به ما یادآوری میکند که رویدادهای اسکرام جلسات اداری خستهکننده نیستند؛ آنها حلقههای بازخورد هستند. اگر این جلسات ارزش تولید نمیکنند، احتمالا اشتباه اجرا میشوند.
ظرفی برای تمام رویدادهای دیگر. طول ثابت اسپرینت به شما “ریتم” میدهد.
جایی که ما به عنوان مالک محصول با تیم توسعه گفتگو میکنیم. ما “چه چیزی” (What) و “چرا” (Why) را تعیین میکنیم و توسعهدهندگان “چگونه” (How) را.
شما به عنوان PO میگویید: “ما باید نرخ تبدیل سبد خرید را ۲۰٪ افزایش دهیم (Why/What).” تیم توسعه میگوید: “ما دکمه پرداخت را بازطراحی میکنیم و سرعت لود صفحه را بالا میبریم (How).”
این جلسه مخصوص توسعهدهندگان است، اما شما باید در دسترس باشید. این جلسه یک گزارش وضعیت به شما نیست! بلکه هماهنگی تیم برای رسیدن به هدف اسپرینت است.
حیاتیترین جلسه برای مالک محصول. اینجا جایی است که شما و ذینفعان (Stakeholders) محصولِ ساخته شده را بررسی میکنید. این جلسه نباید یک ارائه پاورپوینت باشد، بلکه باید کار واقعی نشان داده شود.
شما در حال ساخت یک بازی موبایل هستید. در جلسه بازبینی، سرمایهگذاران بازی را روی گوشی خود تست میکنند. آنها متوجه میشوند که کنترل بازی سخت است. این یک بازخورد ارزشمند است که بکلاگ محصول شما را برای اسپرینت بعدی تغییر میدهد.
تمرکز بر بهبود فرآیند و کیفیت. حتی اگر محصول عالی باشد، اگر تیم در حال سوختن است یا کیفیت کد پایین است، شما در بلندمدت شکست خواهید خورد.
فصل ۱۱ درباره “چیزهایی” است که ما میسازیم و مدیریت میکنیم. هر آرتیفکت (مصنوع) در اسکرام یک “تعهد” (Commitment) دارد تا شفافیت را تضمین کند.
هدف محصول (Product Goal).
بکلاگ لیست کارهای شما نیست؛ بلکه توصیفی از آینده محصول شماست. این لیست زنده است و مدام تغییر میکند.
بکلاگ مثل منوی یک رستوران است. مشتریان (ذینفعان) ممکن است چیزهایی بخواهند، اما شما (PO) تصمیم میگیرید چه چیزی در منو باشد تا رستوران سودآور و جذاب بماند.
هدف اسپرینت (Sprint Goal).
برنامهای که توسعهدهندگان برای اسپرینت جاری دارند. مالک محصول باید به تیم اعتماد کند که آنها بهترین راه را برای تبدیل آیتمها به محصول نهایی پیدا میکنند.
تعریف انجام شده (Definition of Done - DoD).
این مهمترین بخش است. اینکریمنت یعنی پلهای به سوی هدف محصول. تا زمانی که یک آیتم “Done” نشده باشد، ارزشی ندارد.
فرض کنید در حال ساخت یک وبسایت بانکی هستید. تیم میگوید “ویژگی انتقال وجه تمام شد”، اما هنوز تست امنیتی نشده است. طبق تعریف “Done” (که شامل تست امنیتی است)، این کار تمام نشده است. به عنوان PO، شما نباید کاری که “تقریباً تمام شده” است را تحویل بگیرید، زیرا این کار بدهی فنی و ریسک ایجاد میکند.
نویسندگان در این بخشها تاکید میکنند که اسکرام برای مالک محصول، ابزاری برای مدیریت ریسک و بهینهسازی ارزش است.
رویدادها به شما فرصت میدهند مسیر را اصلاح کنید.
آرتیفکتها به شما شفافیت میدهند تا بدانید دقیقاً کجا ایستادهاید.
یک مالک محصول حرفهای کسی نیست که فقط تیکتها را در جیرا (Jira) جابجا کند؛ بلکه کسی است که از مکانیسمهای اسکرام برای خلق محصولات شگفتانگیز استفاده میکند.
محمد امین ستوده
امیدوارم این خلاصه به شما کمک کرده باشد تا نگاهی دوباره به بخشهای بنیادین اسکرام بیندازید. آیا در تیم شما، آرتیفکتها و رویدادها با همین کیفیت اجرا میشوند؟ نظرات خود را با من به اشتراک بگذارید.
