پشتیبانی و خرید:
@activevpnv2raybot
@activevpn_admin
پیج اینستاگرام:
https://instagram.com/activevpn_v2ray?igshid=OGQ5ZDc2ODk2ZA%3D%3D&utm_source=qr
Last updated hace 3 meses, 2 semanas
Last updated hace 1 año, 8 meses
آینده شغلی مدیریت محصول چه خواهد شد؟
در این ویدئو کلیر وو، مدیر ارشد محصول در لانچدارکلی و بنیانگذار چتپیاِرد،به این سوال جواب میدهد که آینده شغلی مدیریت محصول چه خواهد شد . در این سخنرانی، او به موارد زیر میپردازد:
- چرا مدیریت محصول به شکلی که میشناسیم، در حال مرگ است؟
- چگونه هوش مصنوعی توسعه محصول را سریعتر از حد انتظار متحول میکند؟
- ظهور "سهگانههای قدرتمند" مبتنی بر هوش مصنوعی که میتوانند وظایف محصول، طراحی و مهندسی را بر عهده بگیرند؟
- رهبران محصول برای ماندگاری در عصر هوش مصنوعی به چه اقداماتی نیاز دارند؟
- چگونه تیمهای محصول مبتنی بر هوش مصنوعی را بسازیم و مدیریت کنیم؟
مدل ذهنی Probabilistic Thinking
به عنوان یک رهبر فنی، یکی از متداولترین (و شاید ناخوشایندترین) سوالاتی که با آن مواجه میشوید: «این کار کی تمام میشود؟» مشتریان، ذینفعان و حتی اعضای تیم خودتان به دنبال قطعیت در حوزه ای ذاتا نامطمئن هستند. در حالی که ارائه تاریخهای دقیق تحویل غیرممکن است، در اینجا میتوانیم از مدل ذهنی Probabilistic Thinking برای ارائه تخمینهای واقعبینانهتر و ارزشمندتر استفاده کنیم.
توسعه نرمافزار یک امر پیچیده است. چالشهای غیرمنتظره، تغییر نیازمندیها و خلاقیت ذاتی درگیر در آن، پیشبینی تکمیل با قطعیت مطلق را غیرممکن میسازد. برخورد با تخمینها به عنوان ضربالاجلهای ثابت، انتظارات غیرواقعی ایجاد میکند و میتواند منجر به موارد زیر شود:
- سندرم فرسودگی شغلی: توسعهدهندگان تحت فشار قرار میگیرند تا ضربالاجلها را رعایت کنند که منجر به استرس و کاهش بهرهوری در بلند مدت میشود.
-کاهش کیفیت: برای رعایت ضربالاجلها، ممکن است از برخی مراحل صرفنظر شود که منجر به نرمافزار دارای باگ و افزایش بدهی فنی شود.
- از دست دادن اعتماد: عدم رعایت مکرر ضربالاجلها، اعتماد بین تیم توسعه و ذینفعان را از بین میبرد.
به جای تاریخهای ثابت، بیایید عدم قطعیت را بپذیریم. در اینجا نحوه کمک Probabilistic Thinking آورده شده است:
شناسایی عدم قطعیتهای کلیدی:
پیچیدگی: پیچیدگی کار چقدر است؟ آیا ناشناختهها یا وابستگیهایی وجود دارد؟
تغییر دامنه: احتمال تغییر نیازمندیها چقدر است؟
تجربه توسعهدهندگان: تجربه تیم در زمینه فناوری و حوزه مسئله چیست؟
عوامل خارجی: آیا عوامل خارجی احتمالی وجود دارد که میتواند بر پروژه تأثیر بگذارد (مانند مشکلات زنجیره تامین، تاخیرهای غیرمنتظره)؟
تخصیص احتمالات:
بر اساس ارزیابی شما از این عدم قطعیتها، احتمالات را به سناریوهای مختلف اختصاص دهید.
به عنوان مثال، «۷۰٪ احتمال تکمیل شدن در عرض دو هفته، ۲۰٪ احتمال تکمیل در عرض سه هفته و ۱۰٪ احتمال مواجهه با تاخیرهای غیرمنتظره وجود دارد.»
ارتباط شفاف:
- به جای وعده دادن یک تاریخ مشخص، طیف وسیعی از نتایج احتمالی مرتبط با آنها را ارائه دهید.
- عواملی را که به عدم قطعیت کمک میکنند توضیح دهید.
- در مورد احتمال تاخیرها و اقداماتی که برای کاهش آنها انجام خواهید داد، صریح باشید.
ارزیابی مجدد مداوم:
- با پیشرفت پروژه، بازخورد جمعآوری کنید، پیشرفت را کنترل کرده و تخمینهای خود را متناسباً تنظیم کنید.
- این بهروزرسانیها را به طور منظم با ذینفعان در میان بگذارید تا شفافیت و اعتماد را حفظ کنید.
مثال:
درخواست ویژگی ظاهراً سادهای میرسد: «دکمهای به پروفایل کاربر اضافه کنید.»
پیچیدگی: در حالی که این کار ظاهراً ساده است، ممکن است وابستگیهایی به سایر بخشهای سیستم یا موارد حاشیهای غیرمنتظره وجود داشته باشد.
تغییر دامنه: مشتری ممکن است پس از مشاهده اجرای اولیه، درخواست اضافی کند.
ارتباط: به جای گفتن «تا جمعه انجام خواهد شد»، تیم لید ممکن است بگوید: «بر اساس ارزیابی اولیه، ۸۰٪ احتمال تکمیل این کار تا جمعه وجود دارد، اما ۲۰٪ احتمال وجود دارد که با چالشهای غیرمنتظرهای مواجه شویم که میتواند جدول زمانی را تمدید کند.»
ایجاد اعتماد از طریق شفافیت
با پذیرش Probabilistic Thinking و ارتباط صادقانه و شفاف، رهبران فنی یا مدیران پروژه میتوانند اعتماد را با ذینفعان ایجاد کنند. این رویکرد نه تنها منجر به انتظارات واقعبینانهتر میشود، بلکه فرهنگ همکاری و بهبود مستمر را نیز تقویت میکند.
نقشه راه چابکی : مدل اجایل فلوئنسی
بسیاری از شرکتها معمولا در دام پیاده سازی اجباری یا به زور چارچوبهای چابک میفتند، بدون اینکه نقشه راه مشخصی از چابکی داشته باشند. حقیقت این است که چابک یک مقصد نهایی نیست، بلکه یک سفر با ایستگاههای متنوع است که هر کدام مزایای خاص خود را دارند. مدل اجایل فلوئنسی هم دقیقاً همین نقشه راه گام به گام را ارائه میدهد؛ یک نقشه راه منعطف که به شما امکان میدهد "ایستگاه" چابکی مناسب تیم خود را انتخاب کنید.
تصورش کنید سوار "اتوبوس مدل اجایل فلوئنسی" شدهاید. هر ایستگاه که به آن میرسیم،به سطحی از توانایی چابک خواهیم رسیم، از مهارتهای پایه تا نوآوریهای پیشرو. نیازی نیست به "آخرین ایستگاه" برسید تا موفق باشید؛ کلید کار این است که ایستگاهی را انتخاب کنید که با نیازها و اهداف کسبوکارتان سازگار باشد. البته، سفر هم رایگان نیست، برای اتوبوس باید بلیط تهیه کنید و هر چقدر مسیر دورتر، بلیط گرانتر.
ایستگاه 1: متمرکز شدن – تسلط بر اصول پایه
این آغاز سفر چابکی است. تیمها در این مرحله، پایههای کار را محکم میکنند: هدفگذاری شفاف، اولویتبندی کارها و همکاری مؤثر. چارچوب هایی مثل اسکرام و کانبان، در این مرحله کاربرد خواهند داشت.
چرا مهم است: این مرحله شفافیت ایجاد میکند، درک مشترک میسازد و همه را در مسیر یک هدف مشترک قرار میدهد. در واقع پایهای است که تمام موفقیتهای بعدی چابک بر آن سوار میشوند و به تیمها کمک میکند ارزش قابل پیشبینی ارائه دهند.
ایستگاه 2: تحویل دادن – ارسال ارزش بهطور مستمر
اتوبوس حالا سرعت میگیرد و به ایستگاه "تحویل یا دلیور" میرسد. در اینجا، تمرکز تیمها بر تحویل پایدار و با کیفیت است. تصور کنید قابلیت هایی که همیشه سر وقت و بدون دردسر به دست مشتری میرسند—بدون موعدهای از دست رفته یا عجلههای دقیقه نودی.
چرا مهم است: دست یافتن به این مرحله منجر به کاهش اتلافات و باگ ها شده و البته زمان رسیدن به بازار را کوتاه میکند. تیمها تبدیل به گروههایی بسیار کارآمد میشوند. در این مرحله چارچوب فنی تر مانند اکس پی، DevOps , ... بیشتر مطرح خواهند بود.
ایستگاه 3: بهینهسازی – پیش بردن نوآوری و رهبری بازار
حالا در جادههای سریع در حرکتیم. تیمها در این مرحله فقط تحویل نمیدهند؛ بلکه نوآوری هم میکنند. آنها روندهای بازار را پیشبینی، ایدههای جدید را آزمایش و مرزهای ممکن را جابهجا میکنند. تصور کنید تیمی مثل گروه مکانیکهای فرمول یک که مدام عملکرد را بهتر میکنند تا به نتایج عالی برسند.
چرا مهم است: این مرحله فرهنگ بهبود مداوم و نوآوری را ایجاد میکند، به تیمها اجازه میدهد ارزش متمایز عرضه کنند و از رقبا جلو بزنند.
ایستگاه 4: توانمندسازی – ساخت یک اکوسیستم چابک
ایستگاه چهارجایی است که اصول چابک از مرز یک تیم فراتر میرود و در کل سازمان جاری میشود. اینجا صحبت از ایجاد شبکهای از تیمهای هماهنگ و انعطافپذیر است که مثل یک ارکستر خوشصدا با هم همکاری میکنند و هر بخش نقش خود را عالی ایفا میکند.
چرا مهم است: این مرحله چابکی و انعطافپذیری سازمانی را تقویت میکند و به کل کسبوکار اجازه میدهد با سرعت به تغییرات پاسخ داده و ارزش پایدار ایجاد کند.
مدل اجایل فلوئنسی درباره یک مسیر خطی نیست، بلکه درباره انتخاب آگاهانه است. کدام ایستگاه همین حالا برای شما مناسب است؟ به این پرسشها فکر کنید:
چالشهای اصلی کسبوکار شما چیست؟ (مثلاً تحویل ناپایدار، کمبود نوآوری، تأخیر در رسیدن به بازار)
چقدر میخواهید سرمایهگذاری کنید؟
فرهنگ سازمانی شما چگونه است؟
مدل اجایل فلوئنسی به شما امکان میدهد سفر چابکیتان را بر اساس نیازهای خاص خودتان تنظیم کنید. بحث رسیدن به یک "بهشت افسانهای چابک" نیست؛ بلکه انتخاب مسیر درست برای دستیابی به اهداف کسبوکارتان است.
ورکشاپ بعدی "تحول چابک با مدل اجایل فلوئنسی" در حال ثبت نام است، برای اطلاعات بیشتر میتوانید این لینک را مشاهده کنید.
جلسات بی فایده، یا عدم مشارکت اعضای تیم در موضوعات جلسه
این دو مورد از شایع ترین مواردی هست که این روزها در تیم های چابک گزارش می شود، یا اعضای تیم از جلسات بی فایده شکایت دارند که وقتشان در آن تلف می شود، یا اسکرام مسترها/مربیهای چابک از این که اعضای تیم در جلسات مشارکت نمیکنند، گلهمند هستند.
اینجا دقیقا جایی است که نقش یک تسهلیگر خوب تعریف می شود:
تسهیل گر خوب، کسی است که بتواند یک جلسه یا ورکشاپ را به گونه ای طراحی و اجرا کند، که 1- افرادی که در آن حضور دارند، بیشترین مشارکت را داشته باشند 2- جلسه آغاز و پایان خوبی داشته باشد 3- انتهای جلسه حس کنیم که این جلسه فایده داشته و اکنون میدانیم که گام بعدی چیست.
اسکرام مسترها/مربیهای چابک باید بر روی مهارت تسهیلگری خود سرمایه گذاری خوبی انجام بدهند، زیراکه می توانند با این ابزار در داخل تیم و شیوه کاری تحول بزرگی ایجاد کنند.
ورکشاپ تسهیلگری چابک آبان امسال در شش جلسه از 17 آبان تا 2 آذر به صورت آنلاین برگزار خواهد شد. برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.
? بزرگترین سوءتفاهم درباره تبدیل شدن به یک مدیر محصول ?
هفته قبل در طی دوره آموزشی مدیر محصول چابک، مفهومی مطرح شد بعنوان اینکه مدیر محصول باید mini-CEO محصول باشد، مثل اینکه در رأس یک ساختار سازمانی قرار بگیری، تیمها رو هدایت کنی و تصمیم نهایی با تو باشد. اما این تصویر یک ذره رمانتیک تر از واقعیت هست.
? انتظار: قرار گرفتن در بالای ساختار سازمانی و تصمیمگیری نهایی.
✅ واقعیت: در واقع، در رأس هیچ چیزی نیستی! به جای اون، در مرکز یک شبکه از منافع متضاد قرار داری. فروش، بازاریابی، مهندسی، پشتیبانی مشتری، تجربه کاربری... هر کدوم اولویتهای خودشون رو دارن، و به عنوان مدیر محصول، تو باید همه رو به یک تعادل نسبی و توافق جمعی برسونی، بدون اینکه حق تصمیمگیری نهایی توی هیچ حوزهای داشته باشی.
وظیفه تو چی هست؟ تأثیرگذاری بدون اختیار مستقیم، هماهنگ کردن تیمهای مختلف و پیش بردن کارها به سمت هدفی مشترک حتی وقتی که ذینفعان اهداف متفاوتی دارند. شاید مسئولیتها مشترک باشد، ولی تصمیمگیری یک کار تیمی هست. این نقش به همدلی، مهارتهای ارتباطی و کمی دیپلماسی (با چاشنی صبر زیاد) نیاز دارد.
حقیقت این هست که مدیر محصول بودن، به جای در کنترل داشتن همه امور، بیشتر بدنبال ایجاد وضوح، مدیریت هرج و مرج و کمک به همکاری دیگران برای ساختن چیزی معنادار هست.
«آها»
بین آگوست ۱۹۷۶ تا آگوست ۱۹۷۷، دکتر پال مککریدی و یک تیم کوچک از اعضای خانواده و دوستانش در جنوب کالیفرنیا صدها نسخه از هواپیمای «گاسامر کاندور» خود را ساختند و بهبود دادند؛ هواپیمایی فوقالعاده سبک که با نیروی انسانی کار میکرد و آنها امیدوار بودند که بتوانند با آن جایزه کرمر را ببرند. برای بردن این جایزه ۵۰ هزار پوندی که در سال ۱۹۵۹ توسط تاجر بریتانیایی، هنری کرمر، بنیان گذاشته شده بود، یک هواپیمای با نیروی انسانی باید از زمین بلند میشد، یک مسیر به شکل عدد هشت به طول یک مایل را طی میکرد و به سلامت فرود میآمد. مککریدی و تیمش ۲۲۲ پرواز آزمایشی انجام دادند و ۹ بار تلاش کردند تا این جایزه را ببرند. اما در پرواز ۲۲۳ و دهمین تلاششان، بالاخره موفق شدند.
در طول این یک سال که به سمت پیروزی پیش میرفتند، مککریدی و تیمش بسیاری از «آها» های کوچک را تجربه کردند. «آها» به معنی احساس رضایت، پیروزی یا شگفتی است. هر «آها»ی کوچک از این کشف حاصل میشد که چه چیزی کار میکند و چه چیزی نیاز به بهبود دارد. آنها به سرعت طراحی را بهبود میدادند (گاهی در عرض چند ساعت) و بلافاصله پرواز آزمایشی بعدی را انجام میدادند. حتی درست قبل از پرواز معروف ۲۲۳، مککریدی تصمیم گرفت یک دریچه کوچک در زیر بدنه هواپیما بزند تا پای خلبان خنکتر بماند. و جواب داد. مجموعهای از همین «آها» های کوچک بود که آنها را به جایزه کرمر رساند.
آیا شما در کارتان از «آها»های کوچک استفاده میکنید؟
اگر نه، ممکن است در خطر تلف کردن وقت خود روی کارهایی باشید که ارزش کافی تولید نمیکنند. تصور کنید که در حال نوشتن یک کتاب هستید، اما هیچ بازخوردی در طول مسیر دریافت نمیکنید—شاید هیچکس به موضوع کتاب علاقهای نداشته باشد و کتاب شما فروش نرود؟
برای کشف سریع راههای رضایت مشتریان، باید سریع تجربه کنیم و یاد بگیریم. ما این کار را با تمرکز بر حجم کاری که تکمیل کردهایم انجام نمیدهیم. تکمیل کار مهم است، اما مهمتر از آن این است که بدانیم به دنبال چه نتیجهای هستیم و کشف کنیم که چگونه آن را ارائه دهیم.
«آها» های کوچک به ما در این مسیر کمک میکنند. ما به سرعت از یک «آها» به «آها»ی بعدی میرویم و به تدریج یاد میگیریم که چه چیزی نتیجه مطلوب را تولید میکند.
یک «آها»ی کوچک با مفهوم تولید در دستههای کوچک در تولید ناب تفاوت دارد. در حالی که دستههای کوچک بر سرعت تکمیل کار تمرکز دارند، «آها» های کوچک بر سرعت کشف تأکید دارند.
برای داشتن «آها»ی کوچک، باید:
- سرعت: هرچه سریعتر به «آها» برسیم.
- یادگیری: هر «آها» به ما کمک میکند که یاد بگیریم و تطبیق پیدا کنیم.
- امنیت: ما باید در حین یادگیری، احساس امنیت کنیم که موفق شویم یا شکست بخوریم.
«آها» های کوچک یک تکنیک اجرایی برای زندگی با شعار «نتایج بر خروجیها اولویت دارند» هستند. تمرکز بر کشف چگونگی دستیابی به یک نتیجه کلیدی است، نه فقط گزارشگیری از کارهایی که انجام دادهایم.
به این نتایج و «آها»های کوچک مرتبط با آنها که به ما کمک میکنند در مسیر رسیدن به آن نتایج پیش برویم توجه کنید:
نتیجه: من میخواهم آشپز بهتری شوم. آها: «همه از همبرگرهای سبزیجاتی که درست کردم خوششان آمد!»
نتیجه: من میخواهم با افراد بیشتری در شبکههای اجتماعی ارتباط برقرار کنم. آها: «توییت روز یکشنبهام هیچ توجهی جلب نکرد. شاید باید از روزهای یکشنبه دوری کنم یا حداقل یک تصویر و هشتگ اضافه کنم؟»
نتیجه: من میخواهم یک کتاب پرفروش بنویسم. آها: «مردم تمثیل هنرهای رزمی من را درک نکردند، اما گفتند که دیاگرامهایم بسیار واضح هستند.»
یک «آها»ی کوچک ممکن است بعد از چند دقیقه، ساعت، روز، هفته یا حتی ماه اتفاق بیفتد. آنها لزوما ارتباطی مستقیمی به چارچوبهای زمانی ثابت مثل اسپرینتهای اسکرام ندارند. بلکه «آها» های کوچک در بازههای زمانی کوتاهی رخ میدهند که بسته به زمان و ماهیت کار متفاوت است. به عنوان مثال، زمان بین پروازهای آزمایشی گاسامر کاندور از چند ساعت تا چند روز و گاهی چند هفته متغیر بود. سرعت «آها» های کوچک استاندارد نیست.
?یک لیست خوب و جامع از مقالات و نوشته ها در حوزه های Agile testing, DevOPS, Continuous Delivery , ...
???
https://lisacrispin.com/observability-continuous-delivery-devops-related-resources/
دانلود لیست کامل متریک های محصول 2024
پشتیبانی و خرید:
@activevpnv2raybot
@activevpn_admin
پیج اینستاگرام:
https://instagram.com/activevpn_v2ray?igshid=OGQ5ZDc2ODk2ZA%3D%3D&utm_source=qr
Last updated hace 3 meses, 2 semanas
Last updated hace 1 año, 8 meses