فصل ۴: اولویت‌ها

ایده اصلی چیست

بین خودتان و شرکت‌های بزرگ با شخصی بودن و دوستانه بودن تفاوت بگذارید

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

این دورنما در تصمیم‌گیری‌ها به شما کمک می‌کند و شما را در مسیری سازگار قرار می‌دهد. هر زمان که مشکلی پیش می‌آید بپرسید: «آیا ما همچنان بر دورنما مانده‌ایم؟»

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

برای Basecamp، به عنوان مثال، دورنمای ما « مدیریت پروژه برقراری ارتباط است» بود. ما قویاً حس می‌کردیم که ارتباط مؤثر در پروژه به مالکیت، درگیر شدن، سرمایه‌گذاری و نیروی محرک جمعی هدایت می‌کند. همه را بر سر یک میز و در حال کار بر روی یک هدف مشترک می‌نشاند. ما می‌دانستیم اگر Basecamp این کار را انجام دهد بقیه از دور خارج می‌شوند.

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

فلسفه تخته سفید

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

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

Dave Thomas از The Pragmatic Programmer

رسالتی داشته باشید

شرکت‌ها نیاز به دکل‌های دیدبانی دارند. به برنامه نیاز دارند؛ کارمندان باید هر روز صبح که از خواب بیدار می‌شوند بدانند که برای چه سر کار می‌روند. برنامه باید کوتاه و جذاب و شامل همه چیز باشد: برای چه وجود داری؟ انگیزه‌ات چیست؟ من آن را رسالت می‌نامم، عبارتی سه یا چهار کلمه‌ای که علت وجود شما را توضیح می‌دهد.

Guy Kavasaki نویسنده، نقل از Make Mantra

در ابتدا خطاها را نادیده بگیرید

از بزرگ به کوچک کار کنید

ما شیفته جزئیات‌ایم.

موفقیت و رضایت در جزئیات است.

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

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

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

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

شیطان در جزئیات است

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

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

از بزرگ به کوچک کار کنید، همیشه!

Patrick Lafleur، از Creation Object Inc. به نقل از Signal vs. Noise

وقتی چیزی مشکل است که واقعاً مشکل باشد

وقت خود را برای مشکلاتی که هنوز وجود ندارند هدر ندهید

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

حالا بسازید تا بعد

مردم غالباً وقت خود را مصروف مشکلاتی می‌کنند که در حال حاضر حتی وجود ندارند. این کار را نکنید. ببینید، ما Basecamp را بدون توانایی صدور صورتحساب عرضه کردیم. به دلیل این که صدور صورتحساب‌های نرم‌افزار دوره‌های یک ماهه بود، می‌دانستیم که یک فاصله سی روزه فرصت داریم. ما از این زمان برای رفع مشکلات مهم‌تری استفاده کردیم و بعد از عرضه نرم‌افزار، به سراغ صدور صورتحساب رفتیم. به خوبی کار کرد (ما را مجبور کرد که راه حلی ساده و بودن چیزهای زائد بیابیم).

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

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

مشتریان واقعی خود را بیابید

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

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

اگر شما بخواهید رضایت همه را جلب کنید رضایت هیچ کسی جلب نمی‌شود.

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

بهترین تصمیمی که گرفتیم

تصمیم‌گیری درباره محدود کردن بازار هدف Campaign Monitor به بازار طراحی وب، بهترین تصمیمی بود که گرفتیم. به ما اجازه داد که به سادگی بفهمیم کدام ویژگی‌ها ذاتاً کاربردی هستند و مهم‌تر از آن این که چه ویژگی‌هایی را باید رها می‌کردیم. با هدف‌گیری گروه کوچکی از افراد، نه تنها مشتریان زیادی به دست آوردیم، بلکه این مشتریان نیازهای مشابهی داشتند که کار ما را بسیار آسان‌تر می‌کرد.

انبوهی از ویژگی‌ها در Campaign Monitor وجود دارد که فقط به درد طراحان وب می‌خورد.

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

David Greiner مؤسس Campaign Monitor

مقیاس را به بعد موکول کنید

شما هنوز مشکلات مقیاس پذیری ندارید

«آیا نرم‌افزار من وقتی که میلیون‌ها نفر از آن استفاده کنند پاسخگو خواهد بود؟»

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

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

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

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

به هر حال شما باید بازنگری کنید

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

Dare Obasanjo از Microsoft (نقل از Scaling Up and Startups)

نرم‌افزاری خودرأی بسازید

نرم‌افزار شما باید جانبدار باشد

بعضی‌ها استدلال می‌کنند که نرم‌افزار باید بی‌خدا باشد. می‌گویند که کمال گستاخی است که توسعه‌دهندگان ویژگی‌ها را محدود کنند یا درخواست‌های مربوط به ویژگی‌ها را نادیده بگیرند. می‌گویند نرم‌افزار تا جایی که امکان دارد باید منعطف باشد.

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

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

مثالی عالی، طراحی اولیه ویکی (Wiki) است. Ward Cunningham و دوستانش تعمداً ویکی را از تعداد زیادی ویژگی‌ها -که در گذشته به عنوان اجزای اصلی همکاری بر روی اسناد تلقی می‌شد- عاری کردند. به جای این که هر تغییر در سند را به یک نفر نسبت دهند، علائم مربوط به مالکیت را از اسناد حذف کردند. آن‌ها محتوا را بدون افراد و بی‌زمان کردند. آن‌ها به این نتیجه رسیدند که مهم نیست متن را چه کسی نوشته یا در چه زمانی نوشته است. تمام تفاوت از اینجا آغاز شد. این تصمیم حسی اجتماعی مبنی بر اشتراک را گسترش داد و عامل اصلی موفقیت Wikipedia شد.

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