چرا بیشتر وبسایتها ۹۰ روز بعد از راهاندازی میمیرند
روز راهاندازی بخش ساده کار است. بیشتر سایتها همان روزی شروع به افت میکنند که فاکتور پرداخت میشود — اینجا لایه عملیاتیای را میبینید که نمیگذارد سایت ما اینطور شود.
وضعیت واقعی
یک سایت راهاندازی میشود، همه خوشحالاند، و استودیوی سازنده میرود سراغ پروژه بعدی. سه ماه بعد: فرم تماس شش هفته است که بیصدا از کار افتاده، هیچکس متوجه نشده نیمی از محصولات در نیمی از کانالهای فروش موجود نیست، وبلاگ از هفته راهاندازی دست نخورده مانده، و «پاسخ ظرف ۲۴ ساعت» که روی صفحه اصلی نوشته شده، از هفته دوم دیگر واقعیت ندارد. کسی عمداً دروغ نگفته. کسی اینها را زیر نظر ندارد، چون از اول کسی برای زیر نظر داشتنشان استخدام نشده — قرارداد برای راهاندازی بود، نه برای ۸۷ روز بعدش.
این الگو را از نزدیک میشناسیم: خود سایت ما، پیش از این بازسازی، دقیقاً همین بود. فرم تماس به هیچجا ارسال نمیشد. فوتر چهار ستون لینک مرده داشت. ربات گفتوگو فقط با یک اسکریپت از پیش نوشتهشده و ثابت حرف میزد. آمار روی صفحه اصلی ساختگی بود. کسی قصد فریب نداشت — سایت فقط بدون اینکه کسی مسئول صداقتش باشد، به حال خودش رها شده بود.
چه کاری کردیم
همین سایت — orbitalwebstudio.com — را بهعنوان اولین پروژه واقعی بازسازی کردیم، طی نه جلسه ساخت که در گزارش داخلی خودمان ثبت شده. بهجای اینکه سایت را تحویل بدهیم و برویم، هر بخش عملیاتی سایت، بهجای اینکه به حافظه یک نفر بسپاریم، به یک عامل خودکار و مشخص سپرده شد:
- Dispatch لحظه ورود هر سرنخ، امتیازدهی و مسیریابیاش میکند — بهجای اینکه منتظر بماند کسی صندوق ورودی را چک کند.
- Scribe توالیهای ایمیل را میفرستد، محتوای رایگان را تحویل میدهد، و برای هر صفحه یک تصویر OG تازه میسازد — نه یک اسکرینشات قدیمی که از روز راهاندازی در پوشه عمومی مانده باشد.
- Sentinel سلامت هر یکپارچهسازی (پایگاهداده، سرویس ایمیل، فیلتر اسپم، وبهوک رزرو، سرویس پیامک) را چک میکند و مواردی را گزارش میدهد که واقعاً خراباند، نه آنهایی که فرض میکنیم سالماند.
- Analyst رویدادهای واقعی پشت هر عدد داشبورد را ثبت میکند، تا «مشترک تأییدشده» و «سرنخ واجد شرایط» پرسش از داده واقعی باشند، نه عددی که کسی از یک اکسل به خاطر دارد.
معرفی کامل این تیم — هرکدام چه چیزی را زیر نظر دارند و کجا کار را به یک انسان میسپارند — در صفحه معرفی عاملها.
عدد این پست
صفر — تعداد آماری ساختگی و غیرقابلراستیآزمایی که بعد از ممیزی صداقت در جلسه سوم، در کل کدبیس این سایت باقی مانده. هر ادعایی که روی orbitalwebstudio.com میخوانید، اکنون به چیزی قابلجستوجو یا یک پرسوجوی واقعی در پایگاهداده برمیگردد. مکانیزم واقعی «خودکفا بودن» همین است: نه اینکه هیچ کاری نیاز به انسان ندارد، بلکه اینکه افت کیفیت را یک فرآیند مشخص میگیرد، نه شکایت یک مشتری سه ماه بعد.
این را برای خودتان هم انجام دهید
نیازی نیست دقیقاً همین زیرساخت را داشته باشید. پیش از راهاندازی بعدیتان، برای هرکدام از اینها، بهصورت مکتوب مشخص کنید چه کسی یا چه چیزی مسئول است، و «خرابشدن» برایش دقیقاً یعنی چه:
- هر فرم روی سایت: آیا ارسال فرم واقعاً به یک پایگاهداده میرسد، و اگر ظرف یک ساعت متوقف شود، کسی مطلع میشود؟
- هر یکپارچهسازی بیرونی (پرداخت، ایمیل، رزرو، گفتوگو): آیا یک بررسی سلامت واقعی دارید، یا فقط چون کسی شکایت نکرده فرض میکنید سالم است؟
- هر آماری روی صفحه اصلی: آیا امروز میتوانید همان عدد را از داده واقعی دوباره بسازید؟ اگر نه، پیش از اینکه مشتری متوجه شود، حذفش کنید.
- تقویم محتوا: آیا واقعاً یک ریتم مشخص با یک مسئول مشخص دارد، یا وبلاگ همان هفته بعد از راهاندازی ساکت میشود؟
اگر جواب هرکدام «هیچکس» بود، همانجاست که افت کیفیت شروع میشود.
ادامه ماجرا
این همان ایده پشت اشتراک عملیاتی و کل مدل تیم عاملهاست — ببینید یک ساخت خودکفا واقعاً چه شکلی است، یا بقیه گزارش ساخت را بخوانید.
چکلیستی برای پروژه خودتان میخواهید؟
بگویید روی چه چیزی کار میکنید — ظرف ۴۸ ساعت با یک طرح اولیه معماری پاسخ میدهیم.
پست بعدی: به گزارش ساخت خوش آمدید: اینجا واقعاً چه چیزی منتشر میکنیم