به عنوان یه مدیر محصول شاید برای شما هم این موضوع پیش اومده باشه که یه کار مشخص رو به یکی از هم تیمیهاتون سپرده باشید ولی خروجی کار و چیزی که تحویل میگیرید با اون چیزی که مد نظرتون بوده متفاوت باشه؟! مثلا یه صفحه میخواستین که شماره موبایل کاربرا رو جمع کنید ولی نسخه که طراحی شده اصلا ریسپانسیو موبایلی هم نبوده؟! یا یکی از دولوپرها بهتون میگه این کاری که میخواستی تموم شده ولی وقتی میریم میبینیم تازه یه قسمت از کد زده شده و تا تموم شدن از نظر ما خیلی فاصله داره! اتفاق افتاده که یه کار بصورت پینگ پونگی خیلی رفت و برگشت بین شما و طراح یا دولوپر داره؟
واقعیتش خیلی از هم تیمی های ما تو ذهن ما نیستن که چی میخوایم و در بیشتر مواقع هم مشخص نکردیم که این کاری که میگیم وقتی به خروجی رسید و تموم شد یعنی چی که تموم شد ؟! تو این مطلب از سری نکاتی که به عنوان مدیر محصول باید بدانیم قصد دارم در مورد معیار پذیرش یا ملاک پذیرش صحبت کنم.
معیار پذیرش به مجموعهای از الزامات از پیش تعریف شده میگن که اونا باید پاس بشه تا یه یوز استوری (یا داستان کاربر) کامل بشه، در واقع محدوده و الزاماتی رو تعیین میکنه که باید توسط دولوپرها یا طراح محصول اجرا بشه تا بگیم به کار به پایان رسیده؛ گاهی وقتا به این تعریف انجام شدن کار رو هم میگن.
به عنوان مثال فرض کنید که من میرم پیش یه شیشهگر و میگم یه لیوان میخوام! خب من از لیوان یه درک و یه چیزی تو ذهنم دارم که برای من لیوان وقتی لیوان میشه که یه سری ویژگیهای خاصی رو داشته باشه، ولی این موارد رو به شیشهگر نمیگم. اون شیشهگر هم یه تصویری از لیوان داره و ازم نمیپرسه این لیوانی که میخوای چی هست اصلا. میره و میاد یه سری کارها با مواد شیشه میکنه و بهم میگه که لیوانی که میخواستی آماده شده! وقتی من میرم ازش تحویل بگیرم میرم مبینیم که ای بابا این با اون چیزی که فکر میکردم خیلی تفاوت داره! من یه لیوان میخواستم که حداقل ۳۰۰ سی سی مایعات بشه توش جا بشه، شکلش گرد نباشه، دسته داشته باشه، ارتفاعش ۱۵ سانت و قطرش هم ۱۰ سانت باشه، دورش نقش برجسته طرح گل داشته باشه و لبههای لیوان هم طلایی باشه.
ولی شیشه گر لیوانی که درست کرده ارتفاعش ۱۲ سانته، قطرش ۱۵ سانته، دسته نداره، روی شیشه برجسته هستش ولی هی سری لوزی برجسته شده و... هردوتای اینا هم در واقع لیوان هستش، هم لیوانی که من میخواستم اسمش لیوان هست، هم لیوانی که شیشه گر درست کرده اسمش لیوانه؛ ولی این چیزی نیست که من میخواستم. در واقع تولید محصول هم دقیقا همینه، ما میگیم یه لندینگ میخوایم بدون اینکه با هم توافق کرده باشیم و چک لیستی داشته باشیم که وقتی میگیم لندینگمون تموم شده ینی چی؛ این موضوع که وسط نباشه هی رفت و برگشت میشه کار و در بیشتر مواقع باعث نارضایتی هر دوطرف.
در واقع بصورت خیلی ساده معیار پذیرش همین چک لیستی هست که باید چک و تیک بشه که بپذیریم که ما این کار تموم شده یا نه، هرچی کامل تر بهتر. مایکروسافت اینو اینجوری تعریف میکنه: "شرایطی که یک محصول نرم افزاری برای پذیرفته شدن توسط کاربر، مشتری یا سایر ذینفعان باید رعایت کند." یا تو گوگل اینجوری تعریفش اینه "استانداردها یا الزامات از پیش تعیین شده یک محصول یا پروژه که باید برآورده شود."
تعریف گوگل از معیار پذیرش: "استانداردها یا الزامات از پیش تعیین شده یک محصول یا پروژه که باید برآورده شود."
معیارهای پذیرش باید قابل آزمایش باشند: از اونجایی که قراره این الزامات باید به دولوپرها و طراحان کمک کنه که بفهمن که کی کار تموم شده، پس باید به راحتی هم بشه اندازه گرفت یا آزمایشش کرد؛ همچنین نباید این آزمایشات جایی برای تفسیر داشته باشه. در واقع این آزمایش ها باید فقط جوابش بله / خیر یا قبول / رد باشه. به عنوان مثال یکی از معیارهای پذیرش قابل قبول و قابل آزمایش کردن برای ورود کاربر میتونه این باشه که کاربر باید بتوان با کیبورد فارسی، عربی و انگلیسی هم شماره موبایلش را وارد کند؛ ولی اگه بنویسید که کاربر بتونه موبایلش را وارد کند ممکنه با تفاسیر مختلفی مواجه بشید، کاربر با کیبورد انگیسی میتونه وارد بشه ولی با کیبورد فارسی نه.
معیارها باید واضح و مختصر باشند: قرار نیست یه معیار پذیرش به اندازه یه مقاله چند صفحهای و چند پاراگرافی طولانی باشه، معیار پذیرش خودتون رو تا حد امکان مختصر و ساده و سرراست بنویسید.(اینجوری خودتون هم راحتترید)
همه باید معیارهای پذیرش شما را درک کنند: چیزی که مینویسید بی فایده هستش اگه کسی غیر از خودتون درکش نکنه، معیار پذیرش در واقع زبان مشترکی هست بین شما و دولوپر و طراح و... پس اگه اونا متوجه موضوع نشن فایدهای نداره؛ از نوشتن کلمات اختصار و... پرهیز کنید؛ همچنین حتما مطمئن بشید که هم تیمیها اون چیزی که نوشتین رو درک میکنن.
معیارهای پذیرش باید دیدگاه کاربر را ارائه دهد: معیارهای پذیرش وسیلهای برای بررسی مشکل از دید مشتری یا کاربر هستش و سعی کنید تا حد ممکن چیزی که مینویسید رو از زبان اون بنویسید.
تقریبا هر کسی در تیم «میتواند» معیارهای پذیرش رو برای یوزر استوریها (یا داستان کاربر) بنویسه؛ البته معمولا مالک محصول یا مدیر محصول معیارهای پذیرش رو مینویسن یا اینکه کمک میکنن که یکی از اعضای تیم اینو بنویسه. ایده پشت معیارهای پذیرش اینه که اطمینان حاصل کنه که با توجه به نیازهای مشتری همه الزامات نوشته شده باشه، خب برای این کار کی بهتر از مدیرمحصول یا مالک محصول درک میکنه؟ با این حال پیشنهادم اینه که نوشتن معیارهای پذیرش رو به یه کار گروهی یا کار تیمی تبدیل کنید، که شامل افرادی از تیم تست، تیم دولوپرها و... باشه.
درگیر کردن بچههای تست و دولوپرها تو نوشتن معیار پذیرش میتونه مزیتهای زیادی داشته باشه؛ اولین مزیتش برای شما به عنوان مدیر محصول اینه که فرصتی برای برقراری ارتباط با این دوستان در مورد چشم انداز و استراتژی محصول و همراه شدن در این راستا باشه. مزیت بعدی این اینه که خیلی وقتا یه موضوع هست که از دید شما مخفی میمونه یا یه سری وابستگی وجود داره که قبلا مشخص نکردین که تو این کار تیمی اینا خودشون رو نشون میدن. و در آخر هم به شما به عنوان مدیر مصحول کمک میکنه که درک بهتری از یوزر استوریها از نگاه دولوپرها داشته باشید؛ پس هرموقع که ممکن بود معیارهای پذیرش رو باهم تعریف کنید.
خیلی از مدیران محصول و مالکان محصول معیارهای پذیرش رو قبل از جلسات برنامه ریزی اسپرینت مینویسن تا اونو تو این جلسات بیارن و درموردش با دولوپرها و طراحان بحث و تبادل نظر کنند و تکه نیاز بود با توجه به بازخوردها اونو اصلاحش کنن. البته که هیچ قانونی برای این که مشخصا بگه چه زمانی این معیارها رو بنویسید وجود نداره.
حداکثر، معیارهای پذیرش رو باید قبل از شروع دولوپ و توسعه محصول تعریف کنید؛ در غیر این صورت بسیاری از مزایای داشتن اونو از دست میدین. همچنین نوشتن معیارهای پذیرش خیلی زود هم میتونه نتیجه برعکس داشته باشه، یه سری چیزها هست که تو طول توسعه محصول و یاگیری از مشتری و کاربر بهش میرسید پس در نتیجه میتونه خیلی از جزییات از قلم بیوفته اگه خیلی زود بنویسید یا اینکه با توجه به اینکه دائما در حال اولویت بندی موارد برای انجام هستین ممکنه چیزهایی با اولیت بالاتر برسن و زمانی که برای نوشتن گذاشتین تلف بشه.
یکی از راههای متعادل کردن این عدم قطعیت اینه که فقط زمانی که تصمیم گرفتیم که یه کاری به لیست کارهای آماده برای انجام یا بک لاگ بذارید، معیارهای پذیرش رو بنویسید. به این ترتیب شما وقت صرف نوشتن معیارها و مشخصات پذیرشی که در نهایت از اولویت خارج میشه، نمیکنید.
مطمئنا هیچ راخ درست یا غلط واحدی برای نوشتن معیارهای پذیرش یک یوزر استوری وجود نداره. در نهایت شما باید قالب و روشی رو برای ایجاد معیارهای پذیرش ایجاد کنید که به طور مداوم برای تیم شما کار بکنه. اگه تو راه مدیریت محصول تازه اول راه هستین پس یه خورده آزمون و خطا کنید تا راه حل پیدا بشه (عادیه). تجربهای که من دارم از معجزه چک لیست غافل نشید، برای هر یوزر استوری یه چک لیست درست میکنید و هرچی که لازمه رو بصورت مختصر و ساده و شفاف توش بنویسید که جوابش بله / خیر یا قبول / رد باشه؛ البته این فقط یه پیشنهاد هستش و خودتون میتونید قالب خودتون رو بسازید.
در نهایت، قالب معیارهای پذیرش شما به اندازه عملی بودن اون مهمه. اگه تیم شما اونو درک کنه و بتونه از اون استفاده کنه ینی موفق شدین معیارهای پذیرش موثری درست کنید. خیلی فرقی نمیکنه که فرمت و قالب به چه شکلی باشه.
-----------------
نتیجه گیری:
معیارهای پذیرش جز مهمی از یوزر استوریها و کارها برای تیم هست که رو اون کار میکنه. به وضوح به محدوده، نتایج مورد نظر و معیارهای پذیرش و آزمایش رو برای بقیه افراد تیم تعریف میکنه و زبان مشترکی میشه بین همه تیم که بدونید چی میخواین؛ کمک میکنه که رفت و برگشتهای اضافه و پینگ پونگی شدن کارها رو کمتر کنه و در بیشتر مواقع حتی همین چارچوبی میشه که تمرکز روی موضوع و مساله بیشتر بشه. در نهایت همین فرآیند ایجاد و توافق بر روی معیارهای پذیرش نیز خودش فرصتی ارتباطی ارزشمندی برای شما و دولوپرها و سایر اعضای تیم هستش که بیشتر و بیشتر حس تیم بودن ایجاد بشه بینتون.
ممنون از توجهتون به این یادداشت، شما هم اگه تجربه مشابهی در این زمینه دارید میتونید بامن به اشتراک بذارید.
مهدی صالحزاده
