شاید تا حالا اصطلاح «خوردن غذای سگ خود» یا به شکل خلاصه «داگفودینگ» به گوشتون خورده باشه. این عبارت شاید در نگاه اول کمی عجیب و حتی ناخوشایند به نظر بیاد، اما توی دنیای تکنولوژی و کسب و کار، یک مفهوم خیلی جدی و کاربردیه. به طور ساده، داگفودینگ یعنی یک شرکت یا سازمان از محصولات یا خدماتی که خودش تولید میکنه، در کارهای روزمره داخلی خودش هم استفاده کنه. این کار فقط یک جور نمایش یا تبلیغ نیست، بلکه یکی از بهترین روشها برای پیدا کردن ایرادها، بهتر کردن تجربه کاربری و فهمیدن اینه که کاربرهای واقعی با چه چالشهایی روبرو میشن. وقتی یک شرکت خودش مشتری محصول خودش میشه، انگار یک آینه جلوی خودش گذاشته که نقاط ضعف و قوتش رو بدون تعارف بهش نشون میده.
این کار میتونه یک روش برای تست محصول در شرایط دنیای واقعی باشه و به عنوان نوعی کنترل کیفیت عمل کنه. در نهایت هم وقتی محصول به بازار عرضه میشه، این کار مثل یک جور تبلیغ زنده است که نشون میده سازندهها چقدر به محصول خودشون اطمینان دارن. به بیان دیگه، این روش به شرکتها کمک میکنه تا با محصولشون صادق باشن و چیزی رو به مردم نفروشن که خودشون حاضر به استفاده ازش نیستن. این فرآیند باعث میشه که تیمهای توسعه، بازاریابی و فروش، خودشون رو جای کاربر نهایی بذارن و مشکلات رو از دید اونها ببینن.
این اصطلاح عجیب از کجا اومد؟
برای اینکه بفهمیم این عبارت از کجا پیدا شد، باید به چند دهه قبل برگردیم. روایتهای مختلفی در این مورد وجود داره.
وارن هریسون، که سردبیر ارشد مجله «نرمافزار IEEE» بود، در سال ۲۰۰۶ به دو داستان احتمالی اشاره کرد. یکی از اونها به تبلیغات تلویزیونی غذای سگ «آلپو» در دهه ۱۹۷۰ برمیگرده. توی این تبلیغات، بازیگر و سخنگوی معروف، لورن گرین، با اطمینان میگفت که به سگهای خودش هم همین غذای آلپو رو میده. این یک پیام قدرتمند به مشتریها بود که این محصول اونقدر خوبه که حتی چهره تبلیغاتیش هم بهش اعتماد کامل داره.
یک روایت دیگه که هریسون به خاطر داشت، مربوط به رئیس شرکت غذای حیوانات خانگی «کال کان» بود. گفته میشد که این مدیرعامل در جلسات سالانه سهامداران، یک قوطی از غذای سگ شرکت خودش رو باز میکرد و میخورد تا کیفیت و قابل اطمینان بودن محصول رو به همه ثابت کنه. این عمل نمادین، نشون دهنده اوج اعتماد به محصولی بود که شرکت تولید میکرد. در واقع، اون به معنای واقعی کلمه «غذای سگ خودش رو میخورد».
اما ریشهای که بیشتر از همه در دنیای تکنولوژی شناخته شده، به شرکت مایکروسافت و سال ۱۹۸۸ برمیگرده. در اون زمان، پل ماریتز، یکی از مدیران مایکروسافت، ایمیلی به برایان ولنتاین، مدیر تست محصول «Microsoft LAN Manager»، فرستاد که عنوانش این بود: «خوردن غذای سگ خودمان». ماریتز توی این ایمیل، ولنتاین رو به چالش کشید تا استفاده داخلی از این محصول رو در خود شرکت مایکروسافت افزایش بده. از اون زمان به بعد، این اصطلاح به سرعت در تمام شرکت پخش شد و به یک بخش جداییناپذیر از فرهنگ مایکروسافت و بعد هم کل صنعت نرمافزار تبدیل شد. خود پل ماریتز هم در یک سخنرانی در سال ۲۰۰۹ به شوخی گفت که یکی از تنها مشارکتهای اون در دنیای فناوری اطلاعات، ابداع همین عبارت «خوردن غذای سگ خود» بوده و اضافه کرد: «میتونید در این مورد توی ویکیپدیا بخونید، پس حتما درسته».
داگفودینگ در عمل یعنی چی؟
مهمه که بدونیم داگفودینگ با سیاستهای سادهای مثل حمایت از برند خودی فرق داره. مجله «اینفوورلد» توضیح میده که این فرآیند باید شفاف و صادقانه باشه. مثالهای سطحی مثل اینکه یک نمایندگی خودرو، فروشندههاش رو مجبور کنه که ماشینهای همون برند رو سوار بشن، یا اینکه شرکت کوکاکولا اجازه نده هیچ محصولی از پپسی وارد دفاترش بشه، ربطی به مفهوم اصلی داگفودینگ نداره. اینجور کارها بیشتر یک فرهنگ سازمانی برای حمایت نکردن از رقیبه. اما داگفودینگ روی جنبههای عملکردی محصول خود شرکت تمرکز داره.
هدف اصلی اینه که کارمندها محصول شرکت رو در موقعیتهای واقعی زندگی روزمره تست کنن. این کار یک مزیت فراتر از بازاریابی داره، هرچند که هنوز هم بحثبرانگیزه. این روش به مدیریت یک دید کلی میده که محصولشون چطور ممکنه توسط مشتری نهایی استفاده بشه، اون هم قبل از اینکه محصول به دست مصرفکنندهها برسه.
در دنیای توسعه نرمافزار، داگفودینگ میتونه در چند مرحله اتفاق بیفته:
- اول، یک نسخه پایدار از نرمافزار که فقط یک ویژگی جدید بهش اضافه شده، توسط تیم استفاده میشه.
- بعد، چند تا ویژگی جدید با هم ترکیب میشن و در قالب یک نسخه واحد، با هم تست میشن.
این کار اجازه میده تا قبل از عرضه نهایی نرمافزار، چندین مرحله اعتبارسنجی انجام بشه. این تمرین به حل فعالانه مشکلات احتمالی مربوط به ناهماهنگی و وابستگیها کمک میکنه، به خصوص وقتی که چندین توسعهدهنده یا تیمهای مختلف روی یک محصول کار میکنن.
البته داگفودینگ، به خصوص وقتی به صورت عمومی انجام بشه، ریسکهایی هم داره. برای مثال، اگه یک شرکت در استفاده از محصول خودش دچار مشکل بشه و این خبر به بیرون درز کنه، میتونه به اعتبارش لطمه بزنه. همین ریسک باعث شده که خیلی از شرکتها ترجیح بدن این فرآیند رو به صورت عمومی و پر سر و صدا انجام ندن.
هدف از داگفودینگ فقط تست کردن محصول نیست، بلکه اینه که خودتون رو جای کاربر واقعی بذارید و از دید اون به مسائل نگاه کنید. در حالت ایدهآل، این فرآیند نباید به گروه خاصی محدود بشه و هر کسی در شرکت که به محصول یا ویژگی جدید علاقه داره، باید در اون شرکت کنه. اما حداقل گروههای زیر باید در این فرآیند حضور داشته باشن:
- تیمی که مستقیما روی محصول کار کرده (توسعهدهندهها و تیم کنترل کیفیت).
- تیم بازاریابی که قراره اون رو تبلیغ کنه.
- تیم توسعه کسب و کار که قراره اون رو بفروشه.
- مدیران محصول که مشتاق دیدن نتیجه نهایی هستن.
شاید درگیر کردن همه این افراد در فرآیند داگفودینگ کمی سخت و زمانبر به نظر برسه، اما نتایج اون ارزشش رو داره.
داستان شرکتهایی که غذای سگ خودشون رو خوردن
تاریخ دنیای تکنولوژی پر از مثالهای جالبی از شرکتهاییه که داگفودینگ رو به عنوان یک اصل پذیرفتن. این داستانها نشون میده که این رویکرد چطور به شکلگیری برخی از معروفترین محصولات دنیا کمک کرده.
اپل و خداحافظی با ماشینهای تحریر
در فوریه سال ۱۹۸۰، مایکل اسکات، رئیس وقت شرکت اپل، یک یادداشت داخلی نوشت که در اون اعلام کرد: «از همین لحظه!! هیچ ماشین تحریری نباید خریده یا اجاره بشه و غیره و غیره. […] ما معتقدیم که ماشین تحریر منسوخ شده. بیاید این رو اول در داخل شرکت ثابت کنیم قبل از اینکه سعی کنیم مشتریانمون رو قانع کنیم». هدف اون این بود که تا اول ژانویه ۱۹۸۱، تمام ماشینهای تحریر از شرکت اپل حذف بشن. این یک حرکت جسورانه بود که نشون میداد اپل چقدر به آینده کامپیوترهای شخصی و محصول خودش ایمان داره.
آتاری و استفاده از کامپیوترهای ST
تا سال ۱۹۸۷، شرکت آتاری هم در حال پیادهسازی یک سیاست مشابه بود و در سراسر شرکت از کامپیوترهای سری Atari ST استفاده میکرد. این کار به تیمها کمک میکرد تا نقاط قوت و ضعف محصولی که میساختن رو از نزدیک لمس کنن.
مایکروسافت: یک امپراتوری مبتنی بر داگفودینگ
شاید هیچ شرکتی به اندازه مایکروسافت با مفهوم داگفودینگ گره نخورده باشه.
- توسعه ویندوز NT: توسعه سیستمعامل ویندوز NT یک پروژه عظیم بود که بیش از ۲۰۰ توسعهدهنده در تیمهای کوچک روی اون کار میکردن. چیزی که این تیمها رو هماهنگ نگه میداشت، اصرار دیو کاتلر در فوریه ۱۹۹۱ بر داگفودینگ بود. مایکروسافت این سیستمعامل رو روی کامپیوترهایی توسعه میداد که هر روز جدیدترین بیلد (نسخه ساخت) ویندوز NT روشون نصب میشد. در اوایل، این نرمافزار به شدت ناپایدار بود و مدام کرش میکرد. اما بازخورد فوری ناشی از اینکه یک قطعه کد باعث از کار افتادن کل سیستم میشد، از دست رفتن غرور برنامهنویس و اینکه میدونستن کار بقیه رو مختل کردن، انگیزههای قدرتمندی برای بهتر کردن سریع محصول بود. به طور معمول، توسعهدهندههای ویندوز از همون بیلدهای اولیه (آلفا) شروع به استفاده از ویندوز میکردن، در حالی که بقیه کارمندهای مایکروسافت از بیلدهای بتا که پایدارتر بودن و در اختیار مشترکین MSDN هم قرار میگرفتن، استفاده میکردن.
- شبکه داخلی مایکروسافت: در سال ۲۰۰۵، مجله «اینفوورلد» گزارش داد که بازدیدی از مرکز عملیات شبکه مایکروسافت «تقریبا فراتر از هر شک منطقی» نشون داده که این شرکت شبکه بینالمللی خودش با بیش از ۲۰ هزار نود رو روی ۹۹ درصد تکنولوژی ویندوز اداره میکنه. این شامل سرورها، کامپیوترهای کاری و سیستمهای امنیتی بود. اینفوورلد استدلال کرد که استفاده مایکروسافت از ویندوز برای عملیاتهای سنگین و پرترافیک خودش، خیلی از افراد شکاک رو به سمت ویندوز کشوند. به قول اونها، «استفاده مایکروسافت از ویندوز و دات نت شاید بیاهمیت بود، به جز یک نکته: مدیران پروژههای نرمافزاری و سرویسهای آنلاین اونها واقعا آزادی انتخاب داشتن».
- مهاجرت به مایکروسافت اکسچنج: داستان سیستم ایمیل داخلی مایکروسافت هم جالبه. در ابتدا، این سیستم روی Xenix، یکی از نسخههای یونیکس، اجرا میشد. تنها کارمندهایی که از نرمافزار Microsoft Mail استفاده میکردن، خود تیم توسعهدهنده اون بودن که ازش به عنوان یک کلاینت برای سرورهای ایمیل Xenix استفاده میکردن. وقتی از مایکروسافت پرسیده شد که چرا از یونیکس استفاده میکنه، این شرکت به صورت عمومی اعلام کرد که در حال مهاجرت به محصول خودش یعنی Microsoft Exchange هست. در طول این مهاجرت که بین سالهای ۱۹۹۳ تا ۱۹۹۶ انجام شد، محیط تست داخلی اسم رمز «Dogfood» رو داشت.
در سال ۱۹۹۷، یک طوفان ایمیلی که به حادثه «Bedlam DL3» معروف شد، باعث شد مایکروسافت ویژگیهای قویتری رو در اکسچنج سرور تعبیه کنه تا از گم شدن و تکراری شدن ایمیلها و از کار افتادن شبکه و سرور جلوگیری کنه. البته داگفودینگ به ندرت اینقدر دراماتیک میشه. یک طوفان ایمیلی دوم در سال ۲۰۰۶، به بهترین شکل توسط سیستم مدیریت شد و نشون داد که درسهای حادثه اول به خوبی یاد گرفته شده.
مثالهای دیگر از دنیای تکنولوژی
- در سال ۱۹۹۹، کارمندان شرکت هیولت-پاکارد (HP) به پروژهای که در اون از محصولات خود HP استفاده میشد، «پروژه آلپو» (با اشاره به همون برند غذای سگ) میگفتن.
- همزمان، شرکت موزیلا هم دقیقا با همین نام، یعنی «داگفودینگ»، در حال استفاده از محصولات خودش بود.
- در اول ژوئن ۲۰۱۱، یوتیوب یک ویژگی جدید به سرویس آپلود ویدیوی خودش اضافه کرد که به کاربرها اجازه میداد بین لایسنس استاندارد یا Creative Commons یکی رو انتخاب کنن. کنار این برچسب لایسنس، پیامی با این عنوان روی تمام ویدیوهایی که لایسنس تجاری نداشتن ظاهر شد: «(ششش! – داگفود داخلی)». یکی از کارمندان یوتیوب تایید کرد که این پیام به محصولاتی اشاره داره که به صورت داخلی در حال تست هستن.
- شرکت اوراکل در اکتبر ۲۰۱۶ اعلام کرد که سیستمعامل Oracle Linux رو روی بیش از ۴۲ هزار سرور اجرا میکنه تا «بیش از ۴ میلیون کاربر خارجی و ۸۴ هزار کاربر داخلی رو پشتیبانی کنه. بیش از ۲۰ هزار توسعهدهنده در اوراکل از Oracle Linux استفاده میکنن».
- بعد از قطعیهای گسترده CrowdStrike در جولای ۲۰۲۴، مدیرعامل این شرکت، آدام مایرز، در کنگره آمریکا شهادت داد که «داگفودینگ» (افزایش تستهای داخلی قبل از عرضه) یکی از اقداماتی بوده که شرکت برای جلوگیری از مشکلات آینده در نظر گرفته.
ماجرای DoorDash و برنامه WeDash
یک نمونه جدیدتر و جنجالی از داگفودینگ مربوط به شرکت دلیوری «DoorDash» میشه. در یک جلسه عمومی، مدیران شرکت اعلام کردن که همه کارمندها، از جمله مهندسها، باید حداقل ماهی یک بار به عنوان پیک کار کنن و غذا تحویل بدن. این برنامه که «WeDash» نام داشت، قبلا هم اجرا میشد اما در دوران اولیه پاندمی متوقف شده بود.
این تصمیم با واکنشهای تندی روبرو شد. در سایت «Blind» که کارمندان سیلیکونولی به صورت ناشناس در اون در مورد شغلشون صحبت میکنن، یک نفر که ادعا میکرد مهندس DoorDash هست، با عصبانیت نوشت:
«WeDash اجباری از سال آینده شروع میشه. باید ماهی یک بار دلیوری انجام بدی. این موضوع توی ارزیابی عملکرد هم لحاظ میشه!! این دیگه چه کوفتیه؟ من برای این کار قرارداد نبستم، هیچ چیزی در این مورد توی نامه پیشنهاد شغلی یا شرح وظایف من نبود.»
این پست یک بحث بزرگ با نزدیک به ۱۹۰۰ کامنت به راه انداخت. بعضیها با این مهندس موافق بودن و بعضیها هم با کنایه جواب میدادن که «اگه رانندهها از رانندگی خوششون نمیاد، میتونن مهارتهاشون رو ارتقا بدن…». این اتفاق نشون داد که هرچند داگفودینگ یک ایده قویه، اما نحوه اجرای اون میتونه خیلی بحثبرانگیز باشه.
مزایا و معایب داگفودینگ: یک شمشیر دو لبه
اینکه یک شرکت خودش از محصولاتش استفاده کنه، هم طرفدارهای سرسختی داره و هم منتقدانی که به خطرات و محدودیتهاش اشاره میکنن. بیاید نگاهی به هر دو طرف ماجرا بندازیم.
چرا داگفودینگ ایده خوبیه؟ (طرفداران)
- بهبود کیفیت و پیدا کردن سریع باگها: این شاید بزرگترین مزیت باشه. وقتی مجبور باشی هر روز با محصولی که خودت ساختی کار کنی، کوچکترین ایرادها و باگها خیلی زود خودشون رو نشون میدن. جوئل اسپولسکی، یک وبلاگنویس معروف در حوزه نرمافزار، داستان جالبی از توسعه محصول خودش به نام «CityDesk» تعریف میکنه. اون فکر میکرد محصولش تقریبا ۳ هفته تا عرضه نهایی فاصله داره، اما وقتی یک آخر هفته سعی کرد باهاش یک سایت واقعی بسازه، به مشکلات بزرگی برخورد.
«وای! چند تا باگ وجود داشت که به معنای واقعی کلمه اجازه نمیداد کارم رو ادامه بدم، پس مجبور شدم اول اونها رو درست کنم. تمام تستهایی که ما با دقت انجام داده بودیم… نتونسته بود این مشکلات اساسی رو که جلوی انجام کار اصلی محصول رو میگرفت، پیدا کنه. اما تلاش برای استفاده از محصول، درست مثل یک مشتری، این مشکلات رو در یک دقیقه پیدا کرد.»
اسپولسکی در یک بعد از ظهر یکشنبه، ۴۵ باگ پیدا کرد. اون میگه بسیاری از این باگها ایرادات فنی نبودن، بلکه چیزهایی بودن که کار رو برای کاربر سخت میکردن. این تجربه باعث شد که اون از کل تیمش بخواد که با CityDesk یک سایت جدی بسازن تا باگهای بیشتری پیدا بشه. این دقیقا همون «خوردن غذای سگ خود» بود.
- ایجاد حس همدلی با کاربر: وقتی خودت کاربر محصولت باشی، درک میکنی که کاربر چه چیزی رو تجربه میکنه. این حس همدلی به طور خودکار به وجود میاد. اسپولسکی تعریف میکنه که چطور تلاش برای وارد کردن یک صفحه وب از نیویورک تایمز به CityDesk یک روز کامل ازش وقت گرفت، چون باید به صورت دستی دهها عکس رو دانلود و لینکهاشون رو اصلاح میکرد. بعد به این نتیجه رسید که به عنوان یک برنامهنویس، میتونه در زمان کمتری یک تابع بنویسه که این کار رو به صورت خودکار انجام بده. این ویژگی بدون تجربه مستقیم درد کاربر، هرگز به محصول اضافه نمیشد.
- ایجاد اعتماد و اعتبار: وقتی یک شرکت از محصول خودش استفاده میکنه، یک پیام قدرتمند به بازار میفرسته: «ما به محصول خودمون ایمان داریم». این مثل یک جور تبلیغ زنده عمل میکنه. به قول یکی از کاربران Quora، «تصور کنید یک دکتر به شما قرصهایی بده تا بیماریتون رو درمان کنه، اما خودش حاضر نباشه همون قرصها رو بخوره. آیا به اون دکتر یا قرصهاش اعتماد میکنید؟ احتمالا نه!». این اعتماد، هم مشتریان فعلی رو حفظ میکنه و هم مشتریان جدید رو جذب میکنه.
- تایید تجربه کاربری (UX): یک برنامه ممکنه از نظر فنی درست کار کنه، اما برای کاربر نهایی گیجکننده و سخت باشه. داگفودینگ مثل یک دور آزمایشی قبل از عرضه نهایی عمل میکنه. اگه کاربرها تجربه خوبی با محصول شما داشته باشن، اون رو به دوستان و خانوادهشون معرفی میکنن، و در عصر شبکههای اجتماعی، تبلیغات دهان به دهان میتونه خیلی سریع پخش بشه.
- این روش شما رو صادق نگه میداره: در یک بحث در سایت Reddit، یکی از بنیانگذاران استارتاپی به نام Shram میگه: «ما هر روز بهش (داگفودینگ) تکیه میکنیم تا کارهای خودمون رو پیگیری کنیم، مشارکتها رو بشناسیم و روی چیزهایی که واقعا مهمه تمرکز کنیم. این کار ما رو صادق نگه میداره».
دونالد کنوث، دانشمند کامپیوتر افسانهای، در مقالهای در سال ۱۹۸۹ در مورد درسهایی که از توسعه نرمافزار حروفچینی خودش یعنی TeX گرفته بود، به مزایای این رویکرد اشاره کرد:
«بنابراین، من به این نتیجه رسیدم که طراح یک سیستم جدید نه تنها باید پیادهساز و اولین کاربر در مقیاس بزرگ باشه؛ بلکه طراح باید اولین راهنمای کاربر رو هم بنویسه. جدا کردن هر یک از این چهار جزء به TeX آسیب قابل توجهی میزد. اگر من به طور کامل در همه این فعالیتها شرکت نمیکردم، به معنای واقعی کلمه صدها بهبود هرگز انجام نمیشد، چون من هرگز به اونها فکر نمیکردم یا درک نمیکردم که چرا مهم هستن.»
چرا داگفودینگ میتونه ایده بدی باشه؟ (منتقدان)
- توسعهدهندهها کاربران معمولی نیستن: این یکی از بزرگترین انتقادهاست. توسعهدهندههای نرمافزار ممکنه نسبت به مشکلات usability (کاربرپسندی) کور باشن. اونها دانش فنی لازم برای کار با نرمافزار رو دارن، حتی اگه نرمافزار ایراد داشته باشه؛ دانشی که کاربر نهایی از اون بیبهره است. مدیر ارشد اطلاعات مایکروسافت در سال ۲۰۰۸ اشاره کرد که قبلا «ما تمایل نداشتیم تجربه واقعی مشتری رو طی کنیم. ما همیشه از یک نسخه بتا آپگرید میکردیم، نه از دیسک نهایی به دیسک نهایی».
- عادت به راهحلهای موقتی: کارمندانی که مجبور به استفاده از یک محصول ناتمام هستن، ممکنه به استفاده از راهحلهای موقتی (workarounds) عادت کنن یا با خودشون فکر کنن که حتما یکی دیگه این مشکل رو گزارش کرده. این باعث میشه باگهای مهم گزارش نشن.
- کاهش بهرهوری و تضعیف روحیه: مجبور کردن کارمندها به استفاده از یک محصول پر از باگ و ناقص میتونه به شدت بهرهوری اونها رو پایین بیاره و باعث بیانگیزگی و دلسردی بشه.
- سندروم «اینجا اختراع نشده» (Not Invented Here): داگفودینگ در حالت افراطی میتونه باعث بشه یک شرکت فقط و فقط از ابزارهای داخلی خودش استفاده کنه و چشمش رو روی ابزارها و راهکارهای بهتری که توسط رقبا ارائه میشه، ببنده. وارن هریسون در مقالهاش به مدیری در یک شرکت داگفودینگ اشاره میکنه که با افتخار میگفت: «سالهاست که هیچکس در این شرکت چیزی رو که برچسب “محرمانه” شرکت ما رو نداشته باشه، نخونده». این دیدگاه باعث میشه مهندسها از یادگیری از رقبا محروم بشن و جنبههای بد ابزارهای خودشون رو تکرار کنن، چون اصلا نمیدونن که راه بهتری هم وجود داره.
- شرایط غیرواقعی: در دنیای واقعی، مشتریان همیشه میتونن از محصولات شرکتهای مختلف در کنار هم استفاده کنن. اما در یک محیط داگفودینگ، ممکنه محصول در یک اکوسیستم کاملا کنترل شده و ایزوله تست بشه که با شرایط واقعی مشتریان مطابقت نداره.
- ریسک شکست عمومی: همونطور که قبلا گفته شد، اگه شرکتی به صورت عمومی از محصول خودش استفاده کنه و اون محصول شکست بخوره، این میتونه یک ضربه بزرگ به اعتبار اون شرکت باشه.
در نهایت، بسیاری از منتقدان معتقدند که داگفودینگ نباید جایگزین فرآیندهای رسمی تست و تضمین کیفیت (QA) بشه. اگه یک شرکت برای پیدا کردن باگها به شدت به استفاده داخلی متکی باشه، این میتونه نشوندهنده ضعف در فرآیندهای QA اون شرکت باشه.
جایگزینهای خوشایندتر برای «خوردن غذای سگ»
صادقانه بگیم، عبارت «خوردن غذای سگ» برای همه خوشایند نیست. بعضیها معتقدن این عبارت این حس رو منتقل میکنه که داری اعتراف میکنی محصولت بیکیفیته. به همین دلیل، در طول سالها اصطلاحات جایگزین و لطیفتری برای این مفهوم به وجود اومده.
- «نوشیدن شامپاین خودمان» (Drinking our own champagne): این شاید معروفترین جایگزین باشه. در سال ۲۰۰۷، جو هوپ، مدیر ارشد اطلاعات شرکت Pegasystems، گفت که از این عبارت استفاده میکنه. این اصطلاح همون مفهوم رو میرسونه اما با یک استعاره بسیار دلپذیرتر و لوکستر. بروس لوری، رئیس روابط عمومی شرکت Novell، هم در مورد استفاده شرکتش از لینوکس و OpenOffice.org گفت که این عبارت رو ترجیح میده.
- «خوردن بستنی خودمان» (Icecreaming): در سال ۲۰۰۹، تونی اسکات، مدیر ارشد اطلاعات جدید مایکروسافت، استدلال کرد که عبارت «داگفودینگ» ناخوشاینده و باید با «آیسکریمینگ» جایگزین بشه. هدف اون این بود که محصولاتی تولید بشن که «مثل بستنی باشن که مشتریان ما بخوان اون رو مصرف کنن».
- «خودهوستی» یا «سلف-هاستینگ» (Self-hosting): این یک اصطلاح فنیتر و رایج در دنیای نرمافزاره. برای مثال، وقتی کامپیوترهای کاری توسعهدهندهها به صورت خودکار هر شب به آخرین بیلد روزانه نرمافزار یا سیستمعاملی که روش کار میکنن آپدیت میشه، به این کار سلف-هاستینگ میگن. این اصطلاح به طور خاص برای ابزارهایی مثل کامپایلرها، سیستمهای کنترل نسخه یا ابزارهای مدیریت نیازمندیها هم به کار میره.
- «خوردن غذای پخته شده توسط خودمان» (Eating our own cooking): این عبارتیه که توسعهدهندگان سیستمعاملهای مینفریم شرکت IBM از قدیم از اون استفاده میکردن. این هم یک جایگزین مودبانهتر برای همون مفهومه.
- «ما به چیزی که موعظه میکنیم، عمل میکنیم» (We practice what we preach): این یک عبارت رسمیتره که به معنای واقعی کلمه به استفاده از محصول اشاره نمیکنه، اما همون پیام رو میرسونه که حرف و عمل ما یکیه.
- «من فقط رئیس باشگاه مو نیستم، بلکه یک مشتری هم هستم»: این جمله معروف سخنگوی شرکت «Hair Club for Men» در تلویزیون بود. این یک روش خیلی واضح و جذاب برای گفتن اینه که ما خودمون اولین مشتری و مصرفکننده محصول خودمون هستیم.
انتخاب بین این عبارتها اغلب به فرهنگ شرکت و مخاطبی که باهاش صحبت میکنید بستگی داره. در شرکتهای تکنولوژی، «داگفودینگ» یک اصطلاح کاملا عادی و رسمی محسوب میشه. اما وقتی با مشتریان غیرفنی صحبت میکنید، ممکنه این عبارت کمی تند یا توهینآمیز به نظر برسه. همونطور که یکی از کاربران در سایت StackExchange نوشته بود: «من که فنی نیستم، اصلا نفهمیدم منظورتون از غذای سگ چیه!».
استراتژی آمازون: داگفودینگ در مقیاس یک پلتفرم
آمازون رویکرد داگفودینگ رو به یک سطح کاملا جدید برده و از اون به عنوان یک استراتژی اصلی برای ساختن پلتفرمهای عظیم استفاده کرده. بن تامپسون، یک تحلیلگر معروف، تاکتیک آمازون رو به این شکل خلاصه میکنه:
- یک سرویس (با استفاده از تکنولوژی) برای استفاده داخلی در آمازون بساز.
- این سرویس رو به صورت تکرارشونده کامل کن (و در نتیجه اون رو به یک محصول تبدیل کن). آمازون خودش یک مشتری فوقالعاده سختگیره که تضمین میکنه این سرویس کارا باشه و بتونه در مقیاس بزرگ کار کنه.
- این سرویس رو در اختیار تمام دنیا قرار بده و ازش کسب درآمد کن.
اینکه آیا جف بزوس از اول این ایده رو در سر داشت یا در طول زمان به این نتیجه رسید، مشخص نیست. اما به احتمال زیاد حالت دوم درسته. این رویکرد به آمازون اجازه داده تا پلتفرمهای غولپیکری به عنوان سرویس (PaaS) بسازه.
- خدمات وب آمازون (AWS): اول از همه سایت Amazon.com بود. یک سایت تجارت الکترونیک به این بزرگی به زیرساخت فناوری اطلاعات (سرورها، مراکز داده، فضای ذخیرهسازی) نیاز داشت که بتونه در مقیاس بزرگ کار کنه. پس آمازون شروع به ساختن این زیرساخت کرد. وقتی این زیرساخت آماده شد و Amazon.com تونست به صورت انعطافپذیر ازش استفاده کنه، آمازون به سادگی اون رو به یک محصول به نام Amazon Web Services (AWS) تبدیل کرد و در اختیار عموم قرار داد. زیبایی این رویکرد این بود که زیرساخت IT سرمایهبر و با هزینههای ثابت بالاست. بدون داشتن یک مشتری بزرگ و تضمین شده، شرطبندی روی ساختن یک پلتفرم مثل AWS خیلی سخته. Amazon.com اولین و بزرگترین مشتری AWS بود!
- خدمات انبارداری آمازون (Amazon Fulfilment Services): همین رویکرد برای سرمایهگذاری آمازون در مراکز انبارداری هم به کار رفت. این مراکز هم هزینههای سرمایهای ثابت و عظیمی داشتن. اما اینکه Amazon.com خودش مشتری اصلی و بزرگ این انبارها بود، این سرمایهگذاریها رو توجیه میکرد و به آمازون کمک کرد تا مکانیک عملیات داخلی این انبارها رو به کمال برسونه. بعد چی کار کردن؟ اون رو هم به یک محصول تبدیل کردن و حالا آمازون انباردار و نگهدارنده موجودی برای هزاران فروشنده سوم شخص هم هست.
- لجستیک و خرید Whole Foods: به نظر میرسه آمازون همین مسیر رو با لجستیک هم در پیش گرفته و این بخش هم در آینده به یک پلتفرم تبدیل خواهد شد. خرید فروشگاههای زنجیرهای Whole Foods توسط آمازون هم با همین تاکتیک قابل تحلیله. کسب و کار خواروبار حاشیه سود پایینی داره و هزینههای ثابت بالایی داره (شبیه به زیرساخت IT یا انبارداری). با خرید Whole Foods، آمازون در واقع برای خودش یک «مشتری» خریده که مصرفکننده اصلی بهبودهای تدریجی این شرکت در فضای دلیوری مواد غذایی خواهد بود. وقتی آمازون این عملیات رو به کمال برسونه، احتمالا این خدمات رو هم به عنوان یک پلتفرم ارائه خواهد داد.
گفته میشه که اساس این توانایی برای اجرای چنین تاکتیکهایی، به دستور معروف بزوس برمیگرده که تاکید داشت تمام سرویسهای آمازون باید طوری ساخته بشن که بتونن به راحتی از طریق وب با هم ارتباط برقرار کنن. اما در نهایت، این رویکرد «خوردن غذای سگ خود» بود که مشتریان داخلی آمازون، سرویسهای نوپای داخلی خودشون رو به چالش کشیدن و اونها رو به محصولات در کلاس جهانی و پلتفرمهایی که امروز میشناسیم تبدیل کردن.
منابع
- [۱] Eating your own dog food – Wikipedia
- [۲] Stealth Extraction Failed
- [۳] Reddit – The heart of the internet
- [۴] phrases – What is a more refined & formal way to say ‘we eat our own dog-food’? – English Language & Usage Stack Exchange
- [۵] What is the Work of Dogs in this Country? – Joel on Software
- [۶] The Value — and Limits — of Eating Your Own Dog Food | by Clive Thompson | Marker
- [۷] Amazon’s ‘Eat Your Own Dog Food’ Approach to Building Platforms
- [۸] What they mean saying ‘eat your own dog food’? Is it a patronizing statement to point that development team is below business? – Quora
- [۹] Eating Your Own Dog Food
- [۱۰] Software Dogfooding and its benefits
دیدگاهتان را بنویسید