چکیده: آیا میتوانیم به جای نیروهای گرانقیمت در تیم تست، از نیروهای ارزان یا متوسط استفاده کنیم، و نتایج بهتری بگیریم؟ آیا میتوانیم از ریاضیات برای عملیات بهتر بهره بگیریم. همه این کارها شدنیست، به شرط آنکه به ریاضی اعتماد کنیم.
دو سه شب پیش از شدت خستگی و سر رفتن حوصله، تصمیم گرفتم به جای خوابیدن، یک فیلم ببینم. شانسی، فیلمی با نام فارسی “بازی پول”(Moneyball) را انتخاب کردم. کلا نمیدانستم فیلم، چه داستانی را روایت میکند. ولی گویا فیلم خوبی بود، چون با حدود ۳۵۰۰۰۰ رای در IMDb، رتبه بالای ۷ داشت، و این یعنی با فیلم جذابی طرف بودم.
اما در ادامه ترجیح میدهم مقداری با حال و هوای این فیلم همراه شوید، تا در زمان ورود به مباحث تست، با تحلیلهای آماری غریبه نباشید. برای تشریح فیلم ترجیح دادم بخشی از متن ویکیپدیای فارسی را ارائه دهم، که البته مقداری هم مطلب به شرح مذبور اضافه کردهام که داخل “[ ]” قرار دارد:
“مانیبال یک روایت واقعی از بیلی بین(با بازی برد پیت) مدیر ناموفق یک تیم بیسبال است. بیلی بین مدیر تیم بیسبال اوکلند اتلتیک است و تیمش نتایج بسیار ضعیفی را کسب کرده است و دو تن از بهترین بازیکنان خود را به خاطر همین مشکلات از دست میدهد. به خاطر همین موضوع تیم اوکلند اتلتیک در آستانه فروپاشی قرار گرفته است. اما بیلی بین که در سن جوانی با یک اشتباه ورزش بیسبال رو انتخاب کرده است راه بازگشتی را نمیبیند و تصمیم میگیرد نهایت سعی و تلاش خود را به کار گیرد تا بتواند تیمش را از بحران نجات دهد! او با کمک فردی به نام پیتر براند[که درس خوانده رشته اقتصاد از داشنگاه ییل(Yale) آمریکاست و بیلی بین او را به عنوان آنالیزور تیم استخدام میکند،] دست به اقدام عجیبی میزند و براساس یک سری معادلههای ریاضی برخی از بازیکنان را به خدمت میگیرد تا اینکه به خاطر همین تصمیم رفته رفته تیم نتایج بهتری میگیرد و موفقیتی تاریخی را رقم میزند[این موفقیت تاریخی یعنی ۲۰ برد پیاپی که گویا در تاریخ بیسبال آمریکا سایقه نداشته است. درنهایت کار به جایی میرسد، که تیم دیگری برای استخدام بیلی بین مبلغ ۱۲٫۵۰۰٫۰۰۰ دلار را به وی پیشنهاد میدهد، اما او به دلایلی که خودش میداند، باز هم ترجیح میدهد، در اوکلند اتلتیک مربیگری کند].”
هر چند، سالها پیش هم یک مربی فوتبال ایرانی به نام مجید جلالی به دلیل استفاده از ریاضی و آمار، و نیز پیمودن مسیر قهرمانی در فوتبال برتر ایران، بسیار بر سر زبانها افتاد، که البته احتمالا او هم از چنین روشی استفاده کرده بود. اما از آنجاییکه هیچ سررشتهای در ورزش ندارم، از این موضوع میگذرم. اما آنچه که مشخص است این است که حتی در رشتههای حرفهای ورزشی هم که به نظر میرسد بیشتر تاک تیک تیمی و تکنیک فردی برای گرفتن نتیجه مطلوب حائز اهمیت است، ولی باز هم ریاضی و آمار میتواند یک راهکار خوب و نسبتا مطمئن برای Planning عملیاتی باشد.
نکته جالب فیلم “بازی پول” این بود که برخی از کهنه کاران تیم اوکلند اتلتیک مرتب به سرمربی ایراد میگرفتند، که آنالیزور تیم یعنی پیتر براند، نه یک بازیکن بیسبال، بلکه صرفا درس خوانده اقتصاد است، و با همین موضوع هجمه سنگینی علیه وی راه انداختند. تیم اوکلند اتلتیک در ابتدای مسیر که تیم در حال ستاپ شدن با آنالیزهای جدید بود و ایضا اعتماد چندانی به این روش وجود نداشت، چندین باخت پی در پی کسب کرد، آنچنانکه نومیدی تا حد زیادی بر بیلی بین غلبه کرد، اما او نومیدیها را کنار زد، و با قدرت به این مسیر ادامه داد و همه هجمهها را خنثی کرد، تا در نهایت، تیم روی یک ریل پیروزی اعجاب آور قرار گرفت، و رکوردی دست نیافتنی را ثبت کرد.
اما آن بخش از فیلم که مرا به نوشتن این مقاله تحریک کرد، این بود که:
- برای موفقیت نیازی به جذب بازیکنان بزرگ نیست، و میتوان به جای بازیکنان بزرگ و پرهزینهای که باید جور یک تیم تنبل را بکشند، یک تیم فعال و جدید با بازیکنان ارزان و سطح پایینتر تربیت کرد، که هزینهای به مراتب کمتر دارند، و البته میتوانند بهتر هم نتیجه بگیرند.
- اینکه برای نائل شدن به موفقیت، کل تیم و هر یک از بازیکنان باید قادر به کسب چه امتیازی در هر بازی یا تعداد خاصی از بازیها باشند، چه تعداد توپ پرت کنند، و چه تعداد ضربه بزنند، و در ضربات چه امتیازی کسب کنند.
به هر حال بعد از دیدن این فیلم مطمئن بودم همین موضوع را میتوان به یک تیم تست بسط داده و آنرا به سمت نتایج عالی سوق داد، تا در آخر به این مقاله رسیدم. البته میدانم که این موضوع، قطعا در Paperهای تست مطرح شده است، اما اینکه چه مقدار عملیاتی شده، موضوعیست که در مورد آن اطلاعی ندارم.
مهمترین کاری که یک تیم تست انجام میدهد، استخراج Failureها یا همان واژه عامیانه استخراج باگهاست. تقریبا تا کنون نشده که تیم تستی را ببینم که از کار خود اطمینان داشته باشند. درست است که طبق اصول هفتگانه تست نرمافزار نمیتوان تضمین کرد که پس از فرآیند تست، همه باگها مشخص شدهاند، اما این انتظار وجود دارد، که تسترها به حد مناسبی از اطمینان در رابطه با استخراج باگها برسند، و من تقریبا تا حالا چنین اطمینانی را در تسترها ندیدهام.
طبق آنچه که به عنوان دانش مدیریت تست از آن یاد میشود، عاملی که باعث میشود فرآیند تست خاتمه یابد، و بر اساس آن تسترها دست از تست کردن بکشند، فاکتوری به نام Test Exit Criteria یا همان “معیار خروج از تست” است. معمول اوقات اکثر شرکتهای داخلی به دلیل ضعف جدی در مدیریت تست، Planning مناسبی انجام نمیدهند، و پیرو آن اصلا موضوعی به نام Test Exit Criteria را نیز در واژه نامه ذهنی خود ندارند. اما با این فرض که مدیران تست ما، Test Planهای مناسبی داشته باشند، اکثر آنها Test Exit Criteria های کلیشهای را انتخاب میکنند. مثلا: زمان پایان تست، بودجه، درصد Test Coverage، تعداد باگ در واحد زمان و مواردی از این دست. غالب اواقات هم اطمینانی به این معیارهای خروج وجود ندارد، یعنی خیلی مشخص نیست که چرا برای این Exit Criteriaها چنین اعدادی در نظر گرفته شده است. معمول اوقات(و نه همیشه) این اعداد بر حسب یک تجربه ذهنی و غیرفرمولی حاصل میشوند. و تجربه ذهنی همان چیزیست که نزدیک بود تیم اوکلند را نابود کند.
اما آیا میشود یک معیار خروج نسبتا مطمئن داشته باشیم، که بتواند مثل فیلم مانیبال بعد از چند شکست یا حتی بدون شکست ما را به نتایج اعجاب آور برساند؟ به نظرم پاسخ این سوال، مثبت است.
ما به سادگی میتوانیم تعداد باگهای هر ریلیز را استخراج کنیم. منظورم از باگهای هر ریلیز، حد فاصلِ ما بینِ استارت به کار آمادهسازی یک ریلیز تا لحظه لانچ ریلیز بعدیست که همزمان با آن، ریلیز قبلی نیز بازنشسته میشود. یعنی اگر دو ریلیز A و B داشته باشیم، از لحظه استارت به کارِ تولیدِ ریلیز A تا لحظه لانچ ریلیز B که با بازنشستگی ریلیز A همراه است، ما مجبور به تولید و یا پشتیبانی از ریلیز A هستیم. تمامی باگهایی که در اینجا کشف میشوند، باگهای ریلیز A هستند.حالا این باگها یا توسط تیم تست، یا توسط مشتری، و یا توسط خود کدنویسها و یا حتی دیگر ذینفعان استخراج میشوند. به هر حال مجموع این باگها یک عددی میشود.
آبروریزترین باگها معمولا توسط مشتری استخراج میشوند، و ما هم برای مقالبه با این موضوع، باید کاری کنیم که مشتری قادر به یافتن باگ نباشد. برای این که کار تیم تست نیز سنگین نشود، فرض میکنیم که از تیم تست میخواهیم به شکلی تست کند که مشتری یک نسخه تقریبا بدون باگ را در اختیار بگیرد، و دیگر نتواند باگی بیابد تا آنرا به ما ارجاع دهد. این یعنی فقط مسئولیت استخراج باگهای گزارش شده از سمت مشتری را به عهده تیم تست میگذاریم. اما یک سوال. تیم تست از کجا بفهمد که نسخه بدون باگ است؟ او چقدر باید باگ پیدا کند؟
قطعا یک سوال برای تستر پیش میآید: “چقدر باگ بگیرم خوبه؟”. مدیرانِ تستِ تنبل که نمیخواهند به مغز خود فشار بیاورند، فورا توپ را به زمین تستر میاندازند و میگویند: “هر چی بیشتر، بهتر”. این پاسخ از سمت مدیر تست احتمالا به این معنیست: “به من گیر نده. خودم هم نمیدونم. یه کاریش بکن دیگه”.
اما این سوال “چقدر باگ بگیرم خوبه؟”، طبیعیترین و درست ترین سوالیست که یک تستر میتواند بپرسد. چرا که میخواهد معیار قابل لمسی از درستی عملکرد خود داشته باشد.
فرمولهای ریاضی پیچیدهای میتوان برای این موضوع استخراج کرد، که قطعا از فرمول اولیهای که در این مقاله میبینیم کاراتر هستند. اما در این مقاله قصد آموزش نداریم، بلکه فقط میخواهیم سر نخ را به شما بدهیم. فرض کنید تا کنون ریلیزهای زیر را ارائه کردهایم، و در هر ریلیز هم تعداد مشخصی باگ استخراج شده است. جدول مثالیِ پراکندگیِ تعدادِ باگ به صورت زیر خواهد بود:
اما آنچه که برای ما به عنوان تیم تست اهمیت دارد، این است که کار از سمت مشتری برگشت نخورد. بنابراین باید فشار باگهای ارجاعی از سمت مشتری را نیز به دوش بکشیم.
طبق جدول بالا بعد از ۸ ریلز به این آمار رسیدهایم:
این یعنی ما طی ۸ ریلیز با ۴۰۰ باگ مواجه شدهایم. که نتیجه آن یعنی۵۰ باگ به طور میانگین در هر ریلیز.
نتیجه منطقی این است که اگر ما بتوانیم با توجه به تجربه ریلزهای خود تا اینجا، از ریلیز ۹ به بعد، در هر ریلیز ۵۰ باگ استخراج کنیم، قطعا آهنگ ارجاع باگ از سمت مشتری با احتمال زیاد بعد از تعدادی ریلیز، به صفر میل خواهد کرد. بنابراین میتوانیم علاوه بر Test Exit Criteriaهای دیگر، یک مورد جدید با عنوان “استخراج ۵۰ باگ در هر ریلیز” را نیز داشته باشیم.
خب این یک فرمول میانگینگیری بسیار ساده بود. اما میتوان به این موضوع بال و پر زیادی داد، و محاسبات را دقیقتر کرد.
مثلا آهنگ تعداد باگها.
با تحلیل آهنگ باگها توسط یک متخصص آمار میتوان تعداد احتمالی باگها برای ریلیز ۹ به بعد را متوجه شد. این یعنی اگر در تیم خود یک نیروی مجرب در تحلیل آماری یا بهتر بگویم یک نیروی متخصص “تحقیق در عملیات” داشته باشید، او به سادگی میتواند انتظار آتی را برای شما محاسبه کند، و مدیر تست نیز Planning خود را بر مبنای همین تحلیل بچیند. البته ناگفته نماند که هر چه اطلاعات شما بیشتر باشد، تحلیلهای آماری، نتایج نزدیکتری با واقعیتهای آماده بروز در آینده خواهند داشت. مثلا اینجا اطلاعات ۸ ریلیز ارائه شده است، فرض کنید شما اطلاعات ۸۰ ریلیز را داشته باشید، آنگاه قطعا تحلیلهای پختهتری برای شما وجود خواهد داشت.
حتی مدیر تست میتواند، موضوع را بسیار دقیتر کند. مثلا میتواند برای هر شخص، Test Exit Criteria ویژه داشته باشد، و همین جدول را برای هر یک از تسترهای خود ایجاد کند. به این ترتیب که هر تسترِ مورد نظر، در هر ریلیز، چند باگ گرفته و نیز مشتری از بخشی که تستر مورد نظر ما مسئول آن بوده، چند باگ ارجاع داده است. به این ترتیب انتظاری که در هر ریلز از تسترهای خود دارید نیز مشخص میشود.
حتی میتوان دقیتر از این هم عمل کرد. مثلا اگر باگهای موجود در جدول را علاوه بر ریلیز، دارای Rank نمایید(آنچنانکه باگهای خطرناک بالاترین Rank را بگیرند، و باگهای کم خطر پایینترین Rank را)، آنگاه میتوانید انتظار خود از هر تستر را بر اساس تعداد باگهای استخراجی در هر Rank تنظیم نمایید. مثلا اگر سه Rank داشته باشیم، میتوانیم بگوییم فلان تستر باید حتما دو باگ Rank 1، چهار باگ Rank 2، و شش باگ Rank 3 استخراج کند.
اما در بحث نیرو!
شما فرض کنید، n نیرو برای تست دارید. یکی از آنها میتواند ۲ برابر دیگران باگ استخراج کند، اما ۴ برابر دیگران حقوق میگیرد. شما میتوانید همین نیرو را با دو نیروی دیگر که همسطح باقی نیروها هستند، جایگزین کنید، اما حداکثر به مجموع این دو نفر نصف نیروی حرفهای خود حقوق پرداخت کنید. میبینید که با این سیاست، نه تنها توان قبلی خود را در استخراج باگها حفظ کردهاید، بلکه نیمی از حقوق نیروی گرانقیمت خود را نیز صرفهجویی نمودهاید.
به هر حال به نظر میرسد روش پیش رو، در بسیاری از صنایع حتی در ورزش جواب مثبت گرفته است. پس چرا این روش در عمل، تست نرم افزار که ماهیتا پیوند عمیقی با ریاضیات دارد را متحول نکند؟!
با سلام خدمت شما استاد عزیز
در رابطه با موضوعی که مطرح فرمودید بنده منکر تاثیر ریاضی و آمار نه در ورزش حرفه ای هستم و نه مخالف آن در حوزه هایی مثل تست، بلکه مطمئنم روشی که در بالا بدان اشاره فرموده ایید در صورت تفسیر درست و در نظر گرفتن تمام جوانب مسئله می تواند مثمرثمر واقع شده همانطور که در حال حاضر استفاده از کامپیوتر، ریاضی و آمار بخش لاینفکی از باشگاهای حرفه ایی دنیا می باشد اما در عین حال نمی توان نقش بازیکنانی مثل رونالدو، مسی و … را در تیمهایشان منکر شد و حضور این بازیکنان در باشگاههای مطرح و سطح یک دنیا به معنی تنبلی بقیه اعضای تیم هم نیست و با این جمله که {برای موفقیت نیازی به جذب بازیکنان بزرگ نیست، و میتوان به جای بازیکنان بزرگ و پرهزینهای که باید جور یک تیم تنبل را بکشند، یک تیم فعال و جدید با بازیکنان ارزان و سطح پایینتر تربیت کرد…} بنده مخالف می باشم. برای توضیح شفاف تر موضوع نظر شما را جلب می کنم به چارچوب کانهوین (Cynefin) و ارتباط آن با محصولات در حال تولید و توسعه که همواره مسائل و مشکلات از نوع Simple نیستند که با best practice و کارشناس تست با تجربه پایین بتوان به نتیجه رسید و محصولاتی که چندین سال از تولید آنها می گذرد و ظاهرا به بلوغ رسیده اند در فرایند توسعه و اضافه شدن فیچرهای جدید و گاها پیچیده تر Complex نسبت به فازهای اولیه تولید محصول نیاز دارند که توسط کارشناسان تست خبره و expert آن حوزه تست شوند و کار یک چنین کارشناسی را با استخدام چندین کارشناس سطح پایین یا استفاده از تست های اتوماتیک و ابزار نمی توان انجام داد. از این رو نمی توانم بحثی که مطرح کرده ایید را بصورت عمومی بپذیرم همانطور که ورزشی مثل فوتبال هم استفاده از ریاضی و آمار و محاسبات خیلی توانسته کمک حال باشد اما این به معنی تضمین موفقیت فقط با به کاری گیری این اصول نبوده و همچنان در دنیای حرفه ای امثال مسی و رونالدو تاثیرگذاری خود را دارند و بصرف مجید جلالی داشتنها در عمل نمی توانید موفق باشید.
سلام جناب مهندس حسینی.
از اینکه مطالب را با دقت بسیار بالا مطالعه میکنید، واقعا مسرور هستم.
و اینکه این مباحث مطرح میشه هم خوشحالی بنده رو دو چندان میکنه.
همه ما، لااقل خود بنده شخص آماتوری هستم، و دوست دارم یاد بگیرم. باید دقت کنیم که ممکنه بسیار از اوقات اشتباه کنیم، و دیگران میتونن این اشتباه رو به ما گوشزد کنن، و ما رو از مشکل یک درک اشتباه آزاد کنند.
به همین دلیل از بیان این مباحث بسیار خوشحالم.
اما در مورد اول که فرمودید حضور بازیکنان بزرگ رو در موفقیت نمیشه کتمان کرد.
من سررشته ای زیادی از ورزش ندارم.
اما همین قدر میدونم که گاهی همین تیمها با همین بازیکنان بزرگ هم نمیتونن به موفقیتهای اولیه برسن. که خب شاهد مثال این مورد هم کم نیست. مثلا تیم پر ستاره ای که نمیتونه از مرحله گروهی صعود کنه و …
شاید بگیم این موضوع به مربی تیم مربوطه. من میگم بسیار خب.
اما سوال اینجاست، آیا نمیشد بدون این همه ستاره یک نتیجه درخشان گرفت؟ کما اینکه تیم اوکلند گرفت!
پاسخ به این سوال دقیقا موضوع این مقالست، که چطور با کمترین هزینه به نتیجه شگفت انگیزی برسیم.
وقتی یک موضوع در دنیا تجربه میشه، که یک نمونش میشه تیم بیسبال اوکلند، و این موضوع در حوزه های صنعتی دیگر بارها تجربه میشه، دیگه نمیشه اون رو به عنوان اتفاق در نظر گرفت. تیم اوکلند هم یک تیم ورزشی بوده، که در لیگ بیسبال آمریکا فعالیت میکرده. من خودم هیچ ارتباطی با بیسبال ندارم، اما میدونم لیگ فوتبال آمریکایی، لیگ بسکتبال، و لیگ بیسبال در آمریکا در ورزش خاص خودش چیزی هست شبیه به جام جهانی فوتبال. یعنی رقابتهای سنگین و بی رحمانه.
خب با این روش نتیجه عجیب و غریبی گرفتن. نمیتونیم این رو نپذیریم. و اتفاقا این نتیجه رو با کمترین ستاره گرفتن. دقیقا زمانی هم که مربی تیم با تحلیلهای ریاضی میخواست بازیکنان بزرگ رو جذب نکنه، یا بعضی رو کنار بگذاره، همین مخالفتها شامل حالش میشد، که چرا بازکینان بزرگ رو ندیده میگیره.
البته در مقاله هم اینطور عنوان نکردیم که همه رو بریزید کنار و دو تا آدم نابلد بیارید. خب آدمی که نابلد باشه کلا کاری نمیتونه بکنه. حالا چه آمار باشه و چه آمار نباشه. گفتیم آدمی رو بیارید که به نسبت آدمهای ستاره سطحشون مقداری پایینتر هست. موضوع رو اینطور بیان کردیم، که نیازی به ایجاد یک تیم پرستاره نیست، و شما میتونید حتی با تیم کم ستاره تر نتایج خوب یا حتی نتایج بهتری هم بگیرید.
البته همین آدمها رو هم باید دقت کرد، که باید افرادی باشن، که در اون زمینه خاصی که ما بهشون احتیاج داریم توانمند باشن یا مستعد باشن، اما به n دلیل مختلف استار محسوب نمیشن، و هزینه زیادی هم ندارن.
اما موضوع بعدی که فرمودید، بعضی موارد رو فقط افراد خاص میتونن استخراج کنند، که احتمالا این موضوع ناشی از تجربه ای هست که دارن، و در موارد بسیار کمتری ناشی از دانششون.
اگر موضوع ما یک سیستم Critical باشه(حالا چه Safety Critical، چه Mission Critical و چه Business Critical)، فرمایش شما درسته. این سیستمهای هزینه تست سنگینی دارند. در این سیستمها ما نباید بگذاریم به این راحتی باگی از دستمون در بره، ولی موضوع اینه که این سیستمها رو اصلا نباید تجربی تست کرد. بلکه باید تست رسمی و معمولا Model Based روشون اتفاق بیفته. حالا بعد از تست رسمی جهت اطمینان یک تست تجربی روشون انجام میشه، که اون هم معمولا Exploration رو پیشنهاد میکنند، که دقیقا اون هم نیازی به تجربه قبلی نداره.
اما اگر با یک سیستم Critical طرف نباشیم، اصلا لزومی نداره روی تست هزینه سنگینی رخ بده. مجددا تاکید میکنم، باید هزینه بشه، اما هزینه سنگین لزوم نداره.
ایضا تاکید میکنم، قرار نیست، همه چیز آمار و ریاضی باشه، بلکه آمار و ریاضی برای کمک به تسهیل وارد کار میشن. اما این موضوع رو قویا قبول دارم، که یک تیم کم ستاره، و شاید حتی بی ستاره(خود من هم در برابر این موضوع بی ستاره بودن مقداری مقاومت ذهنی دارم)، با استفاده از این روش میتونه از یک تیم پرستاره نتیجه بهتری بگیره. و این یعنی صرفه جویی سنگین هزینه و ایضا رسیدن به نتیجه بهتر، که البته در عمل هم جواب داده.
به هر حال موضوع اینه که این روش در یکی از بی رحمانه ترین رقبایتهای دنیا یعنی لیگ بیسبال آمریکا تست شده، و پاسخ مناسب گرفته. ایضا در حوزه های مختلف صنعتی هم همینطور.
این مساله به قدری اهمیت داره، که یک رشته از ریاضی کاربردی با عنوان تحقیق در عملیات رو منشعب کرده، که در تمام حوزه های صنعتی میتونه ورود کنه، و بهترین نتیجه ها رو با کمترین هزینه رقم بزنه.
ما هم یا باید مثل گذشته عمل کنیم، و نتایج معمولی بگیریم. و یا راهمون رو برای نتایج بهتر عوض کنیم.
در آخر پیشنهاد میکنم این فیلم رو فارق از سرگرم کننده بودن، به عنوان یک فیلم آموزنده ببینیم. خود من این فیلم رو دو بار در طول دو روز نگاه کردم.
با سپاس از پاسخ مفصل شما استاد بزرگوار، بنده هم با فرمایشات شما موافق هستم و منکر هیچ کدام از مسائل مطرح نیستم و اتفاقی هم که برای تیم اوکلند اتلیتیکس در آن مقطع تاریخی رخ داده را تا حد زیادی متاثر از طرز تفکر مربی این تیم می دانم… در حالی که در آن مقطع تاریخی بازیکن سرشناس و به اصطلاح ستاره ای در تیم نبوده اما یک مربی خاص تیم را هدایت می نموده که در واقع نقش ستاره را برای تیمش ایفا نموده است… البته کلا بنده ترجیح می دهم یک تیم خوب کاری متشکل از اعضایی مکمل و در کنار هم داشته باشیم و با کار تیمی درست به موفقیت برسیم تا با حضور تک ستاره ها که همراستا با اهداف تیم حرکت نمی کنند… بنده بخاطر حضور سالها در حوزه تست محصولات بانکی و بخصوص محصول حساس سوئیچ بانکی که کوچکترین اشتباهی می تواند ضرر و زیانهای مالی بسیار بالای میلیاردی برای مشتریان و بانکها ایجاد نماید اعتقاد دارم باید حتما برای حضور کارشناسان تست خبره و بادانش هزینه نمود و این هزینه جلوی ضرر را قبل از فاجعه خواهد گرفت… در رابطه با باشگاه اوکلند اتلیتیکس هم این را باید عرض کنم خدمت شما که این تیم بعد از تیم های نیویورک یانکیز ،سینت لوییز کاردینالز ،سومین تیم پر افتخار میجر لیگ بیسبال آمریکا بوده و ۹ عنوان قهرمانی در سال های (۱۹۱۰-۱۹۱۱-۱۹۱۳-۱۹۲۹-۱۹۳۰-۱۹۷۲-۱۹۷۳-۱۹۷۴-۱۹۸۹) را از آن خود کرده است .با این حال این تیم از سال ۲۰۱۳ تا به امروز اوضاع جالبی ندارد و به خصوص نتایج ضعیفی را در فصل پیش۲۰۱۵-۲۱۰۶ میجر لیگ بیسبال کسب کرد و با ۶۳ پیروزی از ۱۶۲ بازی خود در قعر بخش غربی آمریکن لیگ قرار دارد و این نشان می دهد که عملکرد فوق العاده و خاص این تیم در آن مقطع تاریخی وابسته به عواملی بوده (نظر شخصی بنده یک مربی خوب با افکار خاص) که در این تیم تداوم نداشته و زیرساختی روالمند برای آینده این تیم ایجاد ننموده و مقطعی بوده است… خلاصه مطلب اینکه استفاده از ریاضیات، آمار، تشکیل تیم منسجم و روالمند، استفاده از ابزار و روشهای اتوماتیک کردن همه همه لازم هستند اما برای سیستمهای حساس حضور متخصصان با دانش و خبره را منکر نخواهد شد و جایی که لازم است باید برای حضور متخصص هزینه نمود تا جلوی هزینه های نجومی و فجایع گرفته شود.
درباره موضوع مربی که فرمودید تک ستاره هست. به هر حال هر تیمی برای موفقیت نیاز به یک طرز تفکر درست داره، که این بار از مربی صادر شده.
اما بازیکنان معمولی هستند. موضوع ما هم از ابتدا داستان بازیکنان بود.
اما در مورد نتایج ضعیف بعدی. بله کاملا درسته. اما نتیجه ۲۰ برد پیاپی و قابل پیشبینی به لحاظ ریاضی، چیزی نیست که بشه، به اتفاق ربطش داد.
ایضا داستان عدم موفقیتهای بعدی میتونه دلایل زیادی داشته باشه، از جمله از بین رفتن این دیدگاه در تیمهای فنی بعدی، که سنتی فکر میکردن، یا ورود تیمهای دیگه به عرصه تحلیلهای آماری که کار تیم اوکلند رو برای رقابت با اونها سخت میکرده، یا استخدام تحلیلگران ضعیف یا هر چیز دیگه.
اما در رابطه با سیستم شما، که یک سیستم business critical محسوب میشه، قبلا تشریح کردم. سیستم شما نیازی به ستاره نداره تا کارهاش انجام بشه. بلکه نیاز به اسناد محکم آنالیزی، و دقیق به انضمام روشهای Model Based در طراحی تست داره.
که با یک آموزش عملیاتی حداکثر ۱۰۰ ساعته در رابطه با چگونگی طراحی تست و تمرین ده بیست روزه، که کاملا روشهای مدونی هستند، میشه با نیروهای معمولی بهترین جواب رو گرفت.
که از قضا خود بنده این کار رو کردم.
ما زمانی به این ستاره ها در تیم نیاز داریم، که نخوایم اصولی کار کنیم، و کار رو ببنیدم به افراد با تجربه تیم. تجربه یا Experience به دلیل ضمنی بودن یا قابل انتقال نیست، و یا به سختی منتقل میشه، اما دانش یا همون Knowledge با آموزش قابل انتقاله.
نمونه دانش همین تکنیکهای تولید Test Basis و تکنیکهای طراحی تسته.
البته نمیخوام بگم تجربه نباید باشه. خیر. اتفاقا بعضی کارها با تجربه حل میشه اما: ۱- تجربه رو نباید اصل کرد، و این باید دانش باشه که محوریت داشته باشه، که میشه اون رو آموزش داد و تمرین کرد. ۲- فقط باید برخی موارد رو به تجربه واگذار کرد، که مجبور نباشیم، با تجربه ها رو تبدیل به کاراکترهای کلیدی تیم کنیم، که این همون پاشنه آشیله.
موضوعی که شما درباره افراد خبره فرمودید، افراد با دانش نیستند، چون افراد با دانش رو میشه ترتبیت کرد، تا به اون اهداف برسن. منظور شما افراد با تجربه هست. که مشخصا بنده با محوریت دادن به این افراد در تیمها مخالفم. حتی بدون در نظر گرفتن این مقاله. چون اینجوری کل تیم آویزون این افراد با تجربه یا همون ستاره هاست که عرض کردم این پاشنه آشیل در کار تیمیه. در سیستمهای Critical که خیلی شدید مخالفم، که دلیلش رو قبلا عرض کردم.
تقریبا غالب شرکتهای ما همه چیز رو میبندن به تجربه افراد، و همینجوری کار میکنن. و دقیقا این افراد جور کل تیم رو میکشن، و معمولا هم پول به نسبت بیشتری میگیرن. این رو به جهت سابقه مشاوره ای که در پنج شش سال گذشته در حوزه تست داشتم عرض میکنم. و آخر الامر گزارشات باگ سنگینی که از سیستم عملیاتی و نه آزمایشی از سمت مشتری برای ما ارسال میشه، ثمره همین نگاهه. اغلب اوقات محصولات ما وضع خوبی ندارند، مگر اینکه سالیان طولانی از لانچ اونها گذشته باشه، و تثبیت شده باشن.
اما در آخر موضوع من اینه:
۱٫ این کار با یک تیم کم ستاره و شاید بی ستاره حتی در حوزه ورزشی هم انجام شده.
۲٫ اتفاقا در اون زمان همه میگفتن که نیاز به بازیکن ستاره داریم، اما نتیجه عجیب این تیم، بدون ستاره به دست اومد.
۳٫ زمانیکه این کار مجدانه پیگیری شده، جواب داده، و بر خلاف تصور دیگران نتیجه اعجاب آوری داشته.
۴٫ این روش در حوزه های دیگه صنعت هم اجرایی شده، و جواب گرفته.
۵٫ این روش جلوی هزینه های نجومی رو میگره. یعنی اصلا اگر قرار نبود صرفه جوبی به ارمغان بیاره، اصلا ارزش اجرا نداشت.
۶٫ احساس میکنم منطقی نیست با کاری که تجربه شده، و پاسخ مثبت گرفته مقابله کنیم. البته با احتیط ورود کردن به این کار رو میپسندم، اما اصرار بر روشهای گذشته به نظرم جالب نیست.
چقدر این بحث طولانی شد:)
از شما بابت حضور جدی در این بحث متشکرم
با سلام و احترام
تمام مطلب یک طرف پاراگراف آخر یک طرف…!
اینکه یک نیروی متبحر رو از دور زندگی خارج کنم و دو نیروی جونیور با حقوق هم سطح بیارم به نظرم بجز اینکه از مروت به دوره و باید این فرهنگ دور ریخته بشه!!!باید نیروهای خود رو همچون سرمایه بدونیم و برای ارتقا کیفیت کارشون بهشون ابزار و سرمایه مناسب بدیم.
بنده ده سال است در زمره نرم افزار افتخار خدمت دارم و با چم و خم این موضوعات کلنجار رفتم!
به این رسیدم که نیروی حرفه ای پول بیشتر بگیرد و کار را بصورت تخصصی جلو ببرد بسیار کم هزینه تر از جایگزینی آن با دو نیروی بی تجربه یا کم تجربه است.
منظور از هزینه فقط هزینه مالی نیست.
سلام.
از اینکه مطلب را با دقت و وسواس مطالعه کردید بسیار خوشحالم.
فارق از اینکه هر نیرویی چه حرفه ای و چه سطح پایینتر مشکلاتی برای خودش داره، و همینطور اینکه شیوه برخورد با این شخص باید چجور باشه، یک موضوعه، و موضوع مطروحه در این مقاله مبحث دیگری هست. ما نمیگیم با بی احترامی با نیروها برخورد بشه.
ایضا ما از واژه جونیور استفاده نکردیم. گفتیم نیرویی که میتونه نصف یک شخص حرفه ای کار کنه. این یعنی نیروی که نسبت به یک نیروی استار، سطح پایینتری داره.
البته همین آدمهای سطح پایینتر رو هم باید دقت کرد، که باید افرادی باشن، که در اون زمینه خاصی که ما بهشون احتیاج داریم توانمند باشن یا مستعد باشن، اما به n دلیل مختلف استار محسوب نمیشن، و هزینه زیادی هم ندارن.
موضوع مطروحه، داره میگه چجوری با استفاده از تحقیق در عملیات میتونیم راندمان بهتری کسب کنیم. و این مساله هم در دنیا به کرات در صنایع مختلف تجربه شده.
شاید خود من هم تمایل نداشته باشم، نیرو رو تعدیل کنم، و نیروی ارزانتر استخدام کنم، ولی تمایل یا عدم تمایل من در اصل موضوع که با این روش تجربه شده، میشه نتایج اجرایی بهتری گرفت عوض نمیشه.
من که با این قاعده طبیعتا کار نکردم ولی از یک چیز مطمئنم اینکه در ابتدای توسعه محصول تعداد باگ هایی که ریپورت میشه زیاده و در طول زمان فیکس میشن بله حتما باگ های جدید و یا از قدیم به جا مونده هم پیش میاد ولی رفته رفته سیستم به شرایط پایدار نزدیک تر خواهد شد.
بله. البته همیشه هم اینطور نیست. گاهی اوقات داستان دقیقا معکوس میشه. هر چی شما بیشتر میرید جلو و ریلیزهای بعدی رو میدید، باگها بیشتر میشه. حتی Featureهایی که در نسخ قبلی درست کار میکردند، دچار ایراد میشن. البته معمولا وقتی سیستمها دیگه وارد حالت Legacy و سن بالا میرسن، غالبا پایدار میشن. که البته معنیش باگ کمتره. نه بدون باگ بودن.
اما این موضوع دخلی به داستان این مقاله نداره.
این میون دو چیز قطعیت داره: ۱٫ کار همیشه از سمت مشتری برگشت میخوره، حالا چه زود به زود و چه دیر به دیر. ۲٫ آمار باگها قابل تحلیله و این تحلیل آهنگ قابل پیشبینی باگها رو در آینده به ما ارائه میده.
تمام داستان ما این بود، که با کمک ریاضی چه کنیم، تا باگی از سمت مشتری برگشت نخوره یا به حداقل برسه. حالا چه باگها به مرور زمان کم بشن و چه زیاد.
سلام یه مشکلی هست. اینطوری نمیشه
چون در ابتدای ریلیزها تعداد باگی که ریپورت میشه بیشتره ولی بعد از اسپرینت های مختلف این باگ ها مرتبا فیکس میشن و تعداد باگ کمتری معمولا ریپورت میشه
سلام.
اگر فرمایش شما رو درست متوجه شده باشم، با شما هم نظر هستم. اما مهم نیست که باگ به چه ترتیبی داره گزارش میشه. مهم اینه که در هر ریلیز به هر حال تعدادی باگ وجود داره.
طبعا وقتی شما نسخه A رو ریلیز میکنید، و بعد از اون نسخه B رو، دیگه با نسخه A کاری ندارید و اون بازنشسته شده. حالا احتمالا باگهایی در نسخه B گزارش میشه که متعلق به امکانات نسخه A هست، ولی در نسخه B دچار مشکل شده. و البته ممکن حالات دیگری هم پیش بیاد.
مساله ای که در اینجا اهمیت داره، آمار تعداد باگها در هر نسخه هست. حالا چه باگها مستقیما به امکاناتی مربوط بشه، که در نسخه B ارائه شده، و چه این مشکلات از نسخه A به نسخه B به ارث رسیده باشه. و چه هر حالت دیگه ای اتفاق بیفته.
به هر حال مجموع همه این مشکلات در نسخه B جمع میشه. همین موضوع برای نسخ دیگر هم به اشکال محتلف میتونه بروز کنه.
موضوعی که اهمیت داره، آمار ایرادات در هر نسخه و آهنگ بروز ایرادات هست، که هر چقدر شما بتونید آمار نسخ بیشتری رو داشته باشید، بهتر میتونید تحلیل آماری بدید.
به هر حال سیستم ما هر چه که باشه از یک سری قواعد ریاضی و توزیع آماری استفاده میکنه.
ایضا هر چقدر هم بتونید آمار باگهای هر نسخه رو با جزییات بیشتری استخراج کنید(مثل داستان Bug Ranking و مواردی شبیه به این)، تصمیمگیری بهتری خواهید داشت.
البته همه اینها نیازمند تحلیل آماری دقیق توسط یک متخصص “تحلیل آماری” یا همون متخصص “تحقیق در عملیات” هست.
وقتی چنین تحلیلی انجام بشه، خواهیم دید که یک آهنگ مشخص در بروز ایرادات وجود داره، که البته همیشه هم ثابت نیست، ولی میشه اون رو بر اساس آمار پیشبینی کرد.