Iran Agile channel

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

آنچه شما را به اینجا رسانده، شما را به مقصد جدید نمی‌رساند. باید فرضیات خود را تعریف، آزمایش و تأیید کنید، زیرا ممکن است نادرست باشند، به ویژه زمانی که به دسته‌های جدیدی از مشتریان هدف می‌پردازید.

استارتاپ‌ها از گرسنگی سود می‌برند. گرسنگی، انگیزه حل مشکلات را با خلاقیت و فوریت ایجاد می‌کند. هنگام کاوش در محصولات جدید در یک شرکت بزرگ با منابع فراوان، باید کمیابی ایجاد کنید تا این گرسنگی استارتاپی را تقلید کنید. این معمولاً به معنای فعالیت به عنوان یک تیم کوچک، چابک و مستقل است. احتمال شکست هنگام راه‌اندازی یک محصول جدید بیشتر است – حتی در شرکت‌های بزرگی که به نظر می‌رسد مزایای زیادی دارند. مهم است که این واقعیت را بپذیرید تا از سرمایه‌گذاری بیش از حد شرکت جلوگیری کنید، که در نهایت گرسنگی را کاهش می‌دهد، کارها را کند می‌کند و شانس موفقیت را کم می‌کند. چرا باید در چیزی که احتمالاً شکست می‌خورد سرمایه‌گذاری زیادی کرد؟ موفقیت محصولات جدید باید به شکلی متفاوت از محصولات موجود اندازه‌گیری شود، هم از نظر معیارها و هم از نظر زمان. به طور کلی، محصولات جدید باید با توجه به اینکه تیم سوالات درست را در زمان مناسب پاسخ می‌دهد، ارزیابی شوند. یک اشتباه رایج این است که محصولات جدید را با معیارهایی که شرکت بزرگ به آن عادت کرده، مانند MAUs یا درآمد، ارزیابی کنیم. اما اگر تیم برای MAUs یا درآمد بهینه‌سازی کند قبل از اینکه مشکل را درک کرده باشد، روی موارد اشتباه کار خواهد کرد. اطلسین از یک روش چهار مرحله‌ای برای راه‌اندازی محصولات جدید و تصمیم‌گیری درباره سرمایه‌گذاری بیشتر در آنها استفاده می‌کند: حیرت - Wonder. اثبات اینکه مشکلی با اندازه بازار کافی برای توجیه سرمایه‌گذاری در این حوزه وجود دارد. همچنین بسیار مهم است که به سوال "چرا حالا؟" پاسخ دهیم، زیرا شرکت‌های بزرگی مانند اطلسین تعداد بی‌شماری از فرصت‌های "خوب" دارند. باید یک محرک قوی برای اقدام بر روی هر فرصت مشخص وجود داشته باشد که در برابر گزینه‌های دیگر برتری داشته باشد. کاوش - Explore. بررسی راه‌حل‌های بالقوه و تأیید آنها با مشتریان به طور ارزان، خواه از طریق ماکت‌های Figma، مصاحبه با مشتریان یا روش‌های خلاقانه دیگر. ساخت - Build . ساخت نسخه آلفا و سپس بتای راه‌حل که مشتریان می‌توانند شروع به استفاده از آن کنند. اثر - Impact . نشان دادن اینکه راه‌حل می‌تواند تأثیر قابل توجهی بر کسب‌وکار داشته باشد. عوامل "چرا حالا" را در هر پیشنهاد یا طرح تجاری بیان کنید. داشتن یک ایده یا فرصت جذاب کافی نیست؛ باید به وضوح نشان دهید چرا باید فوراً اقدام شود. این می‌تواند شامل برجسته کردن ماهیت موقت فرصت یا توضیح اینکه چرا تأخیر در اقدام می‌تواند به معنای از دست دادن مزایا یا مزایای قابل توجه باشد. لینک کامل پادکست @iranagile

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

دیروز یک مصاحبه جذاب با یکی از بنیان‌گذاران ویز در پادکست لنی راچیتسکی دیدم. این مصاحبه مرا به فکر فرو برد که چطور ارزشی که ما در محصولاتمان می‌بینیم می‌تواند به طور قابل توجهی با چیزی که کاربران ما ارزشمند می‌دانند، متفاوت باشد. 🚗 ویز با این ایده شروع شد که به مردم کمک کند ترافیک را دور بزنند. اما بیایید رو راست باشیم، ترافیک اکنون بدتر از سال ۲۰۰۷ است. با این حال، ویز برای بسیاری به ابزاری ضروری تبدیل شده است. پس ارزش واقعی اینجاست؟ 🤔 این مثال خوب موضوع را روشن می‌کند. تصور کنید از کوپرتینو به سانفرانسیسکو می‌روید و دو مسیر اصلی دارید: ۱۰۱ و ۲۸۰. اکثر مردم تا حد امکان نمی‌خواهند مسیرشان را تغییر دهند. چیزی که واقعاً برایشان اهمیت دارد، دانستن مدت زمان سفر است. آنها مشکلی با ادامه مسیر در ۱۰۱ ندارند، به شرطی که دقیقاً بدانند چه زمانی به مقصد می‌رسند. این قطعیت چیزی است که کاربران بیش از همه ارزش قائلند. 🛣️ در پادکست، لوین اشاره کرد که:

برای بسیاری از کاربران، ارزش اصلی ویز اجتناب از ترافیک نیست. بلکه قطعیت و پیش‌بینی‌پذیری است که ارائه می‌دهد. دانستن زمان دقیق رسیدن به مقصد بیشتر از صرفه‌جویی چند دقیقه‌ای در راه ارزشمند است. ⏰

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

جادوی واقعی زمانی اتفاق می‌افتد که چیزی را که آنها واقعاً ارزش می‌گذارند ارائه دهیم، حتی اگر آن چیزی نباشد که در ابتدا تصور می‌کردیم.

اگر به مباحث مدیریت محصول علاقه مند هستید، ورکشاپ بعدی مدیریت محصول چابک این هفته برگزار خواهد شد.

کارگاه آموزشی مالک محصول حرفه‌ای (مدیریت محصول چابک) انتهای خرداد ماه در چهار جلسه برگزار خواهد شد. سرفصل کارگاه: - ایجاد چشم انداز و تدوین استراتژی محصول - ایجاد ارتباط بین هدف و اجزای بک لاگ محصول - تکنیک‌های متفاوت ایجاد نقشه راه محصول - مدیریت ذینفعان و نکات کلیدی در دنیای واقعی - مدیریت و سازماندهی موثر بک لاگ محصول - چگونه با تیم در طول اسپرینت باید کار کرد؟ - شیوه های متفاوت اولویت بندی - آشنایی با Story Mapping اطلاعات بیشتر در این لینک

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

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

قالب (تمپلیت) میرو برای برگزاری جلسات بازبینی اسپرینت : با استفاده از این قالب میتوانید ایده های خوبی در مورد نحوه برگزاری جلسات موثر بازبینی یا Sprint Review داشته باشید. مشاهده این قالب

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

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

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

به وضعیت الان خودمون نگاه کنیم، فارغ از اینکه آینده که چی باید بشود، همین الان چه چیزی خوب هست؟ و چه چیزی خوب نیست؟

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

“اگر امروز تغییری ایجاد نکنیم و با همین فرمون جلو برویم، چه چیزی ممکن هست پیش بیایید؟ چه چیزی در انتظار ما هست؟”

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

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

گام آخر: برگشت به الان و ایجاد تغییرات خوب، در این بخش قصد داریم تیم را به این دعوت کنیم، که به الان و امروز برگردند، و به این سه سوال جواب بدهند:

همین الان (مثلا اسپرینت آینده) چه تغییری می‌توانیم ایجاد کنیم که مشکلات موجود(اشاره به موارد گام اول) را حل کند؟همین الان چه تغییری می‌توانیم ایجاد کنیم، که از به وجود آمدن آینده نامطلوب (اشاره به گام دوم) جلوگیری کند؟ همین الان چه تغییراتی می‌توانیم ایجاد کنیم یا از موارد مثبت (چیزهایی که همین الان می‌کنند) چه چیزهایی را میتوانیم تقویت کنیم که آینده مطلوب (اشاره به گام سوم) خودمون را ممکن کند؟

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