https://virgool.io/alibaba-product/feed اینجا قرار است داستان بگوییم! داستان‌هایی جذاب از محصولاتی ناب. در حقیقت، اینجا پشت صحنه تیم محصول گروه علی باباست؛ جایی که اعضای تیم از از چالش‌ها و دغدغه‌هایشان برای رسیدن به محصولی کامل می‌نویسند. شنبه هر دو هفته یک داستان جدید برای شما داریم. به ما سر بزنید. fa 2026-04-15 07:36:40 https://files.virgool.io/upload/publication/x5tjsfle4wql/5tveoq.png https://virgool.io/alibaba-product https://virgool.io/alibaba-product/%D8%A7%D8%B1%D8%A7%D8%A6%D9%87-%D9%85%D8%AD%D9%85%D8%AF%D8%B9%D9%84%DB%8C-%D8%B5%D8%A7%D8%A8%D8%B1%DB%8C-%D8%AF%D8%B1-%D8%B3%D9%88%D9%85%DB%8C%D9%86-%D8%AF%D9%88%D8%B1%D9%87%D9%85%DB%8C-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%DA%AF%D8%B1%D9%88%D9%87-%D8%B9%D9%84%DB%8C%D8%A8%D8%A7%D8%A8%D8%A7-abproduct-s3-fi6q6eu9wof9 مهمترین نقش یک مدیر اتخاذ تصمیم های با کیفیت است. بسیاری از تصمیم سازان امروزه برای انتخاب بهترین تصمیم ممکن از داده و تحلیل کمک میگیرند.این ارایه چالشهای پیشرو برای تصمیم سازی داده محور را بیان کرده است. چالش هایی که در مسیر تحویل یک مدیر سنتی به یک تصمیم ساز داده محور در مسیر وی قرار می گیرند. این چالش ها «Data Distrust»، «Data Daze» و «Analysis Paralysis» هستند. https://www.aparat.com/v/x6zqQ ارائه محمدعلی‌ صابری پیرامون چالش های تصمیم داده‌محور در سومین دورهمی محصول گروه علی‌بابا (ABProduct) پشت صحنه تیم محصول علی بابا حسین ساداتی‌پور Sun, 19 Jan 2020 11:04:42 +0330 https://virgool.io/alibaba-product/%D8%AE%D9%88%D8%A8-%D8%A8%D8%AF-%D8%B2%D8%B4%D8%AA-%D9%87%D8%A7%DB%8C-%D8%AA%D8%B5%D9%85%DB%8C%D9%85%DA%AF%DB%8C%D8%B1%DB%8C-%D8%AF%DB%8C%D8%AA%D8%A7-%D9%85%D8%AD%D9%88%D8%B1-k2vlnkmqk3bn حدود یک سال پیش اعضای تیم محصول برای اخذ تصمیم استراتژیک مهمی دور هم جمع شده بودند. جریان ایجاد شده تصمیم نهایی را به سمتی می‌برد که من کاملا مخالف بودم؛ من معتقد بودم به محصولی که تیم ما در حال کار روی آن است، ضربه وارد می‌شود.چند دقیقه بیشتر برای نجات محصولمان (البته به عقیده خودم) فرصت نداشتم. بنابراین پنل بی‌آی، گوگل آنالیتیکز و گوگل استودیو را باز کردم و با این جمله «ویلیام ادواردز» جلسه را به دست گرفتم:“In God we trust; all others must bring data.”چند ماه قبل در جلسه استندآپ شرکت قول داده بودم که از این به بعد تمام تصمیماتم دیتا محور خواهد بود و طی ماه‌های بعد با جمع‌آوری و نمایش اطلاعات در پنل‌های مختلف مقدماتش را فراهم کرده بودم. بنابراین ذهن حاضران در جلسه آماده نطق غرای من بود؛ در نهایت با سوءاستفاده از دیتا (دقت کنید استفاده نه، سوءاستفاده) توانستم مسیر تصمیم‌گیری را به سمتی که شهودم می‌گفت، هدایت کنم.بعد از جلسه از طرفی خوشحال بودم که محصول را نجات داده‌ام (خوشبختانه بعدها مشخص شد واقعا نجات دادم) و از طرفی فکرم به شدت درگیر این بود که خودم تا به حال چند بار قربانی سوءاستفاده از دیتا بوده‌ام؟اتفاقا چند روز بعد در حال تحلیل داده‌ها متوجه شدم به خاطر یک بی‌دقتی، تا به حال راجع به رفتار خرید کاربرها به کل در اشتباه بودیم.تقابل این دو موضوع باعث شد به قداست دیتا شک کنم. شک کنم که شاید دیتا آن «حبل المتین»ی نیست که باید تمام قد به آن تکیه کنیم.بنابراین از دیدگاه «ویلیام ادواردز» ی عقب‌نشینی و سعی کردم یک بار دیگر جایگاه دیتا را بررسی کنم.آن زمان کتاب «lean analytics» را بازخوانی می‌کردم و کتاب «قوی سیاه» را تازه شروع کرده بودم. بنابراین اکثر مباحثی که در این متن می‌خوانید تحت تاثیر این دو کتاب ارزشمند نوشته شده است.مغز انسان و هزارتوی تصمیم‌گیریطی دهه‌های اخیر تحقیقات زیادی بر روی مغز انسان انجام شده و خطاها و ضعف‌های بسیاری از خطای تکیه‌گاهی و اجتناب از زیان گرفته تا تاییدجویی برای همه آشکار شده است.به دنبال همین تحقیقات، اصطلاح یا بهتر بگویم جنبش تصمیم‌گیری دیتامحور برای مقابله با تصمیمات شهودی ایجاد شد؛ چرا که ما انسان‌ها کاملا متوجه شده بودیم شهود ما نه تنها به تنهایی برای تصمیم‌گیری مناسب نیست بلکه ضعف‌های بی‌شماری هم دارد.ولی آیا واقعا مغز ما صلاحیت تصمیم‌گیری ندارد؟اگر مغز ما نمی‌تواند درست تصمیم بگیرد پس چطور توانسته این بدن ضعیف (به نسبت بقیه موجودات) را این همه سال زنده نگه دارد؟واقعیت این است که مغز ما طوری طراحی شده تا با حداقل اطلاعات سریع‌ترین تصمیم را بگیرد؛ چون انسان اولیه برای بقا مجبور بوده سریع عکس‌العمل نشان بدهد. تصور کنید انسان اولیه اگر می‌خواست بعد از اولین غرش، دیتای بیشتری برای اثبات وجود شیر جمع‌آوری کند قطعا خورده می‌شد (احتمالا آنهایی که اینطوری بودند خورده شدند و نسلشان ادامه پیدا نکرده است.)این فرمول قطعا برای زندگی بدوی کاملا دقیق طراحی شده بود تا وقتی که انسان تصمیم گرفت شهرهای بزرگ را بسازد، روش‌های ارتباطی در لحظه ایجاد کند، کامپیوتر بسازد و ریاضیات را توسعه دهد.حالا ما انسان‌ها اطلاعات زیادی در لحظه داشتیم که دانشمندهای آمار می‌توانستند تحلیلش کنند و مثلا بگویند چقدر احتمال دارد امسال خشکسالی داشته باشیم.یک لحظه تصور کنید انسانی که در گذشته به خاطر تغییرات آب و هوا ممکن بوده ضررهای جبران ناپذیری تحمل کند، امروزه می‌داند که امسال خشکسالی می‌شود و می‌تواند برای آن برنامه‌ریزی کند.این دوره عصر طلایی ویلیام ادوارزها بود که انصافا خدمت بزرگی به بشریت انجام دادند.همه چیز خوب بود تا وقتی که ما انسان‌ها به خاطر ذات حریصمان پیش خودمان گفتیم حالا که می‌شود آب و هوا را پیش‌بینی کرد، پس بیایید همه چیز را تحلیل و پیش‌بینی کنیم.بیایید اول درباره بعضی از نقاط ضعف ذاتی دیتا صحبت کنیم: ارزش دیتاهای گذشته و آیندهداده‌ها برای گذشتهما هیچ وقت دیتای کامل گذشته را تمام و کمال نمی‌توانیم نگه داریم؛ فقط یک اسنپ‌شات را از گذشته نگه می‌داریم.بیایید فرض کنیم همه ما با هم در یک مهمانی هستیم. در این مهمانی اتفاقات زیادی از قهر، آشتی، شادی و غم ممکن است اتفاق بیافتد. ما یک سری خاطره و تعدادی عکس از آن مهمانی برایمان باقی می‌ماند.احتمالا فردا خیلی دقیق می‌توانیم راجع به مهمانی شب قبل صحبت کنیم و مثلا بگوییم لبخند فلانی در این عکس زورکی است. فقط کافی است غبار زمان روی این عکس بنشیند؛ چند سال بعد همه یادشان می‌رود که اون لبخند زورکی بوده است.دیتای محدودی که ما جمع کردیم با ترکیب شهودمان فقط بخشی از واقعیت را نمایش می‌دهد. این بخشی از واقعیت هم به مرور زمان اسیر فراموشی و کم اعتبارتر می‌شود. حالا هر چقدر هم ما دیتایی که ممکن است بعدا نیاز بشود را روی دیتاسنترها انبار کنیم، بازهم چیزی را که امروز می‌دانیم جمع کرده‌ایم، معلوم نیست در آینده برایمان کافی باشد.داده‌ها برای آیندهفرض کنیم یک میز بیلیارد بدون اصطکاک داریم که توپ بیلیارد می‌تواند تا بی‌نهایت با بدنه برخورد کند و به مسیرش ادامه دهد. ما می‌خواهیم براساس دیتای موجود، محل برخورد توپ بیلیارد با دیواره میز را پیش‌بینی کنیم.«سر مایکل بری» ریاضیدان به جای ما زحمت کشیده و سال‌ها پیش این محاسبات را انجام داده است. پیش‌بینی محل ضربه اول اصلا سخت نیست، دو و سوم هم همینطور ولی برای پیش‌بینی ضربه نهم باید اثر گرانش تمام افراد دور میز را در محاسباتمان بیاوریم. برای محاسبه ضربه پنجاه و چهارم باید اثر گرانش تمام ذرات موجود در کائنات را وارد محاسباتمان کنیم.یعنی گرانش دورترین الکترون دورترین کهکشان روی محاسبات ما تاثیر دارد.مایکل بری این محاسبات را با فرض اینکه هیچ تغییر غیر منتظره‌ای مثل جابه‌جا شدن یکی از حضار رخ ندهد، انجام داده بود. یعنی من و شما و تمام موجودات دارای اختیار تا ضربه پنجاه و چهارم بدون نفس کشیدن سر جای خودمان نشسته باشیم.حتی با این فرض هم نمی‌توانیم حرکت ۱۵ دقیقه بعد یک توپ بیلیارد را پیش‌بینی کنیم. حالا دنیایی پر از اختیار و عدم قطعیت امروز را در نظر بگیرید که ما می‌خواهیم مسائل پیچیده‌تری مثل بازار بورس، رشد استارت‌آپ‌ها و … را پیش‌بینی کنیم.جمع آوری دیتا، گران و تحلیل دیتا گرانترجمع‌آوری دیتا کار پر هزینه ای است. منظور دیتایی نیست که می‌دانید نیاز دارید، منظور دیتایی است که ممکن است در آینده نیاز پیدا کنیم. برای جمع‌آوری این دیتای عظیم به دیتاسنترهای بی‌نهایت بزرگی نیاز داریم که هزینه‌اش برای دیتایی که شاید لازم بشود، قطعا معقول به نظر نمی‌آید.حالا با فرض وجود دیتای کافی به آدم‌های باهوشی نیاز داریم که تجربه و دانش کافی برای کار با دیتا را داشته باشند. با کمی جستجو متوجه می‌شویم که این آدم‌ها به هیچ وجه ارزان نیستند.دنیای کرانستان و میانستان«نسیم نیکلاس طالب» در کتاب ارزشمندش «قوی سیاه» دنیا را به دو بخش تقسیم می‌کند.کرانستان و میانستان (این دو کلمه به ترتیب ترجمه انگلیسی دو کلمه Extremistan و Mediocristan هستند که توسط نویسنده ساخته شده‌اند و آقای محمد ابراهیم محبوب هم به پیروی از نویسنده این دو کلمه را از نو خلق کرده است).میانستان دنیایی است که مغز ما راحت‌تر می‌فهمد. در این بخش از دنیا اختلاف‌ها از یک میانگین، تفاوت معنی‌دار ندارند. مثلا قد انسان‌ها احتمالا بین ۵۰ تا ۲۵۰ سانتی‌متر بوده و در طول تاریخ موارد نادری از این میانگین خارج بوده‌اند. حتی این موارد معدود تاثیری در کل هر تحلیلی که داشته باشیم ندارد.اما امان از کرانستان،کرانستان دنیایی است که مغز ما درک درستی از آن ندارد. مثل پولی که انسان‌ها دارند. موجودی بانکی انسان‌ها می‌تواند از صفر (یا حتی منفی هر عددی) تا مثبت هر عددی باشد. هیچ محدودیتی نمی‌توان برایش قائل شد و این اختلاف‌ها در تصمیم‌گیری ما تاثیر چشمگیری دارند.تقریبا تمام ریاضیات ما بر پایه میانستان بوده و در میانستان جواب می‌دهد. مثل پیش‌بینی آب و هوا (در کره زمین سرعت باد و دمای هوا و… از یک میانگین پیروی می‌کنند که اگر پیروی نمی‌کردند احتمالا ما الان اینجا نبودیم که بخواهیم راجع به دیتا صحبت کنیم.)ولی در کرانستان دیتای ما خیلی کم ارزش‌تر و تحلیل ما خیلی سطحی تر خواهد بود. تقریبا هیچ توزیع آماری در این دنیا کار نمی‌کند. در کرانستان اصل پارتو کار نمی‌کند، هیچ توزیع آماری کارآمدی نداریم و تقریبا هیچ وقت نتوانستیم نقاط شکست این دنیا را پیش‌بینی کنیم.در کرانستان تقریبا خلع سلاح شده‌ایم.محدودیت‌های ساخته انسانحالا که با محدودیت‌های جمع‌آوری و تحلیل دیتا آشنا شدیم قبل از جمع‌بندی نهایی باید درباره بعضی از محدودیت‌های که خودمان در این راه پر پیچ و خم جلوی راهمان می‌گذاریم، صحبت کنیم.تهوع دیتااوایل متن گفتیم که مغز ما طوری ساخته شده که با دیتای کم تصمیم سریع بگیرد و این کار را خیلی با کیفیت انجام می‌دهد. یکی از عارضه‌های دیتامحور شدن داشبوردهای دیتای شلوغ و آزاردهنده است که مغزمان را گیج و احتمال تصمیم‌گیری به موقع را غیرممکن می‌کند.تحقیقات زیادی انجام شده که هر چه گزینه‌های بیشتری جلوی مشتری قرار بدهیم، شانس خریدش کمتر می‌شود.راه حلی که lean analytics‌ پیشنهاد کرده استفاده از OMTM(one metrics that matters) است. یعنی در هر لحظه فقط و فقط روی یک kpi متمرکز بشویم و هر دیتای دیگری را نادیده بگیریم.دیتای درست به آدم درستنباید از همه آدم‌ها توقع داشته باشیم که همه نوع دیتا را بفهمند. طبیعتا انسان‌ها هرکدام تخصص‌ها و دغدغه‌های متفاوتی دارند. دیتایی که برای یکی از اعضای تیم قابل فهم و الهام بخش است برای یکی دیگر از اعضای تیم ممکن است استرس‌زا باشد.راه حل این است که OMTM را خیلی قابل‌فهم و ساده انتخاب کنیم و به آدم‌های درگیر، بیشتر دیتایی بدهیم که مورد نیازشان باشد.مثلا در یک تیم محصول اعلام می‌‌کنیم می‌خواهیم نرخ تبدیل ترافیک ورودی به خرید را ۵۰ درصد بیشتر کنیم. از دیزاینر می‌خواهیم که روی ux مترکز شود، فنی down time را کاهش بدهد، مرکز تماس نرخ پاسگخویی را افزایش دهد و... .نادیده گرفتن خبرگیمی‌خواهیم یک تست را از دو نفر بگیریم. نفر اول از بچگی در بازار کار کرده و الان تاجری موفق است؛ بیایید اسمش را بگذاریم اصغر اعیادی.نفر دوم یک آدم تحصیل‌کرده با شغل کارشناس ارشد دیتا در علی باباست. بیایید اسم این شخص را هم بگذاریم امید.سوال این است: یک سکه را ۹۹ بار به هوا می‌ندازیم و نتیجه شیر می‌شود چقدر احتمال دارد دفعه ۱۰۰ ام خط بیاد؟امید بدون درنگ می‌گوید ۵۰ درصد.اصغر اعیادی می‌گوید آن سکه خراب است و همیشه شیر می‌آید بنابراین احتمال خط شدن صفر است.حتی اگه به او بگوییم سکه سالم است به احتمال خیلی زیاد ما را دروغگو خطاب می‌کند که البته حق هم دارد. واقعا چقدر احتمال دارد یک سکه ۹۹ بار خط بیاد؟ آیا احتمال دروغگو بودن ما بیشتر نیست؟امید اشتباه نکرده، حتی اگه این دیتا را در اختیار ابرکامپیوتر واتسون هم قرار بدهیم نتیجه همان است و جواب صحیح را اصغر داده است.این مثال ارزش خبرگی را نشان می‌دهد که من اسمش را می‌گذارم فهم شهودی. بینش عمیقی که حاصل تعامل طولانی با مسئله دشواری است که باعث می‌شود مسیر نورونی مغز ما بارها و بارها در تمام حالت‌های ممکن به چالش کشیده و برای نباختن آماده شود.همین خبرگی است که باعث می‌شود نفر اول روزبه‌روز موفق‌تر باشد و نفر دوم سال به سال از نفر اول پاداش عملکرد بگیرد. (فکر می‌کنم همه ما یک پسر عمه بازاری داریم که چندین برابر ما ثروت دارد!)احتمالا قدرت شهود مغز ما تا مدت‌ها جایگاه خود را حفظ می‌کند (روزی که ما این قابلیت را به هوش مصنوعی ببازیم، به نظرم دنیا خیلی جای کسل کننده‌ای می‌شود).جایگاه دیتا:اگه تا اینجای متن به این نتیجه رسیدید که من قصد دارم به دیتا بتازم چند لحظه صبر کنید؛ منظور من به هیچ وجه تقبیح شخصیت محترم دیتا نیست. بیشتر روی نقاط ضعف و محدودیت‌های خودمان اشاره دارم والا دیتا یک شمشیر بُرنده است که بستگی دارد چطور از آن استفاده کنیم.ولی راه حل چیست؟داشبورد خودرو مثال کاملی از دیتای دقیق، حداقلی و درلحظه است‌من معتقدم هر قدر دیتایی که تحلیل می‌کنیم مربوط به زمان نزدیک‌تری به اکنون باشد (چه گذشته، چه آینده)، با قبول ریسک و محدودیت‌های جمع‌آوری و تحلیل اطلاعات و با علم به عدم قطعیت‌های دنیای کرانستانی امروزی، می‌توانیم خطی روی شن‌ها بکشیم و با داشبوردهای محدود اطلاعات وضعیت فعلی‌مان را کنترل کنیم. درست است که آینده قابل پیش‌بینی نیست ولی همیشه برنامه‌ای منعطف (اصلاحا روی شن‌ها) داشته باشیم و هر وقت دیتای جدیدی داشتیم این خط را به‌روز کنیم.به قول «یوگی برا» مربی افسانه‌ای بیسبال:“If you don't know where you are going, you'll end up someplace else.”حتی ماشین‌های تسلا هم با وجود اینکه می‌دانند مسیر نهایی کجاست ولی فقط برای ۱۰۰ متر جلوتر برنامه‌ریزی دقیق دارند و برنامه دورترشان هر لحظه ممکن است به روز شود.من عمیقا به دانش خبره بازار (یعنی «اصغر ایادی» در بخش نادیده گرفتن خبرگی) اعتقاد دارم ولی همیشه می‌شود دانش این افراد را با دشبوردهایی با دیتای کافی تقویت کرد. ما پشت فرمان زندگی نشستیم. با داشبوردی که به ما سرعت، میزان سوخت، دمای موتور و دور موتور را نشان می‌دهد. این داشبورد به شدت ریسک رانندگی را کم می‌کنند ولی تصمیم نهایی با خود ماست. ممکن است سر پیچی که سرعت مجاز ۶۰ کیلومتر بر ساعت است و داشبورد سرعت ۸۰ کیلومتر بر ساعت را نشان می‌دهد تصمیم بگیرم سرعت را بیشتر کنیم یا شاید تصمیم بگیریم بزنیم بغل تا بقیه رد شوند. برای همین گذاشتن تمام تخم مرغ‌ها در سبد دیتا همان قدر خطرناک است که بی‌توجهی به دیتا.ولی اگه مجبور به انتخاب باشم عمیقا معتقدم شهود انسانی از هر دیتا و تحلیلی قوی تر است.روند جدیدی در دنیا به عنوان data insightبه جای data driven به راه افتاده و همان طور که از اسمش پیداست، از دیدگاه دیتا محور بودن صرف فاصله گرفته و نقش شهود را جدی‌تر می‌کند.این متن در نتیجه تجربه و مطالعات محدود نگارنده نوشته شده و احتمال اینکه در بند دانش کم و محدودیت‌های شناختی گرفتار باشد وجود دارد. بنابراین با به اشتراک گذاشتن نظر و تجربیات خود به کامل شدن این متن کمک خواهید کرد.منتظر نظرات شما هستیم. پشت صحنه تیم محصول علی بابا کیوان پوریاور Sat, 21 Dec 2019 17:20:46 +0330 https://virgool.io/alibaba-product/usability-test-alibaba-i225ezzz27m0 تست کاربردپذیری (Usability Test) تستی است که میزان راحتی کاربران در کار با یک محصول را نشان می‌دهد. این تست معمولا در دو حالت کنترل‌شده (Moderated) و از راه دور یا کنترل‌نشده (Remote or Unmoderated) برگزار می‌شود.برای هر محقق، تجربه کاربری انجام یک تست کاربردپذیری با کاربران واقعی در یک محیط کنترل‌شده تجربه‌ای ایده‌آل و ناب است. این تجربه برای من قبل از نوروز 97 اتفاق افتاد.تیم ایندرا (نام پروژه بازنویسی وب‌سایت جدید علی بابا) در حال بازنویسی و توسعه سایت جدید بودند. از آنجایی که تمامی طراحی‌ها به تیم فنی رسیده بود ما زمان آزادی برای برگزاری تست داشتیم. مدیر تیم برنامه‌ریزی، تست را از چند ماه قبل با تیم و سازمان مطرح کرده بود؛ در حالی که سه هفته به سال نو زمان داشتیم، تیم تجربه کاربری تصمیم خود را برای برگزاری اولین تست کاربردپذیری علی ‌بابا گرفت و ما در سه هفته تمام مقدمات را برای حضور کاربران فراهم کردیم.چگونه کاربران را انتخاب کردیم؟یکی از سخت‌ترین بخش‌های برگزاری تست، بخش‌بندی کاربران بر اساس رفتار خرید و دستگاه (دیوایس) مورد استفاده در خرید است. در آن زمان بر اساس دیتایی که داشتیم کاربران را از دسته‌های متفاوت انتخاب کردیم: کاربران کم‌خرید، کاربران پرخرید و دسته آخر، کاربرانی که تعداد خرید آنها میان این دو دسته قرار می‌گرفت.از آنجایی که واحد بازاریابی تجربه بیشتری در تعامل با کاربران داشت، تصمیم مدیریتی بر این شد که تیم تحقیقات بازاریابی، برای سنجش کاربرانی که شرایط حضور دارند و دریافت اطلاعات دموگرافی آنها، مصاحبه اولیه تلفنی (Call interview) را انجام دهد. سپس لیستی پالایش‌شده به تیم تجربه کاربری داده شد. قرار بود ما از افراد مشخص‌شده که امکان همکاری دارند، برای حضور در تست دعوت کنیم.آیا کاربران حاضر به شرکت در تست می‌شوند؟لیست ما آماده بود و قول تست به سازمان داده شده بود. ما فقط سه هفته تا عید وقت داشتیم و باید 15 کاربر را به تست دعوت می‌کردیم. من با کاربران تماس می‌گرفتم. متن مکالمه ما به این شکل بود که بعد از معرفی خودم به آنها می‌گفتم: «ما تغییراتی در طراحی علی بابا داده‌ایم و قصد تست این تغییرات را داریم؛ شما را دعوت می‌کنیم که به هزینه شرکت، در دفتر مرکزی حضور پیدا کنید و نظرات خود را در مورد طراحی جدید با ما درمیان بگذارید.»پاسخ‌هایی که دریافت می‌کردیم خیلی جالب بود؛ برخی از کاربران می‌گفتند: «ما از سایت شما راضی هستیم و اگر سوالی دارید تلفنی بپرسید». عده‌ای هم شلوغی دم عید را بهانه می‌کردند. از همه سخت‌تر کاربران پر سفر بودند؛ افرادی که امکان حضورشان برای روزهایی غیر از روز کاری بود یا اصلا امکان حضور نداشتند.هر چه به انتهای لیست می‌رسیدیم، ناامیدتر از قبل می‌شدیم. تا اینکه مدیر تیم پیشنهاد داد در مکالمات تلفنی به جای تست که برای کاربران کلمه ترسناکی بود، از «شنیدن نظرات و اهدا هدیه صحبت کنیم». بالاخره در روز سوم ما توانستیم دو کاربر را برای هفته آخر اسفند هماهنگ کنیم و دو هفته مانده به تست ما 15 کاربر داشتیم که قرار بود در یک ساعت و روز مشخص در علی بابا حضور داشته باشند. تجربه به ما نشان داد که در دعوت از کاربران هم باید تجربه‌ای خلق کنیم که برای حس این تجربه حضوری به علی بابا بیایند.یک هفته تا شروع تست وقت داریملیست کاربران آماده بود اما ما هنوز آماده تست نبودیم. هر کدام از اعضای تیم، بخشی از کارها را به عهده گرفتیم؛ مدیر تیم کارهای زیرساختی، تهیه هدیه برای کاربران، هماهنگی برای ارسال ماشین و... را انجام داد. یکی از بچه‌ها پرسشنامه مقیاس کاربردپذیری سیستم (SUS) را آماده کرد؛ این پرسشنامه دارای 10 سوال است و هر سوال پنج مقیاس پاسخ‌دهی دارد که تک‌تک کاربران بعد از تست باید به این پرسشنامه پاسخ دهند تا مقیاس کاربردپذیری سیستم را بتوانیم با یک شاخص کمی به مالکان، مدیران و طراحان محصول ارائه دهیم.من سوالات قبل از تست و سناریوها را آماده کردم و در کمتر از یک هفته طبقه سوم ساختمان مطهری را برای اولین تست مهیا کردم. البته که مشکل فضا داشتیم؛ مثلا اتاق مدیر عامل را برای یک هفته به‌ عنوان اتاق مانیتورنیگ قرق کردیم.کتابخانه شرکت را به اتاق تست تبدیل کردیم؛ برای ارتباط اسکایپی اتاق تست با اتاق مانیتورینگ از تیم زیرساخت و تجهیزاتشان کمک گرفتیم. این تجهیزات شامل یک دوربین رویِ دست کاربران موبایل و یک دوربین روبه‌روی آنها بود که حرکات و حالات صورت کاربر را در حین کار با محصول ضبط می‌کرد و به صورت زنده در اتاق مانیتورنیگ برای افراد حاضر نمایش می‌داد. دو نرم افزار هم صفحه لپتاپ یا موبایلی که کاربر با آن کار می‌کرد را ضبط می کردند.تقریبا برای میزبانی از کاربران آماده بودیم که روز چهارشنبه از طرف تیم ایندرا به ما اعلام شد APIهای برخی از تامین‌کنندگان هنوز آماده نیست و شما می‌توانید فقط روی یک مسیر و تنها از یک ایرلاین خرید کنید. در واقع فهمیدیم تنها امکان تست روی یک محصول را داریم. به این ترتیب بود که آخرین ساعات کاری روز چهارشنبه به تغییر سناریوها و چاپ دوباره آنها گذشت.تجربه تجربه کاربری با کاربرانروز شنبه 19 اسفند 96 ساعت 10 صبح اولین کاربر برای تست کاربردپذیری وارد علی بابا شد، قرارمان این بود که کاربران قبل از ورود به اتاق تست، آماده شوند. به استقبال کاربران می‌رفتیم و در لابی طبقه سوم قبل از شروع تست آنها را آماده می‌کردیم. برای من که همیشه گزارش‌های این تست‌ها و تجربه سایر محققان را درباره تست شنیده بودم، تجربه بی‌نظیری بود و هر لحظه شگفت‌زده می‌شدم.قرارمان این بود که من در اتاق مانیتورینگ گزارش‌ها را بنویسم و همکارم کار تسهیل‌گری را انجام دهد. بعد از ورود کاربر به اتاق تست به او اعلام می‌کردیم که صدا و تصویرش در حال ضبط شدن است و در گزارش‌های ما اسمی از او آورده نمی‌شود؛ تا کاربر اجازه این کار را نمی‌داد رکوردی صورت نمی‌گرفت. اما قسمت جالب ماجرا اینجا بود که هیچ یک از کاربران ابراز ناراحتی نکردند و از دیدن فضای شرکت بسیار لذت می‌بردند. برای آشنا کردن تیم فنی و محصول با فرآیند تست و دیدن نحوه تعامل کاربران با سایت جدید، با ورود هر کاربر یکی از اعضای تیم فنی را به اتاق مانیتورینگ می‌آوردیم تا نتیجه کار خود را ببینند و این اولین قدم تیم تجربه کاربری برای افزایش تعاملات تیم فنی با کاربران واقعی و تیم تجربه کاربری بود کاربرانی که از دستمان لیز خوردند.عدد طلایی 5 حداقل تعداد کاربران مورد نیاز برای انجام یک تست کاربردپذیری است، اما فراموش نکنیم که ما برای هر دسته از کاربران و هر دیوایس به حداقل 5 نفر نیاز داشتیم؛ مثلا 5 نفر کاربر پر خرید موبایل و 5 نفر کاربر پرخرید دسکتاپ. اما برخی از کاربران با وجود هماهنگ‌های قبلی زمان تست حاضر نشدند و ما باید در وقت باقی‌مانده آنها را جایگزین می‌کردیم. دوباره سراغ لیست رفتیم و با کاربرانی که دفعه اول جواب تماسمان را نداده بودند، تماس گرفتیم و توانستیم دو کاربر را جایگزین کنیم.حس اولین بودننقطه عطف این تست برای ما لحظه‌ای بود که کاربر نسخه جدید سایت را در استیجینگ مشاهده می‌کرد و می‌پرسید: «یعنی من اولین کاربری هستم که سایت جدید علی بابا را می‌بینم؟». هیجان‌زدگی کاربر از «اولین بودن» برای ما جذاب بود و دستاوردش اطمینان کاربر برای بیان تجربیات قبلی و فعلی از کار با سایت بود که بعدها ما را در توسعه محصولات و ویژگی‌های‌شان یاری کرد.دستاورد این تست برای علی بابااین تست به ما کمک کرد که مشکلات کاربر با طراحی جدید را قبل از رونمایی از سایت پیدا کنیم و با اولویت به آنها بپردازیم و تجربه بهتری را با سایت جدید ارائه دهیم. برای مثال یکی از اصلی‌ترین مشکلات کاربران فرایند انتخاب پرواز «رفت و برگشت» بود که این فرایند قبل از لانچ نهایی وب سایت جدید تغییرات اساسی داشت.از نظر شرکت‌ها در اسکیل جهانی و ایران تست کاربردپذیری از پر هزینه‌ترین تست‌های تجربه کاربری است، اما تجربه بعد از لانچ به ما نشان داد که این هزینه در مقابل هزینه‌ای که بعدها برای ریز‌‌ش‌های کاربران به دلیل تجربه بد کاربری خواهیم پرداخت، بسیار اندک است. تست‌ها در علی بابا ادامه پیدا کرد و به یک فرهنگ تبدیل شد؛ فرهنگ «UCD یا همان طراحی کاربرمحور».در قسمت بعدی به یکی از بزرگ‌ترین و کامل‌ترین تست‌های کاربردپذیری انجام شده در ایران که در اردیبهشت امسال در علی بابا انجام شد، می‌پردازم و تجربه متفاوت‌تری را به اشتراک خواهم گذاشت. پشت صحنه تیم محصول علی بابا نیره افضلی Sat, 07 Dec 2019 20:35:35 +0330 https://virgool.io/alibaba-product/%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%D8%B3%D8%A7%D8%AE%D8%AA%D9%86-%D9%85%D8%AD%D8%B5%D9%88%D9%84%DB%8C-%DA%A9%D9%87-%D8%B3%D8%A7%D8%AE%D8%AA%D9%86%D8%B4-%D8%B1%D8%A7-%D8%A8%D9%84%D8%AF-%D9%86%D8%A8%D9%88%D8%AF%D9%85-mydkxrpmpyzq شاید بارها داستان شکل‌گیری استارتاپ‌های مختلف را شنیده باشید، اما شکل‌گیری یک استارتاپ درون یک استارتاپ بزرگ‌تر می‌تواند داستان متفاوت‌تری باشد.برای من که مدت طولانی در زمینه گردشگری فعالیت می‌کردم، چیزی جذاب‌تر از معرفی ایران و ارائه تجربه ناب ایرانگردی به خارجی‌ها وجود نداشت. جای خالی «هلوپرشیا» در علی بابا حس می‌شد. هلوپرشیا پلتفرم معرفی و فروش تجربه ایرانگردی به مسافران خارجی است. هرچند سازمان به جذابیت این بازار واقف بود و این پروژه در راستای چشم‌انداز علی بابا یعنی «خلق ثروت برای مناطق محروم و در عین حال بکر کشور» قرار داشت، اما شروع پروژه و سرمایه‌گذاری به نظر ساده نمی‌رسید.دیتا کلید راضی کردن مدیران ارشدپیش از این در علی بابا تجربه شکست یک محصول پلتفرمی را داشتیم که زمان زیاد و هزینه بالایی برایش صرف شده بود و همین جلب اعتماد سازمان را سخت تر کرده بود. پلتفرم به مدلی اطلاق می‌شود که مبادلات بین چند گروه (در مدل ما تامین‎کننده‌های تور و مشتری) را تسهیل می‌کند؛ در واقع برخلاف مدل‌های خطی، به جای تمرکز بر مفهوم تولید، روی مفهوم ارتباط تمرکز دارد.برای Pitch deck در مورد اطلاعات کلی بازار، نقاط ضعف و قدرت، اندازه بازار و مدل درآمدی با مدیران ارشد گفت‌گو کردم اما نبود اطلاعات کافی از بازار و مشتری و رقبا شروع سرمایه گذاری از طرف مدیران ارشد را سخت کرده بود. برای کم کردن ریسک، روی میزان بودجه مورد نیاز تا رسیدن به MVP محصول، تست آن و نقطه سربه‌سر متمرکز شدم.نمایی از وب سایت هلوپرشیاروز اول محصولکار اصلی تازه شروع شده بود و ما هنوز هیچ منبعی برای ساختن محصول نداشتیم. پروسه جذب نیروی برنامه‌نویس شروع شد اما طبق تجربه زمان زیادی طول می کشید که یک نفر جذب شود. در آن زمان ما هنوز روش استانداردی برای توسعه یک محصول جدید نداشتیم.محمدعلی در مورد روشی که یک سال بعد در علی بابا از آن استفاده کرده تا به ساخت یک محصول جدید در یک ساختار سریع برسد، توضیح داده است.علی بابا نتیجه‌محور بود و این آزادی عمل را به افراد می‌داد تا با روشی که انتخاب خودشان است، راهکار را پیدا کنند برای همین تصمیم گرفتیم تا پیدا شدن توسعه دهنده از ظرفیت خود شرکت استفاده کنیم. بودن در علی بابا کمک می‌کرد به تعداد زیادی برنامه‌نویس و متخصص که به ساختار آشنایی کامل داشتند، دسترسی داشته باشم و همین می‌توانست سرعت ما را بیشتر کند. من با تعدادی از همکاران برنامه‌نویسم صحبت کردم؛ با هماهنگی مالک محصول تیمشان، دو نفر از آنها همراه ما شدند تا بخش کمی از زمانشان را به این محصول اختصاص بدهند. با حضور نیروهای اشتراکی، کار با سرعت خیلی کمی جلو می‌رفت.در نهایت مصمم بودن ما برای تولید این محصول سازمان را ترغیب به بالا بردن اولویت جذب برای هلوپرشیا کرد. طی یک ماه یک نفر برنامه‌نویس به صورت اختصاصی به تیممان اضافه و ابتدای مهر 97 نسخه اولیه سایت بعد از حدود دو ماه منتشر شد. از این جا پیشرفت محصول سرعت چند برابری گرفت. Simple yet significantشاید بارها شنیده باشید اگر از نسخه اولیه محصولتان خجالت‌زده نیستید، یعنی خیلی دیر آن را به بازار عرضه کرده‌اید. با حضور در یک مجموعه بزرگ که همه تیم‌ها به‌صورت تخصصی کار می‌کردند و پای محصولات بالغی مثل سایت علی بابا و جاباما در میان بود، ابتدا تصورم از محصول موفق، محصولی بود که شامل همه خدمات گردشگری و مجموعه‌ای از فیچرهای رنگارنگ باشد.در ابتدا قرار بود یک علی بابای خارجی داشته باشیم که شامل تعداد زیادی محصول و فیچر می‌شد. اما وقتی شروع به ساختن محصول کردیم مجبور به انتخاب شدیم. قدرت «نه گفتن» شاید مهم‌ترین توانایی من شد؛ و بعد از یک سال، این سوال هر روزم شده است: «با منابع موجود چه طور می‌شود بیشترین ارزش را خلق کرد؟»نسخه اولیه هلوپرشیا خیلی ساده بود و کاربر فقط می‌توانست خدمت ویزا را خریداری کند؛ فرآیند آفلاین اما باکیفیت انجام می‌شد و مشتری به موقع ویزایش را دریافت می‌کرد.چرا و چطور مدیر محصول شدم؟من نه از برنامه‌نویسی سر در می‌آوردم و نه از دیتا اطلاعات زیادی داشتم؛ نه بازاریابی را خوب بلد بودم و نه از طراحی سررشته ای داشتم. حدود یک سال و نیم بود که در علی بابا در تیم‌های مختلف تامین و فروش تور مشغول به کار بودم و همیشه اشتیاق کار در حوزه محصول در من وجود داشت.کسانی که در حوزه محصول فعالیت دارند یا بنیان‌گذار یک استارتاپ هستند می‌دانند که فعالیت در زمینه محصول نیازمند دانش جامعی از همه رشته‌هاست. اولین قدم این بود که دست به کار شوم و سخت مطالعه کنم. از آن جایی که تیم‌های توسعه علی بابا طبق متد اسکرام برنامه‌ریزی می‌کردند، اولین دوره‌ای که شروع کردم اسکرام بود. بعد از آن دوره‌های آنلاین تجربه کاربری و آموزش تعدادی از ابزارها را گذراندم. در کنار همه اینها، همکارانم در علی بابا از هیچ کمکی دریغ نکردند و من با سرعت به هدفی که داشتم نزدیک‌تر شدم. اگر واقعا به محصول علاقه‌مندید، ورود به این حوزه کار سختی نیست.«اشتباه کردن» اشتباه است؟در دنیایی که هیچ چیز قابل پیش‌بینی نیست چطور می‌توانیم انتظار داشته باشیم همه چیز عالی و بی‌نقص پیش برود؟ در ابتدای کار از مسئولیت به ثمر رساندن محصول بارها و بارها ترسیدم. یک روز برای مقابله با ترسم، هر موردی را که در شغلم اشتباه کرده بودم و البته عواقب آنها را لیست کردم. جالب بود که هیچ اتفاق بدی غیر از سرزنش خودم نیفتاده بود.مدیران علی بابا این فضا را فراهم کرده اند که اعضا به جای ترسیدن از شکست، آن را به عنوان مسیر راه ببینند. سه سال گذشته را در مجموعه‌ای سپری کردم که بنیان‌گذارانش در جمع بزرگ همکاران به اشتباهاتشان اعتراف می‌کنند و برای جبران آن قول می‌دهند.یکی از اشتباهاتمان این بود که در ابتدا همه تمرکز تیم به توسعه محصول معطوف بود و در اولویت‌بندی اضافه کردن خدمات، تناسب محصول با بازار را در نظر نگرفته بودیم؛ بنابراین توسعه محصولمان جلوتر از بازاریابی پیش می‌رفت. هرچند اتلاف هزینه داشتیم اما آگاه شدن به موقع از اشتباه و تغییر مسیر در جهت درست کمکمان کرد تا از باتلاق نجات پیدا کنیم. برای همین وزن تیم را سمت تامین و فروش بیشتر کردیم تا بیش از این بازار را از دست ندهیم.ساختن رویای خودم یا رویای مدیرمابتدای راه یک کسب‌وکار یا محصول، یک منتور خوب می‌تواند همراه فوق‌العاده‌ای باشد؛ در این راه من از مدیرعامل و چند نفر از مدیران محصول سازمان کمک می‌گرفتم. حضورشان فوق‌العاده بود، اما در شروع که تجربه کمی داشتم، نظرات افراد مختلف تاثیر زیادی روی تصمیماتم می‌گذاشت به خصوص اگر از سمت مدیریت ارشد سازمان بود. این تاثیرگذاری بالا دو علت داشت؛ هم به این دلیل که توان تصمیم‌گیری این افراد را بهتر از خودم می‌دیدم و هم به این علت که در نهایت مدیران را مسئول تصمیم‌گیری‌ها می‌دانستم.در فرهنگ علی بابا، هیچ بهانه‌ای قابل قبول نیست و برای رسیدن به آینده خلق شده، همه در بستر چهار اصل «عاملیت»، «تمامیت»، «روراستی» و «تعهد به چیزی فراتر از خود» تمرین می‌کنیم. آنچه به مرور متوجهش شدم این بود که همه مسئولیت نتیجه بر عهده خودم است و هیچ بهانه‌ای از جنس «شما این طور گفتید» یا «سازمان این طوری است» وجود ندارد. «مسئولیت تمام و کمال یک محصول را برداشتن» سخت اما بی نظیرترین تجربه کاری من تا امروز بوده است.محصول یک مدیر محصول، تیمش استساختن یک نرم‌افزار شاید ساده‌ترین قسمت ساختن محصول باشد. در حالی که فراهم کردن بستری که اعضای تیم بتوانند در جهت رودمپ با هم تعامل موثر داشته باشند و آینده را بسازند، سخت‌ترین اما باارزش‌ترین بخش آن محصول است. امروز سرمایه ما یک تیم پر انرژی است که پر قدرت به سمت آینده خلق شده حرکت می کند. پشت صحنه تیم محصول علی بابا Hafseh Ahrari Sat, 23 Nov 2019 20:20:32 +0330 https://virgool.io/alibaba-product/%DA%A9%D8%A7%D8%B1-%D8%A8%D8%A7-%D9%85%D8%B9%D9%86%D8%A7-%D8%B9%D9%85%D9%84%DA%A9%D8%B1%D8%AF-%D9%85%D8%A7-%D8%B1%D8%A7-%D9%85%D8%AA%D8%AD%D9%88%D9%84-%D9%85%DB%8C%DA%A9%D9%86%D8%AF-vm1y6zqfrvds تولد "کار با معنا"5 آذر ماه 97 بود. یک روز بعد از حادثه تلخ زلزله سر پل ذهاب. از آن روزها که وقتی صبح پشت میزت می‌نشینی دلت نمی‌خواهد چشمت به هیچ سایت خبری بیفتد. صحنه ها تلخ است و دلخراش. کودکان گریان، مادران داغدار، مردان درمانده و هموطنی که زندگی اش در عرض چند ثانیه زیر و رو شده است. دردناک‌تر زمانی است که شغلت فروش بلیط است و ناگهان با هموطنانی از نوع دیگر روبرو می‌‌شوی که حتی ازگرفتن ماهی‌های این آب گل آلود هم نمی گذرند. جستجو میکردیم بلیط "تهران به کرمانشاه" و با قیمت‌های نجومی روبرو می‌شدیم. دلگیر بودیم و ناخشنود و البته عصبانی. به این فکر می‌کردیم نقش ما به عنوان علی بابا در این اتفاق چه می‌تواند باشد؟ ما کجای این معادله سراسر نا عادلانه قرار گرفته ایم؟در عرض کمتر از یک ساعت تصمیم بر این شد که هزینه خرید بلیط هواپیما برای هر پرستار و پزشک داوطلب اعزام به کرمانشاه به صورت رایگان توسط علی بابا پرداخت شود و بلیط برای داوطلبین صادر گردد.در شرایط معمول پیاده سازی این فیچر حداقل چهار روز زمان نیاز دارد. از هماهنگی‌های واحد‌های مالی و پشتیبانی گرفته تا توسعه صفحات لازم و گرفتن منابع زیر ساختی و برنامه ریزی و تست و اجرا، و تازه این تسک خارج از اسپرینیت بود که دوستان اجایلی می‌دانند عبور از چه خط قرمزی است.اما به جرات می‌توانم بگویم آن روز بهترین روز کاری همه ما بود. تقسیم کار در عرض چند دقیقه انجام شد، تیم بازاریابی مسئول اطلاع رسانی در رسانه های مرتبط شد با این خط قرمز که از این اقدام به عنوان PR استفاده نخواهد شد. مالی عهده دار تامین مبلغ و بودجه مربوطه شد. پشتیبانی شیفت‌های فوق العاده ترتیب داد و تمامی کارکنان داوطلب حضور 24 ساعته خارج از شیفت کاری خود شدند. تیم توسعه نه شکایت کار خارج از اسپرینت کرد و نه داکیومنت تحلیل طلب کرد. زیر ساخت سرور داشت و دواپس مرج ریکوِست‌ها را خارج از برنامه کامیت کرد. هر کس نمی‌توانست بخشی از کار را انجام دهد فرد دیگری بلافاصله جایگزین می‌شد.تا قبل از ظهر یک صفحه در سایت بالا بود تا مدارک پزشکان در آن آپلود شود. مدارک در عرض چند ثانیه تایید می‌شد و بلیط به دست داوطلبین می‌رسید.درست است که از لحاظ فنی کار دشوار و پیچیده ای نبود. اما کاری که انجام آن در شرایط عادی حداقل چهارروز زمان نیاز داشت در عرض کمتر از 3 ساعت انجام شده بود. ما همه حس غرور می‌کردیم و در آن چند ساعت عاشق ترین کارمندان روی زمین بودیم. و بعد از انجام آن آنچنان حس رضایتی داشتیم که می‌توانستیم چندین روز بی وقفه کار کنیم.تجربه کوچکی است اما برای من درس‌های مهمی دارد. "معنا در کار" می‌تواند عملکرد افراد را متحول کند. ظرفیت کار تیمی را دگرگون کند و ارتباطات درون سازمانی را به شکل فوق العاده ای بهبود بخشد. تفاوت آن چند ساعت با بقیه روزهای کاری ما در چند موضوع به ظاهر کوچک اما عمیق و پر اهمیت است:1- کاری که انجام دادیم برای ما سرشار از "معنا" بود.2- همگی بر سر آن "معنا" هم نظر بودیم و در یک صفحه قرار داشتیم.3- کاری که انجام دادیم ما را به "به فراتر از خود" متعهد کرده بود.4- نتیجه کار بسیار ملموس بود.هر فرد مسئولیتش را به روشنی می‌دانست و تاثیر کارش را به وضوح می‌دید.5- در انجام این کار هیچ اجبار خارجی وجود نداشت. انتخاب به عهده افراد بود6- تیم یکپارچه بود و هیچ ساختار سلسله مراتبی وجود نداشت.بلوغ "کار با معنا"با من همراه شوید و یک روز کاری معمولی را تصور کنید: صبح پشت میزتان می‌نشینید و قرار است استوری های اسپرینت بعدی را تعریف کنید دغدغه تان ولوسیتی تیم و کارهای در حال انجام وبک لاگ مفصل و فیچر‌های آماده لانچ است. به نمودارهای جیرا خیره شده اید و به مکالمات جلسه رترو بعدی با تیمتان فکر می‌کنید. تجربه کار با معنا برایتان تبدیل به یک خاطره دور شده است که با یاد آوری آن نهایتا لبخندی بر لبتان می‌آید و آهی می‌کشید و به دوردست خیره می‌شوید. با خود فکر می‌کنید چرا استوری‌ها را با معنا نکنم؟ خلق معنا برای مسئولیت‌های روزانه، بهره وری تیم را متحول نخواهد کرد؟ "چگونه می‌شود این معنا را برای کارهای روزانه و یا هفتگی و یا هر اسپرینت برای تیم ایجاد کرد؟شاید با معنا کردن کارهای روزانه راه حلی برای یافتن رضایت شغلی و افزایش بهره وری تیمی و متحول کردن قابلیت‌های حرفه ای تیممان باشد. با این چالش همراه شوید و این بار شما بگویید این استوری را چگونه "با معنا" می‌کنید:"ارسال اس ام اس به مسافران در صورت تغییر ساعت پرواز تا مسافرین در ساعت مقرر پرواز در فرودگاه حاضر شوند." پشت صحنه تیم محصول علی بابا آرزو قانع Sat, 02 Nov 2019 17:58:01 +0330 https://virgool.io/alibaba-product/prioritize-backlog-part2-udexyi7nfzog در قسمت قبلی درباره این نوشتم که چطور یک بک‌لاگ ۳۰۰‌ تایی را با ماتریس اولویت بندی به ۸۰ مورد رساندم. اما مسئله اینجا بود که ما برای اسپرینت بعدی در بهترین حالت تنها به انجام ۱۰ مورد می‌رسیدیم و هنوز نتوانسته بودم خوراک اسپرینت بعدی را آماده کنم. اینجا بود که به سراغ یک اولویت بندی دقیق رفتم و چون منبعی پیدا نکردم پس ساختار اولویت بندی مخصوص خودمان را ساختم. ممکن است انتخاب شده در اولویت بندی مسیر محصول را به کلی عوض کند.چارچوب اولویت بندی همپ۲برای اولویت بندی ابزارهای زیادی را زیر و رو کردم و با اطمینان می‌توانم بگویم هیچ سایت و ابزاری برای اولویت بندی کارها ساخته نشده است. تنها محصولی که این کار را با کیفیت انجام می‌دهد Product plan است که ماهانه مبلغی را برای اشتراک دریافت می‌کند.وقتی که دیدم با ماتریس اولویت بندی به هدفم (که ساخت اسپرینت هفته آینده بود) نرسیدم و هر روز هم بک‌لاگ طویل‌تر می‌شد، آستین‌ها را بالا زدم که تا مدل مخصوص خودمان را بسازم. همان ایده Product Plan را با کمی شخصی سازی در یک فایل اکسل پیاده سازی کردم و سعی کردم چندتا از مهمترین کارها را از این طریق اولویت بندی و مستند کنم. وقتی که از کارکرد درست آن مطمئن شدم موضوع را با مدیر محصول در میان گذاشتم و بعد از همراستا شدنمان همه چیز برای اولویت بندی اولین اسپرینت آماده بود.چارچوب همپ۲ چطور کار می‌کند؟در همپ۲ هزینه و منفعت به دقیق‌ترین شکل ممکن تحلیل می‌شود. در حقیقت این یک مارتیس اولویت بندی کامل‌تر است و هزینه و منفعت به قسمت‌های بیشتری شکسته شده تا بتوان در مواقعی که حجم کارها بیشتر است به صورت موثرتری اولویت بندی را انجام داد. بهتر است این چارچوب را به خاطر زمان گیر بودن بعد از ماتریس اولویت انجام دهید. هر کدام از این‌ها به موارد جزئی تری تقسیم می‌شود که ضریب مخصوص به خودشان را دارند و بر اساس استراژی بازار و محصول تعیین می‌شوند. اینجا یک نسخه از این چارچوب قابل دانلود است.نمونه‌ای از چارچوب همپ۲هزینهدرست کردن یک فیچر و قابلیت همواره هزینه‌هایی دارد و زمان بر است. از دست دادن زمان ارزش کار را کم می‌کند. با همین منطق مهم است که اول کارهایی را انجام دهیم که هزینه کمتری دارد. با تجربه این مدت به این نتیجه رسیدم که ساخت قابلیت از ۴ شکل هزینه تشکیل شده است:پیاده سازی فنیمهمترین مسئله‌ای که برای ساخت یک فیچر هزینه ایجاد می‌کند پیچیدگی‌های فنی است گاهی یک مسئله به نظر ساده می‌رسد اما برای انجام آن به تغییرات ساختار دیتابیس و معماری سیستم نیاز دارید و همین موضوع ممکن است شما را از پیاده سازی منصرف کند یا فیچر را به تعویق بیندازد چرا که با کارهای کوچک‌تری می‌توانید دستاوردهای بزرگتری به دست آورید. تحلیل بیزینسیگاهی ایده‌ای که وارد بک لاگ می‌شود آن قدر پیچیده است که حتی ابعاد بیزینسی آن هم مشخص نشده است یا مشخص شده و لازم است که چندین جلسه با چند شرکت خارج از مجموعه گذاشته شود یا تاییده‌هایی گرفته شود. همین موضوع فرآیند ساخت را پیچیده می‌کند.افزایش عملیاتگاهی ایده با وجود هزینه کم پیاده سازی و یا بیزینسی سربار عملیاتی زیادی دارد. مثلا قابلیت چت با پشتیبانی می‌تواند به ارتباط بهتر شما و مشتری و حتی فروش بیشتر کمک کند اما احتیاج به چند فرد تمام وقت دارد که همیشه آماده پاسخگویی باشد. یا مثلا برای ما قابلیت نظارت بر محتوا با آنکه به کیفیت کار کمک می‌کند اما هزینه‌های عملیاتی زیادی را تحمیل می‌کند که می‌تواند تعدم یا تاخیر یک کار را تغییر دهد.ریسکبسیاری از قابلیت‌ها حتی بعد از تحلیل دارای ریسک‌های پیدا و پنهانی هستند. مثلا همین قابلیت نظارت هرچند کیفیت کار را افزایش می‌دهد اما فرآیند را وابسته به عملیات انسانی می‌کند که ممکن است در حجم کار بالا با اختلال روبرو شود و سیستم منهدم شود. یا حذف فرآیند نظارت فواید بسیاری در کاهش هزینه‌ها دارد و هزینه عملیات را کم می‌کند اما ریسک انتشار محتوای اشتباه را بالا می‌برد.منفعتدرآمددرآمد مهمترین هدف هر کسب و کاری است اما شاید گاهی تصمیم شما این باشد که بی خیال درآمد شوید و کارهای استراتژیک که سهم بازار بیشتری به شما می‌دهد و محصول و خدمات شما را معروف تر می‌کند انتخاب کنید.ارزش به کاربرتعداد زیادی از فیچرهایی که پیاده سازی می‌کنید در راستای استفاده راحت‌تر کاربر از محصول شماست. این مورد به صورت غیر مستقیم روی درآمد و سهم بازار هم تاثیر می‌گذارد اما میزان آن به شدت کمتر است. به طور مثال قابلیت Night mode یکی از ویژگی‌هایی است که جدیدا در بسیاری از محصولات رایج شده و در استفاده‌های شبانه حس خوبی به کاربر می‌دهد اما به احتمال زیاد منفعت دیگری ندارد ممکن است وضعیت محصول یا سازمان شما در حالتی باشد که صرفا به دنبال یک تجربه خوب برای مشتری باشید در این صورت ضریب این بخش بیشتر می‌شود.استراتژیک و زمان ورود به بازاراینکه الان موقع پیاده سازی چه فیچری است تا سهم بازار بیشتری بگیرید و محصول خود را بهتر جا بیندازید مسئله مهمی است که می‌تواند به کل کسب و کار شما جهت دهد. بنابراین این مورد احتمالا همیشه بیشترین ضریب را در تحلیل شما خواهد داشت. مخصوصا در محصولاتی که به بلوغ نرسیده‌اند مهمترین مسئله این است که الان زمان ارائه چه چیزی فرا رسیده است.کاهش عملیاتمعمولا یکی از مهمترین معیارهای محصولات جدید و استارتاپ‌ها این است که بدون رشد هزینه‌های عملیاتی و سربار کسب و کار خود را رشد دهند. در حقیقت برای ده برابر کردن فروش لازم نباشد نیروهای انسانی و ماشین آلات هم ده برابر شود برای همین یکی از مهمترین منفعت‌های یک فیچر این است که چقدر هزینه‌های عملیاتی را کاهش می‌دهد.درخواست سازمانالبته که همیشه اوضاع بر وفق مراد نیست گاهی سازمان مسائلی را می‌خواهد که هیچ کمکی به محصول شما نمی‌کند اما در هر صورت لازمش دارد. مثلا بارها پیش آمده که مجبور شدیم خودمان را با سیستم مالی پیچیده یا زیر ساخت نرم افزاری شرکت تطابق دهیم در حالی که عملا هیچ سودی برای فروش و کاربر نداشته اما سازمان این مسئله را از ما می‌خواسته است.پرسوناکشف پرسونای کاربران یکی از وظایف مدیر یا مالک محصول است. این کار به شما و تیم توسعه کمک می‌کند بدانید دقیقا فیچرهایی که در حال توسعه آن‌ها هستید را برای چه کسی تهیه می‌کنید. اگر یک پیرمرد ۸۰ ساله مخاطب شماست نیاز است تدابیر دیگری بیندیشید و اگر یک نوجوان ۱۸ ساله مخاطب شماست همان نیازمندی‌های شما طور دیگری نمود پیدا می‌کند. البته پرسونا مبحث بزرگی است اما همین حد سطحی هم می‌تواند به شما کمک کند.هدفمهمترین مسئله توسعه محصول این است که این کار را آگاهانه و با تسلط کامل بر استراتژی انجام دهید. پس برای هر تغییری به دنبال هدفی هستید. شاید هدف شما سهم بازار بیشتر باشد. مثلا ما با قابلیتی مثل «ذخیره شدن دیتای فیلترها و سرچ‌ها» به دنبال داده‌محور کردن تصمیمات مان بودیم و این هدف را با ده فیچر دیگر هم دنبال می‌کردیم. این ستون کمک می‌کند کارها را بهتر به هم مرتبط کنید و اگر زمانی هدف تان تغییر کرد سریع اولویت‌بندی را تغییر دهید.متریکاگر ندانید کجا می‌روید هر مسیری شما را به مقصد می‌رساند. هنگام پیاده سازی فیچری قطعا دنبال این هستید که متریک و معیاری را تغییر دهید. من با قابلیت «بهبود نمایش تماس با سفریار» دنبال این بودم که تماس مشتری با سفریارها را افزایش دهم. اگر ندانید چه چیزی را اندازه می‌گیرید هر تغییری برای شما مثبت به نظر می‌آید. یا مثلا با قابلیت «دکمه ثبت نام سفریار» دنبال این بودم که تعداد ثبت‌نام‌های سفریارها را افزایش دهم و وقتی این نتیجه را نگرفتم و صرفا بازدیدها را افزایش دادم یعنی این متریک تکان نخورده و من را به هدفم که رشد سفریارها بدون هزینه مارکتینگ بوده نرسانده است.پیش بینیپیش بینی شما این است که با این بهبود متریکی که برایتان مهم است چقدر و چند درصد جابجا شود؟ این پیش بینی کمی کمک می‌کند دقیقا انتظار خودتان را از کار بدانید. من انتظار داشتم دکمه ثبت نام سفریار، تعداد درخواست‌ها برای ثبت نام را ۲۰ درصد افزایش دهد اما وقتی پس از انتشار و اندازه گیری این بهبود فقط ۵ درصد بود متوجه شدم که این مسئله با پیش بینی‌هایم جور در نمی‌آمد و باید کار دیگری کرد.اینجاست که مهمترین کارتان به عنوان مالک یک محصول نوپا می‌شود «انتخاب». در فضای ناپایدار تجاری هر انتخاب اشتباهی می‌تواند شما را یک قدم از رقیب عقب بیندازد. هرچند انتخاب‌های اشتباه عواقب جبران ناپذیری دارند اما این مسئله ناگزیر است. آنچه بین یک مالک محصول موفق و ناموفق تمایز ایجاد می‌کند قدم بعدی بعد از هر اشتباه است، کاری که محصول را از یک مسیر دردناک اما میان بر عبور می‌دهد. پشت صحنه تیم محصول علی بابا امیر اچ پی Thu, 17 Oct 2019 12:56:51 +0330 https://virgool.io/alibaba-product/how-prioritize-backlog-x9fwb9ext0dj هنگامی که عنوان مالک محصول وارد علی بابا شدم و یک بورد جیرا با ۳۰۰ مورد بک‌لاگ مقابلم قرار گرفت، برای من که درباره فروش آنلاین تور خارجی هیچ ایده‌ای نداشتم، بسیار گیج‌کننده بود. از طرف دیگر محصول در دوران رشد خود قرار داشت و مثل قطاری که بی‌وقفه و پرسرعت در حرکت است؛ تیم در لحظه مشغول ریل‌گذاری بود و بدتر از همه اینکه هنوز معلوم نبود آبادی کجاست. به همه اینها این مورد را هم اضافه کنید که قطار به خاطر تعجیل در ورود به بازار در باتلاقی فنی گیر افتاده بود و هرچه سرعتش بیشتر می‌شد، بیشتر در باتلاق فرو می‌رفت وتیم فنی نیاز داشت مدتی روی زیرساخت محصول کار کند.خوشبختانه آنچه که ساخته شده بود به خوبی توسط تیم عملیات استفاده شده و روزانه فروش قابل قبولی روی آن انجام می‌شد، اما فروش به خاطر کمبودهای محصول به سقف خود رسیده بود و رد کردن آن سقف نیازمند تغییرات جدی در فرآیندها بود. اینجا بود که دیگر بودن و عملکرد قبلی جوابگوی آنچه به دنبالش بودیم نبود. مالک محصول دروازه بان ایده‌هامالک محصول وظایف مختلفی دارد. به قول Agile coach شرکت اگر بخواهیم همه آن‌ها را کوتاه کنیم می‌شود دو کلمه: Maximizing valueالبته می‌توان این دو کلمه را بسط داد و به عبارات زیر رسید:مدیریت بک‌لاگ محصولارتباط با مشتریمرتب کردن موردهای بک‌لاگ محصولتوضیح موارد به همه (توسعه‌دهنده‌ها، مشتریان و ...) نمایش مواردی که تیم اسکرام در اسپرینت بعدی روی آن کار می‌کندمطمئن شدن از اینکه محصول در راستای چشم انداز و رودمپ حرکت می‌کندبرگزاری جلسات شفاف سازی بک‌لاگ محصولاعتبار بخشیدن به آیتم‌هااندازه گیری بهره‌وری پروژهبررسی بودجه در پایان هر اسپرینتبا توصیفات بالا حالا اگر منابع و زمان کم باشد دو کلمه «بیشینه کردن ارزش» بیشتر به چشم می‌آید. ممکن است در مثل من ابتدای کارتان به عنوان مالک محصول شروع به شناخت سیستم کنید و بعد از مدتی تحلیل‌های جذابی هم بنویسید. اما اگر متوجه شوید که همواره «مشکلات زیاد است و منابع کم» کابوس هرشبتان این می‌شود که آیا کارهایی که برای این اسپرینت انتخاب کردید «بیشترین ارزش ممکن» را خلق می‌کرد؟ و احتمالا هر روز در مسیر برگشت به خانه به «نه‌»هایی که می‌توانستید به ایده‌های مختلف بگویید و نگفتید، فکر می‌کنید.ماجرا وقتی آزاردهنده‌تر می‌شود که چون با گذر زمان ارزش کارها کم می‌شود و جهان به سمت بهینگی دائمی می‌رود، ریسک اولویت‌بندی اشتباه در زمان ضرب می‌شود و عدم تمرکز استراتژیک هر روز عواقب بیشتری را رقم می‌زند. ممکن است فروش‌تان را کم کند، باعث شود بازاری را از دست بدهید یا بدهی‌های سازمانی یا فنی روی دستتان بگذارد.چطور از شرایط عدم قطعیت اندکی خارج شدم؟هنگامی که وارد محصول تور شدم در بک‌لاگ محصول نزدیک به ۳۰۰ مورد دیده می‌شد که تیم قصد داشت انجامش دهد. تصور کنید چه حجم عظیمی از کار وجود داشت و من هم هیچ ایده‌ای نداشتم که باید کدام یک را زودتر در اسپرینت بعدی انجام بدهم.این برای من بهترین فرصت بود تا بیشتر در زمینه اولویت‌بندی کارها عمیق شوم و راه‌حلی که در شرکت قبلی دست و پا شکسته انجام داده بودم را این بار عمیق‌تر و دقیق‌تر اجرایی کنم.البته برای رسیدن به این هدف بک‌لاگ اولویت‌بندی‌شده قبلی را به کلی کنار گذاشتم و تمامی آیتم‌ها را از نو با ذی‌نفعان چک کردم؛ در این مسیر تعداد زیادی از آیتم‌ها حل شده بود، تعدادی هم اصلا مشکلی نبود که لازم باشد راه‌حلی برایش پیدا کرد و تعدادی هم با همین محصول فعلی قابل حل بود. منطق این مرتب سازی چیست؟تصور کنید به صورت غریزی قصد دارید کارها را اولویت‌بندی کنید، احتمالا اصلی ترین روش شما این است: که با این کار چقدر سود می‌برم؟ماتریس چهارخانه‌ای یکی از معروف‌ترین و ساده‌ترین روش‌ها برای اولویت‌بندی کارهاست. این ماتریس را می‌توان به شکل‌های مختلف پر کرد که معروف‌ترین آن هزینه و فایده است.اولویت بندی بر اساس ماتریس سود/هزینهطبق این ماتریس مهم‌ترین اولویت برای کارهایی است که سود زیادی دارند و منابع کمی مصرف می‌کنند. اینها کارهایی هستند که بدون فوت وقت باید انجام دهید و پیدا کردن به موقع و انجامشان می‌تواند شما را به یک برد سریع برساند. بعد از آن سراغ کارهایی رفتم که هرچند منابع زیادی می‌خواستند اما برای ما ارزش زیادی هم داشتند که به خاطر پیچیدگی و اساسی بودنشان بود. یکی از اشتباهات من این بود که از این مرحله عبور می‌کردم که مبادا در فرآیند پیچیده‌ای بیفتم و منابع هدر برود. به خاطر پیچیده بودن از این کارها نترسید و به این بهانه همواره آخر لیست قرارشان ندهید. این دو مهم‌ترین کارهایی هستند که باید در اولویت‌بندی در نظرشان بگیرید.بعد از این موارد طبعا سعی کردم به هیچ وجه سراغ کارهایی که دستاورد پایینی دارند و منابع زیادی مصرف می‌کنند، نروم. اما چاله‌ای که معمولا بسیاری از تیم‌ها در آن می‌افتند و تیم ما و خود من هم چند بار گرفتارش شدیم آخرین بخش ماتریس است: «کارهایی که هرچند منابع کمی مصرف می‌کنند و سریع می‌توان انجامشان داد اما فایده کمی هم دارند». مثل تغییر بی‌دلیل رنگ یک دکمه یا جابه‌جایی یک بنر؛ یا حتی کارهای پیچیده‌تری که معمولا با این استدلال که «زمان زیادی نمی‌گیره» وارد بک‌لاگ اسپرینت می‌شوند اما در حقیقت فایده‌ای برای محصول ندارند و با این دام «سریع می‌شود انجامشان داد» زمان شما و تیم را می‌گیرند.یک آفت دیگر هم این است که کارها را به جای اینکه درست (یعنی به صورتی که دوباره نخواهید به سراغشان بیایید) انجام دهید آن‌ها را به خانه LL ماتریس بیاورید. البته این به این معنا نیست که بی خیال MVPها شوید. اینجاست که هنر مالک محصول به عنوان کسی که مرز MVP و چگونگی انجام آن را تشخیص می‌دهد نمایان می‌شود. اولویت بندی بر اساس ماتریس فوریت/اهمیت ماتریس بعدی مخصوصا در محصولاتی که بالغ شده‌اند به کار آید. این ماتریس بر دو اساس فوریت و اهمیت کارها را مرتب می‌کنند. هنگامی که در یک سازمان بزرگ کار می‌کنید روزانه کارهای زیادی با فوریت بالا به سمت شما می‌آید که الزاما اهمیتی برای آینده محصول ندارند یعنی فوری هستند اما مهم نیستند. اینجاست که با این ماتریس می‌توانید ذی‌نفعان را راحت‌تر قانع کنید و کارهایی که صرفا اولویت بالایی دارند را در ابتدای لیست نگذارید. آنچه مالکان محصول را تهدید می‌کند افتادن به دام کارهای فوری است این کار باعث می‌شود محصول شما هیچ وقت فراتر از آنچه بوده نرود و دچار روزمرگی و رفع باگ‌های مداوم شوید. با این دو ماتریس توانستم بعد از صحبت‌های مفصل با تیم عملیات و سایر ذی‌نفعان، از بین ۳۰۰ مورد موجود در بک‌لاگ ۸۰ مورد را که در بخش HH قرار می‌گرفت، شناسایی کنم (اینکه چقدر در تحلیل و شناسایی آن‌ها در ابتدای کار که شناختی از کسب و کار نداشتم، دقیق بودم هم جای بحث دارد و احتمالا خطاهای متعددی کردم)، اما مسئله این بود که هنوز هم نمی‌توانستم ۱۰ یوزر استوری را برای اسپرینت هفته آینده آماده کنم و این موضوع من را در همان چالش نگه داشت.در قسمت بعدی با چارچوب قدرتمندتری به نام همپ۲ برای اولویت بندی کارها آشنا می‌شویم که به صورت مکمل با این ماتریس‌ها کار می‌کنند. این چارچوب کمک می‌کند در مواقعی که محصول به سرعت در حال رشد است از رقابت جا نمانید. من با این چارچوب توانستم ۸۰ مورد باقی مانده را اولویت بندی کنم و ۱۰ کار مهمی که لازم است در اسپرینت بعدی انجام دهیم را پیدا کنم. ۱۰ موردی که ما را یک قدم به چشم انداز نزدیک‌تر کرد و الزاما کارهایی نبود که بتوان به راحتی پیدایشان کرد. پشت صحنه تیم محصول علی بابا امیر اچ پی Sat, 05 Oct 2019 11:46:35 +0330 https://virgool.io/alibaba-product/%DA%86%D8%A7%D8%A8%DA%A9%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B3%D8%A7%D8%AE%D8%AA%D9%86-%DB%8C%DA%A9-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D8%AC%D8%AF%DB%8C%D8%AF-nec20pfg6yir من در پاییز ۹۷ به تیم محصول علی بابا پیوستم، چند ماهی از تغییر ساختار مدیریت محصول در سازمان می‌گذشت و شرکت در حال گذار به سمت مدل اسپاتیفای بود. مزیت بزرگ این ساختار جدید، ایجاد استقلال زیاد در تیم‌های محصول برای افزایش چابکی است. هر تیم باید بتواند همه‌ نیازهای فنی و محصول خود را از داخل تامین کند و با کمترین وابستگی به تیم‌های دیگر روی ماموریت خود متمرکز باشد.در مدل پیشنهادی اسپاتیفای، هر تیم محصول توسعه‌دهنده‌های اختصاصی خود و همچنین Product Designer و Product Analyst و Agile Coach خودش را دارد و حول یک ارزش مشخص فعالیت می‌کند. بر این اساس واحد فنی و محصول ۱۰۰ نفره‌ علی بابا به ۱۵ تیم محصول تقسیم می‌شود و در هر تیم، مدیر محصول به عنوان نماینده مشتری مسئول بودجه و نقشه راه (رود مپ) است و به سوال‌هایی از جنس Why و What پاسخ می‌دهد و مالک محصول به عنوان Solution Provider مسئول ساختن محصول، اولویت‌بندی و کنترل کیفیت است و به سوال‌هایی از جنس How پاسخ می‌دهد اما این حوزه‌ها، مناطق حفاظت‌شده‌ای نیستند که دیگرا نقش‌ها در تیم محصول اجازه‌ی وارد شدن به آن را نداشته باشند. تصمیم‌ها در یک فضای گفتگو ساخته می‌شوند که هر کس بسته به موضوعی که نسبت به آن پاسخگوست، گفتگو را راهبری می‌کند. تیم‌های محصول در علی بابااگر قبلا درباره ساختار محصول اسپاتفای نخوانده‌اید، بهتر است پیش از ادامه‌ این متن، این دو ویدئو را تماشا کنید. https://www.aparat.com/v/EOzuk https://www.aparat.com/v/NMQ2o مسئولیت گروه محصولات هسته (Alibaba Core Tribe) به من سپرده شد. ماموریت این ترایب، ساختن تجربه‌ی عمومی وب‌سایت علی بابا و توسعه محصولات زیرساختی در سطح درگاه علی بابا است. ترایب هسته مستقل از محصولات مختلف (پرواز، هتل، قطار، اتوبوس و ...) و با نگاه کلی به علی‌بابا به عنوان یک وب‌سایت و مشتریانش، به خلق ارزش مشغول است. محصولاتی مانند ایندرا (زیرساخت فروش)، باشگاه مشتریان، سریبرو (بک آفیس)، API Out، ترافیک، فنی مالی و ... در این ترایب قرار گرفته‌اند.چالش اصلی من برای محقق کردن برنامه‌ای که نسبت به آن به علی‌بابا متعهد شده بودم، تضمین چابکی در راه اندازی محصولات پیچیده جدید ضمن حفظ تمرکز تیم برای نگهداری و توسعه‌ی محصولات مستقر بود. محصولاتی که زیرساخت فروش و پشتیبانی علی بابا را تامین می‌کرد. راه افتادن یک محصول جدید در علی بابا مراحل شکل‌گیری یک استارت آپ را طی می‌کند، با این تفاوت که بخش زیادی از زیرساخت‌های فنی و محصول از قبل آماده شده‌اند.به این ترتیب، عموما تیم محصول جدید با یک نفر به عنوان مدیر محصول شکل می‌گیرد که بر اساس استراتژی سازمان، تحقیقات اولیه را در خصوص مارکت-پروداکت مشخصی شروع می‌کند. خروجی کار، یک مدل کسب و کار به همراه مستندات MVP خواهد بود. زمانی که برای راه اندازی محصول باشگاه مشتریان به این نقطه رسیده بودیم (ارائه‌ی MVP به هیات مدیره)، برای شروع فرایند توسعه‌ محصول، دو انتخاب کلی داشتیم.یا اینکه برای جذب توسعه دهنده و دیگر تخصص‌های مورد نیاز تیم شروع به مصاحبه کنیم و یا اینکه از ظرفیت مهندسی و محصول داخل ترایب برای تولید MVP استفاده کنیم. روش اول منجر به از دست دادن زمان می‌شد و روش دوم خطر کاهش تمرکز تیم‌های محصول یا کند شدن فرایند توسعه‌شان را در پیش داشت.استفاده از تیم فنی مشترک برای توسعه‌ی چندین محصولمن ریسک روش دوم را پذیرفتم و تولید محصول را با قوی‌ترین نیروهای فنی موجود در ترایب آغاز کردیم. در واقع از یک اسکواد فنی مشترک برای توسعه‌ ۲ محصول استفاده می‌کردیم. در عمل، هر اسپرینت دو هفته‌ای به صورت ۳۰/۷۰ میان محصول مستقر و محصول جدید برنامه ریزی می‌شد و حتی جلسات Planning و Demo برای هر دو محصول به صورت مشترک برگزار می‌شد. بعد از چندین ماه کار فشرده، نهایتا محصول اولیه آماده‌ لانچ شد. اگرچه این مدل با ساختار کلی اسپاتیفای مغایرت داشت اما در آن برهه، زمان ورود به بازار برای ما اهمیت زیادی داشت و نیاز بی‌پاسخ جدی در بازار حس می‌شد. بنابراین برای راه‌اندازی محصول جدید بعدی هم از همین مدل استفاده کردیم.در این مدت، Velocity تیم، حجم کار انجام شده در هر اسپرینت، میزان بدهی فنی ایجاد شده و کیفیت خروجی به دقت اندازه گیری می‌شد.تحلیل عملکرد تیم محصول بر اساس Velocity (اعداد در ضریب ثابتی ضرب شده‌اند)به فاصله‌ی میان خط آبی و نارنجی توجه کنیدبررسی‌ها نشان می‌داد توسعه‌ محصولات مستقر کند شده است (که از قبل پیش‌بینی می‌شد). اما چیزی که در گزارش‌های آماری خودش را نشان نمی‌داد، کاهش حس مالکیت نسبت به محصول در تیم‌های محصول بود. به عبارت دیگر، کاهش تمرکز تیم محصول بر روی ارزش اصلی، به صورت پنهان نشاط و چابکی را کاهش داده بود و این پراکندگی فعالیت‌ها، خودش را در کاهش مشارکت کل تیم در گفتگوها نشان می‌داد.این تجربه‌ بسیار گرانی برای من بود. اگرچه در کوتاه مدت، چابکی مورد نظر برای ارائه‌ پاسخ مناسب در زمان مناسب به نیاز مشتری تامین شده بود اما ادامه‌ فعالیت در این مدل نمی‌توانست اهداف بلند مدت ما را تامین کند. مالکان محصول با همین استدلال با تصمیم من برای استفاده‌ مشترک از منابع، مخالفت کردند و برایند نظر گروه بر این بود که باید برای محصولاتی که اخیرا لانچ شده‌اند، تیم فنی اختصاصی تامین کنیم.بگذارید همین‌جا بگویم، نقطه‌ قوت اصلی تیم‌های محصول در علی بابا، باور به گفتگوهای شفاف و جسورانه در تک تک اعضاست. در سازمان ما، تیم‌ها یا با موفقیت مواجه می‌شوند و یا عمیقا چیزی یاد می‌گیرند که نهایتا به موفقیت منجر می‌شود و این یادگیری در گفتگوهای شفاف و جسورانه نمود پیدا می‌کند. اگرچه بهتر بود مستقل کردن تیم محصول جدید زودتر اتفاق بیفتد اما این تجربه ما را به نسخه‌کامل‌تری از مدل ساختاری علی بابا برای راه اندازی محصولات جدید رساند: مدل میتوز محصولی.یادگیری اصلی تیم: میتوز (Mitosis) محصولیچیزی که پس از سه فصل برنامه‌ریزی، آزمون و یادگیری برای اعضای تیم شفاف شده‌است را می‌توان در چهار مرحله و به صورت خلاصه، این‌طور بیان کرد:بهینه‌ترین مسیر برای شروع یک محصول جدید در سازمان‌های بزرگی شبیه علی‌بابا:１. شروع برنامه ریزی با تیم محصول (مدیر محصول) برای تهیه‌ی BM اولیه و مستندات MVP２.شروع توسعه محصول با نیروهای فنی یکی از محصولات مستقر (محصولی انتخاب می‌شود که از نظر کسب و کاری با محصول جدید بیشترین نزدیکی را داشته باشد) این فاز تا لانچ MVP ادامه پیدا خواهد کرد.３.بعد از لانچ اولیه با افزایش هدکانت تیم، زمینه برای تقسیم تیم آماده می‌شود و در حین توسعه‌ اولین Revision بعد از لانچ، نیروهای جدید نسبت به مختصات محصول آموزش می‌بینند و در حین اسپرینت‌های جاری، محصول به تیم جدید تحویل می‌شود.4.جلسه‌ی Demo اولین Revision محصول توسط نیروهای جدید و با حضور تیم قبلی برگزار می‌شود. بعد از لانچ این نسخه، تیم محصول به صورت رسمی به دو تیم تقسیم می‌شود و هر تیم بورد مخصوص به خود را دریافت می‌کند. یک میتوز محصولی بی عیب و نقص!در مدل میتوز محصولی، تشکیل تیم جدید به آرامی و با جذب تک به تک نیروها شروع می‌شود. نیروها در درون یک تیم محصول با فرهنگ تیم، ارزش‌ها، نقش‌ها و نحوه تعامل آشنا می‌شوند. به این ترتیب، چون تیم جدید از دل یک محصول مستقر خارج می‌شود، با هزینه‌ی پایین می‌توانیم مطمئن باشیم ارزش‌های ترایب به خوبی در تیم جدید نهادینه شده است و از سوی دیگر، تعامل میان تیم جدید و تیم قبلی بسیار با کیفیت خواهد بود. در یک ترایب شبیه ترایب هسته‌ علی بابا که نیاز به توسعه‌ محصولات جدید به صورت همیشگی وجود دارد، تشکیل یک اسکواد فنی از مسلط‌ترین‌ نیروها بر ساختار فنی علی‌بابا به عنوان جوخه‌‌ی پیشرو می‌تواند بازدهی این مدل را افزایش دهد. تیمی که همیشه درحال شروع محصولات جدید است و پس از لانچ آن را به تیم جدید تحویل می‌دهد. پشت صحنه تیم محصول علی بابا محمدعلی طائبی Sun, 22 Sep 2019 13:42:21 +0330