چرا تیمهای خوب نرمافزاری محصولات بد میسازند؟
یکی از پرسشهای مهم در توسعه محصولات نرمافزاری این است که چرا گاهی تیمهای فنی و نرمافزاری توانمند، محصولات ضعیف و کمارزش میسازند؟
این مسئله را میتوان هم در محصولات عمومی و هم در محصولات سازمانی مشاهده کرد؛ محصولاتی که با وجود برخورداری از تیمهای مهندسی قوی، در مقایسه با نمونههای موفق جهانی فاصله قابلتوجهی دارند.
یکی از دلایل مهم این مسئله، عبور سریع از نیازمندی به سمت راهحل است.
برای مثال، فرض کنید مدیر محصول یک سوپراپلیکیشن به تیم مهندسی میگوید: «کاربران هنگام انتقال وجه مشکل دارند؛ بهتر است قابلیتی اضافه کنیم که بتوانند برای یک فرد، انتقال وجه تکرارشونده انجام دهند.»
تیم مهندسی ممکن است بلافاصله وارد بحث راهحل شود: معماری چگونه باشد؟ چه تغییراتی در دیتابیس لازم است؟ چه APIهایی باید توسعه پیدا کنند؟ رابط کاربری چگونه طراحی شود و قابلیت چگونه تحویل داده شود؟
اما در این میان یک سؤال اساسی ممکن است نادیده گرفته شود:
مشکل واقعی کاربران دقیقاً چیست؟
ممکن است «انتقال وجه تکرارشونده» تنها یکی از راهحلهای احتمالی باشد و حتی شاید اصلاً ریشه اصلی مشکل کاربران نباشد.
بنابراین، صرفاً دریافت یک نیازمندی به این معنا نیست که مسئله را بهدرستی فهمیدهایم. قبل از اینکه به سمت طراحی و پیادهسازی راهحل حرکت کنیم، باید زمان کافی برای کشف، بررسی و فهم عمیق مسئله اختصاص دهیم.
نکته کلیدی:
با دریافت یک نیازمندی، هنوز نمیدانیم مسئله دقیق چیست. ابتدا مسئله را بفهمیم، سپس سراغ راهحل برویم.