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

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

دقت در جزئیات شما را متمایز می‌کند

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

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

کد و اینترفیس‌های زیبا درست کنید

استدلال‌هایی مثل اینکه بخش تنظیمات نرم‌افزار را فقط مدیر نرم‌افزار می‌بیند پس اهمیتی ندارد که چه شکلی باشد، یا  اینکه این کد قرار است در یک job با schedule خاص اجرا شود پس مهم نیست چطوری نوشته می‌شود و مواردی از این دست ناشی از دو چیز است: فشار deadline‌ها در یک پروژه تجاری و تنبلی تیم توسعه! نقش عامل دوم هم به اندازه عامل اول پر رنگ است.
بیل گیتس می‌گوید: “if you can’t make it good, at least make it look good” اما می‌خواهم این جمله را این‌طور اصلاح کنم که اگر نمی‌توانید خوب درستش کنید، اصلاً درستش نکنید!
ارائه یک کار بی‌کیفیت یا کم‌کیفیت در ظاهر یا جزئیات حتی با وجود مزیت رقابتی باز هم باعث موفقیت نرم‌افزار شما نمی‌شود.