ترجمه کتاب واقعی شدن، فصل ۵٫ انتخاب ویژگی‌ها

توجه:

از این به بعد می‌توانید این کتاب را در وب سایت اختصاصی‌اش مطالعه کنید:

وب سایت اختصاصی کتاب واقعی شدن

نیمه، ولی نه نیمه آشغال

یک محصول نیمه بسازید، نه یک محصول نیمه آشغال

برای توسعه برنامه‌های وبی، مراقب روش «همه‌چیز» باشید. اگر همه ایده‌های جالبی که در حین کار به آن‌ها برخورد می‌کنید وارد کار کنید، در نهایت به نگارشی از نرم‌افزار خود می‌رسید که نیمی از آن آشغال است. کاری که باید انجام دهید، ساختن نیمی از محصول است که خوب و عالی باشد.

به چیزهای اساسی بپردازید. ایده‌های خوب می‌توانند در فهرست قرار بگیرند. فکر کنید که محصول چه چیزی باید باید باشد و بعد نیمی از آن را حذف کنید. ویژگی‌ها را هرس کنید تا زمانی که فقط اساسی‌ترین آن‌ها باقی بماند. بعد دوباره این کار را تکرار کنید.

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

با نرم‌افزاری کوچک و باهوش آغاز کنید و اجازه بدهید راه بیافتد. بعد می‌توانید به این پایه محکمی که ساخته‌اید چیزهای مختلف اضافه کنید.

 

اصلاً مهم نیست

فقط چیزهای اساسی

پاسخ محبوب ما به سؤالاتی از قبیل «چرا این کار را نکردید یا چرا آن کار را نکردید؟» همیشه این است: «اصلاً مهم نیست». این جمله متضمن چیزی است که یک محصول را بزرگ می‌کند. فهمیدن چیزهای که مهم هستند و رها کردن سایر چیزها.

وقتی Campfire را عرضه کردیم، اغلب از افرادی که برای اولین بار نرم‌افزار را امتحان می‌کردند سؤال‌هایی می‌شنیدیم:

«چرا بازه‌های زمانی ۵ دقیقه؟ چرا بازه‌های زمانی به ازای هر خط نباشد؟»

پاسخ: اصلاً مهم نیست. چقدر اتفاق می‌افتد که شما یک مکالمه را چند ثانیه‌ای یا حتی دقیقه‌ای دنبال کنید؟ قطعاً در ۹۵ درصد موارد اینگونه نیست. بازه‌های زمانی پنج دقیقه کافی است چون هر چیزی که بیشتر ویژه و خاص شود اصلاً مهم نیست.

«چرا نمی‌گذارید از حروف ضخیم، خمیده یا رنگی در گفتگوها استفاده کرد؟»

پاسخ: اصلاً مهم نیست. اگر شما می‌خواهید بر چیزی تأکید کنید می‌توانید از کلید مطمئن Caps Lock استفاده کنید یا چند تا * در اطراف کلمه یا عبارت قرار دهید. این راه‌حل‌ها نیاز به نرم‌افزار بیشتر، پشتیبانی فنی، توان پردازش یا آموزش ندارند. وانگهی، قالب‌بندی سنگین در گفتگوی متنی ساده اصلاً مهم نیست.

«چرا تعداد افراد حاضر در گفتگو یا در یک زمان خاص را نمایش نمی‌دهید؟»

پاسخ: اصلاً مهم نیست. نام افراد حاضر در گفتگو فهرست شده است و ضمناً چه فرقی می‌کند که ۱۲ نفر آنجا باشند یا ۱۶ نفر؟ اگر این موضوع بر رفتار شما تأثیر نداشته باشد، قطعاً موضوع مهمی نیست.

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

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

 

با گفتن «نه» آغاز کنید

کاری کنید که پیاده‌سازی ویژگی‌ها سخت شود

راز ساختن محصولی نیمه به جای محصولی نیمه آشغال در گفتن «نه» است.

هر زمان که شما به یک ویژگی «بله» می‌گویید، بچه‌ای را به فرزندخواندگی پذیرفته‌اید. باید کودک خود را در زنجیره‌ای از وقایع (مانند طراحی، پیاده‌سازی، آزمون و …) همراه خود ببرید. و هر وقت که این ویژگی‌ها آماده شود، شما به آن‌ها می‌چسبید. فقط سعی کنید یک ویژگی عرضه شده را از مشتریان دریغ کنید تا ببینید که چقدر آن‌ها را ناراحت می‌کنید.

 

آدم بله‌گو نباشید

 

کاری کنید که پیاده‌سازی ویژگی‌ها سخت شود. کاری کنید هر ویژگی خودش را اثبات کند و نشان دهد که باقی می‌ماند. شیبه «باشگاه مبارزه» است. فقط باید به ویژگی‌هایی فکر کنید که بتوانند سه روز پشت در منتظر اجازه ورود بمانند.

به این دلیل است که باید با «نه» آغاز کنید. هر درخواست برای ویژگی جدید که به ما می‌رسد -یا خود ما پیشنهاد می‌کنیم- با پاسخ «نه» مواجه می‌شود. به آن‌ها گوش می‌کنیم ولی به آن‌ها عمل نمی‌کنیم. پاسخ اولیه «الأن نه» است. اگر درخواست برای یک ویژگی همچنان برگردد، می‌دانیم که زمان آن است که به آن عمیق‌تر نگاه کنیم. بعد از آن و فقط بعد از آن، آن ویژگی را واقعاً مورد بررسی قرار می‌دهیم.

چه می‌گوید به مشتریان معترضی که ایده‌‌های آن‌ها درباره ویژگی‌ها را نپذیرفته‌اید؟ به آن‌ها یادآوری کنید که اولین بار برای چه برنامه را پسندیده‌اند. «آن را دوست دارید به خاطر این که ما نه می‌گوییم. آن را دوست دارید به خاطر این که صد تا کار دیگر انجام نمی‌دهد. آن را دوست دارید به خاطر این که نمی‌خواهد همیشه همه را راضی نگهدارد.»

 

ما هزاران ویژگی نمی‌خواهیم

استیو جابز جلسه‌ای خصوصی برای معرفی فروشگاه موسیقی iTunes برای تعدادی از افراد مستقل و فعال در زمینه ضبط موسیقی ترتیب داده بود. جالب‌ترین قسمت در آن روز وقتی بود که افراد دست خود را بالا می‌آوردند و می‌پرسیدند: «آیا فلان کار را هم انجام می‌دهد؟»، «آیا برنامه‌ای برای اضافه کردن فلان ویژگی را دارید؟». در انتها جابز گفت: «بایستید، بایستید، دست‌های خود را پایین بیاورید. گوش کنید: من می‌دانم شما هزاران ایده جالب درباره iTunes دارید. ما هم مثل شما هستیم. ولی ما یک هزار کاره نمی‌خواهیم. اینطوری زشت است. نوآوری بله گفتن به همه چیز نیست، نه گفتن به همه چیز غیر از ویژگی‌های اساسی است.»

Derek Sivers، رئیس و برنامه‌نویس CD Baby و Host Baby نقل از (Say NO by default)

هزینه‌های مخفی

افشا کردن قیمت ویژگی‌های جدید

حتی اگر یک ویژگی مرحله «نه» را پشت سر گذاشته باشد، باز هم باید هزینه‌های مخفی آن را افشا کرد. برای مثال مراقب حلقه تکرار ویژگی‌ها (حالتی که یک ویژگی، ویژگی‌های جدید را به دنبال دارد) باشید. ما چندین درخواست برای اضافه کردن قفسه (Tab) جدید ملاقات‌ها به Basecamp داشتیم. به تمام اقلام مورد نیاز برای قفسه ملاقات‌ها فکر کنید: مکان، زمان، اتاق، افراد، رایانامه‌های دعوت، یکپارچه شدن با تقویم، مستندات پشتیبانی و غیره. نیازی به بیان نیست که باید تصاویر تبلیغاتی، صفحات گردش در برنامه، صفحات سؤالات متداول و راهنما، شرایط استفاده از نرم‌افزار و چیزهای دیگر را تغییر دهیم. قبل از این که متوجه شوید، یک ایده کوچک به بهمنی دردسرساز تبدیل می‌شود.

برای هر ویژگی جدید شما باید…

۱٫ نه بگویید.

۲٫ ویژگی جدید را وادار کنید تا ارزش خود را اثبات کند.

۳٫اگر باز هم پاسخ نه بود، همین جا آن را رها کنید. در غیر این صورت ادامه دهید…

۴٫ طرح اولیه صفحات را بکشید. (نمای کاربری)

۵٫ صفحات را طراحی کنید. (نمای کاربری)

۶٫ برنامه آن را بنویسید.

۷٫ الی ۱۵٫ آزمون، استفاده، آزمون، استفاده، آزمون، استفاده، آزمون، استفاده…

۱۶٫ بررسی کنید که آیا راهنما نیازی به تغییر دارد یا نه؟

۱۷٫ در صورت لزوم قسمت گردش در برنامه را اصلاح کنید.

۱۸٫ در صورت لزوم برنامه بازاریابی را تغییر دهید.

۱۹٫ در صورت لزوم شرایط استفاده را اصلاح کنید.

۲۰٫ بررسی کنید که آیا کلیه تعهدات به درستی انجام شده‌اند یا نه.

۲۱٫ بررسی کنید که آیا ساختار تعیین قیمت تأثیر گرفته یا نه.

۲۲٫ عرضه کنید.

۲۳٫ نفس خود را نگه دارید.

 

آیا می‌توانید آن را اداره کنید؟

چیزی بسازید که می‌توانید آن را مدیریت کنید

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

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

خلاصه این که محصولاتی بسازید و خدماتی ارایه کنید که می‌توانید مدیریت کنید. تعهد دادن آسان است. عمل کردن به این تعهدات سخت است. مطمئن شوید هر آن چه که انجام می‌دهید، چیزی است که از عهده مسائل تشکیلاتی، راهبردی و مالی آن برمی‌آیید.

 

راه‌حل‌های انسانی

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

یک قاعده را به مردم تحمیل نکنید. برعکس، نرم‌افزار خود را عمومی بسازید تا هر کسی بتواند راه‌حل خودش را پیدا کند. به مردم آن قدر بدهید که بتوانند مشکلاتشان را به شیوه خودشان حل کنند. و بعد از مسیر آن‌ها کنار بروید.

وقتی Ta-da list را ساختیم، عمداً خیلی چیزها را حذف کردیم. هیچ راهی برای واگذار کردن یک کار به دیگران یا تعیین تاریخی برای کار یا دسته‌بندی کارها وجود نداشت.

ما برای اجازه دادن به بروز خلاقیت افراد، ابزار را تمیز و مرتب نگه داشتیم. مردم فهمیدند که چطور باید مسائل را حل کنند. اگر بخواهند تاریخی را به کار اضافه کنند، عبارت‌هایی مانند (در تاریخ: ۲۵/۳/۱۳۸۶) را به ابتدای کار اضافه می‌کنند. اگر بخواهند یک دسته‌بندی ایجاد کنند، عبارت‌هایی مانند [کتاب‌ها] را به ابتدای کار اضافه می‌کنند. آرمانی است؟ نه. بی‌نهایت منعطف؟ بله.

اگر سعی می‌کردیم نرم‌افزار را به گونه‌ای بسازیم که کلیه موارد بالا را به صورت ویژه اداره کند، باعث می‌شد نرم‌افزار برای کلیه حالت‌هایی که این موارد به کار نمی‌آیند، کارایی لازم را نداشته باشد.

برای حل مشکل ریشه‌ای، هر چه می‌توانید انجام دهید. پس از آن کنار بایستید. مردم راه‌حل‌ها و قواعد خودشان را در چارچوب عمومی شما پیدا می‌کنند.

 

بی‌خیال درخواست برای ویژگی‌ها شوید

بگذارید مشتریان شما به شما یادآوری کنند که چه چیزی مهم است

مشتری‌ها همه چیز می‌خواهند. درخواست‌های آن‌ها مثل بهمنی بر سر شما فرود می‌آید. سری به انجمن‌های بحث محصولات ما بزنید، درخواست برای ویژگی‌های جدید بر سایر چیزها غلبه کرده است.

ما همواره عباراتی مثل «فقط این ویژگی کوچک» یا «این که سخت نیست» یا «اضافه کردن فلان چیز آسان نیست؟» یا «افزودن این یکی بیش از چند ثانیه وقت نمی‌گیرد» یا «اگر فلان چیز را اضافه کنید، من دو برابر می‌پردازم» و مانند آن‌ها را می‌شنویم.

البته ما مردم را برای درخواست‌هایشان مقصر نمی‌دانیم. ما آن‌ها را تشویق می‌کنیم و مشتاقیم آنچه را آن‌ها باید بگویند بشنویم. همه چیزهایی که به نرم‌افزارهایمان اضافه کرده‌ایم از درخواست‌های مشتریان آغاز شده است. ولی همانطور که قبلاً گفتیم اولین پاسخ شما باید «نه» باشد. پس با این همه درخواست‌هایی که هر روز می‌رسند چه چه می‌کنید؟ آن‌ها را کجا نگهداری می‌کنید؟ چگونه آن‌ها را مدیریت می‌کنید؟ کاری نمی‌کنید. آن‌ها را می‌خوانید و بعد دور می‌ریزید.

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

چطور به چنین نتیجه‌ای رسیدیم؟ وقتی برای اولین بار Basecamp را عرضه کردیم، هر درخواست مهمی را که می‌رسید در فهرست کارهای Basecamp وارد می‌کردیم. وقتی درخواستی تکرار می‌شد، فهرست را با افزودن شماره‌ای (۱، ۲، ۳ و …) بروز می‌کردیم. فکر می‌کردیم که روزی این فهرست را بازنگری کرده و کار بر روی ویژگی‌هایی که بیشتر درخواست شده‌اند را آغاز خواهیم کرد.

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

در ضمن، این که X نفر چیزی را درخواست کرده‌اند، هرگز به معنی اهمیت آن چیز نیست. بعضی وقت‌ها بهتر است که بگویید نه و دورنمای خود از نرم‌افزار را حفظ کنید.

 

سس نزنید لطفاً   

از مردم بپرسید چه چیزی را نمی‌خواهند

بیشتر مطالعات نرم‌افزاری و سؤال‌های تحقیقاتی حول محور چیزهایی است که افراد از محصول انتظار دارند. «فکر می‌کنید که چه ویژگی‌ای از قلم افتاده است؟» «اگر فقط می‌توانستید یک چیز به نرم‌افزار اضافه کنید، چه می‌کردید؟» «چه چیزی این نرم‌افزار را برای شما سودمندتر می‌کند؟»

نظر شما درباره آن روی سکه چیست؟ چرا از مردم نپرسیم که چه چیزی را نمی‌خواهند؟ «اگر می‌توانستید فقط یک ویژگی را حذف کنید، کدام را حذف می‌کردید؟» «از چه چیزی استفاده نمی‌کنید؟» «چه چیزی بیشتر دست و پای شما را بسته است؟»

بیشتر کردن همیشه پاسخ مناسب نیست. بعضی وقت‌ها بزرگ‌ترین محبتی که می‌توانید به مشتریان بکنید این است که چیزی را حذف کنید.

 

نوآوری از گفتن نه به وجود می‌آید

[نوآوری] از گفتن نه به هزار چیز به وجود می‌آید تا این که مطمئن شویم راه خطا نمی‌رویم یا این که سعی نمی‌کنیم بیش از حد کار کنیم. همیشه به بازارهای جدیدی که می‌توانیم به آن‌ها وارد شویم فکر می‌کنیم، در حالی که فقط با گفتن نه است که می‌توانید بر چیزهایی که واقعاً مهم هستند تمرکز کنید.

         Steve Jobs، مدیر اجرایی Apple، نقل از The Seed of Apple’s Innovation.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.