پروژه‌های علم داده: چگونه قبل از نوشتن حتی یک خط کد، شکست بخوریم؟

فرض کنیم شرکت شما تصمیم گرفته است با استفاده از علم داده و یادگیری ماشین به یک مشکل تجاری رسیدگی کند. فرض کنیم شما یک تیم قدرتمند مجهز به آخرین الگوریتم‌ها را در اختیار دارید و می‌خواهید به این گروه کاملاً آزادی عمل بدهید. پیش خودتان می‌گویید: «حالا وقتشه داده واسمون معجزه کنه!» حالا می‌پرسیم: چه مشکلاتی ممکن است بر سر راه شما سبز شود؟ باید از قبل بدانید که کار با داده به این راحتی‌ها هم نیست. بدون برنامه، حتی خبره‌ترین دانشمندان داده هم ممکن است گمراه شوند. بدون برنامه، پروژهٔ داده‌ای شما، حتی قبل از نوشتن یک خط کد، محکوم به شکست خواهد بود.

برای اینکه از این سرنوشت محتوم فرار کنید، پیش از آغاز یک پروژهٔ علم داده و یادگیری ماشین، باید حواستان جمع این شش نکته باشد که بالقوه می‌تواند هر پروژه‌ای را به شکست بکشاند:

هرکدام از ابعاد مطرح شده در نمودار بالا، نشان‌دهندهٔ ملاحظات کلیدی‌ای است که باید به آنها توجه کرد. پاسخ نادرست به هرکدام از این موارد، چه‌بسا سبب شکست کل پروژه شود. در ادامه تلاش می‌کنم با مثال‌هایی نشان دهم که پاسخ نادرست به این مسائل، چگونه ممکن است سبب شکست پروژه شود. در خلال بررسی این مثال‌ها به درک بهتری از این امر خواهیم رسید که برنامه‌ریزی درست دقیقاً یعنی چه.

نکتهٔ اول: ارزش کسب‌وکار

راه درست این است که پیش از آغاز پروژهٔ علم داده، باید شفافِ شفاف بدانید که این پروژه قرار است چه ارزشی به شرکت شما اضافه کند؛ اما با توجه ‌به سنت دیرپای «اول شلیک، سپس نشانه‌گیری» (RFA) بسیاری از شرکت‌ها قبل از اینکه چرخ کسب‌وکارشان را به حرکت درآورند، یادشان می‌رود که ابتدا باید مقصد نهایی را تعریف کنند. برای اجتناب از این امر، ابتدا مشخص کنید که دلتان می‌خواهد که کدام شاخص‌های کلیدی عملکرد (KPI) تغییر کنند و پیش از آغاز پروژه، ارزش تجاری این تغییرات را برآورد کنید. اگر هدف شما بهینه‌سازی فعالیت‌های ترویجی (promotions) است، ابتدا از خودتان بپرسید که چقدر قرار است روی این فعالیت‌ها هزینه کنید و چقدر باید تلاش کنید تا فروش یا سود شما به صورت روزافزون افزایش یابد. اگر متوجه شدید که سود یا فروش اضافهٔ اندکی ممکن است از این راه عایدتان شود، پس به‌احتمال خیلی زیاد، هزینهٔ پروژه بیش از عایدی آن خواهد بود: در این صورت در وهلهٔ اول از خود بپرسید: اصلاً چرا باید این پروژه را انجام داد؟

به سنجه‌های معینی که می‌خواهید بهبود ببخشید و به‌اندازهٔ تأثیری که از یک پروژه انتظار دارید، به‌دقت فکر کنید. تنها به این بسنده نکنید که خیلی کلی بگویید من انتظار «۵ درصد سود بیشتر» دارم. هر چقدر می‌توانید دقیق باشید. به‌جای اظهارات کلی‌، مانند اینکه می‌خواهم پروموشن‌های خرده‌فروشی (retail promotions) داشته باشم، به جزئیات دقت کنید.

یا ممکن است بخواهید روی تصمیماتی تمرکز کنید که معمولاً نظارت و تحلیل انسانی چندانی روی آنها وجود ندارد. درست است، در مورد بزرگ‌ترین حساب‌ها می‌توان از تحلیل برای پیش‌بینی خطر ریزش (churn) مشتری استفاده کرد؛ اما اگر نیروهای فروش شما همواره فقط با مشتریان بزرگ در حال صحبت باشند، چگونه باید مطمئن شد که مدل شما چیزی بیشتر از دانسته‌های نیروهایتان به شما عرضه می‌کند؟ در عوض، بهتر است ارزش پروژه را بر اساس اطلاعات کسب شده از کسب‌وکارهای مشتریان کمتر دیده شده و کوچک خود، تخمین بزنید.

نکتهٔ دوم: تأثیر فرایندهای کسب‌وکار

چیزی که باید به آن توجه کنید این است که بفهمید نتایج پروژهٔ تحلیل داده قرار است چه تصمیم‌هایی را تحت‌الشعاع قرار دهد و نیز دریابید که آیا نتایج پروژهٔ تحلیل دادهٔ شما، اطلاعاتی را که راهنمای کارکنان مرکز تماس شما است، تغییر خواهد داد یا خیر. فرض کنیم شرکتی می‌خواهد به موضوع ریزش مشتری، اعم از مشتری کوچک یا بزرگ، رسیدگی کند. تیم علم داده، برای بررسی این موضوع، شروع به ساخت مدلی می‌کند که می‌تواند پیش‌بینی کند که تا ۳ ماه آینده، کدام مشتری‌ها در معرض ریزش هستند. نتایج این مدل به طور منظم در اختیار کارشناسان حفظ مشتری‌ها (retention specialists) قرار می‌گیرد، یعنی در اختیار کسانی که به تماس‌های درخواست لغو مشتریان، پاسخ می‌دهند و می‌کوشند آنها را حفظ کنند.

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

در یکی از پروژه‌های مربوط به پروموشن مشتریان ما به مشکل عدم تطابق طراحی پروژه با اهداف تجاری برخوردیم. در ابتدای پروژهٔ مربوط به جلوگیری از ریزش مشتری، ما به سوابق تلاش‌های قبلی شرکت برخوردیم، یعنی به تلاش‌های قبلی برای ایجاد مدلی به‌منظور پیش‌بینی تأثیر فعالیت‌های پروموشن بر نرخ ریزش مشتری. مدل پیشنهادی قبلی بسیار دقیق بود و رابط کاربری (user interface) فوق‌العاده‌ای داشت. می‌شد طرح‌های پروموشن آنلاین فراوانی تهیه کرد و به طور خودکار داده‌های لازم را جمع‌آوری کرد و سپس با فشردن یک دکمه، نتایج را به‌منظور تأیید از طرف مدیران، منتشر کرد.

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

1. این پیشنهادها فاقد شواهد کافی زمینه‌ای (sufficient background evidence) و معقول هستند.
2. در این پیشنهادها برای کاربرهایی که صلاحیت دارند، اجازهٔ بازبینی در نظر گرفته نشده است. برای مثال، اگر تیم بازاریابی بخواهد از استراتژی قیمت‌گذاری پایین برای جذب مشتری (loss leader) استفاده کند، این مدل به عملکرد تیم بازاریابی نمرهٔ پاییینی می‌دهد.
3. از همه بدتر اینکه، برای گرفتن داده‌های لازم از سیستم‌های آی‌تی قدیمی، بنابر قوانین مربوط به این‌دست ابزارها، ابتدا باید برنامه‌های ترویجی منتشر شود. یعنی، این برنامه‌ها در دید مدیر فرد برنامه‌ریز قرار خواهد گرفت. حتی اگر برنامه‌ریز تنها در پی تجربه‌کردن و آزمایش باشد، مدیر او به‌هرحال کار او را مشاهده می‌کند. در مواردی ازاین‌دست، این ابزارها تبعات ناخواسته‌ای دارند که از جملهٔ آنها یکی این است که رفتارهای مثبت را با درنظرگرفتن ملاحظات غیر لازم و غیرضروری، تشویق می‌کند. (مانند، بررسی گزینه‌های بالقوه برای یافتن بهترین فعالیت ترویجی).

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

نکتهٔ سوم: دسترس‌پذیری، کیفیت و حاکمیت داده

همهٔ مدل‌ها، مبتنی بر داده‌اند، اما داده‌ها چیزهای مجرد و در خلأ نیستند. متخصصان خبره خود را مسئول مدیریت خطوط جریان داده (managing pipelines)، مخازن و دریاچه‌های داده می‌دانند. حتی در این صورت هم، داده ارزش خود را از دست می‌دهد. ممکن است از داده‌های مربوط به برخی از عرصه‌ها، برای مدت‌ها استفاده نشده باشد یا آن داده‌ها برای مدتی به‌روز نشده باشند. فرایندهای مربوط به پاک‌سازی داده‌ها (data-hygiene processes) ممکن است برای مدتی اجرا نشده باشند. ممکن است برخی از داده‌ها و فرایندهای معین مربوط به آن داده‌ها به هر دلیلی دچار استهلاک شده باشند، اما چیزی که مهم است این است که مدل‌های شکل‌گرفته بر اساس این دست از داده‌ها محکوم به شکست خواهند بود. پیش از آغاز پروژه‌های داده‌ای باید از سلامت و کامل بودن داده‌ها مطمئن شد، از به‌روز شدن مستمر آنها اطمینان حاصل کرد و نیز باید از تمام تغییرات احتمالی پایگاه داده درک درستی داشت.

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

برای جلوگیری از بروز این اتفاق دو راه وجود دارد:

1. کمک بگیرید: معمولاً متخصصی پیدا می‌شود که می‌تواند نشانه وجود مشکل در داده‌ها را متوجه شود. (معمولاً در بین متخصصان هوش تجاری یا متخصصان مالی این افراد پیدا می‌شوند). باید چنین فردی را در کنار خود داشته باشید و او در کل فرایند به شما کمک کند. ناهنجاری‌ها و داده‌های پرت ، معمولاً حاصل اشتباه نیستند: این نقص‌ها اغلب نتیجهٔ اجرای نادرستِ فرایندی است که به تولید داده منجر شده است.
2. آهسته کار کنید: حداقل ده نمونه، مثلاً ده مشتری، را در نظر بگیرید و تمام داده‌های مربوط به آنها را مرور کنید. در ذهن خود تصور کنید که هرکدام از این مشتری‌ها شبیه چه چیزی هستند، سپس توجیه عقلانی برای یافته‌های خود پیدا کنید. قول می‌دهم از اینکه با اعمال این روش چه مقدار دریافت اولیهٔ شما دگرگون می‌شود، تعجب خواهید کرد. برای مثال، وقتی در حال اجرای یک پروژهٔ داده‌ای برای یک خط هوایی بودیم، متوجه یک ناهنجاری شدیم و آن هم این بود که در بین خریداران بلیت خانواده‌هایی پیدا می‌شد که ۲۰ نفر یا بیشتر جمعیت داشتند! با کمی تحقیق بیشتر، متوجه شدیم که تعدادی از رزروهای گروهی، به اشتباه در بین داده‌های ما قرار گرفته بود.

نکتهٔ چهارم: رویکرد تحلیلی

یادتان باشد، پیش از اینکه تصمیم بگیرید که از کدام الگوریتم استفاده کنید، باید مشخص کنید که از پروژهٔ خود انتظار دارید که چه کارکردی داشته باشد. آیا می‌خواهید فروش خود را به حداکثر برسانید یا می‌خواهید نسبت فروش به فرصت فروش (sales per opportunity) را بیشینه کنید؟ یا اینکه شما به فلان قدر حاشیهٔ سود فکر می‌کنید یا اینکه چه مقدار ارتقا (lift) لازم است که ارزش‌های کسب‌وکار شما برآورده شود؟ پس از اینکه به این امور پرداختید، وقت آن رسیده است که به الگوریتم مناسب فکر کنید.

در یکی از پروژه‌های مربوط به اندازه‌گیری میزان تأثیر روش‌های ترویج (promotional-effectiveness project)، در طرح اولیه، خواسته شده بود که مدلی برای پیش‌بینی حجم فروش به‌ازای هر کالا یا خدمت (sales volume per item) ساخته شود. با این تعریف از مساله، یکی از توابع هدف (Objective Function) اهداف کارکردی می توانست میزان دقت پیش‌بینی‌ها به ازای کالا و در یک هفته معین باشد؛ اما آنچه این کسب‌وکار واقعاً احتیاج داشت، توانایی تشخیص این امر بود که برای هر فقره از کالا و خدمات، چه نوع پروموشنی موردنیاز است.

به طور معمول، این فعالیت‌های ترویجی ممکن است به مدت چند هفته ادامه داشته باشد و از نظر تابع هدف (objective function)، بهتر این بود که ابتدا برای آنها مشخص می‌شد که برای هر کالا یا خدمت به‌خصوص، چه پروموشن‌هایی مناسب‌تر است. (یعنی باید مدلی برای آنها طراحی می‌شد که می‌توانست پیش‌بینی کند که چه قیمتی برای هر کالا به بالاترین سود افزایشی (highest incremental profit) منجر می‌شود؛ البته پس از اینکه ملاحظات اقتصادی مربوط به محصول (product economics) در نظر گرفته می‌شد.

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

نکتهٔ پنجم: بین اهداف و مهارت‌های افراد توازن برقرار کنید!

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

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

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

نکتهٔ ششم: برای اجرای آزمایشی و انجام آزمایش‌ها برنامه‌ریزی کنید!

واضح است که قبل از اینکه مدلی را طراحی کنید باید به نحوهٔ آزمایش آن، فکر کرده باشید. آیا برای آزمایش فلان مدل باید از اعتبارسنجی متقابل (cross-validation) استفاده کرد؟ آیا باید از یک پایلوت  مجازی ترتیب دهید  که در آن کاربران سازمانی (business users) در معرض آزمون قرار می‌گیرند و تصمیم‌های آزمایشی (vet decisions) بر اساس پیشنهادهای مدل طراحی شده، ارائه می‌شود؟ اگر پایلوت شما از داده های عملیاتی و زنده سازمان استفاده می کند، آیا بهتر است در مقیاس کوچک اجرا شود یا مقیاس بزرگ؟

انتخاب شیوهٔ آزمایش به چیزی مربوط می‌شود که به آن «سرعت بازخورد» (speed of feedback) گفته می‌شود. به‌عبارت‌دیگر، شما باید بدانید چقدر زمان خواهد برد که بفهمید که آیا مدل، کار می‌کند یا نه و بر اساس مدل، چقدر زمان خواهد برد که بازخورد تعبیه شده در داده‌های آزمایشی در اختیار شما قرار بگیرد.

در بیشتر موارد، بهتر این است که  یک «حداقل محصول قابل ارائه» (minimum viable product ) بسازید، آن را عرضه کنید و پیوسته و به‌مرور آن را بهبود ببخشید. در برخی موقعیت‌ها بهتر است که چیز کامل‌تری بسازید و سپس آن را عرضه کنید. یک‌بار در حین ایجاد ابزار پشتیبان فروش (sales support tool) برای یک مشتری، سعی کردیم مدل ما دقت زیادی داشته باشد و در این کار حتی شاید زیاده‌روی کردیم؛ اما ما با اینکه می‌دانستیم ساختن مدلی که در همهٔ موارد کاملاً دقیق باشد کار بسیار سختی است، ولی از طرف دیگر، این را هم می‌دانستیم که تیم فروش از تغییرات زیاد خسته شده است. می‌دانستیم اگر ما مدلی بسازیم که تقریباً در همهٔ زمینه‌ها درست عمل ‌کند؛ ولی در درصد کمی از موارد جزئی،‌دارای نقص‌های عملکردی باشد، اعتماد و اطمینان تیم فروش را از دست می‌دهیم. همچنین می‌دانستیم که اگر اطمینان آنها را از دست بدهیم، برای راضی کردن آنها برای دادن یک فرصت دوباره، باید تلاش خیلی زیادی بکنیم. فرض کنید از اکسل استفاده می‌کنید و هر بار نتیجهٔ ۱+۱ می‌شود ۳. چطور ممکن است که شما دوباره به این نرم‌افزار اعتماد کنید؟ اما اینکه یک کمپین فروش لباس، نوع خاصی از لباس را به شما پیشنهاد دهد و شما به نوع دیگری علاقه داشته باشید، اتفاق مهمی نیست. تفاوت موقعیت‌های مختلف هم چیزی ازاین‌دست است.

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

ابتدا فکر کنید و سپس برنامه‌ریزی کنید!

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

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

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