پرش به محتویات

احتیاط‌ها، سلب مسئولیت‌ها و پیشگیری‌های لازم

برای اینکه همین اول راه تکلیف روشن شود، این‌ها پاسخ ما به چند گلایه‌ای است که هر از گاهی می‌شنویم:

«این تکنیک‌ها برای من جواب نمی‌دهد.»

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

اما قضیه همه یا هیچ نیست. حتی اگر نتوانید Getting Real را کامل بپذیرید، حتماً چند ایده در این کتاب هست که بتوانید از کنار قدرت‌های مستقر رد کنید.

«این ایده را شما اختراع نکرده‌اید.»

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

«خیلی سیاه و سفید نگاه می‌کنید.»

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

«این داخل شرکت من جواب نمی‌دهد.»

فکر می‌کنید برای Getting Real زیادی بزرگ هستید؟ حتی Microsoft هم Getting Real کار می‌کند، و بعید می‌دانیم شما از Microsoft بزرگ‌تر باشید.

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

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

توضیح دهید Getting Real راهی کم‌ریسک و کم‌هزینه برای آزمودن مفهوم‌های تازه است. ببینید می‌توانید برای اثبات ایده، از کشتی مادر جدا شوید و پروژه‌ای کوچک‌تر را مستقل جلو ببرید. نتیجه را نشان دهید.

یا اگر واقعاً جسارت دارید، مخفیانه پیش بروید. زیر رادار حرکت کنید و نتیجه واقعی بسازید. تیم Start.com همین رویکرد را هنگام Getting Real در Microsoft به کار برد. Robert Scoble، Technical Evangelist در Microsoft، می‌گوید: «من کار تیم Start.com را دیده‌ام. اجازه نمی‌گیرند. مدیری دارند که برایشان پوشش هوایی فراهم می‌کند. هر بار تکه کوچکی را برمی‌دارند، انجامش می‌دهند و به بازخورد پاسخ می‌دهند.»

عرضه Start.com در Microsoft

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

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

گفتنش خیلی آسان‌تر از انجام دادنش است. یعنی:

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

قابلیت‌های کمتر، اما باکیفیت عرضه کنید.
به رویکرد big bang با نسخه‌ای کاملاً تازه و انبوهی قابلیت نیاز ندارید. تکه‌های کوچک و قابل‌هضم به کاربر بدهید.

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

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

—Sanaz Ahari، Program Manager در Start.com، Microsoft


منبع اصلی: Caveats, disclaimers, and other preemptive strikes