خزش دامنه به لحاظ نظری ترسناک است، اما در عمل می‌تواند به یک کابوس تبدیل شود.
تاکنون درباره‌ی اینکه خزش دامنه چیست و چگونه می‌توان آن را مدیریت کرد با شما صحبت کرده‌ایم. اکنون زمان آن رسیده است تا مثال‌هایی از دنیای واقعی برایتان مطرح کنیم. به سراغ مالکان کسب‌وکارها و مدیران پروژه رفته‌ایم تا پاسخ یک پرسش ساده را به‌دقت درآوریم:
آیا می‌توانید درباره تجربه‌تان در برخورد با خزش دامنه و چیزی که از این تجربه یاد گرفتید برای ما صحبت کنید؟
از میان پاسخ‌های به‌دست‌آمده بهترین پاسخ‌ها را برایتان انتخاب کرده‌ایم تا بدانید در دنیا تنها کسی نیستید که با مشکل خزش دامنه مواجه شده است.
خزش دامنه را پیش‌بینی کنید و سپس آن را Upsell کنید.
کیل وایت که یکی از مدیران اجرایی شرکت وری‌کانکت است، در دوران کاری‌اش بارها و بارها با مشکل خزش دامنه برخورد داشته است. او به یمن این مواجهه‌ها متوجه شده است که خزش دامنه بهترین روش برای کاهش دادن درخواست‌های خیلی جزئی و وسواسی و شروع کردن به جمع‌آوری اطلاعات پیش از آغاز پروژه است.
«ما همیشه مفهوم و مشکل خزش دامنه را در آغاز پروژه برای مشتری‌ها و دیگر بخش‌های سازمانمان (بازاریابی و تیم پشتیبانی) توضیح می‌دهیم. با آماده کردن ذهن افراد در آغاز کار، می‌توان در میانه‌ی کار که درخواست‌ها اضافه می‌شوند به‌راحتی آن‌ها را توجیه کرد که با چه مشکلی روبه‌رو هستیم. باید به مشتری توضیح داده شود که این یک مشکل دو‌طرفه است و حتی اگر در بودجه‌ی مورد نیاز برای انجام کار پیش‌بینی‌های لازم برای آن صورت گرفته باشد باز هم باعث تأخیر در تحویل پروژه می‌شود.»
زمانی که منابع محدود است یک راه‌حل سریع اما شلخته را انتخاب کنید.
برای دیوید آتراد که مدیر تولید در شرکت کلکتیو ری است، خزش دامنه مشکلی است که به صورت روزانه با آن دست‌و‌پنجه نرم می‌کند. از آنجا که او معمولا در گروه‌های استارتاپی حضور دارد، می‌داند که برخی منابع مانند زمان بسیار کمیاب هستند، درنتیجه ترجیح می‌دهد که «سریع‌ترین راه برای انجام کارها» را انتخاب کند.
«هر روز در وضعیتی قرار داریم که می‌توانیم چندین روش را برای ایجاد یک ویژگی یا کارکرد خاص انتخاب کنیم. به طور کلی می‌توان کارها را به دو صورت انجام داد: روش سریع که درست کار می‌کند و به سرعت ایجاد می‌شود و روش ایده‌آل که همه‌ی ریزه‌کاری‌ها و نکات را دیده است اما سه برابر بیشتر از حالت سریع زمان می‌برد. در دنیای ایده‌آل باید بهترین روش برای انجام کار را انتخاب کرد. اما مشتری‌ها معمولا می‌خواهند کارشان سریع انجام شود تا سریع رشد کنند. در اینجا است که ترجیح می‌دهم از روش سریع استفاده کنم. برای مثال در یک پروژه می‌خواستیم یک فرایند ورود را طراحی کنیم که در آن امکان ورود مستقیم از صفحه‌ی فرود برای مشتری فراهم شود. در یکی از روشها لازم بود یک صفحه‌ی لندینگ و یک بک‌اند بسازیم تا بتوانیم سایر بخش‌های لازم را اضافه کنیم. اما یک روش سریع و شلخته‌تر وجود داشت که در آن بخش‌های مورد نیاز به صورت خودکار و براساس قوانین از پیش تعریف شده تولید می‌شدند. اگرچه راه‌حل دوم ایده‌آل نبود اما این امکان را فراهم می‌کرد که محصول را سریع‌تر تولید کنیم، درنتیجه آن را انتخاب کردیم.
روش‌های سریع و شلخته تنها زمانی انتخاب می‌شود که منابع اندک باشند. درنهایت هنگامی که افراد بیشتری به خدمت گرفته شدند و اوضاع مالی بهتر شد، یا زمانی که روندهای اولیه با مشکل روبه‌رو شدند می‌توان این بخش‌ها را از نو و به شکل مناسب طراحی کرد.»
روش قیمت‌گذاری ساعتی را با روش قیمت‌گذاری پروژه‌ای اشتباه نگیرید.
به نظر رابرت مک‌گوایر، موسس شرکت نیشن ۱۰۹۹، خزش دامنه زمانی اتفاق می‌افتد که انجام یک پروژه مستلزم ترکیبی از فعالیت‌های مختلف باشد که به شیوه‌های متفاوت، ساعتی یا پروژه‌ای، قیمت‌گذاری می‌شوند. هنگامی که این دو روش قیمت‌گذاری باهم ترکیب شوند، انتظارات طرفین قرارداد با هم متفاوت خواهد شد.
«بهترین روش برای جلوگیری از این مشکل این است که یک سند کاملا روشن برای دامنه‌ی کارها داشته باشید. همچنین باید مشخص کنید که «تحویل پروژه» به چه معنا است. در این صورت زمانی که مشتری از شما بخواهد کارهای بیشتری برایش انجام دهید، به‌طور کاملا قطعی می‌توانید به او بگوید آیا بودجه‌ای برای انجام این کار باقی‌مانده است یا خیر. اگر بودجه موجود باشد ابتدا با مشتری توافق می‌کنید که کارهای کم‌تری از چیزی که در ابتدا برنامه‌ریزی شده بود انجام شود و سپس بودجه را به شکلی متفاوت خرج می‌کند. اما اگر بودجه باقی نمانده باشد آن‌ها درواقع درخواست خزش دامنه را دارند. درنهایت مطمئن شوید که هزینه‌ی خدمات اضافی‌ای را که ارائه می‌کنید براساس مبنای درستی محاسبه کرده‌اید.»
یک استراتژی دیگر که در چنین شرایطی کمک زیادی به شما می‌کند، این است که مطمئن شوید قراردادتان بند‌های لازم را برای پرداخت‌های اضافی و پرداخت‌های جاری دارد. اگر در مرحله‌ی استارتاپ کار قرار دارید کمی پول برای این بخش کنار بگذارید و هر ماه صورت‌حسابی برای مشتری بفرستید که نشان دهد تاکنون چه کارهایی انجام شده است. هنگامی که به صورت مداوم به مشتری یادآوری می‌کنید که سر چه موضوعاتی با هم توافق کرده‌اید و آن‌ها برای چه مواردی پول پرداخت کرده‌اند، متوجه خواهند شد که درخواست‌های جدید‌شان درواقع یک سفارش کار جدید است.
روی اولویت‌های حد وسط تمرکز کنید
سرجیو فلورس که اکنون مالک محصول اسمارت فراگ است، در گذشته با استارتاپ‌های زیادی کار کرده است. در یکی از پروژه‌ها او به‌شدت با مشکل خزش دامنه درگیر شده بود: مدیران اجرایی شرکت نسبت به پتانسیل‌های پروژه بسیار هیجان‌زده بودند و قصد داشتند آن را با توجه به ویژگی‌های تازه بهبود ببخشند. خیلی زود اشتیاق زیادشان فروکش کرد و از طولانی شدن کار خسته شدند.
«رویکرد من برای مدیریت کردن این مشکل این بود که با مدیران اجرایی جلسه گذاشتم و آن‌ها را تشویق کردم یک محصول فوق‌العاده با ویژگی‌هایی که مد نظرشان است بسازند اما روی اولویت‌های حد وسط تمرکز کنند. متقاعد کردن آن‌ها کار ساده‌ای نبود، اما در نهایت موفق شدم با مقایسه کردن نتایجی که از یکی از محصولاتمان که در گذشته به بازار معرفی کرده بودیم با محصولاتی کنونی که ویژگی‌های بسیار بیشتری داشتند، بر این مشکل نیز غلبه کنم. استدلال اصلی من این بود که در محصولات قدیمی ما نادانسته روی اولویت‌های حد وسط تمرکز کرده بودیم و به موفقیت خوبی دست پیدا کردیم، اکنون نیز می‌توانیم با استفاده از همین استراتژی به موفقیت‌های بزرگی دست پیدا کنیم و رقبا را کنار بزنیم. شگفت‌آور است، اما زمانی که اولویت‌های حد وسط تعریف می‌شود، حس هدفمندی تازه‌ای در تیم ایجاد می‌شود. پس از این نیز بارها در چنین وضعیتی قرار گرفتم اما با تأکید بر اهمیت محصول در درازمدت و تمرکز کردن روی اولویت‌های حد وسط موفق شدم جلوی خزش محدوده را بگیرم.»
تغییرات باعث می‌شوند که خزش دامنه به شکلی نمایی رشد کند نه خطی
استنلی تن که اکنون یک مدیر بازاریابی دیجیتال در سلبای است، اولین تجربه‌اش از خزش دامنه را در اولین پروژه‌ی توسعه‌ی نرم‌افزارش به‌دست آورده است. تیم او قصد داشت یک نرم‌افزار برای کار سئو طراحی کند که روی گزارش‌دهی تمرکز داشته باشد.
«با وجود اینکه هدف اولیه ساختن ابزاری برای ایجاد گزارش برای کار سئو بود، وضعیت خیلی سریع از کنترل خارج شد. پیش از اینکه متوجه شوم ما ابزاری برای مدیریت وظایف ساخته بودیم و پس از آن یک قالب سیستم برای مشخص کردن وظایف در پروژه‌های تکراری ایجاد شد. سپس یک مدیر بک‌لینک و پس از آن نیز داشبورد مشتری ساخته شد.
هر ویژگی‌ای که اضافه می‌گردیم باعث ایجاد اشکالات بیشتری می‌شد و به جایی رسیدیم که هر روز کارمان مختل می‌شد. به‌جای اینکه یک ابزار فوق‌العاده بسازیم که به‌خوبی کار کند، خود را در مخمصه انداخته بودیم. وقتی به گذشته نگاه می‌کردیم، می‌دیدیم که اقدامات تکنیکی لازم در هر مرحله را برای کم کردن خطاها انجام نداده بودیم. بسیاری از مدیران متوجه این خطا نیستند که ایجاد تغییرات پی‌درپی باعث می‌شود خزش محدوده به شکلی نمایی رشد کند و نه خطی. برای مثال:
- اگر ایجاد یک تغییر ۳۰ دقیقه طول بکشد.
- ایجاد دو تغییر ۷۰ دقیقه طول خواهد کشید نه ۶۰ دقیقه (۳۰ دقیقه + ۳۰ دقیقه)
- و ایجاد ۱۰ تغییر ۱۰۰۰ دقیقه طول خواهد کشید نه ۳۰۰ دقیقه (۳۰ دقیقه x ۱۰)
هر چه یک پروژه بیشتر طول بکشد، بنیان آن توسعه‌ی بیشتری پیدا خواهد کرد. دیر یا زود یک تغییر باعث ایجاد خزش دامنه در همه‌ی ابعاد می‌شود و سایر بخش‌های پروژه را نیز تحت تأثیر قرار خواهد داد.
تا روز Xx خزش محدوده نداشته‌ایم
بهترین توصیه را برای آخر مقاله نگه داشته‌ایم. شرولین سلرز، مؤسس و مدیرعامل گروه اجرایی پایوتال برای ما توضیح می‌دهید که چگونه خزش دامنه را به بهترین شکل ممکن مدیریت کنیم. داستان او را به طور کامل برایتان توضیح می‌دهیم.
«هنگامی که پروژه‌ها را مدیریت می‌کنم، زمان زیادی را صرف می‌کنم تا پاسخ پرسش‌های لازم را به‌دست بیاورم. این پرسش‌های را مطرح می‌کنم تا به درستی بفهمم محرک‌های پروژه چه هستند، چرا این پروژه در دستور کار قرار گرفته است، منابع مالی آن چگونه تأمین می‌شود و چه اولویت‌هایی را دنبال می‌کند. سعی می‌کنم بفهمم انتظارات اسپانسر‌ها و مشتری‌ها چیست. پس از اینکه فهم لازم را به‌دست آوردم، همه‌ی منابع لازم برای انجام پروژه را گرد هم می‌آورم و از مدل هوشمند استفاده می‌کنم تا تصویر روشنی از اینکه خروجی کار چه خواهد بود فراهم شود.
همچنین جمع‌آوری مستندات را تا جایی ادامه می‌دهم که به‌روشنی بدانم خروجی کار چه چیزی خواهد و چه چیزی نخواهد بود و این اطلاعات را با ذی‌نفعان کلیدی به اشتراک می‌گذارم. سپس این محدوده را به‌عنوان مبنای کار قرار می‌دهیم و هر چیزی که از این تاریخ به بعد تغییر کند وارد فرایند کنترل تغییرات می‌شود.»
شرولین اضافه می‌کند اگرچه این فرایند ۱۰۰ درصد تضمین نمی‌کند که پروژه دچار خزش دامنه نمی‌شود، اما گام بزرگی در جهت کاهش دادن احتمال وقوع آن است. برای انجام دادن این کار باید یک طرح بازی را پیاده‌سازی کرد.
«در پروژه‌های فنّاوری خزش دامنه معمولا توسط اعضای تیم توسعه انجام می‌شود که هنگام تکمیل کردن الزامات جدید، تغییرات سریع در کد‌ها ایجاد می‌کنند. من ابتدا فرد خطاکار را پیدا می‌کنم تا بفهمم چه محدوده‌ای اضافه شده است. سپس تحلیل می‌کنم که این اتفاق چه تأثیراتی رو پروژه داشته است. اما وارد فرایند کنترل تغییرات نمی‌شوم. درنهایت خروجی را با اعضای تیم پروژه و ذی‌نفعانی که در جلسات شرکت می‌کنند به اشتراک می‌گذارم. هدف از انجام این کارها این است که همه از تأثیرات خزش دامنه آگاه شوند و جلوی رخ دادن دوباره‌ی آن گرفته شود. این کار بسیار مؤثر است (من هیچ نامی از فرد خطاکار نمی‌برم، اما آن‌ها همیشه خودشان می‌دانند که خطا از جانب آن‌ها سر زده است.)»
شرولین در نهایت یک روش نامتعارف برای جلوگیری از خزش دامنه به ما معرفی می‌کند.
«یک‌بار که در یکی از پروژه‌های شرکتی که به خاطر خزش دامنه بسیار بدنام بود کار می‌کردم، تیم ما تصمیم گرفت برای مقابله با خزش دامنه رفتاری غیرمتعارف از خودش نشان دهد. درست مانند محیط کار که در آن ایمنی یک عنصر کلیدی محسوب می‌شود (برای مثال کارخانه‌ها) و پیام‌هایی مانند «تا روز xx حادثه‌ای نداشته‌ایم» در محل انجام کار نصب می‌شود، ما نیز در صفحه‌ی فرود مربوط به سایت کنترل پروژه یک پیام تصویری قرار دادیم که روی آن نوشته شده بود «تا روز xx خزش دامنه نداشته‌ایم». این یک روش بامزه برای تمرکز مستمر روی خزش دامنه در پروژه بود که هم‌زمان روند انجام کارها را نیز دنبال می‌کرد.»
نتیجه
برخی از خزش دامنه‌ها ممکن است آزاردهنده باشند، اما اگر به شکلی مناسب مدیریت شوند می‌توان از تبدیل شدن آن‌ها به یک کابوس جلوگیری کرد. مطمئناً روش‌های زیاد دیگری نیز برای مدیریت کردن خزش محدوده وجود دارد که در کسب‌وکارهای مختلف می‌توان از آن‌ها بهره گرفت.
