قبل از شروع مطالعه این نوشته، لازم است مجدداً تاکید کنم کلیه نوشته‌های این وبلاگ در حوزه نرم‌افزار است. من در خودم توان یا صلاحیت ارائه راه حل یا اظهار نظر در حوزه‌های تولیدی دیگر را نمی‌بینم، به همین دلیل است که به تیتر هر کدام از این نوشته‌ها یک کلمه “نرم‌افزار ” به یک شکلی چسبانده می‌شود!

چرا باید روی مشکلات موجود تمرکز کنیم؟

می‌خواهید یک سایت درست کنید، یک برنامه موبایل بنویسید یا یک نرم‌افزار سازمانی درست کنید. چطور به این نتیجه می‌رسید که در چه زمینه‌ای محصول نرم‌افزاری‌تان را درست کنید؟

راه اشتباه
راه اشتباه این است که یک محصول را درست کنید و بعد در یک جستجوی خانه به خانه دنبال مشتری برایش بگردید!

راه درستراه درست این است که یک نیاز (بخوانید مشکل) را پیدا کنید و به دنبال ارائه راه حلی برای آن باشید. به عبارت بهتر اگر محصولی که می‌سازید مشکلی را از مردم (یا مخاطبانش) حل نکند، حکایت یک دکمه است که بخواهید برایش کت بدوزید!

واقعیت این است که مردم حاضرند برای رفع مشکلات موجودشان هزینه بپردازند، رفع این مشکلات همیشه به معنی برطرف کردن کامل آن‌ها نیست، گاهی سریع‌تر شدن یک فرآیند، اطمینان از صحت روال انجام شده، اطلاع‌رسانی در حین انجام مراحل یک فرآیند طولانی و … می‌تواند همان چیزی باشد که کاربران به دنبالش هستند.

چطور مطمئن شویم که راه حل ما درست است؟

بسیار خب، شما نشسته‌اید و بعد از کلی فکر تعدادی مشکل پیدا کردید و راه حل‌هایی هم در ذهن‌تان دارید. چطور مطمئن می‌شوید که راه‌حل‌های شما درست است؟

راه اشتباه
راه اشتباه این است که محصول را درست کنید و بعد به چند نفر نشان بدهید و نظرشان را راجع به راه‌حل‌تان بپرسید. چرا این راه اشتباه است؟ چون شما خودتان را درگیر هزینه تولید کرده‌اید. هزینه تولید نرم‌افزار بالاست، نباید بی دلیل متحمل هزینه تولید نرم‌افزاری شوید که در نهایت باید انداختش توی سطل آشغال!

راه درست
قبل از اینکه حتی یک خط کد بنویسید، مشکلی که پیدا کردید و راه حل پیشنهادی‌تان را بنویسید و برای تکمیل ایده پردازی برای چند نفر بفرستید و نظرشان را بپرسید. اخیراً من برای یک مشکل این کار را کردم و آن را برای عده‌ای فرستادم. برآیند همه نظرات جمع آوری شده این شد که گرچه مشکل وجود دارد اما راه حل جواب نمی‌دهد! بنابراین قضیه منتفی شد. به این می‌گویند شکست روی کاغذ. هزینه شکست روی کاغذ خیلی خیلی پایین‌تر از شکست در دنیای واقعی است.

چطور بفهمیم که با نرم‌افزارمان یک مشکل واقعی را حل کرده‌ایم؟

تا اینجای کار، پذیرفته‌اید روی یک مشکل موجود کار کنید و برای رفعش راه حل نرم‌افزاری بدهید (نه اینکه یک چیز عجیب و غریب که به نظر خودتان باحال است بسازید و معلوم نباشد به درد چه کسانی می‌خورد).
در گام بعدی مطمئن شدید یک مشکل را پیدا کرده و راه حلی برای آن ارائه کردید و نظر چند نفری را هم درباره راه حل پرسیدید و در نهایت به این نتیجه رسیدید که وقت درست کردن محصول است. محصول را آماده کردید اما متوجه می‌شوید علیرغم تصورات قبلی‌تان محصول چندان مورد استفاده کاربران هدف نیست. مشکل از کجاست؟ بیشتر مواقع مشکل از اینجاست که شما یک مشکل واقعی را حل نکرده‌اید. در واقع یک آلترناتیو برای راه‌حل‌های موجود هستید و اگر مزیت رقابتی نداشته باشید عملاً محصول شما فروش نخواهد رفت!

راه تشخیص اینکه مشکل واقعی را حل کرده‌اید خیلی ساده است. محصول شما باید بتواند چیزی را جایگزین کند! یعنی باید از کاربران نرم‌افزارتان پس از انتخاب شما چنین عباراتی را بشنوید:

اگر محصول نرم‌افزاری شما با موفقیت توانسته باشد یک مشکل واقعی را حل کند معنی‌اش این است که محصول شما موفق شده جایگزین یک راه حلی که مشتریان قبلاً از آن استفاده می‌کردند بشود.

پی نوشت: این نوشته الهام بخش نوشتن این پست بود. البته مثل همیشه تجربیات خودم را هم به موضوع اصلی اضافه کردم.