اشتباهات رایج بنیانگذاران غیرفنی
این فهرست از پروژههای واقعی درآمده، نه از کتاب. هر بند اینجاست چون بیش از یک بار دیدهایم و هر بار هزینهٔ مشابهی ساخته.
۱. ساختن پیش از فروختن
پرهزینهترین اشتباه ممکن، و شایعترین.
یک سال و کل سرمایه صرف ساخت نسخهٔ کامل میشود، و بعد معلوم میشود بازار آن را نمیخواهد — یا میخواهد ولی نه به این شکل.
نشانهٔ زودهنگام: اگر هنوز با ده نفر از مشتریان بالقوه ننشستهاید و کسی پیشپرداخت نداده، دارید حدس میزنید.
روشش در اعتبارسنجی ایده.
۲. نسخهٔ اولی که نسخهٔ اول نیست
فهرستی از چهل قابلیت که همهشان «ضروری»اند.
نتیجه: پروژهٔ هجدهماهه، تمام شدن پول در ماه چهاردهم، و محصولی که هرگز به دست کاربر نمیرسد.
نشانه: اگر نمیتوانید در یک جمله بگویید نسخهٔ اول چه میکند، بزرگ است.
معیارهای حذف در چه چیزی را از نسخهٔ اول حذف کنیم.
۳. کپی کردن محصول موفق
«مثل فلان اپلیکیشن، ولی برای این صنعت.»
مشکل این است که آن اپلیکیشن امروز صد قابلیت دارد که در طول هفت سال و بر اساس بازخورد میلیونها کاربر اضافه شده. شما نسخهٔ امروزش را میبینید، نه نسخهٔ اولش.
نسخهٔ اول همان محصول، معمولاً بهطرز شرمآوری ساده بوده.
۴. سنجیدن پیشرفت با درصد
«پروژه هفتاد درصد پیش رفته.»
این عدد تقریباً همیشه بیمعنی است. نرمافزار یا کار میکند یا نمیکند؛ و آن سی درصد آخر معمولاً نصف زمان را میگیرد.
معیار درست: هر دو هفته چیزی ببینید که بشود با آن کار کرد. تیمی که تا ماه سوم چیز قابل استفادهای نشان نمیدهد، در ماه سوم غافلگیرتان میکند.
۵. نبود یک نفر پاسخگو از سمت خودتان
تیم فنی سؤال میپرسد و جواب سه روز طول میکشد. یا بدتر: دو نفر از سمت شما دو جواب متفاوت میدهند.
نتیجهاش این است که توسعهدهنده یا منتظر میماند یا حدس میزند. هر دو گران است، و دومی گرانتر.
یک نفر باید مسئول پاسخ باشد و اختیار تصمیم داشته باشد.
۶. تغییر مداوم بدون آگاهی از هزینه
هر جلسه ایدهٔ جدیدی میآید. هر کدام کوچک است. مجموعشان پروژه را دو برابر میکند و هیچکس نفهمید کِی.
تغییر بد نیست؛ تغییر بدون قیمت بد است. قاعده: هر درخواست تخمین بخورد و جوابش این شکل باشد — «میشود، دو روز کار دارد، یا تحویل دو روز عقب میافتد یا چیز دیگری خارج میشود. کدام؟»
الگویش در تغییر دامنه.
۷. اعتماد کامل بدون هیچ بررسی
سپردن همهچیز به پیمانکار و ندیدن هیچ چیزی تا روز تحویل.
حداقلهایی که باید داشته باشید، بدون اینکه دانش فنی لازم باشد:
- دسترسی به مخزن کد از روز اول، حتی اگر نتوانید بخوانیدش.
- تحویل و پرداخت مرحلهای.
- مالکیت صریح کد، دامنه و حسابها.
فهرست کامل در وابستگی به تأمینکننده — و اگر پیمانکاری با دسترسی به کد مخالفت کند، همانجا بحث را جدی بگیرید.
۸. صرف کل بودجه برای ساخت
محصول آماده میشود و پولی برای رساندنش به مشتری نمانده.
بودجهٔ ساخت، همهٔ بودجه نیست. بعد از تحویل هم هزینه هست: اصلاحات بر اساس بازخورد واقعی، بازاریابی، و ماههایی که هنوز درآمدی نیست.
تقسیم واقعبینانهتر: حدود نیمی برای نسخهٔ اول، نیم دیگر برای بعدش.
۹. سکوت دربارهٔ آنچه نمیدانید
جلسهای که در آن سر تکان میدهید بدون اینکه بفهمید، هزینهاش را ماهها بعد میدهید.
بنیانگذاران غیرفنی معمولاً از پرسیدن سؤال «ساده» خجالت میکشند. این خجالت گرانترین احساس در کل پروژه است.
و معیار خوبی هم به شما میدهد: تیم فنی خوب، توضیحدادن به غیرفنی را بلد است. اگر کسی نمیتواند ساده توضیح دهد، یا خودش خوب نفهمیده یا همکار خوبی نیست.
۱۰. رها کردن محصول بعد از راهاندازی
«تمام شد، حالا بفروشیم.»
نرمافزار تمام نمیشود. روز راهاندازی، شروع یادگیری است نه پایان ساخت. کاربران کارهایی میکنند که پیشبینی نکرده بودید و همانها محصول واقعی را میسازند.
بودجه و ظرفیت برای دستکم شش ماه پس از راهاندازی کنار بگذارید.
سه اشتباه کوچکتر که مکررند
کپی کردن قیمت رقیب بدون فهمیدن ساختار هزینهاش. رقیبی که ارزان میفروشد، شاید زیان میدهد یا مدل درآمدی دیگری دارد.
نداشتن هیچ سنجهای. اگر نمیدانید چند کاربر برگشتهاند، نمیدانید محصول کار میکند یا نه. ابزار تحلیل ساده، از روز اول.
فرض اینکه کاربر مثل شما فکر میکند. شما محصول را ساختهاید و همهچیزش برایتان بدیهی است. یک بار کنار کاربری بنشینید و ببینید — تجربهٔ فروتنانهای است و از هر نظرسنجی مفیدتر.
آنچه بنیانگذاران موفق متفاوت انجام میدهند
از همان پروژهها، الگوی معکوس:
- پیش از ساخت، فروختهاند — حتی اگر دستی تحویل داده باشند.
- نسخهٔ اولشان شرمآور ساده بوده و زود منتشر شده.
- با کاربران حرف میزنند، مرتب و مستقیم.
- میدانند کدام تصمیم برگشتناپذیر است و فقط سر همانها وقت میگذارند — که در انتخاب فناوری توضیح دادهایم.
- کوچک اما مستمر میسازند، بهجای جهشهای بزرگ.
هیچکدام از اینها دانش فنی لازم ندارد. انضباط لازم دارد.