می‌خواهید نرم‌افزار وبی موفقی بسازید؟ پس وقت آن است که واقعی شوید. واقعی شدن روشی کوچکتر، ساده‌تر و بهتر برای ساختن نرم‌افزار است. واقعی شدن درباره گذشتن از چیزهایی که واقعی می‌نماید (نمودارها، شکل‌ها، جعبه‌ها، پیکان‌ها، سیم‌ها و غیره) و در عوض، پرداختن به چیزهای واقعی است. واقعی شدن کم شدن است. جمعیت کمتر، نرم‌افزار کمتر، امکانات کمتر، کاغذ بازی کمتر و کمتر شدن هر چیزی است که مهم می‌نماید (و خیلی از چیزهایی که فکر می‌کنید مهم هستند هرگز مهم نیستند).
واقعی شدن کوچک ماندن و چابک و چالاک شدن است.
واقعی شدن با ظاهر برنامه آغاز می‌شود، پنجره‌هایی که مردم می‌خواهند استفاده کنند. با چیزی که مشتری آن را تجربه می‌کند آغاز شده و از آن جا عقبگرد می‌کند. این‌ها به شما اجازه می‌دهد که پیش از این که نرم‌افزار به خطا برود، ظاهر آن را درست کنید.
واقعی شدن درباره تکرار و کاهش هزینه تغییرات است. واقعی شدن کلاً درباره اقدام کردن، دستکاری کردن و دائماً ارتقا دادن است که آن را به روشی عالی برای نرم‌افزارهای وبی تبدیل کرده است.
واقعی شدن فقط چیزی را به مشتری می‌دهد که نیاز دارد و سایر چیزها را حذف می‌کند.
واقعی شدن نتایج بهتری به بار می‌آورد زیرا شما را وادار می‌کند به جای درگیر شدن با ذهنیت خود از مسائل، با مسائل واقعی که می‌خواهید آن‌ها را حل کنید درگیر شوید. شما را وامی‌دارد که با واقعیت روبرو شوید.
واقعی شدن به دلیل ساختن پنجره‌های واقعی، بر ویژگی‌های کاربردی و مستندات ناپایدار تقدم دارد. ویژگی‌های کاربردی، مجعول و ساختگی هستند، توهمی‌از یک توافق، در حالی که که صفحات وب واقعی هستند. چیزی هستند که مشتری شما می‌بیند و استفاده می‌کند. این چیزی است که مهم است. واقعی شدن شما را به سرعت به چنین چیزی می‌رساند. این بدان معنی است که تصمیم‌گیری‌های شما برای نرم‌افزار بر مبنای چیزهای واقعی است نه نمادهای ذهنی.
در نهایت این که واقعی شدن راه حل ایده‌آلی برای برنامه‌های وبی است. روش کهنه و قدیمی‌فروش نرم‌افزار در جعبه و بعد یکی دو سال منتظر دریافت یک بروز رسانی ماندن در حال محو شدن است. نرم‌افزارهای وبی -بر خلاف نرم‌افزارهای نصبی- می‌توانند به صورت متداوم و روزانه رشد و نمو کنند.
واقعی شدن مانند تمام این منافع را برای شما به ارمغان می‌آورد.
چگونه نرم‌افزار قوی بسازیم
نوشته قوی، نوشته مختصر است. جمله نباید کلمات زیادی داشته باشد، بند نیز نباید جملات زیادی داشته باشد. به همان دلیل که نقاشی نباید خط زیادی و ماشین نباید قطعات زیادی داشته باشد. این بدان معنی نیست که نویسنده باید جملات را کوتاه‌تر بنویسد یا از جزئیات چشم بپوشد و موضوع را در لفافه بیان کند، بلکه هر کلمه باید گویا باشد.
نقل از The Elements of Style اثر William Strunk Jr.
روش قدیمی: فرایندی طولانی، پر از کاغذبازی و مسائل نامربوط. نتیجه عمومی: نرم‌افزار حجیم و فراموش‌شدنی که ضعف از سر و روی آن می‌بارد.
واقعی شدن شر این‌ها را کم می‌کند:
برای ساختن نرم‌افزاری فوق‌العاده نیاز به مقدار زیادی پول یا گروهی بزرگ یا چرخه توسعه طولانی ندارید. این چیزها عناصر تشکیل دهنده نرم‌افزارهای کند و پیچیده و غیر قابل درک و تغییر ناپذیر است.
در این کتاب ما به شما نشان می‌دهیم:
و خیلی چیزهای دیگر ...
تأکید بر روی مسائل اصلی است. ما شما را در باتلاق‌های نمونه کد یا حقه‌های css فرو نمی‌بریم. ما به تفکرات اصلی و فلسفه محرک فرایند واقعی شدن خواهیم پرداخت.
شما کارآفرین، طراح، برنامه نویس یا بازاریابی هستید که بر روی ایده بزرگی کار می‌کنید. شما می‌دانید که قوانین قدیمی دیگر به کار نمی‌آیند. نرم‌افزار خود را هر ساله بر روی دیسک فشرده منتشر می‌کنید. شما باید بسازید، اجرا کنید و دستکاری کنید، سپس مرتب این کار را تکرار کنید.
یا این که ممکن است شما هنوز درگیر توسعه چابک و ساختارهای تجاری نشده‌اید ولی دوست دارید درآمد بیشتری داشته باشید.
اگر این گونه است این کتاب برای شما است!
نکته: با این که تأکید اصلی این کتاب بر روی توسعه نرم‌افزارهای وبی است ولی بسیاری از ایده‌های آن برای فعالیت در حوزه‌های غیر از نرم‌افزار نیز کاربرد دارد. پیشنهادهای مربوط به گروه کوچک، تولید سریع نمونه اولیه، استقبال از تکرار، و بسیاری از چیزهای دیگری که در این جا آمده‌اند می‌تواند به شما در راه‌اندازی کسب و کار، نوشتن کتاب، طراحی پایگاه وب، ضبط آلبوم موسیقی، یا سایر کارها و فعالیت‌ها کمک کند. یک بار که شما در یکی از جنبه‌های زندگی واقعی شوید خواهید دید که چطور این مفاهیم می‌توانند در طیف وسیعی از فعالیت‌ها به کار گرفته شوند.
هنوز ترجمه نشده است.
برای جلوگیری از تکرار برخی اشتباهات، در این جا به تعدادی از اعتراضاتی که هر روزه می‌شنویم پاسخ می‌دهیم.
واقعی شدن سامانه‌ای است که برای ما فوق‌العاده مفید بوده است. ولی به این معنی نیست که واقعی شدن برای هر پروژه‌ای در این کره خاکی به درد می‌خورد. اگر شما سامانه‌های نظامی، سامانه‌های کنترل نیروگاه هسته‌ای، سامانه بانکی با میلیون‌ها کاربر، یا هر چیزی که با مسائل حیاتی یا مالی سر و کار دارد می‌سازید، شما باید برخی از روش‌های آزادانه ما را نادیده بگیرید و احتیاط بیشتری پیشه کنید. در ضمن واقعی شدن گزاره‌ای همه یا هیچ نیست. حتی اگر نمی‌توانید آن کاملاً بپذیرید دست کم تفکراتی وجود دارد که شما می‌توانید از آن‌ها استفاده کنید.
ما ادعا نمی‌کنیم که این فنون را ابداع کرده‌ایم. بسیاری از این ایده‌ها به شکل‌های گوناگون و در زمان‌های گذشته پیرامون ما وجود داشته‌اند. اگر مطالب و توصیه‌هایی را که این جا می‌خوانید، مطالبی که قبلاً در وبلاگ یا کتابی که بیست سال پیش منتشر شده را به یاد شما می‌آورد، اخم نکنید. این مسأله طبیعی است. این فنون انحصاراً متعلق به 37Signals نیست. ما فقط به شما می‌گوییم که چگونه کار خود را انجام می‌دهیم و چه چیزهایی برای ما مفید و سودمند بوده است.
اگر لحن کلام ما تلخ است با ما باشید. ما معتقدیم که ارایه جسورانه ایده‌ها بهتر از بی‌اعتنا بودن نسبت به آن‌ها است. اگر متکبرانه و خودخواهانه به نظر می‌رسد، باشد. ما‌ترجیح می‌دهیم محرک و تأثیر گذار باشیم تا این که با گفتن «بستگی دارد ...» هر چیزی را از اهمیت بیندازیم. یقیناً در برخی مواقع این قوانین باید بسط یابند یا نقض شوند. و برخی از این فنون در موقعیت شما به کار نیاید. خودتان در این مورد داوری کنید.
شما فکر می‌کنید برای واقعی شدن بسیار بزرگ هستید؟ حتی Microsoft هم واقعی شده است (و ما شک داریم که شما از آن‌ها بزرگ‌تر باشید).
حتی اگر شرکت شما برنامه‌های زمانی طولانی مدت یا گروه‌های بزرگی دارد باز هم راه‌هایی برای واقعی شدن وجود دارد. اولین قدم شکستن آن‌ها به واحدهای کوچکتر است. زمانی که افراد زیادی درگیر شوند هیچ کاری انجام نمی‌شود. هر قدر که شما لاغرتر و کوچکتر باشید کارها سریع‌تر و بهتر انجام می‌شود. موافقیم که نیاز به رفتار فروشندگی دارد. فرایند واقعی شدن را در شرکت خود مطرح کنید. این کتاب را به آن‌ها نشان دهید. نتیجه‌های واقعی را که می‌توانید در زمان کمتر و تیم کوچکتر به آن‌ها دست یابید به آن‌ها نشان دهید.
توضیح دهید که واقعی شدن روشی کم خطر و کم سرمایه‌بر برای آزمودن مفاهیم جدید است. برای اثبات این مدعا بهتر است پروژه‌های بزرگ را به پروژه‌های کوچک‌تری بشکنید و نتایج را به آن‌ها نشان دهید.
یا اگر واقعاً می‌خواهید بی باک باشید، در خفا حرکت کنید. بیرون از دید رادار حرکت کنید و نتایج واقعی را به آن‌ها نشان دهید. این روشی است که گروه Start.com در Microsoft برای واقعی شدن پیش گرفتند. Robert Scoble فنی‌نویس Microsoft می‌گوید: «من کار گروه Start.com را دیدم. آن‌ها اجازه نمی‌گیرند. آن‌ها رئیسی دارند که پوشش هوایی را برای محافظت آن‌ها فراهم می‌کند و آن‌ها در هر لحظه به چیزهای کوچک ناخنک می‌زنند و به بازخوردها پاسخ می‌دهند».
عرضه Start.com متعلق به Microsoft
در شرکت‌های بزرگ فرایندها و ملاقات‌ها تبدیل به هنجار شده‌اند. با هدف رسیدن به توافق درباره چیزهای «مناسب» برای کاربر، چندین ماه صرف برنامه ریزی ویژگی‌ها و بحث بر روی جزئیات می‌شود.>
این روش شاید بهترین روش برای نرم‌افزارهای بسته‌بندی شده باشد، ولی وقتی با وب سروکار داریم امتیاز بزرگی داریم. شما فقط نرم‌افزار را عرضه کنید. اجازه بدهید کاربر خودش به شما بگوید که آیا نرم‌افزار برای وی مناسب است یا خیر. آهای! اگر بخواهید می‌توانید خطاها را رفع کرده و در همان روز مجدداً نرم‌افزار را عرضه کنید! مهم‌ترین انگیزه برای حضور در جلسات طاقت فرسا و مباحثات، پایداری مشتریان است. فقط عرضه کنید و یک نقطه به جلو حرکت کنید.
سخن گفتن از عمل کردن آسان‌تر است. این مطلب می‌رساند که:
نیازی به برنامه‌ریزی‌های چند ماهه نیست.
ماه‌ها نوشتن ویژگی‌ها لازم نیست. ویژگی‌ها باید بر بنیان‌هایی نهاده شوند که در طول توسعه به دست می‌آیند و جزئیاتی که در طول توسعه فهمیده و اصلاح می‌شوند. هرگز سعی نکنید که تمام مباحث باز و تمام جزئیات را پیش از آغاز توسعه ببندید.
ویژگی‌های کمتر ولی مطلوب را عرضه کنید.
نیازی به روش انفجار بزرگ و عرضه تعداد زیادی ویژگی‌ها در یک زمان ندارید. به کاربر قطعات در‌اندازه یک بایت بدهید که بتواند آن را هضم کند. اگر خطاهای کوچکی وجود دارند نرم‌افزار را به محض آماده شدن طرح اصلی آن، عرضه کنید و رفع خطاها را به تدریج در وب منتشر کنید. هر چه سریع‌تر بازخورد کاربر را بگیرید بهتر است.
ایده‌ها بر روی کاغذ عالی به نظر می‌رسند ولی در عمل غیر بهینه از کار در می‌آیند. هر چه زودتر اشکالات بنیادی ایده‌ها را بیابید بهتر است. یک بار که شما به سرعت تکرار کنید و به بازخوردهای کاربران عکس‌العمل نشان دهید شما با کاربران ارتباط برقرار می‌کنید. به یاد داشته باشید که هدف پیروز شدن کاربر است با ساختن چیزی که آن‌ها می‌خواهند.
Sanaz Ahari مدیر برنامه Start.com در Microsoft
