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