Telegram Web Link
Media is too big
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 15
عنوان: اسکرام چیست؟ و چگونه کار می کند؟
زبان: انگلیسی
015-What is Scrum and how does it work.srt
2.3 KB
زیرنویس انگلیسی قسمت 15 دوره جامع مدیریت محصول
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 15
عنوان: اسکرام چیست؟ و چگونه کار می کند؟

در این جلسه، درباره اسکرام (Scrum) و کانبان (Kanban) صحبت می‌کنیم که هر دو فلسفه یا چارچوبی برای توسعه نرم‌افزار چابک هستند. همانطور که می‌دانیم، چابک (Agile) فلسفه‌ای برای توسعه نرم‌افزار به صورت بهینه و تکرارشونده با همکاری زیاد بین اعضای تیم است. اما راهنمای عملی کردن آن چیست؟ به چه صورت اجرا می‌شود؟

دو متدولوژی یا ساختار بسیار محبوب برای توسعه نرم‌افزار چابک وجود دارد. یکی اسکرام است که احتمالا قبلا اسمش را شنیده‌اید و دیگری کانبان. نحوه تلفظ کانبان ممکن است کمی متفاوت باشد اما مهم نیست. هر دوی این روش‌ها را می‌توان به عنوان راهنماهایی برای توسعه نرم‌افزار به روش چابک در نظر گرفت.

بیایید با اسکرام شروع کنیم. این روش احتمالا رایج‌ترین از بین این دو است. نحوه اجرای آن یا شکل ظاهری‌اش را در چهار مرحله ساده بررسی می‌کنیم. البته اسکرام جزئیات زیادی دارد اما این چهار مورد، موارد اصلی آن هستند.

اولین مرحله، جلسه برنامه‌ریزی اسپرینت است. شما با یک بک‌لاگ محصول (Product Backlog) شروع می‌کنید. بک‌لاگ محصول فهرستی اولویت‌بندی شده از تمام کارهایی است که تصمیم گرفته‌اید انجام دهید یا ممکن است انجام دهید. تیم شما یک جلسه برنامه‌ریزی اسپرینت برگزار می‌کند. در این جلسه، مهم‌ترین ویژگی یا چند ویژگی از بالای بک‌لاگ محصول را انتخاب کرده و آن را به بک‌لاگ اسپرینت منتقل می‌کنید. سپس در مورد تمام کارهایی که برای پیاده‌سازی آن ویژگی نیاز دارید، صحبت می‌کنید. تیم شما با هم، کارهایی که برای تبدیل آن ویژگی به واقعیت لازم است را یادداشت می‌کنند. این کارها در قالب تسک (Ticket) وارد نرم‌افزار مدیریت پروژه می‌شوند.

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

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

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


کانال آموزش دوره جامع مدیریت محصول 

@ProductManagementCourses
ادامه قسمت 15 :

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

خب حالا بیایید چهارچوب اسکرام و چهار جزء اصلی آن را مرور کنیم. اول جلسه برنامه‌ریزی اسپرینت است که در آن موارد منتخب از بک‌لاگ محصول را به بک‌لاگ اسپرینت منتقل می‌کنیم. دوم خود اسپرینت است که یک بازه زمانی محدود، معمولا دو هفته‌ای است، البته می‌تواند سه یا چهار هفته هم باشد، اما دو هفته رایج‌ترین حالت است. سوم جلسات استندآپ روزانه‌ای است که در طول اسپرینت برگزار می‌شود. این جلسات ۱۰ تا ۱۵ دقیقه‌ای هستند و برای اینکه افراد زیاد صحبت نکنند، به صورت ایستاده برگزار می‌شوند. در این جلسات در مورد کارهای دیروز، امروز و فردا صحبت می‌کنیم و هرگونه مشکلی که وجود دارد یا نیاز به همکاری است را روشن می‌کنیم. در نهایت جلسه گذشته‌نگر را داریم که در آن در مورد اینکه در طول اسپرینت چه چیزهایی خوب پیش رفت، چه چیزهایی خوب پیش نرفت و any outstanding questions که افراد دارند صحبت می‌کنیم.

خب، دوستان، در جلسه بعدی می‌بینیم.


کانال آموزش دوره جامع مدیریت محصول 

@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
کانال آموزش جامع دوره مدیریت محصول 

@ProductManagementCourses
سلام به همه همراهان عزیز
امیدوارم حالتون خوب باشه 🌹

متاسفانه برخی زیرنویس های موجود ناقص هست و من مجبور هستم زیرنویس ها رو شخصا تولید کنم و یک مقدار این مشکل روند ترجمه ها رو طولانی تر می‌کند.

ارادتمندم 🌹🙏
Media is too big
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 16
عنوان: کانبان چیست؟ و چگونه کار می کند؟
زبان: انگلیسی
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 16
عنوان: کانبان چیست؟ و چگونه کار می کند؟

خب، کانبان چیست و چه تفاوتی با اسکرام دارد؟ راستی، تلفظش کانبان هست یا کانبان؟ تقریبا مطمئنم کانبان درسته، ولی اگه اشتباه می کنم توئیت کنید بهم بگین.

مثل اسکرام، کانبان هم یک چارچوب برای پیاده سازی توسعه نرم افزار Agile است، با این تفاوت که به اندازه اسکرام در مورد جلسات و زمان بندی سخت گیرانه نیست.

احتمالا قبلا چیزی شبیه به برد کانبان دیده اید. این برد فقط شامل چند ستون با کارت هایی روی آن است که می توانید با توجه به وضعیت آن آیتم، از یک ستون به ستون دیگر جابجا کنید. مثلا ستون هایی برای "باید انجام شود"، "در حال انجام" و سپس "انجام شده".

با این حال، فقط به خاطر اینکه چیزی یک برد به سبک کانبان دارد، به این معنی نیست که این همان فرایند کانبان است.

کلیدهای اصلی کانبان این هستند که از اسپرینت استفاده نمی کند، بنابراین کار تیمتان را در دوره های دو یا چهار هفته ای محدود نمی کنید. همچنین، از آنجایی که اسپرینتی وجود ندارد، پس Backlog اسپرینت هم نداریم (بعدا در موردش صحبت می کنیم)، و فقط خود Backlog محصول وجود دارد.

بنابراین، تیم فقط روی کارهایش (تیکت ها) کار می کند، آنها را انجام می دهد، به ستون "انجام شده" منتقل می کند و سپس کار بعدی را از بالای Backlog محصول برمی دارد. این Backlog برای همیشه ادامه دارد، بی انتهاست.

همچنین، کانبان با اسکرام در این مورد هم متفاوت است که هیچ نوع جلسه خاصی را تجویز نمی کند، برخلاف اسکرام که جلسات ایستاده (استندآپ)، جلسات برنامه ریزی اسپرینت و جلسات بازنگری دارد.

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

برخی از تیم های نرم افزار از کانبان استفاده می کنند، اما به نظر می رسد برای تیم هایی که خیلی نگران مسائلی مانند تخمین زدن نیستند و به طور مداوم وظایف را با سرعت نسبتاً بالایی از همان مراحل عبور می دهند تا زمانی که کامل شوند، بهتر کار می کند. به عنوان مثال، تیم های خدمات مشتری اغلب از سبک کاری کانبان استفاده می کنند، درست است؟

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

همانطور که می بینید، کانبان یک روش راحت تر برای انجام توسعه نرم افزار Agile است، اما یک عیب بزرگ دارد. از آنجایی که از اسپرینت استفاده نمی کند، پیش بینی مدت زمان لازم برای تکمیل کار دشوارتر خواهد بود. نگران این موضوع فعلا نباشید، زیرا در جلسات بعدی در مورد مسائلی مانند تخمین و سرعت صحبت خواهیم کرد.

خب، بیایید مرور کنیم. کانبان فقط یک راه دیگر برای پیاده سازی یک گردش کار توسعه نرم افزار از نوع Agile است. کمی کمتر دستوری از اسکرام است و از اسپرینت استفاده نمی کند.

خیلی خوب، همه، در جلسه بعدی می بینمتان.

اصطلاحات:

* Kanban (کانبان):
یک چارچوب چابک برای مدیریت پروژه است که از یک برد کانبان برای تجسم جریان کار استفاده می کند.

کانال آموزش دوره جامع مدیریت محصول 

@ProductManagementCourses
This media is not supported in your browser
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 17
عنوان: توسعه آبشاری(waterfall) چیست؟
زبان: انگلیسی
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 17
عنوان: توسعه آبشاری(waterfall) چیست؟

در مثال برنامه‌ی Agile، ما آن ۱۰ قابلیتی را که فکر می‌کردیم به آن‌ها نیاز داریم، در نظر گرفتیم. اما به جای توسعه‌ی همه‌ی آن‌ها، تنها چند مورد از مهم‌ترین‌ها را انتخاب کردیم. سپس روی آن قابلیت‌های انتخاب‌شده تحقیق و بررسی (Research) انجام دادیم، آن‌ها را طراحی (Design) و توسعه (Develop) دادیم، و بعد از انتشار (Release)، بازخورد (Feedback) گرفتیم تا ببینیم آیا این‌ها همان چیزهایی بودند که کاربران به آن‌ها علاقه‌مند بودند یا خیر.

این رویکرد چابک (Agile) با رویکرد آبشاری (Waterfall) کاملا متفاوت است. در Waterfall، ما هر ۱۰ قابلیتی را که فکر می‌کنیم به آن‌ها نیاز داریم، به طور همزمان توسعه می‌دهیم. بنابراین، ما همزمان روی تحقیق، طراحی، توسعه و انتشار تک‌ تکِ آن‌ها کار می‌کنیم.

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

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


اصطلاحات:

* Waterfall (آبشاری):
روشی خطی برای مدیریت پروژه است که مراحل آن به ترتیب انجام می‌شوند و بازگشت به مراحل قبلی وجود ندارد.

کانال آموزش دوره جامع مدیریت محصول 

@ProductManagementCourses
Media is too big
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 18
عنوان: مثال های اجایل و واترفال در دنیای واقعی.
زبان: انگلیسی
018-Real world examples of Waterfall and Agile.srt
8.3 KB
زیرنویس انگلیسی قسمت 18 دوره جامع مدیریت محصول
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 18
عنوان: مثال های اجایل و واترفال در دنیای واقعی.

قسمت اول:
در جلسه قبل یاد گرفتیم که توسعه نرم‌افزاری Agile یک روش برای به کارگیری طرز فکر چابک در توسعه نرم‌افزار درون یک شرکت است. حالا، وقتی این روش را درون محیط توسعه به کار می‌گیریم، واقعا به چه شکلی درمی‌آید؟ کار روزمره با این روش چطور است؟

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

با صحبت با طراحان و مهندسان، می توانیم با اطمینان نسبی بگوییم که ابتدایی ترین نیاز برای ساختن قابلیت لیست پخش، اضافه کردن مجموعه ای از آهنگ ها به لیستی به نام "پلی لیست" است. با این دانش، مهندسان می توانند پیش بروند و شروع به توسعه پایگاه داده ای کنند که می دانیم برای ساختن قابلیت لیست پخش به آن نیاز داریم.

در همین حال، طراح و ما، مدیران محصول، می توانیم دور هم جمع شویم و در مورد نحوه عملکرد لیست های پخش، ظاهر آنها و حس و حال آنها درون برنامه صحبت کنیم. ما، مدیران محصول و طراحان، می توانیم چند طرح اولیه (wireframe) بالقوه ایجاد کنیم. طراحان می توانند آنها را بسیار زیبا کنند. می توانیم آنها را با کاربران تست کنیم و بر اساس بازخورد کاربران تغییراتی ایجاد کنیم. می توانیم این فرآیند را چند بار تکرار کنیم، در حالی که مهندسان روی پایگاه داده کار می کنند.

کانال آموزش دوره جامع مدیریت محصول 

@ProductManagementCourses
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 18
عنوان: مثال های اجایل و واترفال در دنیای واقعی.

قسمت دوم:
تا زمانی که طراحی و ظاهر عالی و برای ارائه آماده شود، مهندسان می توانند آن را درون برنامه قرار دهند، زیرا آنها کار با پایگاه داده را به پایان رسانده اند. حالا که مهندسان با بخش پشتیبان (backend) و پایگاه داده کار خود را تمام کرده اند، شروع به پیاده سازی عملکرد واقعی لیست پخش در برنامه می کنند.

سپس، مدیر محصول و طراح می توانند به سراغ کاربران بروند و در مورد ویژگی های بعدی که باید ساخته شوند صحبت کنند و سپس کل فرآیند را دوباره شروع کنند. بنابراین، در حالی که مهندسان در حال پیاده سازی این ویژگی در برنامه هستند، ما، مدیر محصول و طراحان، می توانیم با کاربران دیگر صحبت کنیم و به معیارها (metrics) نگاه کنیم تا تصمیم بگیریم که ویژگی بعدی چه باشد. سپس دوباره سراغ ساخت طرح های اولیه و طراحی می رویم و بازخورد بیشتری از کاربران دریافت می کنیم و دوباره کل چرخه را تکرار می کنیم.
وقتی شرکت ها از روش توسعه Agile استفاده می کنند، معمولا همه افراد در ارتباط و همکاری بسیار نزدیکی قرار دارند. مهندسان، طراحان و مدیران محصول معمولا در یک اتاق یا دفتر هستند و همیشه با هم صحبت می کنند. اما در مورد Waterfall چطور؟ چه زمانی این روش مفید است؟ و نمونه هایی از کاربردهای مفید آن چیست؟

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

نمونه دیگری از کاربرد Waterfall که نسبت به Agile کمی مفیدتر است، در نرم افزارهای کاربردی حیاتی مانند سیستم های ترمز یا کنترل موتور در خودروها است. فکر می کنید که استفاده از توسعه Agile و توسعه تنها چند ویژگی در یک زمان برای سیستم ترمز خودرو ایده خوبی است؟ قطعا نه!

حالا به خارج از نرم افزار چطور؟ Waterfall در جاهای دیگری هم کاربرد مفیدی دارد. تصور کنید در حال ساخت یک آسمان خراش هستیم. فکر می کنید بخواهیم پنج طبقه را به طور همزمان بسازیم و سپس تعدادی از افراد را در آن قرار دهیم و ببینیم که آیا همچنان پابرجا است؟ احتمالا نه. ما قصد داریم همه ۱۰۰ طبقه را با هم بسازیم و این کار را بر اساس مشخصاتی که از ابتدا می دانیم همه چیز مورد نیاز را دارد انجام می دهیم.

وقتی از فرآیند توسعه نرم افزار Waterfall استفاده می شود، تیم به اندازه تیمی که از فرآیند توسعه نرم افزار Agile استفاده می کند، همکاری نزدیکی ندارد. تیم تحقیقات و نیازمندی های محصول می تواند در یک شهر، طراحان در شهر و منطقه زمانی دیگر و توسعه دهندگان در یک شهر و منطقه زمانی کاملا متفاوت باشند. دلیل این امر این است که همه چیز از قبل تعریف شده و از یک تیم به تیم دیگر منتقل می شود و هیچ چیز تغییر نمی کند.

بنابراین، امیدوارم همه درک مناسبی از تفاوت های Agile و Waterfall و نمونه های واقعی از کاربردهای آنها داشته باشند. در جایگاه شما به عنوان یک مدیر محصول، بیشتر روی Agile تمرکز خواهید کرد، اما فکر نکنید که Waterfall کاملاً بی فایده است، زیرا اینطور نیست.

اصطلاحات:
Lean mindset (ذهنیت ناب یا طرز فکر چابک):
رویکردی برای به حداقل رساندن اتلاف و به حداکثر رساندن ارزش در یک فرآیند است.

* User feedback (بازخورد کاربر):
اطلاعاتی است که کاربران در مورد تجربه خود با یک محصول یا سرویس ارائه می دهند.
* Wireframe (طرح اولیه):
یک چارچوب بصری ساده از یک صفحه نمایش یا ویژگی است که بر روی چیدمان و عملکرد تمرکز دارد.
* Backend (بخش پشتیبان):
بخشی از یک برنامه که با کاربر نهایی تعامل ندارد و وظایف اصلی را انجام می دهد.
* Metrics (معیارها):
داده های قابل اندازه گیری که برای ارزیابی عملکرد یک محصول یا سرویس استفاده می شود.
* Mission-critical software applications (نرم افزارهای کاربردی حیاتی):
نرم افزارهایی که عملکرد صحیح آنها برای ایمنی و یا موفقیت یک سازمان یا سیستم ضروری است.
* Spec (مشخصات):
یک سند دقیق که تمام الزامات و ویژگی های مورد نیاز برای یک محصول یا پروژه را شرح می دهد.

کانال آموزش دوره جامع مدیریت محصول 

@ProductManagementCourses
Media is too big
VIEW IN TELEGRAM
دوره جامع مدیریت محصول ( از سری آموزشهای لینکدین)
قسمت : 19
عنوان: مقدمه ای بر ایده و نیاز های کاربران
زبان: انگلیسی
019-Introduction to ideas and user needs.srt
3.6 KB
زیرنویس انگلیسی قسمت 19 دوره جامع مدیریت محصول
2025/07/05 14:40:45
Back to Top
HTML Embed Code: