«کارآفرینی فناورانه» در دنیای نرم‌افزار معمولاً با یک ایدهٔ درخشان در گاراژ شروع نمی‌شود؛ با یک قرارداد شروع می‌شود. تیمی برای حل مشکل یک مشتری مشخص سامانه‌ای می‌سازد، تحویل می‌دهد و کمی بعد درخواست‌های مشابه از راه می‌رسند. همان‌جا یک انتخاب سرنوشت‌ساز پیش می‌آید: هر درخواست تازه را پروژهٔ تازه ببینیم یا به سمت محصولی برویم که یک بار ساخته می‌شود و بارها فروخته می‌شود؟ این مقاله دربارهٔ همین گذار است؛ مسیری که از «کار برای یک مشتری» به «کار برای یک بازار» می‌رسد و بیشتر شرکت‌های نرم‌افزاری سازمانی روزی مجبور به انتخابش می‌شوند.
پروژه، بهترین آزمایشگاه محصول است
وسوسهٔ همیشگی این است که پیش از فروش، محصول را کامل بسازیم. تجربهٔ شرکت‌هایی که سال‌ها نرم‌افزار سفارشی تحویل داده‌اند چیز دیگری می‌گوید: پروژه‌ها ارزان‌ترین منبع کشف محصول‌اند، به شرطی که از آن‌ها داده استخراج شود. در هر پروژه سه چیز به دست می‌آید که هیچ جلسهٔ ایده‌پردازی جای آن را نمی‌گیرد: فرایند واقعی کسب‌وکار، رفتار کاربر واقعی و پولی که واقعاً پرداخت شده است.
قدم اول، ثبت الگو است. یک دفتر سادهٔ «الگوهای تکرارشونده» بسازید و در آن سه چیز بنویسید: کدام بخش از تحلیل و کد در پروژه‌های مختلف تکرار شده، ساخت آن چقدر زمان برده، و چند مشتری مستقل آن را خواسته‌اند. وقتی برای سومین بار بخش بزرگی از مدل داده یا یک جریان کاری مشابه بازنویسی شد، آن بخش دیگر «سفارشی‌سازی» نیست؛ نامزد محصول است.
سه آزمونی که پیش از محصول‌سازی باید بدهید
تبدیل کد به محصول، تصمیم احساسی نیست. سه آزمون ساده کمک می‌کند پیش از سرمایه‌گذاری، مسیر را بسنجید:
- آزمون تکرار: آیا این مشکل در چند کسب‌وکار مستقل وجود دارد؟ اگر تفاوت‌های مشتریان از شباهت‌هایشان بیشتر است، آنچه دارید یک ابزار داخلی است، نه محصول. محصول روی شباهت‌ها سوار می‌شود و تفاوت‌ها را به تنظیمات می‌سپارد.
- آزمون پرداخت: آیا کسی حاضر است پیش از کامل شدن محصول پول بدهد؟ اگر پاسخ نه است، احتمالاً مشکل به‌اندازهٔ کافی دردناک نیست. پیش‌فروش یا قرارداد محدود با تخفیف، هم سرمایه می‌دهد و هم تعهد می‌آورد؛ و هزینهٔ اشتباه را کوچک نگه می‌دارد.
- آزمون مرز: هستهٔ مشترک را از پوستهٔ اختصاصی جدا کنید و بپرسید چه سهمی از کد فعلی واقعاً مشترک است. اگر بیش از نیمی از سامانه به یک مشتری گره خورده باشد، محصول‌سازی یعنی بازنویسی، نه بسته‌بندی.
هسته و پوسته؛ معماری‌ای که سفارشی‌سازی را ارزان می‌کند
محصول نرم‌افزاری خوب، محصولی است که هستهٔ آن ثابت بماند و پوستهٔ آن برای هر مشتری تغییر کند؛ بدون آنکه کد هسته دست بخورد. هسته شامل موجودیت‌های اصلی، قواعد کسب‌وکار مشترک و جریان‌های کاری پایه است. پوسته شامل گزارش‌ها، فیلدهای اضافه، ظاهر و یکپارچه‌سازی با سامانه‌های دیگر می‌شود.
دو قاعدهٔ عملی این جدایی را حفظ می‌کند:
- پیکربندی به‌جای شخصی‌سازی: هر درخواستی که با یک تنظیم، فرم‌ساز یا قاعدهٔ قابل تعریف حل شود، بهتر از یک خط کد اختصاصی است.
- انشعاب نگیرید: نسخهٔ جداگانه برای هر مشتری، در ظاهر سرعت می‌آورد و در واقع مسیر رشد را می‌بندد. شاخه‌های اختصاصی به‌سرعت به بدهی فنی تبدیل می‌شوند و هر اصلاح در هسته باید چند بار تکرار شود.
چندمستأجری و وایت‌لیبل؛ اهرم فروش محصول
وقتی محصول آماده شد، پرسش بعدی این است: یک نصب برای همه، یا نصب جداگانه برای هر مشتری؟ معماری چندمستأجری (multi-tenancy) اجازه می‌دهد چند کسب‌وکار روی یک نصب واحد سرویس بگیرند، در حالی که داده‌هایشان جدا می‌ماند. لایهٔ وایت‌لیبل (white-label) هم می‌گذارد شریک یا مشاور، همان سامانه را با برند خودش به مشتریانش بفروشد؛ کانالی که هزینهٔ جذب مشتری را به‌شکل محسوسی پایین می‌آورد. نمونه‌ای از این الگو، سامانهٔ مدیریت تماس و CRM با قابلیت چندمستأجری است که یک نصب را به چند کسب‌وکار سرویس می‌دهد. البته این معماری رایگان نیست: جداسازی دقیق داده، پشتیبان‌گیری، به‌روزرسانی همگانی و پشتیبانی چندلایه، از همان روز اول باید در طراحی دیده شود، نه بعد از رسیدن مشتری پنجم.
اقتصاد واحد: عددی که مسیر رشد را تعیین می‌کند
بسیاری از محصول‌های نرم‌افزاری نه به‌خاطر ضعف فنی، بلکه به‌خاطر economics شکست می‌خورند. اقتصاد واحد (unit economics) یعنی بدانید از یک مشتری چقدر درمی‌آورید و برایش چقدر خرج می‌کنید. چهار عدد را برای هر مشتری محاسبه کنید:
- هزینهٔ راه‌اندازی: نصب، انتقال داده، آموزش و سفارشی‌سازی اولیه
- هزینهٔ پشتیبانی ماهانه: ساعت انسانی، نه تعرفهٔ قرارداد
- هزینهٔ زیرساخت و نگهداری نسخه
- درآمد تکرارشونده (recurring revenue) در یک بازهٔ زمانی مشخص
اگر هزینهٔ راه‌اندازی هر مشتری نزدیک به کل درآمد سال اولش باشد، آنچه می‌فروشید محصول نیست؛ پروژه‌ای است با برچسب اشتراک. راه‌حل همیشه افزایش قیمت نیست: خودکارسازی نصب، قالب‌های آمادهٔ انتقال داده و کتابخانهٔ پاسخ‌های پشتیبانی، همان هزینه را در مشتری دوم و سوم نصف می‌کند.
چهار دامی که رشد را متوقف می‌کند
- بزرگ‌ترین مشتری، جادهٔ محصول را می‌چرخاند: اگر نقشهٔ راه را درخواست‌های یک مشتری بنویسد، محصول به سفارشی‌سازی گران‌قیمت برمی‌گردد. برای هر درخواست بپرسید «چند مشتری دیگر این را می‌خواهند؟»
- فروش پیش از آمادگی پشتیبانی: محصول بدون پشتیبانی قابل پیش‌بینی، تجربهٔ مشتری را می‌سوزاند و ارجاع را از بین می‌برد.
- ساختن همه‌چیز برای همه: فهرست قابلیت‌ها به‌سرعت متورم می‌شود. هر قابلیت تازه، بار نگهداری دائمی است؛ فقط چیزی را بسازید که در مسیر فروش بعدی اثر دارد.
- نداشتن مالک محصول: تیمی که سال‌ها پروژه تحویل داده، با معیار «تاریخ تحویل و محدودهٔ قرارداد» فکر می‌کند. محصول به کسی نیاز دارد که معیارش استفادهٔ واقعی و ماندگاری مشتری باشد.
جمع‌بندی
مسیر رشد یک محصول نرم‌افزاری از دل پروژه‌ها می‌گذرد، اما با خودِ پروژه تمام نمی‌شود. سه کار، این گذار را ممکن می‌کند: الگوهای تکرارشونده را جدی ثبت کنید، پیش از سرمایه‌گذاری سنگین سه آزمون تکرار و پرداخت و مرز را بدهید، و از روز اول هسته را از پوسته جدا نگه دارید تا سفارشی‌سازی به انشعاب کد تبدیل نشود. هر جا این سه کار انجام شده، محصول از دل سفارش‌ها بیرون آمده؛ هر جا نشده، شرکت همچنان پروژه می‌فروشد و اسمش را محصول می‌گذارد.
