شاید نه چندان با “بهینه سازی”

در پیگیری بی پایان بهینه سازی، تست A/B، معیارها و قیف ها، ما در خطر از دست دادن لذت و ارزش کار خلاق هستیم.

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

وقتی حداقل برای انجام کار انجام می دهیم، کارآمد هستیم اما هیجان انگیز نیستیم. ما “ضعیف” هستیم، اما دلها را تکان نمی دهیم. ما کارآمد هستیم اما بازیگوش نیستیم.

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

گاهی اوقات باید کاری را انجام دهید فقط به این دلیل که جالب است. چیزی به نام “طعم” محصول وجود دارد.

این نمایش باورنکردنی عشق را که IHumanable به کامپیوتر خود نشان می دهد، ببینید:

این یکی از دلایلی است که من iMac جدید خود را دوست دارم، این فقط یک صفحه نمایش شناور جادویی زیبا و پر از پیروزی است.

شما نمی توانید برای تایید قوی تر درخواست کنید. این حتی بهتر از “725231 دلار برای من ذخیره شد.” این فراتر از مفید است –این عشق است. (عشق پیروز می شود.)

آیا عشق از نکات اصلی می آید؟ آیا از طریق آزمایش A/B و پیاده سازی ویژگی ها خارج از بالای GetSatisfaction عشق می ورزی؟ یا چیز دیگری است، چیزی عمیق تر، چیزی کمتر افزایشی، کمتر داده محور، شهودی تر، احساسی تر؟

اولین محصول من در Smart Bear در سال 2002 یک اختراع غیربهینه شناور در پیروزی به نام “mini-look” داشت.

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

چیزی که باید روی آن تمرکز کنید عنصر UI در گوشه سمت راست پایین است. این “مینی بیننده” و به هر معنی قابل اندازه گیری، این یک تصمیم تجاری وحشتناک است.

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

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

اما آیا شما موافق نیستید؟ آنها شبیه باگرها هستند:

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

اکنون برای همه بحث‌های معمول در مورد ناب، چابک و مینیمالیسم، باید از boogers نیز استفاده می‌کردم:

1. بوگرها اکنون نیمه استاندارد شده بودند. رابط های کاربری باید از اصل “کمترین شگفتی” پیروی کنند – اگر مردم به یک استعاره، نماد یا رفتار خاص عادت دارند، باید از آن پیروی کنید تا مردم فوراً محصول شما را درک کنند. هیچ کس دیگری نمایشگر کوچک نداشت.
2. بوگرها حداقل فضای صفحه را اشغال می کنند. این فقط یک نوار نازک است که پهن‌تر از نوار پیمایش نیست. در واقع، برخی از محصولات باگرها را قرار می دهند در بالای نوار اسکرول نمای کوچک نه تنها بزرگتر است، بلکه عرض قابل توجهی نیز دارد، به این معنی که شما باید بقیه قسمت سمت راست صفحه را با چیزهای دیگری اشغال کنید.
3. به هر حال وقتی در حال پیمایش فایل هستید، Boogers درست در کنار نوار پیمایش جایی که شما به آن نگاه می کنید ظاهر می شود.
4. محاسبات Boogers نسبت به الگوریتم تنوع رنگ در miniviewer تلاش کمتری می کند.
5. بوگرها تلاش کمتری برای کشیدن می کشند. بوگرها یک بار روی صفحه کشیده می شوند و تغییر نمی کنند مگر اینکه اندازه پنجره تغییر کند⁠-عملیاتی نادر. با این حال، miniview موقعیت اسکرول فعلی شما را در فایل نشان می‌دهد (آن براکت‌های سیاه)، بنابراین وقتی در اطراف فایل پیمایش می‌کنید، سرعتی که می‌توانید با آن می‌توانید دوباره محاسبه و ترسیم کنید اهمیت دارد. کشیدن مستقیم روی صفحه باعث سوسو زدن می شود، بنابراین به بافر کردن خارج از صفحه نیاز دارید. به طور خلاصه مینی برنامه بازبینی تلاش برنامه نویسی بسیار بیشتری با احتمال خطاهای بسیار بیشتر است.
6. مینی بیننده اطلاعات بیشتری نسبت به بوگرها منتقل نمی کند.

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

مینی بیننده ضایع کننده اما سرگرم کننده بود. بهینه نبود و هیچ مزیت قابلیت استفاده قابل اندازه گیری نداشت، اما “پر از پیروزی” بود. تلاش بیشتری می‌خواست، اما دوست‌داشتنی بود⁠ – یک ویژگی مهم که به راحتی توسط معیارها و صفحات گسترده قابل دریافت نیست.

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

اما گاهی کار شما پر کردن صفحه نمایش است پیروزی شاد.