1. مقدمه:
در قسمت قبل در مورد این صحبت کردیم که بخش مهمی از مدرن‌سازی معماری، ایجاد چشم‌اندازی از معماریِ مدرن شده است که این کار به شما امکان می‌دهد چالش‌ها و فرصت‌های هر بخش را شناسایی کرده و سفر خود را از وضعیت جاری به چشمانداز آینده برنامه‌ریزی کنید. در ادامه‌ی این فصل به بحث‌های تکمیلی در مورد محصول و طبقه‌بندی آن میپردازیم.
2. طراحی طبقه‌بندی محصول:
پس از تعیین بلوک‌های سازنده‌ی طبقه‌بندی محصول، می‌توانید از آن‌ها برای طراحی معماری بعنوان یک طبقه‌بندی محصول استفاده کنید. بسیاری از جنبه‌های طراحی طبقه‌بندی در بخش‌های باقی‌مانده پوشش داده خواهند شد. سفر هر سازمان منحصر به فرد خواهد بود. با این حال، این بخش چند اصل کلی را برجسته میکند که قبل از شروع، ارزش به خاطر سپردن دارند.
2.1. با بخش‌های ساده‌تر شروع کنید:
شروع کردن گاهی اوقات سخت‌ترین بخش است، بنابراین توصیه می‌کنم با بخش‌های ساده‌تر شروع کنید — چیزهایی که کمتر ذهنی و کمتر بحث‌برانگیز هستند. به عنوان مثال، فرض کنید شرکتی در حوزه‌ی محصولات و خدمات فردی و اختصاصی فعالیت میکند و پیشنهادات اختصاصی به مشتریان ارائه میکند. بررسی وب‌سایت شرکت و موارد مرتبط با بازاریابی می‌تواند منبع خوبی برای بینش و شروع کار باشد.
روش دیگر، نگاه کردن به چارت سازمانی است. ساختارهای گزارش‌دهی می‌توانند نشان دهند که کدام بخش‌های کسب‌وکار مستقل از یکدیگر در نظر گرفته شده‌اند. با این حال، احتیاط شرط عقل است، زیرا گاهی اوقات ساختار سازمانی موجود نیاز به تغییرات عمده‌ای برای امکان‌پذیر کردن مدرنیزه‌سازی دارد. اما ممکن است هنوز بتوانید از بخش‌هایی از چارت سازمانی فعلی به‌عنوان نقطه شروع برای چالش و تکامل استفاده کنید.
پس از تعیین محصولات به طور خاص، باید زوم کنید و بررسی کنید که چگونه هر محصول خاص می‌تواند به جریان‌های ارزش تجزیه شود و شناسایی کنید که کدام قابلیت‌های مشترک مورد استفاده توسط چندین محصول می‌توانند به پلتفرم‌ها استخراج شوند. این تصمیم‌ها معمولاً بسیار ذهنی‌تر خواهند بود و نیاز به تحلیل عمیق‌تر با استفاده از تکنیک‌های مناسب دارند.
2.2. از تکنیک‌های مناسب استفاده کنید:
یکی از اولین سوالاتی که اغلب هنگام طراحی طبقه‌بندی محصول پرسیده می‌شود این است که چگونه این کار را انجام دهیم؟ پاسخ ساده این است که می‌توانید از هر تکنیکی که با آن راحت هستید یا احساس می‌کنید مرتبط است، استفاده کنید. تکنیک‌هایی مانند EventStorming و Wardley Mapping، آزموده و آزمایش شده‌اند. با این حال، اگر احساس می‌کنید که تکنیک‌های دیگری نیاز است یا با آن‌ها راحت‌تر هستید، کاملاً قابل قبول بوده و می‌توانید از آن‌ها استفاده کنید.
توصیه‌ای که همیشه دارم، بدون توجه به تکنیک‌های استفاده شده، این است که از تصمیم‌گیری‌های حیاتی طبقه‌بندی بر اساس درک سطحی و کلی اجتناب کنید. این آسان است که خود را فریب دهید و فکر کنید با ماندن در سطح بالا، انتخاب‌های خوبی انجام داده‌اید. برخی تکنیک‌ها به طور خاص طراحی شده‌اند تا به شما اجازه دهند تصویر کلان و سطح بالا را ببینید، اما فاقد سطح جزئیات لازم برای تصمیم‌گیری‌های معماری دقیق‌تر هستند. بنابراین، باید با استفاده از تکنیک‌هایی که پیچیدگی بیشتری را نشان می‌دهند، به هر بخش زوم کنید. به عنوان مثال، اگر از تکنیکی استفاده می‌کنید که بخش بزرگی از کسب‌وکار شما را تنها در ده یادداشت و نهایتا چند برچسب ترسیم میکند، احتمالاً اطلاعات کلیدی زیادی برای تصمیم‌گیری‌های معماری دقیق‌تر از دست رفته است.
2.3. انتظار تکامل مداوم را داشته باشید:
دیدها و مناظر به دلیل رقابت عرضه و تقاضا به طور مداوم در حال تغییر هستند، همان‌طور که Wardley Mapping به ما می‌آموزد. و این آسان است که وقتی کمترین اطلاعات را دارید، تصمیم اشتباه بگیرید: شاید یک بخش پیچیده‌تر از آنچه در ابتدا تصور می‌شد باشد و نیاز به تقسیم داشته باشد، یا شاید وابستگی‌های غیرمنتظره‌ای به وجود آمده باشد که نیاز به هماهنگی بیش از حد دارد و نیاز به بازنگری در معماری را ایجاد میکند. بنابراین، هیچ حالت پایانی‌ای وجود ندارد. طبقه‌بندی محصول نیاز به تکامل دارد، و این تفکر باید از روز اول در رویکرد شما گنجانده شود.
اگر تا به حال در موقعیتی بوده‌اید که مجبور بوده‌اید یک تصمیم را از ابتدا درست بگیرید زیرا بعداً فرصتی برای تغییر آن وجود نخواهد داشت، این یک زنگ خطر است. فشار از کجا می‌آید که چنین تصمیم‌های پرریسکی بگیرید؟ چه چیزهایی مانع اصلاح مسیر در آینده هستند؟ این موارد ممکن است نشان‌دهنده نگرانی‌های فرهنگی عمیق‌تری باشد که باید مورد توجه قرار گیرد. البته، برخی تصمیم‌ها پیچیده‌تر از دیگران هستند، بنابراین منطقی است که زمان بیشتری را برای برنامه‌ریزی از ابتدا صرف کنید، جایی که تصمیم‌ها بعداً گران‌تر برای تغییر خواهند بود.
ایده خوبی است که به‌طور منظم، مثلاً هر سه ماه یکبار، یک طبقه‌بندی به‌روزرسانی شده منتشر کنید. این نشان می‌دهد که تغییر امری عادی است. تیم‌ها خودشان به‌طور مکرر نیاز به تغییرات را کشف خواهند کرد، زیرا نزدیک‌ترین افراد به بسیاری از محرک‌های تکامل هستند، مانند همکاری بیش از حد با تیم‌های دیگر یا اولویت‌های نامشخص. بنابراین، باید تشویق شوند که نگرانی‌های خود را زمانی که احساس می‌کنند تکامل لازم است، مطرح کنند و با این تصور غلط که طراحی ثابت است، زندگی نکنند.
2.4. مسئولیت طراحی را توزیع کنید:
یکی از دلایل کلیدی برای تعریف یک طبقه‌بندی، تعیین این است که چه کسی مسئول تصمیم‌گیری در هر بخش از پورتفولیو است، هم در طول مدرنیزه‌سازی و هم پس از آن. مسئولیت‌ها چه هستند و چگونه آن‌ها را اختصاص خواهید داد؟
هنگام طراحی طبقه‌بندی، ضروری است که از ضد الگوی یک تیم معماری متمرکز که سیستم را طراحی کرده و طرح‌ها را به تیم‌ها تحویل می‌دهد، اجتناب کنید. در یک سازمان محصول‌محور، مسئولیت بیشتر غیرمتمرکز است، و جریان تغییرات آنقدر زیاد است که یک تیم متمرکز نمی‌تواند همه چیز را نظارت کند. در نتیجه، فرآیند طراحی یک طبقه‌بندی بیشتر غیرمتمرکز است. ایده خوبی است که یک AMET (تیم معماری سازمانی) حداقل در ابتدای سفر، فرآیند را تسهیل و نظارت کند.
تصمیم‌گیری در مورد اینکه کجا اجازه خودمختاری و استانداردسازی داده شود، همیشه یک تعادل ظریف است. خودمختاری بیشتر می‌تواند منجر به مشکلاتی مانند گسترش فناوری شود، جایی که هر تیم از فناوری‌های مختلف استفاده میکند، و همکاری را سخت‌تر میکند زیرا مهندسان نمی‌توانند کار در تیم‌های دیگر را درک کنند یا به آن کمک کنند یا بین تیم‌ها جابجا شوند. از طرف دیگر، استانداردسازی بیش از حد می‌تواند محدودکننده باشد، اصطکاک به گردش کار تیم اضافه کند و جریان آن‌ها را مختل کند.
در مثال Salesforce که قبلاً بررسی شده ، ابر بازاریابی یک پورتفولیوی محصول بسیار خودمختار بود. در داخل ابر بازاریابی، گروه‌های محصول سطح بالایی از خودمختاری برای طراحی و تکامل بخش خود از طبقه‌بندی داشتند. هر سطح از طبقه‌بندی رهبران محصول و فناوری اختصاصی داشت که به‌عنوان یک واحد کار می‌کردند تا از تشکیل سیلوها جلوگیری کنند.
3. نقشه‌برداری از فرصت‌ها، ریسک‌ها و چالش‌های مدرنیزه‌سازی:
طراحی یک طبقه‌بندی محصول درباره‌ی ایجاد یک چشمانداز برای هدایت سفر شما است. بخش دشوار، انجام ابتکارات تغییر سازمانی و فناوری برای حرکت از ساختار فعلی به ساختار مطلوب است. این کار به آسانی انجام یک بازسازی بزرگ یک‌شبه نیست. کار مدرن‌سازی احتمالاً نیاز به اولویت‌بندی و انجام تدریجی در طول چندین سال دارد.
بنابراین، برنامه‌ریزی و اولویت‌بندی یک فعالیت حیاتی و چالش‌برانگیز است. هرچه بهتر ارزش، هزینه‌ها و ریسک‌های مدرن‌سازی هر بخش را درک کنید، بهتر می‌توانید گزینه‌های مدرن‌سازی با بالاترین ارزش را اولویت‌بندی کنید. این بخش به برخی از موضوعات رایج که هنگام ترسیم طبقه‌بندی باید ثبت شوند، اشاره میکند. آن‌ها به شناسایی سطح تلاش مورد نیاز برای انتقال از ساختار فعلی به ساختار جدید در هر بخش از طبقه‌بندی کمک می‌کنند و شروع آماده‌سازی را تسهیل می‌کنند.
3.1. وابستگی‌ها و مرزهای ناهماهنگ:
انتظار داشته باشید که برخی بخش‌های چشمانداز طبقه‌بندی شما با مرزهای نرم‌افزار و تیم فعلی شما هماهنگ نباشند. در حالی که افراد می‌توانند به راحتی در تیم‌های مختلف سازماندهی شوند (اگرچه تشکیل یک تیم با عملکرد بالا ساده نیست)، تغییر شکل نرم‌افزار بسیار پیچیده‌تر است، به‌ویژه در سیستم‌های قدیمی با اتصال محکم که تغییر آن‌ها بسیار پرریسک است.
شکل زیر یک سناریوی رایج را نشان می‌دهد که در آن یک سازمان زیردامنه‌های هدفی را شناسایی کرده است که می‌خواهد جریان‌های ارزش مستقل برای آن‌ها ایجاد کند که هر کدام متعلق به تیمی متفاوت است. با این حال، معماری نرم‌افزار فعلی به این معنی است که هر سه تیم در هر سه پایگاه کد کار می‌کنند و نیاز به هماهنگی کار و استقرار خود دارند، که بر جریان آن‌ها تأثیر می‌گذارد.
هنگامی که مرزهای ناهماهنگ به اندازه شکل بالا شناسایی می‌شوند، اولین چیزی که باید تشخیص دهید این است که احتمالاً سطح بالایی از عدم قطعیت و ریسک وجود دارد. بسته به میزان اتصال و بدهی فنی، این احتمالاً یک مدرن‌سازی ساده سه ماهه نیست و بعید است که یک برش اولیه خوب باشد، مگر اینکه، به عنوان مثال، یکی از زیردامنه‌ها به راحتی قابل استخراج باشد یا بتواند به راحتی بازنویسی شود بدون اینکه نیاز به تغییرات در سیستم قدیمی داشته باشد.
برنامه‌ریزی کارهای دیگر در اطراف یک ابتکار مدرن‌سازی مانند این می‌تواند پرریسک باشد. بسیاری از تأخیرهای غیرمنتظره ممکن است به وجود آیند، مانند کد قدیمی که زمان بسیار بیشتری برای جدا کردن از آنچه پیش‌بینی شده است می‌گیرد، پیچیدگی زیرساخت پنهان، و عدم دانش درباره بخش‌های خاصی از سیستم زیرا هیچ کس در حال حاضر در شرکت آن‌ها را درک نمی‌کند.
در یک سازمان خدمات مالی، اولین برش مدرن‌سازی به دلیل کشف مشکلات ناشناخته‌ی انطباق، دقیقاً زمانی که تیم آماده استقرار بود، ماه‌ها به تأخیر افتاد. مهم‌ترین نکته این است که یک ایده کلی از سطح ناهماهنگی در هر بخش از طبقه‌بندی و لیستی از چالش‌های کلیدی درگیر در حرکت به سمت طراحی پیشنهادی به دست آورید.
3.2. مالکیت نامشخص یا فقدان مالکیت :
قبل از مدرن‌سازی یک بخش از طبقه‌بندی، باید یک برنامه کارکنان برای تیم‌هایی که مسئول جریان‌های ارزش مرتبط خواهند بود، در نظر گرفته شود. ممکن است تیم‌های موجود جابجا شوند، یا ممکن است این بخش در حال حاضر متعلق به هیچ تیمی نباشد، و مشخص نباشد که کدام تیم مالک آن خواهد بود. در این سناریو، باید برنامه‌ای برای تشکیل تیم ایجاد شود، که ممکن است شامل آوردن کارمندان موجود، استخدام کارمندان جدید، استفاده از پیمانکاران، یا ترکیبی از این سه باشد.
به خاطر داشته باشید که تشکیل تیم‌های جدید زمان‌بر است. اگر چهار تا هشت هفته طول بکشد تا تیم استخدام شود، و هر کدام باید یک دوره اخطار چهار هفته‌ای با کارفرمای فعلی خود کار کنند، به راحتی می‌تواند سه ماه (یا حتی بیشتر) طول بکشد تا تیمی برای شروع کار روی یک ابتکار مدرن‌سازی مشخص تشکیل شود. برجسته کردن این چالش قبل از تصمیم‌گیری‌های مهم اولویت‌بندی ضروری است.
من در موقعیت‌هایی بوده‌ام که رهبری ارشد چراغ سبز به یک پروژه خاص داده و انتظار داشته کار بلافاصله شروع شود، در حالی که هیچ تیمی هنوز تشکیل نشده است. سپس عجله برای استخدام سریع افراد وجود دارد، که همه را تحت فشار قرار می‌دهد و زمان کافی برای استخدام افراد مناسب یا پرورش فرهنگ لازم برای مدرن‌سازی را نمی‌دهد.
3.3. شکاف مهارتی :
حتی زمانی که تیمی برای مسئولیت یک بخش خاص در نظر گرفته شده است، ممکن است تیم فاقد مهارت‌های لازم برای انجام مدرن‌سازی مورد نظر باشد. ممکن است نیاز به آموزش و ارتقای مهارت‌ها باشد، و ممکن است نیاز به استخدام تخصص اضافی یا کمک خارجی باشد. هرچه شکاف بین نحوه کار فعلی تیم و نحوه‌ای که انتظار می‌رود کار کنند بیشتر باشد، زمان بیشتری باید در نقشه راه برای اجازه دادن به آن‌ها برای ارتقای مهارت‌ها در نظر گرفته شود.
3.4. مدرن‌سازی محصول و دامنه:
مدرن‌سازی معماری فقط درباره بازنویسی سیستم قدیمی با فناوری‌های جدید یا حتی حرکت به سمت الگوها و ساختارهای جدید نیست؛ به همان اندازه درباره مدرن‌سازی محصول و دامنه برای ایجاد ارزش جدید از طریق بهبودهایی مانند:
این فعالیت‌ها ممکن است شامل مقدار زیادی مکاشفات باشد — به عنوان مثال، جلسات تحقیقات کاربری، کارگاه‌های کشف، و نمونه‌سازی‌های زیاد. شناسایی بخش‌هایی از طبقه‌بندی که بیشترین بهره را از مدرنیزه‌سازی محصول و دامنه می‌برند، مفید است تا اطمینان حاصل شود که زمان کافی برای آماده‌سازی و انجام کشف مؤثر وجود دارد، به‌ویژه اگر پتانسیل بازدهی سرمایه (ROI) بالا وجود داشته باشد. اگر کشف محصول مشارکتی یک مفهوم جدید برای سازمان شما باشد، برجسته کردن این فرصت‌ها حتی مهم‌تر است زیرا به زمان بیشتری برای تطبیق با این رویکرد نیاز خواهید داشت.
3.5. پیچیدگی و بار شناختی:
همه بخش‌های یک سیستم به یک اندازه پیچیده نخواهند بود. برخی بخش‌ها شامل قوانین و گردش کار پیچیده‌تر کسب‌وکار یا چالش‌های مقیاس‌پذیری بالاتر هستند، یا ممکن است با فناوری‌های بسیار قدیمی نوشته شده باشند که نیاز به سرمایه‌گذاری بیشتری برای مدرن‌سازی دارند. تعیین این موضوع مهم است زیرا جایی که ریسک‌ها و چالش‌ها ممکن است به وجود آیند را برجسته میکند. همچنین مهم است زیرا کمک میکند اطمینان حاصل شود که یک تیم واحد مسئول چندین دامنه بسیار پیچیده نخواهد بود، که بار شناختی آن‌ها را بیش از حد افزایش می‌دهد.
3.6. محدودیت‌ها و چالش‌های سطح کلان:
سطح کلان به ساختار بزرگ‌مقیاس یک سازمان، سطح ۳ و بالاتر، اشاره دارد. تغییرات در این سطوح به طور بالقوه هزاران نفر را تحت تأثیر قرار می‌دهد، که آن‌ها را هم پر هزینه و هم پرریسک میکند. تصمیم‌گیری در این سطح معمولاً توسط رهبری ارشد برای دلایل استراتژیک عمده گرفته می‌شود، مانند زمانی که در سال ۲۰۱۵ گوگل به مجموعه‌ای از شرکت‌های جداگانه تحت مالکیت یک شرکت هلدینگ جدید به نام Alphabet تقسیم شد.
در حالی که تصمیم‌گیری در سطوح بالاتر ممکن است خارج از محدوده مدرن‌سازی باشد، هنوز ارزش دارد که تصویر بزرگ‌تر و چگونگی محدود کردن مدرن‌سازی را درک کنید. حتی ممکن است فرصت‌هایی را کشف کنید که هیچ‌کس متوجه آن‌ها نشده بود.
یکی از موضوعات سطح کلان که باید به آن توجه داشت، استفاده مجدد است. هنگامی که یک شرکت بزرگ دارای بسیاری از محصولات است و در بسیاری از بازارها فعال است، همیشه بحثی درباره اینکه چه چیزی را متمرکز کنند و چه چیزی را به هر بخش اجازه دهند تا خودشان بسازند، به وجود می‌آید. تصور کنید یک زنجیره فست‌فود جهانی که حول بازارهای منطقه‌ای سازماندهی شده است — به عنوان مثال، ایالات متحده، بریتانیا، سوئد و ژاپن — و این شرکت در بیش از ۱۰۰ کشور فعال است. شکل زیر یک تصمیم کلیدی معماری کسب‌وکار سطح کلان را برجسته میکند: آیا هربرش عمودی باید آزاد باشد تا قابلیت‌های خود مانند وفاداری و CRM را توسعه دهد، یا باید آن‌ها در یک برش افقی متمرکز شوند که توسط همه برش‌های عمودی به اشتراک گذاشته می‌شود؟
تعیین چگونگی شکل‌دهی به برش‌های عمودی و افقی یک مشکل همه‌جایی و پیچیده با بسیاری از ریسک‌ها است. این یک موضوع بحث‌برانگیز در برخی شرکت‌ها است. برخی از ملاحظات کلیدی عبارتند از:
علاوه بر موارد فوق، Wardley Mapping همیشه یک ایده خوب برای به‌دست آوردن تصویری از کل منظره و پیش‌بینی فرصت‌های آینده است، به جای اینکه بیش از حد روی دردهای فعلی متمرکز شوید.
مثال واقعی Stripe Treasury:
امکان‌های مختلفی بین دو حالت افراطی تکرار کامل در هر بخش عمودی و استفاده مجدد کامل به‌عنوان یک بخش افقی سازمانی وجود دارد. در کنفرانس Craft 2022 در بوداپست، Prajakta Kalekar بینشی درباره چگونگی ساخت محصولات در Stripe ارائه داد.
او صحبت خود را با چارچوب‌بندی سفر Stripe از یک شرکت پرداخت به یک شرکت زیرساخت اقتصادی شروع کرد. سپس درباره داستان یک برش عمودی جدید که Stripe ساخته است به نام Stripe Treasury، یک پلتفرم بانک‌داری به‌عنوان سرویس، صحبت کرد.
این صحبت شامل بینش‌های جالبی بود، از جمله رویکرد Stripe به پلتفرم‌ها و استفاده مجدد. در ابتدای چرخه عمربرش عمودی، تیم‌ها برخی از زیرساخت‌های اصلی پرداخت Stripe را تکرار کردند تا به‌دست آوردن "کارایی کوتاه‌مدت" را بهینه کنند. در واقع، این کار درباره‌ی فعال‌سازی برش عمودی جدید برای اعتبارسنجی ایده‌ها در سریع‌ترین زمان ممکن و کاهش زمان ورود به بازار به هزینه تکرار بود.
بعداً در چرخه عمر برش عمودی، Stripe تصمیم گرفت که برش عمودی Treasury را به زیرساخت اصلی پرداخت Stripe منتقل کند. آن‌ها می‌خواستند "از بازسازی Stripe در داخل Stripe اجتناب کنند" و در عوض به "کارایی بلندمدت" برسند.
4. محصول چیست؟
کلمه محصول به طور گسترده در این نوشته استفاده شده است، اما یک کلمه بسیار مبهم با تعاریف متضاد در سراسر صنعت است. در بخش پایانی این فصل یک تعریف توصیه‌شده از کلمه محصول و مفاهیم مرتبط را ارائه می‌دهم. در مورد این کلمه اجماعی وجود نخواهد داشت، در نتیجه این پیشنهاد به‌عنوان تنها تعریف صحیح ارائه نشده است. با این حال، اگر در تعریف این مفهوم در سازمان خود مشکل دارید، این یک تعریف خوب برای استفاده است. اگر قبلاً تعریف واضحی در سازمان خود دارید، می‌توانید از این بخش صرف نظر کنید.
4.1. محصولات در مقابل ویژگی‌ها در مقابل اجزاء:
خانم Melissa Perri یکی از افراد پیشرو در دنیای مدیریت محصول است. او یک مشاور، نویسنده و مدرس ارشد در مدرسه کسب‌وکار هاروارد است. او در سخنرانی افتتاحیه خود در کنفرانس Agile 2022 در نشویل درباره تعریف خود از محصول صحبت کرد.
تعریف ملیسا حول محور محصولات به‌عنوان یک پیشنهاد کامل است: "یک راه‌حل قابل تکرار که می‌تواند به بازار عرضه شود و یک خواسته یا نیاز (کاری که باید انجام شود) را حل کند." او سپس کارت‌های اعتباری را به عنوان مثال ارائه داد. کارت فیزیکی به خودی خود یک محصول نیست؛ فقط بخشی از آن است. به تنهایی، یک خواسته یا نیاز را حل نمی‌کند.
آقای Roman Pichler نظر مشابهی دارد و به وضوح بین محصولات، ویژگی‌ها و اجزاء تمایز قائل می‌شود. در تجربه‌ی من، بسیاری از مردم از کلمه محصول برای اشاره به چیزی که رومن آن را ویژگی یا جزء می‌نامد، استفاده می‌کنند. رومن از مثال جستجو و تسویه‌حساب استفاده میکند که توسط شرکت‌های تجارت الکترونیک مانند آمازون استفاده می‌شود. برخی ممکن است جستجو و تسویه‌حساب را محصولات در نظر بگیرند زیرا تیم‌های جداگانه آن‌ها را مدیریت می‌کنند و مدیران محصول جداگانه دارند. اما این موضوع با تعریف رومن یا ملیسا مطابقت ندارد.
رومن استدلال میکند که جستجو و تسویه‌حساب ویژگی‌ها هستند. دلیل او این است که آن‌ها به طور مستقل ارزشی برای مشتریان ایجاد نمی‌کنند. رومن همچنین از مفهوم جزء استفاده میکند، که به آن بلوک‌های ساختمانی معماری نیز می‌گوید. این‌ها چیزهایی مانند لایه‌های UI و APIهای backend هستند، اما به اندازه کافی مستقل نیستند که محصول در نظر گرفته شوند.
شکل زیر یک دید کلی از محصول ملیسا را ارائه می‌دهد. در این مدل، پنج جنبه کلیدی کمک میکند تا روی یک محصول کامل تمرکز کنید: تحقیقات مشتری/کاربر، داده‌ها و تحقیقات بازار، داده‌های مالی و تأثیر بر فروش، داده‌های کاربر، و پیامدهای فناوری. اگر با هر یک از این مفاهیم آشنا نیستید، سخنرانی Melissa یا کتاب او Escaping the Build Trapرا بررسی کنید.
4.2. محصولات در مقابل انواع در مقابل سفرها:
طبق گفته رومن چندین نسخه از یک محصول به عنوان انواع محصولات شناخته می‌شوند. به عنوان مثال، بسیاری از محصولات یک برنامه وب، یک برنامه اندروید و یک برنامه آیفون دارند. هر یک از این برنامه‌ها عملکرد یکسان یا مشابهی را به عنوان بخشی از همان مدل کسب‌وکار ارائه می‌دهند. بنابراین، آن‌ها در واقع انواع یک محصول هستند تا اینکه خود محصولات مستقل باشند.
یک سفر کاربر ممکن است شامل تعامل با چندین محصول و انواع محصولات باشد و همچنین ممکن است شامل اقداماتی باشد که به تعامل با محصولات مرتبط نیستند. بنابراین، یک سفر کاربر بخشی از محصول نیست؛ مراحلی است که کاربر به عنوان بخشی از تجربه خود انجام می‌دهد. یک سفر کاربر می‌تواند به وظایف کاربر تجزیه شود.
4.3. حالت محصول:
در حالی که پلتفرم‌ها، ویژگی‌ها، اجزاء و انواع محصولات محصول نیستند، هنوز می‌توانند مانند محصولات واقعی مدنظر قرار گیرند. Sriram Narayan این را حالت محصول نامیده است. جدول زیر برخی از نقاط مقایسه کلیدی بین حالت محصول و رویکردهای توسعه سنتی که از یک مدل عملیاتی پروژه‌محور یا کارخانه ویژگی استفاده می‌کردند، برجسته میکند. به طور خلاصه، رویکردهای پروژه‌محور سنتی بر تحویل یک محدوده ثابت در زمان و بودجه با تیم‌های کوتاه‌مدت تمرکز داشتند، در حالی که حالت محصول بر بهبود مستمر محصولات بلندمدت که توسط تیم‌های پایدار مدیریت می‌شوند، تمرکز دارد.
حالت محصول مشخص میکند که تیم‌های محصولی توانمند در عمل چگونه به نظر می‌رسند: چگونه تشویق می‌شوند، چقدر مالکیت از ایده‌پردازی تا نگهداری مستمر دارند، و چگونه تأمین مالی می‌شوند. انتقال به این رفتارها از روش‌های کاملاً متفاوت و عمیقاً ریشه‌دار کار دشوار است و یک‌شبه اتفاق نخواهد افتاد. اما برای بهره‌برداری کامل از پتانسیل یک طبقه‌بندی محصول که به‌خوبی طراحی شده و معماری مدرن ضروری است.
5. نتیجه گیری:
انتقال به یک مدل عملیاتی محصول‌محور نیازمند تغییر عمیق در ساختار، فرهنگ و روش‌های کار در یک سازمان است. یک طبقه‌بندی محصول ابزاری برای طراحی معماری کسب‌وکار سازمان بر اساس بهبود مستمر محصولات و تجربیات مشتری است. از آن برای تعیین حوزه‌های مسئولیت و مالکیت تیم‌ها و شکل‌دهی به معماری نرم‌افزار متناسب با آن استفاده می‌شود.
انتقال به یک مدل عملیاتی محصول‌محور نیازمند تغییر عمیق در ساختار، فرهنگ و روش‌های کار در یک سازمان است. یک طبقه‌بندی محصول ابزاری برای طراحی معماری کسب‌وکار سازمان بر اساس بهبود مستمر محصولات و تجربیات مشتری است. از آن برای تعیین حوزه‌های مسئولیت و مالکیت تیم‌ها و شکل‌دهی به معماری نرم‌افزار متناسب با آن استفاده می‌شود. نکات کلیدی درباره طبقه‌بندی محصول عبارتند از:
