Media is too big
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 22
عنوان: کاربران و مشتریان.
زبان: انگلیسی
قسمت : 22
عنوان: کاربران و مشتریان.
زبان: انگلیسی
022-Users vs Customers.srt
2.4 KB
زیرنویس انگلیسی قسمت 22 دوره جامع مدیریت محصول
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 22
عنوان: کاربران و مشتریان.
خوش آمدید همه. پس یادتان هست که گفتم گاهی اوقات افرادی که برای محصول شما پول پرداخت می‌کنند در واقع کاربران محصول شما نیستند؟ ما الان می‌خواهیم کمی بیشتر در مورد این موضوع صحبت کنیم. پس تفاوت بین کاربران و مشتریان وجود دارد. و اگر شما به عنوان یک مدیر محصول B2B یا کسب و کار به کسب و کار کار می‌کنید، این ممکن است واقعاً رایج باشد. بنابراین یکی از اولین کارهای مدیریت محصول من در شرکتی بود که نرم افزار مانیتورینگ رسانه‌های اجتماعی را به شرکت‌هایی می‌فروخت که علاقه‌مند به شناسایی روندها در رسانه‌های اجتماعی بودند. بنابراین شرکت Mass. Relevance نام داشت و این محصولی که ما می‌فروختیم، توانایی ورود به یک پلتفرم و بررسی همه این روندهای رسانه‌های اجتماعی چیزی بود که حدود 2 تا 500000 دلار هزینه داشت. بنابراین ارزان نبود. بنابراین افرادی که این را خریداری کردند شرکت‌های بزرگی بودند و افرادی که چک‌ها را امضا می‌کردند مدیران بازاریابی یا رسانه‌های اجتماعی بودند. و وقتی آنها آن را خریداری می‌کردند، خودشان از آن استفاده نمی‌کردند، بلکه لاگین‌ها را به زیردستان خود مانند مدیران رسانه‌های اجتماعی یا مدیران بازاریابی می‌دادند. و می‌توانید ببینید که این دو نفر کاملاً متفاوت هستند. بنابراین وقتی ما بازخورد می‌گرفتیم، از دو گروه مختلف بازخورد می‌گرفتیم. ما بازخورد سطح کلان در مورد اینکه محصول ما به طور کلی باید چه کاری انجام دهد دریافت می‌کردیم. این از بالا به پایین مانند مدیران بازاریابی و این جور چیزها بود. و سپس ما بازخورد بسیار دقیق از خود کاربران داشتیم. اینها افرادی بودند که هر روز وارد سیستم می‌شدند و بازخوردهایی مانند اوه، دکمه این کجاست؟ من دوست دارم این کار را داخل پلتفرم انجام دهم. دو گروه کاربری جداگانه و دو مجموعه بازخورد جداگانه. باشه، پس خلاصه کنیم، کاربران و مشتریان گاهی اوقات دو گروه کاملاً متفاوت با مجموعه‌های مختلف بازخورد هستند، اما مهم است که به خاطر داشته باشید. فهمیدی؟ باشه، ادامه میدیم.
اصطلاحات :
* Macro level feedback:
بازخورد سطح کلان: بازخورد کلی در مورد محصول یا خدمات.
* Granular feedback:
بازخورد دقیق: بازخورد جزئی در مورد ویژگی‌های خاص محصول یا خدمات.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
قسمت : 22
عنوان: کاربران و مشتریان.
خوش آمدید همه. پس یادتان هست که گفتم گاهی اوقات افرادی که برای محصول شما پول پرداخت می‌کنند در واقع کاربران محصول شما نیستند؟ ما الان می‌خواهیم کمی بیشتر در مورد این موضوع صحبت کنیم. پس تفاوت بین کاربران و مشتریان وجود دارد. و اگر شما به عنوان یک مدیر محصول B2B یا کسب و کار به کسب و کار کار می‌کنید، این ممکن است واقعاً رایج باشد. بنابراین یکی از اولین کارهای مدیریت محصول من در شرکتی بود که نرم افزار مانیتورینگ رسانه‌های اجتماعی را به شرکت‌هایی می‌فروخت که علاقه‌مند به شناسایی روندها در رسانه‌های اجتماعی بودند. بنابراین شرکت Mass. Relevance نام داشت و این محصولی که ما می‌فروختیم، توانایی ورود به یک پلتفرم و بررسی همه این روندهای رسانه‌های اجتماعی چیزی بود که حدود 2 تا 500000 دلار هزینه داشت. بنابراین ارزان نبود. بنابراین افرادی که این را خریداری کردند شرکت‌های بزرگی بودند و افرادی که چک‌ها را امضا می‌کردند مدیران بازاریابی یا رسانه‌های اجتماعی بودند. و وقتی آنها آن را خریداری می‌کردند، خودشان از آن استفاده نمی‌کردند، بلکه لاگین‌ها را به زیردستان خود مانند مدیران رسانه‌های اجتماعی یا مدیران بازاریابی می‌دادند. و می‌توانید ببینید که این دو نفر کاملاً متفاوت هستند. بنابراین وقتی ما بازخورد می‌گرفتیم، از دو گروه مختلف بازخورد می‌گرفتیم. ما بازخورد سطح کلان در مورد اینکه محصول ما به طور کلی باید چه کاری انجام دهد دریافت می‌کردیم. این از بالا به پایین مانند مدیران بازاریابی و این جور چیزها بود. و سپس ما بازخورد بسیار دقیق از خود کاربران داشتیم. اینها افرادی بودند که هر روز وارد سیستم می‌شدند و بازخوردهایی مانند اوه، دکمه این کجاست؟ من دوست دارم این کار را داخل پلتفرم انجام دهم. دو گروه کاربری جداگانه و دو مجموعه بازخورد جداگانه. باشه، پس خلاصه کنیم، کاربران و مشتریان گاهی اوقات دو گروه کاملاً متفاوت با مجموعه‌های مختلف بازخورد هستند، اما مهم است که به خاطر داشته باشید. فهمیدی؟ باشه، ادامه میدیم.
اصطلاحات :
* Macro level feedback:
بازخورد سطح کلان: بازخورد کلی در مورد محصول یا خدمات.
* Granular feedback:
بازخورد دقیق: بازخورد جزئی در مورد ویژگی‌های خاص محصول یا خدمات.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
آموزش جامع مدیریت محصول
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین) قسمت : 22 عنوان: کاربران و مشتریان. زبان: انگلیسی
قسمت 22 در کانال ارسال شد...❤️
https://www.tg-me.com/karyabi_modiriat_tehranut
گروه جامعه کاریابی تخصصی
دانشجویان و فارغ‌التحصیلان
مدیریت و مهندسی صنایع دانشگاه تهران
گروه جامعه کاریابی تخصصی
دانشجویان و فارغ‌التحصیلان
مدیریت و مهندسی صنایع دانشگاه تهران
Telegram
گروه تخصصی مدیریت و مهندسی صنایع - دانشگاه تهران
به گروه تخصصی و جامعه دانشگاهی دانشجویان و فارغ‌التحصیلان مدیریت و مهندسی صنایع دانشگاه تهران خوش آمدید!
https://www.tg-me.com/+yjE6qbEMnfthMmQ0
https://www.tg-me.com/+yjE6qbEMnfthMmQ0
Forwarded from آموزش جامع مدیریت محصول
Media is too big
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 15
عنوان: اسکرام چیست؟ و چگونه کار می کند؟
زبان: انگلیسی
قسمت : 15
عنوان: اسکرام چیست؟ و چگونه کار می کند؟
زبان: انگلیسی
Forwarded from آموزش جامع مدیریت محصول
015-What is Scrum and how does it work.srt
2.3 KB
زیرنویس انگلیسی قسمت 15 دوره جامع مدیریت محصول
Forwarded from آموزش جامع مدیریت محصول
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 15
عنوان: اسکرام چیست؟ و چگونه کار می کند؟
در این جلسه، درباره اسکرام (Scrum) و کانبان (Kanban) صحبت می‌کنیم که هر دو فلسفه یا چارچوبی برای توسعه نرم‌افزار چابک هستند. همانطور که می‌دانیم، چابک (Agile) فلسفه‌ای برای توسعه نرم‌افزار به صورت بهینه و تکرارشونده با همکاری زیاد بین اعضای تیم است. اما راهنمای عملی کردن آن چیست؟ به چه صورت اجرا می‌شود؟
دو متدولوژی یا ساختار بسیار محبوب برای توسعه نرم‌افزار چابک وجود دارد. یکی اسکرام است که احتمالا قبلا اسمش را شنیده‌اید و دیگری کانبان. نحوه تلفظ کانبان ممکن است کمی متفاوت باشد اما مهم نیست. هر دوی این روش‌ها را می‌توان به عنوان راهنماهایی برای توسعه نرم‌افزار به روش چابک در نظر گرفت.
بیایید با اسکرام شروع کنیم. این روش احتمالا رایج‌ترین از بین این دو است. نحوه اجرای آن یا شکل ظاهری‌اش را در چهار مرحله ساده بررسی می‌کنیم. البته اسکرام جزئیات زیادی دارد اما این چهار مورد، موارد اصلی آن هستند.
اولین مرحله، جلسه برنامه‌ریزی اسپرینت است. شما با یک بک‌لاگ محصول (Product Backlog) شروع می‌کنید. بک‌لاگ محصول فهرستی اولویت‌بندی شده از تمام کارهایی است که تصمیم گرفته‌اید انجام دهید یا ممکن است انجام دهید. تیم شما یک جلسه برنامه‌ریزی اسپرینت برگزار می‌کند. در این جلسه، مهم‌ترین ویژگی یا چند ویژگی از بالای بک‌لاگ محصول را انتخاب کرده و آن را به بک‌لاگ اسپرینت منتقل می‌کنید. سپس در مورد تمام کارهایی که برای پیاده‌سازی آن ویژگی نیاز دارید، صحبت می‌کنید. تیم شما با هم، کارهایی که برای تبدیل آن ویژگی به واقعیت لازم است را یادداشت می‌کنند. این کارها در قالب تسک (Ticket) وارد نرم‌افزار مدیریت پروژه می‌شوند.
دومین مرحله، توسعه است. اصل اساسی اسکرام این است که کار تیمتان در یک بازه زمانی به نام اسپرینت (Sprint) محدود می‌شود که معمولا دو هفته است. برخی شرکت‌ها اسپرینت‌های سه یا چهار هفته‌ای دارند اما دو هفته رایج‌ترین حالت است. در طول این دو هفته، تیم شما روی کارها تمرکز می‌کند و آنها را از بالای بک‌لاگ اسپرینت برداشته و به وضعیت «در حال انجام» و در نهایت «انجام شده» منتقل می‌کند. این تسک‌هایی هستند که آنها از یک ستون به ستون دیگر جابه‌جا می‌کنند. در پایان دو هفته، باید تمام موارد موجود در بک‌لاگ اسپرینت را تکمیل کرده باشید. اگر تکمیل نشده باشند، به اسپرینت بعدی منتقل می‌شوند.
مرحله سوم، جلسات استندآپ (Stand-up) است که بسیار رایج و مفید هستند. جلسات استندآپ، جلسات کوتاه روزانه‌ای هستند که معمولا صبح‌ها برگزار می‌شوند. چرا به آنها استندآپ می‌گویند؟ دلیلش این است که اگر به عنوان تیم سر پا بایستید و روی صندلی ننشینید، به طور کلی جلسه کوتاه و مختصر خواهد بود و تجربه نشان داده که این موضوع صحت دارد. هدف جلسه استندآپ این است که هر عضو تیم در مورد کاری که روز گذشته انجام داده، کاری که در حال حاضر روی آن کار می‌کند و کاری که قرار است بعدا انجام دهد، صحبت کند. مهم‌تر از همه، آنها باید هر گونه سوال یا درخواست کمکی را در طول جلسه استندآپ مطرح کنند. این جلسات روزانه که معمولا هر صبح برگزار می‌شوند، باعث می‌شوند همه چیز به آرامی پیش برود.
آخرین و مهم‌ترین بخش از اجرای اسکرام، جلسات گذشته‌نگر (Retrospective) است. جلسه گذشته‌نگر، برعکس جلسه برنامه‌ریزی اسپرینت است. گذشته‌نگر جلسه‌ای است که در پایان هر اسپرینت با تیم خود برگزار می‌کنید. همه افراد از جمله توسعه‌دهندگان، طراحان و غیره را در یک اتاق جمع می‌کنید و در مورد سه موضوع اصلی اسپرینت گذشته صحبت می‌کنید: چه چیزهایی خوب پیش رفت، چه چیزهایی خوب پیش نرفت و چه سوالاتی برای افراد وجود دارد.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
قسمت : 15
عنوان: اسکرام چیست؟ و چگونه کار می کند؟
در این جلسه، درباره اسکرام (Scrum) و کانبان (Kanban) صحبت می‌کنیم که هر دو فلسفه یا چارچوبی برای توسعه نرم‌افزار چابک هستند. همانطور که می‌دانیم، چابک (Agile) فلسفه‌ای برای توسعه نرم‌افزار به صورت بهینه و تکرارشونده با همکاری زیاد بین اعضای تیم است. اما راهنمای عملی کردن آن چیست؟ به چه صورت اجرا می‌شود؟
دو متدولوژی یا ساختار بسیار محبوب برای توسعه نرم‌افزار چابک وجود دارد. یکی اسکرام است که احتمالا قبلا اسمش را شنیده‌اید و دیگری کانبان. نحوه تلفظ کانبان ممکن است کمی متفاوت باشد اما مهم نیست. هر دوی این روش‌ها را می‌توان به عنوان راهنماهایی برای توسعه نرم‌افزار به روش چابک در نظر گرفت.
بیایید با اسکرام شروع کنیم. این روش احتمالا رایج‌ترین از بین این دو است. نحوه اجرای آن یا شکل ظاهری‌اش را در چهار مرحله ساده بررسی می‌کنیم. البته اسکرام جزئیات زیادی دارد اما این چهار مورد، موارد اصلی آن هستند.
اولین مرحله، جلسه برنامه‌ریزی اسپرینت است. شما با یک بک‌لاگ محصول (Product Backlog) شروع می‌کنید. بک‌لاگ محصول فهرستی اولویت‌بندی شده از تمام کارهایی است که تصمیم گرفته‌اید انجام دهید یا ممکن است انجام دهید. تیم شما یک جلسه برنامه‌ریزی اسپرینت برگزار می‌کند. در این جلسه، مهم‌ترین ویژگی یا چند ویژگی از بالای بک‌لاگ محصول را انتخاب کرده و آن را به بک‌لاگ اسپرینت منتقل می‌کنید. سپس در مورد تمام کارهایی که برای پیاده‌سازی آن ویژگی نیاز دارید، صحبت می‌کنید. تیم شما با هم، کارهایی که برای تبدیل آن ویژگی به واقعیت لازم است را یادداشت می‌کنند. این کارها در قالب تسک (Ticket) وارد نرم‌افزار مدیریت پروژه می‌شوند.
دومین مرحله، توسعه است. اصل اساسی اسکرام این است که کار تیمتان در یک بازه زمانی به نام اسپرینت (Sprint) محدود می‌شود که معمولا دو هفته است. برخی شرکت‌ها اسپرینت‌های سه یا چهار هفته‌ای دارند اما دو هفته رایج‌ترین حالت است. در طول این دو هفته، تیم شما روی کارها تمرکز می‌کند و آنها را از بالای بک‌لاگ اسپرینت برداشته و به وضعیت «در حال انجام» و در نهایت «انجام شده» منتقل می‌کند. این تسک‌هایی هستند که آنها از یک ستون به ستون دیگر جابه‌جا می‌کنند. در پایان دو هفته، باید تمام موارد موجود در بک‌لاگ اسپرینت را تکمیل کرده باشید. اگر تکمیل نشده باشند، به اسپرینت بعدی منتقل می‌شوند.
مرحله سوم، جلسات استندآپ (Stand-up) است که بسیار رایج و مفید هستند. جلسات استندآپ، جلسات کوتاه روزانه‌ای هستند که معمولا صبح‌ها برگزار می‌شوند. چرا به آنها استندآپ می‌گویند؟ دلیلش این است که اگر به عنوان تیم سر پا بایستید و روی صندلی ننشینید، به طور کلی جلسه کوتاه و مختصر خواهد بود و تجربه نشان داده که این موضوع صحت دارد. هدف جلسه استندآپ این است که هر عضو تیم در مورد کاری که روز گذشته انجام داده، کاری که در حال حاضر روی آن کار می‌کند و کاری که قرار است بعدا انجام دهد، صحبت کند. مهم‌تر از همه، آنها باید هر گونه سوال یا درخواست کمکی را در طول جلسه استندآپ مطرح کنند. این جلسات روزانه که معمولا هر صبح برگزار می‌شوند، باعث می‌شوند همه چیز به آرامی پیش برود.
آخرین و مهم‌ترین بخش از اجرای اسکرام، جلسات گذشته‌نگر (Retrospective) است. جلسه گذشته‌نگر، برعکس جلسه برنامه‌ریزی اسپرینت است. گذشته‌نگر جلسه‌ای است که در پایان هر اسپرینت با تیم خود برگزار می‌کنید. همه افراد از جمله توسعه‌دهندگان، طراحان و غیره را در یک اتاق جمع می‌کنید و در مورد سه موضوع اصلی اسپرینت گذشته صحبت می‌کنید: چه چیزهایی خوب پیش رفت، چه چیزهایی خوب پیش نرفت و چه سوالاتی برای افراد وجود دارد.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
Forwarded from آموزش جامع مدیریت محصول
ادامه قسمت 15 :
هدایت تیم در این فرآیند معمولا بر عهده مدیر محصول است. این جلسات تضمین می‌کنند که حرف همه اعضای تیم که سوال یا نگرانی در مورد تیم، ساختار یا فرآیند کاری دارند، شنیده شود و همه چیز به آرامی پیش برود.
خب حالا بیایید چهارچوب اسکرام و چهار جزء اصلی آن را مرور کنیم. اول جلسه برنامه‌ریزی اسپرینت است که در آن موارد منتخب از بک‌لاگ محصول را به بک‌لاگ اسپرینت منتقل می‌کنیم. دوم خود اسپرینت است که یک بازه زمانی محدود، معمولا دو هفته‌ای است، البته می‌تواند سه یا چهار هفته هم باشد، اما دو هفته رایج‌ترین حالت است. سوم جلسات استندآپ روزانه‌ای است که در طول اسپرینت برگزار می‌شود. این جلسات ۱۰ تا ۱۵ دقیقه‌ای هستند و برای اینکه افراد زیاد صحبت نکنند، به صورت ایستاده برگزار می‌شوند. در این جلسات در مورد کارهای دیروز، امروز و فردا صحبت می‌کنیم و هرگونه مشکلی که وجود دارد یا نیاز به همکاری است را روشن می‌کنیم. در نهایت جلسه گذشته‌نگر را داریم که در آن در مورد اینکه در طول اسپرینت چه چیزهایی خوب پیش رفت، چه چیزهایی خوب پیش نرفت و any outstanding questions که افراد دارند صحبت می‌کنیم.
خب، دوستان، در جلسه بعدی می‌بینیم.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
هدایت تیم در این فرآیند معمولا بر عهده مدیر محصول است. این جلسات تضمین می‌کنند که حرف همه اعضای تیم که سوال یا نگرانی در مورد تیم، ساختار یا فرآیند کاری دارند، شنیده شود و همه چیز به آرامی پیش برود.
خب حالا بیایید چهارچوب اسکرام و چهار جزء اصلی آن را مرور کنیم. اول جلسه برنامه‌ریزی اسپرینت است که در آن موارد منتخب از بک‌لاگ محصول را به بک‌لاگ اسپرینت منتقل می‌کنیم. دوم خود اسپرینت است که یک بازه زمانی محدود، معمولا دو هفته‌ای است، البته می‌تواند سه یا چهار هفته هم باشد، اما دو هفته رایج‌ترین حالت است. سوم جلسات استندآپ روزانه‌ای است که در طول اسپرینت برگزار می‌شود. این جلسات ۱۰ تا ۱۵ دقیقه‌ای هستند و برای اینکه افراد زیاد صحبت نکنند، به صورت ایستاده برگزار می‌شوند. در این جلسات در مورد کارهای دیروز، امروز و فردا صحبت می‌کنیم و هرگونه مشکلی که وجود دارد یا نیاز به همکاری است را روشن می‌کنیم. در نهایت جلسه گذشته‌نگر را داریم که در آن در مورد اینکه در طول اسپرینت چه چیزهایی خوب پیش رفت، چه چیزهایی خوب پیش نرفت و any outstanding questions که افراد دارند صحبت می‌کنیم.
خب، دوستان، در جلسه بعدی می‌بینیم.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
Forwarded from آموزش جامع مدیریت محصول
اصطلاحات:
* فلسفه چابک (Agile Philosophy): رویکردی برای توسعه نرم‌افزار که بر همکاری، انعطاف‌پذیری و ارائه سریع ارزش به مشتریان تمرکز دارد.
* بک‌لاگ محصول (Product Backlog): فهرستی اولویت‌بندی شده از تمام کارهایی که باید برای یک محصول انجام شود.
* جلسه برنامه‌ریزی اسپرینت (Sprint Planning Meeting): جلسه‌ای که در آن تیم محصول، کارهایی را که در اسپرینت بعدی انجام خواهد داد، انتخاب می‌کند و اولویت‌بندی می‌کند.
* اسپرینت (Sprint): بازه زمانی کوتاه (معمولاً 1 تا 4 هفته) که در آن تیمی برای تکمیل یک مجموعه از ویژگی‌های محصول تلاش می‌کند.
* بک‌لاگ اسپرینت (Sprint Backlog): فهرستی از کارهایی که تیم در طول یک اسپرینت خاص باید انجام دهد.
* تسک (Ticket): واحد کار کوچکی که به عنوان بخشی از یک اسپرینت باید تکمیل شود.
* نرم‌افزار مدیریت پروژه: ابزاری برای کمک به تیم‌ها در برنامه‌ریزی، پیگیری و مدیریت کارها.
* جلسه استندآپ (Stand-up Meeting): جلسه روزانه کوتاهی که در آن اعضای تیم در مورد پیشرفت خود در اسپرینت صحبت می‌کنند.
* جلسه گذشته‌نگر (Retrospective Meeting): جلسه‌ای که در آن تیم در مورد آنچه در اسپرینت گذشته خوب پیش رفته و چه چیزی خوب پیش نرفته است، بحث می‌کند و برای بهبود در اسپرینت‌های آینده برنامه‌ریزی می‌کند.
* Scrum Master: فردی که به تسهیل اجرای اسکرام در تیم کمک می‌کند.
* Product Owner: فردی که مسئولیت بک‌لاگ محصول و ارائه ارزش به مشتریان را بر عهده دارد.
* Development Team: تیمی از افراد که مسئول توسعه و تحویل ویژگی‌های محصول هستند.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
* فلسفه چابک (Agile Philosophy): رویکردی برای توسعه نرم‌افزار که بر همکاری، انعطاف‌پذیری و ارائه سریع ارزش به مشتریان تمرکز دارد.
* بک‌لاگ محصول (Product Backlog): فهرستی اولویت‌بندی شده از تمام کارهایی که باید برای یک محصول انجام شود.
* جلسه برنامه‌ریزی اسپرینت (Sprint Planning Meeting): جلسه‌ای که در آن تیم محصول، کارهایی را که در اسپرینت بعدی انجام خواهد داد، انتخاب می‌کند و اولویت‌بندی می‌کند.
* اسپرینت (Sprint): بازه زمانی کوتاه (معمولاً 1 تا 4 هفته) که در آن تیمی برای تکمیل یک مجموعه از ویژگی‌های محصول تلاش می‌کند.
* بک‌لاگ اسپرینت (Sprint Backlog): فهرستی از کارهایی که تیم در طول یک اسپرینت خاص باید انجام دهد.
* تسک (Ticket): واحد کار کوچکی که به عنوان بخشی از یک اسپرینت باید تکمیل شود.
* نرم‌افزار مدیریت پروژه: ابزاری برای کمک به تیم‌ها در برنامه‌ریزی، پیگیری و مدیریت کارها.
* جلسه استندآپ (Stand-up Meeting): جلسه روزانه کوتاهی که در آن اعضای تیم در مورد پیشرفت خود در اسپرینت صحبت می‌کنند.
* جلسه گذشته‌نگر (Retrospective Meeting): جلسه‌ای که در آن تیم در مورد آنچه در اسپرینت گذشته خوب پیش رفته و چه چیزی خوب پیش نرفته است، بحث می‌کند و برای بهبود در اسپرینت‌های آینده برنامه‌ریزی می‌کند.
* Scrum Master: فردی که به تسهیل اجرای اسکرام در تیم کمک می‌کند.
* Product Owner: فردی که مسئولیت بک‌لاگ محصول و ارائه ارزش به مشتریان را بر عهده دارد.
* Development Team: تیمی از افراد که مسئول توسعه و تحویل ویژگی‌های محصول هستند.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
Forwarded from آموزش جامع مدیریت محصول
Media is too big
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 16
عنوان: کانبان چیست؟ و چگونه کار می کند؟
زبان: انگلیسی
قسمت : 16
عنوان: کانبان چیست؟ و چگونه کار می کند؟
زبان: انگلیسی
Forwarded from آموزش جامع مدیریت محصول
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 16
عنوان: کانبان چیست؟ و چگونه کار می کند؟
خب، کانبان چیست و چه تفاوتی با اسکرام دارد؟ راستی، تلفظش کانبان هست یا کانبان؟ تقریبا مطمئنم کانبان درسته، ولی اگه اشتباه می کنم توئیت کنید بهم بگین.
مثل اسکرام، کانبان هم یک چارچوب برای پیاده سازی توسعه نرم افزار Agile است، با این تفاوت که به اندازه اسکرام در مورد جلسات و زمان بندی سخت گیرانه نیست.
احتمالا قبلا چیزی شبیه به برد کانبان دیده اید. این برد فقط شامل چند ستون با کارت هایی روی آن است که می توانید با توجه به وضعیت آن آیتم، از یک ستون به ستون دیگر جابجا کنید. مثلا ستون هایی برای "باید انجام شود"، "در حال انجام" و سپس "انجام شده".
با این حال، فقط به خاطر اینکه چیزی یک برد به سبک کانبان دارد، به این معنی نیست که این همان فرایند کانبان است.
کلیدهای اصلی کانبان این هستند که از اسپرینت استفاده نمی کند، بنابراین کار تیمتان را در دوره های دو یا چهار هفته ای محدود نمی کنید. همچنین، از آنجایی که اسپرینتی وجود ندارد، پس Backlog اسپرینت هم نداریم (بعدا در موردش صحبت می کنیم)، و فقط خود Backlog محصول وجود دارد.
بنابراین، تیم فقط روی کارهایش (تیکت ها) کار می کند، آنها را انجام می دهد، به ستون "انجام شده" منتقل می کند و سپس کار بعدی را از بالای Backlog محصول برمی دارد. این Backlog برای همیشه ادامه دارد، بی انتهاست.
همچنین، کانبان با اسکرام در این مورد هم متفاوت است که هیچ نوع جلسه خاصی را تجویز نمی کند، برخلاف اسکرام که جلسات ایستاده (استندآپ)، جلسات برنامه ریزی اسپرینت و جلسات بازنگری دارد.
یک تفاوت بزرگ دیگر هم وجود دارد. کانبان بر اساس این تئوری عمل می کند که در هر زمان فقط تعداد معینی از آیتم ها می توانند در حال انجام یا در هر وضعیت دیگری باشند. اینکه چه تعداد آیتم در هر وضعیت خاص باشد، به تصمیم شما و تیمتان بستگی دارد.
برخی از تیم های نرم افزار از کانبان استفاده می کنند، اما به نظر می رسد برای تیم هایی که خیلی نگران مسائلی مانند تخمین زدن نیستند و به طور مداوم وظایف را با سرعت نسبتاً بالایی از همان مراحل عبور می دهند تا زمانی که کامل شوند، بهتر کار می کند. به عنوان مثال، تیم های خدمات مشتری اغلب از سبک کاری کانبان استفاده می کنند، درست است؟
حالا که با اسکرام و کانبان آشنا شدیم، سوال بزرگ این است که کدامیک بهتر است؟ متاسفم که ناامیدتان می کنم، اما در اینجا پاسخ قطعی وجود ندارد، زیرا به این بستگی دارد که تیم شما چه چیزی را ترجیح می دهد. بهترین فرآیند، فرآیندی است که شما از استفاده از آن لذت می برید.
همانطور که می بینید، کانبان یک روش راحت تر برای انجام توسعه نرم افزار Agile است، اما یک عیب بزرگ دارد. از آنجایی که از اسپرینت استفاده نمی کند، پیش بینی مدت زمان لازم برای تکمیل کار دشوارتر خواهد بود. نگران این موضوع فعلا نباشید، زیرا در جلسات بعدی در مورد مسائلی مانند تخمین و سرعت صحبت خواهیم کرد.
خب، بیایید مرور کنیم. کانبان فقط یک راه دیگر برای پیاده سازی یک گردش کار توسعه نرم افزار از نوع Agile است. کمی کمتر دستوری از اسکرام است و از اسپرینت استفاده نمی کند.
خیلی خوب، همه، در جلسه بعدی می بینمتان.
اصطلاحات:
* Kanban (کانبان):
یک چارچوب چابک برای مدیریت پروژه است که از یک برد کانبان برای تجسم جریان کار استفاده می کند.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
قسمت : 16
عنوان: کانبان چیست؟ و چگونه کار می کند؟
خب، کانبان چیست و چه تفاوتی با اسکرام دارد؟ راستی، تلفظش کانبان هست یا کانبان؟ تقریبا مطمئنم کانبان درسته، ولی اگه اشتباه می کنم توئیت کنید بهم بگین.
مثل اسکرام، کانبان هم یک چارچوب برای پیاده سازی توسعه نرم افزار Agile است، با این تفاوت که به اندازه اسکرام در مورد جلسات و زمان بندی سخت گیرانه نیست.
احتمالا قبلا چیزی شبیه به برد کانبان دیده اید. این برد فقط شامل چند ستون با کارت هایی روی آن است که می توانید با توجه به وضعیت آن آیتم، از یک ستون به ستون دیگر جابجا کنید. مثلا ستون هایی برای "باید انجام شود"، "در حال انجام" و سپس "انجام شده".
با این حال، فقط به خاطر اینکه چیزی یک برد به سبک کانبان دارد، به این معنی نیست که این همان فرایند کانبان است.
کلیدهای اصلی کانبان این هستند که از اسپرینت استفاده نمی کند، بنابراین کار تیمتان را در دوره های دو یا چهار هفته ای محدود نمی کنید. همچنین، از آنجایی که اسپرینتی وجود ندارد، پس Backlog اسپرینت هم نداریم (بعدا در موردش صحبت می کنیم)، و فقط خود Backlog محصول وجود دارد.
بنابراین، تیم فقط روی کارهایش (تیکت ها) کار می کند، آنها را انجام می دهد، به ستون "انجام شده" منتقل می کند و سپس کار بعدی را از بالای Backlog محصول برمی دارد. این Backlog برای همیشه ادامه دارد، بی انتهاست.
همچنین، کانبان با اسکرام در این مورد هم متفاوت است که هیچ نوع جلسه خاصی را تجویز نمی کند، برخلاف اسکرام که جلسات ایستاده (استندآپ)، جلسات برنامه ریزی اسپرینت و جلسات بازنگری دارد.
یک تفاوت بزرگ دیگر هم وجود دارد. کانبان بر اساس این تئوری عمل می کند که در هر زمان فقط تعداد معینی از آیتم ها می توانند در حال انجام یا در هر وضعیت دیگری باشند. اینکه چه تعداد آیتم در هر وضعیت خاص باشد، به تصمیم شما و تیمتان بستگی دارد.
برخی از تیم های نرم افزار از کانبان استفاده می کنند، اما به نظر می رسد برای تیم هایی که خیلی نگران مسائلی مانند تخمین زدن نیستند و به طور مداوم وظایف را با سرعت نسبتاً بالایی از همان مراحل عبور می دهند تا زمانی که کامل شوند، بهتر کار می کند. به عنوان مثال، تیم های خدمات مشتری اغلب از سبک کاری کانبان استفاده می کنند، درست است؟
حالا که با اسکرام و کانبان آشنا شدیم، سوال بزرگ این است که کدامیک بهتر است؟ متاسفم که ناامیدتان می کنم، اما در اینجا پاسخ قطعی وجود ندارد، زیرا به این بستگی دارد که تیم شما چه چیزی را ترجیح می دهد. بهترین فرآیند، فرآیندی است که شما از استفاده از آن لذت می برید.
همانطور که می بینید، کانبان یک روش راحت تر برای انجام توسعه نرم افزار Agile است، اما یک عیب بزرگ دارد. از آنجایی که از اسپرینت استفاده نمی کند، پیش بینی مدت زمان لازم برای تکمیل کار دشوارتر خواهد بود. نگران این موضوع فعلا نباشید، زیرا در جلسات بعدی در مورد مسائلی مانند تخمین و سرعت صحبت خواهیم کرد.
خب، بیایید مرور کنیم. کانبان فقط یک راه دیگر برای پیاده سازی یک گردش کار توسعه نرم افزار از نوع Agile است. کمی کمتر دستوری از اسکرام است و از اسپرینت استفاده نمی کند.
خیلی خوب، همه، در جلسه بعدی می بینمتان.
اصطلاحات:
* Kanban (کانبان):
یک چارچوب چابک برای مدیریت پروژه است که از یک برد کانبان برای تجسم جریان کار استفاده می کند.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
Media is too big
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 23
عنوان: تحقیقات بازار برآورد اندازه بازار.
زبان: انگلیسی
قسمت : 23
عنوان: تحقیقات بازار برآورد اندازه بازار.
زبان: انگلیسی
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 23
عنوان: تحقیقات بازار برآورد اندازه بازار.
بخش اول:
این بخش در مورد تحلیل رقابتی بازار است. بخش بزرگی از مدیریت محصول، اطمینان از این است که بازاری که قصد ورود به آن را دارید به اندازه کافی بزرگ است تا ارزش ورود به آن را داشته باشد. این موضوع چه در صورتی که مدیر محصول یک شرکت باشید و به دنبال ساخت یک ویژگی یا محصولی باشید که شما را وارد بازار دیگری کند و چه در صورتی که کسب و کار جدید خود را به تنهایی راه اندازی کنید، صدق می‌کند. دو رویکرد رایج برای فکر کردن در مورد اندازه بازار وجود دارد. یکی از آنها بالا به پایین (Top Down) و دیگری پایین به بالا (Bottom Up) است.
تحلیل بالا به پایین با محاسبه کل بازار و سپس تخمین سهم شما از بازار محاسبه می‌شود. بیایید فرض کنیم که یک اپلیکیشن آیفون برای علاقه‌مندان به بستنی می‌فروشیم. برآورد بالا به پایین چیزی شبیه به این خواهد بود، "خب، می‌دانیم که در ایالات متحده 100000 علاقه‌مند به بستنی با آیفون وجود دارد. بنابراین، اگر بتوانیم فقط 10 درصد از آنها را برای دانلود اپلیکیشن خود به قیمت 5 دلار برای هر نفر جذب کنیم، 50000 دلار درآمد خواهیم داشت." مشکل این رویکرد این است که شما باید در مورد میزان نفوذ بازار در آن بازار خاص، فرضیاتی را مطرح کنید. حتی اگر به نظر منطقی برسد، این معتبرترین روش برای تخمین بازار بالقوه نیست.
تحلیل پایین به بالا با فکر کردن به فروش فعلی محصولات مشابه و سپس تخمین میزان فروش قابل تصاحب از آنها انجام می‌شود. این رویکرد بسیار دقیق‌تر است زیرا به الگوهای موجود در فروش امروز به جای کل بازار نگاه می‌کند. این به عنوان یک مدیر محصول روش بهتری برای انجام کار است، اما کمی بیشتر تلاش و زمان می‌برد.
باز هم، بیایید وانمود کنیم که یک اپلیکیشن آیفون برای علاقه‌مندان به بستنی داریم. اولاً، باید از خود بپرسیم که مردم در حال حاضر اپلیکیشن‌های مرتبط با بستنی یا غذا را از کجا خریداری می‌کنند. بدیهی است که در این مورد، این اپ استور اپل خواهد بود. در مرحله بعد، به حجم فروش اپلیکیشن‌های مشابه موجود فکر می‌کنیم. ممکن است فکر کنید که هیچ اپلیکیشن مشابهی با اپلیکیشن شما وجود ندارد، اما در واقع احتمالاً اپلیکیشن‌هایی وجود دارند که حداقل کمی شبیه هستند. اگر اپلیکیشن‌های دیگری برای علاقه‌مندان به بستنی وجود ندارد، می‌توانیم به اپلیکیشن‌های دیگری که با انواع دیگر دسرها یا غذاها سروکار دارند نگاه کنیم.
کمی تحقیق آنلاین انجام می‌دهیم یا به وب‌سایت‌هایی مانند App Annie سر می‌زنیم و به حجم فروش و محبوبیت اپلیکیشن‌های موجود نگاه می‌کنیم. بیایید فرض کنیم که این اپلیکیشن‌های مشابه حدود 1000 بار در ماه به صورت جهانی دانلود می‌شوند. در آن زمان می‌توانیم یک فرض محافظه‌کارانه داشته باشیم و بگوییم که اگر 5 درصد از فروش ماهانه آنها را به دست آوریم، حدود 50 دانلود در ماه می‌شود. پس تفاوت بین این دو رویکرد را می‌بینید؟ رویکرد بالا به پایین به اندازه کل بازار یا تعداد بالقوه کاربران فکر می‌کند که همیشه بسیار خوش‌بینانه است. بازار پایین به بالا به روندها و داده‌های فعلی نگاه می‌کند تا اطمینان حاصل کند که فرضیات ما کمی نزدیک‌تر به واقعیت باقی می‌مانند. هنگام شروع یک محصول یا کسب و کار یا افزودن یک ویژگی جدید، بهتر است محافظه‌کار باشید تا اینکه بیش از حد خوش‌بین باشید.
در نهایت، می‌خواهم چند نکته در مورد ابزار و تکنیک‌هایی که می‌توانید برای نگاه کردن به برخی از داده‌های بازار استفاده کنید، به شما بگویم. اولین کاری که می‌توانید انجام دهید این است که فقط گزارش‌های صنعتی را برای "X" یا اندازه صنعت یا بازار برای "X" فقط با استفاده از گوگل جستجو کنید. این یک راه واقعاً خوب برای یافتن گزارش‌های موجودی است که گروه‌های تحقیقاتی صنعت منتشر کرده‌اند.
دوم اینکه، اگر به وب‌سایت‌های رقیبان یا سایر اپلیکیشن‌های مشابه نگاه می‌کنید، می‌توانید از وب‌سایتی مانند compete.com استفاده کنید و میزان ترافیکی که وب‌سایت‌های رقابتی مختلف دریافت می‌کنند را بررسی کنید. می توانید این را با سایر موارد یا سایر صنایع مقایسه کنید و یک نمای کلی واقعاً خوب از رقابت به دست آورید.
کانال آموزش دوره مدیریت محصول
@ProductManagementCourses
قسمت : 23
عنوان: تحقیقات بازار برآورد اندازه بازار.
بخش اول:
این بخش در مورد تحلیل رقابتی بازار است. بخش بزرگی از مدیریت محصول، اطمینان از این است که بازاری که قصد ورود به آن را دارید به اندازه کافی بزرگ است تا ارزش ورود به آن را داشته باشد. این موضوع چه در صورتی که مدیر محصول یک شرکت باشید و به دنبال ساخت یک ویژگی یا محصولی باشید که شما را وارد بازار دیگری کند و چه در صورتی که کسب و کار جدید خود را به تنهایی راه اندازی کنید، صدق می‌کند. دو رویکرد رایج برای فکر کردن در مورد اندازه بازار وجود دارد. یکی از آنها بالا به پایین (Top Down) و دیگری پایین به بالا (Bottom Up) است.
تحلیل بالا به پایین با محاسبه کل بازار و سپس تخمین سهم شما از بازار محاسبه می‌شود. بیایید فرض کنیم که یک اپلیکیشن آیفون برای علاقه‌مندان به بستنی می‌فروشیم. برآورد بالا به پایین چیزی شبیه به این خواهد بود، "خب، می‌دانیم که در ایالات متحده 100000 علاقه‌مند به بستنی با آیفون وجود دارد. بنابراین، اگر بتوانیم فقط 10 درصد از آنها را برای دانلود اپلیکیشن خود به قیمت 5 دلار برای هر نفر جذب کنیم، 50000 دلار درآمد خواهیم داشت." مشکل این رویکرد این است که شما باید در مورد میزان نفوذ بازار در آن بازار خاص، فرضیاتی را مطرح کنید. حتی اگر به نظر منطقی برسد، این معتبرترین روش برای تخمین بازار بالقوه نیست.
تحلیل پایین به بالا با فکر کردن به فروش فعلی محصولات مشابه و سپس تخمین میزان فروش قابل تصاحب از آنها انجام می‌شود. این رویکرد بسیار دقیق‌تر است زیرا به الگوهای موجود در فروش امروز به جای کل بازار نگاه می‌کند. این به عنوان یک مدیر محصول روش بهتری برای انجام کار است، اما کمی بیشتر تلاش و زمان می‌برد.
باز هم، بیایید وانمود کنیم که یک اپلیکیشن آیفون برای علاقه‌مندان به بستنی داریم. اولاً، باید از خود بپرسیم که مردم در حال حاضر اپلیکیشن‌های مرتبط با بستنی یا غذا را از کجا خریداری می‌کنند. بدیهی است که در این مورد، این اپ استور اپل خواهد بود. در مرحله بعد، به حجم فروش اپلیکیشن‌های مشابه موجود فکر می‌کنیم. ممکن است فکر کنید که هیچ اپلیکیشن مشابهی با اپلیکیشن شما وجود ندارد، اما در واقع احتمالاً اپلیکیشن‌هایی وجود دارند که حداقل کمی شبیه هستند. اگر اپلیکیشن‌های دیگری برای علاقه‌مندان به بستنی وجود ندارد، می‌توانیم به اپلیکیشن‌های دیگری که با انواع دیگر دسرها یا غذاها سروکار دارند نگاه کنیم.
کمی تحقیق آنلاین انجام می‌دهیم یا به وب‌سایت‌هایی مانند App Annie سر می‌زنیم و به حجم فروش و محبوبیت اپلیکیشن‌های موجود نگاه می‌کنیم. بیایید فرض کنیم که این اپلیکیشن‌های مشابه حدود 1000 بار در ماه به صورت جهانی دانلود می‌شوند. در آن زمان می‌توانیم یک فرض محافظه‌کارانه داشته باشیم و بگوییم که اگر 5 درصد از فروش ماهانه آنها را به دست آوریم، حدود 50 دانلود در ماه می‌شود. پس تفاوت بین این دو رویکرد را می‌بینید؟ رویکرد بالا به پایین به اندازه کل بازار یا تعداد بالقوه کاربران فکر می‌کند که همیشه بسیار خوش‌بینانه است. بازار پایین به بالا به روندها و داده‌های فعلی نگاه می‌کند تا اطمینان حاصل کند که فرضیات ما کمی نزدیک‌تر به واقعیت باقی می‌مانند. هنگام شروع یک محصول یا کسب و کار یا افزودن یک ویژگی جدید، بهتر است محافظه‌کار باشید تا اینکه بیش از حد خوش‌بین باشید.
در نهایت، می‌خواهم چند نکته در مورد ابزار و تکنیک‌هایی که می‌توانید برای نگاه کردن به برخی از داده‌های بازار استفاده کنید، به شما بگویم. اولین کاری که می‌توانید انجام دهید این است که فقط گزارش‌های صنعتی را برای "X" یا اندازه صنعت یا بازار برای "X" فقط با استفاده از گوگل جستجو کنید. این یک راه واقعاً خوب برای یافتن گزارش‌های موجودی است که گروه‌های تحقیقاتی صنعت منتشر کرده‌اند.
دوم اینکه، اگر به وب‌سایت‌های رقیبان یا سایر اپلیکیشن‌های مشابه نگاه می‌کنید، می‌توانید از وب‌سایتی مانند compete.com استفاده کنید و میزان ترافیکی که وب‌سایت‌های رقابتی مختلف دریافت می‌کنند را بررسی کنید. می توانید این را با سایر موارد یا سایر صنایع مقایسه کنید و یک نمای کلی واقعاً خوب از رقابت به دست آورید.
کانال آموزش دوره مدیریت محصول
@ProductManagementCourses
بخش دوم و پایانی:
ابزار دیگری که می توانید از آن استفاده کنید، ابزار کلیدواژه Google AdWords است. این ابزاری است که گوگل برای افرادی که می خواهند در گوگل تبلیغاتی قرار دهند، تحقیق کند. این ابزار حجم و عبارات مرتبط با جستجوها در گوگل را به شما نشان می دهد و برای تعیین میزان علاقه به برنامه یا محصول شما بسیار ارزشمند است. همچنین می توانید چیزهایی مانند توییتر و ردیت را جستجو کنید تا ببینید مردم در مورد چیزهای مرتبط با محصول شما چه می گویند. این همچنین این مزیت را دارد که به شما نشان دهد که آنها چه مشکلاتی دارند، در صورت وجود، زیرا مردم معمولاً نظرات اضافی اضافه می کنند یا پاسخ می دهند و می گویند، خوب، این چیزی است که من در مورد یک محصول خاص دوست دارم یا دوست ندارم.
کانال آموزش دوره مدیریت محصول
@ProductManagementCourses
ابزار دیگری که می توانید از آن استفاده کنید، ابزار کلیدواژه Google AdWords است. این ابزاری است که گوگل برای افرادی که می خواهند در گوگل تبلیغاتی قرار دهند، تحقیق کند. این ابزار حجم و عبارات مرتبط با جستجوها در گوگل را به شما نشان می دهد و برای تعیین میزان علاقه به برنامه یا محصول شما بسیار ارزشمند است. همچنین می توانید چیزهایی مانند توییتر و ردیت را جستجو کنید تا ببینید مردم در مورد چیزهای مرتبط با محصول شما چه می گویند. این همچنین این مزیت را دارد که به شما نشان دهد که آنها چه مشکلاتی دارند، در صورت وجود، زیرا مردم معمولاً نظرات اضافی اضافه می کنند یا پاسخ می دهند و می گویند، خوب، این چیزی است که من در مورد یک محصول خاص دوست دارم یا دوست ندارم.
کانال آموزش دوره مدیریت محصول
@ProductManagementCourses
آموزش جامع مدیریت محصول
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین) قسمت : 23 عنوان: تحقیقات بازار برآورد اندازه بازار. زبان: انگلیسی
🔥🔥قسمت 23 از مجموعه آموزش های جامع مدیریت محصول لینکدین 🔥🔥
آموزش جامع مدیریت محصول
https://www.tg-me.com/Compressor_irobot
سلام وقت همگی بخیر ❤️
دوستانی که دانلود کردن فایل ها براشون سنگین هست میتونند از این ربات تلگرامی استفاده کنند برای کاهش حجم فایل ویدئو🔥
دوستانی که دانلود کردن فایل ها براشون سنگین هست میتونند از این ربات تلگرامی استفاده کنند برای کاهش حجم فایل ویدئو🔥
Forwarded from آموزش جامع مدیریت محصول
This media is not supported in your browser
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 17
عنوان: توسعه آبشاری(waterfall) چیست؟
زبان: انگلیسی
قسمت : 17
عنوان: توسعه آبشاری(waterfall) چیست؟
زبان: انگلیسی
Forwarded from آموزش جامع مدیریت محصول
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 17
عنوان: توسعه آبشاری(waterfall) چیست؟
در مثال برنامه‌ی Agile، ما آن ۱۰ قابلیتی را که فکر می‌کردیم به آنها نیاز داریم، در نظر گرفتیم. اما به جای توسعه‌ی همه‌ی آنها، تنها چند مورد از مهم‌ترین‌ها را انتخاب کردیم. سپس روی آن قابلیت‌های انتخاب‌شده تحقیق و بررسی (Research) انجام دادیم، آنها را طراحی (Design) و توسعه (Develop) دادیم، و بعد از انتشار (Release)، بازخورد (Feedback) گرفتیم تا ببینیم آیا اینها همان چیزهایی بودند که کاربران به آنها علاقه‌مند بودند یا خیر.
این رویکرد چابک (Agile) با رویکرد آبشاری (Waterfall) کاملا متفاوت است. در Waterfall، ما هر ۱۰ قابلیتی را که فکر می‌کنیم به آنها نیاز داریم، به طور همزمان توسعه می‌دهیم. بنابراین، ما همزمان روی تحقیق، طراحی، توسعه و انتشار تک تکِ آنها کار می‌کنیم.
انجام کارها به روش آبشاری گاهی اوقات بسیار ریسک‌پذیر است، زیرا ممکن است محصول نرم‌افزاری شما ویژگی‌های زیادی داشته باشد، و توسعه‌ی همه‌ی آنها به طور همزمان، زمان زیادی را می‌طلبد. در این مدت، ممکن است رقبای شما اقدام جدیدی انجام دهند، یا شما چیز دیگری در مورد نیازهای کاربران یا بازار کشف کنید که تطبیق با آن با رویکرد آبشاری بسیار دشوار باشد. همچنین ممکن است متوجه شوید که بعد از توسعه‌ی همه‌ی ویژگی‌ها، کاربران به چیز دیگری نیاز داشته‌اند که زمان کمی را صرف آن کرده‌اید، در حالی که بیشترین زمان را صرف توسعه‌ی چیزهایی کرده‌اید که کاربران واقعاً از آنها استفاده نمی‌کنند.
بنابراین، بعد از تمام این انتقادها به توسعه‌ی آبشاری، شاید فکر کنید که آیا اصلاً این روش کاربردی دارد؟ خب، در واقع چند مورد خاص وجود دارد که توسعه‌ی آبشاری در آنها بسیار مفید است و ما در سخنرانی بعدی در مورد آنها صحبت خواهیم کرد.
اصطلاحات:
* Waterfall (آبشاری):
روشی خطی برای مدیریت پروژه است که مراحل آن به ترتیب انجام می‌شوند و بازگشت به مراحل قبلی وجود ندارد.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses
قسمت : 17
عنوان: توسعه آبشاری(waterfall) چیست؟
در مثال برنامه‌ی Agile، ما آن ۱۰ قابلیتی را که فکر می‌کردیم به آنها نیاز داریم، در نظر گرفتیم. اما به جای توسعه‌ی همه‌ی آنها، تنها چند مورد از مهم‌ترین‌ها را انتخاب کردیم. سپس روی آن قابلیت‌های انتخاب‌شده تحقیق و بررسی (Research) انجام دادیم، آنها را طراحی (Design) و توسعه (Develop) دادیم، و بعد از انتشار (Release)، بازخورد (Feedback) گرفتیم تا ببینیم آیا اینها همان چیزهایی بودند که کاربران به آنها علاقه‌مند بودند یا خیر.
این رویکرد چابک (Agile) با رویکرد آبشاری (Waterfall) کاملا متفاوت است. در Waterfall، ما هر ۱۰ قابلیتی را که فکر می‌کنیم به آنها نیاز داریم، به طور همزمان توسعه می‌دهیم. بنابراین، ما همزمان روی تحقیق، طراحی، توسعه و انتشار تک تکِ آنها کار می‌کنیم.
انجام کارها به روش آبشاری گاهی اوقات بسیار ریسک‌پذیر است، زیرا ممکن است محصول نرم‌افزاری شما ویژگی‌های زیادی داشته باشد، و توسعه‌ی همه‌ی آنها به طور همزمان، زمان زیادی را می‌طلبد. در این مدت، ممکن است رقبای شما اقدام جدیدی انجام دهند، یا شما چیز دیگری در مورد نیازهای کاربران یا بازار کشف کنید که تطبیق با آن با رویکرد آبشاری بسیار دشوار باشد. همچنین ممکن است متوجه شوید که بعد از توسعه‌ی همه‌ی ویژگی‌ها، کاربران به چیز دیگری نیاز داشته‌اند که زمان کمی را صرف آن کرده‌اید، در حالی که بیشترین زمان را صرف توسعه‌ی چیزهایی کرده‌اید که کاربران واقعاً از آنها استفاده نمی‌کنند.
بنابراین، بعد از تمام این انتقادها به توسعه‌ی آبشاری، شاید فکر کنید که آیا اصلاً این روش کاربردی دارد؟ خب، در واقع چند مورد خاص وجود دارد که توسعه‌ی آبشاری در آنها بسیار مفید است و ما در سخنرانی بعدی در مورد آنها صحبت خواهیم کرد.
اصطلاحات:
* Waterfall (آبشاری):
روشی خطی برای مدیریت پروژه است که مراحل آن به ترتیب انجام می‌شوند و بازگشت به مراحل قبلی وجود ندارد.
کانال آموزش دوره جامع مدیریت محصول
@ProductManagementCourses