https://virgool.io/feed/@ar.oroumand fa 2026-04-15 10:07:52 https://files.virgool.io/upload/users/55915/avatar/V2uWDA.png?height=120&width=120 https://virgool.io/@ar.oroumand https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D8%A7%D8%B2%D8%AF%D9%87%D9%85-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-event-storming-qfh8hdhac3ip 1. مقدمه:رهبران مدرن‌سازی باید از اتخاذ تصمیم‌های حیاتی در معماری بر اساس درک محدود و سطحی از محیط اجتناب کنند. وقتی جزئیات زیادی را نمی‌دانید ممکن است به سادگی یک طراحی بد را خوب فرض کنید و کار را پیش ببرید.اخیرا با یکی پلتفرم‌های ویدئو همکاری داشتم که تلاش می‌کنند نرم افزار و فرایندهای خود را به روز کنند. طرح اولیه‌ای توسط مدیران سطح بالا آماده شده بود که وقتی این ایده را در مقابل کارمندان مختلف قرار دادیم، آن‌ها دلایل متعددی پیدا کردند که چرا معماری پیشنهادی کار نمی‌کند. آن‌ها درک بسیار عمیق‌تری از پیچیدگی‌های دامنه داشتند که مدیران طراح فاقد آن بودند. خدا رو شکر این مدیران به اندازه‌ای باهوش و فروتن بودند که بازخورد را بپذیرند، اما همیشه اینطور نیست و در بسیاری موارد ایده‌های ساده لوحانه تحمیل شده و مسیر معمار برج عاج را انتخاب می‌کنند.تکنیکی که رهبران مدرن‌سازی می‌توانند برای جلوگیری از نفوذ تفکر برج عاج به یک پروژه استفاده کنند، Big Picture Event Storming است. فرمت کارگاه به شما امکان می‌دهد تا وارد جزئیات یک دامنه شوید و اطمینان حاصل کنید که هیچ پیچیدگی یا nuance پنهانی هنگام تصمیم‌گیری‌های مهم مدرن‌سازی از قلم نیفتد. این یک تکنیک انعطاف‌پذیر است که در طول سفر مدرن‌سازی مفید خواهد بود، از اولین قدم ساخت یک چشمانداز تا شناسایی دامنه‌ها و زیردامنه‌هایی که طبقه‌بندی محصول را شکل می‌دهند و برای سازمان‌ها در انواع صنایع مؤثر است. من از این تکنیک برای تیم‌های مختلفی در بخش‌های آن را با مشتریانی در بخش‌های مختلف مانند مالی، ویدئو، خبر و ... استفاده کرده‌ام. این تکنیک یکی از مهم‌ترین ابزارها در جعبه ابزار من است بخصوص زمانی که در یک حوزه تازه وارد هستم.کارگاه Event Stroming حول ایده حداکثر مشارکت و تنوع شرکت‌کنندگان طراحی شده است. گرد هم آوردن افراد از سراسر کسب‌وکار با مهارت‌ها و نقش‌های مختلف این امکان را فراهم می‌کند که بازتاب واقعی از نحوه عملکرد کسب‌وکار ساخته شود. هیچ محدودیتی برای شرکت‌کنندگان و بهره‌وری در یک کارگاه Event Stroming وجود ندارد: افراد محصول، توسعه‌دهندگان نرم‌افزار، متخصصان دامنه، مهندسان کیفیت، طراحان UX، حسابداران و تقریباً هر کسی که در مشارکت در مدل کسب‌وکار شرکت نقش دارد. برگزاری این کارگاه امکان‌پذیر است زیرا Event Stroming به طور عمدی با یک نماد ساده طراحی شده است که به هر کسی که در یک کارگاه شرکت می‌کند اجازه می‌دهد به راحتی دانش خود از دامنه را به اشتراک گذاشته و آن را با دانش دیگران ترکیب کند. این نماد Domain Event یا رویداد دامنه نامیده می‌شود، که به سادگی به عنوان "رویدادهایی که در دامنه اتفاق می‌افتند" تعریف می‌شوند و به صورت یک جدول زمانی از چپ به راست تشکیل می‌شوند، همان‌طور که در شکل زیر نشان داده شده است. توجه کنید که این یک نمونه کوچک است؛ در یک جلسه واقعی، یک فضای دیواری بزرگ 8 تا 20 متری با یادداشت‌های چسبنده نارنجی پوشیده خواهد شد.در این قسمت، شما در مورد اصول Event Stroming یاد خواهید گرفت و راهنمایی عملی لازم برای برنامه‌ریزی و تسهیل اولین کارگاه Big Picture Event Storming خود را دریافت خواهید. تقریبا 4 سال پیش نیز طی مطالبی در این باره آموزش‌هایی در همین سایت داشتیم. اما این بار با ریکرد مدرن‌سازی و کمی به روز شدن مطلب به این موضوع می‌پردازیم.2. درک Event Storming:تکنیک Event Storming به طور آگاهانه ساده طراحی شده است. این تکنیک موانع ورود مانند نمادهای پیچیده و نقش‌ها و قوانین سخت‌گیرانه را کنار می‌گذارد. درک اصول اولیه بیشتر مربوط به درک ذهنیت Event Storming است، اینکه چگونه برای حداکثر همکاری و مشارکت بهینه‌سازی شده است ممکن است با تکنیک‌هایی دیگر تفاوت‌های زیادی داشته باشد.شما آزاد هستید که از تکنیک‌های دیگر هنگام نقشه‌برداری از کسب‌وکار و ساخت طبقه‌بندی محصول استفاده کنید. Event Storming به عنوان یک گلوله نقره‌ای که تکنیک‌های دیگر را از رده خارج می‌کند، معرفی نشده است. اما وقتی از Event Storming استفاده می‌کنید، مهم است که فلسفه آن را بپذیرید تا حداکثر ارزش را از جلسات خود به دست آورید.2.1. نمادها: فرضیه‌ی اصلی Event Storming ساخت یک جدول زمانی است که از چپ به راست با استفاده از رویدادهای دامنه، که از طریق یادداشت‌های چسبنده نارنجی بیان می‌شوند، اجرا می‌شود. در حالی که برخی تکنیک‌ها، مانند نقشه‌های سفر مشتری و نقشه‌های سرویس، بسیار ساختارمند هستند، رویدادگردانی انعطاف‌پذیرتر است. با توجه به شکل زیر شما متوجه خواهید شد که، شاخه‌های مختلف و خوشه‌های به ظاهر تصادفی وجود دارند تا یک خط واحد از رویدادها که از چپ به راست اجرا می‌شوند. این ساختار به این دلیل است که Event Storming بر روی قرار دادن تمام اطلاعات مفید روی دیوار و نمایش پیچیدگی منحصر به فرد دامنه شما در هر شکلی که به طور تصادفی یا عمدی ظاهر می‌شود، تمرکز دارد. ثبت تمام جزئیات مهم‌تر از نظم است.2.1.1. رویدادهای دامنه:یک رویداد دامنه به طور کلی به عنوان "چیزی که در دامنه اتفاق می‌افتد" تعریف می‌شود. این تعریف دقت کمی دارد تا از حذف هر کسی که ممکن است چیزی ارزشمند برای مشارکت داشته باشد، جلوگیری کند. هر چیزی که به نظر مرتبط با کسب‌وکار شما باشد می‌تواند در جدول زمانی نمایش داده شود. لیست زیر انواع رویدادها را به همراه یک مثال از هر کدام نشان می‌دهد. تعامل کاربر با یک محصول — مثلاً، "بررسی اضافه شد" یا "بیمه نامه خریداری شد" یا "سریال بارگذاری شد"، جایی که کاربر با یک محصول مانند استفاده از یک برنامه موبایل تعامل می‌کند. اقدامات در زندگی کاربر — مثلاً، "فکر کردن به نقل مکان به خانه جدید" یا "برنامه ریزی برای خرید یک سهام"، جایی که کاربر کاری انجام می‌دهد که شامل تعامل با یک محصول نیست اما هنوز برای کسب‌وکار جالب است. اقدامات درون سازمان — مثلاً، "ادعا تأیید شد" یا "قسمت جدید سریال بارگذاری شد"، جایی که یک کارمند درون سازمان عملی انجام می‌دهد یا تصمیمی می‌گیرد. اقدامات مدیریت شده توسط نرم‌افزار — مثلاً، "راننده انتخاب شد" یا "ترنسکد قسمت جدید سریال انجام شد" ، جایی که قوانین کسب‌وکار خودکار و الگوریتم‌ها عملی را انجام می‌دهند، مانند محاسبه یک مقدار یا تصمیم‌گیری. شما از همه این مثال‌ها متوجه خواهید شد که رویدادهای دامنه به زمان گذشته بیان می‌شوند. این یکی از معدود قوانین در Event Storming است که تا حد امکان باید رعایت شود. اگر همه از زمان گذشته استفاده کنند، جدول زمانی سازگارتر و درک آن آسان‌تر خواهد بود. علاوه بر این، استفاده از زمان گذشته این امکان را فراهم می‌کند که به یک نقطه دقیق در زمان اشاره شود. به عنوان مثال، یک رویداد "خبر منتشر شد" به لحظه دقیقی اشاره می‌کند که یک خبر منتشر و در وب‌سایت قابل مشاهده شد، که باعث می‌شود اشاره به نقاط خاص در جدول زمانی و بیان بدون ابهام آنچه قبل و بعد از آن می‌آید، آسان‌تر شود.معمول است که مبتدیان از نام‌های مبهم‌تری مانند "ثبت‌نام کاربر" استفاده می‌کنند. مشکل این نوع نام‌گذاری این است که مشخص نیست کجا شروع و پایان می‌یابد و چه چیزی شامل می‌شود. پشت رویداد ساده مثل این، نکات ظریف زیادی وجود دارد که ممکن است مهم باشد که باز شود.این تکنیک در مورد اندازه دقیق رویدادها بیش از حد مته به خشخاش نمیگذارد. با این حال، چند اصل اساسی وجود دارد که باید در نظر داشته باشید. از یک طرف، ماندن در سطح خیلی بالا به این معنی است که جزئیات مهم و پیچیدگی دامنه پنهان خواهد ماند. به عنوان مثال، مهم است که نه تنها مسیرهای خوش‌بینانه را بررسی کنید، بلکه سناریوها و موارد لبه‌ای مختلف را نیز بررسی کنید. از طرف دیگر، رویدادهایی که خیلی جزئی هستند ممکن است روایت واقعی کسب‌وکار را با جزئیات غیرضروری مبهم کنند، مانند "کاربر روی فرم کلیک کرد" و "آیتم در پایگاه داده ذخیره شد". گاهی اوقات مکانیزم‌های انجام کار مفید هستند، اما معمولاً بهتر است روی دامنه تمرکز کنید: قصد کاربر هنگام کلیک روی فرم چه بود (مثلاً، "درخواست عضویت")؟ و چه آیتمی در پایگاه داده ذخیره شد (مثلاً، "درخواست عضویت دریافت شد")؟2.1.2. افراد، سیستم‌ها و نقاط حساس کانونی:علاوه بر رویدادهای دامنه که با رنگ نارنجی نمایش داده می‌شوند، نمادهای دیگری نیز می‌توانند در یک جلسه Big Picture Event Storming استفاده شوند، همان‌طور که در شکل نشان داده شده است. یادداشت‌های چسبنده کوچک زرد برای نشان دادن نقش‌ها یا شخصیت‌ها در دامنه استفاده می‌شوند، مانند یک مشتری در بانک، تماشاچی در پلتفرم نمایش خانگی یا نماینده بیمه. یادداشت‌های چسبنده بزرگ صورتی روشن برای نشان دادن سیستم‌هایی مانند سیستم مدیریت سفارش (OMS) یا یک پلتفرم پرداخت شخص ثالث خارجی استفاده می‌شوند. یادداشت‌های چسبنده صورتی تیره (فوشیا) چرخانده شده برای نشان دادن نقاط کانونی (Hotspot)استفاده می‌شوند. یک نقطه کانونی به عنوان یک نماینده برای نشان دادن چیزی مهم، مانند یک مشکل یا یک منطقه اختلاف استفاده می‌شود. به طور کلی، این نمادها به تدریج معرفی می‌شوند تا یادگیری ساده باشد.2.1.3. موارد خاص، جریان‌های موازی و حلقه‌ها:در هر دامنه‌ی پیچیده، بسیاری از شاخه‌ها وجود خواهند داشت که سناریوها و موارد حساس خاص مختلف را نشان می‌دهند. اغلب فرآیندهایی نیز به طور موازی اتفاق می‌افتند. برخلاف تکنیک‌های دیگر، Event Storming نماد خاصی برای نشان دادن این مفاهیم ندارد. با این حال، آن‌ها هنوز هم می‌توانند به راحتی نمایش داده شوند. ساده‌ترین رویکرد برای تجسم چندین سناریوی ممکن این است که یک مسیر خوش‌بینانه در جریان اصلی حفظ کنید و موارد خاص را به عنوان جریان‌های افقی زیر جریان اصلی نشان دهید، همان‌طور که در شکل زیر نشان داده شده است.شما در شکل بالا متوجه خواهید شد که نقطه داغ خالی باقی مانده است، در حالی که سایر شکل‌ها توضیحاتی روی آن‌ها نوشته شده است. قاعده کلی من این است که وقتی مشکل از قبل واضح است، زمان را ذخیره می‌کنم و نقطه داغ را خالی می‌گذارم. در این مثال، واضح است که خراب شدن برنامه یک مشکل است. جایی که یک مسیر خوش‌بینانه واحد وجود ندارد، حاشیه‌نویسی‌ها می‌توانند در ابتدای هر جریان اضافه شوند که نام سناریو را توصیف می‌کنند، همان‌طور که در شکل زیر نشان داده شده است.جریان‌های موازی می‌توانند با تقسیم جریان اصلی به چندین شاخه تجسم شوند، همان‌طور که در شکل بعد نشان داده شده است. اگر تشخیص اینکه یک شاخه خاص به طور موازی اجرا می‌شود یا یک سناریوی جایگزین است آسان نباشد، یادداشت‌های اضافی می‌توانند اضافه شوند. برای مثال در تصویر از یک یادداشت چسبنده زرد با کلمه "موازی" روی آن استفاده شده است. علاوه بر این تکنیک‌ها، همچنین ممکن است از استراتژی‌های مرتب‌سازی مختلف، که بعداً پوشش داده می‌شوند، مانند ایجاد خطوط شنا برای تأکید بر ماهیت یک دامنه و جریان‌های مختلف استفاده شود.نمایش حلقه‌ها سوال پیچیده‌تری نسبت به فقط تصمیم‌گیری در مورد نحوه تجسم آن‌ها است. ما باید بپرسیم، "آیا واقعاً به یک حلقه در اینجا نیاز داریم، یا رویکرد بهتری وجود دارد؟" ما نمی‌توانیم در زندگی واقعی به عقب برگردیم، و این موضوع معمولاً در مورد جدول زمانی در Event Storming نیز صادق است.به عنوان مثال، پرداخت با تاخیر به یک ISP (ارائه‌دهنده خدمات اینترنت) را در نظر بگیرید. اگر یک مشتری به موقع پرداخت نکند، ISP به او یک نامه یادآوری می‌فرستد. اگر مشتری پس از 30 روز هنوز پرداخت نکند، نامه دیگری ارسال می‌شود. این ممکن است به نظر یک حلقه برسد، اما آیا واقعاً اینطور است؟ آیا این حلقه برای همیشه ادامه می‌یابد، و آیا هر تکرار حلقه یکسان است؟ به عنوان مثال، اگر یک مشتری اولین پیام را نادیده بگیرد، پیام دیگری با زبان قوی‌تر و تهدید به قطع اینترنت مشتری دریافت می‌کند. اگر مشتری هنوز پرداخت نکند، تکرار سوم یک تماس تلفنی به جای نامه خواهد بود. و سپس، در نهایت، اگر مشتری هنوز پرداخت نکند، خدمات او لغو می‌شود و فرآیند وصول بدهی آغاز می‌شود. بنابراین، هر زمان که احساس می‌کنید می‌خواهید از نماد حلقه خاصی استفاده کنید، ابتدا سعی کنید چند تکرار از حلقه را نقشه‌برداری کنید و سعی کنید تفاوت هر تکرار را شناسایی کنید.2.1.4. خطوط و فلش‌ها: یک تمایل رایج در جلسات Event Storming رسم خطوط و فلش‌ها است، همان‌طور که در تکنیک‌های دیگر وجود دارد. خطوط و فلش‌ها به راحتی مانند یادداشت‌های چسبنده قابل جابجایی نیستند، و این بسیار مشکل‌ساز است زیرا رویدادهای دامنه در یک جلسه معمولی زیاد جابجا می‌شوند. از نظر مفهومی، خطوط و فلش‌ها معنا ندارند زیرا سفر به عقب و جلو در زمان غیرممکن است. ممکن است سخت به نظر برسد که علیه غرایز خود مبارزه کنید، اما به سرعت به عدم نیاز به خطوط و فلش‌ها عادت خواهید کرد.2.2. اکتشاف آشفته: علاوه بر دیواری پوشیده از یادداشت‌های چسبنده نارنجی، ویژگی تعیین‌کننده دیگر Big Picture Event Storming، اکتشاف آشفته است. بیشتر تکنیک‌ها برای نقشه‌برداری از سفرهای کاربر و فرآیندهای کسب‌وکار یک رویکرد گام به گام ساختارمند دارند. از طرف دیگر، Event Storming با کل گروه شروع می‌شود که تعداد زیادی رویداد دامنه اضافه می‌کنند و آن‌ها را به طور موازی روی دیوار قرار می‌دهند. نتیجه این کار بسیار به هم ریخته به نظر می‌رسد، و شرکت در یک جلسه Event Storming برای اولین بار ممکن است کمی ناراحت‌کننده به نظر برسد. با این حال، مرحله آشفته Event Storming بخش کلیدی فلسفه آن است. اکتشاف آشفته این امکان را فراهم می‌کند که هر شرکت‌کننده آنچه را که در مورد دامنه می‌داند و آنچه برای او مهم است را مطرح کند، و تا حد امکان ایده‌ها و بینش‌ها را با کمترین سوگیری و پیش‌فیلترینگ ممکن روی دیوار قرار دهد. در اصل، طوفان فکری فردی به منظور اجازه دادن به ظهور مهم‌ترین موضوعات است. بعدا این به هم ریختگی به راحتی مرتب خواهد شد.اکتشاف آشفته برای ساختار‌های نوظهور یک توانمندساز است. این مفهوم در مورد اجازه دادن به مرزهای دامنه برای ظهور از به هم ریختگی و آشفتگی به جای تعریف هر ساختاری از قبل است. اضافه کردن برخی ساختارها از قبل، مانند مرزهای دامنه یا سازمانی موجود، ساختارهای تعریف شده در طول کارگاه را تحت تأثیر قرار می‌دهد. در عین حال، اجازه دادن به ظهور ساختارها با استفاده از تکنیک‌هایی مانند رویدادهای محوری (که بعداً در توضیح داده می‌شوند) احتمالاً مرزهای دامنه ایده‌آلی را نشان می‌دهد که تحت تأثیر فرضیات نادرست قرار نگرفته‌اند.نکته: در برخی موقعیت‌ها، اکتشاف آشفته رویکرد درستی نیست و کار را با چالش‌هایی همراه خواهد کرد. جلسات از راه دور مثالی از ایجاد مشکل با اکتشاف آشفته است. اکتشاف آشفته و مکالمات موازی به سختی از راه دور قابل بازسازی و مدیریت هستند، بنابراین می‌توان از حالتی خاص استفاده کرد که در آن فقط یک نفر رویدادها را روی جدول زمانی قرار می‌دهد و سایر شرکت‌کنندگان آن‌ها را راهنمایی می‌کنند. شخصا گاهی از حالت تک‌رشته‌ای برای کارگاه‌های حضوری نیز استفاده می‌کنم. وقتی انرژی و همکاری شرکت کنندگان کم است یا می‌خواهم جهت کارگاه را کنترل کنم معمولا در نقش مدل‌ساز ایجاد تایم لاین را مدیریت میکنم.2.3. بهینه‌سازی برای یادگیری و همکاری: برای بسیاری از افراد، ایده‌های ارائه شده در این بخش می‌تواند درک Event Storming را دشوار کند. به عنوان مثال، عدم وجود نمادهای خاص و دقت اغلب منجر به نظراتی مانند موارد زیر می‌شود: این یک به هم ریختگی است؛ سازگار نیست. برخی رویدادها بسیار سطح بالا هستند و در بخش‌های دیگر جدول زمانی، جزئیات بسیار بیشتری وجود دارد. غلبه بر این موانع نیاز به پذیرش این دارد که Event Storming یک تکنیک بهینه‌سازی شده برای همکاری و یادگیری است. جدول زمانی روی دیوار راهی است برای اینکه افراد به طور مشارکتی آنچه را که به طور فردی می‌دانند را در یک تصویر از دانش جمعی به اشتراک گذارند که این تصویر خود به عنوان پایه‌ای برای مکالمات نقشه‌برداری استفاده خواهد شد.اگر برخی بخش‌های جدول زمانی جزئیات بیشتری داشته باشند، ممکن است به این دلیل باشد که افراد تصمیم گرفته‌اند که ارزش دارد به برخی مناطق زوم کنند و به برخی دیگر نه. همچنین ممکن است نشان‌دهنده این باشد که برخی افراد که مناطق کمتر تعریف شده را درک می‌کنند در کارگاه حضور نداشته‌اند. یادداشت‌های چسبنده روی دیوار فقط یک ابزار برای داشتن مکالمات عالی، به اشتراک گذاری دانش و شناسایی فرصت‌های بهبود هستند. خیلی روی مصنوع یا ارزش استفاده مجدد بعد از جلسه وسواس نداشته باشید. اما بعد از جلسه آزادانه عکس بگیرید و هر یادگیری مهم را به فرمت‌های دیگر تقطیر کنید.2.4. زمان استفاده از Event Storming:داشتن Event Storming در جعبه ابزار شما به این معنی است که برای مقابله با طیف گسترده‌ای از سناریوها مجهز هستید. هنگام ساخت یک چشمانداز برای مدرن‌سازی معماری، این مفید است که بخش‌هایی از دامنه را بررسی کنید تا فرصت‌های مدرن‌سازی را شناسایی کنید یا یک پیشنهاد موجود برای مدرن‌سازی یک بخش خاص از کسب‌وکار را تأیید کنید.در یک پروژه بورسی، ما به دنبال منطقه‌ای از کسب‌وکار بودیم که مناسب برای یک برش اولیه مدرن‌سازی باشد. ما چهار منطقه کاندید را شناسایی کرده بودیم که به نظر می‌رسید بر اساس ارائه نتایج کسب‌وکار و فرصت‌های یادگیری، مناسب باشند. اما هنوز به اطلاعات بیشتری نیاز داشتیم تا به ما کمک کند انتخاب نهایی را انجام دهیم. بنابراین تصمیم گرفتیم جلسات Event Storming را اجرا کنیم. پس از اجرای یک جلسه Event Storming در یک منطقه، به سرعت آن را رد کردیم. همان‌طور که وارد جزئیات دامنه شدیم، می‌توانستیم تعداد زیادی وابستگی بین زیردامنه‌های مختلف را ببینیم. مدرن‌سازی آن منطقه شامل 3 تیم و لمس پنج پایگاه کد در کنار 3 دیتابیس می‌شد. اینکار برای یک برش اولیه بسیار چالش‌برانگیز و پرخطر بود.یکی از موضوعات اساسی در تلاش برای مدرن‌سازی معماری، طراحی مرزهای نرم‌افزار و سازمانی است که باید توسط مرزهای دامنه هدایت شود. برای من، Event Storming ابزاری ضروری در این فرآیند است و اغلب به عنوان نقطه شروع عمل می‌کند زیرا رویدادگردانی می‌تواند به دامنه‌ها و زیردامنه‌ها تقسیم شود، همان‌طور که تصویر نشان داده شده است.نکته‌ی عالی‌ای که در مورد استفاده از Event Stormingبرای تعریف دامنه‌ها و زیردامنه‌ها وجود دارد این است که Event Storming نشان‌دهنده دانش جمعی دامنه از دیدگاه‌های متنوع است. این به ما اطمینان بسیار بالایی می‌دهد که ما مرزهای دامنه را بر اساس تمام جزئیات کلیدی دامنه شکل می‌دهیم و فرضیات حیاتی را از دست نمی‌دهیم. البته دقت کنید این فرض تا زمانی که اطمینان حاصل کنیم تمام افراد کلیدی در کارگاه حضور دارند صحیح است.در قسمت‌های بعدی استفاده از Event Storming را برای شناسایی دامنه‌ها و زیردامنه‌ها، از جمله طیف وسیعی از اصول و اکتشافات، نشان می‌دهد. سپس می‌توان از تکنیک‌های دیگر، مانند مدل‌سازی جریان پیام دامنه و توپولوژی‌های تیم، برای ارزیابی و اصلاح مرزهای شناسایی شده با Event Stormingاستفاده کرد. در مجموع، این ابزارها به چالش کشیدن طراحی از بسیاری از دیدگاه‌ها کمک می‌کنند، و اطمینان بالایی می‌دهند که تمام عوامل مهم در نظر گرفته شده‌اند و طراحی برای نتایج مدرن‌سازی مورد نظر بهینه شده است.در این قسمت روی Big Picture تمرکز داریم، در آینده به مدل‌سازی فرآیند و طراحی نرم‌افزار به کمک Event Storming خواهیم پرداخت. Big Picture برای اکتشاف آشفته و یادگیری گروهی در یک منطقه بزرگ بهینه‌سازی شده است. مدل‌سازی فرآیند می‌تواند برای نقشه‌برداری از مناطق کوچکتر دامنه با درشت دانگی بالاتر با استفاده از ساختار و نماد بیشتر استفاده شود. اینکار برای نقشه‌برداری از وضعیت فعلی و طراحی فرآیندهای جدید یا بهبود یافته عالی است. طراحی نرم‌افزار به کمک Event Storming (که به عنوان رویدادگردانی سطح طراحی نیز شناخته می‌شود) ساختار و جزئیات بیشتری اضافه می‌کند و به عنوان یک پل برای نقشه‌برداری بین دامنه و نرم‌افزار که به شدت با دامنه همسو است، استفاده می‌شود.2.5.نکته:طی سالیانی که از این تکنیک برای کارهای مختلف و با همراهی تیم های متفاوت استفاده کرده ام درس بزرگی که دریافتم این است که Event Storming یک تکنیک است که فضایی ایجاد می‌کند که مکالمات و یادگیری ارزشمند در آن اتفاق می‌افتد. اگر چندین تیم در یک منطقه کسب‌وکار کار می‌کنند یا بخشی از یک ابتکار بزرگتر هستند، فقط گرد هم آوردن آن‌ها برای یک جلسه Event Storming می‌تواند منجر به بسیاری از نتایج مثبت شود حتی بدون یک هدف مشخص شده از قبل. این کشف است — ما نمی‌دانیم چه چیزی را کشف خواهیم کرد. اگر زمان را برای مکاشفات سرمایه‌گذاری نکنید، ممکن است هرگز ندانید که چه فرصت‌های یادگیری مهمی را از دست می‌دهید.3. اجرای یک جلسه Event Storming:در حالی که Event Storming بر اساس یک نماد ساده است که به یک گروه بزرگ با مهارت‌ها و تخصص‌های متنوع اجازه می‌دهد به راحتی همکاری کنند، باید اعتراف کنم که برنامه‌ریزی و اجرای یک جلسه Event Storming کمی چالش‌برانگیزتر است. پیدا کردن زمانی که برای همه مناسب باشد، آماده کردن یک اتاق با فضای مدل‌سازی زیاد، و به ویژه مدیریت دینامیک یک گروه ترکیبی از شخصیت‌ها می‌تواند مشکل‌ساز باشد. خوشبختانه، پس از چند کارگاه اول، مواجهه با مشکلات آسان‌تر می‌شود. مانند بیشتر مهارت‌ها، تمرین و پشتکار داشتن کلید موفقیت است. این بخش برای کمک به آماده‌سازی شما برای اولین کارگاه شما با ارائه راهنمایی برای هر مرحله از فرآیند است.3.1. برنامه‌ریزی یک جلسه:محدوده و هدف اولین عناصری هستند که هنگام برنامه‌ریزی یک جلسه Event Storming باید در نظر گرفته شوند. اگر محدوده را خیلی محدود تعیین کنید، ممکن است ارتباطات مهم بین بخش‌های مختلف دامنه را از دست بدهید که برای منطقه‌ای که روی آن تمرکز کرده‌اید حیاتی هستند. با این حال، اگر محدوده را خیلی گسترده تعیین کنید، مجبور خواهید بود افراد زیادی را دعوت کنید، و ممکن است تسهیل چنین گروه بزرگی غیرممکن شود. من معمولاً با محدودیت حدود 15 تا حداکثر 20 شرکت‌کننده برای یک جلسه Big Picture Event Storming کار می‌کنم،تجربه نفرات بیشتر موفقی نداشته ام و شاید برای تعداد بیشتر نیاز باشد تسهیل‌گرهای بیشتری همراه ما باشند. من این تعداد را نقطه مناسبی برای بسیاری از بینش‌ها و دیدگاه‌های متنوع بدون اینکه تعداد افراد طاقت‌فرسا شود، می‌دانم. با این محدودیت انسانی در ذهن، سپس این سوال مطرح می‌شود که چگونه می‌توانید محدوده را به اندازه‌ای گسترده تعیین کنید که تمام افرادی که نیاز به حضور در جلسه دارند را شامل شود.برای ساخت یک تصویر دقیق از نحوه عملکرد کسب‌وکار، شرکت‌کنندگان باید تا حد امکان نماینده کسب‌وکار باشند: طراحان UX، افراد محصول، متخصصان حوزه کسب و کار، مهندسان، تسترها، افراد پشتیبانی و غیره. فرض کنید شما در حال ساخت یک پیشنهاد برای اولین برش مدرن‌سازی هستید و یک دامنه خاص (محدوده 2) را شناسایی کرده‌اید که می‌تواند نقطه شروع خوبی باشد. دامنه شامل پنج زیردامنه است که هر کدام توسط یک تیم جداگانه اداره می‌شود، با حدود 30 مهندس نرم‌افزار که در آن دامنه کار می‌کنند. حداقل لیست شرکت‌کنندگان ممکن است چیزی شبیه به این باشد:5 توسعه‌دهنده نرم‌افزار (حداقل یک نفر از هر تیم) 1 مهندس ارشد/معمار/مدیر مهندسی (مسئول کل دامنه) 2 مدیر محصول (به طور جمعی مسئول کل دامنه) 1 طراح UX (در کل دامنه کار می‌کند) 1 متخصص کسب و کار1 نماینده پشتیبانی مشتری 1 مهندس عملیات/پلتفرم 1 تستر انتخاب یک دامنه در محدوده‌ی 2 این پیشفرض را دارد که مرزها در آن سطح از قبل تعیین شده‌اند. اما اگر اینطور نباشد و هدف کارگاه شما تعیین آن‌ها باشد، در این سناریو منطقی است که ابتدا یک سری کارگاه‌ها برای تعیین مرزهای محدوده 2 داشته باشید و سپس جلسات عمیق‌تری در هر یک از آن‌ها برگزار کنید. کارگاه‌های Event Storming که چندین دامنه محدوده 2 را پوشش می‌دهند ممکن است از 15 تیم یا بیشتر عبور کنند، بنابراین در آن سطح ممکن است امکان حضور یک مهندس از هر تیم وجود نداشته باشد. ممکن است به اجبار فقط رهبر فنی هر دامنه را برای شرکت در کارگاه دعوت کنیم.دعوت از شرکت‌کنندگان و کمک به آن‌ها برای دیدن اهمیت حضور در جلسه گاهی اوقات نیاز به تلاش و صبر دارد. معمولاً تمایلی برای خروجی‌های مشخص و یک دستور کار برای جلسه وجود دارد. از آنجا که Event Storming شامل مقدار زیادی مکاشفه است، ارائه لیستی از خروجی‌های خاص و یک دستور کار دقیقه به دقیقه از قبل امکان‌پذیر نیست.در زمینه مدرن‌سازی، ربط دادن جلسه به موضوع مدرن‌سازی و توضیحی کوتاه مثل "ما به دنبال مدرن‌سازی این منطقه از کسب‌وکار هستیم، و این کارگاه شامل نقشه‌برداری از وضعیت فعلی و بررسی وضعیت‌های آینده خواهد بود"، یا "ما به دنبال تعریف دامنه‌ها و زیردامنه‌ها در این منطقه هستیم، و از تکنیکی به نام رویدادگردانی به عنوان نقطه شروع استفاده خواهیم کرد." کارآمد و جذاب خواهد بود.مدت زمان نیز یک ملاحظه‌ی مهم است. برای یک جلسه رویدادگردانی پایه با کمی زمان برای بررسی مشکلات و فرصت‌ها، حداقل 3 ساعت را پیشنهاد می‌کنم. به طور متناوب، اگر قصد دارید یک دامنه را نقشه‌برداری کنید، چندین مشکل و فرصت را بررسی کنید که به وجود می‌آیند، و زیردامنه‌ها را شناسایی کنید، توصیه می‌کنم حداقل 3 روز کامل را کنار بگذارید.3.2. آماده‌سازی فضا: فضای موجود و چیدمان اتاق می‌تواند تأثیر زیادی بر نحوه‌ی پیشرفت جلسه داشته باشد، بنابراین آماده‌سازی فضای مدل‌سازی ضروری است. حداقل باید 8 متر فضای آزاد روی دیواری داشته باشید، مانند شکل زیر. جایی که شرکت‌کنندگان می‌توانند به راحتی جمع شوند و حرکت کنند. بهتر است از کاغذ روی دیوار استفاده کنید زیرا ریسک استفاده از سطح دیوار برای یادداشت‌های چسبنده زیاد است و معمولا چسبندگی خوبی ندارند. یک میز کوچک برای تمام یادداشت‌های چسبنده، خودکارها و سایر لوازم کارگاه نیز لازم است. علاوه بر این، بهتر است تمام میزهای دیگر را از اتاق خارج کنید تا حواس‌پرتی‌های خارجی مانند استفاده افراد از لپ‌تاپ به حداقل برسد. یک جلسه معمولی بین 3 ساعت تا یک روز کامل طول می‌کشد، بنابراین غیرمنطقی است که کاملاً صندلی‌ها را حذف کنید، اما ممکن است بخواهید آن‌ها را برای یک یا دو ساعت اول که می‌خواهید انرژی و مشارکت بالا باشد، بردارید. یکی از مزایای جلسات مجازی با استفاده از ابزارهایی مانند Miro این است که نیازی به نگرانی در مورد این چیزها نیست و فضای مدل‌سازی نامحدود دارید.3.3. شروع جلسه: معمولا دوست دارم کارگاه‌ها را با یک مرور سریع از هدف شروع کنم، سپس با یک سوال شخصی-اجتماعی مرتبط با شرکت کنندگان ادامه می‌دهم. علاوه بر معرفی معمول که نقش فرد در شرکت و امیدهای او برای کارگاه را پوشش می‌دهد، این سوال همچنین فضایی ایجاد می‌کند که افراد چیزی درباره خودشان را آشکار کنند و کمی سرگرمی به جلسه بیاورند. برخی از مثال‌هایی که من استفاده کرده‌ام عبارتند از: "اولین شغل شما چه بود؟"، "برنامه تلویزیونی مورد علاقه شما در کودکی چه بود؟"، و "چه کسی را بیشتر دوست دارید ملاقات کنید (هر فردی که زنده است یا بوده) و چرا؟" در بخش بعدی در صورتی که افراد با Event Stroming آشنا نباشند، با یک مثال ساده و در دامنه‌ای عمومی موضوع را خیلی سریع برای همه معرفی می‌کنم. بعد از اینکه از درک کلی کارگاه توسط همه شرکت کنندگان مطمئن شدم، سراغ شروع جلسه می‌روم.امکان‌های متعددی برای شروع نقشه‌برداری از دامنه وجود دارد. برخی افراد دوست دارند مستقیماً وارد Event Storming شوند و جدول زمانی را بسازند، در حالی که دیگران دوست دارند با فعالیت‌های دیگر شروع کنند. کارگاه Event Storming در ابتدا به طور عمدی آشفته است؛ ممکن است مدتی طول بکشد تا افراد شروع به درک ارزش‌های آن کنند. بنابراین، اغلب تمایل دارم با فعالیتی شروع کنم که افراد را گرم کند تا در مورد دامنه فکر کنند و ارزش کافی را ارائه دهد تا افراد اطمینان داشته باشند که بقیه کارگاه نیز ارزش ارائه خواهد داد. تکنیکی که من استفاده می‌کنم، نقشه‌برداری از نقش‌ها و شخصیت‌ها در دامنه است.با لیست کردن تمام افراد در دامنه و توصیف هدف آن‌ها، کارهایی که باید انجام دهند، و سایر اطلاعات مفید درباره‌ی آن‌ها، شما شروع به لمس مناطق مختلف دامنه می‌کنید و مکالمات ارزشمندی دارید. شما در حال شروع به ساخت تصویر بزرگ و ایجاد ارتباطات هستید، که آماده‌سازی ایده‌آلی برای یک جلسه Big Pircutre Event Storming است. افراد محصول و UX ممکن است قبلاً این کار را انجام داده باشند، اما توصیه می‌کنم از یک بوم خالی شروع کنید. هدف این است که برای جلسه گرم شوید و همه را به فکر وادارید. پس اگر شخصیت‌هایی از قبل وجود دارند، در ابتدا استفاده نکنید، بلکه افراد را در تابلو خالی وارد کرده و بعدا از افراد موجود برای مقایسه استفاده کنید.در تصویر بعد، می‌توانید نمونه‌ای از نقشه‌برداری نقش‌ها و شخصیت‌ها در یک دامنه را ببینید. این تصویر بر اساس یک کارگاه با مشتری‌ای در بخش املاک است . فقط با لیست کردن نقش‌ها و مسئولیت‌ها، افراد شروع به تقسیم آن‌ها به طرف تقاضا و طرف عرضه کردند و اصطلاحات کلیدی را تعریف کردند. ما همچنین اینکه چگونه یک نفر می‌تواند چندین نقش را بازی کند را برجسته کردیم، مانند یک نفر که اغلب همزمان خریدار و فروشنده است.3.4. ساخت جدول زمانی: وقتی آماده شروع رویدادگردانی هستید، اولین قدم ساخت جدول زمانی است. به هر فرد چند یادداشت چسبنده نارنجی و یک خودکار داده می‌شود. سپس به همه گفته می‌شود که شروع به اضافه کردن رویدادهای دامنه در طول جدول زمانی کنند، آن‌ها را در هر جایی که احساس می‌کنند درست است، قرار دهند. ابتدا یک توضیح کوتاه از رویدادهای دامنه لازم است، و سپس افراد می‌توانند شروع به اضافه کردن یادداشت‌های چسبنده در هر جایی که دوست دارند کنند.معمولاً رویدادهای دامنه را به عنوان چیزی که می‌تواند در فرآیند کسب‌وکار یا دنیای کاربر اتفاق بیفتد، به زمان گذشته بیان می‌کنم. و برخی مثال‌های کلی مانند "بیمه نامه خریداری شد"، "منو منتشر شد"، "حادثه گزارش شد"، و "دستگاه فعال شد" ارائه می‌دهم. همچنین مهم است که توضیح دهید که هر چیزی می‌تواند ناقص باشد. من به شرکت‌کنندگان تأکید می‌کنم که قسمت اول یک مرحله طوفان فکری به هم ریخته است، و سپس همه چیز را مرتب می‌کنیم.یک تکنیک کنترل‌شده‌تر برای شروع جلسه، تسهیل چند رویداد اولیه است. به عنوان تسهیل‌کننده، از یک شرکت‌کننده بخواهید مثالی از یک رویداد بدهد و آن را روی جدول زمانی قرار دهد. سپس از شرکت‌کننده دیگری بخواهید یک رویداد متفاوت بدهد. در این حالت، من از شرکت‌کنندگان می‌خواهم که به رویدادهایی فکر کنند که در بخش‌های دیگر جدول زمانی اتفاق می‌افتند، همان‌طور که در شکل زیر نشان داده شده است. به این ترتیب، افراد به کل فرآیند فکر می‌کنند و کل جدول زمانی روی دیوار را پر می‌کنند. فضای خالی بین رویدادها نشان‌دهنده این است که من انتظار دارم شرکت‌کنندگان شکاف‌ها را پر کنند و وارد جزئیات دامنه شوند تا اینکه در سطح بالا بمانند. پس از اضافه شدن چهار یا پنج رویداد اولیه، و زمانی که افراد می‌دانند یک رویداد دامنه خوب چیست، جلسه به اکتشاف آشفته تغییر می‌کند.چند لحظه اول هنگام ساخت جدول زمانی می‌تواند دوره گیج‌کننده‌ای باشد. افراد هنوز دقیقاً نمی‌دانند چه کاری انجام دهند و یک رویداد دامنه چیست. به عنوان یک تسهیل‌کننده، بهترین کار این است که به افراد یادآوری کنید نگران نباشند زیرا جدول زمانی بعداً مرتب می‌شود. در ابتدا، هدف این است که تا حد امکان رویدادها را روی دیوار قرار دهید، هر جایی که به نظر می‌رسد مناسب است. با این حال، اگر افراد خیلی از مسیر خارج شوند، باید مداخله کنید و آن‌ها را اصلاح کنید. به عنوان مثال، اگر متوجه شوید که کسی رویدادها را به زمان گذشته بیان نمی‌کند، می‌توانید به آرامی آن‌ها را اصلاح کنید. پس از 5 دقیقه، برخی افراد ممکن است هیچ رویدادی اضافه نکرده باشند، بنابراین می‌توانید از آن‌ها بپرسید که آیا می‌توانید کاری برای کمک انجام دهید. ممکن است بخواهید آن‌ها را تشویق کنید تا کار خود را توصیف کنند و سپس شروع به مدل‌سازی آن برای آن‌ها کنید، اما سپس به آرامی عقب‌نشینی کنید و به آن‌ها بگویید که باید ادامه دهند. مراقب نقش تسهیل‌گری خود باشید که به مدل‌ساز تغییر پیدا نکند.مشکلی ندارم که افراد در مرحله اول صحبت کنند، تا زمانی که به اضافه کردن رویدادها ادامه دهند و در مورد رویدادهای روی دیوار بحث کنند. اگر به نظر می‌رسد که خیلی صحبت می‌کنند، توصیه می‌کنم به آرامی افراد را تشویق کنید که به طوفان فکری رویدادها ادامه دهند و به آن‌ها بگویید که بعداً در مورد آن‌ها بحث خواهیم کرد. به عنوان یک راهنمای کلی، من دوست دارم حداقل 25 دقیقه فعالیت مداوم و دیواری که به خوبی با یادداشت‌های چسبنده نارنجی پوشیده شده است، قبل از اجازه دادن به مکالمات طولانی ببینم. وقتی انرژی کاهش می‌یابد، می‌توانید به گروه اعلام کنید که زمان استراحت است، و وقتی بعد از استراحت دوباره جمع می‌شویم، به هم ریختگی را مرتب می‌کنیم و آن را معنا می‌دهیم.3.5. مرتب‌سازی جدول زمانی: این مرحله شامل مرتب‌کردن جدول زمانی به هم ریخته با استفاده از یکی از تکنیک‌های مرتب‌سازی متعدد است. ساده‌ترین رویکرد این است که از گروه بخواهید تمام رویدادها را مرور کنند و آن‌ها را به ترتیب درست قرار دهند. همه رویدادها به طور طبیعی در یک مکان واحد قرار نمی‌گیرند، بنابراین می‌توانید به شرکت‌کنندگان بگویید که می‌توانند یک مکان را انتخاب کنند یا برای حالا رویدادها را تکرار کنند. این کار اغلب نقطه خوبی برای گروه است که از نماد نقش‌ها/شخصیت‌ها و سیستم‌های خارجی استفاده کنند.فقط خواستن از یک گروه برای مرتب‌کردن جدول زمانی کمی خوش‌بینانه است، بنابراین یک رویکرد ساختارمندتر می‌تواند مفید باشد. رایج‌ترین رویکرد، رویدادهای محوری (Pivotal Event) نامیده می‌شود، که شامل تقسیم جدول زمانی به بخش‌هایی با استفاده از رویدادهای خاص به عنوان نقطه تفکیک بین مناطق مختلف، با استفاده از نوارهای زرد برای برجسته‌کردن آن‌ها است. من همچنین رویدادهای محوری را بزرگ‌تر و سیاه می‌کنم تا وقتی از راه دور کار می‌کنم،کاملا مشخص باشد.انتخاب رویدادهای محوری یک علم دقیق نیست، اما افراد اغلب هنگام شناسایی آن‌ها به دنبال دقت و کمال هستند. مهم‌ترین چیز این است که جدول زمانی را به حدود 5 تا 10 بخش کوچک‌تر تقسیم کنید تا رویدادها راحت‌تر مرتب شوند. توضیح ساده من برای شناسایی رویدادهای محوری این است که به دنبال یک نقطه انتقال باشید، مانند شروع یا پایان یک فرآیند یا زیرفرآیند. برخی مثال‌ها شامل "درخواست عضویت"، "تیکت پشتیبانی ایجاد شد"، "حساب غیرفعال شد"، و "خبر منتشر شد" است. یک راه برای بررسی اینکه آیا رویدادهای محوری مناسبی دارید این است که بپرسید: آیا رویدادهای محوری به تنهایی داستان سطح بالای دامنه را بیان می‌کنند؟همچنین ممکن است یک رویدادگردانی را با استفاده از swimlaneها مرتب کنید. با این حال، این رویکردی نیست که اغلب به عنوان راهکار اصلی استفاده کنم زیرا می‌تواند خیلی محدودکننده باشد، اما می‌تواند انتخاب خوبی باشد وقتی دامنه شامل تعاملات پیچیده رفت و برگشتی بین چندین بازیگر است یا به عنوان راهکاری جانبی برای مرتب سازی از این تکنیک استفاده کنیم.همان‌طور که در شکل زیر نشان داده شده است، نقاط عطف زمانی (Temporal Event) رویکرد دیگری است که در آن جدول زمانی بر اساس لحظات خاص تقسیم می‌شود. به عنوان مثال، من یک جلسه Event Storming برای یک شرکت فناوری مدیریت همایش که نرم افزاری برای مدیریت آنلاین همایش ها ارائه می‌کرد، اجرا کردم. ما نقاط عطف زمانی مانند روز شروع دریافت مقالات،شروع داولی مقالات، شروع بلیط فروشی، یک هفته قبل از همایش، روز همایش، فردای همایش، یک ماه بعد از برگزاری همایش و غیره را بر اساس نقاط عطفی که بیشترین اهمیت را برای متخصصان دامنه داشتند، اضافه کردیم.3.6. مرور جدول زمانی:پس از اینکه جدول زمانی به طور منطقی مرتب شد، کل گروه دور هم جمع می‌شوند و جدول زمانی را مرور می‌کنند. این مرور زمانی است که افراد شروع به دیدن تصویر بزرگ و نحوه‌ی تأثیر بخش‌های مختلف کسب‌وکار بر یکدیگر می‌کنند. این زمانی است که افراد چیزهای زیادی در مورد بخش‌هایی از شرکت که با آن‌ها آشنا نیستند، یاد می‌گیرند. به عنوان تسهیل‌کننده، من از یک شرکت‌کننده می‌خواهم داوطلب شود تا جدول زمانی را مرور کند. وقتی این کار را انجام می‌دهند، رویدادهای روی جدول زمانی را مانند یک داستان می‌خوانند در حالی که از چپ به راست در طول جدول زمانی راه می‌روند. سوالات از شرکت‌کنندگان و تسهیل‌کننده در هر زمان مجاز است.هنگام مرور جدول زمانی، هدف این نیست که در مورد هر مشکل یا فرصت توقف و بحث کنید. هدف اول این است که داستان را از ابتدا تا انتها بیان کنید تا همه بتوانند تصویر بزرگ را ببینند و دوم این است که تمام مکالمات جالب ممکن را شناسایی کنید. بنابراین، در این مرحله می‌توانید از نقاط حساس به عنوان یک نگه‌دارنده استفاده کنید، همان‌طور که در شکل زیر نشان داده شده است (نقاط حساس می‌توانند نگه‌دارنده‌ و ارجاع دهنده‌هایی برای هر چیزی که می‌خواهید به آن بازگردید، مانند مشکلات، بخش‌های پیچیده، اختلافات و غیره باشند). هر زمان که یک مکالمه در مورد یک منطقه خاص از جدول زمانی بیش از 2 دقیقه طول بکشد، به گروه اطلاع دهید که یک نقطه حساس قرار می‌دهید و به حرکت در طول جدول زمانی ادامه می‌دهید.همان‌طور که در حال مرور جدول زمانی و بیان داستان کسب‌وکار هستید، ممکن است بخواهید رویدادها را اضافه و اصلاح کنید یا به اضافه کردن نمادهای اضافی مانند سیستم‌ها و نقش‌ها ادامه دهید. همچنین تمرین خوبی است که اصطلاحات مهم یا گیج‌کننده صنعت را تعریف کنید، همان‌طور که در شکل زیر نشان داده شده است. برای جلسات حضوری، می‌توانید از یادداشت‌های چسبنده بزرگ زرد یا برگه‌های کوچک کاغذ برای تعاریف اصطلاحات استفاده کنید.4. شناسایی مشکلات و فرصت‌ها: برای رهبران مدرن‌سازی، درک بیشتر از نحوه عملکرد سیستم فعلی ضروری است. شناسایی مشکلات و فرصت‌های موجود در محیط، برای اطمینان از اینکه مدرن‌سازی ارزش‌هایی بیش از بازنویسی سیستم قدیمی با فناوری‌های جدید ارائه می‌دهد، مهم است. پس از ساخت و مرتب‌کردن جدول زمانی با حضور بسیاری از افراد کلیدی، فرصتی عالی برای شناسایی این بینش‌ها است. در حال حاضر برخی نقاط حساس روی جدول زمانی از مرور وجود خواهد داشت. اما قبل از رای‌گیری در مورد اینکه کدام یک از آن‌ها را بررسی کنید، خوب است که به شرکت‌کنندگان 5 تا 10 دقیقه فرصت دهید تا مشکلات و فرصت‌های خود را با استفاده از همان نماد نقطه داغ برای مشکلات و یادداشت‌های چسبنده سبز برای فرصت‌ها اضافه کنند.یک چیزی که همیشه در مورد این بخش از کارگاه قدردانی می‌کنم این است که همه ایده‌های عالی دارند. افرادی که ممکن است آن‌ها را فنی برچسب بزنیم، مانند توسعه‌دهندگان، تسترها و معماران، اغلب برخی از بهترین ایده‌های کسب‌وکار و محصول را دارند. بر این اساس، به عنوان یک تسهیل‌کننده، حیاتی است که همه را تشویق کنید تا ایده‌های خود را به اشتراک بگذارند، صرف نظر از نقش آن‌ها. وقتی به سمت یک مدل عملیاتی متمرکز بر محصول حرکت می‌کنیم، کل تیم مسئول کشف و تحویل هستند. بنابراین، این لحظه فرصتی عالی برای تشویق و الگوبرداری از این رفتارهای فرهنگی مطلوب است.4.1. مشکلات: هیچ محدودیتی در نوع مشکلاتی که می‌توانند در جلسه Event Storming مطرح شوند، وجود ندارد. هر چیزی که بر مشتری، کارمندان، محصول، فرآیندهای داخلی، فرهنگ شرکت، قابلیت اطمینان سیستم یا رضایت شغلی تأثیر منفی بگذارد، ممکن است ارزش برجسته‌کردن داشته باشد. این بخش به برخی مثال‌های رایج اشاره می‌کند تا به شما ایده‌ای از آنچه انتظار دارید، بدهد.4.1.1. کاربران از یک جریان خارج می‌شوند:کاربران از یک جریان خارج می‌شوند چیزی است که من همیشه به دنبال آن هستم زیرا این اغلب جایی است که چیزی در مورد محصول بهینه‌سازی نشده است، و کسب‌وکار در حال از دست دادن درآمد بالقوه است. رویدادهایی مانند "سبد خرید منقضی شد"، "مشتری به رقیب تغییر کرد"، و "طرح ماهانه لغو شد"، همگی مثال‌هایی از یک مشتری هستند که از برخی خطوط لوله خارج می‌شوند، جایی که ممکن است ارزش داشته باشد عمیق‌تر شویم و بفهمیم چرا این اتفاقات رخ داده و چگونه می‌توان از آن‌ها جلوگیری کرد.4.1.2. نارضایتی کاربر:نارضایتی کاربر به طور کلی چیزی است که همیشه باید به دنبال آن باشید. کدام بخش‌های تجربه آن‌ها در تعامل با محصولات و سازمان شما باعث بیشترین استرس، ناامیدی و خشم می‌شود؟ شاید محصول آن‌ها را مجبور کند که برای انجام یک کار ساده از موانع زیادی عبور کنند، یا گردش کار پشتیبانی مشتری بین چندین نماینده پرش کند، به آن‌ها اطلاعات متناقض بدهد. چندین نفر که نیازهای کاربران را درک می‌کنند، مانند مدیران محصول، محققان UX و نمایندگان پشتیبانی، برای کشف نارضایتی واقعی کاربر ضروری هستند. هنگام ساخت محصولات داخلی، باید خود کاربران را به کارگاه‌ها دعوت کنید تا تجربیات دست اول آن‌ها را دریافت کنید.معمولاً چندین دیدگاه برای بررسی راه‌های مقابله با نارضایتی کاربر وجود دارد. از یک طرف، چگونه می‌توانید از وقوع مشکل جلوگیری کنید؟ و از طرف دیگر، اگر نمی‌توانید کاملاً از آن جلوگیری کنید، چگونه می‌توانید مشکلات ایجاد شده را هنگام وقوع کاهش دهید؟ یک شرکت، ایده تشویق کاربران برای علامت‌گذاری داده‌های نادرست را ارائه داد. اینکار به جلوگیری از مشکلات آینده کمک کرد و با نشان دادن تلاش برای حل مشکلات به کاربران، به مقابله با نارضایتی آن‌ها کمک کرد.4.1.3. فناوری غیرقابل اعتماد:در برخی دامنه‌ها، فناوری منبع اصلی مشکلات است، از سیستم‌های غیرقابل اعتمادی که به تجربه کاربری ضعیف کمک می‌کنند تا سیستم‌های IoT که در آن دستگاه‌ها می‌توانند ناگهان آفلاین شوند یا شروع به رفتار غیرعادی کنند. وقتی من با یک شرکت بیمه کار می‌کردم، یکی از همکاران که مسئول پیکربندی ساختار نرم افزار بود توضیح داد که چگونه باید رکوردهایی را در یک سیستم ایجاد کند و سپس شناسه تولید شده توسط سیستم را در سیستم دیگری کپی کند تا بتواند جنبه‌های بخش دیگری را پیکر بندی کند. همان‌طور که احتمالاً می‌توانید حدس بزنید، طیف وسیعی از مشکلات ناشی از یک خطای انسانی ناخواسته تا سیستم‌هایی که به درستی همگام‌سازی نمی‌شدند، به وجود آمد. این نشان می‌دهد که چرا مهم است که وارد جزئیات سیستم‌های مختلف شوید. اضافه کردن برخی از یادداشت‌های چسبنده بزرگ صورتی به جدول زمانی ممکن است مکالمات ارزشمندی درباره فرصت‌های کلیدی مدرنیزه‌سازی فناوری باز کند.4.1.4. دانش گم‌شده و مورد اختلاف: دانش — هم گم‌شده و هم مورد اختلاف — منبع اصلی دیگری از مشکلات است. در یک جلسه Event Storming که اجرا کردم، هیچ‌کس نمی‌دانست که محصول چگونه فراتر از UI کار می‌کند زیرا تمام توسعه‌دهندگانی که روی آن بخش از سیستم کار می‌کردند، شرکت را ترک کرده بودند. معمولاً مشکلات اینقدر شدید نیست، اما کمبود دانش رایج است و ارزش برجسته‌کردن دارد.دانش مورد اختلاف وقتی افراد در مورد حقایق اختلاف نظر دارند می‌تواند حتی جالب‌تر نیز باشد. زمانی، یک کارگاه برای یک شرکت در صنعت پخش مویرگی اجرا کردم، و پرسیدم، "اعتبار خرید نسیه چگونه محاسبه می‌شود؟" یک توسعه‌دهنده برای توضیح الگوریتم پیش قدم شد، اما سپس مدیر بازاریابی حرف او را رد کرد. توسعه‌دهنده لپ‌تاپ خود را باز کرد تا تأیید کند که کد چگونه کار می‌کند، و مدیر بازاریابی شوکه شد که متوجه شد چرا گزارش‌های آن‌ها معنی‌دار نبودند. آن‌ها مدتی بود که این سوءتفاهم را داشتند اما به جای اینکه این مسئله را مرتفع کنند آن‌ها را نادیده گرفته و بر اساس آن‌ها تصمیم نیز می‌گرفتند.4.2. فرصت‌ها: هر مشکلی می‌تواند منجر به فرصت‌ شود، اما بسیاری از انواع فرصت‌ها حتی وقتی همه چیز به خوبی یا همان‌طور که انتظار می‌رود کار می‌کند، می‌توانند پیدا شوند. به عنوان مثال، در طول یک جلسه رویدادگردانی، یک سوال خوب که می‌تواند به یافتن بهبودها کمک کند این است که بپرسید، "چگونه می‌توانیم از این اتفاق زودتر سود ببریم؟". 4.2.1. هدف‌گیری بخش‌های جدید مشتری: مدرن‌سازی یک سرمایه‌گذاری است که شرکت را برای رشد و نوآوری موقعیت‌دهی می‌کند. یک نوع فرصتی که باید به دنبال آن باشید، گسترش TAM (بازار قابل دسترسی کل) محصولات و خدمات شما است. همان‌طور که در Event Storming قدم می‌زنید، بپرسید، "کدام مشتریانی که در حال حاضر جذب نمی‌کنیم ممکن است به این خدمت یا کالا علاقه‌مند باشند؟" یا "چقدر باید این بخش از سیستم را تغییر یا تطبیق دهیم تا برای انواع مختلف مشتریان جذاب باشد؟" به عنوان مثال، اگر محصول B2C است، آیا می‌توان آن را برای B2B نیز تطبیق داد؟ 4.2.2. استفاده بهتر از داده‌ها: موضوع رایجی که در جلسات Event Storming با آن مواجه خواهید شد، داده‌ها است. شما نظراتی مانند "اگر می‌توانستیم اطلاعات بیشتری از این اطلاعات را ثبت کنیم، می‌توانستیم از آن برای انجام <چیزی> بسیار بهتر استفاده کنیم"، یا "ما داده‌های زیادی ثبت می‌کنیم، و کارهای بسیار بیشتری وجود دارد که می‌توانیم با آن‌ها انجام دهیم" خواهید شنید. به عنوان یک تسهیل‌کننده، می‌توانید آگاهی را به این موضوعات بیاورید و از افراد بخواهید فرصت‌هایی را در طول جدول زمانی اضافه کنند که فکر می‌کنند داده‌های مفیدتری می‌توانند ثبت یا اعمال شوند. در یک جلسه با یک سازمان بهداشتی، ما در مورد اینکه برخی پزشکان شرکای مشکل‌سازی بودند به دلیل عدم پاسخگویی آن‌ها بحث می‌کردیم. یکی از مهندسان اشاره کرد که سازمان قبلاً اطلاعات زیادی دارد و می‌تواند به راحتی شروع به اندازه‌گیری عملکرد پزشکان و توصیه به مشتریان در مورد پاسخگوترین پزشکان در منطقه خود کند. مشکل این بود که داده‌ها در سیستم‌های قدیمی و پایگاه‌های داده مختلف پراکنده بودند.4.2.3. افزایش مشارکت:در برخی دامنه‌ها، بررسی فرصت‌هایی برای افزایش مشارکت مشتری می‌تواند ارزشمند باشد. وقتی با یک شرکت سفر کار می‌کردم، آن‌ها توضیح دادند که فصلی بودن یک مشکل بزرگ است. مردم یک بار در سال یک تعطیلات رزرو می‌کنند، و برای بقیه سال مشارکت کمی یا هیچ مشارکتی وجود ندارد. شرکت سفر به دنبال راه‌هایی برای افزایش مشارکت سالانه با مشتری بود، مانند نوشتن محتوای مفید برای ایجاد ارتباطات و وفاداری قوی‌تر با مشتریان خود. Event Storming، با رویکرد مبتنی بر جدول زمانی خود، زمینه خوبی برای این مکالمات فراهم می‌کند. به عنوان مثال، بین هر تعامل مشتری، می‌توانید این سوال را بپرسید: "آیا راه‌هایی وجود دارد که بتوانیم در این فاصله با مشتری مشارکت کنیم؟"4.3.3. استفاده از فناوری‌های جدید: همان‌طور که در مطلب مرتبط با واردلی مپینگ دیدیم، محیط‌ها به طور مداوم در حال تکامل هستند. در طول یک جلسه Event Storming، مهم است که چگونگی تکامل محیط را در نظر گرفته و چه فرصت‌های جدیدی ممکن است با این تغییر در دسترس باشد. اینکار می‌تواند به شکل پیشرفت‌های فناوری جدید یا محصولات جدید SaaS باشد که وارد بازار شده‌اند. همیشه ارزش دارد که هر بخش از جدول زمانی را به چالش بکشید و بپرسید: "آیا محیط اطراف این رویداد تغییر کرده است؟ آیا امکان‌های جدیدی وجود دارد که در زمان طراحی این بخش از سیستم در دسترس نبوده است؟"4.3.4. رسیدگی به مشکلات و فرصت‌ها:در بیشتر موارد، تعداد زیادی مشکل و فرصت کشف خواهید کرد. شما زمان کافی برای رسیدگی به همه آن‌ها در طول جلسه نخواهید داشت، بنابراین باید به عنوان یک گروه تصمیم بگیرید که بهترین استفاده از زمان خود را چگونه انجام دهید. رویکرد پیش‌فرض رای‌گیری نقطه‌ای است، جایی که هر فرد تعداد مشخصی رای برای قرار دادن در کنار نقاط بحث که فکر می‌کنند مهم‌ترین هستند، دریافت می‌کند. در برخی موارد،زمانی که کارگاه هدف خاصی دارد و ذینفع بیشترین درک را از مسائلی که باید پوشش داده شود دارد، ذینفع کلیدی ممکن است تعیین کند که کجا تمرکز شود.برای هر موضوعی که نمی‌توان در طول جلسه به آن رسیدگی کرد، چندین امکان پیگیری وجود دارد، از جمله:سازماندهی کارگاه‌های Big Picture بیشتر با محدوده‌ی یک منطقه خاص. گذراندن زمان با کاربران برای درک کامل تجربه آن‌ها. Event Storming عالی است، اما گاهی اوقات بهترین راه برای یادگیری در مورد دامنه و فرصت‌های آن، گذراندن زمان با افرادی است که در آن کار می‌کنند. برنامه‌ریزی جلسات مدل‌سازی فرآیند با کمک Event Storming برای طراحی فرآیندهای جدید و آینده. برنامه‌ریزی کارگاه‌ها برای تأیید مرزهای دامنه (با استفاده از تکنیک‌های پوشش داده شده در قسمت‌های بعدی). پس از بحث در مورد فرمت کارگاه‌ها و اینکه چگونه یک Event Storming پایه عالی برای کشف مشکلات و فرصت‌ها است، مهم است که کارگاه‌ها را به طور مؤثر تسهیل کنید تا پتانسیل این مفاهیم را باز کنید، که موضوع بخش بعدی است.4. نکات و چالش‌های تسهیل‌کننده: چسباندن یادداشت‌های چسبنده روی دیوار در یک جدول زمانی تقریبی بسیار ساده به نظر می‌رسد، اما هر چه بیشتر Event Storming را تمرین کنید، بیشتر یاد می‌گیرید که چگونه از هر جلسه مزایایی استخراج کنید. منحنی یادگیری برای شرکت‌کنندگان به طور عمدی کوتاه است، اما به عنوان یک تسهیل‌کننده، منحنی یادگیری تقریباً بی‌نهایت است. هیچ چیز جای تمرین را نمی‌گیرد، اما نکات و ترفندهای زیر به شما کمک می‌کند تا زمان یادگیری خود را تسریع کنید و از مشکلات رایج مبتدیان اجتناب کنید.4.1. اکتشافات مدل‌سازی: کیفیت رویدادهای قرار داده شده روی جدول زمانی می‌تواند تأثیر زیادی بر بینش‌های به دست آمده و مشکلات و فرصت‌های کشف شده داشته باشد. رویدادهای خوب افراد را به پرسیدن سوالات جالب وادار می‌کنند و اجازه می‌دهند دانش افراد مختلف به یک دیدگاه جمعی از نحوه عملکرد کسب‌وکار متصل شود.همان‌طور که در طول این قسمت اشاره شد، هیچ قانون، فرآیند یا نمودار جریانی سخت‌گیرانه‌ای وجود ندارد که به شما کمک کند تعیین کنید چه چیزی یک رویداد خوب است. و احتمالاً مفید هم نخواهد بود زیرا ایده این است که تعداد ایده‌های به اشتراک گذاشته شده را به حداکثر برسانید و سپس آنچه مفید نیست را فیلتر کنید، نه اینکه اطلاعات مهم به دلیل نگرانی افراد از شکستن قوانین به اشتراک گذاشته نشود. با این حال، برخی هیوریستیک‌ها می‌توانند شما را در مسیر درست هدایت کنند بدون اینکه به مشارکت آسیب بزنند، و تمرکز این بخش است. فقط به یاد داشته باشید که آن‌ها را خیلی مشتاقانه در ابتدای یک کارگاه اعمال نکنید تا مطمئن شوید که افراد را ناراحت نمی‌کنید و آن‌ها را از این تکنیک جدید دور نمی‌کنید.4.1.1. مراقب انتزاع بیش از حد باشید: وقتی رویدادهای دامنه اطلاعات زیادی را انتزاع می‌کنند، تفاوت‌های ظریف و مهم دامنه را پنهان می‌کنند. تصویر بعد دنباله‌ای از رویدادها را نشان می‌دهد که به نظر می‌رسد رویدادهای دامنه خوبی هستند. آن‌ها روی یادداشت‌های چسبنده نارنجی هستند، به زمان گذشته بیان شده‌اند، و آنچه در دامنه اتفاق می‌افتد را توضیح می‌دهند تا اینکه خیلی فنی باشند، مانند کلیک‌های دکمه و تراکنش‌های پایگاه داده. با این حال، مقدار زیادی پیچیدگی توسط فقط چهار رویداد نشان داده شده است. در این سطح جزئیات چیز کمی برای یادگیری وجود دارد. چگونه می‌توانیم فرصت‌هایی برای بهبود فرآیندهای ثبت‌نام، اشتراک یا ایجاد کمپین‌ها شناسایی کنیم اگر هر کدام توسط یک یادداشت چسبنده پوشش داده شده است؟محدوده کارگاه روی این که چه چیزی خیلی سطح بالا در نظر گرفته شود و چه چیزی معقول باشد، و احتمالاً امکان ندارد که در هر بخش از دامنه به عمق جزئیات برویم تأثیر می‌گذارد. تصمیم‌گیری در مورد اینکه گروه باید و نباید روی کجا تمرکز کند، یکی از مهم‌ترین مهارت‌ها به عنوان یک تسهیل‌کننده است و متأسفانه یکی از سخت‌ترین‌ها برای تسلط.4.1.2. مدل نکنید؛ یک داستان بگویید: برای جبران رویدادهای بیش از حد انتزاعی، یک هیوریستیک مفید برای به خاطر سپردن این است که "مدل نکنید؛ یک داستان بگویید." این جمله کلیشه‌ای به معنای پذیرش جزئیات و مشخصات و عدم تلاش برای ایجاد مدل‌های انتزاعی است که تمام موارد استفاده را پوشش می‌دهد. ما ممکن است یک شخصیت تعریف کنیم و به طور خاص‌تر آنچه را که آن‌ها می‌بینند و انجام می‌دهند در سطح جزئیات بیشتری توصیف کنیم. برای مهندسان و معمارانی که از مدل‌سازی لذت می‌برند، این ممکن است غیرطبیعی به نظر برسد. اما توانایی تغییر بین مشخصات و مدل‌های انتزاعی در زمان‌های مناسب مهم است.4.1.3. تکرار واگرایی: وقتی واگرایی در دامنه بر اساس برخی ویژگی‌ها شناسایی می‌کنید، ایده خوبی است که به دنبال واگرایی‌های مشابه در طول جدول زمانی باشید. در شکل زیر، جدول زمانی ابتدا بر اساس اینکه تبلیغ‌کننده برای یک استارت‌آپ یا یک شرکت بزرگ کار می‌کند، واگرا می‌شود. پس از مرحله ثبت‌نام، جدول زمانی ممکن است همگرا شود و تجربه در برخی مکان‌ها مشابه باشد، اما نوع تبلیغ‌کننده ممکن است دلیلی برای واگرایی‌های بعدی در جریان باشد.4.1.4. کنجکاو مفاهیم معرفی نشده باشید: وقتی یک مفهوم جدید ناگهان در جدول زمانی ظاهر می‌شود، ممکن است نشانه‌ای باشد که بخش‌هایی از دامنه نمایش داده نشده‌اند. به عنوان مثال، نقش یک متخصص در دامنه در رویداد "کمک متخصص ارائه شد" ظاهر می‌شود. اگر این اولین باری است که این مفهوم در جدول زمانی ظاهر می‌شود، خوب است که برخی سوالات کاوش‌کننده مانند "چگونه یک متخصص در این لحظه در دسترس می‌شود؟" یا "می‌توانید داستان یک متخصص را توصیف کنید؟" بپرسید. با اضافه کردن داستان متخصص به جدول زمانی، ممکن است بینش‌ها و فرصت‌های جدیدی را آشکار کند که افراد فکر می‌کردند بی‌ربط هستند. کشف همه چیز در مورد کاوش راه‌های جدید و به چالش کشیدن فرضیات است.4.1.5. رویدادهای با نام یکسان را واجد شرایط کنید:گاهی اوقات رویدادهایی وجود دارند که در چندین مکان در جدول زمانی ظاهر می‌شوند. در ابتدا ممکن است به نظر برسد که همان رویداد است، اما خطر این وجود دارد که تفاوت ظریفی بین رویدادها وجود داشته باشد که پنهان است. یک سوال تسهیل‌کننده خوب این است: "آیا همان چیزها می‌توانند بعد از هر رویداد اتفاق بیفتند؟". ممکن است وسواسی یا آکادمیک به نظر برسد، اما روشن‌سازی و پاک‌سازی اصطلاحات دامنه برای ایجاد یک زبان مشترک، همکاری را بسیار آسان‌تر می‌کند.4.1.6. رویدادهای مشابه که به نظر یکسان هستند را نگه دارید:گاهی اوقات ممکن است به نظر برسد که چندین رویداد نمایانگر همان چیز هستند، و ممکن است وسوسه شوید که یکی را نگه دارید و دیگری را دور بیندازید. با این حال، قبل از انجام این کار، ارزش دارد که عمیق‌تر شوید. ممکن است این دو رویداد نمایانگر چیزهای کمی متفاوت یا همان رویداد از دیدگاه‌های مختلف افراد باشند. دو رویدادی که به نظر یکسان می‌رسند حتی ممکن است نشانه‌ای از مرزهای دامنه باشند. به عنوان مثال، رویدادهای "پیام ارسال شد" و "پیام دریافت شد" را در نظر بگیرید. ممکن است به نظر برسد که آن‌ها در همان زمان دقیق اتفاق می‌افتند و نمایانگر دو دیدگاه از همان چیز هستند. با این حال، آن‌ها می‌توانند هر طرف مرز بین دو زیردامنه مانند "ترکیب پیام" و "مشاهده پیام" را نشان دهند. این یک مثال از یک هیوریستیک کلی‌تر است، "تعارض را قابل مشاهده کنید." شما همیشه نیازی به عجله برای یافتن یک راه‌حل ندارید؛ گاهی اوقات خوب است که نظرات متضاد را تجسم کنید و اجازه دهید مدتی بمانند.4.1.7. از فضای خالی به طور هدفمند استفاده کنید: به عنوان یک تسهیل‌کننده، می‌توانید از فضای سفید برای تشویق شرکت‌کنندگان به پیشروی عمیق‌تر به جزئیات استفاده کنید. اگر احساس می‌کنید که رویدادها سطح بالا و بیش از حد انتزاعی هستند، می‌توانید دو رویداد را با هم بگیرید، آن‌ها را گسترش دهید، و به گروه اطلاع دهید که می‌خواهید شکاف را با رویدادهای بیشتری در سطح ریز یا درشت دانگی بیشتر پر کنند.4.1.8. ترکیب Example Mapping و Event Storming: تکنیک Example Mapping یک تکنیک مشارکتی است که برای کشف سناریوها و موارد لبه‌ای مختلف استفاده می‌شود. وقتی با Event Storming ترکیب شود، راهی عالی برای زوم کردن روی مناطق خاص دامنه و جستجوی بینش‌ها و پیچیدگی‌های پنهان در سطح ریزدانگی بالاتر است. این تکنیک مانند گرفتن یک ذره‌بین به یک منطقه کوچک از دامنه است.تکنیک Example Mapping با طعم Event Storming با انتخاب یک رویداد روی جدول زمانی شروع می‌شود و سپس یک عمل را مشخص می‌کند، با استفاده از یک یادداشت چسبنده آبی، که رویداد را تحریک می‌کند. به عنوان مثال، رویداد "سفارش لغو شد" ممکن است توسط عمل "لغو سفارش" تحریک شود. سپس، هدف این است که به سناریوهای دیگری فکر کنید که می‌توانند هنگام انجام عمل اعمال شوند. به عنوان مثال، اگر یک مشتری درخواست بازپرداخت برای سفارشی که قبلاً از انبار خارج شده است، کند، سپس یک "لغو رد شد" اتفاق می‌افتد. همان‌طور که شکل نشان می‌دهد، سناریوها به عنوان یادداشت‌های چسبنده سبز بین عمل و رویدادی که در سناریوی داده شده اتفاق می‌افتد، وارد می‌شوند.وقتی به حالت Example Mapping تغییر می‌کند، همیشه سعی می‌کنم شرکت‌کنندگان را تشویق کنم که تا حد امکان به سناریوها فکر کنند و خلاق باشند، خارج از چارچوب فکر کنند. همان‌طور که سناریوهای بیشتری کشف می‌کنید، ممکن است متوجه شوید که منطقی است که آن‌ها را تقسیم کنید و برخی مفاهیم را صریح‌تر کنید.4.2. چالش‌های رایج :تسهیل جلسات رویدادگردانی می‌تواند چالش‌برانگیز باشد. از وارد کردن افراد به ذهنیت درست تا برخورد با افراد دشوار که از همکاری امتناع می‌کنند، بیشتر چالش‌ها مربوط به افراد هستند. این بخش برخی از چالش‌های رایجی که احتمالاً با آن‌ها مواجه خواهید شد و برخی نکات برای برخورد مؤثر با آن‌ها را بیان می‌کنم.4.2.1. وارد کردن شرکت‌کنندگان به ذهنیت کشف چیزی که اغلب هنگام برنامه‌ریزی Event Storming و سایر کارگاه‌های کشف نادیده گرفته می‌شود، نیاز به ایجاد محیطی است که شرکت‌کنندگان بتوانند ذهنیت خلاقانه کشف مورد نیاز را بپذیرند. وقتی افراد تحت فشار برای تحویل هستند، به ویژه با مهلت‌های فوری، چالش بزرگی برای آن‌ها است که آن را به پشت ذهن خود نگهداشته و ساعت‌ها یا روزها را صرف نقشه‌برداری از فرآیندهای کسب‌وکار کنند در حالی که احساس می‌کنند هیچ پیشرفت فوری در اهداف کوتاه‌مدت حاصل نشده است.برای یک جلسه مؤثر، رهبران باید اطمینان حاصل کنند که کار کشف به طور مناسب اولویت‌بندی شده است و فقط یک تعهد اضافی نیست که افراد انتظار دارند علاوه بر تمام تعهدات دیگر خود انجام دهند. ضرری ندارد که قبل از زمان جلسه با شرکت‌کنندگان کارگاه تماس بگیرید تا اطمینان حاصل کنید که آن‌ها از قبل بیش از حد متعهد نیستند. در غیر این صورت، وقتی در کارگاه شرکت می‌کنند، ذهن آن‌ها بیش از حد روی اولویت‌های دیگر متمرکز خواهد بود، و احتمالاً چندوظیفه‌ای نیز خواهند بود. برای اینکه یک جلسه Event Storming مؤثر باشد، واقعاً می‌خواهید همه کاملاً درگیر و هیجان‌زده برای به اشتراک گذاشتن دانش خود از کسب‌وکار و یادگیری از دیگران باشند.4.2.2. اجتناب از bikeshedding: به پدیده صرف زمان زیاد برای بحث در مورد جزئیاتی که در طرح کلی چیزها واقعاً مهم نیستند،bikeshedding نام دارد. bikeshedding باعث یکی از بزرگترین شکست‌های Event Storming من شد، جایی که یک مدیر عصبانی در مقابل تیم خود به من فریاد زد. ما شروع به راه رفتن در جدول زمانی کردیم، و گروه زمان زیادی را صرف بحث در مورد فرآیند ثبت‌نام کرد. من فکر می‌کردم همه چیز عالی پیش می‌رود زیرا بحث‌های زیادی وجود داشت. اما من دلیل عصبانیت مدیر را درک می‌کنم: فرآیند ثبت‌نام واقعاً آنقدر مهم نبود. در یک کارگاه که همه برای فقط چند روز دور هم جمع شده بودند تا در مورد مشکلات بزرگ‌تر بحث کنند، چیزهای مهم‌تری در زمان محدود وجود داشت که باید روی آن‌ها تمرکز می‌کردیم.برای به حداقل رساندن شانس تکرار اشتباه من، اجازه ندهید در جلسات Event Storming هیچ مکالمه‌ای بیش از چند دقیقه طول بکشد. سعی کنید قبل از اینکه خیلی عمیق به یک منطقه بپردازید، به انتهای جدول زمانی برسید. اگر واقعاً مهم‌ترین چیزی است که باید در مورد آن صحبت کنید، گروه از طریق رای‌گیری تصمیم می‌گیرد که پس از رسیدن به انتهای جدول زمانی به آن بازگردند.4.3.3.ما قبلاً نمودارهای این را داریم:برخی افراد با ایده Event Storming مخالفت می‌کنند زیرا فکر می‌کنند که زائد است. آن‌ها قبلاً نمودارهایی در برخی فرمت‌های دیگر مانند UML یا BPMN ایجاد کرده‌اند. در یک کارگاه، یک مهندس فرآیند گفت: "من نمودارهایی از تمام این فرآیندها دارم؛ من دلیلی برای این کارگاه را نمی‌بینم" و در طول کارگاه به این موضوع ادامه داد. یکی از کارمندان که در منطقه‌ای که نمودارها برای آن ایجاد شده بود کار می‌کرد، گفت: "خوب، آن‌ها کجا هستند؟ ما هرگز آن‌ها را ندیده‌ایم." مهندس فرآیند سپس اعتراف کرد که نمودارها در مقایسه با آنچه تاکنون در کارگاه کشف کرده‌ایم، قدیمی هستند، همان موضوعی که در قسمت بازبینی مستندات به طور مشروح به آن پرداختیم.گاهی اوقات یک برخورد فرهنگی اتفاق می‌افتد که افراد فکر می‌کنند Event Storming به خوبی ابزارهای موجود آن‌ها نیست. من سعی می‌کنم با این افراد به طور منطقی صحبت کنم و آن‌ها را به کارگاه‌ها دعوت کنم، اما اگر رفتار آن‌ها در طول کارگاه مشکل‌ساز شود، باید حذف شوند. با این حال، گاهی اوقات مشکل عمیق‌تر است، و افراد فکر می‌کنند که انتظار می‌رود آن‌ها متخصص فرآیندهای شرکت باشند. جلسه Event Storming بعضا باعث نگرانی است زیرا ممکن است چیزهایی را آشکار کند که متخصص نمی‌داند، یا متخصص دوست دارد دانش را برای محافظت از موقعیت خود در شرکت نزد خود نگه دارد. این یک موقعیت اجتماعی بسیار پیچیده‌تر است؛ نحوه برخورد با آن به رابطه شما با افراد درگیر و فرهنگ شرکت شما بستگی دارد.4.3.4. نمی‌توان همه چیز را در یک کارگاه دو روزه حل کرد: گاهی اوقات افراد ناامید می‌شوند که در پایان یک کارگاه دو روزه کل سیستم خود را دوباره طراحی نکرده‌اند و توپولوژی‌های تیم جدید طراحی نکرده‌اند. این انتظارات غیرواقع‌بینانه است، بنابراین مهم است که بیش از حد وعده ندهید یا بیش از حد Event Storming را بزرگ نکنید. اطمینان حاصل کنید که انتظارات واقع‌بینانه در دعوت تنظیم شده و هنگام شروع جلسه تقویت شود.4.3.5. حضوری در مقابل از راه دور: وقتی همه‌گیری در اسفند ماه سال 98 شروع شد، بسیاری از متخصصان Event Storming به شدت به دنبال راه‌هایی برای اجرای جلسات Event Storming از راه دور بودند. تمرکز به شدت روی بازسازی تجربه جلسات حضوری تا حد امکان در محیط‌های مجازی بود. بسیاری ناامید شدند زیرا تجربه از راه دور بسیار متفاوت بود و بسیاری از مزایای حضوری، مانند مکالمات موازی و توانایی خواندن زبان بدن، را نداشت. در همین حال، دیگران در جامعه به دنبال راه‌هایی برای بهینه‌سازی تجربه رویدادگردانی آنلاین بودند، و آن‌ها از تمام انتظارات فراتر رفتند، نه با بازسازی آنچه در حضوری کار می‌کرد، بلکه با تمرکز بر نقاط قوت محیط‌های مجازی.جلسات رویدادگردانی حضوری نیاز دارند که همه در یک فضای فیزیکی باشند. در بسیاری از سازمان‌ها، اینکار مقدار زیادی هماهنگی می‌طلبد، و در برخی سازمان‌ها، تقریباً غیرممکن است. محدودیتِ بودن در یک فضای فیزیکی همچنین به این معنی است که یک سری کامل از کارگاه‌ها باید در یک دوره کوتاه زمانی که همه دور هم هستند، فشرده شود.اما در جلسات راه دور، این محدودیت‌ها وجود ندارند (اگرچه هنوز هم یافتن زمان مناسب که همه در دسترس باشند، دشوار است). ممکن است بسیاری از جلسات کوتاه‌تر را در یک دوره طولانی‌تر اجرا کنید. به عنوان مثال، اغلب جلسات 2 تا 4 ساعته را هنگام اجرای جلسات از راه دور ترجیح می‌دهم. این‌ها می‌توانند در طول هفته‌ها یا ماه‌ها پخش شوند، و پس از هر جلسه، فرصت‌هایی برای ارزیابی مجدد مراحل بعدی و دعوت از چه کسانی داریم.جلسات از راه دور همچنین از محدود نبودن به یادداشت‌های چسبنده فیزیکی سود می‌برند. در واقع، ابزارهای تخته سفید مجازی مانند Miro (اگر فیلترها و تحریم ها به ما اجازه کار کردن بدهند) به شما اجازه می‌دهند که بسیار بیان‌گرتر باشید، با انواع بیشتری از اشکال، رنگ‌ها، تصاویر و ایموجی‌ها برای بیان مفاهیم دامنه و احساسات افراد.مزیت بزرگ دیگری که هنگام اجرای جلسات مجازی داریم، توانایی کپی و چسباندن است. این امکان به شما اجازه می‌دهد که یک Event Storming کامل را کپی کنید و برای ادامه کار به گروه‌های کوچک تقسیم شوید، جایی که هر گروه یک کپی از Event Storming را برای کاوش و شکل‌دهی به مرزهای دامنه دریافت می‌کند.این‌ها چند مورد از نمونه‌های مورد علاقه من برای بهینه‌سازی تجربه کارگاه برای فرمت داده شده هستند. به شما پیشنهاد می‌کنم که به طور مداوم به راه‌هایی برای بهینه‌سازی هر یک از کارگاه‌های خود برای فرمتی که آن‌ها را در آن ارائه می‌دهید، فکر کنید.5. جمع بندی:اکنون به پایان این قسمت درباره Big Picture Event Storming رسیدیم. Event Storming یک تکنیک عالی برای نقشه‌برداری از دامنه‌ها، همسو کردن گروه‌های افراد و افزایش پتانسیل مدرن‌سازی است. در قسمت‌های بعدی، همچنین خواهید دید که Event Storming چگونه نقطه شروعی عالی برای شناسایی دامنه‌ها و زیردامنه‌ها است. به خاطر داشته باشید که Event Storming به تنهایی تمام نیازهای شما را پوشش نمی‌دهد. به عنوان مثال، در برخی شرایط خوب است که زمان را با کاربران واقعی بگذرانید، به یاد دارم که در کاری که در حوزه بیمه دیجیتال انجام میدادیم دو روز کامل از فصل سرد زمستان را در یکی از مراکز تعیین خسارت بیمه در مرکز شهر با کارشناسان شرکت بیمه و مراجعه کنندگان گفتگو کرده و وقت گذراندم— موضوع فصل بعدی که به مدرن‌سازی محصول و دامنه عمیق‌تر می‌پردازد. علیرضا ارومند علیرضا ارومند Sun, 06 Apr 2025 15:53:09 +0330 https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%87%D9%85-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%B7%D8%A8%D9%82%D9%87-%D8%A8%D9%86%D8%AF%DB%8C-%D9%85%D8%AD%D8%B5%D9%88%D9%84%D8%A7%D8%AA-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-ojea0zvxkjsq 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. مدرن‌سازی محصول و دامنه:مدرن‌سازی معماری فقط درباره بازنویسی سیستم قدیمی با فناوری‌های جدید یا حتی حرکت به سمت الگوها و ساختارهای جدید نیست؛ به همان اندازه درباره مدرن‌سازی محصول و دامنه برای ایجاد ارزش جدید از طریق بهبودهایی مانند:بازطراحی UXخودکارسازی مراحل فرآیند کسب‌وکاربازطراحی گردش کار همکارانشفاف‌سازی اصطلاحات مبهم دامنه برای کمک به صحبت کردن به یک زبان مشترکحذف ویژگی‌ها/پیچیدگی‌های غیرضروریاین فعالیت‌ها ممکن است شامل مقدار زیادی مکاشفات باشد — به عنوان مثال، جلسات تحقیقات کاربری، کارگاه‌های کشف، و نمونه‌سازی‌های زیاد. شناسایی بخش‌هایی از طبقه‌بندی که بیشترین بهره را از مدرنیزه‌سازی محصول و دامنه می‌برند، مفید است تا اطمینان حاصل شود که زمان کافی برای آماده‌سازی و انجام کشف مؤثر وجود دارد، به‌ویژه اگر پتانسیل بازدهی سرمایه (ROI) بالا وجود داشته باشد. اگر کشف محصول مشارکتی یک مفهوم جدید برای سازمان شما باشد، برجسته کردن این فرصت‌ها حتی مهم‌تر است زیرا به زمان بیشتری برای تطبیق با این رویکرد نیاز خواهید داشت.3.5. پیچیدگی و بار شناختی:همه بخش‌های یک سیستم به یک اندازه پیچیده نخواهند بود. برخی بخش‌ها شامل قوانین و گردش کار پیچیده‌تر کسب‌وکار یا چالش‌های مقیاس‌پذیری بالاتر هستند، یا ممکن است با فناوری‌های بسیار قدیمی نوشته شده باشند که نیاز به سرمایه‌گذاری بیشتری برای مدرن‌سازی دارند. تعیین این موضوع مهم است زیرا جایی که ریسک‌ها و چالش‌ها ممکن است به وجود آیند را برجسته می‌کند. همچنین مهم است زیرا کمک می‌کند اطمینان حاصل شود که یک تیم واحد مسئول چندین دامنه بسیار پیچیده نخواهد بود، که بار شناختی آن‌ها را بیش از حد افزایش می‌دهد.3.6. محدودیت‌ها و چالش‌های سطح کلان:سطح کلان به ساختار بزرگ‌مقیاس یک سازمان، سطح ۳ و بالاتر، اشاره دارد. تغییرات در این سطوح به طور بالقوه هزاران نفر را تحت تأثیر قرار می‌دهد، که آن‌ها را هم پر هزینه و هم پرریسک می‌کند. تصمیم‌گیری در این سطح معمولاً توسط رهبری ارشد برای دلایل استراتژیک عمده گرفته می‌شود، مانند زمانی که در سال ۲۰۱۵ گوگل به مجموعه‌ای از شرکت‌های جداگانه تحت مالکیت یک شرکت هلدینگ جدید به نام Alphabet تقسیم شد.در حالی که تصمیم‌گیری در سطوح بالاتر ممکن است خارج از محدوده مدرن‌سازی باشد، هنوز ارزش دارد که تصویر بزرگ‌تر و چگونگی محدود کردن مدرن‌سازی را درک کنید. حتی ممکن است فرصت‌هایی را کشف کنید که هیچ‌کس متوجه آن‌ها نشده بود.یکی از موضوعات سطح کلان که باید به آن توجه داشت، استفاده مجدد است. هنگامی که یک شرکت بزرگ دارای بسیاری از محصولات است و در بسیاری از بازارها فعال است، همیشه بحثی درباره اینکه چه چیزی را متمرکز کنند و چه چیزی را به هر بخش اجازه دهند تا خودشان بسازند، به وجود می‌آید. تصور کنید یک زنجیره فست‌فود جهانی که حول بازارهای منطقه‌ای سازماندهی شده است — به عنوان مثال، ایالات متحده، بریتانیا، سوئد و ژاپن — و این شرکت در بیش از ۱۰۰ کشور فعال است. شکل زیر یک تصمیم کلیدی معماری کسب‌وکار سطح کلان را برجسته می‌کند: آیا هربرش عمودی باید آزاد باشد تا قابلیت‌های خود مانند وفاداری و CRM را توسعه دهد، یا باید آن‌ها در یک برش افقی متمرکز شوند که توسط همه برش‌های عمودی‌ به اشتراک گذاشته می‌شود؟تعیین چگونگی شکل‌دهی به برش‌های عمودی‌ و افقی یک مشکل همه‌جایی و پیچیده با بسیاری از ریسک‌ها است. این یک موضوع بحث‌برانگیز در برخی شرکت‌ها است. برخی از ملاحظات کلیدی عبارتند از:تجربه کاربری: آیا معمول است که کاربران در چندین بخش عمودی فعال باشند؟ اگر چنین است، چگونه نیاز به یک تجربه کاربری سازگار در همه بخش‌های عمودی‌ را با یک تجربه کاربری بهینه‌شده در هر بخش عمودی متعادل می‌کنید؟اولویت‌بندی: چگونه کار در بخش‌های افقی‌ زمانی که چندین بخش عمودی درخواست ویژگی‌ها و بهبودهای جدید دارند، اولویت‌بندی می‌شود؟ نیازهای هر بخش عمودی چقدر خاص خواهد بود؟ چقدر تقاضای همزمان وجود خواهد داشت؟تأمین مالی: چگونه بودجه برای بخش‌های افقی‌‌ای که به طور مستقیم درآمد ایجاد نمی‌کنند و به‌عنوان مراکز هزینه در نظر گرفته می‌شوند، تعیین می‌شود؟وابستگی‌ها و پیچیدگی: آیا تعداد وابستگی‌ها و سطح دانش دامنه مورد نیاز باعث می‌شود تیم‌ها بار شناختی بیش از حد داشته باشند یا هماهنگی بیش از حد بین تیم‌ها ایجاد کنند؟ این یک عامل کلیدی در مدرن‌سازی بزرگ‌مقیاس Docker بود.کارایی در مقابل زمان ورود به بازار: آیا اجازه دادن به هر بخش عمودی برای پیاده‌سازی عملکردهای مشابه زمان ورود به بازار را کاهش می‌دهد؟ آیا هزینه‌های این تکرار از مزایای آن بیشتر است؟علاوه بر موارد فوق، 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. نتیجه گیری:انتقال به یک مدل عملیاتی محصول‌محور نیازمند تغییر عمیق در ساختار، فرهنگ و روش‌های کار در یک سازمان است. یک طبقه‌بندی محصول ابزاری برای طراحی معماری کسب‌وکار سازمان بر اساس بهبود مستمر محصولات و تجربیات مشتری است. از آن برای تعیین حوزه‌های مسئولیت و مالکیت تیم‌ها و شکل‌دهی به معماری نرم‌افزار متناسب با آن استفاده می‌شود.انتقال به یک مدل عملیاتی محصول‌محور نیازمند تغییر عمیق در ساختار، فرهنگ و روش‌های کار در یک سازمان است. یک طبقه‌بندی محصول ابزاری برای طراحی معماری کسب‌وکار سازمان بر اساس بهبود مستمر محصولات و تجربیات مشتری است. از آن برای تعیین حوزه‌های مسئولیت و مالکیت تیم‌ها و شکل‌دهی به معماری نرم‌افزار متناسب با آن استفاده می‌شود. نکات کلیدی درباره طبقه‌بندی محصول عبارتند از:طبقه‌بندی محصول نباید توسط یک تیم معماری متمرکز طراحی شود که طرح‌ها را به تیم‌ها تحویل می‌دهد تا بسازند.به‌روزرسانی‌های طبقه‌بندی باید به‌طور منظم منتشر شوند.می‌توانید بلوک‌های سازنده خود را برای طبقه‌بندی تعریف کنید.جریان ارزش (یا به طور خاص، جریان ارزش توسعه نرم‌افزار) به دنباله‌ای از فعالیت‌هایی اشاره دارد که یک تیم در یک دامنه خاص برای کشف و ارائه بهبودهای محصول انجام می‌دهد.محصولات می‌توانند داخلی (مورد استفاده کارکنان سازمان) یا خارجی (مورد استفاده افراد خارج از سازمان) باشند.پلتفرم‌ها قابلیت‌های داخلی هستند که توسط چندین محصول استفاده می‌شوند.پلتفرم‌های توسعه به تیم‌ها کمک می‌کنند تا محصولات را بسازند و پشتیبانی کنند.دامنه‌ها یک مفهوم سلسله‌مراتبی هستند. یک دامنه بزرگ‌تر ممکن است از چندین زیردامنه تشکیل شود، که خود می‌توانند از زیردامنه‌های جزئی‌تر تشکیل شوند. این نوشته‌ها از اصطلاحات سطح ۱، ۲، ۳ و غیره برای توصیف این سطوح استفاده می‌کند.طبقه‌بندی محصول فقط باید به اندازه کافی جزئیات داشته باشد تا از اهداف فعلی پشتیبانی کند، مانند تعیین یک برش اولیه از مدرنیزه‌سازی که می‌تواند در سه تا شش ماه تحویل داده شود. لازم نیست و توصیه نمی‌شود که یک طبقه‌بندی محصول به طور کامل قبل از شروع هر کار مدرنیزه‌سازی تعریف شود.طبقه‌بندی محصول همیشه در حال تکامل است.ستاره‌های شمالی معیارهای کلیدی محصول هستند که به شفاف‌سازی ارزش و انسجام بخشی از طبقه‌بندی کمک می‌کنند. علیرضا ارومند علیرضا ارومند Mon, 24 Feb 2025 11:12:58 +0330 https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D9%86%D9%87%D9%85-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%B7%D8%A8%D9%82%D9%87-%D8%A8%D9%86%D8%AF%DB%8C-%D9%85%D8%AD%D8%B5%D9%88%D9%84%D8%A7%D8%AA-%D8%A8%D8%AE%D8%B4-%DB%8C%DA%A9-lqeqqmhx5l1e 1. مقدمه:بخش مهمی از ‌مدرن‌سازی معماری، ایجاد چشم‌اندازی از معماریِ نوسازی شده است. این کار به شما امکان می‌دهد چالش‌ها و فرصت‌های هر بخش را شناسایی کرده و سفر خود را از وضعیت جاری به چشم‌انداز آینده برنامه‌ریزی کنید. برای این کار، به یک زبان نیاز دارید. این زبان شامل مجموعه‌ای از بلوک‌های ساختاری است که برای توصیف معماری خود، از نمای کلی تا برنامه‌های نرم‌افزاری منفرد را به کمک آن معرفی می‌کنید.هیچ زبان جهان شمول پذیرفته‌شده‌ای برای توصیف معماری وجود ندارد. بنابراین باید زبانی را انتخاب یا ابداع کنید که برای کسب و کار شما مناسب باشد. من در این فصل، رویکردی به نام "طبقه‌بندی محصولات" را به شما معرفی خواهم کرد. این رویکرد مجموعه‌ای از بلوک‌های ساختاری است که برای توصیف معماری بر اساس محصولات شرکت و نتایج کسب و کار و مشتری که آن‌ها را ممکن می‌سازد، استفاده می‌شود.من رویکردی محصول‌محور را توصیه می‌کنم چون به شما کمک می‌کند تا معماری و ساختار سازمانی را برای تیم‌های محصول توانمندسازی‌شده با جریان سریع و پایدار که برای نتایج کلیدی کسب و کار بهینه‌سازی شده‌اند، طراحی کنید. اما برای بهره‌مند شدن از ایده‌های این نوشتار، نیازی به استفاده از بلوک‌های ساختاری ارائه‌شده در این قسمت ندارید. این فقط یک رویکرد ممکن است (هرچند پیش‌فرضی خوب و منطقی است). شما می‌توانید از بلوک‌های ساختاری ترجیحی خود استفاده کنید.به خاطر داشته باشید که این فصل بر تعریف زبانی برای توصیف معماری شما تمرکز دارد. استفاده از این بلوک‌های ساختاری برای طراحی معماری در فصل‌های بعدی پوشش داده می‌شود.2. تعریف بلوک‌های ساختاری: به تعریف بلوک‌های ساختاری که برای سازمان شما بیشترین معنا را دارند خوش آمدید.تعریف بلوک‌های ساختاری اولین گام برای ساخت و استفاده از یک طبقه‌بندی محصول است. شما از این مفاهیم برای مدل‌سازی معماری و زبان مورد استفاده، برای توصیف کسب و کار خود استفاده خواهید کرد.این بخش بلوک‌های ساختاری مثالی را ارائه می‌دهند که می‌توانید به عنوان نقطه شروع استفاده کنید. این بخش تلاش نمی‌کند که همه‌ی سناریوی‌های ممکن برای تمامی سازمان‌ها را پوشش دهد. شما باید بر اساس نیاز، آن‌ها را تطبیق داده، گسترش دهید یا کاملاً جایگزین کنید. به عنوان مثال، همه‌ی محصولات و قابلیت‌ها دیجیتال نخواهند بود. بنابراین، می‌توانید مفاهیم غیر دیجیتال را نیز نشان دهید تا تصویر کامل را در هنگام اتخاذ تصمیمات طراحی در نظر داشته باشید. در حین خواندن این بخش، به خاطر داشته باشید که در قسمت‌های بعدی هر مفهوم را با جزئیات بیشتری پوشش خواهیم داد.2.1 جریان‌های ارزش مستقل:جریان‌های ارزش مستقل یک بلوک ساختاری حیاتی هستند زیرا شناسایی جریان‌های ارزش مستقل کلید دستیابی به جریان‌های سریع است. در این سلسله مطالب، به توالی فعالیت‌های تیمی، از شناسایی نیازهای برآورده نشده کاربران تا ارائه‌ی راه‌حل و اعتبارسنجی آن‌ها، مانند اضافه کردن ویژگی‌های جدید به یک محصول، جریان ارزش مستقل می‌گوییم. معمولاً، جریانات شامل فعالیت‌های متعددی مانند جلسات کشف محصول، تعریف نیازمندی‌ها، برنامه‌ریزی، کدنویسی، بازبینی، آزمایش و استقرار خواهند بود.تیم‌های نرم‌افزار مبتنی بر جریان ارزشماهیت جریان‌های ارزش می‌توانند متنوع باشند. مثال‌های زیر را در نظر بگیرید:یک سرویس محاسبه‌ی قیمت که از طریق یک API ارائه می‌شودیک سرویس جستجو با API و ویجت رابط کاربرییک برنامه موبایل (در صورتی که به اندازه کافی کوچک باشد که توسط یک تیم واحد مدیریت شود) هستند.چهار ویژگی مهم برای ایجاد یک جریان ارزش مستقل با جریان سریع وجود دارد:هم‌راستا بودن با یک زیردامنه کسب و کار با وابستگی کم (یا بخش دیگری از محصول مانند یک رابط کاربری)هدایت شدن توسط نتایج هدفمندِ کسب و کاری تعلق داشتن به یک تیم مستقل و هم‌راستا با جریان داشتن معماری نرم‌افزاری جداشده هم‌راستا با زیردامنه‌ی کسب و کار، که تیم قدرت تغییر و استقرار آن را دارد.زمانی که این جنبه‌ها در جای خود قرار گیرند و جریان‌های ارزش مستقل باشند، تیم‌ها انگیزه پیدا می‌کنند که به یک نتیجه‌ی کسب و کاری دست یابند و قدرت طراحی، پیاده‌سازی و تحویل راه‌حل‌هایی با حداقل وابستگی به افراد خارج از تیم را خواهند داشت. این جنبه‌ها به طور مفصل در طول این فصل و فصل‌های بعدی پوشش داده می‌شوند.2.2 دامنه‌هاجریان‌های ارزش هرگز 100٪ مستقل نخواهند بود. قدرت سازمان‌ها در این است که از کار همزمان چندین تیم با هم توانمندی‌های سطح بالاتری را تولید می‌کنند که هیچ تیم واحدی به تنهایی قادر به ارائه آن نیست. بنابراین، لازم است جریان‌های ارزش را که به نتایج کسب و کاری سطح بالاتری کمک می‌کنند شناسایی کرده و آن‌ها را گروه‌بندی کنیم تا تیم‌های مرتبط، هم‌راستا باقی بمانند، دانش خود را به اشتراک گذاشته و تا حد ممکن برای دستیابی به جریان سریع از ابتدا تا انتهای کار، همکاری کنند.دامنه‌ها بلوک‌های ساختاری‌ای هستند که نمایانگر گروهی از زیردامنه‌های مرتبط هستند که شامل مفاهیم دامنه مشابه بوده و به اهداف سطح بالاتر مشابهی کمک می‌کنند. بنابراین، جریان‌های ارزش بر اساس رابطه‌ی بین زیردامنه‌ها و نتایج کسب و کارشان به دامنه‌ها سازماندهی می‌شوند.شکل زیر نمونه‌ای از دو دامنه را نشان می‌دهد که یکی از آن‌ها دامنه‌ی E-Comerce است که شامل چهار زیردامنه‌ی کارت، قیمت، محصول و جستجو است. برای هر زیردامنه یک جریان ارزش اختصاصی ایجاد شده است.در سازمان‌های بزرگ‌تر، دامنه‌ها ممکن است به صورت سلسله مراتبی در گستره‌های مختلف تعریف شوند تا گروه‌های مرتبط را هم‌راستا کرده و خطوط مسئولیت‌پذیری سطح بالاتر را ایجاد کنند. شکل زیر این مفهوم را بر اساس سطوح گستره‎‌ی معماری روت مالان و دانا بردمایر نشان می‌دهد.محدوده‌ی معماری 1/محدوده‌ی1 دامنه—یک زیردامنه یا جریان ارزش واحد یا خوشه‌ی کوچک متعلق به همان تیم محدوده‌ی معماری 2/محدوده‌ی 2 دامنه —گروهی از دامنه‌های محدوده‌ی 1 مرتبط با پیچیدگی‌ای که نیاز به چندین تیم دارد محدوده‌ی معماری 3/محدوده‌ی 3 دامنه —گروهی از دامنه‌های محدوده‌ی 2 که نیاز به چندین گروه از تیم‌ها برای مدیریت سطوح پیچیدگی دارد تعداد محدوده‌ها به اندازه‌ی سازمان و پیچیدگی دامنه بستگی دارد. برخی سازمان‌ها بیش از سه محدوده و برخی دیگر کمتر از سه محدوده دارند.همه‌ی دامنه‌ها در یک محده‌ی مشخص، اندازه و پیچیدگی یکسانی نخواهند داشت. شکل بالا یک ساده‌سازی برای بیان مفهومی کلی است و نه الگویی یکسان برای همه.2.3 محصولاتشناسایی جریان‌های ارزشی و حوزه‌های بهینه به یک سؤال مهم بستگی دارد: چه نتایج کسب‌وکاری را می‌خواهید بهینه کنید؟ پاسخ به این سؤال نیازمند ورودی‌های متعددی است (مانند جلسات گفت و گو و واردلی مپینگ و ...). یکی از گام‌های مهم، شناسایی محصولات سازمان و تعیین ارزش تجاری و مشتری آن‌ها است. این مرحله برای درک نحوه‌ی تعریف مرزهای دامنه‌ها و تطبیق آن‌ها برای دستیابی به اهداف استراتژیک کسب‌وکار ضروری است.یک محصول موفق برای مشتریان و برای کسب‌وکار همزمان ارزش ایجاد می‌کند. محصولات باید برای مشتریان جذاب، برای سازمان قابل ساخت و از نظر استراتژیک قابل توجیه باشند. هنگام تعیین نتایج هر محصول، باید این اصول را در نظر داشت. برای مثال، افزایش بهره‌وری و افزایش فروش نمونه‌هایی از ارزش مشتری هستند، در حالی که پول و داده‌ها نمونه‌هایی از ارزش کسب‌وکار به‌شمار می‌روند. برخی از محصولات داخلی خواهند بود که ارزش آن‌ها شامل افزایش بهره‌وری یا کاهش هزینه‌های عملیاتی می‌شود. شناسایی و انتخاب نتایج مناسب با استفاده از «ستاره‌های قطبی» در قسمت‌های قبل توضیح داده شده انجام می‌شود.محصولات از نظر اندازه و پیچیدگی بسیار متنوع هستند. طبیعی است که کارها کوچک شروع شده و با اضافه شدن ویژگی‌های جدید در طول زمان پیچیده‌تر شوند. برخی از محصولات به اندازه‌ای کوچک هستند که یک تیم می‌تواند مالک چندین محصول باشد، در حالی که برخی دیگر نیازمند ده‌ها تیم هستند. بنابراین، هیچ نسبت یک‌به‌یکی بین محصولات و دامنه‌ها وجود ندارد. یک محصول ممکن است به‌طور کامل توسط جریان‌های ارزشی یک حوزه در سطح دوم پوشش داده شود یا در حوزه‌های متعددی در سطح سوم گسترش یابد. به تصویر زیر دقت کنید.واژه «محصول» بسیار مبهم است. در انتهای این نوشته یک تعریف پیشنهادی ارائه خواهد شد.2.4 پلتفرم‌ها:سازمان‌هایی که چندین محصول دارند، اغلب باید استفاده مجدد و مقرون به صرفه بودن در مقیاس بالا را در نظر بگیرند. وقتی چندین محصول از قابلیت‌های مشابه استفاده می‌کنند، پلتفرم‌هایی برای متمرکز کردن این قابلیت‌های مشترک ایجاد می‌شوند.پلتفرم‌ها همیشه یک چالش ظریف برای ایجاد تعادل هستند. از یک سو، آن‌ها هزینه‌ها را کاهش داده و مقرون به صرفه بودن در مقیاس بالا فراهم می‌کنند، زیرا قابلیت‌ها یک‌بار ساخته شده و چندین‌بار استفاده می‌شوند. از سوی دیگر، پلتفرم‌ها به‌راحتی به گلوگاه‌هایی تبدیل می‌شوند که نمی‌توانند نیازهای تمامی مصرف‌کنندگان را پاسخ دهند یا قابلیت‌ها را به‌شکلی آسان برای مصرف ارائه کنند.به‌طور کلی، دو نوع پلتفرم وجود دارد (شکل ۶.۶):پلتفرم‌های دامنه‌ای/افقی: قابلیت‌هایی مرتبط با دامنه کسب‌وکار، مانند سیستم رزرو مشترک.پلتفرم‌های توسعه داخلی (IDP) / فناوری داخلی (ITP): قابلیت‌هایی که به تیم‌ها کمک می‌کنند محصولات خود را بسازند و پشتیبانی کنند.حوزه و محدوده‌ی پلتفرم‌ها متنوع است. برخی از آن‌ها مربوط به یک یا چند محصول خاص می‌شود و برخی دیگر کلیه‌ی محصولات سازمان را در بر می‌گیرد. دسته‌ی اول مانند فریم‌ورک های توسعه به زبان و تکنولوژی خاص می‌شود که داخل تیم‌ها توصعه داده می‌شود و برای گروه دوم می‌توان یک Identity Provider در مقیاس سازمانی را نام برد که به همه‌ی تیم‌ها خدمات ارائه می‎‌کند.هر دو نوع پلتفرم برای مدرن‌سازی معماری ضروری هستند. در ادامه دو مثال از دنیای واقعی را بررسی خواهیم کرد.مثال اول: پلتفرم تحقق سفر اوبرپلتفرم تحقق سفر اوبر، نمونه‌ای برجسته از یک پلتفرم افقی ارزشمند است که از چندین بخش عمودی (محصولات، خدمات، بازارها) را پشتیبانی می‌کند. این پلتفرم، قابلیت‌هایی را فراهم می‌کند که برای تمام بخش‌های عمودی‌ِ اوبر قابل استفاده هستند و باعث کاهش هزینه‌ها، بهبود زمان ارائه به بازار و افزایش حفظ مشتریان و رانندگان می‌شود.وقتی Uber شروع به گسترش از شرکتی تک محصولی به یک شرکت چند محصولی کرد، نیازی به ایجاد قابلیت‌های کاملاً جدید برای هر خط کسب و کاری جدید نداشت. اوبر بخش مشترک را به صورت یک پلتفرم در مقیاس سازمان ارائه کرد که همه‌ی بخش‌های کسب و کاری می‌توانند مستقیماً از آن برای کاهش هزینه‌ها، بهبود زمان ورود به بازار و افزایش حفظ مشتریان و رانندگان استفاده کنند. پلتفرم Uber دارای سطح بسیار بالایی از قابلیت استفاده مجدد است، که این قابلیت همیشه برای همه پلتفرم‌ها صدق نمی‌کند. دیدن پلتفرم‌هایی که به دلیل درخواست ویژگی‌های منحصر به فرد هر تیمی که از پلتفرم استفاده می‌کند، به گلوگاه‌های سازمانی تبدیل شده‌اند، معمول است. استفاده مجدد همیشه یک شمشیر دولبه است که باید با در نظر گرفتن معیارهای دامنه کسب و کار، شرایط فنی و اجتماعی تیم‌ها به دقت اعمال شود.مثال دوم: پلتفرم فناوری داخلی NAVسازمان کار و رفاه نروژ (NAV) بزرگ‌ترین سازمان عمومی این کشور است که خدمات متنوعی از جمله بازنشستگی، بیماری درمانی، و بیکاری به ۲.۵ میلیون شهروند ارائه می‌دهد. این سازمان برای بیش از ۱۰۰ تیم داخلی خود، یک پلتفرم فناوری داخلی (IDP) توسعه داده است که شامل زیرپلتفرم‌های مختلفی مانند پلتفرم زیرساخت و پلتفرم داده است.تجزیه‌ی یک پلت فرم بزرگ به زیرپلتفرم ها یک الگوی رایج در سازمان هایی است که پلتفرم ها به بلوغ و مقیاس خاصی می رسند. این یک گام کلیدی برای جلوگیری از تبدیل شدن پلتفرم‌ها به گلوگاه است، زیرا به تیم‌های جداگانه اجازه می‌دهد تا مسئولیت بخش‌های خاصی از پلتفرم را بر عهده داشته باشند، نه اینکه هر عضو تیم از هر قسمت از پلتفرم مطلع باشد، رویکردی که مقیاس‌پذیر نیست و می‌تواند منجر به فرسودگی کارمندان شود.نکته‌ی کلیدی از داستان پلتفرم NAV این است که اگرچه پلتفرم بزرگ و ماهیت متفاوتی دارد، اما بر اساس نیاز توسعه داده شده است. این یعنی موضوعات مختلف به طور کامل از قبل مشخص نشده بود که مثلا به عنوان یک پروژه بزرگ سه ساله تحویل داده شوند. این نوع پروژه‌های پلتفرم اغلب خطرناک و ناموفق هستند. یکی دیگر از نکات برجسته در رویکرد پلت فرم NAV این است که آن‌ها با محصولات مرتبط با بخش‌های داخلی خود، با طرز فکری مشابه سایر محصولات رفتار می‌کنند. آنها کارکنان داخلی را به عنوان مشتری در نظر گرفته و سعی می کنند با کاهش بار شناختی، پلتفرم را تا حد امکان جذاب کنند و آن‌ها را آزاد کنند تا کار خود را به طور موثرتر انجام دهند. این یک جنبه حیاتی در ساختن پلتفرم‌هایی است که به آن پلتفرم به‌ عنوان محصول می‌گویند.2.5 گروه‌های محصول و پورتفولیوهابرای سازمان‌های بزرگ و بسیار بزرگ با ده‌ها هزار کارمند، پیچیدگی بیشتری در مقیاس بالاتری وجود دارد. در طبقه‌بندی محصول خود، راس کلانتون و همکاران اصطلاحات گروه محصول و پرتفوی محصول را برای این سطوح بالاتر پیشنهاد می‌دهند. گروه محصول مجموعه‌ای از محصولات است که به نتایج مرتبط کمک می‌کنند یا وابستگی‌های تحویلی دارند، و پرتفوی محصول مجموعه‌ای از گروه‌های محصول است که رابطه‌ای بین آنها وجود دارد. گروه پلتفرم و پرتفوی پلتفرم ساختارهای کلان متناظر برای پلتفرم‌ها هستند. در حالی که مدرن‌سازی ممکن است همیشه منجر به تغییرات در سطوح گروه محصول و پرتفوی محصول نشود، داشتن درک واضحی از آن‌ها و اینکه چگونه تصمیمات نوسازی در سطوح پایین‌تر با تصویر بزرگتر هماهنگ می‌شوند، مفید است.2.6 مثالی از دنیای واقعی: تاکسونومی محصول Salesforce (2017)احمتالا Salesforce یک نمونه‌ی خوب از یک سازمان بزرگ با پرتفوی‌های مختلف محصول است. بررسی مربوط به سال 2017 می‌شود. در آن زمان، Salesforce حدود سی هزار کارمند در سطح جهانی داشت، در آن زمان این شرکت به‌طور مداوم از طریق رشد ارگانیک و خریدهای منظم در حال گسترش بود. در نتیجه، Salesforce یک محیط فناوری اطلاعات وسیع و ناهمگن داشت و فرهنگ‌های سازمانی مختلفی در چندین منطقه بین‌المللی در آن وجود داشت. در سطح بالاتر، معماری Salesforce به بیش از ده پرتفوی محصول تقسیم شده بود که به آن‌ها "ابرها" (clouds) گفته می‌شد. نمونه‌هایی از این ابرها شامل Sales Cloud، Service Cloud، Marketing Cloud و Commerce Cloud بودند.یکی از پرتفوهای محصول که Marketing Cloud نام داشت به‌طور مستقل درآمدی معادل ۹۳۳ میلیون دلار در سال ۲۰۱۷ داشت. این بخش مدیر ارشد فناوری (CTO) و مدیر عامل (CEO) اختصاصی خود را داشت که به ترتیب به CTO و CEO مرکزی گزارش می‌دادند. Marketing Cloud از چندین گروه محصول تشکیل شده بود که اغلب اما نه همیشه به‌عنوان استودیوها (studios) شناخته می‌شدند؛ به‌عنوان مثال، Social Studio، Mobile Studio، Email Studio و Advertising Studio. تصویر زیر را مشاهده کنید.گروه محصول Advertising Studio شامل سه محصول بود: Advertising Campaigns برای ساخت و اجرای کمپین‌ها در شبکه‌های اجتماعی مانند فیس‌بوک و لینکدین، Advertising Audiences برای ایجاد مخاطبین مشابه بر اساس مشتریان موجود، و Lead Capture برای اتصال سرنخ‌ها از شبکه‌های اجتماعی به حساب Salesforce یک مشتری. هر یک از موارد بالا محصولاتی بودند که مشتریان می‌توانستند به‌صورت جداگانه خریداری کرده و هرکدام کدبیس و تیم‌های خود را برای توسعه داشتند. با این حال، این محصولات به دلایل مختلف به‌عنوان یک گروه محصول معماری شده بودند. از جنبه تجاری، این محصولات به مشتریان مشابهی هدف‌گذاری می‌شدند و شرکت سعی داشت آن‌ها را در قالب قراردادهای B2B بسته بندی و ارائه کند. علاوه بر این، دانش دامنه برای این سه محصول بسیار مشابه بود، بنابراین منطقی بود که افراد درگیر به‌طور نزدیک با یکدیگر همکاری کنند.هر محصول به‌طور فردی از اجزای نرم‌افزاری متعددی تشکیل شده بود که توسط تیم‌های مختلف مدیریت می‌شد. به‌عنوان مثال، Advertising Campaigns شامل مجموعه‌ای از اجزا بود، از جمله رابط کاربری مشتری، یک اپلیکیشن برای ایجاد کمپین‌ها، یک اپلیکیشن برای اجرای و پیگیری کمپین‌ها، و یک اپلیکیشن برای پیکربندی قوانین کمپین بر اساس محرک‌ها و شرایط.3. جمع بندی: چندین مفهوم در این بخش معرفی شده‌اند و ممکن است مدتی طول بکشد تا با آن‌ها و نحوه ارتباطشان با یکدیگر آشنا شوید. شکل زیر یک راهنمای سریع است که می‌توانید به‌راحتی به آن مراجعه کنید. به یاد داشته باشید،این ساختار صرفا یک ابداع است و شما می‌توانید با توجه به نیاز خود ساختار با اجزا و سطوح دلخواه خود را داشته باشید. این مدل سعی ندارد همه سناریوهای ممکن را در نظر بگیرد. به‌عنوان مثال، ممکن است نیاز باشد بلوک‌هایی برای محصولات و قابلیت‌های غیرنرم‌افزاری اضافه کنید.مدل‌های زیادی برای توصیف مفاهیم معماری و روابط آن‌ها در سطوح مختلف دامنه و با درجات مختلفی از جزئیات وجود دارند. برخی از این مدل‌ها عبارتند از: EDGY از Intersections، مدل Teams, Domains, and Verticals از Evan Bottcher و Architectural Levels of Scope از Ruth Malanو Value Stream Network از BVSSH. این‌ها نمونه‌هایی از مدل‌هایی هستند که می‌توانند برای تحلیل و طراحی معماری در سطوح مختلف به کار روند.در قسمت بعد در مورد طراحی طبقه بندی محصولات و پیش‌برد اهداف متناسب با این طبقه بندی گفتگو خواهیم کرد. علیرضا ارومند علیرضا ارومند Sun, 01 Dec 2024 11:55:33 +0330 https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D9%86%D9%87%D9%85-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%88-%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%A7%D8%AA-%D8%B2%D9%86%D8%AF%D9%87-yfegsfwwnzeb 1. اصول مستندات زنده:مفهوم مستندات زنده اولین بار در کتاب «Specification by Example» نوشته‌ی Gojko Adzic محبوب شد. آدزیک یکی از مزایای کلیدی تیم‌هایی کهBDD انجام می‌دهند را اینگونه توصیف کرد توصیف کرد: سناریوهایی که برای تست ومشخصات ایجاد شده بودند به عنوان مستنداتی برای رفتارهای تجاری نیز بسیار مفید بودند. به لطف تست‌های خودکار، این مستندات تا زمانی که ‌همه‌ی تست‌ها در حال اجرا بودند همیشه به‌روز بود. امکان بهره‌مندی از مزایایی شبیه به مستندات زنده در همه‌ی جنبه‌های یک پروژه‌ی نرم‌افزاری وجود دارد: درست است که رفتارهای تجاری از این مستندات بهره‌مند می‌شوند، اما در کنار آن، دامنه‌های کسب‌وکاری، چشم‌انداز پروژه ، طراحی و معماری، راهنمایی‌های کدنویسی، استقرار و زیرساخت و ... نیز از این قابلیت می‌توانند سود ببرند.مستندات زنده شامل چهار اصل است:قابل اعتماد: مستندات زنده در هر زمانی که به آن مراجعه کنیم دقیق و همگام با نرم‌افزار در حال تحویل است.کم‌هزینه: برای تولید مستندات زنده تلاش حداقلی نیاز است. حتی زمانیکه تغییر، حذف یا اضافه شدنی در فرایند کسب و کاری رخ می‌دهد برای به روز زسانی مستندات اندکی تلاش نیاز است.مشارکتی: مستندات زنده گفتگوها و اشتراک دانش بین همه‌ی افراد درگیر را ترویج می‌دهد.بینش‌افزا: با جلب توجه به جنبه‌های مختلفی از کار، مستندات زنده فرصت‌هایی برای بازخورد فراهم و به عمیق‌تر تفکر کردن تشویق می‌کند. این کار کمک می‌کند تا درک بهتری از کار جاری داشته باشید و تصمیمات بهتری بگیرید.مستندات زنده و فرایند اجرایی آن به گونه‌ای است که برای توسعه‌دهندگان نیز انجام آن لذت بخش است. آن‌ها می‌توانند روی انجام کارهای مورد علاقه خود تمرکز کنند و در عین حال مستندات زنده را نیز از این کارها به دست آورند.در ادامه به طور خلاصه چهار اصل اصلی مستندات زنده را توصیف خواهد شد که با هم به عنوان راهنمایی برای بیشترین بهره‌مندی مزایا از این رویکرد عمل می‌کنند. در آینده در مورد این ایده‌ها بیشتر خواهیم نوشت.1.1. قابل اعتماد: مستنداتی مفید است که قابل اعتماد باشد؛ به عبارت دیگر، باید صد در صد قابل اعتماد باشند. از آنجایی که انسان‌ها هیچ‌وقت تا این حد قابل اعتماد نیستند، نیاز به فرایند‌ها و ابزارهایی داریم که امر را ممکن سازند. برای دستیابی به مستندات قابل اعتماد، به ایده‌های زیر تکیه می‌کنیم:بهره‌برداری از دانش موجود: بیشتر دانش‌ مورد نیاز در مصنوعات پروژه وجود دارد، فقط باید با هدف مستندسازی تکمیل شده و مورد بهره‌برداری قرار گیرند.مکانیزم دقت: به مکانیزمی نیاز داریم که اطمینان حاصل شود همیشه دانش‌ها در مصنوعات مختلف با هم هماهنگ هستند.1.2. کم هزینه:برای داشتن مستندات زنده باید هزینه رسیدن به آن را تا حد امکان کاهش دهیم تا در محیط‌هایی که دائماً در حال تغییر هستند ارجای آن امکان‌پذیر و پایدار باشد؛ این هدف را با استفاده از ایده‌های زیر می‌توانید محقق کنید:سادگی: اگر همه چیز واضح و بدیهی باشد و چیزی برای اعلام و ابراز وجود نداشته باشد، مستندات بهترین حالت خود را دارند.استانداردها به جای راه‌حل‌های سفارشی: معمولاً استانداردها برای همه آشنا هستند و اگر اینطور نباشد هم کافی است به کتاب یا منبعی در مورد آن اشاره کنیم.محتوای همیشه‌سبز: همیشه محتوایی وجود دارد که تغییر نکرده یا بسیار نادر تغییر می‌کند.و نگهداری این موارد هزینه زیادی ندارد.دانش مقاوم در برابر بازسازی: برخی زمان‌ها هنگام تغییر چیزی نیاز به تلاش انسانی نداریم. عدم نیاز به تلاش انسانی می‌تواند به خاطر ابزارهای خودکار سازی باشد که استفاده شده یا اینکه دانش چیزی با خود آن چیز مرتبط بوده و هنگام تغییر با هم حرکت کنند.مستندات داخلی: هنگامی که دانش اضافی برای چیزی در اختیار داریم بهتر است این دانش تا حد امکان به آن چیز نزدیک بوده یا درون خودش قرار گیرد.1.3. مشارکتی (همکاری‌محور): مستندات زنده در نظر گرفتن ترجیحات زیر باید همکاری‌محور باشد:ترجیح مکالمات به مستندات رسمی: هیچ چیزی بهتر از مکالمات رو در رو و تعاملی برای تبادل دانش کارآمد نیست. از اینکه هر مباحثه‌ای را ثبت و ظبط نمی‌کنید احساس بدی نداشته باشید.شخصا مکالمات را ترجیح می‌دهم، اما دانش‌هایی وجود دارد که در طولانی‌مدت و یا برای افراد زیادی مفید است. مهم است که به فرایند رسوب‌گذاری ایده‌ها در طول زمان توجه کنید تا تصمیم بگیرید که چه دانشی ارزش ثبت در فرمی پایدار را دارد.دانش قابل دسترس: در رویکرد مستندات زنده، دانش اغلب به صورت دیجیتال ثبت و ظبط شده و به کمک ابزارهای مدیریت نسخه نگهداری می‌شود. این امر دسترسی افراد غیر فنی به آن‌ها را دشوار می‌کند. بنابراین، باید ابزارها و فرایند‌هایی را داشته باشید که این دانش به سادگی در اختیار همگان قرار گیرد.مالکیت جمعی: چون مستندات به کمک سیستم‌های کنترل نسخه نگهداری می‌شوند نمی‌توانیم بگوییم که توسعه‌دهندگان مالک آن هستند. توسعه‌دهندگان مالک مستندات نیستند؛ آن‌ها فقط مسئولیت فنی برخورد با آن را به عهده دارند.1.4. بینش‌محور: اصول ذکر شده مفید هستند، اما بینش محور بودن برای برای دستیابی به پتانسیل کامل مستندات زنده ضروری است:تصمیم‌گیری آگاهانه: زمانی که در حال انجام مستندات زنده هستید، اگر به وضوح ندانید که چه کاری انجام می‌دهید، این موضوع فوراً آشکار می‌شود. این نوع بازخورد شما را تشویق می‌کند تا تصمیمات خود را شفاف‌تر کنید تا آنچه انجام می‌دهید به راحتی قابل توضیح باشد. با تشویق به تصمیم‌گیری آگاهانه‌تر، اغلب کیفیت کار افزایش می‌یابد.یادگیری تعبیه‌شده: کد و سایر مصنوعات فنی باید به گونه ای باشند که سایرین بتوانند طراحی، دامنه‌ی کسب‌وکار و هر چیز مرتبط دیگری را فقط با کار کردن و تعامل با سیستم یاد بگیرند.واقعیت به جای توهمات: مستندات زنده توهمات را کنار زده و به آشکار شدن وضعیت واقعی سیستم کمک می‌کند (به عنوان مثال، "انتظار نداشتم پیاده‌سازی اینقدر نامرتب باشد"، مانند "فکر می‌کردم به درستی اصلاح شده‌ام، اما آینه چیز دیگری می‌گوید."). این موضوع می‌تواند با پذیرش واقعیت به همان صورتی که هست، به جای آنچه که دوست دارید باشد، به بهبود‌های فرایند‌ها و سیستم کمک کند.در ادامه کمی بیشتر در مورد این اصول صحبت خواهیم کرد اما الگوها و شیوه‌های مرتبط با اجرای موفقیت‌آمیز رویکرد مستندات زنده را در آینده خواهیم دید. قبل از ادامه بحث بیایید به دنیای حشرات و الهاماتی از آن نگاه کنیم.1.5. انتقال دانش در مورچه ها: استیگمرژیاخیراً مایکل فیدرز لینکی به یک مقاله آنلاین فوق‌العاده توسط تد لوئیس به اشتراک گذاشت که مفهوم استیگمرژی را در رابطه با کار ما در نرم‌افزار به عنوان یک تیم معرفی می‌کند: حشره‌شناس فرانسوی، پیر-پل گراس، مکانیزمی برای هماهنگی حشرات را توصیف کرد که آن را «استیگمرژی» نامیده‌اند - کاری که توسط یک بازیگر انجام می‌شود محرکی برای کار بعدی توسط خودش یا بازیگران دیگر است. یعنی، وضعیت یک ساختمان، پایگاه کد، بزرگراه یا ساختار فیزیکی دیگر تعیین می‌کند که بدون حاکمیت خودکامه و برنامه ریزی مرکزی چه چیزی باید در ادامه انجام شود. بازیگران - حشرات(برنامه‌نویسان) - بر اساس آنچه قبلا انجام شده، می‌دانند که در ادامه چه کاری باید انجام دهند. این تمایل شهودی به گسترش کار دیگران به اصل سازمان‌دهنده توسعه نرم‌افزار مدرن تبدیل می‌شود. مورچه‌ها از نوع خاصی از نشانگرهای شیمیایی یعنی فرومون‌ها برای برجسته کردن نتایج فعالیت خود استفاده می‌کنند. به طور مشابه، برنامه‌نویسان نشانگرهای خود را از طریق ایمیل‌ها، مسائل GitHub و همه نوع مستنداتی که کد را تکمیل می‌کنند، تولید می‌کنند. همان‌طور که لوئیس نتیجه‌گیری می‌کند: جوهره‌ی توسعه‌ی نرم‌افزار مدرن، هوش استیگمرژیک و نشانگرهای جاسازی‌شده در منبع کد است. با افزایش تمرکز برنامه‌نویسان بر جنبه‌هایی از کار که نیاز به انجام شدن دارند، نشانگرهای استیگمرژی کارآمدتر می‌شوند. در حال حاضر، راه غالب ما برای تبادل دانش بین افراد و ماشین‌هایی که هنگام انجام نرم‌افزار درگیر هستند استیگمرژی است. یکی از ایده‌های کلیدی مستندات زنده این است که اثر استیگمرژیک را به حداکثر برساند. این کار با خارج کردن بیشترین دانش از سیستمی که در آن هستید، مانند مورچه‌ها، شروع می‌شود.2. بیشتر دانش در حال حاضر آنجا هست:وقتی دانشی از قبل ثبت شده باشد نیازی به ثبت مجدد آن نیست. هر پروژه‌ی جذابی یک سفر یادگیری است که دانش خاصی را تولید می‌کند. ما معمولاً انتظار داریم مستندات دانش خاصی که نیاز داریم را به ما بدهد، اما نکته جالب این است که همه‌ی این دانش از قبل هم آنجا هست: در کد، در فایل‌های پیکربندی، در تست‌ها، در رفتار برنامه در زمان اجرا، در حافظه‌ی ابزارهای مختلف درگیر و البته در ذهن همه‌ی افرادی که روی آن کار می‌کنند. در یک پروژه نرم‌افزاری، بیشتر دانش به نوعی و در جایی از مصنوعات وجود دارد. این شبیه به یادگیری مورچه‌ها برای تکامل لانه خود عمدتاً از خود لانه است. بنابراین احتمالا اذعان می‌کنید که بیشتر دانش در حال حاضر در خود سیستم وجود دارد. هر زمان که لازم است، محل آن را شناسایی کرده و از آن استفاده می‌کنید. باید بدانید وجود دانش از قبل در جایی به معنای عدم نیاز به تلاش نیست. دانشی که در حال حاضر وجود دارد مشکلات زیادی نیز دارد:2.1. غیرقابل دسترسی: دانشی که در کد و یا سایر مصنوعات‌ ذخیره می‌شود برای افراد غیر فنی قابل دسترسی نیست. به عنوان مثال، کد برنامه برای غیر توسعه‌دهندگان قابل خواندن نیست.2.2. بیش از حد زیاد: دانش موجود در مصنوعات پروژه بسیار زیاد است و استفاده از آن کارآمد نیست. به عنوان مثال، هر خط از برنامه دانشی در زمینه دامنه‌ی کسب و کار را رمزگذاری می‌کند، اما برای یک سوال خاص، نهایتا یک یا دو خط از برنامه مرتبط است.2.3. پراکنده: دانشی که از نظر ما یک قطعه واحد است در بخش‌های زیادی از مصنوعات مختلف پراکنده شده است. به عنوان مثال، مفهومی که در حالث ارث بری در سی شارپ توسعه داده می‌شود دانشی را در قالب چندین فایل و بعضا چندین پروژه نگهداری می‌کند. حتی اگر ما این کلاس‌ها و ساختار سلسله مراتبی را یکسان فرض کنیم، اما باز هم در فایل‌های مختلفی نگهداری می‌شود.2.4. ضمنی: اغلب مصنوعات پروژه، دانش را به صورت ضمنی در خود دارند. ممکن است نود و نه درصد دانش آنجا باشد و برای اینکه این دانش صریح باشد یک درصد نقص داشته باشد. به عنوان مثال، فرض کنید برای توسعه بخشی از کد از الگوی Composit استفاده شود، تنها افرادی که دانش این الگو را دارند هدف آن را درک خواهند کرد و سایرین متوجه وجود این الگو نخواهند شد.2.5. غیرقابل بازیابی: با اینکه دانشی در جایی وجود دارد، ممکن است به خاطر ابهام زیاد غیر قابل بازیابی باشد. به عنوان مثال با اینکه منطق کسب و کاری در کد پیاده سازی شده است، اما ممکن است کد به قدری کثیف باشد که هیچ کس نتواند متوجه آن شود.2.6. نانوشته: یک حالت بسیار بد نیز وجود دارد و آنست که دانش فقط در ذهن افراد وجود دارد و اثرات آن در مصنوعات پروژه ایجاد شده است. به عنوان مثال، ممکن است قانونی در کسب‌وکار وجود داشته باشد، اما هیچ جا مستقیما مستند نشده باشد و نهایتا در قالب چندین کلاس و تابع در بخش‌های مختلف پخش شده باشد و هیچ کس از وجود کلی قانون مطلع نباشد.3. مستندات داخلی:بهترین مکان برای ذخیره‌ی مستندات روی همان چیزی است که مستند شده است. احتمالاً تصاویر دیتاسنترهای گوگل و مرکز پمپیدو در پاریس را دیده‌اید. آن‌ها لوله‌های رنگی زیادی با برچسب‌های یا حکاکی‌هایی روی لوله‌ها دارند. در مرکز پمپیدو، لوله‌های هوا آبی و لوله‌های آب سبز هستند. این منطق رنگی فراتر از لوله‌ها گسترش می‌یابد: انتقال برق زرد است و هر چیزی مرتبط با جابجایی افراد از جمله آسانسورها و پله‌ها و ... قرمز است. این منطق نیز در دیتاسنترها رایج است و حتی مستندات بیشتری مستقیماً روی لوله‌ها چاپ شده است. برچسب‌هایی برای شناسایی لوله‌ها و پیکان‌هایی برای نشان دادن جهت جریان آب در آن‌ها وجود دارد. در دنیای واقعی، چنین رنگ‌کدگذاری و علامت‌گذاری‌های موقت اغلب برای پیشگیری از حریق و آتش‌نشانی اجباری است: لوله‌های آب برای آتش‌نشان‌ها برچسب‌های بسیار قابل مشاهده‌ای دارند که منبع آن‌ها را نشان می‌دهند. در ساختمان‌های بزرگ محل خروج اضطراری علامت گذاری و مشخص است. در هواپیماها، علائم روشن در راهروهای مرکزی مستند کرده‌اند که به کجا بروید. در شرایط بحرانی، زمانی برای جستجوی یک راهنمای ندارید؛ شما به پاسخ در آشکارترین مکان نیاز دارید: درست جایی که هستید، روی خود آن چیز. فرض کنید خودرویی آتش گرفته و می‌خواهید از کپسول آتشنشانی استفاده کنید و در همین لحظه نیاز داشته باشید به دنبال دفترچه راهنما برای استفاده از آن بگردید.3.1. مستندات داخلی در مقابل خارجی:مستندات پایدار به دو شکل وجود دارند: خارجی و داخلی. با مستندات خارجی، دانش در قالبی بیان می‌شود که هیچ ارتباطی با فناوری‌های پیاده‌سازی انتخاب شده برای پروژه ندارد. نگهداری مستندات در قالب اسناد مایکروسافت آفیس به صورت جداگانه از پروژه شکلی از مستندات سنتی است. یک مزیت مستندات خارجی این است که می‌تواند هر فرمتی و ابزاری که برای مخاطبان و نویسندگان مناسب‌تر است را بگیرد. مشکل اصلی این است که به سختی می‌توان آن‌ها را به روز نگه داشت. مستندات خارجی می‌تواند به سادگی گم شود. در مقابل، مستندات داخلی به‌طور مستقیم دانش را با استفاده از فناوری‌های پیاده‌سازی آن مصنوع از پروژه ثبت و نگهداری می‌کنند. استفاده از کامنت نویسی در زبان‌های برنامه‌نویسی یا قراردادهای نام‌گذاری روی شناسه‌های زبان برای اعلام و توضیح تصمیمات طراحی مثالی خوب از مستندات داخلی است. مزیت مستندات داخلی این است که تقریبا همیشه به‌روز است، زیرا بخشی از کد منبع مصنوعات پروزه است. مستندات داخلی نمی‌تواند گم شود زیرا در خود کد جاسازی شده است. همچنین به راحتی در دسترس است و به چشم هر توسعه‌دهنده‌ای که روی کد کار می‌کند می‌آید. مستندات داخلی همچنین به شما امکان می‌دهد از تمام ابزارها و تمام مزایای IDE فوق‌العاده خود استفاده کنید، مانند تکمیل خودکار، جستجوی فوری و ناوبری یکپارچه درون و بین عناصر. مشکل این است که بیان دانش شما به مکانیزم‌های توسعه‌پذیری موجود در زبان محدود می‌شود. به عنوان مثال، نمی‌توانید خیلی چیزها بهXML های موجود در کد سی شارپ با دانش اضافی در مورد هر وابستگی اضافه کنید. یک مشکل بزرگ دیگر این است که دانش بیان‌شده به‌عنوان مستندات داخلی برای غیر توسعه‌دهندگان به راحتی قابل دسترسی نیست. با این حال، می‌توان این محدودیت را با مکانیزم‌های خودکاری که دانش را استخراج کرده و آن را به اسنادی که برای مخاطبان مناسب قابل دسترسی است تبدیل می‌کند، برطرف کرد. اگر با کتاب «Domain-Specific Languages» نوشته مارتین فاولر و ربکا پارسونز آشنا باشید، مفاهیم مشابهی از زبان‌های خاص دامنه داخلی و خارجی را خواهید شناخت. یک DSL خارجی مستقل از فناوری پیاده‌سازی انتخاب شده است. برای مثال، نحوی که برای عبارات منظم استفاده می‌شود هیچ ارتباطی با زبان برنامه‌نویسی انتخاب شده برای پروژه ندارد. در مقابل، یک DSL داخلی از فناوری پیاده‌سازی انتخاب شده به طور عادی استفاده می‌کند، به گونه‌ای که به نظر می‌رسد یک زبان دیگر باشد. این سبک اغلب به سبک روانی معروف است و در کتابخانه‌های Mock معمول است.3.2. مثال‌هایی از مستندات داخلی و خارجی:همیشه آسان نیست تشخیص دهید که مستندات داخلی است یا خارجی ، زیرا گاهی اوقات این بستگی به دیدگاه شما دارد. نظرات کد معمولاً در منطقه خاکستری قرار دارند. آن‌ها به‌طور رسمی بخشی از زبان هستند اما چیزی بیش از متن آزاد ارائه نمی‌دهند. شما باید آن‌ها را با استعداد نوشتاری خود بنویسید و کامپایلر هیچ کمکی برای بررسی املای اشتباه نمی‌کند. از دیدگاه توسعه‌دهنده، هر فناوری استانداردی که برای ساخت یک محصول نرم‌افزاری استفاده می‌شود می‌تواند به عنوان میزبان مستندات داخلی در نظر گرفته شود، از جمله:فایل‌های ویژگی که برای ابزارهای مشخصات خوانا توسط کسب‌وکار و تست استفاده می‌شوندفایل‌های Markdown و تصاویر در کنار کد با یک قرارداد نام‌گذاری یا پیوند به کد یا فایل‌های ویژگیمانیفست ابزارها، از جمله مانیفست مدیریت وابستگی، مانیفست استقرار خودکار، مانیفست توضیحات زیرساخت و غیره هر زمان که ما مستندات را در این مصنوعات اضافه می‌کنیم، از توانایی استفاده از مجموعه ابزارهای استاندارد خود بهره می‌بریم و مزیت نزدیک بودن به پیاده‌سازی مربوطه را داریم تا بتواند با آن تکامل یابد.3.3. ترجیح مستندات داخلیبه یاد داشته باشید که قبلاً گفته‌ام: بهترین مکان برای قرار دادن مستندات درباره یک چیز روی خود آن چیز است. من قطعاً به مستندات داخلی علاقه‌مندم، این مستندات همراه با خودکارسازی کافی برای مواردی که نیاز به انتشار مستندات سنتی بیشتر است بسیار کارآمد خواهد بود. من پیشنهاد می‌کنم که به‌طور پیش‌فرض مستندات داخلی را انتخاب کنید، حداقل برای همه‌ی دانش‌هایی که در دائما در حال تغییر هستند. حتی برای دانش‌های پایدار، من توصیه می‌کنم ابتدا مستندات داخلی را انتخاب کنید و فقط در مواردی که ارزش افزوده‌ای واضح وجود دارد مستندات خارجی را انتخاب کنید. ممکن است برای اهداف بازاریابی نیاز به ایجاد جاذبه بصری در مستند داشته باشید که در این شرایط مستندات خارجی کارآمد تر است. در این مورد، پیشنهاد می‌کنم اسلایدهای دستی، نمودارهایی با چیدمان دقیق دستی و تصاویر جذاب ایجاد کنید. هدف از استفاده از مستندات خارجی اضافه کردن احساس انسانی به سند نهایی است، بنابراین من از پاورپوینت استفاده می‌کنم، تصاویر با کیفیت زیبا را انتخاب یا ایجاد می‌کنم و اثربخشی مستندات را در یک ارائه به همکاران تست می‌کنم تا مطمئن شوم که به‌خوبی اثرگذار است. توجه داشته باشید که ایجاد جذابیت برای مستندات رسمی یا خودکار سخت است، اما غیرممکن نیست.3.4. مستندات در محل: مستندات داخلی، همچنین به‌عنوان مستندات در محل، به معنای مستنداتی است که «در موقعیت یا مکان طبیعی یا اصلی خود» قرار دارد. این به این معنی است که مستندات نه تنها از همان فناوری پیاده‌سازی استفاده می‌کند بلکه به‌طور مستقیم در کد منبع، درون مصنوعی که محصول را ساخته است، ترکیب می‌شود. در محل به معنای آوردن دانش اضافی درباره یک چیز به جایی است که آن چیز قرار دارد، به عنوان مثال درون کد منبع به جای یک مکان دوردست. این نوع مستندات برای توسعه‌دهندگان مناسب است. همان‌طور که در طراحی رابط‌های کاربری، جایی که اصطلاح در محل به معنای این است که یک عمل خاص کاربر می‌تواند بدون رفتن به یک پنجره دیگر انجام شود، استفاده و ویرایش مستندات می‌تواند بدون رفتن به یک فایل دیگر یا ابزار دیگر انجام شود.3.5. مستندات قابل خواندن توسط ماشین:مستندات خوب بر دانش سطح بالا، مانند تصمیمات طراحی در بالای کد و منطق پشت این تصمیمات تمرکز می‌کند. ما معمولاً این نوع دانش را فقط برای افراد مفید می‌دانیم، اما حتی ابزارها نیز می‌توانند از آن استفاده کنند. از آنجا که مستندات داخلی با استفاده از فناوری‌های پیاده‌سازی بیان می‌شود، معمولاً می‌تواند توسط ابزارها تجزیه شود. این اتفاق فرصت‌های جدیدی برای ابزارها برای کمک به توسعه‌دهندگان در وظایف روزانه آن‌ها باز می‌کند. به ویژه، این فرایند امکان پردازش خودکار دانش برای نگهداری، تلفیق، تبدیل قالب، انتشار خودکار یا همگام‌سازی را فراهم می‌کند.4. دانش خاص در مقابل عمومی:برخی دانش‌ها خاص شرکت، سیستم یا دامنه کسب‌وکار شما است. در مقابل دانشی وجود دارد که عمومی بوده و با بسیاری از افراد دیگر در بسیاری از شرکت‌های دیگر در صنعت به اشتراک گذاشته شده است. دانش درباره زبان‌های برنامه‌نویسی، ابزارهای توسعه‌دهندگان، الگوها و شیوه‌های نرم‌افزار به دسته دانش عمومی تعلق دارد. مثال‌هایی شاملDDD، الگوها، CICD و آموزش‌های Git می‌باشد. دانش درباره‌ی بخش‌های بالغ صنعت کسب‌وکار نیز دانش عمومی است. حتی در حوزه‌های بسیار رقابتی مانند قیمت‌گذاری در مالی یا بهینه‌سازی زنجیره تأمین در تجارت الکترونیک، بیشتر دانش عمومی و موجود در کتاب‌های استاندارد صنعت است و تنها بخش کوچکی از دانش کسب‌وکار خاص و محرمانه است. این خاص و محرمانه بودن نیز تنها برای مدت زمانی کوتاه است. به عنوان مثال، هر دامنه کسب‌وکار فهرست خواندن ضروری خود را دارد و ممکن است کتابی داشته باشد که اغلب به عنوان «انجیل» آن حوزه اشاره شود. برای مثال در صنعت بیمه ممکن است هر کسی بخش زیادی از نیاز دانش خود را در این زمینه از کتاب "اصول، مقررات و رشته‌های بیمه" به دست آورد که در اختیار همگان قرار دارد. خبر خوب این است که دانش عمومی در ادبیات صنعت قبلاً مستند شده است. کتاب‌ها، پست‌های وبلاگی و کنفرانس‌هایی وجود دارد که آن را به‌خوبی توصیف می‌کنند. واژگان استانداردی برای صحبت کردن درباره‌ی آن وجود دارد. آموزش‌هایی در دسترس هستند تا آن را سریع‌تر از افراد آگاه یاد بگیرید.4.1. یادگیری دانش عمومی:شما دانش عمومی را با انجام کار خود، همچنین با خواندن کتاب‌ها و حضور در آموزش‌ها و کنفرانس‌ها یاد می‌گیرید. این فقط چند ساعت طول می‌کشد و شما می‌دانید که چه چیزی را یاد خواهید گرفت، چقدر طول می‌کشد و چقدر هزینه خواهد داشت. یادگیری دانش عمومی به اندازه رفتن به فروشگاه برای خرید غذا آسان است. دانش عمومی یک مشکل حل شده است. این دانش آماده استفاده توسط همه است. هنگامی که از آن استفاده می‌کنید، فقط باید به یک منبع معتبر لینک دهید و کار شما در مستندسازی انجام شده است. این به سادگی یادداشت کردن یک لینک اینترنتی یا یک مرجع کتابشناختی است.4.2. تمرکز بر دانش خاصاز مستندات برای دانش خاص استفاده کنید و دانش عمومی را از آموزش‌ها یاد بگیرید. دانش خاص دانشی است که شرکت یا تیم شما دارد و هنوز با سایر همتایان در همان صنعت به اشتراک گذاشته نشده است. این دانش گران‌تر از دانش عمومی برای یادگیری است؛ زمان تمرین و اشتباه کردن را می‌طلبد. این نوع دانش است که بیشترین توجه را می‌طلبد. دانش خاص ارزشمند است و نمی‌تواند آماده‌‌ی استفاده یافت شود، بنابراین این نوع دانش است که باید به آن توجه کنید. دانش خاص بیشترین تلاش‌ها را از شما و همکارانتان می‌طلبد. به عنوان یک حرفه‌ای، باید به اندازه کافی از دانش استاندارد صنعتی عمومی بدانید تا بتوانید بر رشد دانش خاصی که به آرمان‌های خاص شما مربوط می‌شود تمرکز کنید. بنابراین: اطمینان حاصل کنید که همه در مورد دانش عمومی در صنعت شما آموزش دیده‌اند. سپس هر گونه تلاشی برای مستندسازی را بر روی دانش خاص متمرکز کنید.5. اطمینان از دقت مستندات:شما تنها در صورتی می‌توانید به مستندات اعتماد کنید که یک مکانیزم برای تضمین دقت آن وجود داشته باشد. وقتی صحبت از مستندات می‌شود، مشکل اصلی اغلب دقیق نبود آن‌ها است و دلیل اصلی عدم دقت کهنگی دانش است. مستنداتی که همیشه 100% دقیق نیست نمی‌تواند مورد اعتماد باشد. به محض این‌که بدانید مستندات ممکن است گاهی اوقات گمراه‌کننده باشد، اعتبار خود را از دست می‌دهد. ممکن است هنوز کمی مفید باشد، اما زمان بیشتری می‌طلبد تا بفهمید چه چیزی درست و چه چیزی نادرست است. وقتی نوبت به ایجاد مستنداتی می‌رسد که می‌دانید برای مدت طولانی دقیق نخواهند بود، سخت است زمانی به آن اختصاص دهید. طول عمر صحت مستندات یک انگیزه کُش بزرگ است. به‌روزرسانی مستندات یکی از وظایفیست که کمتر به آن ارج نهاده شده است. این نوشته‌ها جالب نیست و به نظر نمی‌رسد که ترغیب کننده باشد. با این حال، می‌توانید مستندات خوبی داشته باشید اگر آن را جدی بگیرید و تصمیم بگیرید که با یک مکانیزم خوب انتخاب شده برای تضمین دقت در هر زمان به آن رسیدگی کنید. بنابراین: شما باید در مورد چگونگی پرداختن به دقت مستندات خود فکر کنید.5.1. مکانیزم دقت برای مستندات قابل اعتمادهمان‌طور که قبلاً ذکر شد، دانش معتبر که می‌تواند مورد اعتماد باشد معمولاً در جایی وجود دارد، و در پروژه‌های نرم افزاری معمولاً به شکل کد است. بنابراین، دانش تکراری مشکل‌ساز است زیرا هزینه به‌روزرسانی آن برای همراهی با تغییرات را چند برابر می‌کند. این برای کد هر مصنوع دیگر نیز صدق می‌کند. ما معمولاً «طراحی» را به عنوان رشته‌ای که مطمئن می‌شود که تغییرات در هر نقطه‌ای از زمان ارزان باقی می‌ماند، می‌نامیم. ما به طراحی برای کد نیاز داریم و البته به همان مهارت‌های طراحی برای همه چیز درباره مستندات نیز نیاز داریم. یک رویکرد خوب برای مستندات مسئله طراحی است. طراحی مستندات که همیشه دقیق است بدون کند کردن کار توسعه نرم‌افزار مهارت‌های طراحی می‌طلبد. با دانشی که می‌تواند در هر زمان تغییر کند، تعدادی رویکرد برای نگه داشتن مستندات دقیق وجود دارد. آن‌ها در بخش‌های زیر توضیح داده شده‌اند، از مطلوب‌ترین تا کمترین مطلوب. بعدها شاید در نوشته‌هایی دیگر دقیق‌تر به این موارد پرداختیم.5.2. منبع واحد با یک مکانیزم انتشار:منبع واحد رویکردی است که هر زمان ممکن است ترجیح داده شود. با منبع واحد، دانش در یک منبع واحد نگهداری می‌شود که معتبر است. این مستندات به لطف یک مکانیزم انتشار خودکار به اشکال مختلف به عنوان اسناد منتشر شده و نسخه‌دار شده در دسترس قرار می‌گیرد. هر زمان که تغییری وجود دارد، در آنجا و تنها در آنجا به‌روزرسانی می‌شود. به عنوان مثال، کد منبع و فایل‌های پیکربندی اغلب خانه‌های طبیعی معتبر برای مقدار زیادی از دانش هستند. وقتی لازم است، دانش از چنین منبع واحدی استخراج و به شکل دیگری منتشر می‌شود، اما روشن است که تنها یک مکان معتبر وجود دارد. مکانیزم انتشار نیز باید خودکار باشد تا به طور مکرر اجرا شود؛ خودکارسازی مانع از ایجاد خطاهایی می‌شود که در مستندات دستی رایج است. حتی بدون نظرات اضافی، Javadoc یک مثال خوب از این رویکرد است: مستندات مرجع خود کد منبع است، همان‌طور که توسط Doclet Javadoc تجزیه می‌شود و به‌طور خودکار به عنوان یک وب‌سایت برای همه منتشر می‌شود تا ساختار رابط‌ها، کلاس‌ها و متدها، از جمله سلسله‌مراتب کلاس‌ها را به راحتی مرور کنند.5.3. منابع تکراری با یک مکانیزم انتشار:دانش ممکن است در مکان‌های مختلف تکرار شود، اما ابزارهای قابل اعتماد می‌توانند هر تغییری در یک مکان به همه مکان‌های دیگر منتشر کنند. بازسازی‌های خودکار در IDE شما بهترین مثال از این رویکرد است. نام کلاس‌ها، نام رابط‌ها و نام متدها در همه جا در کد تکرار می‌شوند، اما تغییر نام آن‌ها آسان است زیرا IDE می‌داند چگونه به‌طور قابل اعتماد هر مرجع را پیدا کرده و به درستی به‌روزرسانی کند. این بسیار برتر و ایمن‌تر از استفاده ازFind and Replace است، جایی که شما خطر جایگزینی رشته‌های تصادفی به اشتباه را دارید. به طور مشابه، ابزارهای مستنداتی مانندAsciiDoc مکانیزم‌های داخلی برای اعلام ویژگی‌هایی دارند که می‌توانید آن‌ها را در همه جای متن جاسازی کنید. به لطف برخی امکانات در ابزارها، می‌توانید نام‌ها را در یک مکان تغییر دهید و تغییر را به بسیاری از مکان‌ها با هیچ هزینه‌ای منتشر کنید.5.4. منابع تکراری با یک مکانیزم آشتی:اگر دانش در دو منبع اعلام شود، یک منبع ممکن است تغییر کند بدون این‌که منبع دیگر تغییر کند - و این یک مشکل است. نیازی به یک مکانیزمی داریم که هر زمان دو منبع مطابقت نداشتند این عدم تطابق را تشخیص دهیم. چنین مکانیزم آشتی باید خودکار و به طور مکرر اجرا شود تا اطمینان حاصل شود که همواره سازگاری وجود دارد. BDD با ابزارهای خودکار مانند Cucumber یک مثال از این رویکرد است. در این مورد، کد و سناریوها دو منبع دانش هستند و هر دو رفتار کسب‌وکار را توصیف می‌کنند. هر زمان که اجرای سناریوهای تست شکست می‌خورد، این یک سیگنال است که سناریوها و کد دیگر هماهنگ نیستند.5.5. ضد الگویی به نام تعهد انسانی:تعهد انسانی یک الگوی ضد است. اگر دانش در مکان‌های مختلف تکرار شود، گاهی اطمینان از سازگاری دانش ها به افراد تیم واگذار می‌شود و توقع این وجود دارد که افراد با کار زیاد و متعهدانه از این آزمون بزرگ سربلند خارج شوند. در عمل، این اتفاق نخواهد افتاد و هرگز پیشنهاد نمی‎شود.5.6. زمانی که مستندات به یک مکانیزم دقت نیاز ندارد: در برخی موارد، مانند بخش‌های زیر، نیازی به یک مکانیزم دقت برای مستندات خود ندارید.5.6.1. دانش یک بار مصرف:گاهی اوقات دقت فقط یک نگرانی نیست زیرا دانشی که ثبت می‌شود ظرف چند ساعت یا چند روز پس از استفاده دور انداخته می‌شود. این نوع دانش گذرا کهنه نمی‌شود و تکامل نمی‌یابد و بنابراین تا زمانی که برای مدت کوتاهی استفاده شود و بلافاصله پس از استفاده دور انداخته شود، نگرانی‌ای درباره‌ی سازگاری آن وجود ندارد. 5.6.2. حساب‌هایی از گذشتهیک حساب از رویدادهای گذشته، مانند یک پست وبلاگ، موضوع دقت نیست زیرا برای خواننده واضح است که هیچ وعده‌ای برای همیشه دقیق بودن متن وجود ندارد. هدف از پست ممکن است، به عنوان مثال، توصیف یک موقعیت همان‌طور که اتفاق افتاده است، شامل تفکرات در زمان و احساسات مرتبط. چنین دانشی که در یک نقطه زمانی دقیق است و در زمینه آن نقطه زمانی ثبت شده است به عنوان مستندات کهنه در نظر گرفته نمی‌شود. دانش در پست وبلاگ به مرور زمان قدیمی می‌شود، اما این مشکلی نیست زیرا واضح است که این پست مربوط به اتفاقی در گذشته است. این یک راه هوشمندانه برای آرشیو کردن قسمت‌های کاری و ایده‌ی بزرگ پشت یک داستان به صورت پایدار است، بدون این‌که تظاهر کند همیشه جدید است. یک پست وبلاگ کسی را گمراه نمی‌کند تا فکر کند که اطلاعات جدید است زیرا واضح است که این یک حساب از یک تفکر گذشته است. به عنوان یک داستان که در گذشته لنگر انداخته است، همیشه یک داستان دقیق است، حتی اگر نتوانید به کد یا مثال‌های خاصی که ممکن است نقل شده باشد اعتماد کنید. این کار مانند خواندن یک کتاب تاریخی است و درس‌های ارزشمندی در آن وجود دارد که می‌توان آموخت، بدون توجه به زمینه‌ای که در آن اتفاق افتاده‌اند. بدترین چیزی که می‌تواند برای یک حساب از گذشته اتفاق بیفتد این است که ممکن است وقتی که نگرانی‌های آن زمان دیگر نگرانی نیستند، بی‌ربط شود.6. سوالات بزرگ برای به چالش کشیدن مستندات شما:هر دقیقه‌ای که برای نوشتن مستندات صرف می‌شود، دقیقه‌ای است که برای کارهای دیگر از دست رفته است. آیا این مستند ارزش افزوده دارد؟ تصور کنید که رئیس یا مشتری شما درخواست «مستندات بیشتر» کند. تعدادی سوال مهم وجود دارد که باید پرسیده و پاسخ داده شود تا تصمیم بگیرید چه کاری باید انجام دهید. هدف از این سوالات این است که مطمئن شوید که در بلندمدت وقت خود را به کارآمدترین شکل ممکن استفاده می‌کنید. ترتیبی که سوالات مهم زیر را می‌پرسید بستگی به وضعیت دارد و می‌توانید سوالات را به دلخواه خود رد یا ترتیب دهید. بخش‌های زیر فرآیند فکری دخیل در تعیین چگونگی انجام مستندات را توضیح می‌دهد و پس از درک آن، می‌توانید فرآیند را به روش خود انجام دهید.6.1. پرسیدن نیاز به مستندات در همه موارد:مستندات به خودی خود هدف نیست؛ بلکه وسیله‌ای برای هدفی است که باید شناسایی شود. نمی‌توانید چیزی مفید ایجاد کنید مگر این‌که هدف را بفهمید. بنابراین اولین سوال این است:چرا به این مستندات نیاز داریم؟اگر به راحتی پاسخی به دست نیاید، پس قطعاً آماده‌ی سرمایه‌گذاری برای مستندات اضافی نیستید. باید موضوع را به حالت تعلیق درآورید تا زمانی که بهتر بدانید. نمی‌خواهید وقت خود را برای اهداف نامشخص هدر دهید. سپس سوال بعدی بلافاصله به دنبال آن می‌آید:چه کسی مخاطب هدف است؟اگر پاسخ نامشخص یا شبیه به «همه» باشد، پس آماده‌ی شروع هیچ کاری نیستید. مستندات کارآمد باید به یک مخاطب خاص هدفمند باشد. حتی مستنداتی درباره‌ی چیزهایی که «همه باید بدانند» باید به یک مخاطب خاص هدفمند باشد، مانند «افراد غیر فنی با دانش سطحی از دامنه کسب‌وکار». اکنون، همچنان که مصمم به جلوگیری از هدررفت زمان هستید، آماده‌ی اولین سوال از مستندات هستید.اولین سوال مستندات: آیا واقعاً به این مستندات نیاز داریم؟ممکن است کسی وسوسه شود که مستنداتی درباره موضوعی ایجاد کند که فقط برای خودش مفید باشد یا فقط در زمان کار بر روی آن مرتبط باشد. شاید حتی اضافه کردن یک پاراگراف به ویکی هم خیلی منطقی نباشد. اما دلیل بدتر دیگری برای درخواست مستندات وجود دارد.6.2. نیاز به مستندات به دلیل فقدان اعتماد:پاسخ به اولین سوال مستندات ممکن است شبیه به این باشد: «من به مستندات نیاز دارم زیرا می‌ترسم که به اندازه‌ی کافی کار نمی‌کنید، بنابراین باید تحویل‌های شما را ببینم تا مطمئن شوم که به اندازه کافی سخت کار می‌کنید.» در این صورت، مشکل اصلی مسئله مستندات نیست.همان‌طور که مت وین (@mattwynne) و سب رز (@sebrose) در کنفرانس BDD eXchange در سال 2013 گفتند: «نیاز به جزئیات ممکن است نشان‌دهنده‌ی فقدان اعتماد باشد.» در چنین مواردی، فقدان مستندات فقط یک علامت است و مسئله‌ی اصلی فقدان اعتماد است. این مسئله‌ای جدی است که باید ابتدا به آن پرداخته شود و هیچ مقداری از مستندات نمی‌تواند به تنهایی مشکل فقدان اعتماد را حل کند. با این حال، از آنجایی که ارائه‌ی ارزش به طور مکرر راهی برای ساخت اعتماد است، مستندات معقول نیز می‌تواند نقش جانبی در بهبود وضعیت داشته باشد. برای مثال، شفاف کردن کار ممکن است به ساخت اعتماد کمک کند و این نیز نوعی مستندات است.6.3. مستندات در لحظه یا گزینه ارزان برای دانش آینده:اگر به مستندات نیاز دارید، ممکن است واقعاً در همان لحظه به آن نیاز نداشته باشید. بنابراین، یک سوال دیگر به عنوان اولین سوال مستندات وجود دارد.آیا واقعاً به این مستندات در حال حاضر نیاز داریم؟ایجاد مستندات هزینه دارد و مزیت آن در آینده نامشخص است. مزیت نامشخص است وقتی نمی‌توانید مطمئن باشید که کسی در آینده به این اطلاعات نیاز خواهد داشت.یکی از چیزهایی که من در طول سال‌ها در توسعه‌ی نرم‌افزار آموخته‌ام این است که مردم در پیش‌بینی آینده ذاتا بد هستند. معمولاً مردم فقط می‌توانند شرط‌بندی کنند و شرط‌بندی‌های آن‌ها اغلب نادرست است. بنابراین، مهم است که از تعدادی استراتژی برای تعیین زمان مهم بودن مستندات استفاده کنید:درست در لحظه: فقط زمانی که واقعاً نیاز دارید، مستندات را اضافه کنید.ارزان در ابتدا: اکنون مستندات کمی اضافه کنید، با هزینه‌ای بسیار کم.گران در ابتدا: اکنون مستندات را اضافه کنید، حتی اگر زمان زیادی برای ایجاد آن نیاز باشد.6.3.1. درست در لحظه:ممکن است با توجه به عدم قطعیت اینکه در آینده مفید خواهد بود یا نه، تصمیم بگیرید که مستندسازی اکنون ارزش هزینه‌ی آن را ندارد. در این صورت، ممکن است انجام مستندات را تا زمانی که واقعاً لازم باشد به تعویق بیاندازید. به طور معمول، ایده‌ی خوبی است که صبر کنید تا کسی درخواست مستندات کند. در یک پروژه‌ی بزرگ با تعداد زیادی ذینفع، حتی ممکن است تصمیم بگیرید تا درخواست دوم یا سوم صبر کنید قبل از اینکه زمان و تلاش برای ایجاد مستندات را ارزشمند بدانید.توجه داشته باشید که این رویکرد فرض می‌کند هنگامی که زمان به اشتراک گذاری دانش فرا می‌رسد، شما هنوز هم دانش را در تیم موجود دارید. همچنین فرض می‌کند که تلاش برای مستندسازی در آینده در مقایسه با الان خیلی زیاد نخواهد بود.6.3.2. ارزان در ابتدا:ممکن است تصمیم بگیرید که هزینه‌ی مستندسازی در حال حاضر آنقدر کم است که ارزش به تعویق انداختن آن برای بعد را ندارد، حتی اگر هرگز استفاده نشود. این موضوع به خصوص زمانی صادق است که دانش تازه در ذهن است و شما ریسک فراموشی تمام جزئیات مهم را در آینده دارید. و البته، ایجاد مستندات در ابتدا معنی دارد اگر شما راه‌های ارزان برای انجام آن دارید.6.3.3. گران در ابتدا: ممکن است تصمیم بگیرید که ارزش دارد بر روی نیاز آینده به این دانش شرط‌بندی کنید و انتخاب کنید که مستندات را همین حالا ایجاد کنید، حتی اگر انجام آن ارزان نباشد. در این صورت، ریسک این وجود دارد که ممکن است یک هدررفت باشد، اما شما ممکن است خوشحال باشید که این ریسک را بپذیرید - امیدوارم به دلایلی مستند (مثلاً دستورالعمل‌ها یا نیازهای قانونی، اعتماد بالا از بیش از یک نفر که این لازم است).مهم است که به یاد داشته باشید که هر تلاشی برای مستندات در حال حاضر نیز بر کیفیت کار تأثیر می‌گذارد زیرا بر نحوه انجام آن و دلایل آن تمرکز می‌کند و مانند یک بازبینی عمل می‌کند. این به این معنی است که حتی اگر در آینده هرگز استفاده نشود، حداقل یک بار، در حال حاضر، برای فکر کردن دقیق درباره‌ی تصمیمات و منطق پشت آن‌ها مفید است.6.4. پرسیدن نیاز به مستندات سنتی: فرض کنیم که برای یک هدف مشخص و برای یک مخاطب مشخص، نیاز به مستندات اضافی وجود دارد. اکنون آماده‌ی دومین سوال از مستندات هستید.سوال دوم مستندات- آیا می‌توانیم فقط از طریق گفتگوها یا کار کردن با هم دانش را به اشتراک بگذاریم؟مستندات سنتی هرگز نباید انتخاب پیش‌فرض باشد، زیرا بیش از حد هدررفت دارد مگر اینکه کاملاً ضروری باشد. وقتی نیاز به انتقال دانش از برخی افراد به افراد دیگر وجود دارد، بهترین راه حل این است که به سادگی صحبت کنید - با پرسیدن و پاسخ دادن به سوالات به جای تبادل اسناد نوشته شده.کار کردن به صورت جمعی، با گفتگوهای مکرر، یک شکل مستندات به خصوص مؤثر است. تکنیک‌هایی مانند برنامه‌نویسی جفتی، برنامه‌نویسی متقاطع، سه دوست در اجایل بازی را با توجه به مستندات تغییر می‌دهند، زیرا انتقال دانش بین افراد در همان زمانی که دانش ایجاد یا اعمال می‌شود، به صورت مداوم انجام می‌شود.گفتگوها و کار کردن به صورت جمعی از اشکال ترجیحی مستندات هستند، اگرچه گاهی اوقات کافی نیستند. گاهی اوقات نیاز واقعی به داشتن دانش به صورت رسمی وجود دارد.به چالش کشیدن نیاز به مستندات رسمی:آیا باید پایدار باشد؟ آیا باید به تعداد زیادی از افراد به اشتراک گذاشته شود؟ آیا دانش حیاتی است؟اگر پاسخ به هر یک از این سوالات «نه» باشد، گفتگوها و کار کردن به صورت جمعی باید کافی باشد و نیازی به مستندات رسمی بیشتر وجود ندارد.البته، اگر این سوالات را از یک مدیر بپرسید، احتمالاً پاسخ «بله» خواهد بود زیرا این یک انتخاب ایمن است. شما نمی‌توانید با انجام بیشتر اشتباه کنید، درست است؟ این کار مانند تعیین اولویت بر روی وظایف است؛ بسیاری از افراد بر روی همه چیز پرچم اولویت بالا می‌گذارند، که سپس اولویت بالا را بی‌معنی می‌کند. با مستندات، چیزی که به نظر می‌رسد انتخاب ایمن است، هزینه بالاتری دارد که می‌تواند پروژه را به خطر بیاندازد. انتخاب ایمن واقعاً این است که این سه سوال را به روشی متعادل در نظر بگیرید نه این که به صورت خودکار «بله» یا «نه» پاسخ دهید.حتی برای دانش‌هایی که باید با تعداد زیادی از افراد به اشتراک گذاشته شود، باید برای مدت طولانی پایدار بماند یا حیاتی است، چندین گزینه مستندات وجود دارد:جلسه‌ی عمومی با همه‌ی شرکت‌کنندگان، یا یک سخنرانی به سبک کنفرانس با شرکت‌کنندگان که امیدواریم یادداشت‌برداری کنند.پادکست یا ویدیو، مانند یک سخنرانی کنفرانس ضبط شده یا یک مصاحبه ضبط شدهمصنوعاتی که به خودی خود مستند هستند یا به صورت داخلی مستند شده‌اندسند نوشته شده به صورت دستی نکته این است که حتی برای دانش‌های بسیار مهم، مستندات نوشته شده به صورت دستی نباید انتخاب پیش‌فرض باشد.6.5. به حداقل رساندن کار اضافی در حال حاضر:فرض کنید که نیاز مشروع به نگهداری برخی دانش‌ها به صورت رسمی وجود دارد. از آنجا که، همان‌طور که یاد گرفته‌اید، بیشتر دانش قبلاً در جایی وجود دارد، شما باید به سوال دیگری پاسخ دهید.دانش در حال حاضر کجا است؟اگر دانش فقط در ذهن افراد است، پس نیاز است که به صورت متنی، کد، متاداده یا چیز دیگری رمزگذاری شود. اگر دانش قبلاً در جایی نمایندگی شده است، ایده این است که تا حد ممکن از آن نسخه استفاده کنید (بهره‌برداری از دانش) یا از آن دوباره استفاده کنید (افزایش دانش) . ممکن است شما بتوانید از دانش موجود در کد منبع، در فایل‌های پیکربندی، در تست‌ها، در رفتار برنامه در زمان اجرا و شاید در حافظه‌ی ابزارهای مختلف درگیر استفاده کنید. این فرآیند، که به تفصیل بیشتری نیاز دارد، شامل پرسیدن سوالات زیر است:آیا دانش قابل بهره‌برداری است، یا مبهم یا غیرقابل بازیابی؟آیا دانش بیش از حد زیاد است؟آیا دانش برای مخاطب هدف قابل دسترسی است؟آیا دانش در یک مکان واحد است یا پراکنده؟چه چیزی از دست رفته است که دانش را 100% صریح کند؟ وقتی دانش به طور کامل وجود ندارد یا برای قابل استفاده بودن بیش از حد ضمنی است، بازی پیدا کردن راهی برای افزودن دانش به صورت مستقیم در منبع محصول است. 6.6. به حداقل رساندن کار اضافی در آینده:تنها یک بار ایجاد مستندات کافی نیست؛ شما باید در نظر بگیرید که چگونه آن را به مرور زمان دقیق نگه دارید. بنابراین، یک سوال مهم باقی می‌ماند.این دانش چقدر پایدار است؟دانش پایدار آسان است زیرا می‌توانید مسئله‌ی نگهداری آن را نادیده بگیرید. در سوی دیگر طیف، دانش زنده چالش‌برانگیز است. این دانش می‌تواند به طور مکرر یا در هر زمانی تغییر کند و نمی‌خواهید بارها و بارها مصنوعات و اسناد دیگر را به‌روزرسانی کنید. نرخ تغییر معیار مهمی است. دانشی که برای سال‌ها پایدار است می‌تواند با هر شکل نگهداری شود، مانند نوشتن متن به صورت دستی و چاپ آن روی کاغذ. دانشی که برای سال‌ها پایدار است حتی می‌تواند مقدار کمی از تکرار را تحمل کند زیرا نیاز به به‌روزرسانی نخواهد داشت. در مقابل، دانشی که هر ساعت یا بیشتر تغییر می‌کند نمی‌تواند اشکال سنتی مستندات را تحمل کند. نگرانی‌های کلیدی برای حفظ آن به حداقل رساندن هزینه‌ی تکامل و نگهداری مستندات است. تغییر کد منبع و سپس نیاز به به‌روزرسانی دستی سایر اسناد گزینه‌ی مناسبی نیست. این فرآیند، شامل پرسیدن سوالات زیر است:اگر تغییر کند، چه چیزی در همان زمان تغییر می‌کند؟اگر دانش تکراری وجود دارد، چگونه منابع تکراری را همگام نگه می‌داریم؟7. تبدیل یک فعالیت به فعالیتی سرگرم‌کننده: برای پایدار نگه داشتن یک فعالیت، آن را سرگرم‌کننده کنید. سرگرم‌کننده بودن برای شیوه‌های پایدار مهم است. اگر چیزی سرگرم‌کننده نباشد، کسی نمی‌خواهد آن را دائما انجام دهد آن چیز به تدریج از بین می‌رود. برای پایداری شیوه‌ها، آن‌ها باید سرگرم‌کننده باشند. این نکته، به خصوص در مورد موضوع خسته‌کننده‌ای مانند مستندات اهمیت دارد. بنابراین: شیوه‌های مستندات زنده‌ای را انتخاب کنید که تا حد ممکن سرگرم‌کننده باشند. اگر چیزی سرگرم‌کننده است، بیشتر آن را انجام دهید و اگر اصلاً سرگرم‌کننده نیست، به دنبال گزینه‌های دیگری باشید، مانند حل مسئله به روش دیگر یا از طریق خودکارسازی. این ترجیح برای فعالیت‌های سرگرم‌کننده قطعاً فرض می‌کند که کار با مردم در طرف سرگرم‌کننده قرار دارد زیرا هیچ راه خوبی برای دور زدن این موضوع وجود ندارد. برای مثال، اگر برنامه‌نویسی برای شما سرگرم‌کننده است، شما سعی خواهید کرد تا حد ممکن در کد مستند کنید. این ایده پشت بسیاری از پیشنهادات در این نوشته است. اگر کپی کردن اطلاعات از یک مکان به مکان دیگر یک کار خسته‌کننده است، پس این یک کاندید برای خودکارسازی است یا یافتن راهی برای جلوگیری از نیاز به جابجایی داده‌ها. اصلاح یک فرآیند و خودکارسازی بخشی از یک فرآیند معمولاً سرگرم‌کننده است، بنابراین این‌ها نیز چیزهایی هستند که ممکن است بخواهید انجام دهید - و این خوش‌شانسی است.7.1. ترکیب سرگرمی و حرفه‌ای بودن: تا زمانی که در کار خود حرفه‌ای باشید، هیچ مشکلی در داشتن سرگرمی در کار وجود ندارد. این به معنای انجام بهترین تلاش برای حل مشکلاتی است که اهمیت دارند. یعنی ارائه ارزش و کاهش خطر انجام می‌شود. با این ذهنیت، شما آزادید که شیوه‌ها و ابزارهایی را انتخاب کنید که زندگی شما را سرگرم‌کننده‌تر می‌کنند. پس از 21 سال برنامه‌نویسی، اکنون مطمئنم که همیشه می‌توان کار حرفه‌ای انجام داد در حالی که سرگرم هم بود. ایده این‌که کار باید خسته‌کننده و ناخوشایند باشد زیرا کار است یا زیرا برای این ناخوشایندی جبران می‌شوید، احمقانه است. شما پولی دریافت می‌کنید تا ارزشی ارائه دهید که حتی بیشتر از پولی است که دریافت می‌کنید. ارائه ارزش سرگرم‌کننده است و رفتار حرفه‌ای نیز دلپذیر است. و سرگرم‌کننده بودن برای کار کارآمد به عنوان یک تیم در یک جو دلپذیر ضروری است.8. مستندات زنده: نسخه بسیار کوتاه:اگر فقط می‌خواهید در یک دقیقه بدانید مستندات زنده چیست، لطفاً به ایده‌های بزرگ زیر توجه کنید:مکالمات و کار کردن با هم را به هر نوع سندی ترجیح دهید. بیشتر دانش در حال حاضر آنجاست و فقط نیاز به آزاد شدن دارد.بیشتر دانش در حال حاضر آنجاست. شما فقط باید آن را با زمینه، قصد و منطق گمشده تکمیل کنید.به فراوانی تغییرات توجه کنید.فکر کردن به مستندات راهی برای جلب توجه به کیفیت یا فقدان آن در سیستم است. اگر این لیست به اندازه‌ی کافی واضح است، شما پیام کلیدی این نوشته را درک کرده‌اید.8.1. رویکردهایی برای مستندات بهترراه‌های زیادی برای در نظر گرفتن موضوع مستندات وجود دارد. این رویکردها یک طیف کامل را پوشش می‌دهند که می‌توان آن را به عنوان یک چرخه در نظر گرفت که از اجتناب از مستندات تا مستندات حداکثری و سپس فراتر، به سوال دوباره از نیاز به مستندات و چرخش چرخه به سمت مستندات کمتر دوباره پیش می‌رود. شما همچنین می‌توانید این چرخه را به عنوان رفتن از رویکردهای سبک به رویکردهای سنگین‌تر ببینید.این چرخه شامل نرخ تغییر (نوسان) دانش مورد بحث، از دانش پایدار تا دانشی که به طور مداوم تغییر می‌کند، است.8.2. دسته‌های رویکردهای مستندات:اجتناب از مستندات: بهترین مستندات اغلب هیچ مستنداتی نیست زیرا دانش ارزش هیچ تلاشی بیش از انجام کار ندارد. همکاری با گفتگو یا کار جمعی در اینجا کلیدی است. گاهی اوقات می‌توانید حتی بهتر عمل کنید و به جای کار با مستندات، بهبود وضعیت زیربنایی را انجام دهید. مثال‌ها شامل خودکارسازی و رفع مشکلات اصلی هستند.مستندات پایدار: همه‌ی دانش‌ها همیشه تغییر نمی‌کنند. دانش وقتی به اندازه‌ی کافی پایدار باشد، مستندات بسیار ساده‌تر و مفیدتر می‌شود. گاهی اوقات فقط یک گام برای رفتن از تغییر یک قطعه دانش به یک قطعه پایدارتر وجود دارد - و این نوع فرصتی است که می‌خواهید از آن بهره ببرید.مستندات قابل بازسازی: کد، تست‌ها، متن ساده و غیره فرصت‌های خاصی را برای تکامل مداوم در هماهنگی فراهم می‌کنند، به لطف قابلیت‌های بازسازی ابزارهای مدرن IDE. مستندات قابل بازسازی امکان مستندات دقیق با هزینه‌ی کم یا هیچ هزینه‌ای را فراهم می‌کند.خودکارسازی مستندات: خودکارسازی مستندات حوزه‌ای است که به شدت به آن علاقه‌مند هستم، شامل استفاده از ابزارهای خاص برای تولید مستندات به طور خودکار به صورت زنده و همگام با تغییرات در ساخت نرم‌افزار. یک طعم خاص از خودکارسازی مستندات شامل هر رویکردی است که در زمان اجرا، زمانی که نرم‌افزار در حال اجرا است، عمل می‌کند؛ این رویکرد در مقابل سایر رویکردهایی است که در زمان ساخت کار می‌کنند.فراتر از مستندات: در نهایت، به فراتر از حوزه مستندات می‌رسیم، جایی که فرصت داریم همه چیز را به سوال بکشیم و تصدیق کنیم که موضوع مستندات می‌تواند فوایدی فراتر از انتقال و ذخیره دانش داشته باشد. این جایی است که به روشنایی می‌رسیم و هر رویکرد و تکنیک دیگر را به طور انتقادی دوباره بررسی می‌کنیم. این جنبه از مستندات زنده بیشتر انتزاعی، اما مهم است. از طریق شیوه‌های مستندات زنده که توجه شما را به کارتان جلب می‌کند، کیفیت کار نیز به عنوان یک اثر جانبی بهبود می‌یابد.9. دروازه‌ای به طراحی مبتنی بر دامنه (DDD):با سرمایه‌گذاری در مستندات زنده می‌توانید به طراحی مبتنی بر دامنه نزدیک‌تر شوید. مستندات زنده می‌تواند به هدایت تیم یا مجموعه‌ای از تیم‌ها در پذیرش شیوه‌های DDD کمک کند. این رویه به ملموس کردن این شیوه‌ها و تمرکز برخی از توجهات بر روی مصنوعات حاصل کمک می‌کند. البته، نحوه‌ی کار شما با ذهنیت DDD بسیار مهم‌تر از مصنوعات حاصل است. با این حال، مصنوعات می‌توانند حداقل کمک کنند تا DDD را تجسم کنید و می‌توانند به نمایان کردن هر شیوه‌ی مشکل‌دار و ارائه راهنمایی در مورد میزان خوب انجام شدن آن کمک کنند.9.1. طراحی مبتنی بر دامنه به طور خلاصه:طراحی مبتنی بر دامنه رویکردی برای مواجهه با پیچیدگی در قلب توسعه‌ی نرم‌افزار است. این رویکرد به شدت بر تمرکز کامل روی دامنه‌ی کسب‌وکار خاصی که مورد بررسی قرار می‌گیرد، تأکید می‌کند. این شیوه نوشتن کدی که به طور مستقیم دانش دامنه را بیان می‌کند، بدون هیچ گونه ترجمه‌ای بین تحلیل دامنه و کد اجرایی را ترویج می‌کند. به این ترتیب، DDD فراخوانی است برای مدل‌سازی به طور مستقیم در کدی که به زبان برنامه‌نویسی نوشته شده است، در مقابل بسیاری از ادبیات‌های مدل‌سازی دیگر. این اتفاق تنها در صورتی ممکن است که امکان گفتگوهای مکرر و نزدیک با کارشناسان دامنه وجود داشته باشد، با این‌که همه از همان زبان همه‌گیر که زبان دامنه‌ی کسب‌وکار است استفاده می‌کنند.طراحی مبتنی بر دامنه به تمرکز تلاش‌ها بر روی هسته‌ی اصلی دامنه دعوت می‌کند، یعنی باید روی آن حوزه‌ی کسب‌وکاری که پتانسیل ایجاد تفاوت در برابر رقبا را دارد تمرکز کنیم. به این ترتیب، DDD تشویق می‌کند که توسعه‌دهندگان نه تنها کد را تحویل دهند بلکه به عنوان شرکا با کسب‌وکار در یک رابطه دوطرفه سازنده همکاری کنند که در آن توسعه‌دهندگان به درک عمیق از کسب‌وکار برسند و بینش‌هایی در مورد مهم‌ترین مسائل نیز کسب کنند.9.2. مستندات زنده به عنوان کاربردی از DDD:مستندات زنده نه تنها از DDD پشتیبانی می‌کند بلکه به خودی خود نمونه‌ای از به‌کارگیری رویکرد DDD در دامنه مدیریت دانش در طول چرخه عمر آن است. و در بسیاری از موارد، مستندات زنده نمونه‌ای از به‌کارگیری مستقیم DDD تحت نام کمی متفاوت است.9.3. داستان ریشه‌های مشترک بینBDD، DDD، XP و مستندات زنده:اصطلاح مستندات زنده توسط گویکو آدزیک در کتاب «مشخصات بر اساس مثال»، که کتابی در مورد توسعه مبتنی بر رفتار (BDD) است، معرفی شد. BDD یک رویکرد شامل همکاری بین همه افراد درگیر در توسعه نرم‌افزار است که توسط دن نورث پیشنهاد شد، کسی که ایده را با ترکیب توسعه مبتنی بر تست (TDD) با زبان همه‌گیر طراحی مبتنی بر دامنه (DDD) معرفی کرد. به همین دلیل، حتی اصطلاح مستندات زنده نیز ریشه‌هایی در طراحی مبتنی بر دامنه دارد!9.4. تنایج مستندات زنده:توجه کنید که مستندات زنده به شدت به اصول زیر ازDDD پایبند است:کد به عنوان مدل: کد مدل است (و بالعکس)، بنابراین می‌خواهید تا حد ممکن دانش مدل در کد باشد - و این، به تعریف، مستندات است.تکنیک‌های تاکتیکی برای بیان تمام دانش با کد: شما می‌خواهید از زبان‌های برنامه‌نویسی حداکثر استفاده را کنید تا دانش را بیان کنید..تکامل مداوم دانش با چرخه DDD: پردازش دانش عمدتاً مسئله‌ای از همکاری بین کارشناسان دامنه کسب‌وکار و تیم توسعه است. از طریق این فرآیند، برخی از مهم‌ترین دانش به کد و شاید به برخی از مصنوعات دیگر منتقل می‌شود. از آنجا که همه‌ی دانش‌ها تکامل می‌یابند یا ممکن است در هر زمانی تکامل یابند، هر دانش مستند شده باید بدون موانعی مانند هزینه نگهداری، تغییر را بپذیرد.مشخص کردن آنچه مهم است و آنچه نیست: به عبارت دیگر، باید بر روی مدیریت دانش تمرکز کرد. «تمرکز بر هسته دامنه» و «برجسته کردن مفاهیم اصلی» از کتاب DDD اریک اوانز است، اما با وجود محدودیت‌های حافظه و توانایی شناختی انسانی، کارهای خیلی بیشتری را می‌توان با مدیریت دانش انجام داد تا دانش را تحت کنترل نگه داشت.توجه به جزئیات: بسیاری از الگوهای DDD تأکید می‌کنند که توجه به جزئیات مهم است. تصمیم‌ها باید با دقت و غیرتصادفی باشند و باید با بازخورد ملموس هدایت شوند. رویکرد مستندات زنده باید توجه به جزئیات را با آسان‌تر کردن مستندسازی تصمیم‌های دقیق و ارائه بازخورد بینش‌آمیز در طول فرآیند تشویق کند.طراحی استراتژیک و ساختارهای بزرگ‌مقیاس: DDD تکنیک‌هایی برای مدیریت دانش در سطح استراتژیک و در مقیاس بزرگ ارائه می‌دهد، که فرصت‌هایی برای مستندات هوشمندتر نیز فراهم می‌کند.خلاصه:مستندات زنده همه چیز درباره توجه به دانش درگیر در ساخت نرم‌افزار است. برخی دانش‌ها مهم‌تر از سایر دانش‌ها هستند و مهم‌ترین دانش تقریباً به طور قطع در جایی در مصنوعات پروژه وجود دارد. هدف و سرگرمی مستندات زنده شناسایی دانش با ارزش، جایی که در حال حاضر وجود دارد، و تعیین آنچه ممکن است از دست رفته باشد و اینکه چگونه اغلب تغییر می‌کند تا بهترین بهره‌برداری را از آن با حداقل هزینه ببرید. به عبارت دیگر، این موضوع درباره‌ی طراحی یک سیستم دانش درون پایگاه کد خود است و نیاز به مهارت‌های طراحی دارد، درست مانند کدنویسی. علیرضا ارومند علیرضا ارومند Mon, 24 Jun 2024 18:20:29 +0330 https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D9%87%D8%B4%D8%AA%D9%85-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%88-%D8%A8%D8%A7%D8%B2%D9%86%DA%AF%D8%B1%DB%8C-%D8%AF%D8%B1-%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-qevv16einqty 1. مقدمه:مستندات را فراموش و سرعت تولید نرم‌افزار را بالا ببرید. شما می‌خواهید نرم‌افزار را سریع‌تر تحویل دهید. اما قرار نیست فقط در ابتدای راه سرعت کار بالا باشد، باید به گونه‌ای رفتار کنیم که در طولانی مدت نیز سرعت کار حفظ شود. از منظری دیگر اگر به کار نگاه کنیم قرار نیست تنها شما سریع کار کنید، بلکه همه همکاران و کل شرکت باید بتوانند با سرعتی معقول کار انجام دهند. وقتی در مورد تولید نرم‌افزار صحبت می‌کنیم، در ابتدا بیشتر به زبان‌ها و فریمورک‌های برنامه‌نویسی مولدتر، ابزارهای بهتر و مهارت‌های بالاتر می‌اندیشیم. اما هرچه صنعت در همه این جنبه‌ها پیشرفت می‌کند، باید به سایر گلوگاه‌ها نیز نگاه کنیم. توسعه‌ی نرم‌افزار فراتر از فناوری است و در اغلب موارد به تصمیم‌گیری‌های مبتنی بر دانش وابسته است. وقتی دانش کافی ندارید، باید آموزش ببینید و دائما آزمایش‌های آموزشی انجام دهید و با دیگران همکاری کنید تا دانش جدیدی به دست آورید. این فرایند زمانگیراست، که به این معنی است که این دانش گران‌قیمت و ارزشمند است. سریع پیش رفتن یعنی هنگامی که نیاز به دانش جدیدی دارید آن را خیلی سریع به دست آورید یا اگر از قبل دانشی را داشتید هنگام نیاز خیلی سریع توانایی بازیابی آن را داشته باشید. اجازه دهید این موضوع را با داستانک‌هایی توضیح دهیم.2. قصه‌هایی از سرزمین موعود:تصور کنید یک پروژه نرم‌افزاری برای توسعه یک برنامه جدید به عنوان بخشی از یک سیستم اطلاعاتی بزرگتر در شرکت شما در حال توسعه است و شما توسعه‌دهنده‌ای در این پروژه هستید. وظیفه شما اضافه کردن مدل جدید تخفیف برای مشتریان وفادار جدید است.2.1. یک ملاقات کاری:شما با محمد از تیم بازاریابی و رضا، از تیم تست جلسه دارید و شروع به صحبت در مورد ویژگی جدید، پرسیدن سوالات و جستجوی مثال‌های عینی می‌کنید. رضا می‌پرسد: «چرا این ویژگی؟» محمد توضیح می‌دهد که دلیل آن این است که به مشتریان وفادار جدید پاداش بدهیم تا از طریق رویکرد بازی‌سازی، نگهداری مشتریان را افزایش دهیم و یک لینک در ویکی‌پدیا در مورد آن موضوع نمایش می‌دهد. رضا در مورد نکات اصلی و سناریوهای اصلی یادداشت‌برداری می‌کند. همه این‌ اتفاقات سریع پیش می‌رود زیرا همه دور یک میز هستید و ارتباط بسیار ساده است. همچنین، مثال‌های واقعی، فهم و روشن کردن هر چیز مبهمی را ساده‌تر می‌کند. وقتی همه چیز روشن شد، همه به کار خود بر می‌گردند. نوبت رضا است که مهم‌ترین سناریوها را نوشته و آن‌ها را برای همه ارسال کند. (دفعه قبل نوبت محمد بود.) حالا شما می‌توانید کدنویسی را آن شروع کنید. در تجربه‌ی کاری قبلی شما، فرآیند این‌گونه نبود. تیم‌ها از طریق مستنداتی که پر از ابهامات بود و خوانش سختی داشت با یکدیگر ارتباط برقرار می‌کردند.لبخندی از سر رضایت می‌زنید. به سرعت اولین سناریو را به یک تست پذیرش خودکار تبدیل می‌کنید، می‌بینید که شکست خورد و شروع به نوشتن کد می‌کنید تا آن تست موفق شود. احساس خوبی دارید که می‌توانید زمان ارزشمند خود را بر روی چیزهای مهم صرف کنید و از حاشیه‌های دور هستید.2.2. فقط یک روز بهش نیاز دارم:بعدازظهر، دو نفر از همکاران، حسین و امیر، از تیم در مورد تصمیمی که در زمینه طراحی باید گرفته شود، سوال می‌کنند. کنار تخته وایت برد می‌روید و طرح‌های ممکن مختلف را کشیده و ارزیابی می‌کنید. نیازی به استفاده از UML و ابزارهای رسمی نیست و صرفا چند مربع و فلش کار شما را راه می‌اندازد. هدف انجام کاری رسمی نیست، فقط می‌خواهید مطمئن شوید که همه درک مشترکی از طرح‌ها دارید. چند دقیقه بعد یک راه حل انتخاب می‌شود. در مورد موضوع پیام رسانی در دو بخش مختلف گفتگو می‌کنید و در نهایت تصمیم می‌گیرید از دو کانال مختلف برای ارسال پیام استفاده کنید چون نیاز به جداسازی کامل بین سفارش‌های ورودی و درخواست‌های حمل و نقل است. امیر از تخته عکس می‌گیرد چون ممکن است کسی تخته را پاک کند. او می‌داند که در کمتر از یک روز، پیاده‌سازی انجام خواهد شد و سپس می‌تواند با خیال راحت عکس را از گوشی خود پاک کند. یک ساعت بعد، وقتی پیاده سازی انجام شد، هنگام Commit کردن او دقت می‌کند ک «جداسازی بین سفارش‌های ورودی و درخواست‌های حمل و نقل» را روی Commit به درستی ثبت کند. روز بعد، وحید که دیروز مرخصی بود، متوجه تغییر در کد می‌شود و می‌خواهد بداند چرا این اتفاق افتاده است. او git blame را اجرا کرده و بلافاصله پاسخ را دریافت می‌کند.2.3. مستندات بازاریابی نداریم:مدیر بازاریابی جدیدی به نام داوود وارد شرکت می‌شود. او نسبت به مدیر قبلی بیشتر به نگهداری مشتریان علاقه‌مند است. می‌خواهد بداند چه ویژگی‌هایی در برنامه در برای نگهداری مشتریان پیاده‌سازی شده است، بنابراین درخواست مستندات بازاریابی مربوطه را می‌کند و با تعجب می‌فهمد که هیچ مستندی وجود ندارد. داوود با تعجب می‌گوید: «جدی نمی‌گی!». اما شما سریعاً سایتی را با تمام تست‌های پذیرش که در طول هر بیلد تولید شده‌اند به او نشان می‌دهید که قسمتی برای جستجو دارد. داوود «نگهداری مشتریان» را وارد می‌کند و روی جستجو کلیک کند. نتایجی به او نشان داده می‌شود.لیست نتایج، سناریوهای زیادی درباره تخفیف ویژه برای مشتریان وفادار جدید را نمایش می‌دهد. داوود لبخند می‌زند. حتی نیازی به مرور مستندات بازاریابی برای یافتن دانش مورد نیازش را نیز نداشت. سطح دقت این سناریوها به مراتب بیش از چیزی بود که او انتظار داشت. داوود پرسید «آیا می‌توانیم همین تخفیف را برای خریدها به دلار اعمال کنیم؟». شما پاسخ می‌دهید: «مطمئن نیستم که کد در حال حاضر ارزهای مختلف را به خوبی مدیریت می‌کند، اما بیایید امتحان کنیم.» ویژوال استودیو را باز کرده و ارز را در تست پذیرش تغییر می‌دهید و دوباره تست‌ها را اجرا می‌کنید. تست‌ها با خطا متوقف می‌شوند و متوجه می‌شوید برای انجام شدن کار نیاز به توسعه و تغییر کد دارید. داوود پاسخ خود را در عرض چند دقیقه دریافت می‌کند.او به فکر فرو می‌رود و میداند که شما چیزی دارید که هرگز در محیط‌های کاری قبلی خود تجربه نکرده بود.2.4. این کلمات معنایی متفاوت دارند:فردا داوود در مورد خرید و سفارش از شما سوال می‌پرسد. معمولاً از توسعه‌دهندگان می‌خواهد که در کد جستجو کرده و منطق و تفاوت‌های موجود در کد را برای او شرح دهند. اما اینجا شرایط متفاوت است. تیم فرهنگ لغاتی دارد که همه چیز در آن مستند شده است. او می‌پرسد: «آیا این فرهنگ‌نامه به‌روز است؟» شما پاسخ می‌دهید: «بله، در طول هر بیلد به طور خودکار از روی کد به‌روزرسانی می‌شود» او شگفت‌زده می‌شود. چرا همه این کار را نمی‌کنند؟ شما به سادگی می‌گویید: «باید کد و دامنه کسب و کاری شما با هم هنگاهنگی کامل داشته باشند تا این کار امکانپذیز باشد.» در این زمان می‌خواهید درباره DDD و Ubiquitous language و دیگر اصول آن شروع به سخنرانی کنید که داوید ابهامی در فرهنگ لغات پیدا می‌کند که قبلا کسی به آن توجه نکرده بود. او می‌گوید این کلمات باید اصلاح شوند. اما روش کار در شرکت شما متفاوت است. شما ابتدا کد را اصلاح می‌کنید و کلاس را تغییر نام می‌دهید و دوباره بیلد را اجرا می‌کنید فرهنگ‌ لغات نیز کاملا خودکار اصلاح می‌شود. همه خوشحال هستند و تیم چیز جدیدی درباره‌ی کسب‌وکار تجارت الکترونیک یاد گرفته‌ است.2.5. کشف مشکل با دیدی جامع:دو ماژول دارید که وابستگی اشتباهی به هم دارند و می‌خواهید آن را اصلاح کنید، اما با کل کدبیس آشنا نیستید، بنابراین از امیر یک نمودار وابستگی می‌خواهید، زیرا او بیشترین دانش را دارد. اما حتی او هم همه‌ی وابستگی‌ها را به خاطر ندارد. امیر می‌گوید: «من یک نمودار وابستگی از کد تولید می‌کنم. این کاری است که مدت‌هاست می‌خواستم انجام دهم. این کار چند ساعت طول می‌کشد، اما اگر انجام شود برای همیشه مشکل مرتفع خواهد شد.». امیر از قبل درباره‌ی چند کتابخانه که می‌توانند وابستگی‌ها را از یک کلاس یا بسته استخراج کرده و نمودارهای جادویی که به‌طور خودکار چیدمان خوبی نیز ایجاد می‌کنند را بررسی کرده است. چند ساعت بعد، ابزار کوچک او نمودار وابستگی‌ها را تولید می‌کند. شما چیزی را که می‌خواستید دریافت می‌کنید و خوشحال هستید. او سپس یک ساعتی را صرف یکپارچه‌سازی این ابزار در فرایند بیلد می‌کند. اما نکته جالب این است که وقتی امیر برای اولین بار به نمودار تولید شده نگاه می‌کند، متوجه نکته جذابی می‌شود: وابستگی بین دو ماژولی که نباید وجود داشته باشد. با مقایسه دید ذهنی او از سیستم با دید تولید شده از سیستم واقعی، شناسایی ضعف در طراحی سادگی اتفاق افتاد. در تکرار بعدی پروژه، ضعف طراحی برطرف می‌شود و در بیلد بعدی، نمودار وابستگی به‌طور خودکار به‌روزرسانی می‌شود. نمودار بسیار تمیزتر می‌شود.2.6. آینده همین امروز است:مطالب بالا در مورد آینده‌ای خیالی نیست بلکه مربوط به همین امروز است و سال‌هاست که اینجا بوده است. ویلیام گیبسون نویسنده‌ی داستان‌های تخیلی می‌گویندfuture has arrived, it’s just not evenly distributed yet.ابزارها و تکنیک‌ها اینجا هستند.سال‌هاست که این کارها انجام می‌شود، اما هنوز به‌طور گسترده‌ای مورد استفاده قرار نگرفته‌اند. عدم فراگیری این تکنیک‌ها تأسف‌بار است زیرا ایده‌های قدرتمندی برای تیم‌های توسعه نرم‌افزار هستند. در آینده، ما به بخشی از این رویکردها دیگر می‌پردازیم و یاد خواهید گرفت که چگونه آن‌ها را در پروژه‌های خود پیاده‌سازی کنید.3. مشکل مستندات سنتی:معمولات مدیران فکر می‌کنند مستندات چیز خوبی است و بهتر است برنامه‌نویسان سراغ مستندات بروند و برنامه نویسان نیز از آن متنفر هستند. مستندات موضوع خسته‌کننده‌ای است. تجربیات شما را نمی‌دانم اما برای من مستندات اغلب نا امید کننده بوده‌اند. خیلی وقت‌ها سراغ مستنداتی رفته‌ام و داده‎‌هایی که نیاز داشتم در آن‌ها نبوده است. وقتی هم که داده ها وجود دارد، اغلب منسوخ و گمراه‌کننده است، بنابراین حتی نمی‌توانم به مستندات اعتماد کنم. ایجاد مستندات برای دیگران یک کار خسته‌کننده است و همیشه ترجیح می‌دهم به جای تولید مستند، برنامه‌نویسی کنم. اما نباید کارها به این‌گونه باشد. بارها درباره آن‌ها شنیده‌ام و برخی از آن‌ها را نیز امتحان کرده‌ام. راه بهتری برای مستندسازی وجود دارد وجود دارد، اما برای بهره‌مندی از آن نیاز به پذیرش ذهنیتی جدید درباره مستندات است. با این ذهنیت و تکنیک‌هایی که با آن همراه است، ممکن است مستندات به اندازه برنامه‌نویسی لذت‌بخش باشد.3.1. مستندات معمولاً جذاب نیست:وقتی کلمه مستندات را می‌شنوید، چه چیزی به ذهن شما خطور می‌کند؟ چند پاسخ احتمالی در اینجا وجود دارد:خسته‌کننده است.فرایند فکر کردن و نوشتن مقدار زیادی متن است.به معنای تلاش برای استفاده از مایکروسافت ورد بدون از دست دادن عقل با جای‌گذاری تصاویر است. به عنوان یک توسعه‌دهنده، من عاشق چیزهای پویا و اجرایی هستم که حرکت و رفتار را نشان می‌دهند. برای من، مستندات گیاهی خشک و بی‌جان ثابت است.قرار است مفید باشد، اما اغلب گمراه‌کننده است.ایجاد مستندات کاری خسته‌کننده است.ترجیح می‌دهم به جای آن کدنویسی کنم. مستندات زمان زیادی برای نوشتن و نگهداری نیاز دارد، به سرعت منسوخ می‌شود، در بهترین حالت ناقص و غیرجذاب است. مستندات منبع فوق‌العاده‌ای برای ناامیدی است. متاسفم که در این سفر خسته کننده با هم همراه هستیم.3.2. اشکالات مستندات:مثل ذغال بی کیفیت که زود خاموش شده و سردرد آور است، مستندات کاغذی به سرعت منسوخ می‌شود و باعث سردرد می‌شود.روال مستندسازی سنتی اشکالات زیادی دارد و از چندین ضدالگوی رایج رنج می‌برد. همانطور که می‌دانید ضدالگو پاسخی مرسوم به مشکلی پر تکرار است که ایده‌ی خوبی نبوده و باید از آن اجتناب کرد. برخی از رایج‌ترین اشکالات و ضدالگوهای مستندات در ادامه توصیف شده‌اند. آیا برخی از آن‌ها را می‌شناسید؟3.2.1. فعالیت‌های جداگانه:حتی در پروژه‌های توسعه نرم‌افزار که ادعای چابکی دارند، تصمیم‌گیری در مورد آنچه باید ساخته شود و انجام کدنویسی، تست و تهیه مستندات اغلب فعالیت‌های جداگانه‌ای هستند .این فعالیت‌های جداگانه اغلب موجب هدر رفت منابع و از دست رفتن فرصت‌ها می‌شود. اساساً هنگام تولید یک نرم‌افزار دانشی داریم که، همان دانش در فعالیت‌های مختلف دست‌کاری شده و در اشکال مختلف و در مصنوعات مختلف - و احتمالاً با مقداری تکرار ظهور و بروز پیدا می‌کند.وقتی در فرایند‌های مختلفی با دانشی سر و کار داریم و بر اساس آن مصنوعاتی را ایجاد می‌کنیم، ممکن است به مرور دانش ما تکامل یابد و این تکامل باعث می‌شود مصنوعات مراحل مختلف با هم یکسان نباشند.3.2.2. رونوشت دستی:هنگامیکه زمان مستندسازی می‌رسد، اعضای تیم بخشی از دانشی که در ذهن دارند و با آن کار را انجام داده‌اند را انتخاب می‌کنند و رونوشتی دستی از آن‌ها در قالب مناسب برای مخاطب مورد نظر انجام می‌دهند. اساساً، اینکار به معنای نوشتن یک سند متنی درباره‌ی آنچیزی است که در کد انجام شده است. این کار تکرار مکررات و بی‌فایده است. مانند زمانی که هنوز دستگاه چاپ اختراع نشده بود و برای تهیه‌ی نسخه از کتاب، مجددا از آن رونویسی انجام می‌شد.3.2.3. دانش تکراری:رونوشت دستی توضیح داده شده منجر به دانش تکراری می‌شود. در پروژه‌های نرم‌افزاری شما با منبع اصلی حقیقت که معمولاً کد است و یک دسته نسخه‌هایی که این دانش را در اشکال مختلف تکرار می‌کنند، به پایان مستندسازی می‌رسید. متأسفانه، وقتیکه یکی از مصنوعات تغییر می‌کند - برای مثال، کد - اینکه به خاطر بسپاریم مستندات هم باید به روز شوند کار سختی است. در نتیجه، مستندات به سرعت منسوخ می‌شود و شما با مستندات ناقصی که نمی‌توانید به آن اعتماد کنید مواجه می‌شوید.چنین مستنداتی چقدر مفید است؟3.2.4. وقت‌کشی خسته‌کننده:مدیران می‌خواهند مستنداتی برای کاربران و همچنین برای ایجاد امکان جابجایی کارکنان در تیم داشته باشند. با این حال، توسعه‌دهندگان از نوشتن مستندات متنفرند. این کار در مقایسه با نوشتن کد یا خودکارسازی یک فرایند اصلا جذاب نیست. مستند متن مرده‌ای است که به سرعت منسوخ می‌شود و اجرا نمی‌شود، برای یک توسعه‌دهنده نوشتن آن هیچ جاذبه‌ای ندارد. توسعه‌دهندگان همیشه تمایل دارند روی کد زمان بگذارند نه روی مستندات و همین توسعه‌دهندگان هنگامی که سراغ نرم‌افزار شخص ثالثی می‌روند از نبود مستندات کافی شکایت می‌کنند و این خود پارادوکس است. نویسندگان فنی دوست دارند مستندات بنویسند و برای آن دستمزد می‌گیرند. ولی برای دسترسی به دانش فنی مورد نیاز، معمولاً به توسعه‌دهندگان نیاز دارند، ضمن اینکه اغلب آن‌ها هنوز رونوشت دستی از دانش انجام می‌دهند.این کار خسته‌کننده است و زمان ارزشمند زیادی را مصرف می‌کند.3.2.5. خالی‌کردن مغز:از آنجائیکه نوشتن مستندات جذاب نیست ولی کاری است که باید انجام شود، اغلب بدون قاعده و فکر زیاد انجام می‌شود. نتیجه یک تخلیه مغزی تصادفی از آنچه نویسنده در زمان نوشتن در ذهن دارد، است. مشکل اصلی این است که این تخلیه‌ی مغزی تصادفی برای کسی مفید نیست.3.2.6. نمودارهای زیبا:این ضدالگو، در تیم‌هایی که دوست دارند از ابزارهایCASE استفاده کنند بسیار رایج است. این ابزارها برای طراحی نیستند. در عوض، آن‌ها تشویق به ایجاد نمودارهای پالوده و بزرگ می‌کنند، با چیدمان‌های مختلف و اعتبارسنجی در برابر یک مرجع مدل‌سازی. همه‌ی این‌ کارها زمان زیادی می‌برد. حتی با همه‌ی ویژگی‌های چیدمان خودکار این ابزارها، ایجاد یک نمودار ساده هنوز زمان زیادی می‌برد.3.2.7. وسواس به نشانه‌گذاری:این روز‌ها دیگر ‌UML مثل گذشته محبوب نیست، اما در دهه‌ی پس از تصویب آن به عنوان یک استاندارد در سال 1997، این نشانه‌گذاری جهانی برای هر کار نرم‌افزاری مورد استفاده بود،حتی اگر برای آن کار مناسب نبود. هیچ نشانه‌گذاری دیگری از آن زمان محبوب نشده است و تیم‌های سراسر جهان هنوز از UML برای مستندسازی استفاده می‌کنند، حتی وقتی که برای آن مناسب نیست. وقتی تنها چیزی که می‌دانید UML است، همه چیز شبیه به یکی از نمودارهای استاندارد آن به نظر می‌رسد.3.2.8. عدم استفاده از نشانه‌گذاری:در واقع، عدم استفاده از نشانه‌گذاری به طرز عجیبی محبوب شده است. بسیاری از افراد به سادگی UML را نادیده گرفته‌اند و با نشانه‌گذاری‌های سفارشی نمودارهایی رسم می‌کنند که هیچ دو نفری آن‌ها را به یک شکل درک نمی‌کند و نگرانی‌های مختلفی مانند وابستگی‌های بیلد، جریان داده و نگرانی‌های استقرار را با خوشحالی با هم ترکیب کرده و آشوب ایجاد می‌کنند.3.2.9. گورستان اطلاعات:اغلب، راه‌حل‌های مدیریت دانش سازمانی به زباله‌دان‌هایی برای مرگ دانش تبدیل می‌شوند. به این‌ها فکر کنید:ویکی‌های سازمانیشیرپوینتاسناد بزرگ مایکروسافت آفیسپوشه‌های مشترکسیستم‌های تیکتینگ و ویکی‌ها با قابلیت‌های جستجوی ضعیف رویکردی به مستندات ایجاد می‌کنند که اغلب به دلیل فرایند سخت در پیدا کردن اطلاعات درست یا هزینه‌ی زیاد برای به‌روز نگه داشتن اطلاعات یا هر دو شکست می‌خورند. این موارد، نوعی مستندات فقط نوشتنی یا مستندات یک بار نوشتنی را ترویج می‌دهند.3.2.10. کمک گمراه‌کننده:مستنداتی که به‌طور دقیق به‌روز نگه داشته نشود، گمراه‌کننده است. آیا برای شما پیش آمده کهدر یکی از کمد‌های خانه، جعبه‌ی بیسکوئیتی را یافته‌اید و وقتی با شوق و ذوق فراوان درب آن را بازکرده‌اید و در کمال تعجب با انبوهی از نخ و سوزن مواجه شوید؟ این همان مستندات گمراه کننده است. اگرچه این مستندات ادعا می‌کنند که کمک می‌کنند، اما نادرست است. در نتیجه، چنین مستنداتی ممکن است برای خواندن جالب باشد، اما بار شناختی اضافی برای پیدا کردن آنچه که هنوز درست است در مقابل آنچه که نادرست شده است وجود دارد. اگر به مثال خانه بازگردیم، برای یافتن بیسکوئیت احتمالا باید به دنبال جعبه ای با علامت مرگ و نوشته مرگ موش باشید.3.2.11. همیشه چیز مهم‌تری وجود دارد:نوشتن مستندات خوب زمان زیادی می‌طلبد و نگهداری آن زمان بیشتری می‌طلبد. کسانی که تحت فشار زمانی هستند اغلب وظایف مستندسازی را نادیده می‌گیرند یا سریع و بد انجام می‌دهند.3.3. مانفیست چابک و مستندات:مانفیست چابک توسط گروهی از توسعه‌دهندگان نرم‌افزار در سال 2001 نوشته شد. در این مانیفست، آن‌ها مواردی را که به آن‌ها ارزش داده‌اند فهرست می‌کنند، از جمله:افراد و تعاملات بیش از فرآیندها و ابزارهانرم‌افزار کارآمد بیش از مستندات جامعهمکاری با مشتری بیش از مذاکره قراردادپاسخ به تغییرات بیش از پیروی از یک طرح اولویت دوم، «نرم‌افزار کارآمد بیش از مستندات جامع»، اغلب نادرست تفسیر می‌شود. بسیاری از مردم باور دارند که به‌طور کامل مستندات را باید نادیده گرفت. در واقع، مانفیست چابک نمی‌گوید «مستندسازی نکنید». این فقط یک مسئله اولویت است. به گفته‌ی نویسندگان مانفیست، «ما مستندات را می‌پذیریم، اما نه به منظور هدر دادن کاغذهای بی‌شماری که نادیده‌گرفته‌ می‌شوند.» هنوز هم، با رویکردهای چابک که در شرکت‌های بزرگ به جریان اصلی تبدیل شده‌اند،سوءتفاهم در اینباره وجود داشته و بسیاری از تیم‌ها مستندات را نادیده می‌گیرند.با این حال، مشاهداتم نشان می‌دهد نبود یا کمبود مستندات باعث ایجاد مشکل و نا امیدی در بسیاری از مشتریان و همکارانم شده است و این مشکل در حال رشد است.3.4. مستندات سنتی مشکل دارد، اما اکنون بهتر می‌دانیم:از اواخر دهه‌ی 90 میلادی، روش‌ها و اصولی مانند کدنویسی تمیز، توسعه‌ی مبتنی بر تست (TDD)، توسعه‌ی مبتنی بر رفتار (BDD)، طراحی مبتنی بر دامنه (DDD) و تحویل مداوم به‌طور فزاینده‌ای محبوب شده‌اند. همه این روش‌ها نحوه‌ی تفکر ما در مورد تحویل نرم‌افزار را تغییر داده‌اند.وقتی TDD را انتخاب می‌کنیم، تست‌ها ابتدا به عنوان مشخصات در نظر گرفته می‌شوند. با DDD، کد و مدل‌سازی دامنه‌ی کسب‌وکار را شناسایی می‌کنیم و از روش سنتی نگهداری مدل‌ها و کدها به صورت جداگانه فاصله می‌گیریم. یکی از نتایج این رویکردی این است که انتظار داریم کد تمام داستان را درباره‌ی دامنه بیان کند. BDD ایده‌‌های زبان کسب‌وکار را قرض گرفته و آن را به‌طور مستقیم‌تری با پشتیبانی ابزاری‌هایی مورد استفاده قرار می‌دهد. در نهایت، تحویل مداوم نشان می‌دهد که ایده‌ای که چند سال پیش مضحک به نظر می‌رسید (تحویل چندین بار در روز به صورت غیررویدادی) در واقع ممکن و حتی مطلوب است اگر تصمیم بگیریم و بتوانیم به روش‌های پیشنهادی کامل پایبند بمانیم.4. مستندات درباره‌ی دانش است:همانطور که گفتیم، توسعه‌ی نرم‌افزار تماماً درباره دانش و تصمیم‌گیری بر اساس آن دانش است، که به نوبه‌ی خود دانش اضافی ایجاد می‌کند. مشکل موجود، تصمیمی که گرفته شد، دلیل آن تصمیم، حقایقی که به آن تصمیم منجر شد، و گزینه‌های در نظر گرفته شده همگی دانش هستند.ممکن است تاکنون به این شکل به آن فکر نکرده باشید، اما هر دستوری که در یک زبان برنامه‌نویسی تایپ می‌شود یک تصمیم است. تصمیمات بزرگ و کوچک وجود دارند، اما بدون توجه به اندازه، همه‌ی آن‌ها تصمیم هستند. در توسعه‌ی نرم‌افزار، هیچ مرحله‌ی ساخت گرانی پس از مرحله‌ی طراحی وجود ندارد: ساخت ( یا دقیق‌تر اگر بگویم اجرای کامپایلر برای تبدیل کد طراحی شده به زبان ماشین) آنقدر ارزان است که به راحتی بارها و بارها آن را اجرا می‌کنیم.کار اصلی و گرانقیمت طراحی است.طراحی نرم‌افزار می‌تواند مدت زیادی طول بکشد. می‌تواند به اندازه کافی طول بکشد تا تصمیمات قبلی و زمینه‌هایی که در آن تصمیمات گرفته شده اند فراموش شوند. می‌تواند به اندازه‌ی کافی طول بکشد تا افراد نیز از تیم بروند و دانش خود را ببرند و افراد جدیدی بپیوندند که فاقد دانش هستند. دانش در مرکز فرایند توسعه نرم‌افزار قرار دارد.بیشتر اوقات فعالیت طراحی، تلاشی تیمی است که بیش از یک نفر را درگیر می‌کند. کار کردن با هم به معنای تصمیم‌گیری با هم یا تصمیم‌گیری بر اساس دانش شخصی دیگر است.چیزی که توسعه نرم‌افزار را منحصر به فرد می‌کند این است که طراحی نه تنها افراد بلکه ماشین‌ها را نیز درگیر می‌کند. کامپیوترها بخشی از فرایند کلی هستند و بسیاری از تصمیماتی که گرفته می‌شود به سادگی به کامپیوتر داده می‌شود تا اجرا کند. اینکار معمولاً از طریق مستنداتی به نام سورس کد انجام می‌شود. با استفاده از یک زبان برنامه‌نویسی، ما دانش و تصمیمات را به شکلی برای کامپیوتر قابل درک باشد به آن منتقل می‌کنیم.درک سورس برای کامپیوتر بخش سختی نیست. حتی توسعه‌دهندگان بی‌تجربه هم معمولاً موفق به توسعه کد قابل درک برای کامپیوتر می‌شوند. سخت‌ترین بخش این است که سایر افراد درک کنند چه کاری انجام شده است تا بتوانند کار بهتر و سریع‌تری را انجام دهند.هرچه جاه‌طلبی بیشتر باشد، مستندات بیشتری لازم می‌شود تا یک فرآیند تجمعی مدیریت دانش را امکان‌پذیر کند که فراتر از آنچه در ذهن ما جا می‌گیرد، مقیاس‌پذیر باشد. هنگامی که مغز و حافظه‌ی ما کافی نیستند، به فناوری‌هایی مانند نوشتن، چاپ و نرم‌افزار نیاز داریم تا به یادآوری و سازماندهی مجموعه‌های بزرگتر دانش کمک کنند.4.1. منشاء دانشدانش از کجا می‌آید؟ دانش عمدتاً از مکالمات حاصل می‌شود. ما از طریق مکالمه با دیگران، دانش زیادی به دست می‌آوریم. این مکالمات در طول کار گروهی مانند XP، یا در طول جلسات، یا در محل‌های غیررسمی مانند حیاط شرکت یا از طریق چت شرکتی یا ایمیل‌ها اتفاق می‌افتد. نمونه‌هایی از مکالمات شامل کارگاه‌های مشخصات BDD و 3amigos در چابک هستند.با این حال، به عنوان توسعه‌دهندگان نرم‌افزار، ما با ماشین‌ها نیز مکالمه داریم و این مکالمات را تست می‌نامیم. ما چیزی را به یک ماشین می‌گوییم با استفاده از کد در یک زبان برنامه‌نویسی، و ماشین آن را اجرا می‌کند و به ما چیزی می‌گوید: تست شکست می‌خورد یا موفق می‌شود، رابط کاربری طبق انتظار واکنش نشان می‌دهد، یا نتیجه چیزی نیست که می‌خواستیم، در این صورت ما چیز جدیدی یاد می‌گیریم. نمونه‌هایی از تست ها شامل TDD، طراحی در حال ظهور، و آزمایش‌های Lean Startup است.دانش همچنین از مشاهده محیط به دست می‌آید. در یک شرکت، شما با حضور در آنجا و توجه به مکالمات، رفتارها و احساسات دیگران، چیزهای زیادی یاد می‌گیرید. نمونه‌هایی از مشاهده شامل غرق شدن در دامنه، دیوارهای وسواسی، رادیاتورهای اطلاعاتی، و مشاهده "از ساختمان بیرون برو" در Lean Startup است.4.2. تکامل دانش:رخی از دانش‌ها می‌توانند برای سال‌ها پایدار بمانند، در حالی که برخی دیگر از دانش‌ها به طور مکرر در طول ماه‌ها یا حتی ساعت‌ها تغییر می‌کنند.هر شکلی از مستندات باید هزینه‌ی نگهداری را در نظر بگیرد و آن را تا حد ممکن به صفر نزدیک کند. برای دانش پایدار، روش‌های سنتی مستندسازی کارساز هستند. اما با دانش‌هایی که به طور مکرر تغییر می‌کنند، نوشتن متن و به‌روزرسانی آن بعد از هر تغییر، گزینه‌ی نامناسبی است.تأثیر شتاب در صنعت نرم‌افزار این است که ما می‌خواهیم در موقعیتی باشیم که بتوانیم نرم‌افزار را بسیار سریع تکامل دهیم. سرعت به حدی است که نمی‌توان زمان صرف نوشتن صفحات زیادی از مستندات کرد، با این حال ما می‌خواهیم و نیاز داریم از تمامی مزایای مستندات بهره‌مند شویم.4.3. چرا دانش ضروری است؟هنگام ایجاد نرم‌افزار، ما با سوالات، تصمیمات و تنظیمات زیادی روبرو می‌شویم و یاد می‌گیریم که:چه مشکلی را می‌خواهیم حل کنیم؟ همه باید از این به بعد آن را بدانند.واقعاً چه مشکلی را می‌خواهیم حل کنیم؟ (سعی می‌کنیم به این پاسخ دهیم وقتی که متوجه می‌شویم ابتدا اشتباه کرده‌ایم.)موارد مترادفی را می‌بابیم و در ابتدا گیج می‌شویم و با افزایش دانش تفاوت آن‌ها را درک می‌کنیم. نباید دوباره آن‌ها را اشتباه بگیریم.دیتابیس جدیدی را امتحان کردیم و نیازهای ما را برآورده نمی‌کند—به سه دلیل. تا زمانی که نیازهای ما یکسان باقی بمانند، نیازی به امتحان دوباره نیست.تصمیم گرفتیم ماژول سبد خرید و ماژول پرداخت را جدا کنیم زیرا متوجه شدیم که تغییرات یکی هیچ ربطی به تغییرات دیگری ندارد. نباید آن‌ها را دوباره به هم متصل کنیم.به طور تصادفی متوجه شدیم که یک ویژگی بی‌فایده در برنامه وجود دارد، بنابراین قصد داریم کد را ماه آینده حذف کنیم. اما احتمالاً دلیل خود را فراموش می‌کنیم و اگر کد باقی بماند، برای همیشه یک معما باقی خواهد بود.با نرم‌افزار موجود، وقتی دانش توسعه یافته‌ی قبلی را از دست می‌دهیم، مجبور به دوباره‌کاری آنچه قبلاً انجام شده است می‌شویم زیرا نمی‌دانیم که کاری از قبل انجام شده است. همچنین ممکن است یک ویژگی را در یک مؤلفه‌ی غیر مرتبط قرار دهیم زیرا نمی‌دانیم که باید کجا باشد، و این باعث می‌شود نرم‌افزار حجیم شود. یا کد مربوط به ویژگی در بین مؤلفه‌های مختلف پراکنده می‌شود.اگر فقط دانش لازم برای پاسخ به سوالات روزمره مانند سوالات زیر را در دسترس داشتیم:کجا می‌توانم آن مشکل را با اطمینان برطرف کنم؟کجا باید این بهبود را اضافه کنم؟ارگر نویسندگان اصلی بودند کجا این بهبود را اضافه می‌کردند؟آیا حذف این خط کدی که به نظر بی‌فایده می‌رسد، امن است؟من می‌خواهم امضای یک متد را تغییر دهم، اما چه تأثیراتی در نتیجه این کار به وجود می‌آید؟آیا واقعاً باید کد را مهندسی معکوس کنم تا بفهمم چگونه کار می‌کند؟آیا واقعاً هر بار که تحلیلگران کسب‌وکار نیاز به دانستن قوانین کسب‌وکار فعلی دارند، باید وقت صرف خواندن کد منبع کنم؟وقتی مشتری درخواست یک ویژگی می‌کند، چگونه می‌توانیم بدانیم که آیا این ویژگی قبلاً پشتیبانی می‌شود یا نیاز به توسعه دارد؟احساس می‌کنیم که نحوه‌ی تکامل کد بهترین راه ممکن است، اما اگر درک کاملی از نحوه‌ی کار آن نداشته باشیم چه؟چگونه به راحتی بخشی از کد را که با یک ویژگی خاص سروکار دارد پیدا کنیم؟کمبود دانش به دو هزینه منجر می‌شود:زمان هدر رفته: زمانی که می‌توانست در بهبود یا توسعه‌ی چیز دیگری سرمایه‌گذاری شود.تصمیمات غیر بهینه: تصمیمات دیگر می‌توانستند مرتبط‌تر یا در بلندمدت ارزان‌تر باشند.این دو هزینه در طول زمان ترکیب می‌شوند: زمان صرف شده برای یافتن دانش گم شده زمانی نیست که برای گرفتن تصمیمات بهتر صرف شود. در نتیجه، تصمیمات غیر بهینه ترکیب می‌شوند و زندگی ما را به تدریج ناخوشایندتر می‌کنند تا زمانی که چاره‌ای جز تصمیم‌گیری مبتنی بر غیرقابل نگهداری بودن نرم‌افزار و بازنویسی آن نداریم.به نظر می‌رسد ایده خوبی است که بتوانیم به دانشی که برای انجام وظایف توسعه مفید است، دسترسی داشته باشیم.4.4. برنامه‌نویسی، نظریه‌سازی و انتقال:در سال 1985، مقاله مشهور پیتر نائور با عنوان "برنامه‌نویسی به عنوان نظریه‌سازی" به خوبی حقیقت برنامه‌نویسی به عنوان یک تلاش جمعی را آشکار کرد: او گفت که برنامه‌نویسی بیشتر درباره به اشتراک گذاشتن نظریه‌ای از جهان (فکر کنید "مدل ذهنی") با دیگر توسعه‌دهندگان است که به طور صبورانه از طریق یادگیری، آزمایش، مکالمات و تأملات عمیق ایجاد شده است. به گفته خود او:"برنامه‌نویسی به درستی باید به عنوان فعالیتی در نظر گرفته شود که توسط آن برنامه‌نویسان به نوعی از بینش، نظریه، درباره موضوعات در دست اقدام دست می‌یابند. این پیشنهاد در تضاد با آن چیزی است که به نظر می‌رسد مفهوم رایج‌تر باشد، که برنامه‌نویسی باید به عنوان تولید یک برنامه و متون دیگر در نظر گرفته شود."مشکل این است که بیشتر نظریه ضمنی است. کد فقط نوک کوه یخ را نشان می‌دهد. کد بیشتر نتیجه‌ای از نظریه‌ی در ذهن توسعه‌دهندگان است تا نمایشی از خود نظریه. از دیدگاه پیتر نائور، این نظریه سه حوزه اصلی دانش را در بر می‌گیرد:نقشه‌برداری بین کد و جهانی که نمایندگی می‌کند: برنامه‌نویسی که نظریه برنامه را دارد می‌تواند توضیح دهد که چگونه راه‌حل به مسائل جهان که به مدیریت آن‌ها کمک می‌کند، مربوط می‌شود.منطق برنامه: برنامه‌نویسی که نظریه برنامه را در اختیار دارد می‌تواند توضیح دهد چرا هر قسمت از برنامه همان چیزی است که هست؛ به عبارت دیگر، برنامه‌نویس قادر است متن واقعی برنامه را با نوعی توجیه پشتیبانی کند.پتانسیل توسعه یا تکامل برنامه: برنامه‌نویسی که نظریه برنامه را دارد قادر است به هر درخواست تغییر برنامه به صورت سازنده پاسخ دهد تا به مدیریت مسائل جهان به شیوه‌ای جدید کمک کند.با گذشت زمان، تعدادی تکنیک یاد گرفته‌ایم که به افراد اجازه می‌دهد نظریه‌ها را بین خود منتقل کنند. کد تمیز و DDD برنامه‌نویسان را تشویق می‌کند تا راه‌هایی برای بیان نظریه در سر خود به شکلی واقعی‌تر در کد پیدا کنند. به عنوان مثال، ubiquitous language در DDD فاصله‌ی بین زبان جهان و زبان کد را پر می‌کند و به حل مشکل نقشه‌برداری کمک می‌کند. امیدوارم زبان‌های برنامه‌نویسی آینده نیاز به نمایش نه تنها رفتار کد بلکه مدل ذهنی بزرگتر برنامه‌نویسان، که کد نتیجه آن است، را به رسمیت بشناسند.الگوها و زبان‌های الگو نیز به عنوان تلاش‌های صریح برای بسته‌بندی بخش‌هایی از نظریه‌ها به ذهن می‌رسند. هرچه الگوهای بیشتری بشناسیم، بیشتر می‌توانیم نظریه‌ی ضمنی را رمزگذاری کنیم و آن را به شکل گسترده‌تر و قابل انتقال‌تر تبدیل کنیم. الگوها در توضیحات نیروهای خود عناصر کلیدی منطق انتخاب آن‌ها را تجسم می‌کنند و گاهی اوقات اشاره می‌کنند که چگونه توسعه باید اتفاق بیفتد. آن‌ها ممکن است به پتانسیل برنامه اشاره کنند؛ به عنوان مثال، الگوی استراتژی قرار است با افزودن استراتژی‌های جدید گسترش یابد.اما همانطور که در رمزگذاری فهم خود پیشرفت می‌کنیم، با چالش‌های بلندپروازانه‌تری نیز مواجه می‌شویم، بنابراین ناامیدی ما همچنان باقی می‌ماند. من معتقدم جمله نائور از سال 1985 در دهه‌های آینده همچنان معتبر خواهد بود: "برای یک برنامه‌نویس جدید که بخواهد نظریه موجود از یک برنامه را به دست آورد، فرصت آشنایی با متن برنامه و سایر مستندات کافی نیست."ما هرگز مشکل انتقال دانش را به طور کامل حل نخواهیم کرد، اما می‌توانیم آن را به عنوان یک واقعیت بپذیریم و یاد بگیریم با آن زندگی کنیم. نظریه‌ای که به عنوان یک مدل ذهنی در ذهن برنامه‌نویسان است، هرگز نمی‌تواند به طور کامل با افرادی که بخشی از فرآیند فکری‌ای که منجر به ایجاد آن شده، نبوده‌اند، به اشتراک گذاشته شود.شایان ذکر است که تیم‌های دائمی که به طور منظم به صورت جمعی کار می‌کنند، از این مشکل انتقال نظریه زیاد رنج نمی‌برند.5. مستندات درباره انتقال دانش است:کلمه مستندات اغلب تداعی‌های زیادی را به ذهن می‌آورد: اسناد نوشته شده، اسناد Microsoft Word یا PowerPoint، اسنادی بر اساس الگوهای شرکت، اسناد چاپ شده، متن بزرگ، سنگین و خسته‌کننده در یک وب‌سایت یا ویکی، و غیره. با این حال، همه‌ی این تداعی‌ها ما را به شیوه‌های گذشته متصل می‌کنند و بسیاری از شیوه‌های جدیدتر و کارآمدتر را نادیده می‌گیرند.برای اهداف این نوشته، ما یک تعریف بسیار گسترده‌تر از مستندات را اتخاذ خواهیم کرد: فرآیند انتقال دانش ارزشمند به افراد دیگر در حال حاضر و همچنین به افراد در آینده.مستندات یک جنبه‌ی لجستیکی دارد. این کار مربوط به انتقال دانش در فضای بین افراد و همچنین انتقال آن در طول زمان است که افراد فنی آن را ماندگاری یا ذخیره‌سازی می‌نامند. به طور کلی، تعریف ما از مستندات شبیه به حمل و انبار کردن کالاها است، با این تفاوت که کالاها دانش هستند.انتقال دانش بین افراد در واقع انتقال دانش بین مغزها است. این انتقال می‌تواند از یک مغز به مغزهای دیگر در حال حاضر باشد که این مسئله این یک مسئله انتقال یا انتشار نامیده می‌شود. در حالت دیگری این انتقال می‌تواند از مغزها در حال حاضر به مغزهایی در آینده باشد، این نوع انتقال مربوط به ماندگاری دانش و یک مسئله‌ی حافظه است.آیا می‌دانستید؟ نیمه‌ی عمر دوره توسعه 3.1 سال است، در حالی که نیمه‌ی عمر کد 13 سال است. مستندات باید با این ناسازگاری مقابله کنند.انتقال دانش از مغز یک فرد فنی به مغزهای افراد غیر فنی نیز یک مسئله‌ی دسترسی به دانش است. یک مورد دیگر از دسترسی به دانش، کارآمدتر کردن جستجوی آن است.و موارد دیگری نیز وجود دارد، مانند نیاز به قرار دادن دانش در قالب یک سند خاص به دلیل مطابقت با یک استاندارد زیرا شما فقط مجبور به رعایت آن استاندارد هستید.5.1. تمرکز بر آنچه اهمیت دارد:به عنوان وسیله‌ای برای انتقال دانش ارزشمند، مستندات می‌تواند اشکال مختلفی داشته باشد: اسناد نوشتاری، مکالمات رو در رو، کد، فعالیت در ابزارهای اجتماعی، یا هیچ چیز وقتی که ضروری نیست.با این تعریف از مستندات، می‌توانیم برخی از اصول مهم را بیان کنیم:دانشی که برای مدتی طولانی مورد نیاز است، شایسته‌ی مستندسازی است.دانشی که برای تعداد زیادی از افراد مورد نیاز است، شایسته مستندسازی است.دانشی که ارزشمند یا حیاتی است نیز ممکن است نیاز به مستندسازی داشته باشد.از سوی دیگر، مستندسازی دانشی که در هیچ یک از موارد بالا نیست ارزشی ندارد و صرف زمان یا تلاش برای آن بیهوده خواهد بود.توجه کنید که ارزشمند بودن دانش مورد نظر اهمیت دارد. تلاش برای انتقال دانشی که در دراز مدت افراد کافی به آن نیاز ندارند ارزشمند نیست. اگر دانشی از قبل به خوبی شناخته شده است یا فقط برای یک نفر مفید است، یا فقط تا پایان روز مورد به آن نیاز داریم، پس نیازی به انتقال یا ذخیره‌ی آن نیست.به صورت پیشفرض مستندسازی نکنید:هیچ دلیلی برای انجام هیچ تلاش خاصی در مستندسازی دانش وجود ندارد مگر اینکه دلیلی قانع‌کننده برای انجام آن وجود داشته باشد؛ در غیر این صورت، این یک اتلاف وقت است. احساس بدی نداشته باشید اگر چیزی را که نیازی به مستندسازی ندارد، مستندسازی نمی‌کنید.6. جمع بندی:در این نوشته تلاش کردیم دنیایی که باید به سمت آن برویم و مشکلات فعلی در حوزه‌ی مستند سازی را بررسی کنیم. با بازنگری در مورد اینکه مستندات واقعاً چیست، از نظر انتقال و حفظ دانش، و برخی نتایج اولیه در نحوه‌ی مدیریت آن، اکنون زمان معرفی ایده مرکزی مستندات زنده و اصول اصلی آن فرا رسیده است. در قسمت بعد به تعریف اصول مستند سازی مدرن خواهیم پرداخت.پ.ن: منبع اصلی قسمت‌های مرتبط با مستندسازی در این سری نوشتار از کتاب Living Documentation: Continuous Knowledge Sharing by Design نوشته‌ی آقای Cyrille Martraire است که خواندن کتاب اصلی را به همه مهندسین نرم‌افزار و علاقه‌مندان به DDD پیشنهاد می‌کنم. علیرضا ارومند علیرضا ارومند Sun, 09 Jun 2024 14:50:05 +0330 https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D9%87%D9%81%D8%AA%D9%85-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-wardley-mapping-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88-z9gbtwtj1l62 1. مقدمه:در قسمت قبل از مدرن‌سازی معماری، با واردلی‌مپینگ به عنوان ابزاری که در اختیار رهبران مدرن‌سازی معماری است آشنا شدیم و در این قسمت قصد داریم مباحث خود را در این حوزه تکمیل کنیم.2. تکامل را در آغوش بکشید:چالش رایجی که تازه واردان به واردلی‌مپینگ با آن روبرو هستند، درک کامل پیچیدگی‌های تعیین مرحله‌ی صحیح تکامل یک کامپوننت است. Genesis، Custom Built، Product و Commodity کلمات نسبتاً رایجی هستند. با این حال، آن‌ها تعاریف دقیقی در واردلی‌مپینگ با معیارهای ارزیابی مخصوص به خود دارند.درک از پیش‌زمینه و مراحل تکامل، برای یادگیری واردلی‌مپینگ و بدست آوردن سریعتر ارزش از این تکنیک بسیار مهم است. در این بخش، با ویژگی‌های کلیدی‌ای آشنا می‌شوید و تمرین کوتاهی را یاد می‌گیرید که به شما و تیمتان کمک می‌کند تا خیلی زود سرعت خود را افزایش دهید.2.1 ویژگی‌های تکامل:یکی ازجنبه‎‌های مهم واردلی‌مپینگ این است که آقای Simon Wardley و همکاران و جامعه‌ی حول واردلی‌مپینگ منابع زیادی را که برای ایجاد و استفاده از این نقشه‌ها استفاده می‌شوند را گرد هم آورده‌اند. برای ارزیابی تکامل، جامعه سه مشخصه و دوازده ویژگی را توصیه می کند که برای آشنایی بیشتر می‌توانید از این لینک استفاده کنید.به این موارد سیگنال‌های ضعیف می‌گویند و برخی از آن‌هاممکن است برای کامپوننت‌های خاصی مناسب‌تر باشند. متأسفانه، برای رسیدن به هدف، مسیر ساده‌ای که به سادگی بتوان با دنبال کردن آن برای هر کامپوننت به تولید یک ارزیابی دقیق رسید وجود ندارد.برای رسیدن به هدف نیاز به ذهن تیز، تخصص و توان فنی، همراه با مهارت در کار عملی دارید.سه مشخصه‌ی فراگیربودن (Ubiquity)، قطعیت (Certainty) و انواع انتشار (Publication Types ) در جدول زیر آمده است. هر مشخصه با معیارهایی برای تعیین اینکه یک کامپوننت با توجه به آن ویژگی خاص به چه مرحله ای تعلق دارد ارائه می شود. اگر یک کامپوننت کمیاب باشد، به این معنی که تعداد کمی از شرکت‌ها یا هیچ شرکت دیگری این قابلیت را ندارند، در مرحله‌ی تکامل پیدایش با ویژگی Ubiquity مطابقت دارد.از طرفی، اگر چیزی گسترده شده باشد و هر شرکتی آن را داشته باشد، برای ویژگی Ubiquity در Commodity قرار می گیرد. Certainty مشخصه‌ای است که نشان می دهد چقدر استفاده از یک کامپوننت درک شده است. با توجه به این ویژگی، اگر همه‌ی بازیکنان در صحنه‌ی کسب و کار تازه شروع به کشف نحوه‌ی به کارگیری مفهوم کرده باشند، کامپوننت در Genesis قرار دارد. اگر کامپونت‌ها به طور کامل تکامل یافته باشند و چیز دیگری برای یادگیری در مورد استفاده از کامپوننت وجود نداشته باشد، کامپوننت‌ها به جای Commodityدر حوزه‌ی Certainty قرار می‌گیرند.سه مشخصه تکاملدر مثال تحویل غدای آنلاین، مفهوم منو هم رایج است و هم معمولاً درک می شود. محصول هر رقیبی قابلیت‌های منو را ارائه می دهد و همه می‌دانند که چگونه از منو استفاده کنند. بنابراین، به نظر می رسد منو Commodity یا بسیار نزدیک به آن است. حال قابلیت دیگری مثل بهینه‌سازی رستوران را در نظر بگیرید که یک یا دو سازمان شروع به توسعه‌ی آن کرده اند. در اینجا قرار است به رستوران ها برای رشد تجارت خود از طریق مشاوره و توصیه کمک شود. حالا با مفهموم جدیدی مواجه هستیم که بازیگران صنعت هنوز در حال کشف چگونگی توسعه این قابلیت هستند و دائماً در حال آزمایش ویژگی‌های جدید و ایده‌پردازی هستند. با اینکه این ویژگی‌ها جذاب است و برخی رستوران‌ها آن را پذیرفته اند، اما هنوز بسیاری از رستوران‌ها از این ویژگی استفاده نمی‌کنند. بنابراین، به نظر می‌رسد که با افزایش مصرف آهسته و افزایش سریع یادگیری مطابقت بیشتری داشته باشد، ظاهراً Custom Built متناسب است. ما باید اطمینان حاصل کنیم که دیدگاه های مختلفی از کارشناسان حوزه در این زمینه داریم. ما نمیخواهیم این تصور را ایجد کنیم که یک ارزش بالای استراتژیک ایجاد کرده‌ایم در حالی که دانش و بینش‌های کلیدی را از دست داده‌ایم.در جدول زیر می‌توانید نمونه‌ای از ویژگی های عمومی را مشاهده کنید که به شناسایی مرتبط ترین مرحله‌ی تکامل نیز کمک می کند. ویژگی Market نشان دهنده بلوغ بازار است. به طور مؤثر، چقدر افرادی که قرار است از این کامپوننت استفاده کنند استوار هستند؟ در Genesis هنوز بازاری وجود ندارد، در حالی که در Commodity بازار بالغ است و دیگر رشد نمی کند. در حالیکه در Genesis بازاری وجود ندارد، در حالیکه Commodity بازار ساخته شده و کاملا بالغ است و رشد چندانی نیز ندارد. درک کاربر(User Perception) یک ویژگی است که انتظارات کاربران را دربرمی‌گیرد. گر یک کامپوننت غیرمعمول، گیج‌کننده، جذاب یا شگفت‌آور باشد، وارد دسته Genesis می‌شود. در حالی که در سوی دیگر، اگر یک جزء خاص مورد انتظار باشد و درخواست اجباری، در دسته Commodity قرار می‌گیرد.قابلیت منوی رستوران همزمان با بازار پخته و یک قابلیت استاندارد در صنعت است، دوباره در دسته Commodity قرار می‌گیرد.از سوی دیگر بهینه‌سازی رستوران اگر صاحبان رستوران از قابلیت‌ها و امکانات آن متعجب شوند یا شاید حتی گیج شوند اگر نتوانند بفهمند چگونه از آن بهره‌مند شوند ممکن است جذاب باشد. بازار نیز به نظر می‌آید که ممکن است نامعلوم باشد - آیا این قابلیت برای همه رستوران‌ها قابل اعمال است یا فقط برای برخی از انواع رستوران‌ها قابلیت اعمال آن‌را دارند؟ لذا در این مورد، بهینه‌سازی رستوران به نظر می‌آید که جایی بین دسته‌های Genesis و Custom Built قرار دارد که این موضوع بر اساس سطح فهم فعلی آشکار می‌شود.نمونه ای از خواص عمومیمزیت رقابتی چیست؟به گفته Investopedia، مزیت رقابتی به عواملی اشاره دارد که به یک شرکت امکان می‌دهند که کالاها یا خدمات را بهتر یا ارزان‌تر از رقبا تولید کند. این عوامل به موجب این توانایی است که یک واحد تولیدی بتواند فروش بیشتر یا مارجین‌های برتر نسبت به رقبای بازار خود را تولید کند. به علاوه، مزیت رقابتی به دو بخش مزیت مقایسه‌ای و مزیت تفاوتی تقسیم می‌شود. مزیت مقایسه‌ای از این جنبه است که از توانایی استخراج سود بیشتر در حین ارائه یک محصول یا خدمات مشابه حاصل می‌شود. از سوی دیگر، مزیت تفاوتی درباره ارائه محصولات و خدماتی است که به نحوی برتری دارند، مثل ویژگی‌های بیشتر یا قابلیت استفاده بهتر.ویژگی‌های درک در صنعت (Perception in Industry) و تمرکز بر خواص ارزش (Focus of Value) ویژگی‌های مرتبطی هستند که بر روی سطح ممکن از مزیت رقابتی کسب‌شده از طریق یک جزء تمرکز دارند و به همین دلیل نشانگرهای مهمی از اولویت‌های استراتژیک خواهند بود. منوی رستوران بخشی از کسب‌وکار است و یک ویژگی استاندارد (table-stakes) است. همچنین، حوزه‌ای است که سازمان‌ها نمی‌خواهند بیشتر از اندازه‌ی مورد نیاز منابع را برای آن صرف کنند. همانطور که در جدول بالا نشان داده شده است، هر دوی این نشانه‌ها نشانگر بیشتری از این است که منوی رستوران یک Commodity است و از اهمیت استراتژیک بالایی ندارد.اما بهینه‌سازی رستوران به عنوان یک منبع از مزیت رقابتی در نظر گرفته می‌شود. اگر بتوانید به رستوران‌ها کمک کنید که سودآورتر باشند، احتمالاً آن‌ها تمایل بیشتری به همکاری با شما دارند و مشتریان را هم با خود به همراه می‌آورند. این حالت ممکن است هنوز تأثیر خالص مالی منفی برای شرکت داشته باشد. هزینه‌های آن بیشتر از ارزشی است که ایجاد می‌کند، اما شرکت از پتانسیل آینده‌اش هیجان‌زده است. این دو نشانه نیز نشان دهنده این است که بهینه‌سازی رستوران جایی بین دسته‌های Genesis و Custom Built قرار دارد.می‌توان استدلال کرد که برای برخی از رستوران‌ها، طراحی منو یک مزیت رقابتی است که از طریق ارائه دستورپخت‌های متفاوت و منحصربه‌فرد ایجاد می‌شود. بهتر است این را به عنوان یک کامپوننت جداگانه مدل کنیم، مانند "تحقیق و توسعه فهرست غذا" (Menu R&D) تا از قابلیت مدیریت و مرور فهرست‌ها تمایز داشته باشد. سوال عمیق‌تری هم وجود دارد: آیا این قابلیتی است که شرکت تحویل غذا آن را جزء فرآیند می‌داند؟ حتی اگر نه، ممکن است ارزشمند باشد که نقشه‌برداری شود زیرا نمایانگر یک فرصت رشد ظرفیت است.2.2. تمرین سریع یادگیری: درک تکاملهنگام آموزش واردلی‌مپینگ یا نقشه‌برداری با افرادی که برای اولین بار درگیر این فعالیت هستند، من یک فعالیت آماده‌سازی کوتاه را برگزار می‌کنم تا آن‌ها را در درک تکامل یاری دهم. این فعالیت تنها بیست تا سی دقیقه زمان می‌برد و به سرعت افراد را به سطحی می‌رساند که برای جلسه‌ی نخستین نقشه‌برداری موثر نیاز دارند. این فعالیت می‌تواند به صورت گروهی یا در گروه‌های کوچک‌تر انجام شود. برای آماده‌سازی این فعالیت، تنها دو چیز مورد نیاز است: مثالی از یک یا چند کامپوننت برای نقشه‌برداری و لیست ویژگی‌ها و خصوصیات. سپس، از هر معیار فردی عبور کرده و تعیین کنید که برای هر معیار بهترین مرحله تکاملی کدام است (همانطور که در بخش قبل دیدید اما با تمام پانزده معیار). در نهایت، تشخیص دهید که کدام معیارها بیشترین ارتباط را با کامپوننت دارند و سپس ارزیابی کنید که این کامپوننت متعلق به کدام مرحله است. اگر در گروه‌های کوچک کار می‌کنید، می‌توانید نتایج هر گروه را به عنوان یک تمرین گروهی بزرگ بررسی کنید و متوجه شوید کجا اختلاف و همگرایی وجود دارد.از این فعالیت خواهید آموخت که کامپوننت ها همیشه به طور دقیق در یک مرحله از تکامل جا نمی‌شوند. برخی از معیارها ممکن است با فاز "Product" همخوانی داشته باشند در حالی که برخی دیگر ممکن است با فاز "Commodity" همخوانی داشته باشند، بنابراین نیاز به ارزیابی کلی در مورد اینکه کدام مرحله بهترین حس را ایجاد می‌کند وجود دارد. این کمک می‌کند تا یک اصل کلیدی دیگر از نقشه‌برداری وارد شود: برای یک جزء مشخص، هیچ پاسخ صحیح واقعی برای جایگاه آن وجود ندارد. معمولاً عنصری از زاویه ذهنی و شخصیتی وجود دارد چرا که افراد مدل‌های ذهنی مختلفی از زنجیره‌های ارزش دارند. اظهار این اختلاف مفید است چرا که یک فرصت یادگیری است و به گروه اجازه می‌دهد تا درک مشترک خود را بهبود بخشند.مهمترین نکته این است که گفتگوهای موثر واقع شده و بحث شود که چرا یک کامپوننت ممکن است در چندین محل قرار گیرد. این یک روش برای به چالش کشیدن نقشه است.3. نیروهای اقلیمی:تکامل ویژگی مشخصه‌ای اصلی در واردلی‌مپینگ است. با تمرکز بر تکامل هر کامپوننت، به طور طبیعی به بررسی سناریوهای آتی جذب می‌شوید. این ویژگی یک مزیت بزرگ را برای پیشگیری از انحرافات مانند انحراف اخیر (انحراف شناختی که به رویدادهای اخیر اهمیت بیشتری می‌دهد) ایجاد می‌کند، که ممکن است باعث تمرکز بیش از حد بر روی فرصت‌ها و محدودیت‌های فعلی شود. در نقشه‌برداری واردلی، "اقلیم" به تغییراتی اشاره دارد که در منظر خارج از کنترل شما رخ می‌دهد، مانند نوآوری‌های رقبا و رویدادهای مهم جهانی. هرچه بهتر نشانه‌های اقلیمی را شناسایی کنید، بهتر می‌توانید تغییرات را پیش‌بینی کرده و آنها را در تفکر استراتژیک خود یکجا کنید.می‌توانید نیروهای اقلیمی را به نقشه خود اعمال کنید، با اینکه به هر یک از کامپوننت‌های خود به صورت جداگانه می‌پردازید، در مورد سناریوهای احتمالی و خارج از کنترل شما که ممکن است باعث تغییر آن شوند فکر می‌کنید. علاوه بر این، می‌توانید در مورد کامپوننت جدیدی که ممکن است در چشم انداز ظاهر شوند، فکر کنید. ممکن است شما تمام اطلاعات لازم برای پاسخ به این سوالات را نداشته باشید، بنابراین نیاز به تحقیقات بیشتر وجود دارد. اما این طبیعی است، زیرا نقشه‌برداری واردلی یک فعالیت یک باره نیست. پیش از اعمال نیروهای اقلیمی به نقشه اولیه خود، خوب است که در مورد الگوهای اقلیمی ارائه شده توسط جامعه مطالعه کنید. این اطلاعات به شما کمک می‌کنند تا اصول اصلی نیروهای اقلیمی و اینکه چه چیزهایی را در نظر بگیرید هنگام جستجو برای نشانه‌های اقلیمی در چشم انداز خود را بدانید. بخش‌های آینده تعدادی از الگوهای اقلیمی رایج را معرفی می‌کنم تا برای شروع به شما کمک شود.3.1. همه چیز تکامل خواهد یافت:اولین و اساسی‌ترین الگویی که باید به آن توجه کنیم این است که همهٔ کامپوننت‌ها در حال تکامل هستند. شاید سرعت یا زمان تکامل برای ما شفاف نباشد، اما طبق اصول واردلی‌مپینگ، همه‌ی کامپوننت‌ها از چپ به راست تکامل یافته یا در هر نقطه‌ای در طول تکامل ممکن است از بین بروند.کمی در مورد برخی از سیستم‌هایی که در آن‌ها کار کرده‌اید و محصولاتی که استفاده می‌کنید تامل کنید. تاکنون چگونه تکامل یافته‌اند؟ پیشبینی می‌کنید در آینده چگونه تکامل خواهند کرد؟ روی میزم، موبایل خودم را می‌بینم. در دهه 70 یا اوایل 80، تلفن‌های همراه دوربین نداشتند و تنها بازی‌های ابتدایی مانند بازی مار داشتند. امروز، دوربین‌های هوشمند از یک ایده شگفت‌انگیز و جذاب به یک انتظار اساسی تبدیل شده‌اند، با این حال هنوز فضایی برای تفاوت و تمایز وجود دارد.جدول زیر برخی از ویژگی‌ها و چگونگی ظاهر شدن آن‌ها در هر انتهای طیف تکامل را به نمایش می‌گذارد. Genesis سرزمینی ناشناخته است که در آن یک مسیر جدیدی که پیش از این وجود نداشته پیموده می‌شود. بنابراین، مرحله‌ای بسیار پرتنش، نامعلوم و غیرقابل پیشبینی بوده که به دنبال برتری رقابتی در آینده می‌گردد. این در حالی است که Commodity در حال حاضر صنعتی‌سازی شده است. این حوزه مرتب و شناخته شده و قابل اندازه‌گیری است. فرصت‌های این حوزه قبلا کشف شده و استفاده شده است و اکنون تمرکز بر پایداری و کارآیی است؛ Commodity به عنوان یک هزینه اجرای کسب و کار شناخته می‌شوند نه منبعی برای برتری رقابتی. برخی از ویژگی هایی که با تکامل تغییر می کنندبرای کمی تامل به این سوال توجه کنید: "چرا همه چیز تکامل پیدا می‌کند (یا می‌میرد)؟". پاسخ در واردلی‌مپینگ، رقابت عرضه و تقاضا است. هر چه تقاضا برای تکامل یک کامپوننت بیشتر باشد، احتمال تکامل آن بیشتر است زیرا برای تکامل انگیزه‌هایی وجود دارد. در ارزیابی تغییرات اقلیمی ممکن، این سوال بسیار مهم است: "تا چه حد تقاضا برای تکامل این کامپوننت وجود دارد؟".3.2. کامپوننت‌ها با هم تکامل می‌یابند:همانطور که مشاهده کردید، واردلی‌مپینگ از زنجیره‌های ارزش ساخته شده است، که در واقع کامپوننت‌ها و وابستگی‌های آن‌ها هستند. وابستگی‌ها نشان می دهد که تغییر در یک کامپوننت ممکن است بر کامپوننت‌های وابسته نیز تأثیر بگذارد. اغلب، کامپوننت‎‌های مختلف با هم تکامل می یابند. نمونه‌هایی از آن در اطراف ما وجود دارد و در طول تاریخ نیز وجود داشته است.امروز صبح زود به سوپرمارکت آنلاین رفتم تا نان و شیرم را بخرم. کالا‌هایی را انتخاب کردم و مبلغ نهایی را پرداخت کرده و کالاها برای من ارسال شد. چند سال پیش، تمام خرید‌ها به حضور در فروشگاه نیاز داشت و تسویه‌حساب‌ها به یک کارمند نیاز داشتند که هر کالا را اسکن کرده و مبلغ نهایی را دریافت کند.برخی فروشگاه‌ها دستگاه‌های محاسبه و تسویه را جایگزین کارکنان کرده اند اکنون برای یک کارمند امکان نظارت بر پرداخت‌های متعدد وجود دارد.فعالیت در این حوزه تغییر کرده است. در این فروشگاه ها صندوق دار به جای اسکن قیمت و دریافت پول مسئول رفع مشکلاتی است که برای مشتریان ایجاد می‌شود. مثلا زمانی که مشتریان نمی توانند اقلام خود را اسکن کنند و یا خودشان مبلغ نهایی را پرداخت کنند.یک مثال خوب از تکامل در دنیای امروزی کامپوننت‌های کار از راه دور است. با گسترش روزافزون اینترنت و نسل جدیدی از ابزارهای همکاری از راه دور مانند Zoom، Slack، و Google Drive، شرایطی فراهم شدند که این روش کاری به سرعت تحول یافت. 3.2.1.سیستم های مرتبه‌ی بالاتر منابع جدیدی از ارزش ایجاد می کنند:یکی از الگوهای مهم تکاملی این است که "سیستم های مرتبه بالاتر، منابع جدید ارزش ایجاد می کنند". همانطور که در تصویر زیر نشان داده شده است، این الگو می‌گویند بعضا با تکامل Commodity‌ها امکان ایجاد کامپوننت‌های جدید Genesis فراهم می‌شود. مثلا وقتی برق به یک کالا و خدمت گسترده تبدیل شد، امکان ایجاد بسیاری از انواع جدید از محصولات را فراهم کرد. با تکامل خدمات پرداخت آنلاین، کسب و کارهای بیشتری توانستند به صورت آنلاین فعالیت کنند. به همین ترتیب، با توسعه و گسترش اینترنت، منبع بسیاری از منابع تفریحی و تجاری با ارزش شد. این شرایط الگویی است که باید هنگام اعمال تفکر اقلیمی در نقشه‌های خود در نظر بگیرید. می‌توانید سؤالاتی از قبیل این بپرسید که: «با تکامل این کامپوننت چه چیزی ممکن می‌شود؟ چه کامپوننت‌های جدیدی می‌تواند وجود داشته باشد؟»سیستم های مرتبه‌ی بالاتر منابع جدیدی از ارزش ایجاد می کنند3.2.2. کارایی نوآوری را امکان پذیر می‌کند:تکامل یک کامپوننت ممکن است به ایجاد منابع جدید ارزش منجر نشود، در عوض، ممکن است به تکامل کامپوننت‌ها موجود و ایجاد ارزش جدید منجر شود. خدمات وب آمازون یک نمونه کلاسیک از این نوع است. همانطور که آمازون قابلیت های تجارت الکترونیکی خود را توسعه داد، تجارت آن به شدت رشد کرد. در نتیجه، آمازون به یک متخصص در مدیریت زیرساخت برای ترافیک اینترنت در مقیاس بالا تبدیل شد. سپس توانست این خدمت را به یک تجارت رایانش ابری جداگانه تقسیم کرده که زیرساخت فناوری اطلاعات را به سمت تبدیل شدن به یک commodity حرکت دهد. هر زمان که در حال کاوش در تکامل یک کامپوننت روی نقشه خود هستید، خوب است که بررسی کنید چگونه کامپوننت‌های دیگر نیز ممکن است در نتیجه تغییر چشم‌انداز با محدودیت‌های جدید یا متفاوت، تکامل یابند.3.3. موفقیت‌های گذشته اینرسی ایجاد می‌کند:مثلی وجود دارد که می‌گوید: "سری که درد نمی‌کند، دستمال نمی‌بندند". وقتی کسب‌وکاری خود را به عنوان رهبر بازار معرفی می‌کند و همه‌ی معیارهای کلیدی آن مثل درآمد، درست به نظر می‌رسند، چرا ریسک تغییر را به جان بخرد؟ اما از آنجایی که شرایط همیشه در حال تغییر است، همانطور که شرکت‌هایی مانند کداک متوجه شدند احساس امنیت ممکن است کاذب باشد. در فصل‌های قبل نیزنمونه‌هایی از نشانه‌های درونی اینرسی، مانند سیستم‌های قدیمی و روش‌های ناکارآمد کار که از روشی رضایت‌بخش مدرن‌سازی نشده‌اند، ارائه شده است. اینرسی همیشه چیزی است که باید در واردلی‌مپ به دنبال آن بود، به خصوص در مرحله‌ی Product که در آن مفاهیم سودآوری هستند، اما ممکن است صنعتی شوند و ارزش خود را از دست بدهند. خوب است سوالاتی مانند «آیا واقعاً هنوز یک محصول داریم یا محصول ما در حال تبدیل شدن به یک کالا است؟»، «آیا ما بیش از حد بر جریان‌های درآمد فعلی تمرکز کرده‌ایم و نسبت به تغییراتی که در این کامپوننت روی می‌دهد بی‌اعتنا هستیم؟» بپرسیم؟ احتمال این وجود دارد که ورودی‌های جدید کار ما را مختل کنند؟.اینرسی چیزی است که می توانید با استفاده از یک شکل مستطیل توپر همانطور که در تصویر زیر نشان داده شده است، بر روی نقشه خود برجسته کنید، که نشان می دهد کامپوننت در حال تکامل از محصول به کالا است اما سازمان مایل به پذیرش یا تشخیص آن نیست، و بنابراین، اینرسی دارد.تجسم اینرسی در نقشه واردلیدو الگوی اینرسی نزدیک به هم عبارتند از: هر چه مدل گذشته موفق‌تر باشد اینرسی افزایش می‌یابد و اینرسی می‌تواند سازمان را بکشد. شما می‌توانید اصول پشت این الگوها را با تلاش برای درک اینکه کسب‌وکارتان در رابطه با کامپوننت‌های خاص چقدر موفق است و ذینفعان چقدر به آن کامپوننت وابسته هستند، در عمل مشاهده کنید. سؤالاتی مانند موارد زیر می تواند به شروع این گفتگوها کمک کند: "به نظر شما <کامپوننت x> چقدر در موفقیت این سازمان کمک می کند؟"، "اگر مختل می شدیم و <کامپوننت x> دیگر مرتبط نبود چه می شد؟" به نظر من <کامپوننت x> به زودی گسترده خواهد شد، آیا با توجه به این شرایط باید روی چیزی متمایزتر و جدید سرمایه گذاری کنیم؟».این پرسش‌ها عمداً کمی تحریک‌کننده هستند تا ببینیم افراد تا چه اندازه به موفقیت‌های فعلی/ گذشته اعتقاد دارند. به نظر من افزایش کمی حرارت در اندازه‌های کوچک به مردم کمک می کند تا باورهای خود را به چالش بکشند، فقط مراقب باشید که زیاده روی نکنید.3.4. تغییرات همیشه خطی نیست:واردلی‌مپ ممکن است این تصور را ایجاد کند که هر کامپوننت یک مسیر تکاملی قابل پیش بینی از Genesisتا Commodity را دنبال می‌کند. حقیقت این است که تکامل موضوع پیچیده ای است. چگونه، چرا، چه زمانی و با چه سرعتی تکامل اتفاق می افتد، همه چیزهایی هستند که می‌توانند به طور قابل توجهی متفاوت باشند. برخی از صنایع ممکن است کند حرکت کنند، اما یک تغییر ناگهانی، مانند فناوری جدید، می تواند به سرعت نوآوری را سرعت بخشد. تعدادی از صنایع این موضوع را با این فراگیری کرونا تجربه کردند، به ویژه پلت‌فرم‌های همکاری آنلاین مثل Miro. حضوری کار کردن دیگر ممکن نبود و همه ما برای کارگاه‌ها، جلسات، کنفرانس‌ها و هر همکاری دیگری که معمولاً حضوری بود، به Miro (یا محصولات مشابه) روی آوردیم.طبق مطالعه ای در وب‌سایت AWS ، Miro در سال‌های قبل از همه‌گیری به طور پیوسته رشد کرد. اما در دوران کرونا، Miro تنها در دو سال 500 درصد رشد کرد و تا ژانویه 2022 به 30 میلیون کاربر رسید که 99 درصد از آن‌ها در Fortune 100 بودند. اینکه Miro خیلی سریع تغییر مقیاس داده و توانست محصولی بسیار قابل اعتماد ارائه کند، شگفت‌انگیز است. شرکت‌ها در سراسر جهان در هر منطقه زمانی به Miro برای راه‌اندازی متکی هستند. اگر Miroنمی‌توانست کسب و کار، فناوری و سازمان خود را در زمانی که نرخ تغییر در چشم‌اندازش به شدت افزایش می‌یابد، گسترش دهد، Miroفرصت تعیین‌کنندگی در بازار را از دست می‌داد.همانطور که بر روی اجزای موجود در واردلی‌مپ‌های خود کار می کنید، داستان Miro را در ذهن خود نگه دارید (یا هر داستانی مثل این که بیشتر به شما مربوط است). فقط به احتمال تکامل کامپوننت‌ها در آینده نگاه نکنید، به سرعت تکامل آن‌ها در گذشته نگاه کنید. این کار ممکن است به شما کمک کند سیگنال‌هایی را ببینید که به سرعت در شرف تغییر است یا به شما در جایی که برای تغییر سرعت آماده نیستید هشدار دهد. اگر چشم‌انداز شما وارد دوران "تعیین کننده بازار" شود و در آن زمان سرعت تغییرات ناگهان تشدید شود، ممکن است بخش‌هایی از معماری شما به گلوگاه تبدیل شود. این جمله به معنای نیاز به ساختن سیستمی که بی‌نهایت مقیاس‌پذیر است، نیست، بلکه همه چیز در مورد ارزیابی احتمالات و تصمیم‌گیری آگاهانه در مورد ریسک‌ها و فرصت‌هایی است که می‌خواهید روی آن‌ها سرمایه‌گذاری کنید و برای آن‌ها بیشتر آماده باشید.3.5. ارزیابی تاثیر تغییرات اقلیمی:پس از اعمال نیروهای بالقوه اقلیمی بر روی نقشه، خوب است که از سطح بالا به شرایط جهانی به شکلی مشابه زمانی که نقشه در ابتدا ایجاد شد نگاه کنید. برای مثال، ممکن است همانطور که در تصویر نشان داده شده، تمام کامپوننت‌های شما به سمت راست نقشه حرکت کنند و سازمان شما هیچ منبعی برای مزیت رقابتی آینده نداشته باشد. همچنین ممکن است بسیاری از کامپوننت‌های شما ظرف 1 تا 2 سال به یک کالا(commodity) تبدیل شوند. اگر استراتژی فعلی شما مستلزم سرمایه گذاری عمده در آن زمینه‌ها باشد، این یک هشدار بزرگ است زیرا دیگر فرصتی برای تمایز ارائه نمی‌دهند. به احتمال زیاد ادامه کار به شکل فعلی اتلاف منابع برای یک بخش است که به زودی در دسترس همه خواهد بود.تغییرات اقلیمی نشان دهنده فقدان تمایز دهنده های آینده استشرکتی در انگلستان، حدود یک دهه قبل یک CRM داخلی ساخته بود که در آن زمان چنین تصمیمی قابل توجیه بود. زمانی آن‌ها بسیار مشتاق بودند که به یک CRM مدرن مانند Salesforce برسند که کارکرد آن بسیار ارزان‌تر بود و قابلیت‌های بسیار پیشرفته‌تری داشت. با این حال، مشکل این بود که CRM بخشی از همان سورس کدی بود که برخی ویژگی‌های آن را سفارشی‌سازی کرده بودند. اساساً هزینه‌های ایجاد محصول مستقل و commodity بسیار بالا بود. این نوع بینشی است که کارشناسان فناوری می‌توانند به جلسات واردلی‌مپینگ بیاورند: فکر کردن به تصمیمات بالقوه ساخت در مقابل خرید آینده و شناسایی هزینه‌های معماری مرتبط. حتی بهتر از آن، شناسایی چیزهایی است که ممکن است حتی زودتر به یک کالا(commodity) تبدیل شوند و در وهله اول آنها را به سایر بخش‌های سیستم متصل نکنید.در طی یک جلسه نقشه واردلی‌مپینگ در فضای مدیریت املاک، از حاضران مشاهداتشان را پرسیدم. وقتی به مدیر محصول رسیدیم، او گفت: «همه چیز در صنعت ما خیلی سریع تکامل می‌یابد! از چپ به راست فقط در یک سال!». این به این دلیل بود که رقبا به راحتی می‌توانستند از یکدیگر کپی کنند، بنابراین هیچ راهی برای ایجاد مزیت پایدار در هیچ زمینه‌ای وجود نداشت. این شرایط لحظه‌ای بزرگ برای برخی از افراد گروه بود، به‌ویژه آن‌هایی که ذهنیت کمتری نسبت به تجارت و محصول داشتند. آن‌ها درک کردند که منبع دائمی برای نوآوری‌های جدید ضروری است.زمانی که به قسمت پنجم چرخه استراتژی رسیدید، زمان آن فرا رسیده که در مورد انتخاب‌ها فکر کنید. چگونه می خواهید به طور فعال چشم انداز را تغییر دهید؟ کدام کامپوننت‌ها را می‌خواهید به تکامل برسانید، چگونه سرمایه‌گذاری‌ها را اولویت‌بندی می‌کنید و چقدر سرمایه‌گذاری در هر حوزه درست است؟ پاسخ به این سؤالات در سطح کسب و کار، رهبران نوسازی را قادر می سازد تا در ایجاد یک طرح توجیهی مدرن‌سازی،روی شناسایی بالاترین فرصت‌های نوسازی اهرمی تمرکز کنند.باید تاکید کرد که تصمیم گیری لازم نیست در همان کارگاهی که واردلی‌مپ ایجاد می شود اتفاق بیفتد. طبیعی است که چندین جلسه با افراد و گروه های مختلف داشته باشید. و ممکن است لازم باشد که با استفاده از تکنیک‌هایی مانند Event Storming به عمق چشم‌انداز بروید تا قبل از اینکه وارد تصمیم‌گیری شوید، نقشه‌های دقیق‌تری ایجاد کنید. البته، خوب است که انتخاب‌های استراتژیک ممکن را از همان جلسه‌ی اول بررسی کنید و در طول زمان به اصلاح آن‌ها ادامه دهید. ریسک اصلی، حفظ سطح بالا و دلبستگی به ایده‌های اولیه است که با تجزیه و تحلیل‌های دقیق‌تر تأیید نشده‌اند.همانند سایر مراحل چرخه‌ی استراتژی، واردلی‌مپینگ نیز اصول و الگوهایی را برای مرحله‌ی رهبری ارائه می دهد. این الگوها پیشرفته در نظر گرفته می‌شوند. تسلط بر الگوهای اقلیمی و دکترین قبل از اقدام به یک استراتژی به سبک هالیوود بسیار مهمتر است. ابتدا باید فرهنگ، تفکر و توانایی درستی برای اجرا داشته باشید. با این وجود، اگر اخطارها را در نظر داشته باشید، الگوهای گیم‌پلی جذاب هستند و ارزش یادگیری دارند. انجمن‌ها بیش از شصت الگوی گیم پلی را جمع آوری کرده‌اند. در ادامه مجموعه‌ای از الگوها را معرفی می‌کند تا به شروع سفر شما به موضوع کمک کند.4.1. شتاب دهنده‌های تکامل:یکی از گزینه‌ها برای تلاش عمدی برای تکامل چشم‌انداز، استفاده از شتاب دهنده‌هاست. این‌ها اقداماتی هستند که تکامل یک یا چند کامپوننت را به نفع مزیت‌های درک شده شما تسریع می‌کنند. برای هر کامپوننت روی نقشه، به این فکر کنید که چگونه می‌توانید از تکامل کامپوننت منتفع شوید و سپس فهرست شتاب‌دهنده‌ها را برای شناسایی بهترین گزینه بررسی کنید. همانطور که در تصویر زیر نشان داده شده است، شتاب دهنده‌ها روی واردلی‌مپ با استفاده از فلش‌ها نمایش داده می شوند.تجسم شتاب دهنده ها در واردلی‌مپ4.1.1. رویکردهای باز:رویکردهای باز، مانند اوپن سورس، یک شتاب دهنده رایج هستند. با منبع‌باز کردن، یک کامپوننت گسترده‌تر می‌شود و هرکسی که به مولفه علاقه‌مند است، می‌تواند در توسعه آن مشارکت کند. Big Tech به شدت به اوپن سورس متکی است. گوگل، آمازون و مایکروسافت همگی به درجات مختلف به اوپن سورس متکی هستند. به عنوان مثال، مایکروسافت کل دات نت فریم ورک را به صورت متن باز کرد. منبع باز یک توانمندساز نوآوری جامعه محور در طیف وسیعی از زمینه ها و دانشگاه است. TensorFlow یک پلت فرم یادگیری ماشین اوپن سورس با بیش از سه هزار مشارکت کننده در GitHub است. TensorFlow زندگی خود را به عنوان یک قابلیت داخلی که توسط تیم Google Brain استفاده می شود آغاز کرد. اما به جای حفظ خصوصی و کسب مزیت از آن، تیم تصمیم گرفت از اوپن سورس به عنوان یک شتاب دهنده استفاده کند.اوپن سورس بودن یک کامپوننت به معنای از بین بردن هر مزیتی است که ممکن است داشته باشید زیرا اکنون همه‌ی رقبای شما می توانند از آن استفاده کنند. وقتی از منظری دیگر به آن نگاه کنیم، منطقی‌تر است. اگر رقیب شما از طریق یک جزء خاص نسبت به شما برتری پیدا کند، نسخه‌ی اوپن سورس شما از کامپوننت می تواند با اجازه دادن به یک جامعه‌ی بزرگ برای مشارکت و توسعه‌ی نسخه های رقیب، مزیت آن را از بین ببرد. علاوه بر این، شما هستید که شهرت برند را افزایش می‌دهید، زیرا آن را به جامعه اوپن سورس دادید.بسیاری از رهبران حاضر نیستند حتی در مورد ایده‌ی اوپن سورس بودنِ یک کامپوننت که رقبای آن‌ها می‌توانند به آن دسترسی داشته باشند، بحث کنند، اما بررسی احتمالات مهم است، به ویژه در نظر داشته باشید که یک رقیب می‌تواند از اوپن سورس علیه شما استفاده کند.4.1.2. اثرات شبکه:همانطور که اوپن سورس بودن یک کامپوننت با باز کردن امکان مشارکت برای کل جوامع، تکامل را تسریع می‌کند، اثرات شبکه نیز با اجازه دادن به گروه وسیع‌تری از افراد برای مشارکت، تکامل را سریع می‌کند. اثرات شبکه به ویژه در شبکه‌های اجتماعی قابل توجه است. هرچه افراد بیشتری به پلتفرم بپیوندند، به ویژه تولیدکنندگان محتوای با ارزش که جمعیت را جذب می کنند، اکوسیستم سریعتر رشد و توسعه می‌یابد. آیا ممکن است که اثرات شبکه بتواند تکامل چشم انداز شما را تسریع کند؟مثال خوبی که دوست دارم به خاطر بسپارم Slack است، ابزار چت سازمانی. Slack با باز کردن Slack از اثرات شبکه به عنوان یک شتاب دهنده استفاده کرد. آن‌ها توسعه دهندگان اجازه دادند برنامه‌های Slack سفارشی ایجاد کنند. یکپارچه‌سازی Slack با سایر ابزارها یکی از ویژگی‌های مهم آن است که باعث شده شرکت‌های زیادی از آن استفاده کنند. حجم زیادی از برنامه‌های کاربردی سفارشی یکپارچه شده با Slack بسیار سریع تولید شده است. این برنامه در زمانی بسیار کمتر از آنچه که خود Slack قادر به تولید آن‌ها بود ایجاد شده اند و موجب تکامل بسیار سریع اکوسیستم Slack شده‌اند.4.1.3. همکاری:هنگامی که به دنبال سرعت بخشیدن به تکامل یک کامپوننت هستید، همکاری شتاب دهنده‌ی دیگری است که باید در نظر بگیرید. شراکت با یک شرکت دیگر می تواند دسترسی به قابلیت‌های ضروری را بسیار سریع‌تر و مقرون به صرفه‌تر از ساختن آن ابزار توسط خودتان فراهم کند. نمونه‌ای از این همکاری را در سال 2019 دیدیم، زمانی که اپل و گلدمن ساکس برای راه‌اندازی یک کارت اعتباری جدید به نام Apple Card به یکدیگر پیوستند. اپل می‌خواست برای سرعت بخشیدن به سرویس Apple Pay خود کارت‌های اعتباری فیزیکی ارائه دهد. اما اپل به تنهایی توانایی راه اندازی کارت اعتباری را نداشت و همکاری بسیار مقرون به صرفه‌تر و سریعتر از توسعه آن به تنهایی بود.4.2. سرعتگیرهای تکامل:برخلاف شتاب‌دهنده‌ها، سرعتگیرها را می‌توان برای کاهش سرعت تکامل به کار برد. هر زمان که کامپوننتی را شناسایی کردید که از آن مزیتی به دست می‌آورید، طبیعتاً می‌خواهید با کاهش سرعت تکامل کامپوننت را کاهش داده تا خیلی زود به کالا (Commodity) تبدیل نشود و با این‌کار، مدت بهره‌مندی خود از مزایای آن را افزایش دهید. در زیر نمونه‌هایی از سرعتگیرها هستند که باید در مورد استفاده از کامپوننت‌های خود در نظر بگیرید. همانند شتاب‌دهنده‌ها، سرعتگیرها با یک فلش نمایش داده می‌شوند، این بار همانطور که در شکل زیر نشان داده شده است، از راست به چپ نمایان می‌شوند.سرعتگیرها در واردلی‌مپینگ4.2.1. حقوق مالکیت معنوی:حقوق مالکیت معنوی برای محافظت از مزیت رقابتی در برخی صنایع به کار گرفته می شود. آن‌ها با ممانعت از استفاده رقبا از قابلیت‌های خاصی که شما اختراع کرده اید، به عنوان سرعتگیر عمل می کنند. یکی از بزرگترین شکایت های حقوق مالکیت معنوی در سال های اخیر، پرونده‌ی اپل علیه سامسونگ بود. دادگاه کره‌ی جنوبی به دلیل نقض چندین پتنت اپل، سامسونگ را به پرداخت 539 میلیون دلار به اپل محکوم کرد. اپل ادعا کرد که سامسونگ به طور غیرقانونی جنبه‌هایی از طراحی آیفون را کپی کرده است که توسط پتنت‌های آن محافظت شده است. آیفونِ اپل انقلابی بود، بنابراین منطقی بود که می خواست تا حد امکان از مزیت خود محافظت کند و رقبا را وادار کند تا برای ساخت گوشی‌های هوشمندی به خوبی آیفون، تلاش بیشتری کنند.4.2.2. ترس، عدم اطمینان و شک:یکی دیگر از راه‌های کاهش سرعت تکامل، تغییر منفی درک کاربران، کاهش تقاضای آن‌ها برای یک کامپوننت کامل‌تر است. در واقع، این یک تکنیک تبلیغاتی است که روایت‌های نادرستی را ایجاد می‌کند یا ریسک‌های کوچک را بیش از حد به معرفی می‌کند. در چند سال گذشته شاهد استفاده از ترس، عدم قطعیت و شک به عنوان تکنیکی برای ترساندن مشتریان از فناوری‌های ابری بوده‌ایم. مثلا گفته می‌شود اگر از نرم‌افزارهای ابری استفاده کنید مالکیت داده‌های خود را از دست می‌دهید. در سال 1877، نیویورک تایمز مقاله‌ای نوشت و به اختراع گراهامبل یعنی تلفن حمله کرد. این روایت با برانگیختن نگرانی های مربوط به حفظ حریم خصوصی باعث ترس در بین خوانندگان شد.هنگامی که به نقشه‌های خود نگاه می کنید، ممکن است متوجه علائمی شوید که در آن، این گروه سرعتگیرها می تواند به کار گرفته شود. شاید یک تازه وارد مزاحم به صنعت شما ملحق شده باشد و بسیار سریعتر از توانایی شما در حال حرکت باشد. اگر قادر به رقابت از طریق نوآوری نیستید، استفاده از این سرعتگیر به عنوان یک تکنیک بازاریابی ممکن است تنها انتخاب شما باشد. هنگام استفاده از این تکنیک به مسائل اخلاقی نیز توجه کنید.4.3. بازار بازی می‌کند:بازی‌های بازار دسته‌ای از الگوهای بازیست که شامل انجام اقداماتی است که برخی از جنبه‌های بازار را تغییر می‌دهد، مانند توسعه‌ی محصول، تغییر درک و سیاست قیمت‌گذاری. این بخش معرفی مختصری از دو بازی رایج بازار را ارائه می‌دهد که در طیف گسترده ای از صنایع مرتبط هستند.4.3.1. ایجاد تمایز:یک رویکرد واضح این است که محصولاتی بهتر از رقبای خود برای کاربران ایجاد کنید. هنگامی که به دنبال فرصت‌هایی برای متمایز کردن هر یک از کامپوننت‌های خود هستید، لیست ویژگی های محصول که در زیر آمده نقطه شروع خوبی است: خدمات بهتر به مشتری خدمات پس از فروش تنوع بیشترحمل و نقل سریع تر یا ارزان تر مکانزیبایی شناسی قابلیت استفاده ویژگی های انحصاری سفارشی سازیو... داستان اولیه AirBnB نمونه خوبی از تمایز ویژگی های محصول است. AirBnB لیست‌های خود را با افزودن تصاویر حرفه‌ای و با کیفیت بهبود بخشید. این‌کارمنجر به رشد عظیمی برای شرکت شد .5. جمع بندی:در دو قسمت اخیر، در مورد واردلی‌مپینگ، کاربرد آن و نحوه و فرایند ایجاد یک نقشه‌ی واردلی صحبت کردیم. از این تکنیک در طراحی محصول یا طراحی مسیر و سفر مدرن سازی خود می‌توانید بهره مند شوید. علیرضا ارومند علیرضا ارومند Sat, 30 Dec 2023 19:26:44 +0330 https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D8%B4%D8%B4%D9%85-wardley-mapping-%D8%A8%D8%AE%D8%B4-%DB%8C%DA%A9-dfhlyibylj7c 1. مقدمه:واردلی‌مپینگ برای رهبران کسب و کار و فناوری بسیار مهم است، اما در طول سفر مدرن‌سازی این اهمیت به مراتب بیشتر است. واردلی‌مپینگ به عنوان ابزاری محبوب و بسیار موثر ظاهر شده است. در این مدل، کسب و کار را با استفاده از زنجیره‌های ارزش و تکامل‌ آن‌ها به تصویر می‌کشیم. واردلی‌مپینگ این امکان را فراهم می‌کند تا بحث‌های غنی‌تر و با جزئیات بیشتری در مورد استراتژی صورت گیرد.نکته‌ی مهمتر اینکه واردلی‌مپینگ همکاری را برای تعیین استراتژی بیشتر کرده و به گروه‌های متنوعی، از جمله متخصصان فنی و کسب و کار، اجازه می‌دهد که دیدگاه‌های خود را از کسب و کار شرح داده و جنبه‌های فناوری و تجاری را به هم مربوط کنند.واردلی‌مپینگ فقط یک تکنیک نیست بلکه جامعه‌ی بزرگی است که به مرور زمان در حال رشد است. واردلی‌مپینگ در محیط‌های کسب و کاری و فناوری در حال تبدیل شدن به عنوان عمده‌ترین زبان استراتژی است. بنابراین، یادگیری واردلی‌مپینگ و شناخت و جزئیات آن بسیار مهم است. دلیل دیگری نیز برای یادگیری واردلی‌مپینگ وجود دارد و آن دلیل این است که اغلب، با بسیاری از تکنیک‌های دیگری که در این سری نوشته‌ها بررسی خواهیم کرد ترکیب می‌شود، مثلا در قسمت‌های آینده که در مودر ساختار تیم‌ها صحبت می‌کنیم از این تکنیک نیز بهره‌مند خواهیم شد.در این قسمت، مراحل ایجاد یک نقشه‌ی واردلی و برخی از اصول و الگوهای مرتبط با این روش را مشاهده خواهید کرد. اما به یاد داشته باشید که واردلی‌مپینگ موضوع بزرگی است که برای تسلط روی آن به وقت زیادی نیاز دارید، بنابراین، این نوشته به شما کمک می‌کند تا مسیر خود در راه یادگیری واردلی‌مپینگ را شروع کنید و پیوندها و منابع ارزشمندی را برای ادامه‌ی مسیر در اختیار شما قرار خواهد داد.به یاد داشته باشید که واردلی‌مپینگ کاربردهای گسترده‌ای دارد. در حالی که ابزاری عالی برای ساخت و ارائه‌ی یک طرح تجاری است، همچنین ابزاری است که به شما کمک می‌کند تا چشم‌انداز کار را بهتر درک کنید و ایده‌های خود را بهتر به دیگران منتقل کنید. در طول سفر مدرن‌سازی معماری در هر سطحی از معماری، می‌توانید از واردلی‌مپینگ کمک بگیرید.ذکر این نکته خالی از لطف نیست که توالی قسمت‌های این نوشته خیلی مهم نیست. به عنوان مثال، پس از ایجاد یک نقشه واردلی، ممکن است نیاز داشته باشید که با استفاده از تکنیک EventStorming به درک دامنه بپردازید یا به جستجوی راه حل‌های ممکن بپردازید تا بتوانید در نقشه‌های واردلی‌تان تغییراتی ایجاد کنید.نکته‌ی پایانی پیش از اینکه مبحث اصلی این قسمت را شروع کنیم این است که هر کاری را با انجام دادن بهتر خواهیم آموخت. پس بعد از مطالعه‌ی این فصل خالی از لطف نیست که به سراغ کسب و کاری که در آن هستید بروید و واردلی‌مپ آن را ایجاد کنید.2. چرخه‌ی استراتژی:هنگام تمرین استراتژی، به خصوص با واردلی‌مپینگ، داشتن یک مدل از فرآیند استراتژیک می‌تواند به شما کمک کند تا مراحل مرتبط، چگونگی ارتباط آن‌ها و زمان انجام هر مرحله را مشخص کنید. این‌کار به شما در پاسخ به سوالات اساسی مانند: "از کجا باید شروع کنیم؟"، "کاری باید انجام دهیم چیست؟" و "آیا ما این کار را اشتباه انجام می‌دهیم؟" کمک می‌کند. سایمون واردلی، خالق واردلی مپینگ، همچنین خالق چرخه‌ی استراتژی (Strategy Cycle) نیز هست. این چرخه یک رویکرد تکراری به استراتژی را با پنج مرحله ترسیم می کند: هدف، چشم انداز،اقلیم، دکترین، و رهبری. این روش بر اساس پنج عامل سان تزو و چرخه‌ی OODA جان بوید ساخته شده است. تصویری از چرخه‌ی استراتژی را در زیر مشاهده می‌کنید.چرخه استراتژی (سیمون واردلی) شروع یک دوره از چرخه استراتژی با تعریف هدف شروع می‌شود. در واقع، این چیزی شبیه به یک بیانیه‌ی ماموریت است. این بیانیه تعریف می‌کند که چرا یک سازمان باید وجود داشته باشد و اهداف نهایی آن چیست. در ادامه، چند نمونه از بیانیه‌های ماموریت آورده شده است:هدف داتین فراگیری مالی است. ما میخواهیم تمامی افراد و کسب‌وکارها به‌ویژه محرومان یک جامعه به محصولات و خدمات مالی مفید و مقرون‌به‌صرفه دسترسی داشته باشند که می‌تواند نیازهای آنها را برآورده ‌کند؛ این خدمات شامل تراکنش‌های مالی، پرداخت‌ها، پس‌انداز، سرمایه‌گذاری و بیمه می‌شود که باید بدون محدودیت زمانی و مکانی، در دسترس همه‌ی اعضای جامعه قرار گیرد.هدف نیک‌آموز ارائه‌ی آموزش‌های با کیفیت در حوزه‌ی مهندسی نرم‌افزار و داده است. ما می‌خواهیم هر فردی در کشور به آموزش‌های با کیفیت از کانال‌های مختلفی دسترسی داشته باشد. هدف Flatiron Health این است که با یادگیری از تجربه‌ی افرادی که با سرطان دست و پنجه نرم کرده اند، زندگی‌ها را بهبود ببخشد.هدف Hargreaves Lansdown این است که افراد را برای صرفه‌جویی و سرمایه‌گذاری با اعتماد به نفس توانمند کند. آن‌ها خدماتی ارائه می‌کنند که از افراد در فرایند دستیابی به اهداف مالی صحیح حمایت می‌کند. شرکت Carbon Re هر ساله هزاران تن از دی اکسید کربن حاصل از فعالیت‌های بشر را از بین می‌برد. تمرکز ما بر روی بزرگ‌ترین فرصت‌ها و چالش‌ها در صنایعی مانند تولید سیمان، فولاد و شیشه است. ما می‌دانیم اگر بخواهیم تا سال 2050 به احتمال 50% دمای جهانی 1.5 درجه کمتر افزایش یابد، باید 90 درصد از ذخایر زغال‌سنگ و 60 درصد از ذخایر شناخته شده‌ی نفت و گاز را در زمین باقی بگذاریم.در طول فرایند گوش دادن، می‌توانید از هر نهاد دیگری بخواهید که با کلمات خود هدف سازمان را شرح دهد. سپس می‌توانید میزان انحراف و تطابق در دامنه‌ی پاسخ‌ها را ارزیابی کنید.انتقال به مرحله‌ی دوم این چرخه به معنای نقشه کشی از چشم‌انداز فعلی می‌باشد. یعنی باید محصولات، خدمات، توانمندی‌ها و موارد مرتبط دیگری که بر استراتژی تأثیر می‌گذارند و تعاملات میان آن‌ها را شناسایی شود. چشم انداز باید شامل تمام منظره‌ی رقابتی باشد، یعنی رقبا نیز باید در نظر گرفته شده باشند نه اینکه فقط خود سازمان در چشم‌انداز باشد. به یاد داشته باشید که این مرحله در مورد تعریف یک استراتژی یا شناسایی راه حل‌ها نیست؛ بلکه فقط وضعیت فعلی قرار است شناسایی شود تا بتواند به عنوان پایه‌ای برای اکتشاف استراتژیک استفاده شود. واردلی‌مپینگ، یک نقشه با استفاده از زنجیره‌های ارزش موجود در چشم‌انداز را به صورت بصری نمایش می‌دهد.پس از تهیه‌ی نقشه از چشم‌انداز ، مرحله‌ی بعدی این است که به اقلیمی که کسب و کار شما در آن فعالیت می‌کند (نه اقلیم زمین) بپردازید. این مرحله در واقع، در مورد شناسایی تغییرات خارج از کنترل شما است که بر چشم انداز کسب و کار شما ممکن است تأثیر بگذارند. هر چشم اندازی به دلیل نیروهای مختلف اقلیمی به طور مداوم در حال تکامل است. حتی اگر یک کسب و کار ساکن مانده و هیچ کاری انجام ندهد، چشم‌انداز همچنان در حال تکامل خواهد بود و نیروهای مختلفی مانند اقدامات رقبا، رویدادهای جهانی مانند ویروس کرونا و معرفی قوانین و مقررات جدید بر کسب و کار تأثیر خواهند داشت. به عنوان مثال، شرکت Blockbuster تلاش کرد که با خدمات اجاره‌ی DVD در فروشگاه‌های سنتی خود، کارش را ادامه دهد بدون اینکه سیگنال‌های اقلیمی‌ای را که نشان می‌دهد که پخش آنلاین به طور چشمگیری چشم‌انداز کسب و کار را تغییر خواهد داد، تشخیص دهد.فاصله‌ی بین موفقیت استراتژیک و یک فاجعه‌ی کامل، شناسایی تغییرات احتمالی اقلیمی است. یک نقشه‌ی واردلی، برای نمایش تأثیر تغییرات اقلیمی می‌تواند کاربرد داشته باشد. همچنین الگوهای اقلیمی‌ای نیز وجود دارد که می‌تواند برای راهنمای شما باشد. این به رهبران نوآوری کمک می‌کند که سفر مدرن‌سازی معماری خود را بیشتر بر اساس امکانات آینده طراحی کرده و بپیمایند تا موضوعات و شرایط کنونی.پس از اقلیم، مرحله بعدی این چرخه به دکترین می‌پردازد. دکترین بیشتر در مورد این است که چگونه سازمان شما برای دستیابی به هدف مطلوب عمل می‌کند و کمتر در مورد این است که نقشه چگونه تکامل می‌یابد. چارچوب واردلی‌مپینگ مجموعه ای از اصول دکترین مانند استفاده از یک زبان مشترک، استراتژی تکرار شونده و بهینه‌سازی جریان را ارائه می‌دهد. این اصول، به تمام جوانب مدل عملکردی شرکت اشاره دارند و در سراسر این نوشته‌ها مورد بررسی قرار می‌گیرند. دکترین یک جنبه‌ی اغلب نادیده گرفته شده از استراتژی است؛ بدون یک مدل عملیاتی موثر، حتی با یک استراتژی پیشرفته نیز موفقیت دشوار است.سرانجام، چرخه به بخش رهبری منتقل می‌شود. این بخش نمایانگر اقدامات استراتژیک واقعی و انتخابی است که کسب و کارها می‌توانند انجام دهند. اقداماتی مانند گسترش کار به بازارهای جدید یا توسعه‌ی توانمندی‌های جدید برای بهبود محصولات موجود و افزایش نفوذ بازار بخشی از این اقدامات است. یک نقشه‌ی واردلی با چشم اندازی را به تصویر می‌کشد و نیروهای اقلیمی نمایان می‌کند. این کار پایه‌ی گفتگوهای استراتژیک عمیق و تصمیم‌گیری‌های آگاهانه می‌شود. چندین الگوی بازی در اکوسیستم واردلی مپینگ وجود دارد، مانند بازی‌های بازار که در صورت امکان در آینده توضیح خواهیم داد.همانطور که از تصویر و نام آن مشاهده کردید، چرخه‌ی استراتژی از استعاره‌ی چرخه استفاده می‌کند تا بر ماهیت تکراری استراتژی تأکید کند. همانطور که شما یک پرونده‌ی نوسازی کسب‌وکار را ایجاد و با توجه به نوآوری معماری شروع به تحویل دادن می‌کنید، چشم‌انداز نیز همواره در حال تکامل خواهد بود، بنابراین باید به صورت منظم به تعیین استراتژی به کمک واردلی‌مپینگ ادامه دهید تا نوآوری را در مسیر بهینه نگه دارید. همانطور که سایمون واردلی تأکید می‌کند، حتی هدف کسب و کار شما ممکن است تغییر کند: "اقلیم ممکن است بر هدف شما تأثیر بگذارد، محیط ممکن است بر استراتژی شما تأثیر بگذارد، و اقدامات شما ممکن است بر همه چیز تأثیر بگذارد. هدف شما ثابت نیست، همانطور که چشم‌انداز تغییر می‌کند و شما عکس العمل نشان می‌دهید، هدف نیز تغییر می‌کند. هیچ هسته‌ی ثابتی وجود ندارد و همه چیز دائم در حال تغییر و انتقال است.3. ایجاد یک نقشه‌ی واردلیفرآیند ایجاد نقشه واردلی را می توان به شش مرحله اساسی تقسیم کرد که مراحل یک و دو در چرخه‌ی استراتژی یعنی هدف و چشم انداز را پوشش می‌دهد.تعیین اهداف نقشهتنظیم محدودهتشخیص کاربرانتعیین نیازمندی به ازای هر کاربرایجاد زنجیره‌ی ارزش به کمک کامپوننت‌هانگاشت کامپوننت‌ها در امتداد محور تکاملپس از ایجاد چندین نقشه‌ی واردلی، این فرایند برای شما روتین خواهد شد و نیازی به فکر کردن در مورد مراحل انجام کار نخواهید داشت. اما دانستن این مراحل در شروع آشنایی مفید خواهد بود. Ben Mosior یک طرح بصری عالی برای شروع به کار در Miro ایجاد کرده است که در این لینک می‌توانید آن را مشاهده کنید. در ادامه فرایند ایجاد یک نقشه‌ی واردلی را بررسی خواهیم کرد.در این مثال با استفاده از طرح اقای Ben Mosior برای یک شرکت تحویل غذای آنلاین یک نقشه‌ی واردلی ایجاد خواهیم کرد. در این مثال یک مدل تجاری برای بازاری چند جانبه را پیاده سازی می‌کنیم که همزمان رستوران‌ها و مشتریان را در کنار هم مدل می‌کند. بر این اساس، هدف آن‌ها شامل نیازهای هر دو گروه است یعنی: "ارتباط بین افراد گرسنه با تعداد زیادی از بهترین رستوران‌هایی که غذای بیرون بر ارائه می‌کنند" و "توانمندسازی همه رستوران‌ها برای ارائه یک سرویس غذای بیرون‌بر کارآمد". همانطور که در شکل نشان داده شده است، این جزئیات مستقیماً در اولین مرحله بوم وارد می شوند.مرحله‌ی اول از واردلی‌مپینگمرحله‌ی دوم بوم محدوده‌ی نقشه را تعیین می‌کند. نقشه‌ها می‌توانند در هر محدوده و سطحی باشند، از سطح کلان که کل یک کسب و کار را پوشش می دهد تا سطح خرد که یک محصول یا قابلیت فردی را پوشش می دهد. محدوده‌ی نقشه، ریزه‌کاری‌های اجزای ایجاد شده را تعیین می کند و نوع گفتگوهایی را که احتمالاً رخ می‌دهد را نیز شکل می دهد. در این مثال، همانطور که در تصویر بعد نشان داده شده است، محدوده به یک نمای کلی در سطح کلان تنظیم شده است. اگر در حال شروع یک سفر مدرنیزاسیون هستید و هنوز هیچ مرز یا اولویتی در مورد مکان تمرکز تعیین نکرده اید، این کار یک انتخاب معقول به نظر می‌رسد.مرحله‌ی دوم از واردلی‎‌مپینگدر مرحله‌ی کاربرانی که از آنچه در حال نقشه‌برداری است سود می‌برند را باید توصیف کرد. این کار می‌تواند شامل کاربرانی از داخل و خارج سازمان مانند مشتریان، کارمندان و شرکا باشد. در مثال تحویل غذا، سازمان دارای سه نوع کاربری گسترده در سطح کلان است: مشتریان، رستوران‌ها و پیک‌ها، که همانطور که در تصویر نشان داده شده است به قسمت سوم بوم اضافه شده‌اند.مرحله‌ی سوم از واردلی‎‌مپینگ بخش چهارم بوم، شامل مرتبط کردن نیازهای کاربری با هر کاربر است. تصویر بعد مشتریانی را نشان می دهد که می خواهند از غذاهایی عالی و بدون زحمت و در سر برای پخت و پز لذت ببرند، رستوران‌هایی که می خواهند کسب و کار خود را توسعه دهند و پیک‌هایی که می خواهند درآمد کسب کنند. این امکان وجود دارد که چندین نیاز مرتبط با یک کاربر باشد و برخی نیازها نیز ممکن است با چندین کاربر به اشتراک گذاشته شوند. همچنین می‌توان کاربران را به شکل جزئی‌تری تقسیم کرد، مثلا «مشتری عادی» و «مشتری گذری». هدف و دامنه‌ی نقشه در این انتخاب‌ها راه‌گشا خواهد بود.مرحله‌ی چهارم از واردلی‎‌مپینگ بعد از مرحله‌ی چهارم، خیلی چیز‌ها در مرحله‌ی پنجم جالب و پیچیده‌تر می‌شوند، که نیاز به ایجاد زنجیره‌های ارزش از کامپوننت‌ها دارد. در این مرحله، شایان ذکر است که تعریف دقیق «کامپوننت» می‌تواند حواس‌تان را پرت کند، بویژه اگر تکنیک‌های دیگری که از متا‌مدل‌هایی با تعریف دقیق دارند را قبلا مورد استفاده قرار داده باشید. پس از رفع نیازهای کاربر، چیزها یا قابلیت‌های مورد نیاز برای برآورده کردن نیازهای کاربر چیست؟ یک کامپوننت می‌تواند عملاً هر چیزی باشد که برای نقشه برداری مفید به نظر می رسد، مانند فعالیت‌ها، داده‌ها، شیوه‌ها و دانش. یکی از تله‌هایی که در این مرحله ممکن است در آن بیوفتید، غرق شدن در بحث‌های تکراری و بی‌پایان است. مثلا تلاش برای تعریف دقیق یک کامپوننت یا اینکه چیزی کامپوننت است یا خیر؟! بحث‌هایی از این دست می‌تواند به راحتی تبدیل به یک کار فرسایشی و بی‌فایده شود. بهتر است چیزی که برای نقشه‌ای که ایجاد می‌کنید مفیدتر است را انتخاب کنید و از این قبیل بحث‌ها اجتناب کنید.تصویر بعدی، اولین مراحل از ایجاد زنجیره‌ی ارزش در تحویل غذا را نشان می دهد که از دیدگاه مشتری و رستوران شروع می شود. مشتری از موبایل اپلیکیشن "مشتری" استفاده می‌کند در حالی که رستوران از برنامه‌ی تحت وب "مدیریت رستوران" برای مدیریت رستوران خود استفاده می‌کند و کارکنان آشپزخانه از برنامه‌ی "آشپزخانه" روی iPad استفاده می کنند. یکی از عملکردهای برنامه‌ی "مدیریت رستوران" ایجاد منو است در حالی که مشتری از برنامه تلفن همراه برای مشاهده‌ی منو استفاده می‌کند. بنابراین هر دو برنامه به مؤلفه‌ی منو وابستگی دارند. کارکنان آشپزخانه از برنامه‌ی iPad برای پردازش سفارش‌های دریافتی استفاده می‌کنند، در حالی که مشتریان با استفاده از برنامه تلفن همراه سفارش‌ها را ایجاد می‌کنند، بنابراین هر دو برنامه به کامپوننت Ordering وابستگی دارند. در پایین نمودار مولفه‌ی Cloud Platform قرار دارد. این شرکت از این پلتفرم داخلی برای ساخت و اجرای نرم‌افزار سمت سرور استفاده می‌کند، بنابراین تمام اجزایی که روی سرور اجرا می‌شوند به این مؤلفه وابستگی دارند.مرحله‌ی پنجم از واردلی‎‌مپینگ همانطور که تصویر مشاهده نمودید، محور عمودی با عنوان Visible در بالا و Invisible در پایین برچسب گذاری شده است. این نشان می‌دهد که موارد بالاتر برای کاربر بیشتر قابل مشاهده بوده در حالی که موارد پایین‌تر برای کاربر قابل مشاهده نیستند، کاربر ممکن است از وجود آن‌ها آگاه نباشد. در این مثال، مشتری برنامه‌ی موبایل "مشتری" را می بیند و با آن تعامل دارد، بنابراین برای کاربر بسیار قابل مشاهده است، اما مشتری چیزی از پلتفرم ابری شرکت نمی‌بیند.در نهایت، بخش ششم بوم جایی است که در واقع نقشه‌ی واردلی ایجاد می‌شود. زنجیره‌های ارزش از قسمت پنجم کپی می‌شوند و هر کامپوننت به یکی از چهار مرحله‌ی تکامل منتقل می‌شود: پیدایش (Genesis)، ساخت سفارشی (Custom Built)، محصول(Product) یا کالا (Commodity). مرحله‌ی پیدایش مفاهیم جدید و بدیعی را نشان می دهد که ممکن است پتانسیل اثبات نشده‌ی زیادی داشته باشند. در نقطه‌ی مقابل، کالا برای مفاهیمی است که در همه سازمان‌ها بسیار استاندارد شده است و فرصتی برای تمایز وجود ندارد.همانطور که در شکل بعد نشان داده شده است، پلتفرم ابری به عنوان یک کالا در نظر گرفته می شود زیرا یک مفهوم تثبیت شده مشابه رقبا است. برخی از بیت‌ها به صورت داخلی ساخته می‌شوند، اما بیشتر به یک ارائه دهنده‌ی خدمات ابری واگذار می‌شود.با این اجزا فرصت برای تمایز بسیار کم است. در همین حال، سفارش بیشتر به عنوان یک محصول در نظر گرفته می‌شود، زیرا هنوز هم اعتقاد بر این است که فرصتی برای متمایز شدن از رقبا در این قسمت وجود دارد، هرچند که این فرصت خیلی هم زیاد نیست. چهار مرحله‌ی تکامل با جزئیات بیشتر در بخش‌های بعدی پوشش داده خواهد شد.مرحله‌ی ششم از واردلی‌مپینگتصویر قبل تنها زنجیره‌های ارزش مشتری را نشان می‌دهد تا به برجسته کردن نمونه هایی از تکامل کمک کند. با این حال، در یک نقشه‌ی واقعی، می‌توانید چندین کاربر، نیازهای آن‌ها و زنجیره‌های ارزش مربوطه را نشان دهید.اکنون که نقشه‌ای را تهیه کرده‌اید، همه چیز جالب‌تر می‌شود. شما می توانید شروع به بحث در مورد الگوهایی کنید که برای شما برجسته است. من همیشه دوست دارم یک سوال تسهیل کننده بپرسم: "اگر تمام متن را از این نمودار حذف کنید، چه چیزی به شما می گوید؟". به عنوان مثال، تصویر بعد، یک نقشه‌ی Wardley را نشان می‌دهد که هیچ متنی در کنار مؤلفه‌ها وجود ندارد، اما هنوز می توانیم چند موضوع بالقوه را شناسایی کنیم که ممکن است ارزش بررسی بیشتر در آن‌ها را داشته باشد.اولاً، هیچ مؤلفه‌ای در Genesis یا Custom Built وجود ندارد. این یک علامت هشدار است که شرکت هیچ نوآوری در مسیر خود ندارد. ممکن است اینطور باشد، یا ممکن است به سادگی بر روی نقشه نشان داده نشده باشند، اما موضوعی واضح برای کاوش است و احتمالاً به کارگاه‌ها، جلسات و تکنیک‌های بیشتری برای تأیید نیاز دارد.ثانیاً، بسیاری از اجزاء، کالا هستند، اما شرکت از هیچ ابزاری استفاده نمی‌کند. علامت هشدار این است که شرکت منابع زیادی را برای ساختن چیزهایی سرمایه‌گذاری می‌کند که می‌توان آن‌ها را به راحتی خریداری کرد (البته، برای شناسایی این الگو نیاز به کمی دانش دقیق‌تر است، زیرا سازمان از ابزارهای آماده استفاده نمی‌کند، اما این شرایط هنوز منعکس کننده‌ی یک وضعیت واقعی است.).شناسایی موضوعات استراتژیک در یک نقشه‌ی واردلیهمانطور که می بینید، فقط با نگاهی به چشم‌انداز، می توانید شروع به دریافت ایده‌هایی در مورد جایی که ممکن است مدرن سازی بیشتر مورد نیاز باشد، یا جایی که می خواهید بزرگنمایی کنید و عمیق تر شوید، به دست آورید.4. جمع بندی:در این قسمت، در مورد واردلی‌مپینگ، کاربرد آن و نحوه و فرایند ایجاد یک نقشه‌ی واردلی صحبت کردیم. خوب است که کار را در همین جا متوقف کنید و به سراغ کسب و کاری که در آن هستید بروید و واردلی مپ آن را ایجاد کنید تا به این تکنیک مسلط شوید. در قسمت بعد بحث در مورد واردلی‌مپینگ را ادامه خواهیم داد. علیرضا ارومند علیرضا ارومند Tue, 26 Sep 2023 00:30:19 +0330 https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D9%BE%D9%86%D8%AC%D9%85-%DA%AF%D9%88%D8%B4-%D8%AF%D8%A7%D8%AF%D9%86-%D9%88-%D8%AF%D8%B1%DA%A9-%D8%B4%D8%B1%D8%A7%DB%8C%D8%B7-%D8%AC%D8%A7%D8%B1%DB%8C-%D9%88-%D9%86%D9%82%D8%B4%D9%87-%D8%A8%D8%B1%D8%AF%D8%A7%D8%B1%DB%8C-clzgadtc9wed 1. مقدمه:طبق گفته‌هایی که داشتیم میدانیم قرار است سفری را شروع کنیم. مدرن‌سازی معماری هم مثل هر سفر دیگری سرشار از هیجانات و دلهره‌های خاص خود است. مدرن‌سازی، افراد و فرایند‌های زیادی را تحت تأثیر قرار می‌دهد. از نظر فنی و اجتماعی نیز احتمالات نامتناهی برای شسکت خوردن در مدرن‌سازی وجود دارد. شاید فکر کنید باید چشم اندازی از آینده ایجاد کرده و در مورد اهمیتِ مدرن‌سازی و ایده‌های درخشانی که برای دستیابی به آن دارید برای افراد شرکت توضیح دهید و آن‎‌ها را برای این مسیر قانع کنید. اما پیشنهاد میکنم به جای اینکه کار را با صحبت کردن شروع کنید مسیر متفاوتی در پیش بگیرید و با گوش دادن به افراد کار را شروع کنید. با افراد در همه سطوح سازمان گفتگو کنید و سعی کنید بفهمید آن‌ها چه دغدغه‌هایی دارند و در حال تلاش برای دستیابی به چه اهدافی هستند و چه چالش‌هایی در مسیر مدرن‌سازی خواهید داشت.با گوش سپردن به افراد، ارزش‌های واقعی‌ای که مدرن‌سازی ایجاد خواهد کرد را خواهید یافت. در کنار این موضوع شما این فرصت را به دست می‌آورید که روابط خود را با افراد مختلف شکل دهید. با صحبت کردن با افراد و گوش سپردن به حرف‌های آن‌ها، نه تنها می‌توانید بهترین دستاورد‌های سازمانی را بیابید، بلکه همراهی و حمایت آن‌ها را نیز همراه خود خواهید داشت. در این فرایند شما نیاز به ارائه‌ی راه حل فوری ندارید و می‌توانید از این گفتگوها لذت برده و دانش خود را برای سفری که پیش رو دارید تقویت کنید.در این قسمت می‌خواهیم در مورد گوش دادن به افراد و تهیه مسیر و نقشه سفر با کمک دانشی که به دست می‌آوریم صحبت کنیم. رهبرانِ مدرن‌سازی در این مرحله، زمان‌هایی را صرف شرکت در جلسات خصوصی و گروهی با افرادِ مختلفِ سازمان می‌کنند. هدف این جلسات شناسایی فرصت‌های ارزشمندی است که برای مدرن‌سازی وجود دارد تا از این دانش، برای ایجاد چشم‌اندازی استفاده کنیم که بتوانیم با آن سازمان را برای سرمایه گذاری در حوزه‌ی مدرن‌سازی متقاعد کنیم. این جلسات ترکیبی از صحبت کردن، گوش فرا دادن و تسهیل‌گری برای افراد مختلف د رحوزه‌ی کسب و کار است. هنگامی که با افراد مختلف سازمان، از مدیرعامل گرفته تا مدیران ارشد و معماران نرم‌افزار و ... صحبت می‌کنید، دیدگاه‌های مختلفی از معماری و استراتژی‌ها و اولویت‌های هر کدام به دست می‌آورید.قبل از شروع به کار و تشکیل جلسات می‌خواهم تاکید کنم که کلید موفقیت در این مرحله گوش فرا دادن است. این فرصت ارزشمند را با درگیر شدن با اهداف دیگر از دست ندهید.2. چه کسانی را ملاقات کنیم؟شاید تا اینجا به این جمع بندی رسیده باشید که باید با همه‌ی افراد سازمان گفتگو کنید. اما برای این کار، صدها ساعت زمان نیاز دارید و این کار، هزینه‌ی زیادی در بر خواهد داشت و شاید خیلی هم بهره‌وری مناسبی نداشته باشد. پوشش گسترده و عمیق از افراد سازمان در گفتگو‌ها اهمیت زیادی دارد و شاید بخواهید بعد از برگزاری یک جلسه، تعدادی جلسه‌ی پیگری با موضوعات خاص و جزئیات بیشتر برنامه ریزی کنید. پس شاید بهتر باشد با گروه کوچکی در ابتدا جلساتی را برگزار کنید و از آنجا دریابید با چه افراد دیگری نیاز به برگزاری جلسه دارید و به چه جلسات تکمیلی‌ای در کدام قسمت‌ها نیاز دارید.آیا از قبل می دانید مدرن‌سازی معماریِ شما، به حوزه‌ی خاصی از کسب و کار محدود می شود یا کل سازمان را در برمی‌گیرد؟ قبل از اینکه تصمیم بگیرید چه کسی را باید در ابتدا ملاقات کنید باید به این سوال پاسخ داده باشید. شاید در ابتدا بخواهید در حوزه‌ای خاص متمرکز شوید. به عنوان مثال، آیا می خواهید قبل از درک چشم‌انداز فنی، سطح بالایی از وضوح در استراتژی کسب و کار داشته باشید؟ به عنوان یک پیش‌فرض معقول، خوب است در ابتدای راه جلساتی را با ترکیب متنوعی از ذینفعان کسب‌وکار و فناوری‌ ترتیب دهید. اما اگر نمی‌خواهید وقت خود را با صحبت کردن با افراد اشتباه هدر دهید، در ابتدای راه، شفاف سازیِ استراتژی عاقلانه‌ترین کار است. در هر صورت ممکن است زمان کافی برای گفتگوی مستقیم با همه افراد را نداشته باشید. در این شرایط پرسشنامه‌ها و نظرسنجی‌ها می توانند به کسب بینش از افرادی که فرصت گفتگو با آن‌ها را ندارید، کمک کنند. در برخی موارد می‌توان برای مدیریت زمان، جلسات را گروهی برگزار کرد. اما جلسه‌ی مشترک ممکن است روی داده‌هایی که شرکت کننده‌ها به اشتراک میگذارند تاثیر گذار باشد.اگر برای اولین گروه از افرادی که قصد ملاقاتشان را دارید،با مشکل مواجه شده‌اید، به دسته بندی‌های زیر مراجعه کنید و حداقل یک نقش را از هر یک از دسته های زیر انتخاب کنید. به طور ایده‌آل با ترکیبی از رهبران و سایر کارکنان جلسات یک ساعته ترتیب دهید. برای انجام و به ثمر رساندن این کار، به 10 الی 15 ساعت زمان در طول دو تا سه هفته زمان نیاز دارید.گروه اول مدیران ارشد مثل مدیر ارشد اجرایی، مدیر ارشد عملیاتی، مدیر ارشد بازرگانی، مدیر ارشد مالی و ...گروه دوم مدیران و معاونان لایه دوگروه سوم همکاران واحد فروش و بازاریابیگروه چهارم همکاران واحد محصولگروه پنجم همکاران واحد فنی و مهندسیگروه ششم همکاران زیرساختگروه هفتم همکاران واحد استقرارگروه هشتم همکاران واحد دادهگروه نهم همکاران واحد پشتیبانی3. چه کسی جلسات را برگزار و هدایت می‌کند؟جنبه دیگری از تورهای شنیداری که باید در نظر گرفته شود، افرادی است که تور را برگزار می کنند. این سوال می تواند نماینده‌ای برای یک سوال استراتژیک‌تر باشد: گروهی از افرادی که ابتکار نوسازی را رهبری می کنند چه کسانی خواهند بود؟ یک رویکرد این است که تیمِ توانمندسازیِ مدرن‌سازیِ معماری (AMET) مسئولیت این کار را به عهده بگیرد. این تیم متشکل از افرادی است که مسئول شروع یک فرایند مدرن‌سازی و حفظ شتاب مناسب در طول زمانی است که این فرایند به ثمر می‌رسد. با اجرای جلساتِ شنیداری، این گروه قادر خواهد بود تا نوسازی را در مسیر درست هدایت کند. تیم AMET می‌تواند شامل هر کسی باشد که به خوبی برای رهبری و هدایت یک کار نوسازی مجهز است. معمولاً، خوب است که ترکیبی از افراد با پیشینه‌ی فنی و محصول داشته باشید، و خوب است که متخصصان خارجی را نیز شامل شود. AMET همچنین آزاد است تا در صورت لزوم دیگران را در تور شنیداری شرکت دهد. در قسمت‌های آینده در مورد موضوعاتی مانند نحوه تشکیل یک AMET و طیف کاملی از مسئولیت‌هایی که تیم باید داشته باشد مطالبی را بیان خواهیم کرد.پس از تشکیل گروهی که مسئول برگزاری جلسات هستند، گروه باید برای انجام ماموریت خود، سازماندهی شود. در صورتی که گروه کوچکی تشکیل شده باشد، مثلا یک گروه سه نفره، احتمالا همه‌ی اعضای گروه می‎‌توانند در هر جلسه‌ای شرکت کرده و به حرف سایرین گوش فرا دهند. اما اگر گروهی که تشکیل شده اعضای بیشتری داشته باشد، احتمالا خود به زیرگروه‌هایی تقسیم می‌شود. در چنین شرایطی بسیار مهم است که زیرگروه‌ها خیلی خوب با هم همکاری کرده و بینش‌هایی که حاصل جلسات متفاوت است به درستی جمع آوری کرده و به اشتراک بگذارند.برای سادگی در به اشتراک‌گذاری و جلوگیری از فراموش شدن مطالب ممکن است تصمیم بگیرید جلسات را ظبط کنید. اگر تصمیم به ظبط جلسات گرفتید به این نکته دقت کنید که در این شرایط ممکن است مطالبی که افراد با شما به اشتراک می‌گذارند تحت تاثیر قرار بگیرد و بعضا شفافیت مورد نیاز در جلسات برقرار نشود. بنابراین پیشنهاد میکنم به جای تمرکز روی نگهداری دقیق مطالب بیان شده، ابتدا سعی کنید محیطی امن برای بیان دغدغه‌ها و بینش‌ها ایجاد کنید.4. برگزاری جلسات موثر:ممکن است تصور کنید برگزاری جلسه برای شنیدن، کاری ساده است. شاید فکر کنید این فقط یک گپ و گفت ساده است. با این حال، من دیده‌ام که چگونه شرکت‌های بزرگ برای برگزاری این جلسات تقلا می‌کنند. پرسیدن سوالات درست به روش صحیح، هدایت مکالمات در جهت مفید، و جابجایی راحت بین گفتگوهای استراتژی سطح بالا با مدیر عامل، گفتگوهای مالی با مدیران مالی، و بررسیِ عمیق فنی با یک مهندس ارشد نیاز به دانش و تمرین زیادی دارد. در این قسمت عوامل مهمی را که به شما کمک می‌کند تا جلسات مؤثری داشته باشید، پوشش داده می‌شود و شما را راهنمایی می‌کند که یک طرح توجیهی با کیفیت برای مدرن‌سازی معماری ایجاد کنید.4.1. فضای امن ایجاد کنید:فیلم Office Space در سال 1999 تولید شد. در آن فیلم، تیم رهبریِ Initech، مشاورانی را برای بهبود بهره‌وری و کوچک کردن شرکت استخدام کردند. مشاوران از یک اتاق جلسه در دفتر برای مصاحبه با هر یک از کارکنان به صورت جداگانه استفاده می کنند. اگر به جای کارمندان شرکت باشید فضای ترسناکی است. دو مشاور خشن در یک طرف میز نشته و سوالاتی را از کارمندانی می‌پرسند که با استرسِ اخراج دست و پنجه نرم می‌کنند. همانطور که احتمالاً حدس زده اید، این محیطی نیست که می خواهید در طول جلسات ایجاد کنید. شما می خواهید آنچه را که مردم واقعاً معتقد هستند که تاثیرگذارترین فرصت‌های استراتژیک یا بزرگترین موانع هستند را کشف کنید و برای رسیدن به این هدف باید فضایی امن ایجاد کنید.در این فیلم، عدم تعادل در قدرت وجود داشت. در یک سمت میز دو نفر مشاور خشن حضور داشتند و در طرف دیگر کارمندی که اجبارا در جلسه حاضر شده بود. احتمال اینکه جلسات شما نیز چنین ویژگی‌هایی داشته باشد وجود دارد. ممکن است محیطی که ایجاد می‌کنید آرامش افراد را زیر سوال ببرد و هدف اصلی شما نادیده گرفته شده و افراد در جلسات نگران از دست دادن موقعیت‌های شغلی خود باشند. همیشه هنگام گفتگو سعی میکنم فضای چالش برانگیز این فیلم را در نظر داشته باشم و سعی کنم با زبان نرم و روالی دوستانه افراد را به گفتگو دعوت کنم و از هر ابزاری برای آب شدن یخ جلسه و ایجاد حس اعتماد استفاده کنم. محل برگزاری جلسه نیز روی برداشت افراد تاثیرگذار است. شما می‌توانید جلسات را در اتاقی در شرکت برگزار کنید یا در یک کافی شاپ در حالی که موسیقی ملایمی پخش می‌شود و یا حتی فضای سبزی در نزدیکی شرکت. زمان برگزاری جلسه نیز موضوع دیگری است که باید درباره آن دقت کنید. یادم هست یک بار با فردی بعد از یک جلسه پرفشار جلسه برگزار کردم، از نظر روحی اصلا آمادگی این جلسه را نداشت و متاسفانه بعضا صحبت‌هایی رد و بدل شد که نمی‌بایست در جلسه گفته می‌شد. اگر در چنین شرایطی قرار گرفتید بهترین کار این است که یا در مورد مسائل کم حاشیه صحبت کنید یا جلسه را برای زمان دیگری برنامه‌ریزی کنید. به یاد داشته باشید که هدف این است که شرایطی ایجاد کنیم که افراد بتوانند در محیطی امن آن چیزی که به آن معتقد هستند و می‌دانند را با ما به اشتراک بگذارند. اگر تعداد زیادی شرکت کننده در جلسه حاضر باشند، فضای اعتماد دیرتر شکل می‌گیرد، باید صبور باشید و فرصت کافی ایجاد کنید تا اعتماد رفته رفته شکل بگیرد. این نکته زمانی حائز اهمیت می‌شود که شما به عنوان فردی بیرونی به شرکتی وارد می‌شوید.اگر همکاران در شرکت ایمیلی دریافت کنند که آن‌ها را ملزم به شرکت در مصاحبه‌هایی کند، احساسی شبیه به پرسنل Initech خواهند داشت. در چنین شرایطی گفتگوهای غیر رسمی و اطلاع رسانی از طریق تماس تلفنی یا پیامک کاراتر خواهد بود. در ابتدای جلسه نیز بهتر است شرحی از اهدافی که دارید و مسیری که می‌خواهید طی کنید به حاضرین در جلسه بدهید و کاری کنید که اطمینان حاصل کنند اگر داده حساسی به شما بدهند، مانند رازی پیش شما حفظ خواهد شد. همچنین تکرار این نکته مفید است که در این مرحله ما راه‌حل‌های از پیش تعیین شده در ذهن نداریم و ایده‌هایی را مطرح نمی‌کنیم، باید صادقانه بیان کنیم که واقعاً فقط می‌خواهیم گوش کنیم.در نهایت هم به کلمه معماری حساس باشید. معمولا افراد برداشت‌های متفاوتی از کلمه معماری دارند و در صورتی که با این کلمه مواجه شوند ممکن است اطلاعاتی که به شما می‌دهند متناسب با تعریف آن‌ها از معماری باشد. بنابراین، در این مرحله، ممکن است بخواهید این ابتکار را کمی مبهم‌تر بدون استفاده از کلمه معماری، اما به اندازه کافی واضح که اهمیت آن را درک کنند، توصیف کنید.بنابراین، در این مرحله، بهتر است خیلی واضح در مورد معماری گفتگو نکنید و عملکرد خود را کمی مبهم‌تر بدون استفاده از کلمه معماری، اما به اندازه کافی واضح که اهمیت آن را درک کنند، توصیف کنید.4.2. برای هر کاری ابزار مناسبی اختیار کنید:از تکنیک‌های مختلفی برای به دست آوردن بینش در طول جلسات می‌توان بهره برد. برخی از تکنیک‌ها می‌توانند برای عمیق‌تر کردن بینش در موضوعات خاص مفید باشند، در حالی که برخی کمک می‌کنند تصویر بزرگی از کل فرایند بدست آید. مزیت بزرگی که بسیاری از تکنیک‌ها دارند این است که می‌توانید مفاهیمی را که در طول مکالمه ظاهر می‌شوند، تجسم کنید و ببینید چگونه آنها را به هم متصل می‌کنند. تکنیک‌ها و ابزارهایی مثل Impact Mapping، بوم کسب و کار، نمودار‌های C4 و Risk Storming و ... همگی در اختیار شما هستند و می‌توانید از آن‌ها بهره‌مند شوید. اگر با این ابزارها آشنایی ندارید نگران نباشید. در قسمت‌های آینده در مورد ابزارها و تکنیک‌هایی که بسیار پر کاربرد هستند گفتگو خواهیم کرد. 4.3. گفتگوهای ساختارمند و بدون ساختار:جلساتی که برگزار می‌کنید ممکن است کاملا آزادانه برگزار شوند یا حتی در سطح دقیقه ساختار و برنامه‌ریزی داشته باشند. جلسات بدون ساختار و قاعده از این جهت خوب هستند که گفتمان به هر جهتی می‌تواند برود. هر زمانی موضوع مهمی یافت شود گفتگو به همان طرف می‌رود. با هدفی که پیش‌تر گفتیم شاید به نظر برسد گزینه اصلی جلسات بدون ساختار است. دقت کنید هرچند در دیدگاه اول ساختار نداشتن کمک کننده است، اما اگر شرکت کننده‌ها در جلسات احساس پوچی داشته باشند و جلسات بی‌هدف پیش برود کار سختی برای جلب اعتماد مجدد خواهیم داشت. برای ارتباط موثر باید زبان مشترک داشته باشیم و نداشتن زبان مشترک دلهره‌آور است. خیلی وقت‌ها وحشت‌زده بودم و با خودم فکر می‌کردم: «چه بگویم؟ من نمی دانم چه بگویم. اگر حرف احمقانه ای بزنم چه؟». ممکن است وسوسه شوید که سوالاتی مانند "سه اولویت اصلی شما برای امسال چیست؟" بپرسید. اما چنین سوالاتی حس اصالت را القا نمی‌کند و شرکت کنندگان حس میکنند از روی اجبار صرفا حرفی زده شده. مثل جلسات خاستگاری که عروس و داماد در مورد آب و هوا صحبت می‌کنند و هر دو می‌دانند از این گفتگو دستاوردی ندارند.اگر مکالمه‌های بدون ساختار احساس امنیت القا نمی‌کند، مکالمات ساختاریافته مناسب تر هستند. می توانید با لیستی از سوالات شروع کنید و سپس به مکالمات بدون ساختار بیشتری بروید که در آن احساس راحتی کنید. در مکالمات ساختاریافته، می توانید سوالات اختصاصی برای هر فرد ایجاد کرده و یا مجموعه‌ای استاندار از سوالات را برای همه مصاحبه‌ها استفاده کنید. زمانی که گروهی از افراد در جلسات شرکت می‌کنند و می‌خواهید مقداری ثبات و توانایی مقایسه‌ی پاسخ‌ها در مکالمات مختلف را داشته باشید،مجموعه استاندارد سوال می‌تواند مفید باشد. همانطور که ذکر شد، با این حال، جلسات ساختاریافته می توانند مکالمه و انواع بینش‌هایی را که ظاهر می شوند را محدود کنند.در جلسات می‌خواهیم از افراد بپرسیم چه کاری می‎‌کنند؟ برای رسیدن به چه هدفی تلاش می‌کنند؟ برای رسیدن به این هدف با کارهایی که می‌کنند با چه موانعی رو برو هستند؟ این سوالات به طرق مختلفی قابلیت پرسیدن دارند. لیست زیر نمونه ای از انواع سوالاتی را ارائه می دهد که به صورت فی البداهه در جلسات بدون ساختار پرسیده شود یا به عنوان بخشی از قالب استاندارد در جلسات ساختاریافته بپرسید.اولویت‌های اصلی شما در نقشه راه برای یک یا سه یا پنج سال آینده چیست؟یک سال خوب برای شما چگونه است؟چگونه می فهمید که سال خوبی را پشت سر گذاشته اید؟اگر به اهداف اصلی خود نرسید چه اتفاقی می افتد؟به نظر شما بزرگترین تهدید در راه دستیابی به اهدافتان چیست؟نظر شما در مورد سطح نوآوری در شرکت چیست؟چقدر از سرعت ارائه نوآوری های جدید راضی هستید؟این شرکت چقدر از فناوری استفاده می کند و آیا فرصت‌هایی برای استفاده بیشتر از آن می‌بینید؟آیا می‌توانید درباره ابزارهایی که شما یا تیمتان برای انجام کارتان استفاده می‌کنید به من بگویید؟دوست دارید برای چه کاری وقت بیشتری در شغل خود داشته باشید؟چه تغییراتی به شما کمک می کند تا در محل کار شادتر باشید؟آیا چیزی مربوط به کار شما را در شب بیدار نگه می دارد؟آیا چیزهایی وجود دارد که زمان زیادی از شما یا تیمتان را می‌گیرد و دوست دارید از آن‌ها اجتناب شود؟شما یا تیمتان روز کاری خود را در یک دنیای ایده آل چگونه می‌گذرانید؟چقدر احساس می کنید که افراد در سراسر این شرکت روی اهداف استراتژیک همسو هستند؟اگر از یک توسعه‌دهنده نرم‌افزار سطح متوسط بخواهم اهداف استراتژیک را شرح دهد، آیا پاسخ آنها با شما مطابقت دارد؟تاثیر بدهی‌های قدیمی بر این شرکت را چگونه توصیف می کنید؟اگر بتوانید سه چیز را در مورد شرکت تغییر دهید، چه چیزهایی خواهد بود؟علاوه بر این سؤالات، می‌توانید سؤالاتی منحصر به فرد بپرسید و به محصولات، سیستم‌ها یا روش‌های کاری خاص نیز اشاره کنید. به عنوان مثال "ما اخیراً رویکرد خود را از تیم های پروژه محور به تیم های محصول محور تغییر داده‌ایم. تجربه شما تا الان چگونه است؟». با پرسیدن سوالات، به خصوص این نوع از سوالات، به راحتی می توان سوالات هدفمند‌تری مثل "معماری برای دستیابی به اهداف تجاری شما چقدر مهم است؟" را نیز پرسید.4.4. سوالات را در ساختارهای متنوع بپرسید:رهبران‌فناوری که پیشینه‌ای در زمینه تسهیلگری یا مربیگری ندارند، معمولاً سؤالات نسبتاً مستقیم و با تنوع کم و در قالب‌های محدود می پرسند. یادگیری سؤال پرسیدن با استفاده از ساختارهای مختلف می تواند به مکالمات جذاب‌تری منجر شود و شرایطی را برای ظهور بینش‌های جالب‌تر ایجاد کند.برای مثال یک سوال ساده برای پرسیدن این است که "بزرگترین مشکلی که در حال حاضر دارید چیست؟". این سؤال بدی نیست، اما نسبتاً مستقیم است و مردم انتظار آن را خواهند داشت، بنابراین ممکن است بدون تشویق به تأمل عمیق‌تر، پاسخ سریعی بدهند. حال سوالی با این رویکرد را در نظر بگیرید:"چیزیکه در مورد کار من حال حاضر باعث عصبانیت من می شود، ___________ است". هنگام پاسخ به این سوال، افراد این جمله را دائما با خود تکرار می‌کنند و ممکن است این تکرار موجب افکار عمیق‌تری شود و پاسخ‌های متفاوت‌تری را حاصل کند. در زیر انواع مختلفی از فرمت‌های سوال وجود دارد که ارزش یادگیری و کاربرد در سناریوهای شفاهی و نوشتاری و جلسات متفاوت را دارند:جمله را کامل کنید: همانطور که در بالا توضیح داده شد، این قالب کمک می کند تا پاسخ متفاوتی نسبت به سؤالات مستقیم به دست آورید و به طور بالقوه موجب ظهور و بروزِ احساسات مختلف و تأمل عمیق تر می‌شود.احساس خود را انتخاب کنید: این نوع سوالات افراد را وادار می کند تا به چرخه‌ی عاطفه/احساس نگاه کنند و احساسی را انتخاب کنند که به بهترین وجه حس آن‌ها را در مورد یک موضوع خاص توصیف کند. به عنوان مثال، «وقتی به سرعت پیاده‌سازی ویژگی‌های جدید فکر می‌کنید، کدام احساس بر روی چرخ عواطف برای شما برجسته می‌شود؟»یک تصویر انتخاب کنید: یک راه عالی برای تشویق به تفکر جدید و تأمل عمیق‌تر این است که به مردم مجموعه‌ای از تصاویر را نشان دهید و از آن‌ها بخواهید تصویری را انتخاب کنند که منعکس کننده احساسات آنها در مورد یک موضوع خاص باشد. یک مثال واقعی که من استفاده کرده‌ام این است: «تصویری را انتخاب کنید که نشان دهد در محیط کاری فعلی چقدر خلاق هستید؟». وقتی برای اولین بار این کار را انجام می‌دهید، برای مثبت بودن آماده باشید. این یک تکنیک شگفت انگیز است. Ethnographica Deck که توسط Jennifer Mahony ایجاد شده مجموعه‌ای عالی از تصاویر است. شما به سادگی آن‌ها را در اختیار افراد قرار می‌دهید تا بتوانند به راحتی همه تصاویر را ببینند و بین آن‌ها حرکت کرده و واقعاً فضایی برای ارتباط با یک (یا چند مورد) داشته باشند.بدترین حالت ممکن: این نوع سوالات با تشویق افراد به حرکت در جهت کاملاً مخالف آنچه انتظار می رود، فضایی را برای تفکر بسیار خلاق ایجاد می کنند. تصور کنید برای پاسخ دادن به این سوال تشویق می شوید: "بدترین فرصت تجاری ممکن که این سازمان می تواند به آن دست یابد چیست؟" این یک مجوز واقعی برای متفاوت اندیشیدن است. بدترین سؤالات ممکن چندین هدف را دنبال می کنند، مانند برجسته کردن جایی که سازمان واقعاً بدترین کار ممکن را انجام می دهد و شناسایی ایده های دیوانه کننده ای که در واقع می توانند به چیزی با پتانسیل اصلاح شوند.فقط برای سرگرمی: این نوع سؤال بیشتر در مورد ایجاد حس سرگرمی در فرآیند است، که می تواند به افراد کمک کند تا ذهن آرام و خلاقانه‌تری داشته باشند و پاسخ‌های عمیق‌تری را به سؤالات مهم‌تری که در ادامه می آیند بدهند. به عنوان مثال: "(فقط برای سرگرمی) اگر می توانستید هر فرد مشهوری را استخدام کنید تا در مدرن‌سازی به ما کمک کند، چه کسی را استخدام می‌کردید و چرا؟" بدیهی است که دقت در این نوع سوالات مهم است. برخی از سازمان‌ها اهمیت سرگرمی را در کارها درک نمی‌کنند، و گاهی ممکن است مردم فکر کنند شما کارها را جدی نمی‌گیرید. با این حال، نگران نشوید. این موارد را به در برخی شرایط امتحان کنید و ببینید چه نوع پاسخی دریافت می کنید.مدافع شیطان: این سوالات بهانه‌ای است برای به چالش کشیدن باورهای مردم به روشی سازنده. به عنوان مثال، اگر کسی معتقد است سرمایه‌گذاری در محصولات جدید کلیدی است، می‌توانید سؤالی مانند "بنابراین شما 100٪ متقاعد شده‌اید که کاهش هزینه‌های عملیاتی تمرکز اشتباهی است و هیچ چیز نظر شما را تغییر نمی‌دهد؟" بپرسید. این سؤالات باید به طرز ماهرانه‌ای پرسیده شوند، و باید روشن شود که هدف اکتشاف است، نه به چالش کشیدن یا توهین به مخاطب.برخی تصور می‌کنند استفاده از فرمت‌های مختلف سوال حقه‌بازی است. من نیز قبلاً بر این عقیده بودم اما به مرور زمان ارزش آن را درک کردم. کار کردن در کنار افرادی که از این تکنیک‌ها استفاده می‌کنند باعث شد تا بفهمم که وقتی عاقلانه به کار می‌روند چقدر موثر هستند. احتمالاً با افرادی روبرو خواهید شد که مایل به مشارکت نیستند، اما اکثر مردم تمایل به تلاش و تست کردن دارند.4.5. از پرسشنامه استفاده کنید:پرسشنامه و نظرسنجی‌ها ابزارهایی عالی برای بسیاری از جنبه‌های مدرن‌سازی از جمله جلسات دریافت اطلاعات هستند. شما می‌توانید از این ابزار هر زمانی استفاده کنید. قبل از جلسات، بعد از جلسات یا حین برگزاری یک جلسه می‌توانید از این ابزار استفاده کنید. در فرایند برگزاری جلسات شناخت، پرسشنامه یا نظرسنجی اولیه می‌تواند برای افراد زیادی ارسال شود. از نتایج نظرسنجی می‌توان برای شناسایی افراد کلیدی برای شرکت در جلسات و موضوعات و گرایش‌های کلیدی برای بحث در طول جلسات استفاده کرد. همچنین از نظرسنجی می‌توان برای رفع مشکل نداشتن زمان کافی برای صحبت کردن با همه افراد به صورت جداگانه استفاده کرد.هنگام گردآوری پرسشنامه در جریان برگزاری جلسات شناخت، چند موضوع وجود دارد که باید به آنها اشاره کرد. مشکلات و فرصت‌ها کاندیدای اصلی در پرسشنامه هستند، اما اگر از افراد در مورد میزان علاقه و مشارکت مطلوب آن‌ها در این فرآیند نیز بپرسید مطلوب خواهد بود، مانند "چقدر دوست دارید در طراحی و اجرای کارگاه‌هایی برای بررسی این موضوعات مشارکت داشته باشید؟" و همیشه خوب است که در مورد این فرآیند بازخورد بپرسید، مانند "چه چیزی در مورد جلسات شناخت تا کنون برای شما جالب بوده است؟". در حالی که مشغول کار خود هستید مراقب باشید افراد را با پرسشنامه‌های زیاد و مکرر اسپم نکنید.4.6. تشویق و همکاری در بروز ناشناخته‌ها :هنگامی که در حال برنامه ریزی برای جلسات شناخت هستید، به این موضوع دقت کنید که ممکن است همه افراد در مورد اولویت‌ها و چالش‌ها به وضوح آگاه نباشند. افراد ممکن است آنقدر روی یک پروژه و بخش خاص متمرکز شده باشند که، زمانی را صرف توجه و تمرکز روی تصویر بزرگ سازمان یا فکر کردن در مورد اولویت‌های بالقوه دیگر نکرده باشند.شما نباید صرفا رو آنچه در جلسات می‌گویند تمرکز کرده و گفته‌های اولیه آن‌ها را به عنوان افکار نهایی و جامع آنها در مورد موضوعات مورد بحث در نظر بگیرید. شما باید با فکر کردن به احتمالات جایگزین و پرسیدن سوالاتی از نوع مدافع شیطان، آنها را به چالش بکشید، مانند "اگر قرار بود یک سال دیگر دوباره ملاقات کنیم، چقدر مطمئن هستید که ما همچنان در مورد این موضوع به عنوان اولویت استراتژیک اصلی صحبت خواهیم کرد؟" یا «آیا واقعاً احساس می‌کنید که امکان وقوع <سناریوی دیگر> کاملاً غیرممکن است؟»خودتان را جای افرادی بگذارید که با آن‌ها در جلسه صحبت می‌کنید. درک کنید که آن‌ها در حال تلاش برای درک احساس خود هستند و ممکن است در مورد چیزی که می‌گویند مطمئن نباشند. به افراد فشار زیادی نیاورید و به آن‌ها فضا بدهید تا از حالت تدافعی خارج شوند. از سوی دیگر، وقتی کسی به نظرات خود اطمینان دارد، شاید بهتر باشد که او را به سختی تحت فشار قرار دهید تا به او کمک کنید تا آن واقعیت‌هایی را خارج از محدوده شناختی فعلی خود درک کند. شاید در چنین شرایطی، تغییرات فوری اتفاق ندهد اما شک و تردیدی در دل افراد ایجاد می‌شود که با گذشت زمان به تغییر عقیده خواهد انجامید.دقت کنید که وظیفه شما این است که افراد را راهنمای و کمک کنید تا در مورد موضوعات مختلف به درستی فکر کنند، نه اینکه فقط افکاری که از پیش در ذهن آن‌ها است را از سرشان بیرون بکشید. همیشه این موضوع را در ذهن داشته باشید و در مورد نوع سؤالاتی که می‌پرسید فکر کنید. اگر مصاحبه‌ای را با افرادی انجام می‌دهید، حتماً بازخورد آن‌ها را بخواهید و آنها را تشویق کنید که وارد عمل شوند و در صورت لزوم گفتگو را در جهت دیگری هدایت کنند.4.7. عمیق شوید:بررسی موضوعات در سطح کلان و جابجایی بین موضوعات مختلف در آن سطح ساده است، اما تمرکز روی یک موضوع خاص و توجه به جزئیات نیز بعضا ضروری و مفید است. هنگامی که نمی‌دانید چگونه به صورت طبیعی جریان جلسه را هدایت کنید، رویکرد 5 چرا می‌تواند به شما کمک کند. روش کار همانطور که از نام آن پیداست، ساده است و کافیست پنج بار با "چرا" سوال بپرسید. برای مثال فرض کنید این موضوع مطرح شده است که: «بیشتر وقت من در فرایند آنبوردینگ افراد جدید سپری می‌شود و اینکار برای من بسیار زمانگیر است»، پرسیدن «چرا» ممکن است نشان دهد «زیرا باید به آنها یاد دهم چگونه از سه ابزار داخلی استفاده کنند که استفاده از آن‌ها دشوار است». پرسیدن دوباره «چرا» ممکن است نشان دهد که «توسعه‌دهندگان رابط‌های کاربری را ساخته‌اند» و «چرا» دیگر می‌تواند نشان دهد که «در این شرکت، توسعه‌دهندگان همیشه رابط کاربری را برای ابزارهای داخلی می‌سازند، زیرا ابزارهای داخلی به اندازه کافی برای متخصصان UX مهم تلقی نمی‌شوند.»مشاهده می‌کنید که پرسیدن چرایی پنج بار می تواند به بینش‌ها و روندهای عمیق‌تری منجر شود که بسیار مرتبط با مدرن‌سازی هستند. به این نکته دقت کنید که در صورتی که دائما فردی را با "چرا" بمباران کنید ممکن است احساس خوبی نداشته باشد، پس شاید بد نباشد در برخی موارد به فرد مصاحبه شونده گوشزد کنید که قصد دارید از این تکنیک استفاده کنید.4.8. دستیاری برای نوشتن داشته باشید:در طول سالیانی که مشغول کار مشاوره و همراهی در جریان بهبود معماری بوده ام، به وضوح برای من به اثبات رسیده که بهتر است جلسات گفتگو را با دو مجری برگزار کنم. در حالی که یکی از ما در حال پرسیدن سوال است، دیگری می تواند یادداشت برداری کند. این کار، اجازه می‌دهد تا بهره وری را در زمان محدودی که داریم به حداکثر رسانده و از تلاش یک تسهیلگر برای صحبت و نوشتن به صورت همزمان و آسیب هایی که همزمانی انجام وظایف دارد جلوگیری می‌کند. یکی از تکنیک‌هایی که می تواند به مکالمات عالی منجر شود، مرور یادداشت‌ها در طول جلسه است. هنگام بازی در نقش دستیار، من از تبلت خودم استفاده می‌کنم و در بازه‌های زمانی یادداشت‌ها را برای بصری سازی و در اختیار سایرین قرار دادن به Miro منتقل می کنم. از برچسب‌های Miro استفاده می‌کنم و ارتباطی بین برچسب‌ها نیز برقرار می‌کنم. برای دسته بندی موضوعات برچسب‌ها را رنگبندی میکنم و به کمک این رنگ‌بندی مطالبی برجسته نیز می‌شود. مثلا از رنگ های مختلف برای مفاهیم مختلف مثل معیارهای تجاری، فرصت‌ها و مشکلات و ... استفاده می کنم.تصویر زیر احتمالا چیزی است که باید در جلسات به آن برسید. همانطور که می بینید برچسب و ساختار تابلو بسیار نامرتب است، اگر نمودار‌های شما نیز نامرتب به نظر می‌رسند، نگران نباشید، طبیعی است.مستندسازی گفتگو4.9. برای تایید تکرار کنید:در طول فراید شناخت و به دست آوردن بینش، با افرادی ملاقات خواهید کرد که مشاغل و وظایف مختلفی دارند و در حوزه‌های مختلف با فرآیندهای متفاوت کار می‌کنند. غرق شدن در دنیای آن‌ها و درک مفاهیمی که آن‌ها بیان می کنند زمان زیادی نیاز دارد. شما همه‌ی چیزهایی را که آن‌ها می‌گویند را به طور کامل و خیلی سریع متوجه نخواهید شد. البته نیازی هم ندارید که سریع و کامل همه چیز را متوجه شوید. اما اگر بتوانید بیشترین اطلاعاتی را که آن‌ها به اشتراک می گذارند درک و جذب کنید، قطعاً مزیت بزرگی به دست آورده اید. یکی از راه‌های انجام این کار این است که، آنچه را که فهمیده‌اید تکرار کنید و از آن‌ها بخواهید که تأیید کنند. در برخی مواقع شما دچار سوء تفاهم می شوید و تکرار کردن به آن‌ها فرصت می دهد تا شما را اصلاح کنند.وقتی در نقش نویسنده در جلسات شرکت می‌کنم و مجری اصلی من را به گفتگو دعوت می‌کند تا سوالات خودم را بپرسم، صفحه نمایش خودم همه آنچه را که در Miro ثبت کرده‌ام به اشتراک می‌گذارم و سوالات خودم را می‌پرسم. وقتی ذهنیت و دریافت‌های من در قالب Miro با سایرین به اشتراک گذاشته شده و همزمان سوال هم می‌پرسم معمولا گفتگو به سمت جالبی سوق پیدا می‌کند. در بسیاری موارد مصاحبه‎‌شونده تمایل پیدا می‌کند که به عقب بازگشته و مطالبی را مجددا با جزئیات بیشتری توضیح دهد. این رفتار دلایل متعددی می‌تواند داشته باشد. مثلا مصاحبه شونده متوجه می‎‌شود نکته‌ای کلیدی را از قلم انداخته یا ممکن است خطایی در بخشی از یادداشت یافته باشد. شما نیز در صورت لزوم می‌توانید از این تکنیک یا هر تکنیک دیگری برای ترقیب مصاحبه شونده به بررسی و تایید نکاتی که متوجه شده‌اید استفاده کنید.5. دور هم جمع کردن گروه‌ها:هنگامی‌که فرایند برگزاری جلسات را شروع می‌کنید ممکن است با موضوعات مختلفی از طرف گروه‌های متفاوت در سازمان مواجه شوید که هر کدام برای عده‌ای از افراد جذاب است. اما هنگامی که قصد دارید طرح توجیحی برای مدرن‌سازی معماری ایجاد کنید باید به اولویت بندی این موضوعات توجه ویژه‌ای داشته باشید. یک راهکاری که برای این کار دارید این است که افرادی را که به صورت انفرادی با آن‌ها جلسه برگزار کرده‌اید، در جلساتی دور هم جمع کنید و از آن‌ها بخواهید در مورد موضوعاتی که از جلسات انفرادی ناشی شده است گفتگو کنند. اینکه چند نفر را بتوانید دور هم در یک جلسه جمع کنید مهم است. اگر توانایی این را داشته باشید جلسه‌ای با حضور همه افراد برگزار کرده و تسهیل‌گری کنید تا همه به خوبی در آن مشارکت کنند، طرح توجیحی که ایجاد می‌کنید اولویت‌های بهتر و دقیق‌تری را در بر خواهد داشت. شما باید با روش‌ها و تکنیک‌های مختلفی بتوانید افراد را دور هم جمع کنید و از آن‌ها بخواهید با هم در مورد مسائلی که دارند و اولویت‌بندی آن‌ها گفتگو کرده و به جمع بندی برسند. برخی از این گروه‌ها موقتی تشکیل می‌شود و بعضی دیگر ممکن است به صورت بلند مدت به کار خود ادامه بندهند. جدای از اینکه این گروه‌ها موقت است یا دائمی و بلند مدت، شما باید روش‌ها و تکنیک‌هایی داشته باشید که گروه‌ مختلفی از افراد را برای اهداف خود گرد هم جمع کنید. در این مطلب امکان گفتگو در مورد این روش‌ها و تکنیک ها نیست. اما اگر به این موضوع علاقه‌مند هستید به اینجا سر بزنید. (مثل همیشه و هر منبع به درد بخور دیگه‌ای تحریم هستیم، پس ابزار دور زننده تحریم مناسب استفاده کنید.)5.1. مثال واقعی: یکی از دوستانم که در مجموعه‌ای در حوزه سلامت و پزشکی فعالیت می‌کرد با من تماس گرفت و از تصمیمشان برای مدرن‌سازی در حوزه‌های سازمانی، فرایندی و فناوری از من درخواست کمک کرد.در ابتدا تصمیم گرفتیم کار را در یک حوزه خاص شروع کرده و در ادامه درس‌های آموخته شده را در حوزه های دیگر در سراسر سازمان اعمال کنیم. در گام اولیه تصمیم گرفتیم طرح توجیهی مدرن‌سازی معماری را ایجاد کنیم. یکی از خواسته‌های آن‌ها در مدرن‌سازی، بهبود همکاری در بخش‌های مختلف سازمان و توانمندسازی همه برای کمک به بهبود مستمر سازمانی بود. ما از فرآیند واقعی ساخت یک کسب و کار برای شروع الگوبرداری و معرفی این رفتارهای مطلوب استفاده کردیم.در ابتدا، جلسات جداگانه‌ای را با افراد مختلف تشکیل دادیم و سپس پرسشنامه‌ای را ارسال کردیم و از افراد در مورد افکار، نظرات و ایده‌هایشان در مورد حوزه‌ی مشخص شده پرسیدیم. ما بینش‌های زیادی به دست آوردیم که به ما اجازه داد اولین کارگاهمان را طراحی کنیم. حضور در اولین کارگاه اختیاری بود. هر کسی که در حوزه‌ی مدنظر کار می‌کند یا علاقه‌مند به همراهی در این سفر بود، می توانست شرکت کند. ما کارگاه را به سه قسمت تقسیم کردیم که با سؤالات ورود و خروج به هم مرتبط می‌شدند. در بخش اول، به شرکت کنندگان این فرصت داده شد تا در مورد اینکه یک سفر مدرن‌سازی ممکن است چگونه باشد فکر کنند تا بتوانند در مورد فرآیندی که می خواهند در پیش بگیرند تصمیم اتخاد کنند. فرایند‌های مختلفی را به آن‌ها پیشنهاد دادیم. فرایند آبشاری ،الماس دوتایی، موج دار و ... از جمله مواردی بودند که پیشنهاد شدند.در این مرحله اغلب شرکت کنند سراغ فرایند‌های سختگیرانه مثل آبشاری نرفتند و الماس دوتایی و موج دار طرفداران بیشتری داشتند. در قسمت دوم کارگاه، از شرکت کننده‌ها خواستم تا دامنه را تعریف کنند. برای اینکار به افراد فضایی دادیم که شامل دو دایره بود که بخشی از آن‌ها مشترک بود و فضاهایی تشکیل شده نمایانگر داخل دامنه، خارج از دامنه، و جایی در میانه بود. برای اینکه افکار شرکت کننده‌ها محدود نشود ساختار خاصی ایجاد نکردیم و خیلی مبهم خواسته‎‌های خود را بیان کردیم. در چنین شراطی برخی افراد و گروه‌ها وابسته به ساختار ارائه شده باقی ماندند، اما برخی دیگر ساختار ما را تغییر دادند مثلا دایره‌های متحدالمرکز رسم کردند تا بتوانند درک خود از دامنه را بهتر بیان کنند و دیدن این خلاقیت‌ها بسیار خوشحال کننده بود.قسمت سوم کارگاه در مورد شناسایی مراحل بعدی بود. در هنگام کار در جداول، هر گروه با پاسخ دادن به این سوال به چالش کشیده شد که "مهم ترین سوالاتی که این گروه باید در مرحله بعدی به آنها پاسخ دهد چیست؟" پاسخ‌های همه گروه‌ها با هم ترکیب شدند، و سپس هر نفر سه رأی داشت تا سؤالاتی را که می‌خواستند به آنها پاسخ دهند مشخص کنند.همانطور که مشاهده کردید در مورد این کار، تصمیم گرفته شد که روی یک حوزه خاص تمرکز شود و طرح توجیحی در آن دامنه ایجاد شود. در این سناریو، کارگاه‌های گروهی ساختاریافته و پرسش‌نامه‌ها، با استفاده از طیف وسیعی از قالب‌های سؤال، تکنیک‌های کلیدی بودند که به رهبران مدرن‌سازی اجازه می‌داد تا بحث‌های گروهی را تسهیل کنند و گروه را برای هدایت فرآیند توانمند کنند.شاید این روش برای ایجاد طرح توجیهی در همه کسب و کارها مناسب نباشد. در شرایطی ممکن است برای کسب و کاری این کار خیلی بیشتر طول بکشد. با این حال، نکته‌ی کلیدی این است که به نحوه‌ی برگزاری جلسات خود فکر کنید و جلسات ساختار یافته در مقابل بدون ساختار و جلسات فردی در مقابل گروهی را بر این اساس انتخاب کنید.5.2. مثال واقعی:به هر حال بعد از گوش دادن و نقشه کشیدن باید آستین بالا بزنیم و کار را شروع کنیم و یکی از انواع کارگاه‌هایی که می‌تواند برای انتقال از مرحله گوش دادن به اجرا در مدرن‌سازی بسیار مؤثر باشد، کارگاه شروع به کار در مدرنیزاسیون است. در این کارگاه، هدف این است که افرادی را دور هم جمع کنیم و در مورد اولین گام‌هایی که باید برداریم تصمیم بگیریم.پیشنهاد می‌کنم بعد از اینکه مدتی جلسات مختلف را برگزار کرده و درک جامعی از شرایط به دست آوردید کارگاهی دو الی سه روزه با شرکت افراد مختلف برگزار کنید و بررسی کنید فهم فعلی و مسیری که برای مدرن‌سازی طراحی کرده‌اید در عمل چگونه به نظر می‌رسد. در ادامه به شما خواهم گفت که شرایط در کسب و کاری که هدفشان از مدرن‌سازی افزایش درآمد شرکت طی پنج سال به دو برابر مقدار فعلی بود، چگونه پیش رفت.برای شروع این کار، با ذینفعان مختلفی از جمله صاحبان محصول، مهندسان، رهبران و کارکنان پشتیبانی صحبت کردیم. ما اینکار را با چندین جلسه برای مرور کلی محصول و استراتژی دنبال کردیم و در مورد مشکلات کاربر و فرصت‌هایی که برای بهبودهای آینده وجود دارد، بحث کردیم. پس از این جلسات، کارگاه‌های گروهی را برای به تصویر کشیدن اهداف کلیدی ماموریت طراحی کردیم. یکی از تکنیک‌هایی که ما استفاده کردیم، Impact Mapping برای به تصویر کشیدن اهداف سطح بالا در کسب‌وکار و نحوه ارتباط آن‌ها به ابتکارات و محصولات قابل تحویل بود.در این مرحله ما میدانستیم معماری مونولیت در ابتدای راه امکان ورود سریعتر به بازار را فراهم کرده است اما در حال حاضر نیاز به اصلاحات و خارج شدن از فضای مونولیت بود. تا اینجای کار برای ما واضح بود. اما سازمان می‌خواست دقیق بداند که کل کار و اصلاحات چقدر زمان و هزینه نیاز دارد. برای این کار مجبور بودیم تمام دامنه بشناسیم و معماری و بخش‌های مختلف را به صورت کامل طراحی کنیم. اما تصمیم گرفتیم این کار را نکنیم و تمرکز خود را روی یک بخش قرار دهیم و به این شکل هم خیلی سریع ارزش ایجاد کنیم و باور به مدرن‌سازی را در سازمان نهادینه کنیم. در کنار این دستاورد با توجه به دانش و بینشی که در عمل به دست می‌آوردیم، برآورد دقیق‌تری نیز برای شکستن بخش‌های دیگر برنامه مونولیت نیز توانستیم ارائه کنیم.سپس ما با هدف شناسایی اولین بخش مدرنیزاسیون و تنظیم یک برنامه سطح بالا برای رسیدن به آن، یک کارگاه شروع به کار مدرن‌سازی را طراحی و اجرا کردیم. کارگاهی سه روزه، به صورت حضوری در دفتر شرکت، با حدود 15 نفر از حوزه‌های محصول و مهندسی با دستور جلسه‌ی زیر برنامه ریزی شد:به دست آوردن چشم انداز کسب و کار و محصولنقشه‌برداری از قابلیت ها و اهداف نرم‌افزار یکپارچه‌س فعلیکاوش در دامنه و آشنایی با آنانتخاب اولین برش برای مدرن‌سازیطراحی معماری برای اولین برشبرنامه ریزی برای تحویل اولین برشاین کارگاه توسط مدیر بخش فناوری اطلاعات که چشم اندازهای میان و بلند مدت کسب و کار را به خوبی می‌شناخت آغاز شد. تبیین این اهداف مهم بود زیرا نقطه‌ی مرجعی برای همه بحث‌های معماری پس از آن ارائه می کرد. چگونه هر ایده یا پیشنهاد با اهداف تجاری و محصول مطابقت دارد؟ سپس کار را با ترسیم نرم‌افزار یکپارچه‌ی فعلی ادامه دادیم. شرکت کنندگان در گروه های کوچک 3 یا 4 نفره کار می کردند، و جالب بود که ببینیم چگونه هر گروه درک متفاوتی از قابلیت های درونی آن دارند. مقداری همگرایی وجود داشت اما واگرایی زیادی پیرامون مرزها و نامگذاری در محدوده 1 و محدوده 2 وجود داشت (محدوده‌ها و حوزه آن‌ها در قسمت اول تعریف شدند). بخش کلیدی این مرحله از کارگاه این بود که هر گروه معیارهای کلیدی کسب‌وکار را که در برنامه‌ی یکپارچه پوشش داده‌ می‌شد، شناسایی می‌کردند.روز دوم، صبح را صرف نقشه‌برداری از دامنه با استفاده از EventStorming در سطح بالا کردیم. در این قسمت ما فرایند‌های مربوط به یک مشتری را مدل کردیم. سوالات و توضیحات زیادی وجود داشت و فرصت خوبی برای یادگیری در اختیار مهندسان قرار گرفت. سپس گروه به اتفاق آرا در مورد اینکه کدام قسمت از نرم‌افزار یکپارچگی اول خارج شود به توافق رسیدند. انتخاب آن‌ها بخشی بود که ارزش تجاری فوری را ارائه می‌کرد و به اندازه‌ی معقولی نیز پیچیده بود، به طوری که نشان‌دهنده چیزی بود که هنگام مدرن‌سازی سایر بخش‌ها باید انتظار داشت.روز سوم کلا روی طراحی معماری بخشی که برای توسعه انتخاب کرده بودیم تمرکز کردیم و تلاش کردیم طرحی داشته باشیم که بدانیم در 6 ماه آینده چه مسیری پیش روی ماست. در پایان، هنوز سؤالات و ناشناخته‌های زیادی باقی مانده بود، اما گروه می‌توانست ببیند به کجا می‌خواهد برود و چالش‌هایی که باید با آن روبرو شود چیست. گام های بعدی برای ادامه پیشرفت به اندازه کافی روشن بود.در پایان روز اول، تمام گروه شام را با هم صرف کردند. همه احساس خوبی داشتند و قبول داشتند که روز اول مثبت بوده است. این فرصت برای معاشرت به تعامل و انرژی بیشتر در طول دو روز باقی مانده نیز کمک کرد. این شرایط مثبت، نتیجه‌ی اولیه‌ی کارگاه‌های شروع به کار سه روزه است.ذکر این نکته خالی از لطف نیست که همه‌ی اعضای گروه به یک اندازه هیجان زده نبودند و به این فرایند اعتقاد نداشتند. برخی شک داشتند که این امر به جایی نمی‌رسد (که یک نتیجه بسیار رایج است). بنابراین در پایان این سه روز، مدیر فناوری اطلاعات ازCTO دعوت کرد تا در بخش پایانی کارگاه را صحبت کند و ابعاد و تاثیرات این سفر را با همه‌ی اعضا به اشتراک بگذارد. سخنرانی او الهام بخش بود و دقیقا همان چیزی بود که در آن لحظه باید گفته می‌شد. وی جدیت نوسازی را با توجه به تغییر چشم انداز‌های کسب و کار توضیح داد و به مهندسان تعهد داد که این کار در اولویت قرار دارد و از حمایت کامل وی برخوردار خواهد شد.چنین کارگاه‌هایی روشی عالی برای ایجاد یک هیجان اولیه هستند. اما ممکن است خیلی ساده حرکت قطار پیشرفت (:-D) کند شود. به همین دلیل است که توصیه می‌کنم یک AMET ایجاد کنید، گروهی که به پیشبرد ابتکار عمل و حفظ شتاب کمک خواهند کرد.5.3. جنبه‌های طراحی:اگر کارگاه‌هایی را طراحی و تسهیل‌گری می‌کنید در اینجا می‌توانید در مورد همه‌ی ملاحظات کلیدی برای ساختار یک کارگاه، مانند محیط اساسی، هنر پرسیدن، ارتباط رو به رشد، تفکر فردی و جمعی، دعوت به مخالفت و موارد دیگر منابعی پیدا کنید. پرداختن به همه عناصر و ارائه مثال‌ها از حوصله‌ی این مطالب خارج است، اما قطعاً منابع ارائه شده ارزش بررسی و مطالعه دارند.6. جمع بندی:اکنون در پایان این قسمت قرار داریم که اولین گام‌های سفر مدرن‌سازی را پوشش می‌دهد، شما دلایل تجاری و سازمانی را برای ابتکارهای نوسازی شناسایی می‌کنید، و فرآیند ایجاد یک طرح توجیحی را آغاز می‌کنید. به طور کلی، ایده های این قسمت را می توان در هر نقطه از سفر مدرن‌سازی استفاده کرد. در قسمت بعدی بر روی تکنیکی به نام Wardley Mapping تمرکز می‌کنیم که در طول جلسات شنیداری و در بسیاری از نقاط در طول سفر مدرن‌سازی مفید است. این تکنیک برای ترسیم دیدگاه‌های تجاری و فناوری با هدف انتخاب استراتژیک بهتر، که یک مهارت حیاتی برای رهبران مدرنیزاسیون است، استفاده می شود. علیرضا ارومند علیرضا ارومند Wed, 28 Jun 2023 21:08:38 +0330 https://virgool.io/@ar.oroumand/%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%88-%D9%85%D9%88%D8%B6%D9%88%D8%B9%D8%A7%D8%AA-%DA%A9%D8%B3%D8%A8-%D9%88-%DA%A9%D8%A7%D8%B1%DB%8C-f9ry9cumc5zl 1. مقدمه:برای مدرن‌سازی معماری باید سرمایه‌گذاری قابل توجهی در سیستم‌ها و مدل‌های عملیاتی انجام گیرد. قرار است تصمیماتی بگیرید و از آن‌ها حمایت کنید و در سفر مدرن‌سازی معماری در مسیر درست حرکت کنید و بهترین بازگشت سرمایه را برای کسب و کار رقم بزنید. برای رسیدن به این اهداف، داشتن درک کامل از نتایج کسب و کار که امیدوارید به دست آورید، حیاتی است. برای رسیدن به دستاورد‌های بزرگ، احتمالاً باید فداکاری‌هایی نیز انجام دهید و از بعضی دستاورد‌های کوچک و کوتاه مدت چشم‌پوشی کنید. بنا بر همین دلایل، رهبران مدرن‌سازی باید بتوانند ایده های خود را به طور ماهرانه‌ای توجیه کرده و به همه‌ی گروه‌های ذینفعان انتقال دهند.باید در افق‌های زمانی متعدد، دیدگاهی مناسب از استراتژی‌های کسب و کار و محصول داشته باشید تا بتوانید سطح بهینه‌ای برای نوسازی ایجاد کرده و از اتلاف وقت و هزینه برای مواردی که کسب و کار را به جلو نمی برد، بپرهیزید. بخشی کلیدی از این دیدگاه، شامل شناخت استراتژی رشد و چگونگیِ کمک به هر محصول در سبد محصولات می‌شود. سپس، میتوان تشخیص داد کدام مناطقِ معماری، بیشترین سود را از مدرن‌سازی خواهند برد. شما باید به سوالاتی از قبیل موارد زیر پاسخ دهید:کدام قابلیت های جدید باید توسعه یابند؟کدام بخش‌های موجود در سیستم به توسعه بیشتری نیاز دارند؟سطح فعلی بدهی فنی در هر بخش از سیستم چقدر است؟بدهی‌های فنی چگونه اهداف فعلی و آتی کسب و کار را محدود می کند؟کدام سیستم ها را می توان منسوخ کرد؟در این قسمت، برخی از رایج‌ترین موارد در حوزه‌های استراتژیک کسب و کاری و خواسته‌های سازمانی‌ای را که در هنگام شروع و پیمایش یک سفر مدرن‌سازی باید در مورد آن‌ها فکر کرد، تشریح خواهیم کرد. آیا می‌خواهید محصولاتی جدید تولید کرده و در بازارهای جدید ورود کنید یا قصد دارید نفوذ خود را در بازارهای موجود از طریق افزایش کیفیت محصولات افزایش دهید؟ آیا دغدغه‌ی شما سرعت نوآوری است؟آیا قصد دارید هزینه‌های عملیاتی را کاهش دهید؟آیا می‌خواهید مقیاس‌پذیریِ سیستم را، برای اطمینان از عملکرد صحیح آن در هنگام رشد سریع تعداد کاربران بهبود ببخشید؟به خاطر داشته باشید که توجیه و مسیر تجاریِ کامل برای کل سفرِ مدرن‌سازی، در ابتدای کار نیاز نیست. اولین گام را می توان تنها در سه ماه انجام داد، مثلا می‌توانید در عرض سه ماه اولین میکروسرویس را از یک نرم‌افزار یکپارچه استخراج کنید، در حالیکه ابتکار دیگری در بخش دیگری از کسب و کار در حال شکل‌گیری است.2. دلایل کسب‌ و کاری برای مدرن‌سازی معماری:رهبران در طول فرایند مدرن‌سازی معماری وظایف متعددی به عهده دارند، مثلا در کارگاه‌های متعددی به عنوان تسهیل‌گر شرکت می‌کننده و به جمع‌آوری داده و به دست آوردن بینش در مورد کسب و کار مشغول می‌شوند. در حالی که این وظایف را انجام می‌دهند باید تلاش کنند که جنبه‌های اصلی و هسته‌ای کسب و کار را نیز تشخیص دهند و بفهمند که مدرن‌سازی معماری چگونه می‌تواند از آن‌ها پشتیبانی کند. این بخش به تشریح سناریوهای تجاری رایجی می‌پردازد که نوسازی معماری در آنها مفید است. می‌توانید این سناریوها را با پرسیدن سؤال‌های روشن‌کننده‌ای مانند موارد زیر کشف کنید: بنابراین منصفانه است که بگوییم نگران از دست دادن زمین در برابر رقبای سریع نیستید و ما باید ۱۰۰٪ روی کاهش هزینه‌های عملیاتی تمرکز کنیم؟ بزرگترین تهدیدهایی که از خارج از سازمان می بینید چه چیز‌هایی هستند؟مانند رقبای سریعتر یا تغییر نحوه‌ی هزینه کردنِ مصرف کننده؟محصول ما چقدر منحصر به فرد است؟ آیا فکر می کنید که می توان آن را به راحتی توسط شرکت های دیگر دوباره ایجاد کرد؟2.1. عقب ماندن از رقبای سریع:در این قسمت می‌خواهم توجه شما را به گفته‌ی زیر از آقای سایمون واردلی جلب کنم:موفقیت، اینرسی ایجاد می‌کند و هرچقدر در گذشته موفق‌تر بوده‌ باشیم، اینرسی افزایش می‌یابد.کسب و کارهای موفق انگیزه‌های خود را برای نوآوری از دست می دهند. در عین حال، بازیگران جدید در زمینه همان کسب و کار ذهنیت‌های متفاوتی دارند، آن‌ها چالش‌های بزرگی برای غلبه بر برندهای تثبیت شده دارند و مجبور هستند دائما دست به نوآوری بزنند و ریسک‌های زیادی را قبول کنند. علاوه بر این، بازیگران جدید با توجه به عدم پیشینه و روال‌هایی که به آن‌ها به ارث رسیده باشد، می‌توانند فرایند‌های خود را در یک زمین خالی شکل داده و با جدیدترین فناوری‌ها و روش‌های به روز شروع کنند، در حالی که مدیرانی که در سازمان‌های موفق مشغول به کار هستند، سال‌ها یا دهه‌ها فناوری و بدهی سازمانی دارند. بسیاری از کسب و کار‌های تثبیت شده و موفق، با ظهور بازیگران جدید و یا رقیبانی که معماری و عملکرد خود را مدرن‌سازی می‌کنند، دچار مشکل می‌شوند. دلیل این مشکل این است که این رقیب‌ها با سرعتی باور نکردنی می‌توانند دست به نوآوری زده و پیشرفت کنند.تا به حال با فردی مواجه شده‌اید که سال‌ها بیماری خاموشی داشته و ناگهان روزی متوجه بیماری خود می‌شود که خیلی دیر است؟ یک نگرانی بزرگ در مورد کسب و کار‌های موفق نیز همین است. روزی متوجه می‎‌شوند دچار کهنگی شده اند و توانایی مقابله با رقیبان در بازار را ندارند که خیلی دیر شده است. تا به حال داستان شسکت‌های بزرگی مثل Blockbuster یا Netscape یا Nokia را مطالعه کرده‌اید؟ هیچ کسب و کاری نمی‌تواند بفهمد که دقیقا چه زمانی خیلی دیر شده است. همانطور که در قسمت اول از این مجموعه نوشتار اشاره کردم، رهبرانِ باهوش، مانند رهبران شرکت نتفلیکس، به نشانه‌ها توجه می‌کنند. این توجه، به آن‌ها برای اصلاح مشکلات خود، نجات از شرایط نابودی، بازگشتن به مسیر صحیح و شکوفایی فرصت مغتنمی می‌دهد.در چنین مواردی، دانش در مورد اینکه رقبیبان در چه مواردی نسبت به شما مزیت دارند و در چه بخش‌هایی از کسب و کار نیاز به مدرن‌سازی دارید، برای کسب و کار شما حیاتی است. علاوه بر این باید دقت کنید که هدف شما ثابت نیست و دائم در حال تغییر است. در حالی که شما معماری‌ خود را مدرن کرده و قابلیت‌هایی ایجاد می‌کنید که بتوانید با شرایط فعلی رقبای خود مقابله کنید، آن‌ها هم مشغول ایجاد ویژگی‌های جدیدی هستند که باز هم از شما جلو بیوفتند. در قسمت‌های آینده در مورد Wardley Mapping صحبت خواهیم کرد. Wardley Mapping بر تکامل چشم اندازهای کسب و کار و شناسایی بخش‌هایی تمرکز می‌کند که مزیت‌هایی را در آینده ایجاد خواهد کرد و یا احتمال بروز اختلال و مشکل در آن بخش‌ها وجود دارد. متأسفانه، رهبرانِ کسب و کار معمولا به مدرن‌سازی معماری و کسب و کار زمانی که ریسکی در بازه‌ی زمانی خیلی نزدیک آن‌ها را تهدید نمی‌کند توجه نمی‌کنند. آن‌ها فکر می‌کنند که چرا باید پول سرمایه گذاری کرده یا ارائه‌ویژگی‌های جدید را کند کنند در حالیکه هیچ خطر فوری‌ای وجود ندارد؟ این یک شکل رایج از اینرسی است که Wardley Mapping با تمرکز بر تکاملِ طولانی‌مدت به آن می‌پردازد.2.1.1. یک مثال واقعی: رهبر بازار خدمات مالی:سازمانی از من خواست که با CTO در فرایند مدرن‌سازی معماری همکاری کنم. کار در این زمینه برای من بسیار جذاب بود. آن‌ها بیش از یک دهه در بازار پیشرو بودند و همیشه در صدر رتبه بندی‌های صنعت قرار داشتند. این امر باعث ایجاد اینرسی شده بود.وقتی به گوشه و کنار شرکت نگاه می‌شد یک ذهیت در آن جاری بود، هر بهینه‌سازی‌ای باید در جهت ثبات، امنیت و اجتناب از خطرات باشد. آن‌ها فکر می‌کردند تا زمانی که سیستم آنلاین بوده و مشتریان بتوانند از آن استفاده کنند،به لطف برندِ بسیار معتبر خود، پیشتاز و رهبرِ بازار باقی خواهند ماند. در حالی که نتایج کسب و کاری خوب بود، داخلِ سازمان عملکرد ضعیفی داشت. عواملی مانند سیاست‌های امنیتی سخت، فرآیندهای توسعه بسیار محدود کننده، سرمایه گذاریِ اندک در باز پرداختِ بدهی‌های فنی، و سبک مدیریت از بالا به پایین منجر به ایجاد محیطی شده بود که در آن مهندسان دائماً سر خود را به دیوار کوبیده و سعی می کردند کارهای ساده‌ای را به سختی انجام دهند. به وضوح ارتباط بین تیم‌های توسعه و عملیات ضعیف بود. نهایتا شرایط در کسب و کار شروع به تغییر کرد. رقبای سریع‌تر با عملکرد بهتر ظاهر شدند و آن‌ها جایگاه خود را در صدر رتبه‌بندی صنعت از دست داند. محصول آن‌ها از رقبا عقب افتاد و استفاده کننده‌های باهوش آن‎‌ها را ترک کردند. البته که مدیران اجرایی باهوش بودند و نشانه‌های عقب افتادگی را درک کرده و یک CTO جدید که اخیرا تجربه و عملکرد خوبی در بازار خدمات مالی ارائه کرده بود را بر سر کار آورند. مدیرِ ارشد فنی جدید، با استفاده از تجربیات گذشته‌ی خود، اهمیت مدرن‌سازی معماری را در قالب یک مثال کسب و کاری و با زبانی مشترک با کسب و کار توضیح داد. او مدیران و رهبرانِ کسب و کار را از اهیمت استفاده از زیرساخت‌های جدید مثل فضای ابری مطلع ساخت. در ادامه، آن‌ها را قانع کرد که داشتن تیم‌های همسو با جریانِ ارزش حول یک محصول در شرایط فعلی سازنده‌تر از روش قدیمی یعنی فرماندهی و کنترل است. او به اعتبار تجربیات قبلی خود و توانایی در بیان ارتباط بین ابتکاراتِ نوسازیِ معماری و تأثیر مثبت آن‌ها بر نتایج تجاری و سازمانی، سطح بالایی پشتیبانی و حمایت از این ابتکار را بدست آورد.دو تیم در ابتدای راه قرار شد مسیر مدرن‌سازی را شروع کنند و به روش جدید کار کنند و من نیز با آن‌ها همراه شدم. در کنار این مسئولیت من با تیم‌های عملیاتی برای ایجاد پلت فرم توسعه و تیم‌های معماری برای ایجاد چشم انداز همکاری می‌کردم. از آنجایی که به اهمیت اجتماعی سازی مدرن‌سازی آگاه بودم، زمان زیادی را نیز صرف تبلیغ ایده‌ها در بسیاری از بخش‌های سازمان به ذینفعان و تیم های مختلف می‌کردم. معرفی ایده‌های جدید در شرکت‌هایی که برای مدت طولانی عادت کرده‌اند به شیوه‌ای کاملا متفاوت کار کنند، به خصوص در شروع یک سفر طولانی، هرگز آسان نیست. در این شرایط داشتنِ یک مثالِ تجاری محکم و چشم‌انداز الهام‌بخش می‌تواند تفاوت بزرگی در فرایند پذیرش مدرن‌سازی ایجاد کند. CTO خیلی خوب می‌توانست با زبانی مشترک با کسب و کار و مثال‌های واقعی از شرایط فعلی و آینده‌ در کسب و کار، تایید و حمایت‌ِ مدیرعامل و سایر رهبران عالی‌رتبه در سازمان را برای خود حفظ کند. این تایید در کل سازمان گسترش یافته و تغییر را به فرآیندی قابل مدیریت تبدیل کرد. هر زمان که تصمیم مهمی گرفته می‌شد، مانند اختیار دادنِ کامل به تیم‌ها برای استقرار کد خود، همه می‌دانستند که این کار مهم است، چرا مهم است، و رهبری ارشد هم کاملاً در جریان است.2.1.2. یک مثال واقعی: Open Table:این مثال از زبان آقای Orlando Perri بیان شده است که بین سال‌های 2010 تا 2015 در OpenTable مشغول به کار بوده است.در سال 2011 شرکت OpenTable در زمینه رزرواسیون رستوران پرچم‌دار بازار بود و رقیب چندانی نداشت. اما شرایط با ورود رقیبانی مثل Yelp کم کم تغییر کرد. ایده‌های زیادی در OpenTable بود تا آن‌ها را کماکان پرچم دار بازار نگه دارد، اما گلوگاه‌هایی در مهندسی وجود داشت. رقیبان با سرعت زیادی ویژگی‌هایی را به سامانه‎‌های خود اضافه می‌کردند در حالی که خلاقیت به خرج دادن و اضافه کردن آن به نرم‌افزار موجود در OpenTable به کندی پیش می‌رفت. در آن زمان بیش از صد نفر مهندس در OpenTable روی یک نرم‌افزار با معماری یکپارچه و انبوهی از مشکلات مشغول به کار بودند. بخش‌های مختلف به شدت به هم وابستگی داشتند و این وابستگی توسعه را بسیار پرریسک و سخت کرده بود. برای توسعه‌ی یک ویژگی جدید با توجه به نیاز به تست‌های دستی بسیار و وابستگی شدید به حداقل 4 هفته زمان نیاز بود. تیم در لندن مشغول به کار بود و میدانست بهره‌وری می‌تواند بسیار بالاتر باشد. اگر ساختار کد متناسب با دامنه تغییر می‌کرد و وابستگی‌ها کم می‌شد کار بسیار ساده‌تر بود. آن‌ها می‌دانستند بعد از این تغییر اگر زیرساخت‌های تحویل مداوم خودکار داشته باشند می‌توانند در روز چندین بار استقرار ویژگی‌های جدید را انجام دهند. از آن مهم‌تر آن‌ها با این تغییرات و از طریق A/B تست می‌توانستند چرخه بازخورد خیلی سریع‌تری ایجاد کنند. با این تغییرات و بروزرسانی‌ها OpenTable در شرایط خوبی نسبت به رقیبان قرار می‌گرفت. اما برنامه‌ریزی و پیاده‌سازی این روش‌ها کار آسانی نبود.در مقطعی از کار زمانی که تیم مدتی تلاش کرد تا ویژگی جدیدی را به برنامه اضافه کند و هر بار انجام کار ناموفق به پایان رسید، بالاخره تیم مدیریتی تصمیم مهمی گرفت. آن‌ها تصمیم گرفتند مدرن‌سازی را انجام دهند و برای این کار تصمیم بر این شد که تمامی کارهای جدید متوقف شده و تیم مهندسی تمرکز خود را روی مدرن سازی معماری قرار دهند. این تصمیم زمانی گرفته شد که یک CTO جدید به سازمان اضافه شده بود و او نیز تیم‌ها و افراد توانمندی را در زمینه‌های DevOps، Continuse Delivery و DDD به تیم اضافه کرد.البته داستان در OpenTable بسیار ویژه است. چون رهبران اصلی سازمان تصمیم گرفتند کل فرایندهای توسعه را برای به ثمر رسیدن مدرن‌سازی متوقف کنند. دلیل این تصمیم این بود که همه می‌خواستند مدرن‌سازی خیلی سریع انجام شود و کار نیمه‌تمامی باقی نماند. چالشی که در این شرایط وجود داشت این بود که رهبران و مدیران ارشد سازمان برنامه زمانی برای به ثمر رسیدن کار مدرن سازی نیاز داشتند. تیم مهندسی پیش‌بینی کرد که کارهای اصلی در مدت 6 ماه انجام شود، اما برای اینکه بتوان شروع به توسعه ویژگی‌های جدید کرد به 8 ماه زمان نیاز بود و در نهایت برای انجام شدن تمامی کارها، یک سال زمان نیاز بود. در نهایت کارها با موفقیت به ثمر رسید و در انتهای مسیر دستاورد‌های مورد انتظار محقق شد. حالا تیم‌هایی همسو با جریان ارزش ایجاد شده بود که می‌توانستند بدون وابستگی به سایرین،چندین بار در روز کارهای خود را در محیط عملیاتی استقرار دهند. تیم OpenTable یک قدم بزرگ برای باقی ماندن در چرخه رقابت را برداشته بود. شاید به نظر برسد توقف همه کارها و تمرکز روی مدرن‌سازی، مانند کاری که در OpenTable انجام شد، تصمیم درستی باشد. اما باید دقت کرد که این تصمیم‌گیری در بسیاری از کسب و کارها سخت و بعضا غیر ممکن است و باید به دنبال راهکارهای تدریجی باشیم. چندین عامل کلیدی در به ثمر رسیدنِ این حرکت برای OpenTable نقش داشتند، اگر بخواهیم مهم‌ترین عوامل را نام ببریم عبارتند از:قبل از شروع کار، آن‌ها در به ثمر رساندن یک هدف تجاری ناموفق بودند و این خود دلیل محکمی بود که مدرن‌سازی برای آن‌ها ارزشمند است. افراد جدیدی که به سازمان اضافه شدند از کیفیت بالایی برخوردار بودند. توقف توسعه ویژگی‌های جدید، برای هشت ماه بدون عواقب شدید تجاری امکان پذیر بود2.2. معماری، رشد کسب و کار را خفه می کند:ممکن است یک کسب و کار رقبای کمی داشته و بازیگران جدید جدی وارد شاخه کسب و کاری آن نشود، اما باز هم معماری می‌تواند نقش تعیین‌کننده‌ای در جلوگیری از به حداکثر رساندن توان یک کسب‌وکار داشته باشد. تقریبا همه‌ی کسب و کارها به طرق مختلف تمایل به رشد دارند. بعضی از آن‌ها آهسته و پیوسته به دنبال رشد و ارتقا بوده و برخی دیگر برای رشد‌های سریع و بزرگ برنامه‌ریزی می‌کنند. به عنوان یک رهبر مدرن‌سازی، درک جاه‌طلبی‌ها و پتانسیل‌های رشد در سازمان برای شما بسیار مهم است. این امر به شما کمک می کند تا بفهمید معماری تا چه حد باعث محدودیت و مانع رشد کسب و کار شده است. موردِ کسب و کاری‌ای که برای توجیه مدرن‌سازی معماری انتخاب می‌کنید باید متناسب با جاه‌طلبی سازمان برای رشد باشد. این مورد کسب و کاری باید نقش مدرن‌سازی در حمایت از رشد سازمان را برجسته کند، مثلا باید نشان دهد چگونه مدرن‌سازی نقاط ضعف در مقیاس پذیری را حل می‌کند یا چطور سرعت در حوزه‌های استراتژیک، بالا می‌ورد.چهار استراتژی رشد مهم وجود دارد که باید از آن‌ها آگاه باشید:نفوذ در بازارتوسعه بازارتوسعه محصول تنوع محصولهریک از این چهار استراتژی ممکن است در هر مقطع زمانی در کسب و کار شما مطرح باشد. استراتژی‌های رشد و نحوه ارتباط آن‌ها به موارد کسب‌وکاریِ نوسازی، در ادامه و با جزئیات بیشتری پوشش داده می‌شود.2.3. دنبال کردن استراتژی خروج:هدف استراتژیک کلیدی برای برخی از کسب و کارها، دستیابی به یک استراتژی خروج است، مانند خرید توسط شرکتی دیگر یا عمومی شدن با یک IPO (initial public offering - عرضه عمومی اولیه). به عنوان مثال، در اوایل سال ۱۴۰۱، مدیر عامل یکی از کسب و کارهایی که با آن‌ها همکاری داشتم، برایم توضیح داد که هدف او این است که شرکت را برای خریداران جذاب جلوه داده و ظرف سه سال شرکت را به فروش برساند. به همین دلیل هنگامیکه درباره مدرن‌سازی معماری صحبت می‌کردیم، او فقط به بحث در مورد ابتکاراتی علاقه داشت که در آن بازه زمانی تأثیرگذار باشد. هر پیشنهادی که در بازه زمانی کوتاه یا میان مدت قابل دستیابی نبود اصلا مورد توجه قرار نمی‌گرفت. رهبران فناوری و مهندسان، هنگامی متوجه این موضوع شدند که برای جدا کردنِ یک پایگاه داده غول‌پیکر که در بخش های مختلفی از کسب و کار نفوذ کرده بود نیاز به زمان و منابع بیشتری بود اما کسب و کار در این مورد همراهی نمی‌کرد.به هرحال مالکان کسب و کار به دنبال خروج از این شرکت در عرض سه سال بودند و تصمیم داشتند مدرن‌سازی معماری هم در این بازه زمانی محدود باشد. در ذهن داشته باشید که مدرن‎‌سازی معماری، می‌تواند کمک کند که شرکت جذاب‌تر به نظر رسیده و ساده‌تر به هدف مالکان که خروج از کسب و کار است دست پیدا کرد. موقع گفتگو با یکی از معماران او به من گفت:می‌توانم قول دهم که یک معمار خوب تمامی کدها، اسناد طراحی و فرایند‌های ما را بررسی خواهد کرد. اگر قصد خروج از کسب و کار را داشته باشیم، نمی‌توانیم صرفا با ظاهرسازی کار را به پایان برسانیم و امیدوار باشیم کسی متوجه مشکلات ما نشود. برای داشتن یک استراتژی خروج خوب باید معماری خوب و فرایند‌های مدرن داشته باشیم.تمرکز روی یک بازه دو تا سه ساله حتی برای شرکت‌هایی که قصد خروج از یک کسب و کار را هم ندارند می‌تواند مفید باشد. بازه کوتاه مدت کمک می‌کند روی کارها و ابتکاراتی تمرکز کنید که در کوتاه مدت اثربخش است. همانطور که می‌دانید مدرن‌سازی نباید سه سال زمان ببرد تا خوبی‌های خود را عیان کند. اگر دقیق‌تر به این سفر نگاه کنیم اکثر شرکت‌ها باید مجموعه‌ای از برنامه‌های کوتاه، میان و بلند مدت برای مدرن‌سازی داشته باشند به طوری که در بازه‌های زمانی مشخص تاثیرات مدرن سازی قابل مشاهده باشد و برنامه‌ای نیز برای ارتقای سیستم‌ها و بخش‌های بسیار پیچیده وجود داشته باشد که برای بروزرسانی نیاز به زمان‌های بسیار طولانی دارند. مثلا وقتی نرم‌افزاری داریم که با معماری یکپارچه و زبان کوبول توسعه داده شده است احتمالا به چندین سال زمان برای جایگزینی آن نیاز داریم. همانطور که مدیرعامل توضیح داد، هنگامی‌که هدف، خروج از یک کسب و کار باشد، باید تلاش کنید که کسب و کار برای خریداران بیشترین جذابیت را داشته باشد. به طور معمول اگر بخواهید در کوتاه مدت جاذبه برای خریداران ایجاد کنید، بیشتر روی بهینه‌سازی معیارهای کسب و کار و حسابداری مانند حاشیه سود ناخالص، رشد درآمد یا درآمد خالص تمرکز خواهید کرد. در برخی از صنایع نیز، رهبران به دنبال بهینه سازی مواردی مثل درآمد قبل از بهره، مالیات، بهای‌تمام شده و استهلاک هستند تا کسب و کار خود را کارآمد جلوه دهند. این موارد معیارهای حسابداری است که سودآوری یک سازمان را برجسته کرده و اغلب برای مقایسه‌ی شرکت ها با یکدیگر استفاده می شود. این معیارها برای شرکت‌هایی که به دنبال جذب سرمایه‌گذار هستند کلیدی است. هرچند باید به این نکته توجه کرد که این معیارها نیز مانند هر گروه معیار دیگری بخشی از حقیقت هستند و اگر صرفا به آن‌ها توجه شود احتمال گمراه شدن وجود دارد.برای رهبران مدرن‌سازی معماری حیاتی است که شرکت‌ها را با معیارهایی مانند آنچه که در بالا ذکر شد نیز مورد بررسی قرار دهند، بخصوص زمانی که می‌خواهند موارد کسب و کاری خاص را برای مدرن‌سازی کنار هم قرار دهند. با این کار نه تنها بهتر می‌توانید ابتکارات مدرن‌سازی را اولویت بندی کنید، بلکه می‌توانید بهتر به زبان کسب و کار صحبت کرده و اعتبار خود را نیز بهبود ببخشید. برای شروع درک این موارد کتاب Financial Intelligence گزینه خوبی است.2.4. رشد با خرید و اکتساب سایر کسب و کارها:ادغام و اکتساب (Mergers and acquisitions - M&A) برای برخی از کسب و کارها نقشی کلیدی دارد. استراتژی‌های رشد متفاوتی با ادغام و اکتساب می‌تواند در نظر گرفته شود. مثلا برای افزایش نفوذ در بازار ممکن است یکی از رقبا را خریداری کنید. یا ممکن است، کسب و کاری را در بازار دیگری به دست آورده تا بتوانید تنوع بهتری در کسب و کار داشته باشید. برای مثال Salesforce با قیمت 27 میلیارد دلار Slack را در سال 2021 خریداری کرد. Salesforce بر این عقیده بود که خرید Slack به آن‌ها کمک می‌کند که پیشنهاد‌های بهتری در دوران جدیدی که برای کار کردن به صورت ریموت ایجاد شده است را ارائه کنند. مثال دیگری در این حوزه‌ نیز خریده شده Github توسط مایکروسافت در سال 2018 به قیمت هفت میلیارد دلار است که به آن‌ها امکان توسعه‌های خلاقانه‌ای مثل GitHub Copilot یا توسعه به کمک هوش مصنوعی را داد.کار در شرکت‌های بسیار بزرگ مانند Salesforce که تمایل و اشتهای زیادی برای M&A دارند چالش‌های معماری و نوسازی معماری خاص خود را دارد. از نگاه مشتریان، که خارج از سازمان هستند، این توقع وجود دارد که سبد بزرگی از خدمات به صورت یکپارچه به آن‌ها ارائه شود. درون سازمان نیز احتمالا رهبران این خواسته و جاه‌طلبی را دارند، اما از دیدگاه فنی ممکن است شرایط متفاوت باشد. با خرید هر کسب و کار و اضافه کردن آن به شرکت، چشم انداز و گستره فناوری ممکن است تغییر کند. از دیدگاه تکنولوژی و فناوری هر خریدی که انجام می‌شود ممکن است نرم‌افزاری باشد که معماری یکپارچه داشته و در دوره‌ها و فرهنگ‌های متفاوتی تولید شده باشد، ممکن است از ابزارها و زبان‌های برنامه نویسی متفاوتی با آنچه داخل شرکت وجود دارد نیز استفاده کرده باشد، در چنین شرایطی انتظار می‌رود همه‌ی این نرم‌افزارهایی که خریداری شده اند بتوانند با هم زیر یک چتر و در قالب سبدی یکپارچه و هماهنگ از خدمات ارائه خدمت کنند. در چنین شرایطی شرکت تلاش می‌کند با خرید راهکارهای بیرونی و ارائه یکپارچه آن‌ها ابتکاراتی را در حوزه کسب و کار وارد کند و از منظر فناوری اطلاعات نیز برای حمایت از این تصمیمات و پیش‌برد اهداف شرکت راهکارهایی مثل ارائه هویت واحد و متمرکز وجود دارد. اما تعداد زیاد تیم و تکنولوژی‌های متعدد فرایند تغییر اولیه را کند می‌کند. چالش دیگری نیز در این شرایط وجود خواهد داشت، برای مثال ممکن است تیم‌ها جایگاه خود در تصویر بزرگی که ایجاد می‌شود را تشخیص ندهند، یا در برخی قسمت ها سیلوهایی ایجاد شود، یا کارهای تکراری و پراکنده در قسمت‌های مختلف انجام شود. بعضاً ممکن است در انتخاب تکنولوژی و ایجاد زیرساخت نیز چالش‌هایی بوجود آید. همه‌ی شرکت‌هایی که استراتژی M&A را در پیش می‌گیرند،در مقیاس Salesforce فعالیت نمی‌کنند، اما برخی یا همه‌ی این چالش‌ها احتمالاً تا حدی برای همه وجود خواهد داشت. در نتیجه، ممکن است برای شناسایی معماری بهینه، پس از خرید یک کسب و کار، بازنگری اساسی در محصولات، دامنه‌ها، نرم‌افزارها و تیم‌ها مورد نیاز باشد. برای تعمق در این موضوع، سخنرانی Ora Egozi Barzilai از MuCon 2019 را مشاهده کنید. وی تجربیات خود را در رهبریِ چندین تکرار برای مدرن‌سازی معماری در Taboola در سال 2016 پس از یک خرید کلیدی را بازگو می‌کند.اگر سازمان شما به دنبال رشد از طریق خرید سایر کسب و کارها است، اما معماری کنونی برای یکپارچه‌سازی فناوری‌های شرکت‌های خریداری‌شده مناسب نیست، بخش مهمی از مسئله تجاریِ مدرن‌سازی شما، تشریح این چالش‌هاست و توجیه اینکه چگونه مدرن‌سازی باعث می‌شود سریع‌تر بتوانید کسب و کارهای خریداری شده را به جریان کسب و کار فعلی خود اضافه کرده و از قابلیت‌های آن‌ها بهره‌مند شوید.2.5. تجربه کاربری (UX) ضیعف شرکت را عقب نگه می‌دارد:در بعضی از محصولات، UX می تواند موجب موفقیت یا عدم موفقیت کل مدل کسب و کار شود. هنگامی که UX ایراد دارد، صرفا طراحی مجدد وب سایت یا نرم‌افزار ممکن است کافی نباشد. در مواردی که UX چنین تاثیر عمیقی دارد، مدرن‌سازی معماری نیز ممکن است ضروری باشد.یکی از راه هایی که معماری می تواند عاملی اساسی در UX ضعیف باشد، غیرقابل اعتماد بودن است. آقای Dan Young تجربه‌ای در این زمینه دارند که در ادامه مطالعه می‌کنیم. در پاییز سال 2021، او سعی داشت سامانه‌ی اجاره‌ی ماشین را در اختیار بگیرد و در نهایت موفق به در اختیار گرفتن سه گزینه شد. این گزینه‌ها UX ضیفی داشند که ناشی از مشکلات معماری بود. روزی از وبسایت از او خواستند تا فرایند پرداخت را یک بار بررسی کند زیرا حتی هنگامی که رزور خودرو با موفقیت انجام می‌شود باز هم بک‌اند خطا بازگشت می‌دهد. شرکت پیشنهاد داد وجه یکی از رزرو‌هایی که خطا در آن موجب استرس زیادی برای دن شده بود را بازگشت دهند که این کار باعث خدشه دار شدن اعتبار وی شد. در مدرن‌سازی سیستمی که من روی آن کار می‌کردم، یکی از مشکلات اصلی کاربران، ناتوانی در وارد کردن اطلاعات کافی در مورد مسئله‌ای بود که با آن مواجه شده بودند. برای رفع این مشکل دردسرهای اضافی مانند تماس‌های تلفنی و نامه‌ها شد به آن‌ها تحمیل می‌شد تا به طریقی دیگر مسئله را از آن‌ها دریافت کنند و این مشکل، کاربران را ناامید کرده بود. شاید در ظاهر این مسئله یک کار UX ساده باشد اما محدودیت کاراکتر بخاطر داده‌های ارسالی به کمک XML، پایگاه داده اصلی و یک پایگاه داده میانی، که همه بخشی از یک سیستم قدیمی و شکننده بودند، ایجاد شده بود. در اصل این مشکلات ناشی از مسائل عمیق در طراحی و معماری سیستم بود نه UX.رهبران کسب و کار و مدیران محصولات که با محدودیت‌های فناوری آشنا نیستند، تصور می‌کنند مشکلات UX را می‌توان با طراحی مجدد وب‌سایت برطرف کرد. آن‌ها نمی‌دانند مدرن‌سازی عمیق‌تری مورد نیاز است. هنگام توجیه کسب و کار برای مدرن‌سازی، کمک به همه ذینفعان برای درک علل عمیق‌تر مشکلات UX و محدودیت‌های عدم پرداختن به این دلایل عمیق‌تر مهم است. آن‌ها باید بدانند مشکلاتی که در سامانه‌ها وجود دارد صرفا مربوط به رنگ یا محل قرارگیری چند دکمه نیست.2.6. ابزارها و فرایند‌های داخلی نا کارآمد:تجربه کاربری محصولات و فرایند‌های داخلی در بعضی سازمان‌ها به همان اندازه که تجربه کاربری محصولات بیرونی مهم است، دارای اهمیت و جایگاه است. طرز فکر اشتباهی وجود دارد که بعضا فکر می‌کنند تجربه کاربری ابزارهای داخلی که کارمندان استفاده می‌کنند مثل تجربه کاربری مشتریان اهمیت ندارد. این طرز فکر باعث می‌شود که پرسنل، برای انجام وظایف و کارهای روزمره خود با ابزارها و فرایند‌های ضعیف دست و پنجه نرم کنند. در چنین شرایطی هزینه‌ی عملیاتی و اجرایی بالا می‌رود و به مرور، هرچه کارها بیشتر می‌شود این مشکل و هزینه نیز بیشتر می‌شود. در یکی از شرکت‌هایی که کار می‌کردم برای انجام یک فرایند مجبور به استفاده از سه سیستم مختلف بودیم. هر کدام از این سیستم‌ها هم UX بسیار بدی داشت و زمانی طولانی نیاز بود تا یاد بگیریم با آن‌ها کار کنیم. با توجه به زمان زیادی که انجام کار طول می‌کشید، شرکت دائما مجبور بود افراد بیشتری را برای انجام کارها استخدام کند. اما اضافه کردن نیروی بیشتر تا جایی امکانپذیر بود و بعد از مدتی شرکت درخواست به روز رسانی UX این سامانه‌ها را داد که در نهایت متصدیان این سامانه متوجه شدند برای به روز رسانی UX و رفع مشکلات فعلی نیاز به مدرن‌سازی در لایه‌های عمیق‌تری دارند. 2.7. بهبود شرایط استخدام و ماندگاری:به طور کلی توانایی استخدام و حفظ افراد با استعداد در بسیاری موارد نادیده گرفته می‌شود. اما این مورد از نظر من یکی از مزایای قابل توجه مدرن‌سازی معماری است. چند سال پیش، با شرکتی که تلاش می‌کرد افراد توانمندی را به تیم توسعه‌ی خود اضافه کند همکاری داشتم. یکی از عوامل مهم در عدم توانمندی آن‌ها برای جذب این بود که سامانه‌ای بسیار مهم و بزرگ داشتند که با C++ توسعه داده شده بود. افراد کمی توانایی و خواست این را داشتند که در چنین جایگاه شغلی‌ای همکاری کنند. در نتیجه، آنها وابستگی زیادی به مهندسان و فارغ التحصیلان جوان و کم تجربه داشتند که باعث می‌شد شرایط معماری روز به روز بدتر شود. یک کارگاه 2 روزه برای بررسی اولیه شرایط برگزار کردم که در همان کارگاه هم تنش و ناامیدی برای تغییر سریع و یافتن راه حل‌های کوتاه مدت احساس می‌شد.طبق تجربه‌ی سالیان کاری‌ای که داشتم، بخشی از موفقیت سیستم‌ها وابسته به استعداد افرادی است که در آن‌ها کار می‌کنند و استعداد افراد نیز به شرایط کسب و کار اضافه می‌شود. افراد با استعداد که در محیط‌های مناسب با حد مناسبی از اختیار مشغول به کار هستند، کلید تولید محصولات خوب و کارآمد هستند. داشتن معماری مدرن یا برنامه مناسب برای مدرن‌سازی معماری کلید جذب افراد با استعداد است. اگر معماری خوبی داشته باشیم یا برنامه‌ای برای مدرن‌سازی داشته باشیم افراد با استعداد، به جای مبارزه با سیستم های قدیمی و فرآیندهای بد که امیدی به بهبودشان نیز وجود ندارد، فرصت و پتانسیل برای حل مشکلات جالب را می‌بینند.استخدام و حفظ استعدادها احتمالا انگیزه‌ی اصلی برای نوسازی نباشد، اما ارزش آن را دارد که هنگام توجیه کسب و کار برای مدرن سازی به این مورد نیز بپردازید.3. ایجاد ارتباط بین استراتژی‌های رشد و مدرن‌سازی معماری:در این بخش به استراتژی‌های رایج رشد کسب‌وکار و انواع چالش‌های مدرن‌سازی معماری که در آن‌ها وجود دارد خواهیم پرداخت. این استراتژی‌های رشد، مبتنی بر ماتریس آنسوف است که در شکل نشان داده شده. ماتریس آنسوفیک شبکه 4×4 است که رشد را بر اساس محصولات جدید در برابر محصولات موجود و بازارهای جدید در برابر موجود طبقه‌بندی می‌کند.توجه کنید که در یک سازمان تمام یا بخشی از این استراتژی‌ها ممکن است وجود داشته باشند. همچنین شایان ذکر است که نیاز نیست که تلاش کنید همه چیز در یکی از این چهار قسمت قرار بگیرد. در عوض، از ماتریس به عنوان شروع کننده مکالمه استفاده کنید.ماتریس آنسوف3.1. استراتژی‌های رشد - توسعه محصولاستراتژی رشد بر مبنای توسعه‌ی محصول بر ایجاد سهم بازار، در بازارهای موجود از طریق توسعه محصولات و خدمات جدید تمرکز دارد. بازار را در این زمینه، می توان به عنوان گروهی از افراد که علاقه‌مند به نوع خاصی از محصول هستند و احتمالا خریدار آن نوع خاص از محصول هستند در نظر گرفت. برای مثال، تقسیم‌بندی بازار شامل گروه‌بندی زیرمجموعه‌های یک بازار بر اساس ویژگی‌هایی مانند سن، حرفه، تعداد کارکنان، صنعت و درآمد است. برای کنسول‌های بازی‌های ویدیویی، بازار همه افرادی است که بازی‌های ویدیویی کنسولی بازی می‌کنند، و می‌توان آن‌ها را بر اساس انواع بازی‌هایی که دوست دارند انجام دهند، تقسیم‌بندی کرد. این بدان معنی است که استراتژی رشد بر مبنای توسعه‌ی محصول در مورد ساختِ محصولات و خدمات جدیدی است که همان افراد را هدف قرار می دهد که محصولات موجود را استفاده می‌کنند.با این نوع استراتژی رشد، شرکت در حال توسعه محصولات جدیدی است که احتمالاً شباهت‌هایی به محصولات موجود دارند، زیرا همان افراد را هدف قرار داده است. چند نکته‌ی معماریِ واضح که باید در مورد آنها فکر کرد عبارتند از قابلیت های مشترک، یکپارچه سازی محصول و ایجاد تعادل بین سرمایه‌گذاری جدید و قدیمی.زمانی که هر دو محصول قدیمی و جدید از قوانینِ تجاری، محاسبات یا داده‌های مشابهی استفاده می کنند که دوباره ایجاد کردن آن‌ها گران تمام می شود، ممکن است در نظر گرفتنِ قابلیت‌های مشترک لازم باشد. قابلیت‌های مشترک ممکن است از کارهای عمومی مانند سیستم اطلاعات هویتی باشد یا یک ویژگی مخصوص دامنه نیاز باشد به صورت مشترک استفاده شود. اشتراک ریسک ها و چالش‌های خاص خود را دارد. اولین چالش زمانی است که می‌خواهیم ویژگی مشترک را از سامانه‌ی موجود که در ابتدا صرفا برای آن توسعه داده شده بود جدا کنیم و این کار ممکن است نیاز به کار و انرژی بیش از آنچه در ابتدا تصور می‌شود نیاز داشته باشد. خیلی وقت‌ها برای مدیران و سهامداران قابل درک نیست که چرا استفاده از یک ویژگی موجود باید هزینه بر باشد.چالش‌ دیگری نیز وجود دارد مثل تعیین سطح مناسب برای استفاده‌ی مجدد.در این شرایط باید یک مدل دامنه و رابط‌هایی را طراحی کنیم که بیش از حد خاص یا بیش از حد عمومی نباشند. همیشه این خطر وجود دارد که قابلیت‌های مشترک به یک گلوگاه تبدیل شده و به همان اندازه سطح استفاده مجدد کمتر از حد انتظار باشد.این موضوع را در فصل‌های بعدی که در مورد مدل‌سازی دامنه، طراحی معماری و توپولوژی‌های تیم صحبت می‌کنیم بیشتر باز خواهیم کرد.هنگامی که مشتریان از محصولات یک شرکت استفاده می کنند، معمولاً انتظار دارند هم‌افزایی و یکپارچگی وجود داشته باشد. شرکت Salesforce و محصولاتش را در نظر بگیرید، مشتریان آن‌ها از اینکه مجبور بودند چندین نام کاربری و رمز عبور برای محصولات مختلف داشته باشند بسیار ناراحت و سرخورده بودند. سوالی که زیاد پرسیده می‌شد این بود که ما در حال استفاده از محصولات Salesforce هستیم، چرا باید برای هر محصول نام کاربری و کلمه عبور مجزا داشته باشیم؟ همچین ایراداتی باید در سطح معماری رفع و رجوع شود. شرایطی باید ایجاد شود که امکان ادغام ویژگی‌های مشترک وجود داشته باشد و برای این کار نیاز به صرف هزینه در رابطه با مدرن‌سازی و اصلاح معماری است.توسعه‌ی محصولات جدید در کنار محصولات موجود،چالش‌هایی را پیرامون طرز فکر و اولویت بندی نیز ایجاد می‌کند. محصولات جدید اغلب پتانسیل بیشتری دارند و سرعت آزمایش و نوآوری احتمالاً سریع‌تر خواهد بود، در حالی که محصولات موجود ممکن است پایگاه مشتریان زیادی داشته باشند و به ثبات بیشتری نیاز داشته باشند. زمانی که چندین تیم سعی می کنند با سرعت های متفاوت حرکت کنند و احساس می‌کنند محصول دیگر سرمایه‌گذاری و توجه بیشتری نسبت به محصول آن‌ها جلب می‌کند، دردسرهایی ایجاد می‌شود.3.1.1. یک مثال واقعی - توسعه محصولات دریاییزمانی شانس این را داشتم با شرکتی کار کنم که سخت افزار و نرم افزار را برای کسب و کارهایی دریایی می‌ساخت. از قایق‌های تفریحی لوکس گرفته تا قایق‌های ماهیگیری کوچک یا تانکرهای تجاری آن‌ها خدماتی ارائه می‌کردند. در آن زمان، آن‌ها قصد داشتند کسب و کار خود را با استراتژی رشد بر مبنای توسعه‌ی محصولات ارتقا دهند. تا آن زمان، آن‌ها عمدتاً در کارِ دستگاه‌های سخت‌افزاری و نرم‌افزارهای تعبیه‌شده بودند، اما می‌خواستند با توسعه‌ی تجربیات متصل به اینترنت، پیشنهادات خود را به بخش‌های مشتریان فعلی افزایش دهند. برای مثال، آن‌ها قصد داشند توانایی نظارت از راه دور بر حسگرهای یک قایق، مانند سرعت موتور و دما را ایجاد کنند. تولید این برنامه و ایجاد یک چرخه کاری با تجربه کاری عالی قمار بزرگی بود که آن‌ها به دنبال آن بودند. مدل کسب و کار، بسیار قانع کننده بود و افراد با استعدادی نیز برایانجام این کار کاندید شده بودند.با تمام این اوصاف از منتظر فناوری محدودیت‌هایی وجود داشت و در عرض 2 سال کار پیشرفت کمی داشت. در نتیجه هیئت مدیره شروع به تحت فشار قراردادن مدیرعامل کردند. تیم فنی تلاش کرد با معماری موجود نرم‌افزار را تولید کند. در این راه نشانه‌هایی وجود داشت مثل پایگاه داده‌های محلی و کد‌های کثیف و مشکل داری که برای آن‌ها نشانه خوبی نبود. آن‌ها می‌دانستند در شرایط فعلی توانایی پردازش هزاران پیامی که در لحظه توسط حسگرها و ... ارسال می‌شود را ندارند. هنگامی که آن‌ها تلاش کردند شرایط کاری را تست کنند تنها موفق به پاسخگویی به 5 قایق شدند اما در طرح کسب و کاری آن‌ها می‌خواستند هزاران قایق را به صورت همزان و متصل مشاهده و مدیریت کنند. در این زمان یک طرح مدرن‌سازی با زبان کسب و کاری گردآوری شد که نیاز به خدمات ابری، داشتن ویژگی چند زبانگی، نیاز به معماریِ میکروسرویس و معماریِ رویداد محور را با ادبیاتی که کسب و کار متوجه ان شود تشریح کرد. آن‌ها همه‌ی موضوعات مدرن‌سازی معماری، مانند مقیاس‌پذیری، را به این نتایج تجاری گره زده و ارائه کردند. اگر با زبان فنی مثل Event و ... با رهبران کسب و کار صحبت می‌شد احتمالا خیلی راحت ‌آن‌ها زیر انبوهی از کلمات فنی مدفون می‌شدند، اما بیان نکاتی مثل اینکه هزاران قایق، تعداد زیادی حسگر دارند که نیاز است داده‌ی همه این حسگر‌ها، در لحظه امکان دریافت توسط سامانه را داشته باشد، کاملا برای رهبران سازمان قابل فهم بود.3.2. استراتژی‌های رشد - نفوذ در بازاردر استراتژی رشد بر مبنای نفوذ در بازار، هدف به دست گرفتن بخش بیشتری از بازار با محصولات و خدمت موجود است. نفوذ بالا در بازار از نشانه‌های رهبران بازار است. نفوذ زیاد در بازار نه تنها سود بیشتری را عاید شرکت می‌کند بلکه برند قوی‌تری نیز می‌سازد و این شرایط به نوبه خود مزایای دیگری مانند صرفه جویی در مقیاس و اتکای کمتر به بازاریابی را نیز به همراه دارد. استراتژی‌های نفوذ در بازار را می‌توان به روش‌های مختلفی اجرا کرد، مثلا تغییر در قیمت‌گذاری، افزایش محصولات موجود، خرید و تحت کنترل در آوردن رقیب، و ابتکارات فروش و بازاریابی.رویکردی که برای افزایش نفوذ در بازار انتخاب می‌شود، روی ابتکارات و کارهای نوسازی معماری نیز اثر گذار است. احتمالاً باید بهینه‌سازی‌هایی برای سیستم‌های موجود انجام شود زیرا هیچ محصول جدیدی در حال توسعه نیست. ممکن است لازم شود تغییرات قابل توجهی در بخش‌های موجود در سیستم ایجاد شود که خود، مستلزم مدرن‌سازی آن بخش‌های سیستم برای ایجاد نرخ سریع‌تر نوآوری است. هنگامی که سناریوی کاهش هزینه در نظر گرفته می‌شود، نوسازی ممکن است با کاهش هزینه‌های عملیاتی نقشی کلیدی ایفا کند، مثلا ممکن است در مدرن‌سازی، فرایند‌های دستی شناسایی و خودکار شوند و یا ابزارهایی مورد استفاده قرارگیرد که بهره‌وری پرسنل بهتر شود و این موضوع باعث کاهش هزینه‌ها شود و به این روش کاهش قیمت برای شرکت امکانپذیر شود.برای رهبران کسب و کار و فناوری مهم است که اولویت‌های کسب و کار را برای سرمایه‌گذاری در بازارهای جدید یا افزایش نفوذ در بازارهای موجود به طور شفاف درک کنند. ممکن است تمایل به سرمایه گذاری هنگفت در هر دو وجود داشته باشد، بنابراین شناسایی سطح نوسازی مورد نیاز برای حمایت از هر دو استراتژی حیاتی است. ذکر این نکته ضروری است که همزمان نمی‌توان چندین هدف را پیگیری کرد؛ پس بهتر است هدفی تعیین شده و تا زمانی که مدرن‌سازی در راستای آن هدف به پیشرفت قابل توجهی نرسیده، تمرکز در همان راستا حفظ شود. قبلا در مورد ارائه‌ی ارزش‌های مدرن سازی صحبت کرده ایم و در این قسمت مشاهده می‌کنید که چگونه ممکن است در یک کسب و کار نیاز باشد جهت گیری‌های متفاوتی برای مدرن سازی بر اساس بازار موجود یا جدید انجام داد و باید این موارد به خوبی انتقال یابد تا تصمیم صحیح گرفته شود.3.2.1 یک مثال واقعی - نفوذ در بازار بانک های چلنجر آمریکای لاتینچند سال پیش بانک چلنجر آمریکای لاتین با حرکت سریع و داشتن بهترین UX، که توسط رتبه‌بندی‌های App Store آنها تأیید شده بود، خود را در بازار تثبیت کرده بودند. برای اینکه مسیر رشد خود را ادامه دهند، لازم بود افراد بیشتری از خدمات آن‌ها به عنوان بانک اصلی خود استفاده کنند. مثلا لازم بود افراد بیشتری از حساب‌های آن بانک برای دریافت حقوق خود استفاده کنند. در آن زمان اغلب مشتریان آن‌ها از خدماتشان به عنوان بانک جانبی بهره‌مند می‌شدند. ستاره شمالی که آن‌ها را هدایت می‌کرد کاملا شفاف بود. رهبران سازمان و محصول می‌دانستند که آن‌ها نیاز به سرمایه‌گذاری زیادی دارند که به این هدف دست یابند. به عنوان یک استارت‌آپ، آنها توجه زیادی را به خود جلب کرده بودند. برای اینکه در زمان کوتاه و با هزینه کم به این هدف برسند کارهایی انجام داده بودند که کدهای کثیف و فرایند‌های پر هزینه‌ای روی دست آن‌ها گذاشته بود. آن‌ها به مدرن‌سازی معماری برای حرکت به سمت سودآوری و جذاب شدن برای سرمایه‌گذارانی که سرمایه‌شان برای برداشتن گام بزرگ بعدی لازم بود، نیاز داشتند. برقراری تعادل لازمه‌ی کار آن‌ها بود. این شرکت نمی توانست به مدت یک سال توسعه را متوقف کند تا مدرن‌سازی انجام شود، باید وجهه خود را به عنوان یک بانک نوآورانه نسل بعدی حفظ می کرد. فرایند مدرن‌سازی باید حول فعالیت‌هایی قرار می‌گرفت که شرکت را برای سرمایه‌گذاران جذاب جلوه دهد در حالیکه مشکل جدیدی ایجاد نکرده و بخشی از ظرفیت هم برای ایجاد ویژگی‌های جدید خالی بماند. هزینه‌های پشتیبانی از مشتری در سفر به سمت سود آوری به‌ عنوان حوزه اصلی تمرکز در نظر گرفته شد. با افزایش تعداد مشتریان، واحد پشتیبانی از آن‌ها نیز به خاطر ابزارهای مشکل دار و فرایند‌های دستی زیاد به صورت خطی باید رشد می‌کرد. فرصت‌های واضحی برای نوسازی فناوری، روش‌های کار، و فرآیندهای عملیاتی برای تغییر وضعیت در این قسمت وجود داشت.3.3. استراتژی‌های رشد - توسعه‌ی بازاراستراتژی رشد بر مبنای توسعه بازار یعنی در بازرهای جدید با محصولات و سرویس‌های موجود نفوذ کنیم. این کار معمولا با بررسی بازار برای به دست آوردی بخش جدیدی از مشتریان شروع می‌شود. در این حوزه شاید اسنپ مثال خوبی باشد. آن‌ها در ابتدا در حوزه حمل و نقل تمرکز کردند و بعد از اینکه نفوذ کاملی در آن صنعت پیدا کردند از همان خدمات برای گسترش کار به حوزه رستوران و داروخانه استفاده کردند. هنگام انتخاب این استراتژی درک اینکه چه زمانی این استراتژی مناسب است، چقدر بازار جدید با بازار فعلی شباهت دارد و چه مقدار سرمایه گذاری باید روی محصولات و خدمات جدید انجام شود، حیاتی است. ممکن است در این راه نیاز باشد محصولات فعلی را تغییر دهیم. در این شرایط ممکن است باز به شرایطی برسیم که نیاز به داشتن ویژگی‌های مشترک باشد. به طور کلی هنگامی که از یک محصول برای چندین بازار استفاده می‌شود معماری و ساختار تیم‌ها یکی از چالش‌های اصلی است. آیا باید کماکان یک تیم روی محصول برای همه بازار‌ها فعالیت کند یا باید قسمت‌های مشتری و اختصاصی جداگانه‌ای ایجاد شود؟ در این شرایط از EventStorming برای تشخیص عملکرد فعلی و کمک به تصمیم گیری در آینده می‌توان بهره برد. قبلا مطالبی در مورد EventStorming نوشته‌ام که می‌توانید به آن‌ها مراجعه کنید و در ادامه نیز به این موضوع خواهم پرداخت.3.3.1 یک مثال واقعی - توسعه بازار شرکت خدمات مسافرتی در زمان کروناکرونا درس‌های زیادی به ما داد و یکی از آن‌ها این بود که موضوعی خارج از کنترل و دانش بشر، که همه‌ی جنبه‌های زندگی او را تحت تاثیر قرار دهد صرفا در فیلم‌ها رخ نمی‌دهد. انتظار برای غیرمنتظره‌ها به معنای آگاهی از حوزه‌هایی از معماری است که مقیاس‌پذیر نیستند، حتی اگر در حال حاضر یا در آینده نیازی به مقیاس‌پذیری آشکار وجود نداشته باشد، اما ناگهان اتفاقی رخ دهد که نیاز به مقیاس‌پذیری ایجاد شود مانند شرکت مسافرتی که در ادامه مورد بحث است. تا قبل از کرونا، تعداد کنسلی و بازپرداخت‌هایی که رخ می‌داد بسیار کم بود. اغلب کارهایی این حوزه به کمک فرایند‌های دستی رخ می‌داد و بیشترین فناوری که مورد استفاده قرار میگرفت اکسل بود و این روال برای سالهای متمادی به خوبی کار می‌کرد. با بروز کرونا و قرنطینه ناگهان شرایط متفاوت شد. آن‌ها توانایی پاسخ به این تعداد درخواست کنسلی را نداشتند. در این شرایط مشتریان از روال کند در کارهای به خشم آمدند و سیستم‌های نظارتی وارد عمل شدند و برند و اعتبار آن‌ها دچار مخاطره شد. این شرکت قصد داشت یک استراتژی رشد بازار را دنبال کند که مستلزم تطبیق قابلیت‌های موجود برای هدف قرار دادن انواع جدیدی از مشتریان بود. کرونا حقایق زیادی را آشکار کرد. شرایط کرونا نشان داد قبل از تعیین اهداف تجاری بلندپروازانه که منجر به ایجاد پیچیدگی بیشتر بر روی معماری موجود می‌شود، لازم است به صورت عمیق و گسترده به مدرن‌سازی در سراسر سازمان بپردازیم. باید جنبه‌های مختلف مثل فناوری، فرهنگ و طرز فکر را مدرن کنیم. هرچند کرونا برای این شرکت مشکلات زیادی ایجاد کرد، اما درسی که به رهبران اصلی شرکت داد ارزشمند بود. 3.4. استراتژی‌های رشد - تنوع بخشیاستراتژی رشد بر مبنای تنوع، روی راه اندازی محصولات یا خدمات جدید در بازار یا بازارهایی که سازمان در حال حاضر آن را هدف قرار نمی دهد، متمرکز است. یکی از سازمان‌هایی که به طور مداوم از تنوع تهاجمی برای موفقیت فوق العاده استفاده می کند، آمازون است. آمازون در ابتدا یک کتابفروشی بود که به یک غول خرده‌فروشی تبدیل شد، سپس تجارت ابری AWS خود را تأسیس کرد که به تنهایی بیش از 60 میلیارد دلار در سال 2021 درآمد داشت.بعدها، آمازون تنوع محصولات خود را در طیف وسیعی از بازارهای دیگر، مانند پخش ویدئو، موسیقی، مواد غذایی، خانه های هوشمند، و کنفرانس ویدئویی گسترش داد. همانطور که ماتریس آنسوف نشان داد، متنوع‌سازی مخاطره‌آمیزترین استراتژی است که حتی آمازون نیز هر از گاهی در آن اشتباه می‌کند، که نشان از دشواری ورود آن به بازار بازی‌های ویدیویی دارد.همه شرکت‌ها منابع و استعدادهایی که در اختیار آمازون است را ندارد. رهبران فناوری،باید به طور دقیق بدانند که معماری فعلی چقدر از جاه‌طلبی‌های آن‌ها برای متنوع‌سازی کسب‌وکار پشتیبانی می‌کند و چقدر سرمایه‌گذاری مورد نیاز است تا بتوانند به سطح دلخواه برسند. نکته مثبتی که باید در نظر گرفت این است که شاید بتوان محصول جدید را به طور کامل مستقل و خارج از سیستم‌ها و زیرساخت‌های فعلی توسعه داد. در این شرایط محصول جدید فرصتی اس که فناوری‌ها و روش‌های کاری جدید را مورد استفاده قرار داده و بازخورد آن را برای استفاده در بخش‌های قدیمی نیز دریافت کنیم. البته تهدیدی نیز در این جریان وجود دارد.ممکن است در بخشی از کار سیستم و روش‌های کار قدیمی، سیستم‌ها و تیم‌های جدید را آلوده کنند، از روز اول باید برای مقابله با این شرایط آماده شد.مضامین مدرن‌سازی معماری که قبلاً ذکر شد ممکن است در یک استراتژی متنوع‌سازی نیز کاربرد داشته باشند: قابلیت‌های مشترک، یکپارچه‌سازی، ذهنیت‌های متنوع، مدل‌های دامنه عمومی در مقابل بازار خاص، و تضادهای اولویت‌بندی سرمایه‌گذاری.3.4.1 یک مثال واقعی - تنوع در تجارت الکترونیکی تنظیم شدهپس از یک دهه رهبری بازار در تجارت الکترونیکی تنظیم شده مرتبط با سلامت، رشد یکی از مشتریان من کند شده بود. آن‌ها از اولین شرکت‌های آنلاین در حوزه سلامت بودند و به واسطه این پیشرو بودن برند خوبی نیز داشتند. اما با اینکه سطح نفوذ بالایی در بازار داشتند رشد آن‌ها سال به سال کمتر می‌شد و نیاز به طرح‌های بلند پروازانه‌ای داشند تا رشد خود را بهبود ببخشند. شرکت تصمیم گرفت با حرکت به بازار جدید با یک محصول جدید، از یک استراتژی متنوع سازی استفاده کند.آن‌ها بازاری که خدمات آن کماکان آفلاین بود را مورد هدف قرار دادند و می‌خواستند تجربه کار آنلاین را به آن بازار بدهند. محصول نیاز به اختصاصی سازی داشت و نیاز به مراجعه به یک متخصص هم وجود داشت. با این حال چشم انداز خوب و در حال تکامل بود. پیشرفت‌های تکنولوژیکی شروع به رفع نیاز به بازدیدهای حضوری می‌کرد. امکان انجام فرآیند سفارشی سازی از راه دور با استفاده از یک برنامه تلفن همراه وجود داشت. هنوز سطح بالایی از پیچیدگی در ایجاد مدل کسب و کار چند بازاری جدید وجود داشت و نیاز فوری به مدرن‌سازی معماری احساس می‌شد. هم افزایی‌هایی بین بازار جدید و قدیم، به ویژه در مورد گردش کار عملیاتی و نظارتی وجود داشت.رهبرِ حوزه جدید امیدوار بود از برخی از قابلیت‌های موجود استفاده کند تا مجبور به ساختن آن‌ها نباشند تا هزینه‌هایشان را کاهش داده و سریع‌تر وارد بازار شوند.معماری و روش‌های کاری موجود کاملاً حول یک مدل تجاری تک محوری طراحی شده بود. علاوه بر این، سیستم موجود به صورت محل با استفاده از فناوری‌های قدیمی اجرا می‌شد. شرکت یک رهبر تثبیت شده در حوزه کاری خود بود و تا این لحظه با فشار کمی برای مدرن کردن سیستم‌ها و روش‌های کار خود مواجه بود و در نتیجه دچار رکود شده بود. اما حالا نیاز فوری بود. این شرکت می خواست در بازار جدید نیز اولین باشد و به رهبر پیشرو در بازار تبدیل شود و موفقیت خود را تکرار کند.تولید طرح توجیهی مدرن‌سازی معماری کاری پیچیده بود. تشخیص اینکه در حال حاضر در چه شرایطی بودند، برای ورود به بازار جدید چقدر تغییرات مورد نیاز بود و هزینه مدرن‌سازی معماری و انجام تغییرات چقدر بود نیاز به داشتن اطلاعات بسیار دقیق و جزئی داشت. یکی از کارهای پیچیده تعیین بخش‌های مشترک برای ارائه خدمات در هر دو حوزه بود. در این شرایط هم باید نرم‌افزار برای بخش‌های مشترک تعیین می‌شد هم اینکه چقدر کارکنان این بخش می‌توانند به صورت مشترک خدمات ارائه کنند. پیچیدگی های فنی بسیار زیاد بود و بحث گروها‌های مختلف در شرکت در مورد انتقال به فضای ابری یا ماندن در شرایط فعلی و نصب و راه اندازی محلی، موجب نا‌امیدی رهبران شد. باز بحث این به میان آمد که توسعه دهنده‌ها از OCD رنج می‌برند و فقط می‌خواهند همه چیز را باز نویسی کنند.ارتباط برقرار کردن بین همه‌ی آن چالش‌هایی که به ارث رسیده بود با چشم انداز مدل کسب و کار که می‌خواست در حوزه‌ها و بازارهای مختلف به فعالیت ادامه دهد کاری بود که به زمان و پشتکار زیادی نیاز داشت.4. ساختار یک پیشنهاد قانع کننده:ایده‌ی خوب داشتن و با همکاران نزدیک خود در مورد آن صحبت کردن خوب است، اما برای برداشتن گام بعدی کسب و کار باید قانع شود از مدرن سازی حمایت کند که برای این کار نیاز به توانیی ایجاد یک پیشنهاد ساختار یافته و قانع کننده وجود دارد. من با رهبرانی کار کرده‌ام که دوست دارند ایده‌های خود را در قالب‌های مختلف ساختاردهی و مطرح کنند. من متوجه شده ام که هیچ رویکرد کاملی وجود ندارد، توانایی یک رهبر برای ایجاد و برقراری ارتباط به اندازه محتوای پیشنهادات مهم است. اگر از در ساختن و برقراری ارتباط و ارائه پیشنهادات مهارت دارید، از این بخش صرفنظر کنید.4.1. نمونه‌ای از ساختار پروپوزال:این بخش یک ساختار پیش‌فرض برای پیشنهادات شما را مشخص می‌کند. این ساختار قالبی است که من برای طرح‌های کوچک‌ بین 3 تا 6 ماهه استفاده می‌کنم، مانند زمانی که یک ابتکار نوسازی را با شناسایی اولین تکه مدرن‌سازی شروع می‌کنم. در قسمت‌های آینده استراتژی و نقشه راه برنامه ریزی و پیشنهادات در مقیاس بزرگتر را پوشش خواهم داد.هیچ الزامی برای پیروی از این ساختار وجود ندارد. شما می توانید آن را بر اساس نیازهای یا ترجیحات شخصی خود سفارشی کنید یا فقط بخش های خاصی را مورد استفاده قرار دهید.4.1.1. چشم انداز/اهداف/موضوعات تجاری سطح بالا:مثال زیر را در نظر بگیرید: شرکت به دنبال دوبرابر کردن درآمد در عرض 5 سال است و هزینه‌های پشتیبانی از مشتری‌ را 40 درصد کاهش دهد.هدف این بخش، نشان دادن درک اولویت‌های اصلی در سراسر سازمان یا واحد تجاری به عنوان یک کل است. سپس می توان پیشنهادهای بعدی را به این خواسته‌های سطح بالا مرتبط کرد.4.1.2. سهم دامنه از دیدگاه کسب و کار:در این بخش هدف این است که نشان داده شود چگونه محصول یا دامنه‌ مطابق با چشم انداز شرکت و مدل کسب و کار سطح بالاتر است. به مثال زیر توجه کنید:دامنه‌ی مدیریت مشتریان فرصتی را در اختیار ما قرار می‌دهد تا از توانمندی‌های درون سازمانی برای جلب رضایت مشتریان به صورت بهینه استفاده کنیم و از این طریق رشد قابل توجهی در عملکرد و کاهش خوبی در هزینه‌ها ایجاد کنیم.4.1.3. اصول فنی و سازمانی:مثال: ما متعهد به بهبود زمان عرضه به بازار برای محصولات خود هستیم. هدف ما این است که به‌جای نسخه گذاری فصلی، روزانه بتوانیم با کیفیت و اعتماد بالا به نسخه‌گذاری بپردازیم. هدف این بخش بیان بهبودهای مدل عملیاتی است که سازمان در تلاش برای دستیابی به آن است، مثل اتخاذ الگوهای فنی یا روش‌های کاری خاص. سپس این پیشنهاد می تواند چگونگی همکاری برای دستیابی به این خواسته‌ها و همچنین اهداف استراتژیک را مشخص کند.4.1.4. مجموعه ای از فرصت ها در دامنه خاص:در این قسمت لیستی از فعالیت‌هایی که قابلیت سرمایه‌گذاری دارند، همراه با مزایا و معایب هر عضو از لیست، به زبان کسب و کار بیان می‌شود. با این لیست نشان می‌دهید که واقعا در مورد کل فراید و کسب و کار اندیشه کرده‌اید و صرفا اولین ایده را به عنوان بهترین پیشنهاد روی میز قرار نداده‌اید.4.1.5. اقدامات پیشنهادی:در این قسمت، با استدلال‌های کسب و کاری بیان می‌کنید که، فارغ انتخاب‌هایی که در قسمت قبل وجود دارد، اقدام منتخب یا پیشنهادی شما چیست؟4.1.6. تغییرات معماری:در این قسمت طرحی از راه‌حلی که قصد دارید آن را پیاده‌سازی کنید، ارائه می‌کنید. نیازی به ارائه جزئیات دقیق نیست، به اندازه‌ای که مطمئن شوید تصمیم‌گیرندگان اصلی داده‌ی مورد نیاز برای تصمیم‌گیری را به دست می‌آورند کفایت می‌کند.4.1.7. بیان خواسته‌ها:نیازمندی‌های خود برای به ثمر رساندن کار را در این قسمت بیان می‌کنید. زمان، افراد، پول، محدودیت‌ها و سایر سرمایه‌گذاری‌هایی که برای اجرای موفقیت‌آمیز اقدامات خود نیاز دارید را بیان کنید. مثلا قید کنید که چه بودجه‌ای برای استخدام یک تیم و تضمینی که آن‌ها 100٪ به این کار اختصاص خواهند یافت نیاز دارید.4.1.8. سوالات برجسته، ناشناخته ها و خطرات:به هر حال در هر کاری عدم قطعیت وجود دارد. در این قسمت لیستی از سؤالات، ناشناخته‌ها و خطراتی که نشان دهنده‌ی سطح عدم قطعیت است و ممکن است کار اضافی ایجاد شود را قرار می‌دهید.4.1.9. جدول زمان‌ بندی:در این قسمت یک نمای کلی و سطح بالا از نقاط عطف، فعالیت‌ها و رویدادها مسیر نمایش داده خواهد شد. این جدول ممکن است شامل انواع رویدادها مانند تاریخ تحویل، تغییرات تیم، استخدام، کارگاه‌ها و هماهنگی مورد نیاز با سایر جریان‌های کار باشد. در این بخش تلاش می‌شودنسبت به ارائه دهندگان پروپوزال اطمینان ایجاد شده تا افرادی که پیشنهاد را بررسی می کنند بدانند که اقدامات به درستی مورد بررسی قرار گرفته‌اند.4.2. ارزش، بهتر، زودتر، ایمن‌تر، شادتر:یکی دیگر از ابزارهای ساده و موثر برای ساختن ارائه‌های متقاعد کننده،استفاده از ارزش بهتر، زودتر ایمن تر، شادتر یا (Better Value Sooner Safer Happier - BVSSH) است. نمونه‌ای از این ارائه را در زیر مشاهده می‌کنیدارزش بهتر زودتر ایمن تر شادتر. منبع: اسمارت و همکاران، زودتر ایمن تر شادتر: ضدالگوها و الگوهای چابکی تجاری (پورتلند، OR: IT Revolution 2020)بهتر - Better: نشان دهنده‌ی بهبود کیفیت و در نتیجه بهبود کارایی و کاهش زمان صرف شده با حذف دوباره کاری‌ها است.ارزش - Value: نشان دهنده‌ی نتایج کسب و کار مانند بهبود درآمد یا حفظ مشتری است.زودتر - Sooner: نشان دهنده‌ی بهبودهای زمان عرضه به بازار مانند توانایی ارائه سریعتر ویژگی‌های جدید است.امن‌تر - safer: نشان دهنده‌ی عواملی مانند حاکمیت، ریسک، انطباق، امنیت استشادتر - Happier: نشان دهنده‌ی بهبود زندگی افراد درگیر است، مانند شادتر کردن کارکنان در محل کار به دلیل ابزار بهتر.این مدل کمک می‌کند مزایایی که اقدامات شما ایجاد می‌کند را متوجه شوید و از آن مهم‌تر تعادل بین بخش‌های مختلف را درک کنید. مثلا می‌توان فهمید بین ایجاد ویژگی‌های جدید یا پاسخ به بدهی‌های فنی که موجب بهبود سرعت ارائه‌ی ویژگی‌های جدید می‌شود تعادل وجود دارد یا خیر. پرداختن به هر یک از نگرانی‌ها و نشان دادن اینکه چگونه آن‌ها به دقت متعادل شده‌اند، احتمال بیشتری برای همراهیِ همه‌ی سهامداران کلیدی با تصمیمات شما را ایجاد می‌کند.با چنین ارائه‌ای آن‌ها نگران این که آنچه برای آنها مهم است نادیده گرفته شده است، نخواهند بود.5. جمع‌بندی:در این قسمت در مورد داده‌هایی صحبت کردیم که برای شروع فرایند مدرن‌سازی و قانع کردن رهبران سازمان‌ها به آن‌ها نیاز داریم و در انتها نیز در مورد چگونگی ارائه آن‌ها گفتگو کردیم. در قسمت‌های بعدی مورد اینکه چگونه باید اطلاعات را با برخی جلسات و ورکشاپ‌ها جمع‌آوری کنیم گفتگو خواهیم کرد. علیرضا ارومند علیرضا ارومند Sat, 03 Jun 2023 21:36:42 +0330 https://virgool.io/dotin/%D8%A2%D9%85%D8%A7%D8%AF%DA%AF%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B3%D9%81%D8%B1-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-i0hvjdmwefqg می‌خواهیم خود را برای مدرن‌سازی معماری آماده کنیم. موارد بسیاری است که باید برای آن‌ها مهیا باشیم. در قسمت قبل با برخی موارد و باید‌ها و نبایدها آشنا شدیم و در این قسمت می‌خواهیم مباحث خود را ادامه دهیم. با توجه به وابستگی بین مطالب، پیشنهاد می‌کنم حتما پیش از شروع مطالعه این مطلب، بخش اول را مطالعه کنید. https://virgool.io/@ar.oroumand/%D8%A2%D9%85%D8%A7%D8%AF%DA%AF%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B3%D9%81%D8%B1-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-gtscjsvx8o5x 1. مثال واقعی:مثالی که در ادامه مشاهده خواهید کرد مربوط به شرکت ICE است که توسط آقای Kacper Gunia به تالیف رسیده است. روش‌ها و تکنیک‌هایی را در این مثال مشاهده خواهید کرد به در آینده به هرکدام از آن‌ها به صورت مجزا خواهیم پرداخت.نام ICE سرنام International Copyright Enterprise Services است که به عنوان یک ارائه‌دهنده‌ پیشرو در خدمات پردازش حق امتیاز و کپی رایت در صنعت موسیقی فعالیت می‌کند. اما ICE با موانعی در سیستم‌ها و زیرساخت‌های فناوری اطلاعات روبرو بود. در دنیای جدید پخش آنلاین موسیقی و کسب‌وکارهای مربوط به آن به‌طور قابل ملاحظه‌ای زیاد شد و این افزایش حجم داده‌ها موجب کند شدن فرایند پردازش آن‌ها شد. در کنار این افزایش حجم درخواست، کسب‌وکار با مشکل دیگری نیز مواجه بود. در فرایند‌ها و معماری قدیمی بخش زیادی از کار به‌صورت دستی انجام می‌شد، این موضوع موجب افزایش ریسک ایجاد خطا و پیچیدگی بیش از حد در فرایند‌های کاری بود. در چنین شرایطی، هنگامی که ویژگی‌ جدیدی درخواست می‌شد، فرایند کاری در پروژه‌ای مستقل انجام می‌پذیرفت. ادامه این فرایند موجب شد ترویج شیوه‌های مهندسی مدرن و توسعه پایدار دشوار شود. با توجه به این شرایط و اینکه ICE می‌خواست جایگاه خود را در بازار رقابتی حفظ کند، در سال 2020 سفر مدرن‌سازی معماری شروع شد. هدف ICE این بود درحالی‌که به سوی یک رویکردِ محصول‌محور (Product Centric) حرکت می‌کند، سرعت، دقت و مقیاس‌پذیری سیستم‌های فناوری اطلاعات را نیز افزایش دهد.در ابتدای سفر مدرن‌سازی و برای اصلاح زیرساخت IT پردازش حق امتیاز، از روش های استراتژیک مختلفی استفاده کردیم. از Domain-Driven Design (DDD) و Event Storming به‌عنوان ابزارهایی برای درک دامنه و رفتارهای خاص آن استفاده کردیم. در طول جلسات Big Picture Event Storming، ما روی ثبت روابط و تعاملات بین ذی‌نفعان مختلف، سیستم‌ها و رویدادهایی که در دامنه‌ پردازش حق امتیاز اتفاق می‌افتند، تمرکز کردیم. جلسات شامل مخاطبان وسیعی بود تا از دیدگاه‌ها و دانش‌های مختلف که در این دامنه وجود دارد مطلع شویم، زیرا می‌خواستیم یک دید کلی جامع از حوزه کسب‌وکار به‌دست آوریم.پس از اینکه دیدگاه کلی از کار به دست آوردیم، جلساتی را با گروه‌های کوچکتر و مرتبط‌تر در حوزه‌های مختلف با افراد آن حوزه برگزار کردیم تا دانش خود را در آن حوزه‌ها عمیق‌تر کنیم. هر یک از این جلسات بر یک زیر دامنه جداگانه متمرکز بود که منجر به بحث و تبادل نظر عمیق‌تر می‌شد و حاصل این بحث‌ها این بود که در پایان به درک مشترکی از مشکل می‌رسیدیم. این رویکرد، ما را قادر ساخت تا رویدادهای مهم تجاری، رفتارهای آن‌ها و قوانین تجاری‌ای که سیستم در آن راستا کار می‌کرد را مشخص کنیم. با این دانش دوباره کشف شده، ما یک مدل فرایند سطح بالا ساختیم که به ما کمک کرد مشکل موجود را درک کنیم و یک زبان مشترک برای برقراری ارتباط موثر با سهامداران خود ایجاد کنیم.در ادامه فرایند، مهاجرتِ تدریجی را با استفاده از الگوی Strangler برنامه‌ریزی کردیم. ما قابلیت این رویکرد را با نمونه‌سازی (prototyping) در اولین زیر دامنه ثابت کنیم. ما نمونه‌ی اولیه را برای نشان دادن مزایای معماری جدید و جلب رضایت سهامداران مورد استفاده قرار دادیم. در ادامه روی یک طرح تجاری کار کردیم که ارزش‌های مورد علاقه سهامداران را به‌صورتی تدریجی و تکاملی ارائه کردیم. در این روش به‌جای اینکه کسب‌وکار، مدت زیادی منتظر مشاهده‌ خروجی باشد و خروجی، ناگهان و به‌صورت Big Bang ارائه شود، ارزش را به‌صورت تدریجی ارائه کردیم. این روش به ما کمک کرد تا طرحی ایجاد کنیم که ارزش را در بخش‌های کوچک‌تر و مداوم ارائه کنیم و توانستیم از این جریان ارزش، برای توجیه بودجه‌ بیشتر برای مهاجرتِ مداوم استفاده کنیم. ما شروع به تقویت تیم کردیم و طبقه‌بندیِ محصولات را که شامل دامنه‌ها، زیر دامنه‌ها و محصولات و همچنین قابلیت‌های این محصولات و تیم‌های مسئول آن‌ها بود را تعریف کردیم.مهاجرت از ساختار مبتنی بر تکنولوژی به ساختار مبتنی بر دامنهما شروع به پیاده‌سازیِ روش‌های جدید کاری در تیم‌های توسعه کردیم. ما روال‎‌های یکپارچه‌سازی مستمر/استقرار مستمر (CI/CD) و زیرساخت به‌‌عنوان کد (Infrastructure as a code) را مورد استفاده قرار دادیم.با این کار ما توانستیم به‌طور خودکار تغییرات کد را چندین بار در روز Build، تست کنیم و در نهایت به جریان کاری منتقل کنیم. علاوه بر این، ما شروع به استفاده از Pair Programming کردیم که این روش منجر به افزایش اشتراک دانش و همکاری در تیم‌ها شد. همچنین ما مطمئن شدیم که تیم‌های توسعه و کسب‌وکار از نزدیک با هم همکاری می‌کنند و این موضوع موجب افزایش درک همه از محصولات شد و قدرت کسب‌وکاری را ارتقا بخشید. با ادامه کار به این روش، توانایی ما در گسترش تیم بیشتر شد و توانستیم تیم‌های بیشتری تشکیل دهیم و سازمان خود را تبدیل به سازمانی کنیم که با نقشه‌ راه محصول به‌صورت فصلی و سالانه کار می‌کند و ارزش‌هایی را به‌صورت مکرر و با افزایش‌های کوچک ارائه می‌دهد.مدرن‌سازی، منجر به پیشرفت‌های چشمگیری شد. یکی از قابل توجه‌ترین پیشرفت‌هایی که به‌دست آوردیم کاهشِ 80 درصدیِ زمان پردازش داده‌ها بود که به‌طور قابل توجهی توانایی سازمان را برای مدیریت حجم زیادی از داده‌ها بهبود بخشید. علاوه بر این، ما توانستیم زمان ورود ارائه‌دهندگان خدمات جدید را از ماه‌ها به هفته‌ها کاهش دهیم که باعث افزایش چابکی و قدرت رقابتیِ سازمان شد. همچنین سیستم‌های قدیمی را در عرض یک سال و نیم جایگزین کردیم و سامانه‌های قدیمی را از رده خارج کردیم که این کار نیز پیچیدگیِ زیرساخت‌های فناوری اطلاعات سازمان را به میزان قابل توجهی کاهش داد.یکی دیگر از نتایج کلیدی، بهبود در فرایندهای تطبیقِ دستی بود. این بهبود، امکان اولویت‌بندیِ دقیق‌تری در کار را فراهم کرد و منجر به افزایش 5 برابری در بهره‌وری و افزایش نرخ تطابق به میزان 5 درصد شد. علاوه بر این، ما قابلیتی جدید ایجاد که کردیم که قابلیت شنیدنِ کامل ِشاخص‌های تطبیق بود، افزودن این ویژگی به اعتمادسازی برای مشتریان کمک بزرگی کرد. علاوه بر این، بخش اصلی پلتفرم که مسئول محاسبه‌ حق امتیاز بود شروع به مدرنیزه شدن کرد. مدرن‌سازی در این قسمت یعنی ما می‌توانستیم حق امتیاز را سریع‌تر و دقیق‌تر محاسبه کنیم. به‌طور کلی در سازمان ما، تلاش برای نوسازی تاکنون موفقیتی بزرگ بود است، زیرا طیف وسیعی از مزایا را به همراه داشت که عملکرد و توانایی رقابت برای سازمان را بهبود بخشید.علاوه بر بهبودهایی که از جنبه‌های تجاری رخ داد، اتفاقات و بهبودهای دیگری نیز به دست آمد. ما از خدمات ابری برای به حداقل رساندن سربار عملیاتی و بهینه‌سازی هزینه‌ها استفاده کردیم. با استفاده از خدمات ابری، ما توانستیم به‌صورت خودکار مقیاس سیستم را تغییر دهیم. این مقیاس‌پذیری خودکار، به ما امکان داد منابع را به‌صورت پویا و بر اساس تقاضای سیستم در لحظه تخصیص دهیم، در نتیجه هزینه‌ها را کاهش داده و کارایی را بهبود بخشیدیم. به‌علاوه، زیرساخت‌های ابری و خاصیت مقیاس‌پذیری که داشتند به ما این امکان را دادند که به‌راحتی خود را با حجم روز‌افزون از جریان موسیقی آنلاین تطبیق دهیم. با استفاده از خدمات ابری، توانستیم سربار عملیاتی را به حداقل برسانیم، هزینه‌ها را بهینه کنیم و اطمینان حاصل کنیم که سیستم‌ها و زیرساخت‌های فناوری اطلاعات ما می‌توانند از نیازهای تجاری رو به رشد ما پشتیبانی کنند.مدرن‌سازی، بینش‌های ارزشمندی را در مورد اهمیت درک دامنه به ما داد و فهمیدیم که مالکیت تیم‎‌ها در یک حوزه کاری و جریان ارزش چقدر به بهبود فرایند‌ها و توانمندسازی تیم‌ها کمک می‌کند. با توانمندسازی تیم‌ها برای درک دامنه، حلقه‌های بازخورد را تا حد زیادی کاهش دادیم و کیفیت کلی کار و راه‌حل‌هایی که ارائه می‌کردیم را بهبود بخشیدیم. از آنجایی که تیم‌ها قابلیت خودسازماندهی دارند و دارای عملکرد متقابل هستند، مسئولیت کامل طراحی، توسعه، آزمایش، استقرار و اجرای برنامه را بر عهده داشتند که آنها را تشویق کرد تا بهترین کار ممکن را انجام دهند. مدرن‌سازی باعث شد ما از مدل پروژه‌محور به محصول‌محور تغییر حالت دهیم و به این روش به جای تمرکز روی تخمین و ... روی ارائه‌ ارزش متمرکز شویم و این نیز یکی دیگر از مزایای مدرن‎‌سازی برای ما بود.همه‌ مسیر مدرن‌سازی برای ما به سادگی پیمایش نشد. ما با چالش‌های زیادی مواجه شدیم. از مهم‌ترین چالش‌هایی که با آن سر و کار داشتیم، زمانی بود که کار به تغییر در شرایطِ اجتماعی می‌رسید. مثلا یافتنِ راه‌هایی برای ادغام و همکاری بین تیم‌های موجود و به سرانجام رساندن این ادغام و تغییرات به‌صورت موفقت‌آمیز. تیم‌هایی که به‌صورت پروژه‌محور کار می‌کردند هنگامی که دچار دگرگونی در ساختار می‌شدند و قرار می‌شد به‌صورت محصول‌محور کار کنند تغییرات بسیاری را متحمل می‌شدند. مسائل بسیاری در فرایندهای کاری جدید به‌صورت محصول‌محور متفاوت بود. مثلا رویکردهای متفاوت برای تخمین، طراحی، توسعه و آزمایش محصول ایجاد شد و حلقه‌های بازخورد متفاوتی نسبت به قبل نیز ایجاد شد و این تغییرات بعضا منجر به چالش‌های اساسی در کار می‌شد. بر اساس تجربه‌ای که به‌دست آوردیم، توصیه می‌کنم سازمان‌ها به جنبه‌های اجتماعی در تلاش‌هایی که برای نوسازی دارند بسیار توجه کنند، زیرا این جنبه‌ها نیز به اندازه‌ جنبه‌های فنی مهم هستند.کار مدرن‌سازی برای ما به پایان نرسیده است. درحالی‌که موفقت‌های بزرگی را با تلاشی که برای مدرن سازی انجام دادیم به‌دست آوردیم، اما چندین زیردامنه باقی مانده که باید مدرن‌سازی شوند. مدرن‌سازی و این تلاش، چند سال دیگر برای ما طول خواهد کشید. داشتن یک طبقه‌بندیِ محصول که به خوبی تعریف شده تاکنون در پیشرفت ما موثر بوده است.ما بدون طبقه‌بندی محصول مناسب، نمی‌توانستیم تیم‌های مستقلی ایجاد کنیم که به‌طور مداوم ارزش ارائه دهند. همان‌طور که به نوسازیِ سازمان ادامه می‌دهیم، قصد داریم این مدل از همسوییِ تیم‌ها با زیر دامنه‌ها و محصولات را در کل سازمان پیاده‌سازی کنیم. این کار تضمین می‌کند که تلاش‌های نوسازی و مزایای آن به‌طور کامل تحقق یابد و ICE در صنعتی که همیشه در حال توسعه و کاملا رقابتی است، باقی خواهد ماند.2. شناسایی امکان تغییر عمیق:به‌دست آوردن حداکثر ارزش، از معماری مدرن مستلزم اتخاذ شیوه‌هایی مدرن در تفکر، کار و همکاری است. فکر می‌کنید آیا تغییراتی عمیق از این دست در سازمان شما امکان‌پذیر است؟ یا احساس می‌کنید این ریسک وجود دارد در نهایت به سراغ تغییراتی کم عمق بروید؟ مثلا ممکن است فکر کنید در نهایت کمی ساختار سازمانی تغییر می‌کند یا برنامه‌های موجود صرفا بازنویسی می‌شوند درحالی‌که ایرادات گذشته در آن‌ها وجود دارد. اگر این ریسک را احساس می‌کنید که در نهایت، صرفا تغییراتی کم‌عمق خواهید داشت، باید برای مرتفع کردن این ریسک از همه‌ افراد کمک بگیرید. افرادی مانند رهبران ارشد، مدیران میانی و مشارکت‌کنندگانِ عادی که در فرایند مدرن‌سازی تاثیرگذار خواهند بود. در بسیاری موارد مشاهده شده که افراد متوجه نمی‌شوند که تغییر برای آن‌ها هم اتفاق خواهد افتاد، بنابراین ایجادِ روابط و گفت‌وگوهای صادقانه در ابتدای راه، می‌تواند آن‌ها را آگاه کرده و به ایشان زمان دهد تا خود را تطبیق دهند و برای اتفاقات و تغییرات آ‌ینده آماده شوند.2.1. اجتناب از ساختار و فرایند اشتباه:در برخی موارد مشاهده می‌شود که دیدگاه‌ها نسبت به سازمان بسیار مکانیکی است. آنها دوست دارند از استعاره‌های کارخانه‌ای استفاده کنند. مشکل از جایی شروع می‌شود که عوامل انسانی نادیده گرفته شده و در نتیجه انتظارات غیرواقعی می‌شود و فرصت‌ها از دست می‌رود. شرکت‌های متعددی بارها از من خواسته‌اند که در قالب یک ورکشاپ به آن‌ها کمک کنم تا ساختار سازمانی بهینه‌ خود را شناسایی کنند و سازماندهی مجددی به کمک این ساختار بهینه انجام دهند تا همه مشکلات آن‌ها حل شود. این یک ضد الگو است که با عنوان ساختار و فرایند اشتباه ( The Structure and Process Fallacy) شناخته می‌شود. تصور اینکه با تغییر در ساختار سازمانی یا اتخاذ یک فرایند جدید مثل فرایند‎های چابک، بدون ایجاد تغییرات عمیق‌تر مثل تغییر در طرز تفکر، عملکرد را تا حد زیادی بهبود می‌یابد، نادرست است. اگر کار برای بهبود عملکرد به همین سادگی بود که سازمان‌های زیادی تاکنون این کار را کرده بودند. برای افزایش واقعیِ سرعتِ توسعه، تغییرات جامعی مثل ترویج‌ِ کار تیمی، محول کردن تصمیماتِ مربوط به محصول به تیم‌ها، از بین بردن موانع کسب‌وکاری و فناوری اطلاعات، تغییر مدل‌های تامین مالی و سرمایه‌گذاری در کیفیت فنی مورد نیاز است. ساختار سازمانی و فرایندهای توسعه بسیار مهم هستند اما اعمال تغییرات در آن‌ها به‌ تنهایی بهبود محدودی را به همراه خواهد داشت. صحبت در مورد این موارد در ابتدای سفر مدرن‌سازی بسیار حیاتی است.2.2. پذیرش رویکردهای معماری مشترک:شناساییِ مرزهای دامنه‌ بهینه برای سازمان و توانایی در تکامل مداوم آن‌ها نیازمند یک رویکرد مشترک است. تکنیک‌های مدرن برای کشف دامنه و مدل‌سازی مانند EventStorming بر اساس ایده‌ همکاری طراحی شده‌اند، جایی که گروه‌های مختلف، گرد هم می‌آیند و دانش خود را در مورد دامنه به اشتراک می‌گذارند تا جزئیات و پیچیدگی‌های بیشتری را تا حد ممکن قابل مشاهده کنند. ترکیبی که از دانشِ همه به‌دست می‌آید و دیدن تصویری جامع، کلیدی برای تصمیم‌گیری بهتر است. اما به این نکته توجه داشته باشید که همه مایل به اتخاذ این نوع رویکردهای مشارکتی نیستند. برخی افراد، از شرکت در کارگاه‌های EventStorming خودداری می‌کنند، برخی دیگر شرکت کرده اما تلاشی نمی‌کنند و بدتر از همه آن‌هایی هستند که سعی می‌کنند جلسات را خراب کنند.دلایل متعددی برای عدم پذیرش این رویکرد‌های مشترک وجود دارد. یکی از رایج‌ترین دلایل، رهبرانی هستند که می‌خواهند قدرت و امنیت شغلی خود را حفظ کنند. شیوه‌های مشارکتی، در مورد به‌اشتراک گذاشتن دانش و مشارکت دادن همه در تصمیم‌گیری است که به‌طور مؤثر، ساختار‌های سلسله مراتبی را سمت ساختار‌های صاف (Flat) سوق می‌دهد. دلیل دیگر این است که برخی افراد ایده‌ همکاری را دوست ندارند. برخی از توسعه‌دهندگان دوست دارند سرشان را در لاک خود فرو برند و کدنویسی کنند. برخی دیگر نیز تصور می‌کنند، چسباندنِ برگه‌های یادداشتِ رنگی روی دیوار فقط یک سرگرمی جدید است و کار جدی از پیش نمی‌رود.برگزاری ورکشاپ‌ها، در اولین گام‌های مدرن‌سازی معماری یک ایده خوب است. با این کار شما یاد می‌گیرید چطور به‌صورت بهینه، کار تسهیل‌گری را در این جلسات انجام دهید و بفهمید در کدام قسمت‌ها اگر بخواهید در سازمان آن‌ها را به کار گیرید دچار چالش خواهید شد و مقاوت‌هایی وجود خواهد داشت. هرچند همه می‌دانیم که با چالش و مقاوت برای برگزاری این کارگاه‌ها مواجه می‌شویم اما اکثر افراد از شرکت در این جلسات لذت می‌برند و به شما کمک می‌کنند که کارگاه‌های موفقی داشته باشید.2.3. دور شدن از ساختارهای سیلویی در سازمان:به‌طور سنتی در سازمان‌ها، کسب‌وکار و فناوری اطلاعات واحد‌هایی مجزا در نظر گرفته می‌شوند که این عدم یکپارچگی نوآوری را محدود کرده و مانع دستیابی به اهداف مشترک می‌شود. جدایی این بخش‌ها جریان ارزش را کاهش داده و همچنین پیاده‌سازیِ ویژگی‌های جدید بیشتر طول می‌کشد. زیرا افرادی که در بخش فناوری‌اطلاعات هستند، واقعاً نمی‌دانند چه چیزی باید تولید کنند. دیدگاه صحیح این است که کسب‌وکار و فناوری اطلاعات دو روی یک سکه هستند.همان‌طور که در تصویر زیر مشاهده می‌کنید، جریان‌های ارزشِ مستقل شامل کسب‌وکار و فناوری اطلاعات هستند. تیم‌ها، برای دستیابی به نتایج کسب‌وکار هدایت می شوند و تصمیم می‌گیرند که چگونه به بهترین نحو به اهداف خود دست یابند. مهندسان، آزمایش‌کنندگان، مدیران محصول، طراحان تجربه کاربری، متخصصان حوزه‌های کسب‌وکاری و سایر نقش‌ها باید برای ساخت محصولات بهتر با جریانِ سریع‌ِ تغییرات، همکاری نزدیکی داشته باشند. چنین رویکردی یک تغییر بزرگ برای بسیاری از سازمان‌ها است و یک شبه اتفاق نخواهد افتاد، بنابراین مهم است که چشم‌اندازی برای اینکه به کجا می‌خواهید برسید ایجاد کنید، باید بدانید از هدف خود چقدر فاصله دارید و چگونه می‌توانید به تدریج در هر مرحله پیشرفت کرده و به هدف نزدیک شوید. جریان‌های ارزش مستقل، شاملِ کسب‌وکار و فناوری اطلاعات هستند2.4. سرمایه گذاری روی شیوه‌های با کیفیت فنی:بدهی‌های فنی و رفع آن‌ها یکی از مشکلات بزرگ در سازمان‌ها است. یک راهکار مناسب برای برخورد با بدهی‌های فنی این است که اصلا از ابتدا آن‌ها را ایجاد نکنیم. همه می‌دانیم که امکان سفر در زمان بازگشت به گذشته را نداریم، اما می‌توانیم برای حرکت‌های رو به جلو، روال‌های صحیحی در نظر بگیریم. بنابراین، هدف اصلی در سفر مدرن‌سازی، باید ارائه‌ یک معماری مدرن‌ باشد که سالم بماند و در آن بدهی‌های فنی انباشته نشده و در گذر زمان، نیاز نداشته باشد مجددا برای نوسازی سرمایه‌گذاری شود. برای رسیدن به این هدف، سرمایه‌گذاری روی روش‌های فنی صحیح بسیار حیاتی است. شیوه‌های فنی صحیح و پایدار تضمین می‌کند که کد به خوبی طراحی شده، قابل درک باشد، به سادگی تست شود و در نتیجه تغییرات در آن ساده بوده و با هزینه‌ نگهداری کمتر در طول عمر خود خدمات بدهد.من یکی از طرفداران Test Driven Development و pair/mob programming هستم. این تکنیک‌ها، رویِ طراحیِ نرم‌افزارهای با کیفیت و تست شده با استفاده از طراحی‌های دقیق و بازسازی (refactoring) مداوم تمرکز می‌کنند. هنگامی که در جست‌وجوی راه‌حل‌های ساده و قابل نگهداری برای پیاده‌سازی یک عملکرد جدید هستید، این تکنیک‌ها بسیار راهگشا هستند. ممکن است به نظر برسد استفاده از این تکنیک‌ها زمان زیادی می‌برد و موجب افزایش هزینه‌ها می‌شود، اما زمانی که به‌طور موثر از آن‌ها استفاده شود، متوجه می‌شویم که آنها در کوتاه‌مدت، میان‌مدت و به‌ویژه بلندمدت بازدهی عالی خواهند داشت. با این حال، مانند بسیاری از تکنیک‌های دیگر، این تکنیک‌ها نیز می‌توانند بسیار تفرقه‌انگیز باشند. همه‌ی تیم‌های برنامه‌نویسی TDD و pair/mob programming را دوست ندارند، بنابراین مهم است که آنچه را که برای شما مناسب‌تر است پیدا کنید.اگر سازمان شما تخصصی در این شیوه‌های فنی ندارد، پرداختن به این موضوع قبل شروع سفر مدرن‌سازی بسیار حیاتی است. قطعاً باید فرصت‌های آموزشی و ارتقای مهارت را برای تیم‌های خود فراهم کنید و ممکن است به کمک‌هایی از بیرون سازمان نیاز داشته باشید.3. اجتناب از مدرن‌سازی‌های سطحی:یکی از مشکلاتی که اغلب با آن مواجه شده‌ام، این است که بدون پرداختن به چالش‌های اساسی که در معماری وجود دارد تلاش می‌شود یک سیستم را مدرن کنند. مثلا ظاهر بیرونی یک برنامه را بازنویسی می‌کنند اما داخل برنامه کماکان کدهای بیات و دیتابیس‌های قدیمی در حال ارائه خدمات است. اگر بخواهم دقیق‌تر بگویم ظاهر مدرن شده روی شالوده‌ای از سیستم‌های قدیمی و کثیف به نمایش گذاشته می‌شود دقیقا مثل اینکه برای زیبا شدن یک شامپانزه از رژ لب استفاده کنیم. این رویکرد در ابتدای مسیر و برای نمایشِ یک دستاورد سریع به‌عنوان گامی گذرا قابل پذیرش است، اما نکته مهم، توجه به گذرا بودن این رویکرد است. در بسیاری از موارد مشاهده می‌شود که موقتی‌ بودن در نظر گرفته نشده و بهبود ظاهری در کار، هدف نهایی در نظر گرفته می‌‎شود و در پشت صحنه کماکان سامانه‌های قدیمی خدمات ارائه می‌ کنند و همچنان محدودیت‌های زیادی را به محصول تحمیل می‌کنند.چندین سال پیش و هنگام ایجاد یک سری سرویس‌های دولتی، ما به طور مستقیم با چنین مشکلاتی مواجه شدیم. تیم‌های ما خیلی سریع وبسایتی جدید ارائه دادند که تجربه‌ کاربری بسیار بهتری را نسبت به آنچه در گذشته وجود داشت ایجاد کرد، اما در ادامه ما نتوانستیم پیشرفت‌ها و تغییرات مورد درخواست کاربران را ارائه کنیم، زیرا در پشت صحنه، هنوز مجبور بودیم با سیستم‌ها و پایگاه‌های داده قدیمی کار کنیم. ما حتی نمی‌توانستیم یک Textbox برای دریافت اطلاعاتی خارج از آنچه در دیتابیس‌های قدیمی وجود داشت به صفحات خود اضافه کنیم و اگر می‌خواستیم داده‌ای را نمایش دهیم صرفا می‌توانستیم از اطلاعاتی که APIهای قدیمی ارائه می‌دادند، استفاد کنیم.مشکل دیگری که بعضا در سازمان‌ها مشاهده می‌شود این است که، آن‌ها فکر می‌کنند با خرید چند ابزار آماده، مثل Rule Engineها می‌توانند به افرادی که در بخش کسب وکار مشغول هستند این امکان را بدهند که بدون وابستگی به برنامه‌نویس‌ها، هر تغییری که نیاز دارند به سرعت ایجاد کنند. هر چند در مواردی ممکن است که چنین ابزارهایی با هزینه‌های کم و کیفیت قابل قبول مشکلاتی را از سر راه سازمان بردارند، اما اگر این ابزارها برای رفع بحران‌ها تهیه شوند و جایگزینی برای رفع بدهی‌های فنی در نظر گرفته شوند، قطعا دچار دیدگاهی کوته‌بینانه شده‌ایم.هنگام آماده شدن برای یک سفر مدرن‌سازی، مهم است بدانیم که رهبران به دنبال چه چیزی هستند. اگر نشانه‌هایی مانند آنچه در این قسمت بیان کردم مشاهده کردید، ممکن است با مشکلاتی اساسی‌تر مواجه باشید. مشکل اصلی در این شرایط این است که رهبران به دنبال راه‌حل‌های سریع هستند و مقدار سرمایه‌گذاریِ مورد نیاز برای رسیدگی واقعی به برخی از چالش‌های اصلی نوسازی سازمان را درک نمی‌کنند. اگر به چنین شرایطی مشکوک هستید، پس باید به گفت‌وگو‌های طولانی و صادقانه در مورد مدرن‌سازی با رهبران بپردازید و صرفا امیدوار نباشید که شکی که در شما ایجاد شده به یقین تبدیل نشده و همه چیز درست پیش خواهد رفت. خوب است تصویری از برخی از پیچیده‌ترین چالش‌های مدرن‌سازی داشته باشید و درباره آن‌ها با تصمیم‌گیرندگان صحبت کنید تا مقدار سرمایه‌گذاری واقعی و ضروری را درک کنند.4. توسعه‌ رهبران در تمامی سطوح:مدرن‌سازی یک سفر طولانی است که در طول آن باید تصمیمات مهم زیادی گرفته شود و لحظات چالش برانگیزی وجود دارد که باید با آن‌ها مواجه شویم. داشتن رهبر و الگو در همه سطوح، از اتاق هیئت‌مدیره گرفته تا تیم‌هایی برنامه‌نویسی ضروری است. الگوها و رهبرانِ مدرن‌سازی وظایف زیادی دارند، از جمله:درک استراتژی‌های کسب‌وکار و کمک در پیش‌برد آن‎‌هاتعریف استراتژی نوسازیطراحی و توسعه‌ معماریراه‌اندازیِ ساختار سازمانی برای توسعه‌ معماریبرقراری ارتباط بین چشم‌انداز و پیشرفتتصمیم در مورد تولید یک محصول یا خرید آنتعیین پاداش و مشوق‌هایی که رفتارهای مطلوب را تشویق می‌کندایجاد امکانِ ادامه‌ فرایند‌های کسب‌وکاری به‌طور عادی در حالی که به‌طور همزمان نوسازی انجام می‌شوداطمینان از درگیر شدنِ کاملِ تیم‌های مهندسی در حوزه کسب‌وکارشکل دادن به فرهنگ مهندسیمدیریت افراد و توسعه آن‎‌هامعرفی شیوه‌های فنی مدرن و تیم‌های مربی‌گریالقای مداوم روش‌های جدید تفکر و کار با این همه وظایفی که مشاهده‌ می‌کنید، پیمودن مسیر در سفر مدرن‌سازی صرفا با یک ابر قهرمان یا گروهی کوچک از رهبران امکان‌پذیر نیست. قبل از شروع سفر مدرن‌سازی، خوب است که به این لیست و هر مسئولیت دیگری که انتظار دارید با آن‌ها سر و کار داشته باشید، نگاهی بیندازید. سپس مشخص کنید که کدامیک از رهبران قادر خواهند بود هر کدام از این مسئولیت‌ها را بر عهده گرفته و کمبود‌ها را شناسایی کنید. علاوه بر این، باید به این فکر کنید که این افراد چگونه با یکدیگر همکاری خواهند کرد تا به‌طور گروهی همه‌ فرایندها و ابتکارات برای مدرن‌سازی در سراسر کسب‌وکار را رهبری کنند.بسته به اینکه سازمان شما از کجا شروع می‌کند، احتمالاً از روز اول همه‌ این افراد کاملاً خبره نخواهند بود. این بدان معناست که برای رسیدن به هدف خود، به یک راه‌حل کوتاه‌مدت و یک برنامه بلند‌مدت نیاز دارید. این هدف یک تیم توانمند‌سازِ نوسازی معماری یا Architecture Modernization Enabling Team (AMET)(AMET) است.تا اینجا توضیح داده شد که چرا به رهبران در تمامی سطوح نیاز داریم، اما رهبران در تمامی سطوح به چه معناست؟ برای درک اینکه رهبری در همه سطوح به چه معناست، بسته به اندازه و نوع سازمان شما، فهرستی از افرادی که ممکن است نیاز به ایفای نقش رهبری در نوسازی معماری داشته باشند در زیر آمده و توجه کنید که این لیست صرفا برای مثال بوده و غیرجامع است:مدیر فنی (CTO)معمار ارشد نرم‌افزارمعمار نرم‌افزارمدیران ستادیمعمار سازمانیمعمار دادهمعاون فنی و مهندسی...5. جمع‌‌بندی:در دو پست اخیر در مورد آمادگی برای فرایند مدرن‌سازی معماری صحبت کردیم. آماده شدن برای سفر مدرن‌سازی به شما کمک می‌کند تا از مشکلات احتمالی در مسیر مطلع بود و در صورت بروز برای آن‌ها آماده باشید. اکنون می‌دانیم جلب حمایت رهبران و تعیین تعهداتی که برای آن‌های ایجاد می‌شود، از مهم‌ترین کارهایی است که باید پیش از آغاز فرایند مدرن‌سازی به آن بپردازیم. در این قسمت متوجه شدیم جدا دانستن فرایند‌های کسب‌و‌کاری و بخش‌های آن از فناوری اطلاعات چیزی نیست که این روزهای پاسخگوی نیازهای روز باشد و باید قبل از برداشتن اولین گام‌ها تصویری واضح و چشم‌اندازهایی قابل درک برای همه افراد ایجاد کنیم و به همان اندازه که برای مسائل فنی زمان می‌گذاریم باید برای فرایند‌های اجتماعی و فردی هزینه و زمان در نظر بگیریم. علیرضا ارومند علیرضا ارومند Wed, 17 May 2023 16:01:32 +0330 https://virgool.io/@ar.oroumand/%D8%A2%D9%85%D8%A7%D8%AF%DA%AF%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B3%D9%81%D8%B1-%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-gtscjsvx8o5x 1. مقدمه:پیش از شروع هر سفری، باید به چالش‌ها و مشکلاتی که ممکن است با آن‌ها مواجه شوید! فکر کرده و برای آن‌ها آماده شوید.مثلا اگر در رشت زندگی می‌کنید و می‌خواهید به پیکنیک بروید، باید هر لحظه خود را برای بارش باران آماده کنید و برای آن چاره‌ای داشته باشید. حتی اگر بخواهید در یک روز گرم تابستان و سر ظهر که خورشید وسط آسمان است به این پیکنیک بروید باز هم احتمال اینکه هوا بارانی شود وجود دارد.یا اگر بچه کوچکی دارید و می‌خواهید به مهمانی بروید باید هر لحظه آمادگی این را داشته باشید که بدون هیچ دلیل مشخصی نوزاد شروع به گریه کند و هیچ اتفاقی باعث آرام شدن او نشود و ناچار باشید مهمانی را ترک کنید و به محض سوار شدن بر خودرو کودک آرام شود. سفر مدرن‌سازی معماری نیز از این قاعده مستثنا نیست. اگر ذینفعان کلیدی، آمادگیِ تغییر در نحوه‌ی تفکر، کار و اتخاذ تصمیمات دشوار را نداشته باشند، شکست و نا‌امیدی تنها سرنوشتی است که به آن دچار خواهید شد.در این قسمت قصد داریم در مورد چالش‌هایی که اغلب تیم‌ها هنگام مدرن‌سازی معماری با آن مواجه می‌شوند صحبت کنیم. چالش‌هایی که امروز در مودر آن‌ها صحبت می‌کنیم، معمولاً نیازمند تغییر در طرز فکر هستند و اگر به موقع و صحیح به آن‌ها رسیدگی نشود، باعث ایجاد مشکلاتی شده و حتی می‌توانند به طور کامل باعث شکست طرح‌های نوسازی شوند. از آنجایی که مدرن سازی، ذاتاً موضوعات و بخش‌های زیادی را در سازمان‌ها دستخوش تغییر می‌کند، این چالش‌ها نیز حوزه‌های مختلفی مانند کسب‌وکار، محصول، فناوری، فرهنگ، طرز فکر، روش‌های کار و تغییرات سازمانی را در بر می‌گیرد.قبل از شروع سفر، نیاز نیست برای همه چالش‌ها راه‌حل‌های جامع داشته باشید. در قسمت‌های آینده این نوشته‌ها اصول، الگوها و تکنیک‌هایی را ارائه می‌کنیم که به شما برای مقابله با این چالش‌ها کمک خواهد کرد. نکته ای که باید در حین مطالعه این قسمت به آن توجه کنید این است که هر مشکلی را نمی توان صرفاً با ابزارها و تکنیک‌ها حل کرد. یکی از مهمترین قابلیت‌های شما؛ تواناییِ ایجاد روابط و گفتگوهای حرفه ای با افراد در همه سطوح باید باشد.2. آیا رهبری وجود دارد؟برای شروع یک سفر مدرن‌سازی معماری، داشتن پشتوانه‌ی قوی و حمایت از طرف رهبران بسیار مهم است. برای اینکه بفهمید چطور می‌توانید با رهبران سازمان کار کنید تا برای نوسازی آماده شوند سوالات زیر کمک کننده هستند:2.1. آیا رهبران واقعا این آمادگی را دارند تا جریان ارائه‌ی ویژگی‌های جدید را برای رسیدن به اهداف مدرن سازی کند کنند؟یکی از سخت‌ترین چالش‌هایی که در طول فرایندهای نوسازی با آن مواجه شدم، گرفتن زمان کافی برای انجام و به نتیجه رسانیدن کارهای نوسازی است. پیش از شروع فرایند، رهبران وعده‌های بسیاری می‌دهند مثل اینکه می‌گویند مدرن‌سازی معماری برای ما بالاترین اولویت را دارد و برای رسیدن به این هدف کارهای جاری را به تعویق می‌اندازیم، اما در میانه‌ی کار همیشه کارها و شرایط استثنایی ایجاد می‌شوند که مجبور به انجام آن‌ها می‌شویم و برای اینکه آن کارها را انجام دهیم مجبور هستیم از زمانی که برای مدرن‌سازی در نظر گرفته‌ایم استفاده کنیم. در این شرایط پیشنهاد می‌کنم پیش از شروع هر کاری در مورد میزان تعهد مورد نیاز به صورت واضح و صریح با رهبران سازمان صحبت کنید. قول‌ها و وعده‌های بدون برنامه‌ی درست مانع از انجام کارها است.مورد دیگری که باید به آن توجه کنید این است که مدرن‌سازی نیاز به هزینه دارد، پس باید رهبران سازمان را در مورد هزینه‌ای که می‌کنند و دستاوردی که این هزینه کردن برای آن‌ها دارد کاملا مطلع کنید.2.2. آیا رهبران می‌دانند که سیستم‌ها و روش‌های قدیمی چقدر پیچیده هستند و تغییر در آن‌ها چقدر کار سختی است؟ذاتاً بشر در جستجوی راه حل‌های سریع است. حتی اگر سیستمی طی سال‌ها یا دهه‌ها ایجاد شده‌باشد، همیشه باز هم فشار برای ارائه‌ی یک راه‌حل سریع وجود دارد. اما اگر واقعا انجام کارهای درست و مدرن به همین سادگی بود، دیگر مفهومی به نام بدهی فنی وجود نداشت که تبدیل به یکی از بزرگترین مشکلات شرکت‌های فناوری شود. باید با واقعیت مواجه شد و واقعیت این است که مدرن‌سازی و انجام صحیح کارها زمان می‌برد. اگر بخواهم شفاف صحبت کنم این کار معمولاً سال‌ها زمان نیاز دارد، بنابراین باید همه چیز به طور شفاف برای همه‌ی ذینفعان توضیح داده شود.2.3. هنگامی که اتفاقات غیرمنتظره‌ای که اجتناب ناپذیز هستند رخ می دهد که باعث تاخیرهای زیاد یا افزایش هزینه‌ها می‌شود، رهبران کسب و کار چگونه واکنش نشان خواهند داد؟مدرن کردن سیستم‌هایِ قدیمی و روشهایِ کارِ سنتی مستلزم برخورد با سیستم های بسیار پیچیده و تغییر اساسی در نحوه‌ی انجام کار توسط افراد است. تعداد زیادی از موارد فنی و اجتماعی وجود دارد که ممکن است اشتباه پیش برود و برای اینکه خیالتان را راحت کنم همینجا ضمانت می‌دهم که حتما برخی افراد چنین اشتباهاتی را رقم خواهند زد. ممکن است تقسیم یک سیستم قدیمی دشوارتر از آنچه در ابتدا پیش بینی شده بود باشد یا برخی از اعضای تیم در مورد تغییرات پیشنهادی در تضاد و تعارض قرار گیرند. ممکن است همه چیز از مسیر بهینه منحرف شود، باید برای این شرایط آماده باشید. بنابراین خوب است با سهامداران صحبت کنید و سعی کنید درک کنید که آنها چرا و چگونه واکنش نشان خواهند داد.2.4. آیا رهبران کسب و کار آمادگی تغییر در نحوه کار خود را دراند؟ آیا تصور می‌کنید که رهبران از تغییرات در مدل‌های بودجه، اولویت‌بندی کارها، و فرآیندهای توسعه حمایت کرده و تیم‌ها را برای تصمیم‌گیری و اختیار بیشتر توانمند می‌کنند؟نوسازی می‌تواند همه‌ی جنبه‌‌های مدل عملیاتی یک سازمان مثل مدل تأمین مالی و سطح استقلالی که تیم‌ها دارند را تحت تأثیر قرار دهد. این نوع از تغییرات عمیق و دشوار است و نیاز به رهبری، برای تغییر نحوه عملکرد آن‌ها دارد. باید با تصمیم گیرندگان کلیدی درباره‌ی این تغییرات صحبت کنید و دریابید که آن‌ها چقدر عمیقاً آماده‌ی تغییر در سازمان هستند.2.5. آیا رهبران زمان و بودجه‌ی کافی را برای یادگیری و آموزشِ همه کارکنان سرمایه گذاری می‌کنند تا بتوانند مدرن‌سازی را به طور ماهرانه‌ و صحیح انجام دهند؟مدرن‌سازی بدون یادگیری مهارت‌های جدید و رفتار متفاوت اتفاق نمی‌افتد. رهبران باید بدانند که سرمایه‌گذاری قابل توجهی برای حمایت از کارمندانِ درگیر در نوسازی مورد نیاز است تا اطمینان حاصل شود که مهارت‌های لازم را دارند. در غیر این صورت، مدرن‌سازی ممکن است بسیار بیشتر طول بکشد یا معماری جدید ممکن است دقیقاً شبیه معماری قدیمی یا حتی بدتر به نظر برسد. یادگیری و ارتقاء مهارت یک کارگاه یا دوره آموزشی یکبار مصرف نیست، بلکه سرمایه گذاریِ مداومِ مالی و زمانی است. یادگیری باید در فرهنگ سازمان باشد.2.6. آیا فن‌آوران توان بیانِ مزایای تجاری و سازمانیِ ایده‌های خود را به رهبران کسب‌وکار و سایر ذینفعان دارد؟گاهی اوقات مشکل حمایت نکردن از طرف رهبران نیست، بلکه مشکل این است که آنها نمی‌دانید که چه خواسته‌هایی از ایشان وجود دارد و روی چه چیزی باید سرمایه‌گذاری کنند و مزایای این سرمایه‌گذاری چیست. به نقل قول زیر از یک مدیرعامل توجه کنید:توسعه‌دهندگان همه OCD دارند. آن‌ها همیشه در مورد بدهی‌های فنی صحبت می کنند و دوست دارند همه چیز را بازنویسی کنند.من با نظر یا لحن آنها موافق نیستم، اما موضوع یک اتفاق مشترک است: زمانی که مهندسان نمی توانند مزایایِ تجاری و توجیهاتِ پیشنهادهای معماری خود را به رهبران و سایر ذینفعان منتقل کنند، به عنوان افرادی تلقی می شوند که فقط می خواهند برای لذت بردن از تکنولوژی برنامه‌ها را بازنویسی کنند. مهندسان باید در معرضِ حوزه‌ی کسب و کار و استراتژیِ کسب و کار/محصول قرار گیرند تا بتوانند اهمیت ایده‌های خود را به هر مخاطبی با زبانی مشترک بیان کنند.3. برقراری ارتباط با انتقالِ ارزش‌های معماری:نوسازی مستلزمِ تعهدی عظیم و مداوم است. مدرن‌سازی پروژه‌ای جانبی نیست که مهندسان نرم‌افزار بتوانند در حالی که منتظر کامپایل شدنِ کد خود هستند، آن را انجام دهند. بنابراین، فهم این موضوع که ذینفعان مختلف در سازمان، چگونه نوسازیِ معماری را درک می کنند، مهم است. مهمتر از همه، آیا آن‌ها اهمیت و ارزشی را که مدرن‌سازی ارائه خواهد داد را می‌بینند؟ اجتماعی کردنِ اهمیت مدرن‌سازی احتمالا یکی از مهم‌ترین کارهای آماده‌سازی‌ می‌باشد و به پشتکار زیادی نیاز دارد. تحقیقات و بینش‌های زیر می‌تواند به شما کمک کند تا به معماری بپردازید. ارزشِ دقیق نوسازیِ معماری، از سازمانی به سازمان دیگر بر اساس عواملی مانند استراتژی، صنعت و فرهنگ متفاوت است. بنابراین رهبرانِ فناوری نیز باید در ارتباط دادنِ ابتکارات معماری به اهداف تجاری که موضوع قسمت‌های بعدی است، مهارت داشته باشند.3.1. بهبود زمان رسیدن به بازار (Time To Market):در کتاب Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations نویسنده و همکارانش یافته‌های تحقیقاتی خود را در مورد تفاوت بین سازمان‌های با عملکرد بالا، متوسط ​​و پایین شرح داده‌اند. سازمان‌های با عملکرد بالا چندین بار در روز بهبود‌های خود را به محیط عملیاتی منتقل می‌کنند، در حالی که سازمان‌های با عملکرد متوسط ​​و پایین به صورت هفتگی یا ماهانه یا حتی فصلی این کار را انجام می‌دهند. علاوه بر این، افراد با عملکرد بالا زمان کوتاه‌تری برای تغییرات دارند، خرابی‌های کمتری ایجاد می‌کنند و در صورت بروز خرابی سریع‌تر بازیابی می‌شوند. نکته جالب تر در این زمینه این است که آن‌ها یک معماری خوب طراحی و پیاده‌سازی شده را شناسایی کردند که مزایای زیر را به‌عنوان بزرگ‌ترین عامل در عملکرد تحویل مداوم ارائه می‌دهد:تیم ها می توانند تغییرات بزرگی را در طراحی سیستم خود بدونِ نیاز به اجازه از شخصی خارج از تیم ایجاد کنند.تیم‌ها می‌توانند بدونِ وابستگی به تیم‌های دیگر، برای ایجاد تغییرات در سیستم‌هایشان یا ایجاد کارِ قابل توجه برای تیم‌های دیگر، تغییرات بزرگی در طراحی سیستم خود ایجاد کنند.تیم ها می توانند کارِ خود را بدون ارتباط و هماهنگی با افرادِ خارج از تیم خود تکمیل کنندتیم‌ها می‌توانند محصول یا خدمات خود را بدون توجه به خدمات دیگری که به آن بستگی دارد، استقرار داده و عملیاتی کنندتیم‌ها می‌توانند بیشترِ آزمایش‌های خود را بدون نیاز به محیط آزمایشی یکپارچه انجام دهندتیم‌ها می‌توانند در طولِ ساعات کاری معمولی با خرابی‌های ناچیز و قابل چشم‌پوشی، استقرار را انجام دهندعلاوه بر این، نویسندگان این کتاب دریافتند که یک معماری غیر وابسته (Loosely Coupled) به سازمان، این امکان را می دهد که با حفظ عملکرد کاملِ سیستم، مقیاس آن را افزایش دهد. استخدام مهندسانِ بیشتر برای کار در سیستم‌هایِ قدیمی با وابستگی قوی (Tightly Coupled)معمولاً بهره‌وری را کاهش داده و حتی عملکرد معکوس دارد.3.2. مدیریت پیچیدگی روزافزون:با اینکه حدود 6 سال از انتشار کتاب Accelerate در سال 2018 می‌گذر، اما مفاهیم و مطالب آن کماکان کاربردی است. در حقیقت سیستم‌ها دائم در حال رشد هستند و این رشد دائمی باعث ایجاد پیچیدگی‌های روزافزون در آن‌ها می‌شود و در این شرایط داشتنِ یک معماریِ خوب و خوش تعریف از جنبه‌های مختلف بسیار حیاتی است. این روزها تکنولوژی، جنبه‌های مختلف از زندگی انسان را تحت تاثیر قرار داده است و طبق آمار به طور میانگین هر نفر روزانه 4 ساعت از زمان خود را صرف استفاده از ابزارهای مختلف مثل لپتاپ یا موبایل می‌کند. سیستم‌هایی که می‌سازیم هم دائما در حال تغییر و ارتقا هستند. مثلا اینترنت اشیا را در نظر بگیرید. در سال 2019 حدودا 8.6 میلیارد دستگاه به اینترنت متصل بود در حالی که برای سال 2023 این عدد به 15.14 میلیارد رسیده و پیش‌بینی می‌شود تا سال 2030 این عدد به حدود 30 میلیارد برسد. رهبران فناوری اطلاعات باید دائما شرایط آینده و تغییراتی که در صنایع آن‌ها رخ خواهد داد را رصد کنند. هرچه عمر سیستم افزایش پیدا میکند و پیچیدگی آن زیادتر می‌شود، اهمیت داشتن یک معماری خوب نیز بالاتر می‌رود. هرچه جلوتر برویم، تغییر و نوسازی معماری گران‌تر و پیچیده‌تر خواهد شد. در کنار افزایش پیچیدگی و هزینه، احتمال ایجاد مشکلات بنیادی و ایجادِ مخاطرات برای کسب و کار نیز بیشتر می‌شود.برای مثال در سال 2017 شرکت هواپیمایی British Airways یک قطعی در سیستم فناوری اطلاعات خود داشت که موجب زمین‌گیر شدنِ ناوگان هوایی شد. در سرتاسر دنیا نزدیک به 75 هزار مسافر سرگردان شدند و شرکت متحمل ضرری 80 میلیون پوندی شد. سال بعد سیستم‌های شرکت هک شده و اطلاعات نیم میلیون مشتری نشت پیدا کرد و این بار شرکت متحمل ضرری 183میلیون پوندی شد. کار به همین‌جان ختم نشد. در سال 2019 باز هم خطا در سامانه‌های قدیمی موجب لغو بیش از 100 پرواز و سرگردانی مجدد مسافران شد و این بار هم 8 میلیون پوند دیگر ضرر به شرکت تحمیل گردید.3.3. کاهش ناکارمدی‌ها:تحقیقات Adam Tornhill و Markus Borg نیز نشان می‌دهد که هنگامی که سازمان‌ها از معماری خود غفلت می‌کنند چه اتفاقاتی رخ خواهد داد. در مقاله آن‌ها تحت عنوان Code Red: The Business Impact of Code Quality-- A Quantitative Study of 39 Proprietary Production Codebases نشان داده شده است که حدود 42 درصد از زمان توسعه دهنده‌ها صرف سر و کله زدن با بدهی‌های فنی می‌شود. این زمان بسیار زیاد است و هزینه زیادی را به کسب و کار تحمیل می‌کند در حالی که جلوی جریان سریع ارزش را نیز می‌گیرد.روشی که موجب تحلیل رفتن سیستم‌های نرم‌افزاری می‌شود باید مورد توجه همه شرکت‌های فناوری باشد. رخداد این فرایند مانند بیماری سرطان است، زمانی متوجه هزینه‌های بالای پوسیدگی می‌شوید که هزینه‌های تعمیر آن بسیار بالا رفته و قابل توجه است. در مراحل اولیه‌ی تولید یک محصول، نوشتن کد و نادیده گرفتنِ معماری بسیار آسان است. رفته رفته و با گذشت زمان، میزان چسبندگی (Coupling) در سیستم افزایش می یابد. هر بار تغییرات جدید زمان بیشتری نیاز دارد و خطر آسیب بیشتری را به سیستم وارد می‌کند.نیاز به تست‌های دستی بیشتر احساس شده و حتی ضروری می‌شود و سرعت انتشار دائما کاهش می‌یابد. هر روز باگ‌های بیشتری ظاهر می‌شوند زیرا تغییر در یک قسمت از سیستم باعثِ ایجاد مشکلاتی در بخش دیگری از سیستم می‌شود که به ظاهر هیچ ارتباطی بین این بخش‌ها وجود ندارد. توسعه‌دهندگان برای ترجمه نیازمندی‌ها و الزامات به کد تلاش زیادی می‌کنند زیرا زبانی که کسب‌وکار استفاده می‌کند اصلا در کدها وجود ندارد و در هیچ کجای کد زبان مشترک با کسب و کار ظهور و بروز ندارد. چندین تیم با هم میجنگند تا تغییرات خود را ابتدا انجام دهند. حتی میکروسرویس‌ها هم نوش‌داروی این مرض نیستند. هنگامی که معماری بد و ساختاری اشتباه را به صورت Monolith توسعه داده باشید، تبدیل آن به همان شکل به میکروسرویس فقط چندین برنامه‌ی بد و کوچک ایجاد می‌کند.فناوری به خودی خود دلیلی اجتناب ناپذیر برای زوال سیستم‌ها است. یک سیستم با معماری خوب که بر اساس فناوری‌های جاری ساخته شده است، زمانی که نسل‌های بعدیِ فناوری‌ ظاهر شوند، دچار بدهی می‌شود ولی معماری خوب برای این سیستم، مزایای قابل توجهی را ارائه خواهد کرد. استارت‌آپ‌هایی که هیچ پیشینه و میراث فنی ندارند می‌توانند فوراً از جدیدترین فناوری‌ها استفاده کنند، اما شرکت‌هایی که در حال کار و ارائه خدمات هستند، با هزینه‌های زیادی برای تغییر تکنولوژی مواجه هستند. با این وجود، یک معماری خوب باید هزینه‌های روی آوردن به فناوری‌های جدید را بدون نیاز به جایگزینی کامل، پیش‌بینی کرده و به حداقل برساند.به طور خلاصه، نوسازی معماری، ناکارآمدی‌های تحمیل شده توسط معماری قدیمی را کاهش می دهد و توانایی سازمان را برای نوآوری با سرعتی رقابتی را نیز بازیابی می کند.4. اجتماعی کردنِ یک دیدگاه کل‌نگر از معماری:کلمه معماری برای بسیاری، هنوز به شدت به نرم‌افزار و فناوری دلالت دارد. افراد با انواع مختلف عناوین شغلی، مثل مهندسان نرم افزار و یا حتی خودِ معماران، این دیدگاه را نسبت به معماری دارند. اما برای دستیابی به یک معماری مدرن متشکل از جریان‌های ارزش مستقل و با جریان سریع، لازم است که دیدگاهی جامع‌تر از معماری ایجاد و اجتماعی‌سازی شود، علاوه بر فناوری، روی استراتژی، مدل‌سازی دامنه و طراحی سازمان نیز تاثیر بگذارد.4.1. معماری روی مدلسازی دامنه تاثر دارد:معماری نرم‌افزار با چسبندگی کم، کلیدِ دستیابی تیم‌ها به جریان سریع است. اما همانطور که در تصویر مشاهده می‌کنید، معماری نرم‌افزاری با چسبندگی کم نیاز دارد که حوزه‌های کسب و کاری نیز چسبدگی نداشته باشند و حتی المقدور از وابستگی‌های منطقی جلو گیری کنند تا از وابستگی منطقی در جریان ارزش جلوگیری شود. به همین دلیل، شناسایی خوب و صحیح از مرزهای دامنه برای معماری با جریان‌های ارزش مستقل بسیار مهم است.جریان سریع به معماری نرم افزاری غیر وابسته نیاز دارد که به دامنه‌های غیروابسته نیاز داردمیزان مهارت و تلاشی که برای ترسیم نقشه‌ی کسب‌وکار و کاوش در روش‌های سازمان‌دهیِ قابلیت‌ها در دامنه‌ و زیر دامنه‌ها به کار می‌رود، یکی از عوامل اصلی در تعیین میزان چسبندگی و وابستگی در سیستم خواهد بود. مهندسان و معمارانِ نرم‌افزار، باید به همان اندازه که به الگوهای نرم‌افزاری و انتخاب‌های فناوری فکر می‌کنند، در مورد حوزه‌ی کسب‌وکار نیز فکر کنند، این یکی از مهم‌ترین وظایف آن‌هاست. بدون آمادگی کافی برای این تغییر طرز فکر، به احتمال زیادی سیستم جدید یا شبیه سیستم قدیمی به نظر خواهد رسید یا حاوی انواع جدیدی از مشکلات است، مانند زمانی که برخی تیم‌ها شروع به استفاده‌ی آزادانه از کلیشه‌های مد روز کردند، مانند اینکه «هر میکروسرویس باید کمتر از 100 خط کد باشد.».یکی از مواردی که موقع شروع سفر مدرن‌سازی باید به آن توجه کنید، این تصور غلط است که مهندسان باید تمام وقت خود را صرف برنامه نویسی کنند و هر کار دیگری اتلاف وقت آن‌هاست. زمان صرف شده برای یادگیری در مورد دامنه و جستجوی راه بهینه برای معماریِ یک سیستم، ارزش‌های فراوانی دارد و هزینه‌های خود را چندین برابر بیشتر پرداخت خواهد کرد. توجه به دامنه یکی از بهترین کارهایی است که می توانید برای جلوگیری از تبدیل شدن نرم افزار به بدهی انجام دهید. اگر مفاهیم متغیر در دامنه به خوبی در نرم‌افزار مدل‌سازی شده باشد، ایجاد تغییرات ساده خواهد بود و مخازن و خطوط کد کمتری نیاز به تغییر داشته و تیم‌های کمتری نیز این تغییرات را لمس خواهند کرد. همانطور که در قسمت اول نشان داده شد، راه‌های زیادی برای سازمان وجود دارد که بتواند دامنه‌های خود را سازماندهی کند، بنابراین هر چه تیم‌ها ماهرتر باشند، دامنه‌های بهینه‌تری خواهید داشت. نکته‌ی دیگری نیز وجود دارد که باید در نظر بگیرید، هر چه یک تیم زمان بیشتری برای یادگیری در مورد دامنه‌ای که در آن کار می کند، صرف کند، بیشتر می تواند در ایده‌های محصول مشارکت داشته باشد و ترجمه‌ی الزامات کسب و کاری به کد آسان‌تر خواهد بود. این بدان معناست که یک تیم در طول زمان بهره‌ورتر می‌شود، زیرا آن‌ها، دامنه را بهتر درک می‌کنند و به طور مداوم کد را بهبود می‌بخشند، نه اینکه بهره‌وری در سراشیبی نزول قرارگیرد بخاطر اینکه سیستم دائما بدتر می‌شود.4.2. معماری شامل انتخاب های استراتژیک است:موضوع صحبت معماری، استراتژی است. چگونه باید فناوری و تصمیمات سازمانی به نتایج تجاری منجر شوند؟ یکی از اولین کارهایی که انجام می‌دهیم، تعیین مرزهای معماری است. مرزهای معماری شرط‌های استراتژیک برای آینده هستند. هنگام تجزیه یک سیستم بزرگ به زیرسیستم‌ها، همسویی با دامنه‌های تجاری بسیار مهم است، اما همانطور که گفته شد، راه‌های مختلفی وجود دارد که یک کسب و کار می تواند به دامنه‌ها و زیر دامنه‌ها سازماندهی شود. هر انتخابی دارای راهکارهای جایگزینی است که بر روی انواع تغییرات و هزینه های مربوطه تاثیر می گذارد. استراترژی‌های تجاری و محصول در آینده تغییر و تکامل خواهند یافت و با تعیین مرزها و معماری تلاش می‌کنیم این تغییرات را در آینده و تاثیری که روی برنامه دارند را پیش‌بینی کنیم. معماری، استراتژیک است. به این معنا که علاوه بر تعیین مرزهای معماری، سطح و نوع سرمایه گذاری در هر حوزه با توجه به اهمیت پیچیده و استراتژیک آن باید متفاوت باشد. در حوزه‌های بسیار استراتژیک، معمولاً منطقی است که راه حل را در خود کسب و کار و با کمک کارمندان بسیار ماهر تولید کنید. در حوزه‌های غیر استراتژیک، استفاده از راه‌حل‌های آماده یا برون‌سپاری به شرکای بیرونی منطقی‌تر است. با این حال، این موضوع چالش‌های بسیار و نکات ظریف و پیچیده‌ای دارد و به راحتی احتمال دارد اشتباه کنید. مثلا ممکن است برای پاسخ به یک نیازمندی درون سازمان نرم‌افزاری آماده را بخرید و این ذهنیت را داشته باشید که نیازمندی شما را پاسخ می‌دهد،اما بعدا از مدتی متوجه شوید که تمامی نیازهای شما توسط آن برنامه پوشش داده نمی‌شود و نیاز دارید مقدار قابل توجهی درخواست سفارشی سازی و تغییر بدهید که از قبل انتظارش را نداشتید و در مدتی که منتظر انجام درخواست‌ها هستید کسب و کار شما دچار محدودیت شود.پس قبل از شروع سفر مدرن‌سازی، باید بررسی کنید که سازمان شما در گذشته، چگونه برای ساخت یا خرید یک برنامه تصمیمات خود را اتخاذ کرده است، و آیا استراتژی روشنی وجود دارد که افراد را به سمت تصمیم گیری های موثر راهنمایی می کند.4.3. معماری و قانون کانوی (Conway):آشنایی با قانون کانوی از ملزمات کار معماری می‌باشند. قانون کانوی می‌گوید:سازمان‌هایی که سیستم‌هایی را طراحی می‌کنند، مجبور به تولید طرح‌هایی هستند که کپی‌هایی از ساختارهای ارتباطی این سازمان‌ها هستند.مخلص کلام در معماریِ نرم افزار این است که طراحی یک سیستم، منعکس کننده‌ی ساختار و الگوهای ارتباطی در سازمانی است که آن را ایجاد کرده است. اگر هنگام شکل‌دهی به معماریِ نرم‌افزار، سازمان در نظر گرفته نشود، یا اگر افراد مختلفی مسئولیت طراحی سازمان و معماری نرم‌افزار را عهده دار باشند، به احتمال بسیار زیاد ناهماهنگی‌هایی در بخش‌های مختلف اتفاق خواهد افتاد، که ممکن است طیفی از مشکلات در کد یا الگوهای ارتباطی در سیستم را ایجاد کند.برای توضیح دادن قانون کانوی و اینکه شنونده‌ها آن را درک کنند زمان زیادی نیاز نیست. هنگامی که تصمیم به مدرن‌سازی معماری گرفتید، خوب است به عنوان یکی از گام‌های اولیه در اجتماعی سازی فرایند مدرن سازی، در مورد قانون کانوی و اهمیت آن با همه صحبت کنید. اگر به گوشه گوشه‌ی سازمان خود خوب نگاه کنید مثال‌های زیادی از این قانون را خواهید دید. پس در کنار توضیح قانون کانوی شاید بد نباشد که ارجاعاتی نیز به شرایط فعلی سازمان خود بدهید. توجه افراد را به ساختار تیم‌ها و سازمان و نحوه تعاملات آن‌ها و مشکلات و خوبی‌های آن جلب کنید.4.4. آماده‌ی سوار شدن به آسانسور معماری باشید:آقای Gregor Hohpe مطلبی در مودر معماری تحت عنوان Architect Elevator نوشته اند که با یک قیاس خوب دیدگاه مناسبی در مورد نگاه کل‌نگر به معماری شما می‌دهد.فرض کنید سازمان ما یک برج باشد که طبقات مختلف و مسئولیت های مختلفی دارد. از اتاق فنی مهندسی برای تعمیر و نگهداری برج گرفته تا پنت‌هاوسی با دید ابدی. این مطلب بیانگر این ایده است که دیدگاه کل نگر در معماری روی همه‌ی قسمت‌های برج تاثر گذار است. مثلا اگر تصمیمات استراتژیک در پنت هاوس گرفته می‌شود و در زیرزمین کنار موتور خانه کارهای مهندسی عملی (توسعه نرم افزار) انجام می‌شود، معماری روی همه این طبقات و بخش‌ها تاثر گذار ست. این قیاس فوق‌العاده از آقای Gregor Hohpe یک راه عالی برای شماست که بتوانید به افراد در سازمان کمک کنید تا طیف وسیعی از فعالیت‌های مربوط به معماری را ببینند و درک کنند. این قیاس الگوی خوبی برای کارها و بخش‌هایی است که زمان خود را در آن‌ها سپری می‌کنید و حتی می‌توانید مناطقی که ممکن است از آنها غفلت کنید را نیز شناسایی کنید.5. جمع بندی:در این قسمت از سلسله مطالب مرتبط با مدرن‌سازی معماری، سعی در بیان مطالبی داشتم که شما را برای سفر مدرن‌سازی آماده می‌کند. تعدادی سوال پرسیده شد که با آن‌ها می‌توانید تشخیص دهید شما و سازمان چقدر برای این سفر آماده هستید و باید منتظر چه اتفاقاتی در این مسیر جذاب و پر چالش باشید. در ادامه بیان کردیم که باید قبل از شروع این سفر همه را آگاه سازید که در چه مسیری گام بر می‌دارند. باید بدانیم که معماری در سطوح مختلف فنی و کسب و کاری در گیر مسائل کلان و خرد است و باید نگاهی کل نگر به معماری داشته باشید.در صورتی که تمای داشته باشید می‌توانید قسمت اول از این مجموعه مطالب را نیز مطالعه کنید. https://virgool.io/p/gtscjsvx8o5x/%D9%85%D8%AF%D8%B1%D9%86%E2%80%8C%D8%B3%D8%A7%D8%B2%DB%8C%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C%D9%86%D8%B1%D9%85%E2%80%8C%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%D9%85%D8%AF%D8%B1%D9%86%E2%80%8C%D8%B3%D8%A7%D8%B2%DB%8C%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C%D9%88%D9%88%D8%A7%D8%A8%D8%B3%D8%AA%DA%AF%DB%8C%D8%A2%D9%86%D8%A8%D9%87%D8%B3%D8%A7%D8%AE%D8%AA%D8%A7%D8%B1%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%DB%8C%D9%88%D8%AA%DA%A9%D9%86%DB%8C%DA%A9%E2%80%8C%D9%87%D8%A7%D9%88%D8%B1%D9%88%D8%B4%E2%80%8C%D9%87%D8%A7%DB%8C%D8%A2%D9%86%D8%B1%D8%A7%D8%A8%D8%A7%D9%87%D9%85%D8%AF%D8%B1%D8%A7%D8%AF%D8%A7%D9%85%D9%87%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C%D9%85%DB%8C%E2%80%8C%DA%A9%D9%86%DB%8C%D9%85%E2%80%8C%E2%80%8C%E2%80%8C%E2%80%8C%E2%80%8C.virgool. علیرضا ارومند علیرضا ارومند Mon, 08 May 2023 11:45:15 +0330 https://virgool.io/dotin/%D9%85%D8%AF%D8%B1%D9%86-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-f53cdgrwrpnj 1. مقدمه:معماری‌های قدیمی و بیات، ریسک تجاری و نقطه ضعفی برای مزایای رقابتی کسب‌وکارها هستند. تغییر در آن‌ها بسیار سخت و کند بوده و احتمال این وجود دارد که در شرایطی عدم اطمینان به کسب و کار ایجاد شود. در این صورت فرصتی در اختیار رقبا قرار می‌گیرد تا مزایای زیادی نسبت به کسب و کار پیدا کرده و ممکن است کسب و کار آسیب ببیند. خطوط هوایی Southwest این مشکل را با گوشت و پوست خود لمس کرد. در سال 2022 یک سیستمِ برنامه‌ریزیِ قدیمی، بحرانی بزرگ ایجاد کرد. در یک هفته، 14500 پرواز لغو شد و برند آن‌ها آسیب‌های غیرقابل جبرانی دید. آن‌ها به دلایلی اشتباه، تیتر یک اخبار بین‌المللی شدند. در مقابل طراحی و پیاده سازی یک معماری مدرن و دقیق مزیت رقابتی بزرگی برای کسب و کار ایجاد می‌کند. در انگلیس استارت‌آپ Cazoo تنها در 90 روز کسب‌وکاری آنلاین در حوزه خودرو راه‌اندازی کرد و سریع‌ترین یونیکورن بریتانیا شد. رسیدن به ارزش یک میلیارد دلاری در کمتر از 18 ماه چیزی است که بسیاری از کسب‌وکارها در خواب هم نمی‌بینند. اما مسئله اصلی اینجاست که چطور در این زمان کوتاه به این ارزش رسیده‌اند؟ یکی از عوامل کلیدی موفقیت Cazoo، توانایی آن‌ها در بهره‌گیری از شیوه‌ها و فناوری‌های معماری مدرن، مانند Serverless بود. استفاده از معماری‌های مدرن به آن‌ها امکان ساخت محصولی را داد که در شرایطی که در حال ارائه خدمات به استفاده کننده‌ها بود، بتواند تغییر مقیاس داده یا نسخه جدید برای آن نصب و راه اندازی کرد.شاید به نظر برسد با افزایش سن، شرکت‌ها و کسب‌وکارشان از یک استارت‌آپ چابک به شرکتی قدیمی، سنگین و سخت با معماری قدیمی تبدیل می‌شوند و این تغییر شرایط اجتناب‌ناپذیر است. اما Netflix ثابت کرد که تغییر این شرایط امکان‌پذیر است. آن‌ها در سال 2009 تغییرات عمده‌ای در کار خود ایجاد کردند. آن‌ها نرم‌افزار خود را از یک نرم‌افزار با معماری Monolith به چندین نرم افزار با معماری Microservice مهاجرت دادند تا قابلیت‌های رقابتی خود را در بازار Streaming حفظ کنند. آقای Adrian Cockroft که آن زمان به عنوان CTO در شرکت Netflix مشغول به کار بود دلیل خود برای این تغییر را اینگونه بیان کرد:تهدیدی در ماهیت کسب‌وکارها وجود دارد. اگر شما نسخه‌های سه ماهه را انجام می‌دهید و رقیب شما در حال انتشار روزانه و تحویل مداوم است، از تجربه کاربری بسیار عقب خواهید افتاد و فقط از آن رنج خواهید برد.در صورت تمایل می‌توانید به این پادکست گوش کنید. به عقیده‌ی من، هر رهبری باید دائما از خود سولاتی بپرسد که در آن زمان در Netflix نیز پرسیده شد:آیا ممکن است از رقبا عقب بیفتیم؟آیا ممکن است یک استارت‌آپ خیلی سریع وارد شود و کسب‌وکار ما را دگرگون کند؟آیا بخش‌های حیاتی کسب‌وکار ما، در حال استفاده از سیستم‌های تاریخ مصرف‌دار هستند که هر لحظه ممکن است باعث از دست دادن جدی درآمد یا آسیب به شهرت ما شود؟سازمان‌های زیادی مانند نتفلیکس وجود دارند که معماری و شیوه‌های خود را با موفقیت مدرن‌سازی کرده و آن را از یک بدهی بزرگ به مزیتی رقابتی تبدیل کرده‌اند. طی چندین مطلب می‌خواهیم بر مدرن‌سازی معماری برای دستیابی به مدل‌های عملیاتیِ مدرن و با کیفیت متمرکز شویم. می‌خواهیم تیم‌هایی توانمند حول محصولات داشته باشیم که جریان سریعی برای تغییر در محصولات خود دارند و محصولاتی با کیفیت و در حال پیشرفت‌ را هرروز در مقیاس بالا روانه بازار می کنند. در این مطلب جنبه‌های کلیدی در مسیر مدرن‌سازی معماری و نحوه‌ی تطبیق آن‌ها با یکدیگر را بررسی می‌کنیم، سپس در قسمت‌های آینده به موضوعات مختلف به صورت اختصاصی‌تر خواهیم پرداخت.2. معماری مدرن مبتنی بر جنبه‌های فنی و اجتماعی:یک معماری اگر به خوبی طراحی شده باشد، پیوستگی خوبی داشته و با جدیدترین فناوری‌ها ساخته شده باشد باز هم به تنهایی توانایی نوآوری در کسب‌وکار، با سرعت بالا را تضمین نمی‌کند. در کنار معماریِ نرم‌افزارِ خوب، سازماندهی موثر تیم‌ها در محیطی که به آن‌ها قدرت نوآوری دهد نیز ضروری است. هر دو جنبه‌ی فنی و سازمانی معماری باید با هم همخوانی داشته باشند تا راهکاری که ارائه می‌کنیم بهینه باشد. معماری‌ای که به جنبه‌های فنی و اجتماعی، همزمان توجه می کند در اصلاح به معماریِ اجتماعی-تکنیکال (Socio-Technical Architecture) معروف شده است و برخی از معماران خود را معماران فنی-اجتماعی می‌نامند.شاید مدرن‌سازی Netflix ظاهرا یک تلاش کاملاً فنی به نظر برسد. به هر حال، آن‌ها با شکستن نرم‌افزار خود از یک معماری یکپارچه به تعداد زیادی نرم‌افزار کوچک با معماری میکروسرویس، یک الگوی معماری جدید را به کار بردند. اما اگر به دقت نگاه کنید، درخواهید یافت که میکروسرویس‌ها یک الگوی معماریِ اجتماعی- فنی هستند. مزایای این الگوی معماری به یک اندازه فنی و سازمانی است. Sam Newman، نویسنده‌ی Building Microservices (O’Reilly)، این مورد را به خوبی توضیح می‌دهد.دلیل سوم [برای پذیرش میکروسرویس‌ها] واقعاً جایی است که شما به دنبال ایجاد درجه‌ی بالاتری از استقلال سازمانی هستید. شما به دنبال توزیع مسئولیت بین تیم‌ها هستید، می‌خواهید آن‌ها بتوانند تصمیم‌گیری کنند، نرم‌افزار را توسعه دهند و میزان هماهنگی مورد نیاز تیم‌ها با سایر بخش‌های سازمان شما را کاهش دهند.مطلب کاملی در این زمینه منتشر شده که می‌توانید آن را اینجا مطالعه کنید. میکروسرویس‌ها تنها سبکِ معتبرِ معماری برای ما نیستند. صرف‌نظر از الگوها و فناوری‌هایی که استفاده می‌کنیم، یک رویکرد و معماری اجتماعی- فنی برای دستیابی کامل به پتانسیلِ سرعت رسیدن به بازار (speed-to-market) برای سازمان‌ها ضروری است. همان‌طور که Sam Newman تاکید کرد، تیم‌ها برای تغییر و استقرار کدِ خود، بدون وابستگی و نیاز به هماهنگی با دیگران نیاز به استقلال دارند. این جریان در سال‌های اخیر به‌ویژه با انتشار کتاب (Team Topologies (IT Revolution در سال 2019 بسیار مورد توجه قرار گرفته است و به یکی از مفاهیم داغ برای گفتگو در محافل مختلف بدل شده است و توسط بسیاری از سازمان‌ها از Docker گرفته تا دولت نروژ، پذیرفته شده است.توپولوژیِ تیم‌ها، ابزاری برای سازمان‌هایی است که قصد دارند تغییرات سریع و مکرر را در برنامه‌های خود ایجاد کرده و جریان سریعی از ارزش‌ها را در کسب و کار خود اعمال کنند. در عمل این جریان سریع اغلب به این معنی است که تیم‌ها کد را به‌صورت روزانه یا چند بار در طول روز در محیط عملیاتی استقرار می‌دهند. توپولوژی‌ تیم‌ها عمدتاً بر جنبه‌های اجتماعیِ معماریِ اجتماعی-فنی تمرکز دارد که از آن به عنوان تفکر اول تیم (Team-First Thinking) و مرزهای اول تیم (Team-First Boundaries) یاد می‌شود. معماری نرم‌افزار نیز باید توسط الزامات سازمانی برای دستیابی به جریان سریع به سمت این دیدگاه هدایت شود.یکی از مفاهیم اساسیِ معماری در توپولوژی‌های تیمی، جریان ارزش (Value Stream) است. جریانِ ارزش، دنباله‌ای از مراحل است که تیم برای کشف نیازهای برآورده نشده کاربران، طراحی راه‌حل‌ها برای آن نیازها، پیاده‌سازی آن راه حل‌ها در قالب نرم‌افزار و ارائه آن ارزش به مشتریان طی می‌کند. تیمی که مسئول یک جریان ارزش است، تیم همسو با جریان (Stream-aligned Team) نامیده می‌شود. شکل زیر نمای کلی و سطح بالا از یک جریان ارزش را ارائه می‌دهد:نمای سطح بالا از جریان ارزشدستیابی به جریانی سریع، نیازمند این است که معماری به گونه‌ای باشد که جریان‌های ارزش از هم مستقل باشند. این بدان معناست که تیم، در تصمیم‌گیری در مورد جریان ارزش خود بیشترین اختیار را دارد. مثلا تیم می‌تواند تصمیم بگیرد چه چیزی بسازد، چگونه آن را ساخته و سپس به کار گیرد. این نکته اشاره به این مسئله دارد که شما آن را می‌سازید و شما آن را اجرا می‌کنید ( You Build It, You Run It). برای اینکه این مدل به درستی کار کند، تیم‌ها باید مالک نرم‌افزار برای جریان ارزش خود باشند. تیم‌ها روی انتشار نرم‌افزار خود نیز باید کنترل داشته باشند و برای این کار به سایرین وابسته نباشند. در این روش به جای اینکه تیم‌ها را با ویژگی‌ها و الزامات مربوط به پیاده‌سازی بسنجیم آن‌ها را بر اساس نتایج تجاری، مانند OKRها سنجش خواهیم کرد. یک ضدالگوی معروف در این کار که بعضا تیم‌ها به سمت آن میل پیدا می‌کنند، Feature Factory است.حال که دریافتیم باید جریان‌هایی از ارزش‌های‌ مستقل داشته باشیم که مالک آن‌ها، تیم‌های مستقل است، مهم است که بتوانیم این جریان‌های ارزش را شناسایی کنیم. تصویر بعد، نحوه‌ی شناسایی جریان‌های ارزش مستقل را نشان می‌دهد. ابتدا کار خود را با شناسایی زیردامنه‌های تجاری (Business Subdomains، معروف به زیر دامنه‌های کسب‌وکار، مناطقی از کسب‌وکار که به اندازه کافی کوچک هستند تا یک تیم واحد داشته باشد) که قرار است در آن سازمان جریان ارزش ایجاد کند، شروع می‌کنیم. مواردی که شناسایی کردیم را جریان‌های ارزش کاندید (Candidate Value Streams) می‌نامیم. سپس جریان‌های ارزش کاندید از سه دیدگاه مختلف یعنی استراتژیک، سازمانی و فناوری ارزیابی می‌شوند. اگر این دیدگاه‌ها با موفقیت تأیید شوند، جریان ارزش به عنوان یک جریان ارزش هدف در نظر گرفته می‌شود، به این معنی که اطمینان کافی وجود دارد که یک جریان ارزش مستقل خواهد بود و نوسازی آن می‌تواند آغاز شود. در طول این فرایند، احتمالاً اصلاحات زیادی وجود دارد. اغلب، مسائل و مشکلات عمیقی ممکن است ظاهر شوند. مسائلی مانند عدم همسوییِ استراتژیک بین سهامداران یا مسائل و مدل‌های تامین مالی. این مسائل باید قبل از ایجاد تغییرات ساختاری مورد توجه قرار گیرند. این کار یک فرایند یا چک لیست ساده نخواهد بود که خیلی راحت و بدون دردسر از بالا تا پایین تیک بزنیم و به پایان آن برسیم.از جریان ارزش کاندید به جریان ارزش هدف3. معماری، همسو با دامنه تجاری:ممکن است در سطح کد، معماری نرم‌افزار جدا شده باشد اما وابستگی‌هایی بین جریان‌های ارزش به دلیل وابستگی در ایجاد تغییرات وجود داشته باشد. این اتفاق در شرایطی رخ می‌دهد که دو بخش از سیستم مجبور باشند به‌طور هم‌زمان تغییر کنند در حالیکه بخشی از یک منبع کد نیستند. این نوع وابستگی‌ها را وابستگی‌های منطقی می‌نامیم. همان‌طور که در تصویر بعد مشاهده می‌کنید، وابستگی‌های منطقی مشکل‌ساز هستند، زیرا استقلال یک جریان ارزش را کاهش می‌دهند. در وابستگی منطقی، تیم‌های مختلف که مسئول جریان‌های ارزش متفاوت هستند باید فرایند کار و استقرار خود با هم هماهنگ کنند. این نیاز به هماهنگی به‌طور بالقوه حتی منجر به گلوگاه‌هایی می‌شود که در آن یک یا چند تیم برای انجام کارهای خود به خاطر تیمی دیگر متوقف می‌شوند.تغییرات وابسته در تیم‌های مجزا به دلیل وابستگی منتطقیبرای به حداقل رساندن تغییراتِ وابسته، مهم است که دامنه کسب‌وکار را ترسیم کرده و به دقت تجزیه و تحلیل کنید تا دریابید وقتی ویژگی‌های جدیدی به سیستم اضافه می‌شود کدام مفاهیم دامنه با هم تغییر می‌کنند. مفاهیمی که با هم تغییر می‌کنند را می‌توان در زیر دامنه‌های یکسان سازماندهی کرد و جریان‌های ارزشی را می‌توان برای هر زیردامنه ایجاد کرد که حاوی یک منبع کد هماهنگ شده با زیردامنه باشد. در نتیجه، جریان‌های ارزش، مستقل خواهند بود و تیم‌ها می‌توانند هر مرحله از جریان ارزش خود را، از کشف تا استقرار، بدون نیاز به هماهنگی با سایر تیم‌ها طی کنند.یکی از مؤثرترین راه‌ها برای ترسیمِ دامنه‌ی تجاری و شناساییِ زیر دامنه‌های آن، تکنیکی به نام Event Storming است. Event Storming یک تکنیک است که در آن افرادی که درگیر ساختِ یک محصول هستند، از گروه‌های متنوعی مانند مهندسان نرم‌افزار، مدیران محصول، طراحان UX، متخصصان QA، و ... گرد هم می‌آیند و به‌طور گروهی نقشه‌برداریِ بخشی از کسب‌وکار را با استفاده از رویدادهای دامنه (Domain Event) در طول یک بازه زمانی انجام می‌دهند. پس از اینکه گروه بازه زمانی را با رویدادهای دامنه ترسیم کرد، رویدادها را می‌توان به زیر دامنه‌ها تقسیم کرد.باید اذعان کنیم که هرگز نمی‌توان تغییرات وابسته را کاملا حذف کرد. برخی از پیوندهای منطقی بین جریان‌های ارزش همیشه وجود خواهد داشت. سرمایه‌گذاری در زیر دامنه‌هایی که به خوبی طراحی شده‌اند، کلیدی برای جلوگیری از وابستگی غیرضروری در تغییرات است. باید دقت کنیم که اگر هنگام تشخیص زیردامنه‌ها کم دقتی کنیم، ممکن است به راحتی مرزهای دامنه‌ای ایجاد شود که به خوبی تعریف نشده‌اند.4. مدل‌های عملیاتیِ محصول‌محور:معماری مدرن برای توانمندسازی مدل‌های عملیاتی مدرن ضروری است. در گذشته، نرم‌افزار به‌صورت پروژه‌محور ساخته می‌شد. در آن روش، تیم محدوده‌ای از پیش تعیین‌شده در بازه زمانی معلوم شده از قبل و در چارچوب بودجه محدود ارائه می‌کرد. امروزه، سازمان‌ها به سمت مدل‌های عملیاتی و محصول‌محور حرکت می‌کنند که در آن تیم‌هایِ توانمندِ محصول، حولِ نتایج کسب‌وکار متمرکز می‌شوند، به مشتریان نزدیک‌تر می‌شوند و تصمیمات خود را برای محصول می‌گیرند. کارشناسان مدیریت محصول مانند Teresa Torres، Melissa Perri و Marty Cagan بر این عقدیه هستند که تیم‌ها باید به‌صورت منظم مثلا هر هفته با مشتریان خود صحبت کنند.تیم‌های مدرن، عمری طولانی دارند و به‌طور مستمر در جست‌وجوی نیازهای برآورده نشده‌ی کاربران خود هستند، نه اینکه در پایان پروژه از هم جدا شوند. با این روش نه تنها تیم‌ها برای اکتشافات خود و همکاریِ نزدیک با مشتریان توانمند می‌شوند، بلکه آنها به کار پایدار نیز تشویق می‌شوند. آنها به‌طور نامحدود از کدهای خود پشتیبانی می‌کنند و بنابراین می‌خواهند آن را سالم نگه دارند تا به راحتی تکامل یافته و پشتیبانیِ ویژگی‌های موجود و تولید ویژگی‌های جدید در آن آسان باشد.حرکت به سمت مدل عملیاتیِ محصول‌محور ابتدا با تعریفِ واضح محصولات سازمان آغاز می‌شود و سپس با نحوه‌ی مواجهه با مشتری و تیم‌های داخلی، همراه با نتایجِ کسب‌وکار و مشتری‌ای که هر محصول به آن کمک می‌کند، ادامه می‌یابد. این کار به‌عنوان طبقه‌بندی محصول (Product Taxonomy) شناخته می‌شود و پایه و اساس ساختار سازمانی و معماری نرم‌افزار است. تمام جریان‌های ارزشی که به یک محصول معین کمک می‌کند، با ستاره شمالی (North Star) محصول همسو خواهند شد و همان‌طور که در تصویر زیر نشان داده شده است، به رهبران محصول و فناوری اطلاعاتی ارزشمند می‌دهد.استفاده از طبقه‌بندی محصول برای نقشه‌برداری از محصولات، نتایج، معماری، ساختار سازمان و محدوده مسئولیت‌پذیریطبقه‌بندیِ محصول، به‌عنوان چشم‌اندازی از هدفی که سازمان در تلاش است به آن برسد، عمل می‌کند. این یک راه عالی برای برجسته کردن بخش‌هایی است که بیشترین عدم تطابق بین ساختارهای فعلی و ایده‌آل وجود دارد. این کار آشکار می‌سازد که مدرن‌سازی در کجا بیشترین سود را خواهد داشت. تصویر بعدی، سناریوی مشترکی را نشان می‌دهد که هر جریان مدرن‌سازی احتمالاً با آن مواجه می‌شود: مرزهای دامنه برای جریان‌های ارزش هدف، کاملاً با سیستم‌های فناوری اطلاعات موجود ناهمسو هستند و برای همسویی مجدد نیاز به سرمایه‌گذاری بزرگ برای نوسازی دارند.استفاده از طبقه‌بندی محصول برای برجسته کردن عدم تطابق بین ساختار فعلی و ایده‌آلمدرن و نوسازی معماری نه تنها فرصتی برای حرکت به سمت یک مدل عملیاتی محصول‌محور است، بلکه فرصتی هم برای بهبود محصولات است. نوسازی فقط به معنای بازسازی سیستم قدیمی با فناوری‌ها و الگوهای جدید در عین حفظ همان ویژگی‌ها نیست، بلکه مدرن‌سازی، مدرن کردنِ محصول، دامنه، فرایندهای کسب‌و کار و نحوه ایجاد محصولات توسط سازمان نیز هست.5. محدوده‌های معماری:در سازمان‌های بزرگ‌ با محصولات زیاد و هزاران کارمند، برای مقابله با سطوح بالاتر پیچیدگی، باید به معماری در حوزه‌های مختلف فکر کرد. یکی از ویژگی‌های مهم دامنه‌ها این است که برای وضوح هنگام تصمیم‌گیری ضروری هستند. همه باید محدوده‌ای که در آن کار می‌کنند را درک کنند. به عنوان مثال، تصمیمات معماری، مانند انتخاب فناوری، در چه سطحی باید اعمال شوند؟ آیا هر تیمی باید استقلال کامل برای استفاده از هر فناوری داشته باشد، آیا باید گروه‌هایی از تیم‌های مرتبط را ملزم به استفاده از فناوری‌ها مشابهی کرد، یا باید انتخاب‌های فناوری در سطح سازمانی استاندارد شود؟در این نوشته از اصطلاحات محدوده 1، 2 و 3 همان‌طور که در تصویر نشان داده شده است، استفاده می‌کنم. دامنه 1 (معروف به زیر دامنه) دامنه‌ای است که به اندازه کافی کوچک و در اختیار تیمی واحد است. بنابراین توسط یک جریان ارزش واحد سرویس‌دهی می‌شود. دامنه 2 با گروهی از حوزه‌های 1 مرتبط است و دامنه 3 با گروهی از دامنه‌های حوزه 2 مرتبط هستند. سازمان‌های بزرگ‌تر ممکن است دامنه‌های بیشتری داشته باشند. دقت کنید که شما مجبور نیستید از این اصطلاحات در سازمان خود استفاده کنید و این فرایند می‌تواند با هر اصطلاحی که درشرکت شما استفاده می‌شود، سازگار شود. اما این مهم است که مشخص کنید در هر زمان در چه حوزه‌ای کار می‌کنید.محدوده معماریهنگام کار در محدوده 2 و بالاتر، به دلیل پیچیدگیِ تیم‌هایِ متعدد، پاسخ به بسیاری از سوالات معماری دشوار است: جریان‌های ارزش چگونه باید گروه‌بندی شوند؟ هر گروه چقدر باید استقلال داشته باشد؟ آیا تکرار زیاد است؟ کجا باید خدمات مشترکی ساخته شود که توسط جریان‌های ارزشِ چندگانه استفاده می‌شود؟ طبقه‌بندی محصول، همچنین می‌تواند با تعریف سطوح طبقه‌بندی بالاتر مانند گروه‌های محصول و سبد محصولات همسو با نتایج کسب‌وکار که برای هر سطح بهینه شده‌اند، برای پاسخ به این سؤالات کمک کند. با این حال، شناسایی اهداف استراتژیک روشن در هر سطح همیشه ساده نیست، به‌ویژه برای سازمان‌هایی که در حال گذار از یک مدل عملیاتی پروژه‌محور هستند. در قسمت‌های بعد نشان خواهیم داد که چگونه Wardley Mapping که یک تکنیک نقشه‌برداریِ استراتژی است، برای چنین سناریوهایی عالی عمل می‌کند. می‌توان از آن برای ترسیم چشم‌اندازِ کسب‌وکار در هر حوزه‌ای استفاده کرد.همچنین می‌توان به شناسایی حوزه‌هایی که بیشترین شانس را برای مزیت رقابتی محصولات ارائه می‌کنند و متعاقباً همسویی با نتایج کلیدی دارند، کمک کند.6. پلتفرم‌های توسعه‌دهنده داخلی:مرزهای دامنه‌ی خوب، وابستگی در تغییر را کاهش می‌دهد و منبع کد جدا شده، تیم‌ها را قادر می‌سازد تا تغییرات کد را بدون وابستگی و اصطکاک انجام دهند. با این حال، یک جنبه‌ی حیاتی دیگر وجود دارد که برای استخراج ارزش از یک معماری مدرن و فعال کردن جریان سریع تغییرات ضروری است: توانایی تیم‌ها برای تغییر آسان و سریع کدشان و استقرار و پشتیبانی از آن در محیط عملیاتی. اینجاست که پلتفرم‌های توسعه‌دهنده داخلی (Internal Developer Platforms یا IDP) وارد فرایند مدرن‌سازی معماری می‌شوند.در اصطلاحات توپولوژی تیم، هدف یک پلتفرم، کاهش بار شناختی، ظرفیت شناختی جمعی و تیم‌های همسو با جریان است. یک IDP ابزارهایی را در اختیار تیم قرار می‌دهد که تیم‌ها برای ایجاد، توسعه و پشتیبانی از برنامه‌های خود به آن‌ها نیاز دارند. یک IDP خوب این قابلیت‌ها را از طریق یک تجربه توسعه‌دهنده خاص(Developer Experience یا DX) به نمایش می‌گذارد، به این معنی که استفاده از پلتفرم به دلیل مستند بودن و سلف‌سرویس بودن آن، آسان است. وقتی تیم‌ها می‌خواهند برنامه‌های جدید ایجاد کنند یا کدی را مستقر کنند، فرایند باید یکپارچه و ساده باشد و نیازی به برقراری ارتباط با تیم پلتفرم یا هر تیم دیگری وجود نداشته باشد. این فرایند ارائه‌ی قابلیت‌های مورد نیاز تیم‌ها و یک DX خوش‌تعریف و خوب، اغلب به عنوان جاده سنگ‌فرش (Paved Road) یا مسیر طلایی (Golden Path) شناخته می‌شود.امروزه معیارهای ارزیابی برای IDP بسیار بالا تعیین شده است. IDPهای استاندارد طلایی، تیم‌ها را قادر می‌سازند تا برنامه‌های جدید ایجاد کنند و آنها را در یک محیط تولیدی تنها در چند ساعت یا کمتر مستقر کنند. علاوه بر این پلتفرم‌ها، معیارها، نظارت، ثبت گزارش، خطوط لوله استقرار و سایر ابزارهای مورد نیاز را برای این برنامه‌ها را فراهم می‌کنند تا تیم‌ها بتوانند مدل عملیاتی You Build It, You Run It را بدون غرق شدن در زیرساخت‌هایی که جریان ارزش در محصول اصلی آنها را کاهش می‌دهد، اتخاذ کنند. 7. مدرن‌سازی معماری سفری در یک مسیر است نه مقصد:برای بسیاری از سازمان‌ها، تغییر از معماری قدیمی به مدرن چندین سال طول می‌کشد. هیچ راه‌حل سریعی برای سیستم‌هایی که طی سال‌ها یا دهه‌ها دچار افت شده‌اند، وجود ندارد. اما این بدان معنا نیست که باید سال‌ها طول بکشد تا مدرنیزاسیون شروع به ارائه ارزش کند. به‌جای تلقی مدرن‌سازی به‌عنوان پروژه‌ای که در آن معماری مثل یک هدف از ابتدا تعریف شده، سپس یک طرح دقیق برای انتقال از وضعیت فعلی به حالت هدف ایجاد می‌شود، استعاره سفر مناسب‌تر است. در این استعاره نیز اهداف و چشم‌انداز ایجاد می‌شود، اما وقتی گامی به جلو برمی‌داریم، با ظهور بینش‌های جدید امکان تصحیح فرایند وجود دارد. با این رویکرد، معمولاً در عرض 3 تا 6 ماه، ارزش‌هایی تحویل می‌شوند. ارزش یک کلمه کلیدی است. زیرا هر مرحله در سفر مدرن‌سازی باید همیشه بر اساس ارزش تجاری و مشتری باشد. ارتباط برقرار کردن بین تصمیمات معماری و کسب‌وکار و استراتژی محصول یک ضرورت است. همان‌طور که گفته شد، تکنیک‌هایی مانند Wardley Mapping به این امر کمک می‌کند.با استفاده از استعاره سفر، نوسازیِ معماری، جریان‌های متعددی از فعالیت‌ها است. از جمله کشف فرصت‌های نوسازی جدید، طراحی معماری مدرن، ارائه نوسازی و یادگیری و ارتقا در سازمان. همان‌طور که در تصویر نشان داده شده است، فعالیت می‌تواند در هر جریان به‌طور همزمان در حوزه‌های مختلف اتفاق بیفتد. بعضی از قسمت‌های یک معماری را می‌توان قبل از شروع کشف در قسمتی دیگر مدرن کرد و به حلقه‌های بازخورد اجازه ظهور داد.مدرن‌سازی معماری به‌عنوان جریان‌های متعدد فعالیت‌های وابسته به هم که با ارتقای مهارت‌های مداوم پشتیبانی می‌شوند، نه مراحل مجزا.از آنجایی که مدرنیزاسیون، بسیاری از جنبه‌های مدل کسب‌وکار و عملیات را تحت تأثیر قرار می‌دهد، یادگیری و ارتقاء مهارت‌ها دو جنبه کلیدی هستند که از نظر اهمیت با سایر مسیرهای موجود در تصویر برابری می‌کنند. اینکه از کارکنان انتظار داشته باشیم سیستمی را با موفقیت مدرن‌سازی کنند، در حالی که سال‌هاست در یک طرز فکر معمولی کار می‌کنند، کاملا غیر واقع‌گرایانه است. علاوه بر این، معماری هرگز ثابت نیست و به‌طور مداوم با تغییر استراتژی و زمینه‌های کاری تکامل خواهد یافت. یادگیری و ارتقاء مهارت به این معنی است که همه تیم‌ها تکنیک‌هایی مانند EventStorming و مفاهیمی مانند Team Topologies را درک می‌کنند تا بتوانند به‌طور مداوم محل‌های پیشرفت‌ را شناسایی کرده و ارائه دهند.یکی از خطرات اصلی در هر سفر مدرنیزه شدن، تمام شدن انگیزه و بازگشت به کارهای معمولی و عادت‌های قدیمی است. برای حفظ شتاب بالا، باید یک تیم توانمندسازیِ مدرنیزاسیونِ معماری ( Architecture Modernization Enabling Team یا AMET) ایجاد شود. این تیم هدفش این است که با همکاری و رهبری اولویت‌های استراتژیک را تعیین کرده و از طرق مختلف از تیم‌ها در این سفر حمایت کنند. مثلا اگر تیمی با Event storming آشنا نیست مدتی به عنوان تسهیل‌گر در کارگاه‌های Event Storming حضور یابند. اگر تیمی مشکلی با تکنولوژی‌ها و معماری‌های مدرن دارد، مدتی به عنوان مربی‌ توسعه نرم‌افزار در این تیم‌ها حضور یابد. در مجموع با حمایت‌های خود شتاب سفر را بالا نگه دارد. AMET همچنین بر ایجاد شیوه‌های معماری پایدار و پرورش تغییرات پایدار متمرکز است که حتی پس از پایان مدرن‌سازی نیز ادامه می‌یابد.در این نوشته‌ها اصول و تکنیک‌های زیادی برای پیمودن یک سفر مدرن‌سازی ارائه خواهد شد اما یک راهنمای گام به گام یا یک چارچوب سفت و سخت ارائه نخواهیم کرد. شما همیشه باید به انواع سوالات زیر فکر کنید و در نهایت تصمیم نهایی را خودتان بگیرید:آیا می‌خواهید در سراسر کسب‌و‌کار گسترده‌تر شوید یا در یک منطقه‌ای خاص عمیق‌تر شوید؟آیا می‌خواهید از هم دور شوید و بسیاری از احتمالات را بررسی کنید یا روی یک تصمیم یا راه‌حل خاص همگرا شوید؟آیا می‌خواهید یک قدم کوچک‌تر و ایمن‌تر بردارید که ارزش کمتری ارائه می‌کند، یا یک گام بزرگ‌تر و پرخطرتر که ارزش بیشتری ارائه می‌کند؟چقدر زمان می‌خواهید روی مدرن‌سازی در مقابل ادامه توسعه ویژگی‌های معمولی و رفع اشکال سرمایه‌گذاری کنید؟استراتژی شما چیست؟ کجا باید تمرکز کنید، چقدر باید سرمایه‌گذاری کنید و چه چیزی را باید برون‌سپاری کنید؟مطمئن باشید، تکنیک‌ها و مفاهیم این نوشته مانند Event Storming، Wardley Mapping و Team Topologies امتحان و آزمایش شده است. این تکنیک‌ها شما را در شرایط بسیار خوبی قرار می‌دهند تا به این سوالات پاسخ دهید و در هر مرحله از سفر، تصمیم درستی بگیرید.8. پی‌نوشت:در طی چندین مطلب با مفهمون مدرن‌سازی معماری و تکنیک‌های مرتبط با ان آشنا خواهیم شد. بخش اعظمی از مطالب این نوشته از نوشته‌ها و سخنرانی‌های آقای Nick Tune گرفته شده و بعضا تجارب شخصی و مطالعات جانبی نیز به آن اضافه می‌شود که در این صورت منابع دیگر نیز معرفی خواهند شد.سال 1401 در روزهای ابتدایی سال نیت کردم که بیشتر بنویسم. و این نیت را به‌صورت عمومی بیان کردم. نتیجه این شد که سال گذشته هیچ مطلبی ننوشتم که البته دلایل زیادی داشت و عبور می‌کنم. به هر حال امیدوارم امسال بتوانم این مجموعه نوشته‌ها را تکمیل کنم و سال خوبی هم پیش روی همگی ما باشد. علیرضا ارومند علیرضا ارومند Sun, 30 Apr 2023 19:12:56 +0330 https://virgool.io/dotin/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%DA%A9%D8%AA%D8%A7%D8%A8-pro-microservice-with-net-6-xlkygsdy08wq 1. مقدمه:سال نو همیشه حال و هوای قشنگی داشته برای من. با اینکه از دیدگاه طبیعی اگر نگاه کنیم گردش چند روز مثل بقیه روزهاست، اما معمولا با بسیاری تصمیمات جدید و حال و هوای خوب شروع میشه. از رنگ قشنگ آسمان گرفته تا حال و هوای کوچه و خیابان همه تازه تازه است و بوی نویی میدن. بعد از چند روز تعطیلات هم که بر‌گشت به کار و تلاش جاذبه خودشو داره. البته همیشه اولین روزهای کاری بعد از تعطیلات برای من هم جذاب بوده و هم سخت. بعد از چند روز تعطیلات و آسودگی باید مجدد برگردیم سر کار و همه کارها و وظایف گذشته را با قدرت ادامه بدیم. قسمت جذابش دیدن همکارها و شروع مجدد کار و تلاش هست! قسمت غیر جذابش هم اینه که باید بعد از چند روز تعطیلات با قدرت برگردیم سر کار، آخه کی حال داره بعد از تعطیلات با قدرت شروع به کار کنه؟! از این حرف ها که گذر کنیم می‌رسیم به اصل ماجرا! یکی از تصمیماتی که گرفتم این بود که امسال کمی بیشتر بنویسم! هدف گذاری هم کردم و تعداد نوشته‌ها هم معلوم کردم که امیدوارم بتونم تا آخر سال به این هدف برسم که اگر رسیدم احتمالا جزئیاتش این فرایند هم به اشتراک خواهم گذاشت.همونطور که از عنوان نوشته مشخص هست اولین نوشته امسال به معرفی کتاب تخصیص داره! کتاب Pro Microservices in .NET 6 از انتشارات Apress که همین سال میلادی جدید منتشر شد و عنوان و زمان نشر نوید کتابی جذاب و خواندنی میده!قبل از اینکه به سراغ معرفی فصل‌ها و جمع بندی بریم یه نکته‌ای میگم و اینکه معمولا برای مباحث معماری و ... کتاب‌هایی که به یک فریم‌ورک و بستر خاص وابسته هستن را نمی‌پسندم، چون اغلب بیش از اینکه به مفاهیم و آموزش درست الگوها پرداخته بشه، به استفاده از ابزار و ... پرداخته میشه و جان کلامی که منتظر رسیدن به اون هستم در این کتاب‌ها مغفول باقی می‌مونه. اما در مورد این کتاب چند نفر از دوستان و همکارها از من پرسیدن که وقت بذاریم و بخونیم خوبه یا نه، برای اینکه بتونم نظر درستی بدم از تعطیلات 5 روزه استفاده کردم و کتاب رو مطالعه کردم، اینجا مطالب کتاب رو به اختصار خدمت همه به اشتراک می‌ذارم و تصمیم راجع به خواندن یا نخواندن کتاب رو به خوانندگان محترم واگذار می‌کنم!2. معرفی اولیه کتاب:کتاب در 9 فصل و 310 صفحه نوشته شده که 291 صفحه مطالب اصلی و الباقی صفحات شروع و پایان کتاب و ... هست. در توضیحات اولیه قید شده که همراه با مثال عملی و مناسب برای افرادی که تمایل به توسعه سیستم‌های توزیع شده دارن هست. اگر با پیش داوری جلو بریم می‌گم 291 صفحه برای کتابی در زمینه ‌میکروسرویس که حجم زیادی از این 291 صفحه به کد تخصیص داده شده احتمالا کمتر از چیزی هست که قرار باشه مفاهیم عمیقی به ما آموزش بده. اما به هر حال برای یافتن حقیقت ماجرا باید تا انتهای کتاب برسیم و بعد بتونیم قضاوت صحیحی داشته باشیم.3. فصل اول معرفی میکروسرویس‌ها:فصل اول این کتاب هم مثل بسیاری از کتاب‌های دیگه با معرفی اجمالی شروع میشه، در مورد این صحبت میشه که اصلا میکروسرویس چی هست و چرا باید به سمت میکروسرویس حرکت کنیم! از مزایای جذاب میکروسرویس میگه و بعد هم کمی در مصائب و سختی‌های توسعه میکروسرویس قلم فرسایی میشه. در ادامه فصل یک به طور کلی برخی از الگوهایی که هنگام توسعه میکروسرویس‌ها پرکاربرد هستن معرفی میشن. الگوهایی و روش‌هایی که معرفی شده به طول اجمالی شامل موارد زیر میشن:ارائه API f به کمک API Gatewayارائه APIهای تخصصی با Back-end for front-endتنظیمات و نگهداری آنها و به طول عمومی External Configurationارتباط RPCانتقال داده و فرمت‌های پیامانواع تست‌هاانتشار و استفاده از Dockerبررسی صحت عملکرد و Logging, Monitoring و Alteringالبته از این فصل توقع عمق آموزشی نداریم و صرفا آشنایی با نام‌ها و کاربرد این الگوها هدف ارائه در این فصل هست.4. فصل دوم ASP.NET Coreفصل دوم کتاب اما کلا از فضای میکروسرویس خارج شده و به معرفی ASP.NET Core 6 و مزایا، معایب و ویژگی‌های جدید اون میپردازه و اگر قبلا با دات نت کار کردید این فصل چیز جدیدی برای ارائه نداشته و به راحتی و بدون نگرانی از اینکه نکته خاصی از دست بدید میتونید از این فصل عبور کنید.5. فصل سوم در جستجوی میکروسرویس‌ها:یکی از سخت ترین کارهایی که هنگام توسعه میکروسرویس با اون سر و کار داریم پیدا کردن محدوده سرویس‌‌هایی هست که داریم. مبحثی که در فصل سوم از کتاب به آن پرداخته شده. ابتدا توضیحاتی مختصر در مورد کاربر DDD برای شناسایی محدوده و تکنیک‌های اون ارائه میشه، مواردی مثل Domain, Subdomain, UL, Bounded Context و ... از عمده مطالبی هستن که در مورد DDD بیان شدن. بعد کتاب به سراغ معرفی Event Storming‌ به عنوان تکنیکی جهت مکاشفه در دامنه میره. کلیات چیستی Event Storming و بیان نحوه برگزاری ورکشاپ به طور خیلی سریع در این قسمت اتفاق افتاده.درادامه این فصل در مورد کسب و کاری که قرار هست مثال‌های کتاب در مورد اون کسب و کار باشه هم صحبت شده و آمادگی لازم جهت ادامه مطالب ایجاد شده.6. فصل چهارم توسعه اولین میکروسرویس:کتاب در فصل چهارم خیلی سریع به سراغ اولین میکروسرویس رفته و اگر از اینجا به بعد قرار باشه با کتاب همراه بشیم باید دست به کد بشیم. پس قبل اینکه سراغ این فصل بریم باید سیستم خودمون رو برای توسعه آماده کنیم. در این فصل اولین سرویس از مجموعه سروریس‌های مورد نیاز توسعه داده میشه. سرویسی که در اون قرار هست از APIهای گوگل استفاده کنیم و فاصل و ... محاسبه بشه و در اختیار سایر بخش‌ها قرار بگیره. هدف اصلی این فصل آموزش ارتباط Sync و کاربرد Rest و Json‌ در برقراری ارتباطهای داخلی سرویس‌ها هست.برای اینکه کتاب به هدف خودش برسه ابتدا راجع به Inter-process Communication صحبت شده و سختیها و پیچیدگی‌های ارتباط میکروسرویس ها بیان شده. در ادامه در مورد فرمت Json‌برای فرمت انتقال پیام و Rest و gRPC به عنوان بستر انتقال پیام مطرح شده.به عنوان کار عملی سرویس محاسبه مسافت به کمک گوگل پیاده سازی شده و به کمک Rest و gRPC این سرویس در اختیار سایرین قرار گرفته.7. فصل پنجم ارتباط Async:ارتباطات Sync همیشه به عنوان چالشی در توسعه سیستم‌های توزیع شده مطرح بودن و اغلب در شرایطی که امکان این کار وجود داشته باشه تلاش میشه که با ارتباط Async جایگزین بشن. فصل پنجم این کتاب هم سراغ همین موضوع رفته و در مورد ارتباط Async صحبت به میان آورده. اول از همه بحث در مورد معایب روش‌های Sync انجام شده و بعد روش برقراری ارتباط Async به عنوان حلال مشکلات در این کتاب معرفی شده. قابلیت‌هایی مثل توزیع پذیری بهتر، وابستگی کمتر و بافرکردن پیام‌ها از عمده مطالبی هستن که در این فصل به عنوان مزایای اترباط Async شمرده میشن. در ادامه در مورد انواع پیام‌ها مثل Command, Query, Event صحبت شده و اینکه هر کدام از این پیام‌ها چه کاربرد و شرایطی دارن.بعد هم کتاب به برخی چالش‌ها و مشکلاتی که هنگام ارسال پیام‌ها به صورت Async‌خواهیم داشت، پرداخته است. مطالبی مثل اینکه چطور مطمئن شویم پیام یک باید یا حداقل یک بار ارسال می‌شود؟ یا اینکه اگر پیام‌ها با ترتیب صحیح ارسال نشود چه چالشی خواهیم داشت!فصل با یک مثال به پایان رسیده است. مثال این فصل در مورد سرویس‌های صورت حساب و پرداخت است و برای پیاده سازی این مثال‌ها از Masstransit به همراه RabbitMQ استفاده شده است. پس برای پیاده سازی مثال این فصل به جز دات نت به RabbitMQ‌هم نیاز پیدا خواهید کرد. البته اگر داکر نصب داشته باشید کار ساده خواهد بود و بدون مشکل مثال این فصل هم پیاده سازی خواهد شد.8. فصل ششم داده‌های توزیع شده:تا زمانی که داده‌ها در یک دیتابیس نگهداری می‌شود بسیاری از چالش‌ها از دید توسعه دهنده پنهان است. اما هنگامی که سراغ سیستم توزیع شده می‌رویم کارهای ساده ای مثل پیاده سازی یک فرایند به صورت Transactional یا یک کوئری تجمیعی گرفتن تبدیل به کابوس‌های وحشتناکی خواهند شد. موضوع داده‌های توزیع شده بحث اصلی این فصل است. الگو‌های زیادی در این فصل معرفی می‌شود. در مورد اینکه اگر دیتابیس‌ها مشترک باشد چه اتفاقی رخ می‌دهد صحبت می‌شود. در مورد تئوری CAP بحث به میان آمده و در ادامه برای مدیریت تراکنش‌ها الگوی SAGA معرفی می‌شود. سپس به سراغ الگوی CQRS و جداسازی و فرایند‌های خواندن و نوشتن ‌میرود. در مورد اینکه این کار می‌تواند در سطوح مختلف و با شرایط متفاوت انجام شود گفتگو می‌شود و بعد از پایان بحث در مورد CQRS طبق روال بسیاری از کتابها و مقالات مستقیم وارد Event sourcing می‌شود. بعد از اینکه بحث در مورد این دو الگو به پایان می‌رسد کتاب در مورد Eventual Consistency صحبت به میان می‌آورد اینکه بعضا در سیستم‌های توزیع شده چاره‌ای جز پذیرش این موضوع نداریم. البته کتاب در این فصل بیان می‌کند که بحث در مورد داده‌های توزیع شده فراتر از یک فصل از این کتاب است و در عوض یک کتاب بسیار عالی برای مطالعه در این زمینه معرفی می‌کند. کتاب The Art of Immutable Architecture کتابی است که در این فصل معرفی می‌شود که از نظر شخصی من کتابی بسیار عالی و آموزنده است و خواندن آن برای هر کسی که با سیستم‌ها و داده‌های توزیع شده سر و کار دارد واجب است. 9. فصل هفتم تست میکروسرویس‌هاشاید تا 10 - 12 سال پیش اگر کتابی قرار بود در مورد تست صحبت به میان آورد ابتدا باید چند فصلی را به این مورد می‌پرداخت که تست خوب است و باید برای آن زمان گذاشته شود و ...اما این روزها دیگر در هر تیم توسعه‌ای پذیرفته شده است که باید تست خودکار داشت و برای توسعه تست هم به اندازه توسعه و چه بسا بیشتر باید زمان و هزینه در نظر گرفته شود و داشتن تست دیگر صرف زمان و هزینه بیهوده در نظر گرفته نمی‌شود بلکه بخشی از سرمایه گذاری بلند مدت و پر بازده هر پروژه نرم‌افزاری است. به همین دلیل کتاب در مزایای تست نویسی مطلبی بیان نمی‌کند بلکه فورا به سراغ خود مبحث تست می‌رود. ابتدا به این مطلب می‌پردازد که احتمال خطا در سیستم‌های توزیع شده بالاست و بدون تست یافتن خطاها بسیار مشکل خواهد بود. در ادامه به سراغ سطوح تست می‌رود و هرم تست معرفی می‌شود و اینکه در هر سطح از این هرم چه مقدار تست خواهیم داشت و هر تست چه هزینه و آورده‌ای برای پروژه به ارمغان می‌آورد. در بخش بعد به سراغ Contract Test رفته و با معرفی خیلی سریع از Consumer Driven Contract Testing به سراغ یک مثال عملی می‌رود. در این قسمت برای APIهایی که ارائه شده است به کمک PactNetمثال عملی ارائه می‌شود که اگر با این مبحث آشنایی نداشته باشیم در این مثال خیلی سریع و ساده این موضوع آموزش داده می‌شود که به نظرم شخص خودم ن یکی از بهترین بخش‌های کتاب است. بعد از پایان این قسمت هم به سراغ یک مثال عملی برای پیاده سازی تست در محیط ارتباطی Async می‌رود.10. فصل هشتم انتشار میکروسرویس‌ها و داکر:در این فصل به مبحث انتشار میکروسریس‌ها پرداخته می‌شود. داکر ابزار اصلی و مناسب جهت انتشار میکروسرویسها است که در این فصل در مورد آن گفتگو شده است. ابتدا در مورد چرایی نیاز به کانتینرها صحبت به میان آمده است. سپس در مورد اینکه داکر چیست و چگونه نصب می‌شود گفتگو شده است. در ادامه برخی دستورات بسیار پر کاربرد داکر برای اجرا و توقف کانتینرها و دیدن Image ها و ... معرفی شده است.در بخش بعدی نیز در مورد کوبرنتیز و چیستی آن و چگونگی استفاده از آن صحبت به میان آمده است که مبتنی بودن بر Azure‌ در این قسمت شاید اصلی ترین چالش ما در ایران باشد.11. فصل نهم سلامت میکروسرویس‌ها:آخرین فصل از کتاب نیز به مباحثی می‌پردازد که در توسعه هر نرم‌افزاری بسیار مهم است و در هنگام استفاده از سیستم‌های توزیع شده حیاتی‌تر به نظر می‌رسند. ابتدا در مورد سلامت سرویس‌ها و اینکه چه شرایطی ممکن است باعث عدم دسترسی و صحت عملکرد میکروسرویس‌ها شود صحبت به میان می‌آید. در ادامه در مورد اینکه Log چیست و چه کاربردی دارد و اینکه چگونه به کمک Serilog در ASP.NET Core می‌توانیم Log داشته باشیم بحث شده است. در بخش بعد در مورد Metricها صحبت به میان می‌آید. ما به کمک Log می‌توانیم یک رخداد را با جزیئات مورد بررسی قرار دهیم. اما اگر بخواهیم دید کلی از نرم‌افزار خود داشته باشیم باید سراغ Metricها برویم و مباحث را به صورت تجمیعی مورد مطالعه قرار دهیم. در این قسمت Prometheus و نحوه استفاده از آن در ASP.NET Core بررسی شده است.به عنوان بخش بعدی هم کتاب در مورد Tracing مباحثی را به میان آورده و اینکه چگونه به کمک Tracing می‌توان فرایند پردازش درخواست‌ها بین سروریس‌های مختلف را مورد بررسی قرار داد. در این بخش در مورد OpenTelemetry و استفاده از آن در .NETنیز سخن‌هایی به میان آمده است. این فصل از کتاب با مباحث مانیتورینگ موثر در سیستم‌های توزیع شده و دیباگ کردن پروژه‌ها به کمک لاگ به پایان رسیده است.12. جمع بندی:این تمام آن چیزی بود که در این کتاب مطالعه می‌کنید. به عنوان یک خواننده چند نکته نهایی در مورد این کتاب به ذهنم می‌رسد که بیان می‌کنم. در صورتی که بخواهید کد‌های کتاب را پیاده سازی نکنید و صرفا مطالعه تئوری داشته باشید، مطالعه این کتاب را چندان پیشنهاد نمی‌کنم چون مطالب بسیار سطحی و اجمالی بیان شده است. اما اگر توسعه دهنده دات نت باشید و کدهای ارائه شده را پیاده سازی کنید ماجرا متفاوت خواهد بود. برای پیاده سازی کدها اگر از روش Copy & past programming استفاده کنیم برای هر فصل حدود 1.5 تا 2 ساعت زمان نیاز داریم و در صورت نوشتن دستی به حدود 4 ساعت زمان نیاز است. با توجه به اینکه ابزارهایی که معرفی شده است بسیار پر کاربرد است و در قالب یک مثال عملی بدون هیچ تکلف و سختی ابزار مورد استفاده قرار گرفته است برای شروع کار می‌تواند بسیار راهگشا و جذاب باشد. در کل به عنوان یک کتاب کامل از این کتاب نباید توقع داشته باشیم. ولی اگر بخواهیم خیلی سریع با الگوها و روش‌های توسعه میکروسرویس‌ها آشنایی پیدا کنیم کتاب مناسب و کاربردی خواهد بود.با آرزوی سالی پر از موفقیت و سلامتی برای همه! علیرضا ارومند علیرضا ارومند Sat, 26 Mar 2022 11:23:12 +0430 https://virgool.io/dotin/%DA%86%D9%87-%DA%A9%D8%B3%DB%8C-%D8%AA%DA%A9%D9%84-%D8%A7%D8%B2-%D9%BE%D8%B4%D8%AA-%D8%B1%D9%81%D8%AA-%DB%8C%D8%A7-%D9%85%D9%82%D8%B5%D8%B1-%D8%B4%DA%A9%D8%B3%D8%AA-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%DA%A9%DB%8C%D9%87-lpbamohvoww1 کلا خیلی سراغ نوشتن مطالب غیر فنی نمیرم. آخرین بار دو سال پیش مطلبی در مورد انتخاب زبان‌های برنامه نویسی و نحوه انتخاب زبان برنامه نویسی دلخواه خودمون نوشتم که اگر دوست داشته باشید میتونید اون مطلب رو اینجا بخونید! این مطلب هم مثل مطلب قبلی نه خیلی فنی حساب میشه نه غیر فنی! بیشتر بیان عقاید شخصی خودم در نظر بگیرید!چی شد که مجدد سراغ نوشتن مطلب غیر فنی رفتم؟دو روز پیش با یکی از همکاران خوبم گفتگویی داشتیم که باعث شد به سراغ این موضوع برم و این بار از دیدگاه ترکیبی با محصول و فنی داستان خودمون رو بررسی کنم! با این مقدمه بریم سراغ اصل ماجرا و اینکه قصه از کجا شروع شد!سوالی که همکارم از من پرسید این بود "در بعضی از شرایط محصول و پشتیبانی از اون خیلی بغرنج میشه. هزینه پشتیبانی از اون خیلی زیاد میشه و کار بیش از اینکه سود داشته باشه ضرر داره و اعضای تیم از این شرایط رنج می‌برن. به نظرت این مشکل از کجا بروز پیدا میکنه و مقصر این ماجرا کیه؟"واقعا مقصر این شرایط توی محصولات کیه؟! بیاید جواب‌های موجود رو با هم بررسی کنیم که البته کامل نیست و میشه به این لیست موارد دیگه ای هم اضافه کرد که برای جلوگیری از زیادی طولانی شدن مطلب به چند مورد خاص قناعت می‌کنم!جواب اول و قطعی به این مسئله میشه تیم توسعه! قاعدتا تیم توسعه که دانش فنی پایینی داره و در کنار دانش فنی پایین با درک کمی از فضای مسئله و تحلیل ناکافی شروع به کدنویسی میکنه در نهایت محصول نهایی که ایجاد میکنه چیزی بیش از یک فاجعه به تمام معنا که در روزهای اولیه ارائه در نقطه شکست پروژه قرار داره نیست! معمولا در این پروژه‌ها نه معماری درست انتخاب شده! نه مسئله درست فهمیده شده! نه راه حل درستی برای مسئله ارائه شده. کلا به دنبال هر نکته مثبتی تو این پروژه‌ها بگردیم چیزی به دست نخواهیم آورد!اما یک نکته! تیم توسعه که در شرایط فشار داره کار میکنه فرصت نفس کشیدن نداره مگه فرصتی برای فکر کردن داره؟ مگه میتونه زمان بذاره و دانش خودش رو به روز کنه؟ تیم برنامه نویسی در بعضی موارد صرفا ماشین کدنویسیه! بدون کوچکترین اراده و قدرت تصمیمی! جواب دوم و قطعی میشه مجموعه تیم پشتیبانی! بله حتما تیم پشتیبانی مقصر این ماجراست! چرا؟ چون تیم برنامه نویسی بیچاره و بیگناه داره صبح تا شب کد می‌نویسه! این مسئولیت تیم پشتیبانیه که هم باید محصول رو درست برای مشتری پرزنت کنه که کمترین مشکلات رو مشتری توی استفاده داشته باشه و هم در هنگام بروز مشکل باید در سریع ترین زمان، مشکل رو پیدا کنه و راهکاری ارائه کنه و رضایت مشتری رو جلب کنه! اینجوری شرایط تیم برنامه نویسی هم رفته رفته بهتر میشه و مشکلات هر روز کمتر میشه و به آرامش میرسیم!نکته این جواب کجاست؟ اینجاست که خوب اون مصیبتی که تحویل شده اصلا قابلیت پشتیبانی نداره! مثل اینه که پراید تحویل تعمیرکار بدیم و بعد ازش توقع داشته باشیم بعد از تعمیر کیفیت بنز به ما تحویل بشه! خوب این ماجرا هم نشدنیه!جواب سوم و این بار دیگه واقعا قطی میشه Product Owner. بله PO کسی که همیشه مقصر ماجراست! چرا؟ دقیقا چون مسئولیت محصول با اونه! حتما شناخت درستی از محصول و بازار محصولش نداشته و نتونسته تیم توسعه رو درست راهنمایی کنه! درسته تیم توسعه کمی دانش فنی ضعیفی داره! ولی اینکه تیم فنی مسئله رو به درستی نشناخته حتما مقصرش PO بوده و بیشتر مشکلات هم که ناشی از عدم شناخت درست و اولویت بندی درست کارها بوده! در ضمن PO بوده که میتونسته تصمیم بگیره فشار کار کم کنه یا زیاد کنه و ... پس آقا یا خانم PO از زیر بار مسئولیت فرار نکن! مسئول محصول شما هستی! باعث فجایعی هم که به وجود میاد خود شما هستی!البته کمی هم اگر به درد و دل این بندگان خدا گوش بدیم میبینیم که بی‌گناه هستن! حتما میگن من قدرت تصمیم گیری کمی دارم! Product Manager کاری رو با یک فورث زمانی به عهده من میذاره! سراغ مشتری هم که میرم بد قولی می‌کنه! خودش نمی‌دونه چی می‌خاد! خواسته‌هاشو دیر بیان میکنه! وقتی از مشتری میخام کار رو تحویل بگیره خیلی دیر این کارو میکنه و منم در نهایت دیر بازخورد میگیرم و ...خوب کم کم داریم مقصر اصلی رو پیدا میکنیم و اون کسی نیست به جز PM. همون کسی که هیچ کاری نمی‌کنه! فقط نشسته که از بالا بهش پروژه پیشنهاد بشه و اون پروژه رو توی واحد بندازه گردن یک تیم که پیش ببره و از این جریان لذت ببره! چون خودش قرار نیست هیچ کاری بکنه. فقط و فقط استراحت میکنه تا محصول به ثمر برسه! اصلا در جریان جزئیات تیم نیست! در جریان فشاری که روی تیم وجود داره و عدم هماهنگی های بین اعضای تیم و مشتری و ... نیست! اصلا لعنت به PM و هرچی که هست!حالا بریم ببینیم این جلاد بالفطره که تو عصر نوین با عنوان PM شناخته می‌شه حرفی برای گفتن داره؟! بله از پشت صحنه اشاره می‌کنن که PM گفته من هر روز درگیر 1000 تا کار و جلسه مختلف هستم. باید گزارش‌های روزانه و هفتگی و ماهانه و فصلی و سالانه و قرنی و ... از شرایط تیم و پروژه‌ها بدم تا بتونم واحد و کار رو سر پا نگه دارم! باید با واحد‌های دیگه تعامل کنم و باید با مشتری تعامل کنم که کار کمی پیش بره! تازه هر وقت هم سرم خلوت میشه با اعضای تیم جلسه میذارم و ازشون در مورد شرایط کار و ... می‌پرسم و همیشه به من میگن شرایط خیلی خوبه و داریم با قدرت به جلو میریم! خوب گویا PM هم بی گناهه! دو تا متهم داریم اول کمی گویا باید سراغ اسکرام مستر‌ها بریم که شرایط تعاملی تیم رو درست نکردن و نتونستن روح تیمی رو خوب پرورش بدن ! گزینه دوم هم لایه‌های بالاتر مدیریتی و ... است. این چرخه معیوب مقصر پیدا کردن تا بی‌نهایت قابل بررسی کردن هست! اما به چند دلیل دیگه سراغ مقصر‌های جدید نمی‌ریم! اول اینکه زمان محدوده و امکان نوشتن همه مقصرها نیست و در ضمن مطلب حوصله سربر میشه! دوم اینکه کم کم به مقصرهایی در لایه‌های بالا می‌رسیم و احتمال مخاطرات شغلی ایجاد میشه و ممکنه تو کارمون صیانت بشیم پس عقل سلیم حکم می‌کنه زبان به کام بگیریم! سوم هم اینکه بسه همینقدر واقعا! حالا جواب واقعی به نظر شما چی می‌تونه باشه!؟ من به این سوال از دیدگاه خودم جواب میدم. ممکنه شما با این پاسخ موافق یا مخالف باشید! ولی به هر حال نظر خودمه و برای خودم قابل احترام! :-)از نظر من موفقیت یک پروژه هرگز به تنهایی یک سوپرمن و ابر قهرمان نداره! بلکه مجموعه شرایط باعث موفقیت کار میشن! برای موفقیت محصول مشتری، CTO و منابع انسانی، مدیر محصول، مالک محصول، تیم توسعه، اسکرام مستر، تیم پشتبانی و ... همه باید همزمان بهترین کار خودشونو ارائه بدن! در مورد شکست پروژه هم دقیقا شرایط به همین شکل هست! شکست یک پروژه یک مقصر نداره! باید یادمون باشه همه با هم یا به موفقیت می‌رسیم یا شکست می‌خوریم. از شکست همه متضرر میشیم از مدیرعامل تا ... ! وقتی شرایط خراب میشه همه اعضای چرخه اجرای پروژه با هم مقصر هستن. هر کس به اندازه خودش توی شکست نقش داره! به نظرم بهتره به جای چرخه ناقص پیدا کردن مقصر و فرار از زیر بار مسئولیت راهکار بهتری پیدا کنیم. از نظر من یکی از راهکارهای مفید اینه که هر کسی دانش درستی از نقش و تاثیر خودش داشته باشه، کار خودش رو به موقع و درست انجام بده و مهم تر از همه چرخه صحیح بازخورد دادن داشته باشیم! به جای اینکه صبر کنیم تا اسیر شرایط بشیم و شکست بخوریم و دنبال مقصر یا راه فرار بگیردیم باید هدف واضح و روشن برای همه اعضای دخیل در چرخه کار داشته باشیم. با بازخورد درست و به موقع و بدون تعصب دادن به موقع جلوی خروج از مسیر رسیدن به هدف رو بگیریم و در ادامه در هرجایگاهی که هستیم روحیه بازخورد گرفتن داشته باشیم. درک کنیم که بازخورد گرفتن بیش از اینکه یک مسئله شخصی باشه که قراره ما رو خراب کنه، یک موضوع کاملا کاری هست که ما رو در مسیر پیشرفت و رسیدن به هدف قرار میده! علیرضا ارومند علیرضا ارومند Thu, 23 Dec 2021 14:32:28 +0330 https://virgool.io/dotin/%D8%B7%D8%B1%D8%AD-%D9%87%D8%A7%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-41-%D9%85%D8%AF%D9%84-%D9%86%D9%85%D8%A7%DB%8C%D8%B4-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-l2hopby4ltex 1. چکیده:در این مقاله قصد داریم مدلی را برای توصیف معماری سیستم‌های نرم‌افزار با استفاده از نماهای متعدد و همزمان ارائه کنیم. استفاده از چندین نما این امکان را فراهم می‌آورد تا به صورت جداگانه به نگرانی های ذینفعان مختلف معماری پرداخته شود. کاربر نهایی، توسعه دهندگان، مهندسان سیستم ها، مدیران پروژه و غیره هریک نیازمندی‌های خاص خود را دارند. از سوی دیگر به کمک این نما‌های مختلف می‌توانیم نیازهای عملکردی و غیر عملکردی را نیز به درستی مورد بررسی قرار دهیم. در این مطلب 5 نمای مختلف برای معماری توضیح داده شده که هر یک از این پنج نما به همراه یک روش برای ثبت آن توضیح داده شده است. نماها با استفاده از یک فرآیند توسعه تکراری، مبتنی بر سناریو و معماری محور طراحی شده‌اند.2. مقدمه:همه ما تا کنون مقالات و کتب زیادی، که قصد داشته‌اند لب کلام معماری یک سیستم نرم‌افزاری را در قالب یک طرح ارائه کنند مشاهده کرده‌ایم. با کمی دقت در طرح‌های ارائه شده در این کتب و مقالات در خواهیم یافت که نویسندگان آن‌ها تلاش زیادی انجام داده‌اند تا به کمک شکل‌ها و فلش‌ها و علامت‌ها و ... تجمیع شده کنار هم بیش از یک مفهموم را در یک طرح بگنجانند. برای مثال واقعا هر کدام از Boxهای داخل تصویر چه چیزی را نمایش می‌دهند؟ آیا هدف نمایش بخش اجرایی از نرم‌افزار است؟ قرار است بخشی از سورس کد را نمایش دهند؟ گروهی از کامپیوتر‌های فیزیکی همکار را نمایش می‌دهد؟ هدف از فلش‌های این نمودار‌ها چیست؟ نمایش وابستگی سورس‌کدها هنگام کامپایل؟ جهت کنترل جریان؟ جهت حرکت داده‌ها؟ در حقیقت این طرح‌ها جواب همه این سوال‌ها هستند. اما آیا معمار نیازی به داشتن یک ابزار و روش جهت انجام کار خود دارد؟ بعضا معماری سیستم از خورد شدن بسیار زیاد در ابتدای کار آسیب می‌بیند. در برخی موارد تمرکز زیاد از حد روی قسمتی از سیستم می‌تواند موجب ایراد در معماری شود. مثلا تلاش زیاد برای طراحی بهینه ساختار داده‌ها از ابتدای کار، یا تمرکز بیش از حد روی سرعت بالای اجرای برنامه از ابتدا. در بسیاری از موارد این چنین طرح‌هایی نیازهای افراد مختلف درگیر در پروژه را پاسخ نمی‌دهند. به عنوان یک راه حل در این مقاله قصد داریم طرح‌ها و نما‌هایی را ارائه کنیم که به طور همزمان باید در مدل‌های یک سیستم مبتنی بر نرم افزار ارائه شود تا تمامی نیاز‌های تمامی افراد درگیر در پروژه پاسخ داده شود.3. یک مدل معماری:معماری نرم افزار به طراحی و پیاده‌سازی ساختار سطح بالای نرم افزار می پردازد. معماری نرم‌افزار نتیجه کنار‌هم قراردادن تعدادی اجزای منتخب در یک فرم خوب کنار هم می‌باشد. این کنارهم قراردادن باید موجب پاسخ‌گویی به نیاز‌های کاربردی و غیرکاربردی نرم‌افزار شود. پری و ولف این موارد را در قالب یک فرمول که تغییر یافته فرمول آقای بوهم می‌باشد ارائه کرده اند.Software architecture = {Elements, Forms, Rationale/Constraints}معماری نرم‌افزار با مواردی مثل انتزاغ، ترکیب، تجزینه، سبک و زیبایی شناسی سر و کار دارد. برای نمایش معماری ما از چندین طرح یا چشم انداز یا نما استفاده می‌کنیم. برای اینکه بتوانیم معماری یک سیستم بزرگ‌را نمایش دهیم، ما در مدل خود از 5 طرح اصلی استفاده می‌کنیم. نمای منطقی یا Logical view: هنگام استفاده از OOP مدل طراحی اشیا است.نمای فرایند یا Process view: جنبه های همزمانی و همگام‌سازی طراحی را نشان می دهد،نمای فیزیکی Physical view: نگاشت(های) نرم افزار را بر روی سخت افزار توصیف می کند و جنبه توزیع شدن آن را منعکس می کند.نمای توسعه یا Development view: سازماندهی ایستای نرم افزار را در محیط توسعه توصیف می کندتوصیف معماری یک سیستم به کمک این چهار طرح قابل ارائه است و در ادامه به کمک تعدادی مورد کاربرد منتخب شرح داده می‌شود. این موارد کاربرد پنجمین قسمت از پازل ما را تشکیل می‌دهند. در ادامه به توضیح دقیق تر این موارد می‌پردازیم. مدل نمایش 4+1معادله Perry & Wolf را به‌طور مستقل روی هر نما اعمال خواهیم می‌کنیم، یعنی برای هر نما مجموعه‌ای از عناصر قابل استفاده را تعریف می‌کنیم مثلا کامپوننت‌ها، کانتینرها و رابط‌ها را بیان می‌کنیم. برای هر نما، الگوها و فرم‌های کارامد را می‌گیریم، منطق را درک می‌کنیم و محدودیت‌ها را مد نظر قرار می‌دهیم، و با توجه به همه این شرایط با عناصری که در اختیار داریم معماری را بیان می‌کنیم. معماری ما در این شرایط برگرفته از نیازمندی‌های نرم‌افزار است.در این روش هر نما در طرحی که شامل نماد‌های خاص خود است ترسیم می‌شود. برای هر نما معماران می‌توانند سبک خاصی از معماری را مورد استفاده قرار دهند و این امکان وجود دارد که سبک‌های مختلف معماری در یک کار با هم همزیستی مسالمت آمیز داشته باشند. حال قصد داریم هریک از نماها را بررسی کنیم و ببینیم هر نما چه هدفی دارد و در مورد هر نما عناصر قابل استفاده در آن و نحوه استفاده از آن‌ها را مشاهده خواهیم کرد. برای ارائه نماها از مثال‌های ساده شدهای از یک سیستم کنترل ترافیک هوایی و سیستم PABX که برای Alcatel Business قبلا طراحی کرده بودم، استفاده کرده‌ام. دقت داشته باشید که هدف ما صرفا ارائه نحوه بیان معماری سیستم‌های نرم افزاری است، به همین دلیل سیستمی که معماری آن‌را تعیین می‌کنیم ساده در نظر گرفته شده است. مدل 4+1 بسیار عمومی طراحی شده است و این قابلیت وجود دارد که در کنار سایر طرح‌ها مورد استفاده قرار گیرد. 4. نمای منطقی(تجزیه شی گرا):هدف این طرح پشتیبانی از نیازمندی‌های عملکردی است. اینکه چه عملکردی توسط این سیستم باید برای کاربران فراهم شود در حیطه مسئولیت‌های این طرح قرار داد. معمولا سیستم به چندین قسمت که از دامنه اصلی تشخیص داده می‌شود در قالب اشیا یا کلاس‌ها تجزیه می‌شود. در این تقسیم بندی از اصولی مثل ارث‌بری انتزاع و کپسوله سازی استفاده می‌شود. این تجزیه صرفا به خاطر تحلیل عملکردی سیستم نیست. بلکه به ما در شناخت قسمت‌های مختلف سیستم و مکانیزم‌های موجود نیز کمک می‌کند. ما برای طراحی این قسمت از روش رشنال/ بوچ استفاده می‌کنیم یعنی کلاس دیاگرام‌ها و کلاس تمپلیت‌ها. یک کلاس دیاگرام مجموعه‌ای از کلاس‌ها و روابط منطقی آن‌ها مثل تجمیع، ترکیب، استفاده و ... را نمایش می‌دهد. مجموعه‌ای از کلاس‌های مرتبط با هم در قالب class category با هم دسته بندی می‌شوند. در ادامه کلاس تمپلیت روی جزئیات کلاس‌ها تمرکز می‌کند. در کلاس تمپلیت ویژگی‌های اصلی کلاس و عملکرد‌های آن تشخیص داده می‌شود. اگر نیاز داشته باشیم که عملکرد داخلی یک کلاس را مدل کنیم از State Chart یا State Transition diagram استفاده می‌کنیم. موارد و عملکرد‌های عمومی در Class Utilities تعریف می‌شود. در صورتی که نرم افزار ما بیشتر از داده‌محور باشد تا دامنه محور، به جای این دیاگرام‌ها از E-R دیاگرام استفاده می‌کنیم.4.1. علامت‌گذاری‌های نمای منطقی:برای علامت گذاری طرح منطقی از روش بوچ استفاده می‌کنیم. در این علامت‌گذاری‌ها به طور قابل توجهی ساده‌سازی انجام شده است و صرفا علامت‌هایی که از نظر معماری کمک می‌کنند در نظر گرفته می‌شوند.علامت گذاری طرح منطقی4.2. سبکی برای نمای منطقی:برای این نما از سبک Object Oriented استفاده کرده‌ایم. راهنمای اصلی برای طراحی نمای منطقی این است که سعی کنید یک مدل شی منسجم و واحد را در کل سیستم نگه دارید و از تخصصی شدن بیش از حد و زودهنگام کلاس‌ها دوری کنید. نمونه‌ای از طرح منطقی مرتبط با مثال را در تصویر زیر مشاهده می‌کنید.نمونه‌ای از طرح منطقیسیستم PABX ارتباطات بین Terminlها را برقرار می کند. یک ترمینال می‌تواند یک دستگاه تلفن، یک خط ارتباط اصلی، یک ارتباط خصوصی، یک خط ارتباطی ویژه یا ... باشد. خطوط مختلف توسط کارت‌های رابط خط مختلف پشتیبانی می شوند. مسئولیت یک شی Controller خط، رمزگشایی و تزریق تمام سیگنال های روی کارت رابط خط است. Controller سیگنال‌های مخصوص کارت‌ها را به مجموعه کوچکی از رویدادهای یکدست تبدیل می‌کند. رویداد‌هایی مانند Start, Stop, Digit و ... در مجموعه رویدادهای یکدست وجود دارند. این کلاس زیرکلاس‌های متعددی برای انواع اینترفیس‌ها دارد. مسئولیت شی terminal حفظ وضعیت یک terminal و مذاکره در مورد خدمات از طرف آن خط است.برای مثال، از خدمات Numbering Plan برای تفسیر شماره گیری در مرحله انتخاب استفاده می کند. Conversation مجموعه ای از Terminalهای درگیر در یک مکالمه را نشان می دهد. conversation از Translation Service (دایرکتوری، نقشه برداری آدرس فیزیکی منطقی، مسیرها) و Connection Service برای ایجاد یک مسیر صوتی بین Terminal ها استفاده می کند.برای مثالی از یک سیستم بزرگتر هم به تصویر دوم دقت کنید. این تصویر مربوط به سیستم کنترل ترافیک هوایی است که کلاس‌های مهم در سطح معماری آن در این تصویر مشاهده می‌شود. کلاس‌های مهم این طرح شامل 8 گروه کلاس می‌شود که در تصویر قابل مشاهده است. 5. نمای فرایند ( تجزیه فرایند):هنگامی که در مورد معماری و نمای فرایند صحبت به میان می‌آیند هدف ما ویژگی‌های غیرکاربردی نرم‌افزار مثل بهره‌وری و دردسترس بودن است. وقتی در مورد مباحثی مانند همزمانی، توزیع‌پذیری، یکپارچگی، تحمل خطا، در دسترس بودن صحبت می‌کنیم همیشه نمای فرایند به کمک ما می‌آید. معماری فرایند را در چندین سطح می‌توان بیان کرد که هر سطح به نگرانی‌های خاصی توجه کرده و به آن‌ها پاسخ می‌دهد. در بالاترین سطح، معماری فرایند را می توان به عنوان مجموعه‌ای از شبکه‌های منطقی برنامه‌هایی دید که به طور مستقل اجرا می شوند (که «فرایندها» نامیده می شوند)، و این شبکه‌های منطقی از برنامه‌ها در مجموعه ای از منابع سخت افزاری که در یک LAN یا یک WAN در کنار هم قرارگرفته‌اند، توزیع شده اند. برای مثال شبکه‌های منطقی ممکن است برای جدا سازی سیستم‌های عملیاتی و آنلاین از سیستم‌های آفلاین مورد استفاده قرار‌گیرند. هر از تعدادی وظیفه که یک واحد اجرایی را تشکیل می‌دهد ساخته شده است. فرایندها نشان دهنده سطحی هستند که در آن معماری فرایند را می توان به صورت تاکتیکی کنترل کرد. مثلا شروع کرد، پایان داد، بازیابی یا خاموش کرد. در کنار این شرایط فرایند‌ها را می‌توان برای توزیع بار یا بالابردن دسترس پذیری تکثر کرد. نرم افزار به مجموعه ای از وظایف (Task) مستقل تقسیم می شود. یک وظیفه یک رشته کنترل جداگانه است که می تواند به صورت جداگانه در یک گره پردازشی برنامه ریزی شود.با این شرایط می‌توانیم گروه‌های متفاوتی از وظایف را تشخیص دهیم. برخی از آن‌ها وظایف اصلی هستند که از منظر معماری قابل بررسی و هستند و برخی دیگر وظایف جزئی هستند که معمولا به دلایل فنی و جزئی ایجاد می‌شوند. وظایف اصلی و نحوه ارتباط بین آن‌ها مهم است. ارتباط بین این دسته از وظایف باید به خوبی شناسایی و پیاده سازی شود که معمولا از روش‌های RPC یا Event base برای ارتباط بین آن‌ها استفاده می‌شود. این درحالی است که وظایف جزئی معمولا داخل یک برنامه ایجاد می‌شوند ارتباط و عملکرد‌ آن‌ها برای دنیای خارج از برنامه اهیمت چندانی ندارد. وقتی وظایف اصلی طراحی می‌شوند نباید در مورد نحوه قرارگیری آن‌ها در یک یا چند جای مختلف فرضی در نظر گرفته شود. جریان پیام‌ها و باری که روی سیستم قرار می‌گیرد از روی طرح‌هایی که برای نمای فرایند ایجاد می‌شود قابل تخمین و درک است. 5.1. علامت‌گذاری‌های نمای فرایند:نماد‌ها و علامت‌گذاری‌هایی که برای نمای فرایند استفاده می‌کنیم ابتدا توسط بوچ برای وظایف Ada پیشنهاد شده بود. در این جا باز هم تاکید می‌کنم که نمادهای استفاده شده بر عناصری متمرکز است که از نظر معماری مهم هستند. نماد‌هایی که در طرح‌های نمای فرایند استفاده می‌شونداز ابزارهای مختلفی می‌توان برای رسم طرح‌های این سطح استفاده کرد که برخی از ‌آن‌ها می‌توانند با توجه به طرح کد‌ها مربوط به ارتباط فرایند‌های مختلف را هم ایجاد کنند. 5.2. سبکی برای نمای فرایند:سبک‌های متفاوتی را برای طرح‌های این سطح می‌توان در نظر گرفت. برای مثال Pip و Filter یا Client/Server که خود می‌تواند به دسته‌هایی مثل، چندین Client با یک Server، چندین Client با چندین Server تقسیم شود. نمونه‌ای از مستند مربوط به نمای فرایندهمه پایانه ها توسط یک Terminal process واحد مدیریت می شوند که توسط پیام هایی در صف های ورودی آن هدایت می شود. اشیاء کنترلر بر روی یکی از سه وظیفه ای که فرایند کنترل کننده را تشکیل می دهد اجرا می شوند: یک low cycle rate task تمام پایانه‌های غیرفعال (200 میلی‌ثانیه) را اسکن می‌کند، هر پایانه‌ای که فعال می‌شود را در لیست اسکن high cycle rate task (10 میلی‌ثانیه) قرار می‌دهد، که هر تغییر قابل توجهی از حالت را تشخیص می‌دهد، و آنها را به main controller task منتقل می‌کند. main controller task تغییرات را تفسیر کرده و آنها را از طریق پیام به ترمینال مربوطه منتقل می کند. در اینجا ارسال پیام در فرایند کنترلر از طریق حافظه مشترک انجام می شود.6. جمع بندی:مطلبی بالا ترجمه مقاله Architectural Blueprints—The “4+1” View Model of Software Architecture نوشته آقای Philippe Kruchten است که نسخه اصلی از اینجا امکان دانلود دارد. به علت طولانی بودن مقاله در بیش از یک قسمت نوشته را منتشر می‌کنم.نوشته اصلی کمی طولانی هست و اینکه به دلیل قدیمی بودن مطلب بعضا نشانه‌گذاری هایی که استفاده شده یا از رده خارج شدن یا بسیار به روز رسانی شدن و با نسخه به کار برده شده در مقاله متفاوت هستن! در کنار این مسئله، نکته قابل توجه دیگه در مورد قدیمی‌بودن مقاله این هست که سبک‌های معماری جدیدی در نماهای مختلف بعد از این مقاله به دنیای توسعه نرم‌افزار معرفی شدن. بعضا این سبک‌های جدید بسیار پر استفاده هستن یا برعکس بعد از چند سال از رده خارج شدن و دیگه مورد استفاده قرار نمی‌گیرن که هیچ مثال و حرفی از این سبک‌ها توی این مقاله نیست مثلا میکروسرویس‌ها که این روزهای بسیار مورد توجه هستن.اما با همه این تفاسیر به جای استفاده از مثال‌های به روز و استفاده از منابعی که به روزتر باشن از مطلب اصلی استفاده کردم. برای انجام این کار چند دلیل داشتم! اول اینکه با اینکه بعضا نشانه‌ها و ... قدیمی شدن ولی کاملا قابل فهم و کاربردی هستن. نکته بعدی اینکه به نظرم در بین منابع مختلفی که به بیان این موضوع پرداختن نوشته اصلی بسیار بیان جامع و شیوایی توی این کار داره. و آخرین نکته جالب از نظر خود من این هست که با اینکه الان میشه در نظر گرفت سالیان زیادی از مطلب اصلی گذشته اما هنوز هم که هنوز مسئله‌ها، چالش‌ها، نکات مثبت، الگو‌ها و ... یکسان‌ قابل درک و لمس هستن. یعنی هیچ مسئله و دغدغه‌ای در مقاله وجود نداره که بتونیم بگیم 30 سال از مطلب گذشته و این موضوع دیگه حل شده است! این موضوع برای خود من جذابه! چطور ممکنه مسائلی ثابت با نیازمندی‌های ثابت به روش‌های ثابت قرار باشه حل بشه و باز هم نشه در مورد اون مسئله قطعی صحبت کرد! این جاذبه دنیای توسعه نرم‌افزار چیزیه که فکر کنم تا 80 سالگی هم بتونم در موردش فکر کنم، مطالعه کنم، کار کنم، آزمایش کنم و بازهم هیچ چیزی در موردش ندونم! مثل یه پازل تکراری که هر روز حل می‌کنی و هر روز ممکنه خروجی جدیدی بده یا اصلا نتونی حلش کنی! :-D خوشحالم تو عصری زندگی می‌کنم که این دسته از مسائل وجود داره! نه اونقدر زود به دنیا اومدم که بشر به دانش امروزی نرسیده باشه و اصلا همچین مسئله‌هایی مطرح نباشه! نه اونقدر دیر که همه این ها حل شده باشه!اگر دوست داشتید در مورد معماری نرم‌افزار بیشتر بدونید و این مقاله رو هم به صورت تشریح شده ببینید پیشنهاد می‌کنم حتما به این سایت سری بزنید https://lecture2go.uni-hamburg.de/ و درس معماری نرم‌افزار رو ببینید! حدود 23 ساعت هست. دانشگاه خوب و استاد خوب و ارائه هم مال سال 2020-2021 هست و بسیار جدید و جذاب! کلاس‌های زیادی داره! ولی Lecture Software Architectures حتما ببینید! علیرضا ارومند علیرضا ارومند Thu, 23 Dec 2021 11:02:24 +0330 https://virgool.io/dotin/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%DA%A9%D8%B4%D9%81-%D8%B9%D9%85%D8%AF%DB%8C-eym0ylkqofql 1. مقدمه:بیایید نوشته امروز را با یک داستان شروع کنیم. روزی مردی در راه به یک مرد مست برخورد می‌کند که به زمین خیره شده است. مرد مست: کلید‌هایم را گم کرده‌ام و به دنبال آن‌ها می‌گردم.مرد رهگذر: کاملا بدیهی است که کلید‌ها زیر نور چراغ نیست و اگر بود ما آن‌ها را می‌دیدیم.مرد مست: میدانم، کلیدها جایی دیگر در تاریکی از دستم افتاد. اما آنجا تاریک است و امکان جستجو وجود ندارد، پس تصمیم گرفتم زیر نور چراغ را جستجو کنم.بازی برنامه ریزی برای ما در حکم چراغ خیابان در داستان بالا است که شامل نوشتن داستان کاربر و تخمین با استفاده از Pocker Planing یا سایر تکنیک های تخمین است. به نظر می‌رسد از این زمان که در جلسه هستیم به درستی استفاده نمی‌کنیم. شاید بهتر باشد حالا که همه در یک اتاق جمع هستیم از این زمان برای یادگیری نادانسته‌ها استفاده کنیم که به آن کشف عمدی می‌گوییم.2. کشف تصادفی:می‌توان گفت اگر کاری را چندین و چند بار انجام دهید ،(احتمالا) بیشتر و بیشتر در مورد آن خواهید آموخت.به نگاه دیگر، اگر چندین بار کاری را انجام دهید و در هنگام انجام با اتفاقات غیر منتظره مواجه شوید در مورد آن کار و اتفاقات خواهید آموخت. اما اگر کاری را دائم و تکراری انجام دهید، در انجام آن مهارت پیدا می‌کنید اما چیز جدیدی یاد نخواهید گرفت.تفاوت این دو مطلب را به این شکل نیز می‌توانیم بیان کنیم که شما می‌توانید 10 سال تجربه داشته باشید یا یک سال را 10 بار تجربه کرده باشید.تجربه وقایع ناشناخته یکی از بهترین اساتید است. این گفته مطلب زیر را به ذهن متبادر می‌سازد.تصمیمات درست از تجربیات می‌آیند و تجربیات از تصمیمات نادرست.هنگامی که شما در انجام یک کار با شرایطی ناشناخته و نتیجه متفاوت از آنچیزی که منتظر آن بودید مواجه می‌شوید باید مدل خود در انجام کار را به گونه‌ای تغییر دهید که عملکرد کاریتان مطابق با شرایط جدید وفق پیدا کند. این روش و تغییر، عملکردِ ذهن‌هایِ فعال و در جستجوی یادگیری است. اما عده‌ی بسیاری هم در برابر یادگیری مقاومت می‌کنند. یعنی هنگام مواجه شدن با شرایط ناخواسته و ناشناخته به جای عملکرد فعال و یادگیری و اصلاح شرایط، به شکلی عمل می‌کنند که به آن confirmation bias یا سوگیری تایید می‌گویند. در این شرایط، افراد اغلب نتایج ناشناخته را اتفاقی گذرا در نظر گرفته و به جای یادگیری از آن تلاش می‌کنند باز هم اطلاعاتی به دست بیاورند که عملکرد آن‌ها در گذشته را تایید کند. در یادگیری ذن به لحظه‌ی روشنگری - تکامل مدل خود از جهان ساتوری می‌گویند. دانش‌آموزان ذن با کوان‌ها تلاش می کنند به ساتوری برسند. در مدل کسب مهارت مهارت دریفوس هم مرحله‌ای به نام مبتدی پیشرفته وجود دارد. در این سطح، افراد مبتدی اطلاعاتی را که آموخته‌اند در موقعیت‌های واقعی به‌ کار می‌گیرند و قوانین کم‌کم برای‌شان معنا پیدا می‌کنند. در این مرحله، اطلاعات وارد زمینه می‌شوند. در این مرحله افراد قوانینی را یاد گرفته اند و آن‌ها را در محیط کاری به کار می‌برند و چیزی بیش از آموزش تئوری قوانین به دست می‌آورند. عملا تجربه شرایطی متفاوت با آموزش قوانین در این سطح به فراگیران آموزش می‌دهد.در این شرایط فراگیران، یادگیری خود را با جستجوی فعال، تجربه و برخورد با شرایط ناشناخته سرعت می‌بخشند. این تفاوت کشف تصادفی و عمدی است. به یاد داشته باشید پیگیری دائم Best Practiceها با توجه به اینکه شما را از تجربه ناشناخته‌ها باز می‌دارد فرایند یادگیری را کند می‌کند.3. یادگیری محدودیت استدر Gemba Systems آزمایشی انجام شده است که شرح آن در ادامه می‌آید. به پروژه یا کار مهمی که تیم شما اخیرا انجام داده فکر کنید( به طور ایده‌آل کاری که همین چند ماه اخیر انجام داده‌اید). از اولین لحظات آغاز تا پایان آن چقدر طول کشیده است؟ حال فرض کنید مجددا همان پروژه را می‌خواهید بدون هیچ تغییری انجام دهید. همه چیز مثل قبل است. قرار است کار را با همان تیم، همان محدودیت‌های کاری و سازمانی و ... انجام دهید. تنها تفاوتی که این بار با دفعه قبل دارد این است که همه مواردی را که دفعه قبل در طول پروژه آموختید از قبل می‌دانید. همه ناشناخته‌ها و نادانسته ها را مو به مو می‌دانید. حال کمی صبر کنید و تامل کنید. چقدر طول می‌کشد این بار پروژه را انجام دهید؟در آن آزمایش پاسخ‌هایی مثل نصف یا یک‌چهارم زمان قبلی اصلا غیر معمول نبود. از اینجا به این جمع بندی رسید که " یادگیری محدودیت است". اگر فرض کنیم که تنها تفاوت اجرای پروژه در نوبت اول و دوم دانسته‌ها در مورد کار بوده است، این نشان می‌دهد که بزرگترین مانع در برابر توان اجرایی ما، چیزهایی است که نمی‌دانیم. البته این گفته بدین معنا نیست که تمامی زمان اضافه صرف یادگیری شده است. با توجه به نادانسته‌ها از پروژه زمان‌های زیادی در جلسات سپری شده است و آزمایش‌هایی بسیاری انجام شده و بعضا کارهایی انجام شده که موجب بن بست در کار شده و اگر از قبل دانشی در آن زمینه بود اصلا آن کار انجام نمی‌شد. در واقع اگر دقیق تر نگاه کنیم یادگیری محدودیت نبوده بلکه جهل و بی‌خبری موجب اتلاف زمان شده است. اگر خلاصه بخواهیم بگوییم:نادانی بزرگترین مانع برای کارایی است.4. جهل چند وجهی استجهل حول چندین محور وجود دارد. به موارد زیر دقت کنیدشما می توانید از فناوری های خاصی که استفاده می کنید غافل باشید.ممکن است از گستردگی گزینه‌های فناورانه‌ای که پیش روی شماست بی‌خبر باشیدجهل در مورد دامنه کسب و کارجهل در مورد انواع روش‌های حل مسئله پیش روندانستن روشی بهتر برای بیان مدل مسئله که راه حل بهتری را آشکار می‌سازدنادیده گرفتن محدودیت‌های سازمانینادیده گرفتن مخاطرات سوم‌شخص‌های درگیر در پروژهغافل شدن از افرادی که برای پیش‌برد پروژه باید با آن‌ها ارتباط برقرار کنیمغفلت از روشی که باید کار را به انجام رسانده و تحویل دهیمجهل در فرهنگ سازمانیهمه این ها بخش بسیار کوچکی از نادانسته‌ها و جهالت‌ها در جریان اجرای یک پروژه است. من مطمئن هستم اگر کمی زمان بگذارید و تفکر کنید موارد بسیار بیشتری پیدا خواهید کرد که روی فرایند کاری پروژه ما تاثیر گذار هستند و از آن‌ها غافل هستیم و نسبت به آن‌ها جهل داریم.جنبه دیگری از نادانی نیز وجود دارد به طرز شگفت انگیزی ما را به بازی می‌گیرد. ما معمولا در مورد ندانسته‌های خود نادان هستیم. این ندانستنِ ندانسته‌ها باعث می‌شود به جای اینکه محتاط‌تر عمل کنیم، مانند عجول‌های ابله خود را به دردسر بیاندازیم.5. کشف یک فرایند غیرخطی و ناپیوسته استمجددا به پروژه‌ای که اخیرا انجام داده‌اید فکر کنید. آیا ندانسته‌های شما در محور زمان به طور خطی کاسته شده است؟ تقریبا بعید است. آنچه احتمالا در واقعیت اتفاق می‌افتد این است که در برهه‌های خاصی از زمان( که بعضی از آن‌ها بسیار دلچسب تر و شیرین‌تر از سایرین است) اتفاقاتی رخ می‌دهد که ناگهان بخش زیادی از ندانسته‌ها از بین می‌رود. شاید خیلی از این یادگیری‌ها در پایان روز، زمان‌هایی که خسته و نا‌امید از یک روز سخت و بی‌حاصل ( در حال فحش و بد و بیراه گفتن به اقوام درجه یک کار و صاحب کار) هستیم، اتفاق افتاده باشد. شاید هم زمانی که این دانش به دست می‌آید ناگوار باشد اما به هر حال سطح نا آگاهی ما از پروژه کاهش می‌یابد.فرایند کشف غیرخطی استبنابراین برای هر عامل واحدی، در هر پروژه کار را با سطح خاص ناآگاهی شروع کرده و این نادانسته‌ها به صورت غیر خطی کاهش پیدا می‌کند. ناآگاهی ما در پایان پروژه در پایین ترین سطح خود قرار می‌گیرد. بسیاری از این عوامل و نادانسته‌ها به هم مرتبط هستند ، بنابراین با هر کشف با چندین مورد مختلف آشنا شده و جهالت ما در مورد عوامل مختلف به طور همزمان به میزان متفاوت کاهش می یابد. در واقع بسیاری از مکاشفات ناگهانی در طول پروژه از کنترل ما خارج است و توسط خدایان پروژه به ما نازل می‌شود :-). فرض کنید در ابتدای پروژه تاریخی را برای تحویل یک فاز از پروژه تعیین می‌کنید، از کجا می‌توانید بدانید که 2 روز مانده به تاریخ تحویل پروژه همسر یکی از مهم‌ترین افراد پروژه که 6 ماهه باردار است و حداقل باید سه ماه دیگر در همان شرایط با پروژه همراهی کند تصمیم به وضع حمل می‌گیرد؟ اگر کمی منصفانه فکر کنیم ما می‌توانیم در مورد این نادانسته‌ها آگاهی داشته باشیم. در واقع شاید ندانیم چه رخدادی اتفاق می‌افتد. اما اگر کمی بالاتر از سطح معمولی فکر کنیم می‌توانیم منتظر باشیم که اتفاقی رخ خواهد داد که نمی‌دانیم و این نکته اصلی کشف عمدی است.6. اگر فرض کنیم چیز بدی اتفاق می‌افتد چه؟ما به صورت پیش‌فرض یک مکانیسم داخلی برای خوش‌بینی بی‌فکر داریم. به این مکانسیم attribution bias می‌گوییم. ما از این مکانسیم برای محافظت از خود در برابر وقایع بد بیرونی استفاده می‌کنیم. در صورتی که در مورد این موضوع می‌خواهید بیشتر بدانید می‌توانید به کتاب A Mind of Its Own مراجعه کنید اما در ادامه این موضوع را به صورت مختصر توضیح خواهیم داد. اگر اتفاق بدی برای شخصی دیگری رخ می‌دهد، حتما مستحق آن بوده است. برای آن برنامه ریزی نکرده است. کارش را به درستی انجام نداده است و ... اگر همین اتفاق برای خود ما بیوفتد، احتمالا کاری از دستمان برنمی‌آمده است، جبر زمانه بوده و ما از آن کاملا بی‌خبر بودیم و اختیاری در برابر آن نداشتیم. در یک کلام بیچاره خودمان.در شرایط زیر ما در معرض این سوگیری قرار داریموقتی کاری را تخمین میزنیموقتی ریسک کاری را محاسبه می‌کنیموقتی اتفاق بدی در پروژه ما می‌افتدوقتی هر کاری می‌کنیم که ممکن است در انتهای آن کمی غمگین و نا‌امید می‌شویماگر به جای این که امیدوار باشیم این بار اتفاق بدی نیفتد ، موارد زیر را به عنوان واقعیت فرض کنیم:چندین (تعدادی را انتخاب می‌کنیم) اتفاقات بد غیرقابل پیش بینی در طول پروژه رخ می دهد.ما نمی توانیم از قبل بدانیم که آن چیزهای بد چه خواهد بود. معنی غیرقابل پیش بینی این است.این چیزهای بد تحویل پروژه را تحت تاثیر قرار می‌دهد. این معنای بدی است.حال رویکرد ما برای پروژه چگونه تحت تاثیر قرار می‌گیرد؟7. سرانجا، کشف عمدی:به نظر می‌رسد ما جای اشتباهی در حال جستجو هستیم. روش ها ، شیوه ها و الگوهای تحویل همگی خوب هستند ، اما بزرگترین عامل محدود کننده برای تحویل موفق را در نظر نمی گیرند. بیایید فرض کنیم که در طول عمر پروژه جهالت ما در تعدادی از محورهای مرتبط با پروژه ما کاهش می یابد. فرض دیگری نیز داشته باشیم که نادیده گرفتن برخی عوامل در حال حاضر بیشترین محدودیت را به ما وارد می‌کند. فرض دیگری هم داشته باشیم که از بین تمامی این ندانسته نمی‌دانیم کدام عوامل بیشترین تاثیر را روی توانمندی ما دارند. یعنی در مرحله اول نمی‌دانیم و در ادامه هم نمیدانیم که چه چیزی را نمی‌دانیم. وقتی که بدانیم چه چیزی را نمی‌دانیم می‌توانیم از روش‌های مختلفی برای پیشرفت استفاده کنیم، اما تا زمانی که ندانیم ندانسته‌های ما چیست دائما در تاریکی مطلق عکس می‌گیریم.این منطقی است که در ابتدا تلاش کنیم تا دریابیم که کدام جنبه های تحویل را به طور جدی نادیده می گیریم. و در ادامه برای رفع جهالت در آن جنبه سرمایه گذاری کنیم یعنی عمدا به اندازه کافی کشف کنیم تا محدودیت را برطرف کنیم و شرایط ادامه کار را فراهم کنیم. و در تمام طول پروژه ، روز به روز ، ما باید سعی کنیم بفهمیم کجا و چگونه جهل مانع ادامه راه ما می شود. در یک حالت ایده آل ، ما می خواهیم تا حد امکان شیب تندی را برای هر موضوعی روی منحنی جهل ایجاد کنیم، بنابراین عمداً به جای قربانی جبر و شرایط شدن ، میزان محدودیت خود را در جهالت کاهش می دهیم.این شرایط و نحوه عملکرد یک مهارت است و به همین دلیل تابع مدل دریفوس است. این بدان معناست که در ابتدا ما آن را به درستی پیش‌ نخواهیم برد و شرایط آشفته خواهد شد. سپس کم کم متوجه اشتباهات خود در این فرایند خواهیم شود و خواهیم آموخت. سپس سراغ چند Best Practice می‌رویم. و اگر خوب پیش‌برویم بعد از مدتی راهکارها و نکاتی خواهیم یافت تا آن Best Practiceها را برای خودمان متناسب سازی و ایجاد کنیم. سخت ترین قسمت کار آنجاست که متوجه می‌شویم چقدر در اتفاقاتی که قبلا آن‌ها را قضا و قدر می‌دانستیم مقصر هستیم. خودخواهی و خود دوستی ما احتمالا آسیب خواهد دید. ما در میابینم که تا الان در محدوده امن و زیر نور چراغ در جستجوی کلید بودیم. 8. بعدش چی؟ در ابتدای کار ، هنگامی که ما بیشتر جنبه های پروژه را نادیده می گیریم ، بهترین استفاده ای که می توانیم از زمان موجود انجام دهیم ، تلاش برای شناسایی و کاهش جهالتمان در تمام محورهایی که می‌ـوانیم به آن فکر کنیم، است. اگر به مدل برنامه ریزی چابک سنتی پایبند باشیم ، با تجزیه اپیک ها به فیچرها به داستان و سناریوها ، دستاورد‌هایی خواهیم داشت و در برخی از جنبه‌ها جهالت ما به دانش تبدیل می‌شود و در برخی موارد هم نادانسته‌هایی را که نمی‌دانیم پیدا خواهیم کرد. اما اگر این فرایند را برای مدتی کنار بگذاریم و تمرکز خود را روی دانستن و دانستن ندانسته‌ها قرار دهیم چه خواهد شد؟آقای Eric Evans نویسنده کتاب آبی DDD روش‌های سنتی را "قفل شدن در جهالت" توصیف می‌کند. این گفته فقط در مورد روش‌های بسیار سنتی جمع آوری نیازمندی صدق نمی‌کند، بلکه خیلی وقت‌ها که به اصل موضوع دقت نمی‌کنیم روش‌های جدیدتر نیز دچار همین مشکل می‌شوند و چه بسیار پروژه‌هایی که در فرایند داستان نویسی و ... دچار مرگ شده اند. امیدوارم این نوشته به شما این دید را داده باشد که کجا باید سرگرم باشیم. درباره کشف عمدی چیزهای بیشتری برای گفتن وجود دارد. در مورد به کارگیری این اصل برای یادگیری یک زبان جدید ، یا انتخاب یک فناوری جدید ، یا یک حوزه جدید فکر کنید. برای شناسایی و کاهش سریع جهالت خود چه کارهایی می توانید انجام دهید؟ چرا تیم هایی که فرایند بازخورد سریع دارند بسیار موفق تر از تیم های با چرخه‌های طولانی هستند؟ چگونه می توان جهل را سنجید؟ در صورت تمایل می‌توانید ارائه آقای Dan North را در این مورد در Infoq مشاهده کنید.9. جمع بندی:متن اصلی این نوشته را اینجا می‌توانید مشاهده کنید. در پایان خواندن شعر زیر هم از کتاب معراج السعاده ملا احمد نراقی خالی از لطف نیستآنکس که بداند و بخواهد که بداندخود را به بلندای سعادت برساندآنکس که بداند و بداند که بدانداسب شرف از گنبد گردون بجهاندآنکس که بداند و نداند که بداندبا کوزه ی آب است ولی تشنه بماندآنکس که نداند و بداند که نداندلنگان خرک خویش به مقصد برساندآنکس که نداند و بخواهد که بداندجان و تن خود را ز جهالت برهاندآنکس که نداند و نداند که ندانددر جهل مرکب ابدالدهر بماندآنکس که نداند و نخواهد که بداندحیف است چنین جانوری زنده بماندالبته ما در کارهایمان احتمالا در دسته کسانی که نمی‌خواهند بدانند قرار نمی‌گیریم و می‌توان به طور مختصر این طور بیان کرد که در ابتدای هر پروژه دانسته و نادانسته‌های ما 4 دسته کلی ایجاد می‌کنندآن‌هایی که میدانیم که میدانیمآن‌هایی که نمی‌دانیم که میدانیمآن‌هایی که میدانیم که نمی‌دانیمآن‌هایی که نمیدانیم که نمی‌دانیمقاعدتا دسته اول قوت قلب و چراغ راه ما برای شروع کار و مقابله با مشکلات است و دسته دوم هم در راه پروژه به صورت ناخود‌آگاه به ما کمک خواهند کرد. اگر کمی عاقلانه رفتاد کنیم باید برای دسته سوم برنامه ریزی داشته باشیم و آن‌ها را به دسته اول منتقل کنیم و در نهایت باید بیشترین انرژی را صرف تبدیل اعضای گروه چهارم به گروه سوم کرده و در نهایت به گروه یک منتقل کنیم. علیرضا ارومند علیرضا ارومند Wed, 29 Sep 2021 22:09:26 +0330 https://virgool.io/@ar.oroumand/%D9%81%D8%B5%D9%84-%D8%AF%D9%88%D8%A7%D8%B2%D8%AF%D9%87%D9%85-clean-architecture-%DA%A9%D8%A7%D9%85%D9%BE%D9%88%D9%86%D9%86%D8%AA-%D9%87%D8%A7-utyqbxsube88 پیش‌مقدمه بخش چهارم کتاب - Component Principal:اگر معماری نرم‌افزار را بخواهیم با فرایند معماری و ساخت ساختمان مقایسه کنیم، اصول SOLID به ما می‌گویند که چطور آجرها را در دیوار‌ها مورد استفاده قرار دهیم. در ادامه Component Principalها به ما می‌گویند چگونه اتاق‌ها و اجزای بزرگ‌تر را در کنار هم استفاده کنیم. یک نرم‌افزار بزرگ هم مانند یک ساختمان بزرگ از اجزایی تشکیل شده است.در بخش چهارم از این کتاب توضیح می‌دهیم که component چیست و از چه بخش‌هایی باید تشکیل شوند و چگونه در کنار هم قرار بگیرند تا سیستم را ایجاد کنند.شروع فصل دوازدهم:1. مقدمه:یک واحد قابل توزیع را Component می‌نامیم. یک component بخش کوچکی از سیستم است که می‌تواند جداگانه انتشار یابد. در Dotnet این اجز در قالب DLL انتشار پیدا می‌کنند. در جاوا در قالب Jar فایل و در زبان‌هایی مانند جاوا اسکریپت مجموعه ای از فایل‌ها که کار خاصی را انجام می‌دهند. فصل مشترک در تمامی زبان‌ها این است که مجموعه ای از کارهای مرتبط با هم که در قالب یک بسته قابل انتشار است برای ما یک component ایجاد می‌کند.این Componentها می‌توانند در کنار هم قرار بگیرند تا یک برنامه اجرایی را تشکیل دهند یا می‌توانند به تنهایی برای استفاده سایرین منتشر شوند. جدای از اینکه در نهایت چگونه از این Componentها استفاده می‌شود، همیشه یک Component خوب این ویژگی را دارد که مستقلا توسعه و انتشار داده شود.2. تاریخچه Componentها:در سال‌های اولیه توسعه نرم‌افزار، برنامه‌نویس‌ها مجبور بودند حافظه و ساختار برنامه را کنترل کنند. یکی از اولین خط‌ کدها در برنامه ، عبارت Origin بود که نشانی محل برنامه را در آن بارگذاری می شد.تکه کد زیر را در نظر بگیرد که در آن یک روال به نام GETSTRتعریف شده است که متن ورودی از کیبورد را دریافت کرده و در یک بافر ذخیره می‌کند. در ادمه یک تکه کد کوچک هم برای تست این روال وجود دارد.دستور *200 را در ابتدای برنامه را در نظر بگیرید. این خط به کامپایلر اعلام می‌کند که کدی تولید کند که در آدرس 200 بارگذاری می‌شود.این نوع برنامه نویسی برای اکثر توسعه دهنده‌های این روزها عجیب خواهد بود. در اغلب موارد، این روزها برای توسعه دهنده‌ها اهمیتی ندارد که برنامه آن‌ها در کدام خانه از حافظه بارگذاری می‌شود. اما در زمان‌های قدیم یکی از تصمیاتی که هر توسعه دهنده‌ای باید می‌گرفت این بود که برنامه اون در کدام خانه از حافظه بارگذاری شود. در آن زمان برنامه‌ها قابل جابجایی نبودند.در آن زمان چطور می‌شد به کتابخانه‌ای از توابع دسترسی پیدا کرد؟ در ان زمان لازم بود که سورس کد کتابخانه‌ها به سورس کد برنامه متصل شود و در واحد یک برنامه کامپایل شوند. در ان زمان کتابخانه‌ها در قالب فایل‌های سورس کد منتشر می‌شدند نه فایل‌های باینری.یکی از مشکلاتی که در آن زمان‌ها وجود داشت این بود که دستگاه‌ها کند بودند و حافظه بسیار گران بود و در نتیجه محدودیت‌های زیادی در این حوزه وجود داشت. کامپایلر‌ها نیاز داشتند که چندین بار بررسی کنند اما حافظه اصلی برای نگهداری کل سورس کد بسیار محدود بود. در نتیجه کامپایلر دائم مجبور بود سورس کد را از دستگاه‌های کند بازخوانی نماید.این فرایند تکراری و خسته کننده بسیار کند بود. در نتیجه کامپایل کردن سورس کد بسیار کند انجام می‌پذیرفت. اگر نیاز به کامپایل برنامه‌ی بزرگی داشتیم بعضا تا ساعت‌ها این کار به طول می‌انجامید.برای اینکه زمان کامپایل کوتاه شود، برنامه نویس‌ها کد‌های کتابخانه‌ها را جداگانه کامپایل می‌کردند و در آدرسی مشخص بارگذاری می‌کردند. آن‌ها یک جدول راهنما از آدرس‌های کتابخانه‌ها ایجاد می‌کردند و همراه کد‌های خود آن‌ها را هم کامپایل می‌کردند. هنگامی که برنامه قرار بود اجرا شود، کتابخانه‌ها از جدول آدرس که همراه برنامه بود بارگذاری می‌شدند و سپس برنامه بارگذاری می‌شد. حافظه بعد از اجرای برنامه مانند تصویر زیر می‌شد.تا زمانی که برنامه در محدوده آدرسی تعین شده جا بگیرد این فرایند به خوبی کار می‌کند. مشکل زمانی شروع می شود که برنامه رشد کرده و بزرگتر از فضایی بشود که برای آن در نظر گرفته شده است. در این شرایط برنامه نویس‌ها ناچار هستند که برنامه خود را به دو قسمت تقسیم کنند که بخشی از آن قبل و بخش دیگرد بعد از کتابخانه قرار می‌گیرد.با یک نگاه اجمالی می‌توان دریافت که این روند صحیح نمی‌باشد. با بزرگ شدن کتابخانه محدوده تعیین شده برای آن کوچک خواهد شد. چاره این نیست جز اینکه فضای بیشتری برای کتابخانه در نظر گرفته شود. این فرایند تکه تکه شدن برنامه‌ها و رشد آن‌ها در حافظه ادامه پیدا می‌کند و مسلم است که باید فکری برای این وضعیت داشته باشیم.3. قابلیت جابجایی:راهکار حل این مشکل ایجاد قابلیت جابجایی برای کد‌ها بود. ایده پشت این موضوع بسیار ساده بود. کامپایلرها تغییر پیدا کردند تا کد‌های برنامه را طوری به باینری تبدیل کنند که قابلیت جابجایی داشته باشند و با یک فرایند هوشمند در حافظه بارگذاری شوند. در این شرایط Loaderها تعیین می‌کنند که کد قابل جابجایی کجای حافظه بارگذاری شود. کد قابل جابجایی دارای علامت‌هایی بود که به Loader می گفت که کدام قسمت از داده های بارگذاری شده باید تغییر کند تا در آدرس انتخابی بارگذاری شود. برای انجام این فرایند، معمولا فقط کافی است تا آدرس شروع را به همه آدرس‌های موجود در کدهای باینری شده اضافه شود.حال برنامه نویس می تواند به Loader بگوید که کتابخانه را در کجا بارگذاری کرده و برنامه را در کجا بارگذاری کند. در واقع ، Loader چندین ورودی باینری را می پذیرد و به سادگی آنها را یکی پس از دیگری در حافظه بارگذاری می کند و آنها را همانطور که بارگذاری می کند ، جابجا می کند. این به برنامه نویسان اجازه می دهد فقط توابع مورد نیاز خود را بارگذاری کنند.کامپایلر‌ها تغییرات دیگری نیز پیدا کردند. آن‌ها به گونه‌ای تغییر یافند که نام توابع را نیز به عنوان متادیتا به در فایل بانتری منتشر کنند. اگر برنامه یک تابع از یک کتابخانه را صدا بزند، کامپایلر نامه آن تابع را به عنوان یک external reference منتشر می کند. اگر کتابخانه‌ای تابعی را برای صدا زده شدن تعریف کند کامپایلر آن را به عنوان یک external definition تعریف می‌کند. حال loader می‌تواند external reference را به external definition متصل کند. اینگونه بود که Linking Loader ایجاد شد.4. آشنایی با Linkerها:تولد Linking Loaderها این توانایی را به برنامه‌نویسان داد تا برنامه‌های خود را به قطعات کوچکتری که قابل کامپایل و بارگذاری بودند تقسیم کنند. در ابتدا قطعات کوچکی از برنامه‌ها به قطعات کوچکی از کتابخانه‌ها متصل می‌شدند. اما رفته رفته توسعه دهنده‌ها شجاع‌تر و بلند‌پرواز تر شدند و در اواخر دهه 60 و اوایل دهه 70 میلادی اندازه برنامه‌ها بسیار رشد کرد.در نهایت Linker Loader ها بسیار کند شدند. کتابخانه‌های توابع معمولا روی دستگاه‌های ذخیره سازی کندی مثل نوار‌ها ذخیره می‌شدند. بعضا این کتاخانه‌ها روی هارد دیسک‌ها نگهداری می‌شدند که آن‌ها نیز به نسبت کند بودند. در این شرایط Linking Loader مجبور بود چندین باینری را بارگذاری کند تا نیازهای external referenceها و external definitionها را برطرف کند. در همین شرایط برنامه‌ها بزرگ و بزرگتر شدند تا جایی که بعضا چندین ساعت زمان برای بارگذاری یک برنامه لازم بود.در نهایت فرایند Load از Linkجدا شد. برنامه نویس‌ها فرایند کند‌تر را که همان Linker بود جدا کرده و در قالب برنامه‌ای به عنوان Linker قرار دادند. خروجی این Linker چیزی بود که به راحتی توسط Loaderبارگذاری می‌شد. این جدا سازی شرایطی را ایجاد کرد که برنامه‌نویسان توانستند برنامه‌های خود را یک بار با فرایندی کند به هم Link کنند و از آن به بعد هر زمانی که نیاز بود آن‌ها را به سرعت باگذاری و اجرا کنند.سپس به دهه 80 میلادی رسیدیم. زمانی که برنامه‌نویسان با زبان‌های سطح بالایی همچون C کار می‌کردند. با این جداسازی فرایند و ترکیب با زبان‌های سطح بالا، برنامه‌ها به سرعت رشد کردند. در آن زمان برنامه‌هایی که از صدها یا هزاران خط کد تشکیل می‌شدند دیگر غیر معمول نبودند.سورس کدهای C از فایلهای با پسوند .c کامپایل می‌شدند و در قالب فایل های .oقرار می‌گرفتند. سپس Linker آن‌ها را ترکیب می‌کرد و فایل‌هایی را ایجاد می‌کرد که به سرعت قابلیت اجرا داشتند. در آن زمان کامپایل کردن یک ماژول خاص خیلی سریع انجام می‌گرفت اما کامپایل کامل برنامه‌ها بعضا طولانی می‌شد. بعد از این مرحله هم نوبت اتصال به وسیله Linker بود. باز هم سناریوی قبلی و زمان زیاد تبدیل به مشکلی اساسی شد.به نظر می‌رسید که برنامه نویس‌ها در یک حلقه بی‌نهایت از رفع مشکل و ایجاد مجدد مشکل قرار گرفته اند. از دهه 60 میلادی تا دهه 80 میلادی دائما برنامه‌نویسان با مشکل سرعت انجام کار سر و کله میز‌دند. در یک زمان مشکل سرعت بارگذاری بود و با جدا سازی فرایند اتصال از بارگذاری این مشکل موقت حل شد. اما با افزایش اندازه برنامه‌ها این بار سرعت در فرایند اتصال و کامپایل تبدیل به گلوگاه اصلی فرایند شد. این مشکل با قوانین مورفی همخوانی دارد.برنامه‌ها اینقدر بزرگ می‌شوند تا تمام زمان کامپایل و اتصال را استفاده کنند.اما مورفی تنها سخنگوی شهر نیست. همزمان با اون مور نیز قوانینی را بیان کرد. در نهایت برنده این قانون گذاری‌ها مور بود. دیسک‌ها روز به روز کوچکتر و سریع‌تر شدند. حافظه‌های اصلی نیز بسیار پرظرفیت ‌تر و ارزان تر شد و این امکان وجود داشت که بسیاری از اطلاعات روی حافظه اصلی نگهداری شود. سرعت ساعت کامپیوتر نیز از 1 مگاهرتز به 100 مگاهرتز افزایش پیدا کرد.در اواسط دهه 90 این رشد‌های ایجاد شده در سخت‌افزار به قدری بود که فرایند اتصال بسیار سریع شد. این فرایند اینقدر سریع شد که دیگر جاه طلبی برنامه‌نویسان برای بزرگ کردن اندازه برنامه‌ها مشکلی در فرایند اتصال و کاهش سرعت آن ایجاد نمی‌کرد. در بسیاری از شرایط ایده اولیه Linking Loaderمجدد منتطقی به نظر می‌رسید.ایجاد نقطه شروع عصر Active-Xها و Jarفایل‌ها و کتابخانه‌های اشتراکی بود. کامپیوتر‌ها و سخت‌افزار اینقدر سریع شدند که حالا باز این امکان ایجاد شد که فرایند اتصال و بارگذاری همزمان انجام شود. چندین کتابخانه می‌توانستند در کسری از ثانیه به هم متصل شوند و یک برنامه اجرایی را ایجاد کنند. ایجاد بود که نسل جدید معماری به کمک componentها متولد شد.این روز‌ها انتشار Componentها به کمک Jarفایل‌ها و DLLها بسیار فراگیر و روزمره است. این روزها به سادگی می‌توانید برنامه‌ها را که دارید به کمک Componentها گسترش دهید. برای مثلا افزودن امکانات ReSharper به Visual Studio به سادگی اتفاق می‌افتد.5. جمع بندی:بسیاری از امکانات و معماری‌ها امروزه به سادگی مورد استفاده قرار می‌گیرند. اما همانطور که مشاهده کردید برای اینکه امکانات اولیه برای فکر کردن به این معماری‌ها در اختیار ما قرار گیرد بعضا تا 50 سال آزمون و خطا و تلاش پیشینیان اتفاق افتاده است. علیرضا ارومند علیرضا ارومند Tue, 07 Sep 2021 17:11:03 +0430 https://virgool.io/dotin/%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%AF%D8%B1-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-f8euu88j74lm 1. مقدمه:در قسمت قبل کمی در مورد مقدمات امنیت در میکروسرویس‌ها صحبت کردیم. هنوز در ابتدای راه هستیم و موارد زیادی را باید بدانیم، با توجه به تفاوت ساختاری میکروسرویس‌ها با سایر روش‌های توسعه، نیاز داریم که مرزی را جهت برقراری امنیت با دنیای بیرون تشکیل دهیم، البته نباید از مباحث امنیتی داخل این مرزهم غافل شویم. در این قسمت در مورد مقدمات امنیت در داخل و بیرون مرزهای میکروسرویس‌ها مطالبی را با هم بررسی خواهیم کرد.2. امنیت مرزهای نرم‌افزار:میکروسرویس‎ها هنگام انتشار معمولا بصورت مستقیم در معرض دید نرم‌افزار‏های مشتری و دنیای خارج قرار نمی‌گیرند. به طور معمول میکروسرویس‌‎ها از مجوعه‌ای از APIها تشکیل شده اند که به واسطه API Gatewayدر معرض دید جهان خارج قرار می‌گیرند، در عمل با استفاده از API Gateway که در ورودی میکروسرویس‎ها مستقر هستند، تمام پیغام‎های ورودی را غربالگری می‌شوند.در تصویر 1، استقرار میکروسرویس‎هایی شبیه به میکروسرویس‌های نت‌فیلیکس نمایش داده شده است که ازAPI Gateway به نام Zull استفاده می‌کنند. Zuul امکاناتی نظیر آدرس‎دهی پویا، رصدکردن، انعطاف پذیری، امنیت و... را فراهم می کند. در اصل به‌عنوان دریچه ورودی زیرساخت سرور نت‌فیلیکس عمل کرده و ترافیک کاربران نت‌فیلیکس از سرتاسر جهان را مدیریت می‌کند. در این تصویر، Zuul برای به معرض گذاشتن برخی میکروسرویس‌ها بواسطه API استفاده شده است. باقی میکروسرویس‎‌های مستقر نیازی به معرض دید قرار گرفتن بواسطه‌‎ی API را ندارند، چرا که نیازی نیست توسط اپلیکیشن‎های بیرونی مورد استفاده قرار بگیرند. در یک استقرار معمول میکروسرویسی، مجموعه‎‌ای از میکروسرویس‎ها هستند که اپلیکیشن‌‎های بیرونی نیاز به دسترسی به آنها دارند، و مجموعه‏ای از میکروسرویس‌‎ها هستند که اپلیکیشن‎‌های بیرونی نیازی به دسترسی به آنها ندارند. فقط دسته‌‏ی اول به واسطه‌‎ی API gateway به دنیای بیرون عرضه می‌شوند.تصویر 1 ارتباط با دنیای بیرون به واسطه API Gateway2. نقش API Gateway در دنیای میکروسرویس‌ها:با گذر زمان، APIها تبدیل به چهره عمومی شرکت‎‌ها شدند. اغراق نکرده‌ایم اگر بگوییم یک شرکت بدون API مثل یک رایانه بدون اینترنت است. اگر شما توسعه‌‎دهنده باشید حتما درک می‌کنید که زندگی بدون اینترنت به چه شکلی است!برای بسیاری از شرکت‏‌ها، APIها کانال اصلی درآمدزایی هم هستند. بعنوان مثال در شرکت ایکس‌پدیا 90 درصد درآمد کل شرکت از طریق APIها تامین می‌شود. در سلفورث 50 درصد و در ای‌بی 60 درصد درآمد را ایجاد می‌کنند. نتفیلیکس هم شرکت دیگری است که بطور جدی روی APIها سرمایه گذاری کرده است. حساب‎‌های کاربری نتفیلیکس که درصد قابل توجهی از تمام ترافیک اینترنت شمال آمریکا و جهان را بخود اختصاص داده است، تماما از طریق APIهای نتفیلیکس منتقل میشوند.میکروسرویس‌ها و APIها،مثل یک زوج موفق دست در دست هم هستند. در بسیاری از اوقات، یک میکروسرویس که باید برای نرم‌افزار مشتری دردسترس باشد، بعنوان یک API و توسط API Gateway عرضه می‌شود. یکی از نقش‌های کلیدی API Gateway در استقرار میکروسرویس‎‌ها، عرضه مجموعه‌‎ای منتخب از میکروسرویس‌‎ها به دنیای بیرون به‌عنوان API است و ساخت امکان کیفیتِ خدمت (QoS). امکانات QoS شامل امنیت، گلوگاه بودن و تحلیل است.عرضه میکروسرویس‎‌ها به دنیای بیرون الزاما به این معنا نیست که در سطح اینترنت بصورت عمومی دیده شوند. ممکن است صرفا به خارج از یک دپارتمان دیگر داخل شرکت نیاز به عرضه API وجود داشته باشد، یعنی اجازه دهیم کاربران یا سیستم‎‌های یک دپارتمان دیگر درون همان مرزبندی سازمانی مشترک با ما، با میکروسرویس‎‌ها بواسطه API Gateway صحبت کنند. 3. احراز هویت در مرزها:مشابه میکروسرویس‎‌ها، برای APIها نیز، مخاطب سیستمی است که بجای خودش یا بجای کاربر انسانی یا سیستم دیگر عمل با API کار می‌کند (تصویر 2 را ببینید).این نکته را در نظر داشته باشید که این امکان فراهم است که کاربر انسانی مستقیما با APIها کار کند، اما معمولا این اتفاق نمی‌افتد. در اغلب اوقات APIها به API Gateway ها عرضه می‌شوند و در نهایت API Gatewayها با سیستم‌‎های بیرونی کار می‌کنند. در ادامه، ما در مورد گزینه‎‌هایی که برای احراز هویت یک سیستم (یا نرم‌افزار مشتری) در API Gateway داریم صحبت خواهیم کرد.تصویر 2 احراز هویت در مزرهای ورودی توسط API Gateway3.1. احراز هویت مبتنی بر گواهی نامه:احراز هویت مبتنی بر گواهینامه از API در مرزها با استفاده mutual transport layer security که از این به بعد به طور اختصار mTLS می‌گوییم، محافظت می‌کند . در استقرار میکروسرویس‌‎های نتفیلیکس، دسترسی به APIها با استفاده از گواهینامه‌‎ها محافظت می‌شود. فقط مشتریانی که گواهینامه‌‎ی معتبر دارند امکان دسترسی به APIهای نتفیلیکس را دارند. نقش API Gateway در اینجا این است که اطمینان حاصل کند که فقط مشتریان دارای گواهینامه‌‎ی قابل اطمینان به API دسترسی دارند و فقط درخواست‎‌های این مشتریان است که به سمت میکروسرویس‎های سرویس دهنده فرستاده می‌شوند. در قسمت‌های بعدی این سری مطالب در مورد این حوزه توضیحات دقیق‌تری را ارائه خواهیم کرد.3.2. تفویض اختیار به کمک OAuth 2.0:هر کسی می‌تواند برنامه‌‎ای بسازد که از APIهای فیسبوک و تویتر و ... استفاده کند.این برنامه‌‎ها میتوانند نرم‌افزارهای تحت وب، موبایل یا ... باشند. نرم‌افزاری که توسعه داده می‌شود می‌تواند به عنوان خودش یا کاربری دیگر به API دسترسی داشته باشد. OAuth 2.0 یک چارچوب احراز صلاحیت و تفویض اختیار است. این روش، برای محافظت از APIها در زمانی است که یک سیستم تقاضای دسترسی به API بجای یک سیستم دیگر یا کاربر را دارد توصیه شده است. در قسمت‌های بعدی در مورد OAuth 2.0 و روش استفاده از آن جهت تفویض اختیارات و احراز صلاحیت بیشتر صحبت خواهیم کرد.نقش API Gateway اعتبارسنجی توکن‌‎های امنیتی OAuth 2.0 می باشد که در هر درخواست برای API وجود دارند. توکن امنیتی OAuth شامل نشان می‌دهد که کدام برنامه و از طرف چه کاربری قصد استفاده از API را دارد و می‌توان تشخیص داد برنامه‌ای که سراغ APIما آمده از طرف کدام کاربر وکالت دارد به اطلاعات سامانه ما دسترسی داشته باشد!برای کسانی که دقیق‌تر با OAuth آشنا هستند شاید این استفاده از OAuth و جایگاهی که برای آن در نظر گرفته شده است کمی عجیب به نظر برسد! اما در قسمت‌های بعد با بیان جزئیات بیشتر از OAuth و نحوه استفاده از آن در روال‌های میکروسرویس ابهامات برطرف خواهد شد.4. احراز مجوز و صلاحیت در مرزها:یکی دیگر از مواردی که در مرز‌ها و در API Gateway قابل بررسی است، احراز مجوز و صلاحیت است. با توجه به مرکزیت این قسمت، قبل از انجام کار، مجوز‌های کاربر بررسی می‌شود که شامل دسترسی به منبع مورد نظر باشد و در صورتی که مجوز این کار را دارا نبود جلوی دسترسی گرفته می‌شود.5. انتقال اطلاعات زمینه‌ای کاربر و نرم‌افزار مشتری به میکروسرویس‌ها:تمام اتصالات مشتری‌ها به سرویس‌ها به API Gateway ختم می‌شود، اگر همه شرایط مساعد باشد، درخواست ‎ها به میکروسرویس‌های اصلی سرویس ‎دهنده منتقل خواهند شد. راهی نیاز است تا از کانال‎‌های ارتباطاتی بین API Gateway و میکروسرویس مربوطه محافظت شود، و همینطور راهی نیز برای ارسال اطلاعات زمینه‌ای کاربر/نرم‌افزار مشتری به میکروسرویس خدمات دهنده نیاز داریم. اطلاعات زمینه‌ای کاربر شامل یکسری اطلاعات پایه‌‎ای درمورد کاربر نهایی و همینطور اطلاعاتی درمورد نرم‌افزار مشتری می‌باشد. این اطلاعات عموما در میکروسرویس خدمات دهنده برای کنترل دقیق‌تر دسترسی در سطح سرویس مورد استفاده قرار می‌گیرد.همانطور که به احتمال زیاد حدس می‌زنید، ارتباط بین API Gateway و میکروسرویس‌‎ها از نوع سیستم به سیستم است، پس می‌توانیم از mLTS برای امن کردن کانال ارتباطی استفاده کنیم. اما چطور باید اطلاعات کاربر و نرم‌افزار مشتری را برای میکروسرویس سرویس دهنده ارسال کنید؟ چند گزینه دارید: ارسال این اطلاعات در Headerهای HTTP یا ایجاد JWT با داده‎‌های کاربر. گزینه‌ی اول بسیار ساده است، اما کمی گرفتاری برای قابلیت اطمینان به این اطلاعات وجود دارد.زمانی که اولین میکروسرویس اطلاعات کاربر را دریافت می‌کند و برای ادامه کار فرایند را به میکروسرویس دیگری منتقل می‌کند اطلاعات زمینه‌ای کاربر و نرم‌افزار مشتری را در Headerهای درخواست HTTP برای یک میکروسرویس دوم ارسال می کند. میکروسرویس دوم هیچ تضمینی مبنی بر اینکه اطلاعات کاربر تغییر نکرده است ندارد و نمی‌تواند مطمئن باشد میکروسرویس اول این اطلاعات را متناسب با خواست خود تغییر نداده باشد. اما با JWT شما اطلاعات را در قالبی دارید که اگر یک سرویس واسط قبل از رسیدن JWT به دست شما اطلاعات آن را تغییر دهند، این تغییر را متوجه خواهید شد، چرا که صادر کننده‌ی JWT آن را امضا کرده است.اگر با JWT آشنایی ندارید آن‌را محتوای امضا شده‎ای تصور کنید که داده (در این مثال اطلاعات زمینه‌ای کاربر و نرم‌افزار مشتری) را در حالت رمز شده و مطمئن منتقل می‌کند. API Gatewayها می‌توانند JWTای شامل اطلاعات کاربر (و یا اطلاعات نرم‌افزار مشتری) را ایجاد کنند و آن را برای میکروسرویس سرویس‎ دهنده ارسال کنند. (این نکته را در نظر بگیرید که معمولا عنصر سومی مسئول تولید JWT است که در این‌جا برای سادگی API Gateway را برای تولید آن در نظر گرفته‌ایم، در قسمت‌های بعد این مسئولیت و نحوه انجام آن را دقیق‌تر بررسی خواهیم کرد.) میکروسرویس دریافت کننده با تایید کردن امضای JWT به کمک کلید عمومیِ بخشی که JWT را صادر کرده است، آن را اعتبارسنجی می‌کند.6. امنیت در ارتباط سرویس به سرویس:تعدد ارتباط‌های سرویس با سرویس در استقرار میکروسرویس‌‎ها بالاست. ارتباطات بین دو میکروسرویس میتواند درون یک حوزه مطمئن یا بین دو حوزه مطمئن باشد. حوزه مطمئن بیانگر مالکیت است. میکروسرویس‌‎ها با هم و احتمالا درون یک حوزه مطمئن یا یک مرزبندی مطمئن که در سطح سازمان تعریف شده است و درنظر گرفتن فاکتورهای دیگر، توسعه، نصب و مدیریت می‌شوند.مدل امنیتی که به‌منظور محافظت از ارتباطات سرویس به سرویس توسعه می‌دهیم، باید با درنظر گرفتن کانال‎های ارتباطی بین مرزبندی‎های مطمئن باشد و همینطور چگونگی ارتباطاتی که در واقع میخواهیم بین میکروسرویس‌‎ها باشد. همانطور که می‌دانید این ارتباط‌ها می‌تواند Sync یا Async باشد. غالب اوقات ارتباطات Sync بر بستر HTTP رخ می‎دهد. ارتباطات Async می‌تواند با هر نوع سیستمِ پیام‎رسانی نظیر RabbitMQ، Kafka، ActiveMQ و یا حتی Amazon Simple Queue Service (SQS) رخ دهد.6.1. احراز هویت سرویس به سرویس:برای امن کردن ارتباطات سرویس‌‎ها در قالب میکروسرویس سه روش معمول وجود دارد: اطمینان به شبکه ، mTLS و JWTها. 6.1.1. اطمینان به شبکه:روش اطمینان به شبکه قدیمی‎‌ترین راه حلی است که مورد استفاده قرار می‌گیرد. این روش در عمل امنیتی را هم در ارتباطات سرویس به سرویس اجبار نمی‌کند. در واقع این مدل به امنیت در لایه شبکه اکتفا می‌کند. امنیت لایه شبکه باید این تضمین را بدهد که هیچ حمله‎‌کننده‎ای امکان شنود ارتباطات میکروسرویس‌‎ها را ندارد. همچنین هر میکروسرویس بعنوان سیستم مطمئن شناخته می‌شود. این انتخاب می‌تواند مبتنی بر انتظار شما از سطح امنیت و اعتماد شما به اجزای درون شبکه باشد.روش قدیمی دیگری که در این حوزه مورد استفاده قرار میگیرد ، با عنوان شبکه‌‎ی نامطمئن یا zero trusted network شناخته می‌شود که نقطه مقابل روش اطمینان به شبکه است.در این روش یک پیشفرض را همیشه در نظر می‌گیریم که شبکه همواره نامطمئن و آسیب‎‌پذیر است و به هیچ جزئی دسترسی‌‎ای اعطا نمی‌شود. هر درخواستی که به هر میکروسرویسی می‌رسد، پیش از آنکه برای پردازش پذیرفته شود، هربار باید احرازهویت و احراز مجوز شود. 6.1.2. استفاده از mTLS:یکی از روش‎های مرسوم دیگر برای امن کردن ارتباطات سرویس به سرویس در استقرار میکروسرویس‌‎ها، روش Mutual TLS می‌باشد . در حقیقت، این روش پر استفاده‌‎ترین شکل از احراز هویت در این روزهاست. هر میکروسرویسی که در استقرار وجود دارد، برای ارتباط با میکروسرویس گیرنده باید جفت کلیدهای عمومی/خصوصی را با خود حمل کند و با استفاده از mTLS احراز هویت کند. استفاده از TLS در انتقال داده، اطمینان خاطر و یکپارچگی را به ارمغان می‌اورد و کمک میکند مشتری سرویس را تشخیص دهد. میکروسرویس مشتری میفهمد که با کدام میکروسرویس می‌خواهد صحبت کند. اما با TLS (نوع یک طرفه) امکان شناسایی میکروسرویس مشتری برای میکروسرویس گیرنده نیست. در اینجاست که mTLS وارد میشود (Mutual=متقابل). با mTLS هر میکروسرویس در ارتباطات میتواند طرف مقابل خود را شناسایی کند. راه اندازی سیستم، تهیه گواهی‌نامه‌ها، انتقال گواهی‌نامه‌ها و مانیتور کردن آن‌ها از چالش‌های معمول در استفاده از این روش است که در آینده در مورد آن‌ها دقیق‌تر صحبت خواهیم کرد.6.1.2. استفاده از JWT:سومین روش برای امن کردن ارتباطات سرویس به سرویس در استقرار میکروسرویس‎‌ها، استفاده از JWT است. برخلاف mTLS که در لایه Transport فعالیت می‌کرد JWT در لایه‌‎ی Application کار می کند، نه لایه‏ ی انتقال. JWT در عمل همچون یک ظرف عمل می کند که میتواند مجموعه‎‌ای از داده‌ها را از جایی به جای دیگر منتقل کند. این اطلاعات، هرچیزی می تواند باشد، مثل خصوصیات کاربر نهایی (آدرس ایمیل، شماره تلفن)، عملکردهای قابل قبول کاربر نهایی (این که چه کارهایی می تواند انجام دهد) یا هرچیز دیگری که میکروسرویس جاری میخواهد برای میکروسرویس گیرنده ارسال کند. JWT شامل این اطلاعات می شود.اطلاعات داخل JWT توسط صادر کننده‌ی JWT امضا می شود. صادر کننده میتواند یک Security Token Service یا به اختصار STS خارجی باشد یا خود میکروسرویس جاری.هر میکروسرویس باید جفت کلید خودش را داشته باشد و برای امضای JWT از کلید خصوصی استفاده کند. در اکثر مواقع احرازهویت مبتنی بر JWT بر بستر TLS کار میکند: JWT احراز هویت را انجام می‌دهد و TLS قابلیت اطمینان و یکپارچگی در انتقال داده را به عهده می‌گیرد.6.2. احراز مجوز و صلاحیت در سطح سرویس:در یک استقرار معمول میکروسرویس‌‎ها، احرازصلاحیت می‌تواند در مرز صورت بگیرد یا در هر سرویس یا در هر دو . وقتی احراز صلاحیت در سطح سرویس انجام شود، دست بازتری برای اعمال سیاست‎‌های کنترل دسترسی‎‌هایی که دلمان می‌خواهد داشته باشیم، خواهیم داشت. دو روش برای اعمال صلاحیت دسترسی در سطح سرویس مطرح است: مدل مرکزی PDP و مدل توکار PDP. در اینجا PDP مخفف Policy Decision Point می‌باشد.در مدل مرکزی PDP، تمام سیاست‎های کنترل دسترسی، در یک‌جای مرکزی، ایجاد، نگهداری و اجرا می‌شوند (تصویر 3 را ببینید). هربار که سرویس بخواهد یک درخواست را اعتبارسنجی کند، باید با نقطه انتهایی که توسط PDP مرکزی عرضه شده است صحبت کند. این روش به طور جدی به PDP وابسته است و تاخیر را به علت هزینه فراخوانی از راه دور با نقطه‌ انتهاییPDP افزایش می‌دهد. در این موارد، با ذخیره موقت سیاست‎های کنترل دسترسی در سطح سرویس می‌توانیم این تاخیر را ازبین ببریم، اما وقتی این ذخیره موقت بخاطر محدودیت زمانی از بین برود، یا برای دریافت سیاست‎های جدید، طبعا دوباره باید با PDP ارتباط بگیرد. در عمل، سیاست‌های جدید به ندرت اضافه می‌شوند، اما انقضای زمانی حافظه‎ ی موقت مسئله‎ای پر رخداد است.با PDP توکار، سیاست‎ها به شکل مرکزی تعریف، اما در سطح سرویس نگهداری و اجرا می شوند. چالش PDPهای توکار این است که چطور سیاست‎ها را از طریق Policy Administration Point یا به اختصار PAP مرکزی بروز رسانی کنیم. تصویر 3 احراز مجوز‌ها به صورت مرکزیبرای انجام این کار دو روش متداول وجود دارد. یک روش دریافت مستمر از PAP بعد از یک بازه زمانی می‌باشد و مجدد دریافت سیاست‎های جدید از PAP. روش دیگر، مکانیزم ارسال است. زمانی که سیاستی تغییر کرد یا اضافه شد، خود PAP آن را بعنوان یک رخداد منتشر میکند. در این حالت، هر میکروسرویس بعنوان دریافت کننده رخداد عمل میکند و سیاست‎های مربوط به خودش را از PAP می‌گیرد و PDP توکار خودش را بروز می‌کند.برخی معتقدندکه هر دوی این روش‎‌ها مخرب و عذاب‌آور هستند. به همین دلیل آن‌ها سیاست‎ها را فقط در زمانی که سرور بالا میاید روی PDP توکار بارگذاری می‌کنند. و هر زمانی که سیاست جدیدی اضافه شد یا تغییر کرد، تمام سرویس‌ها براید دریافت تغییرات مجبور به شروع مجدد هستند.6.3. انتشار اطلاعات زمینه‌ای کاربر:زمانیکه یک میکروسرویس یک میکروسرویس دیگر را فراخوانی میکند، نیاز دارد که شناسه‌‎ی کاربرنهایی و شناسه‌‏ی خود میکروسرویس را ارسال کند. زمانیکه یک میکروسرویس با استفاده از mTLS و JWT احراز هویت می‌کند، شناسه‎‌ی میکروسرویس فراخوانی کننده درون اعتبارنامه‎‌ی توکار آن تزریق می‌شود. سه راه معمول برای ارسال اطلاعات زمینه‌ای کاربرنهایی از یک میکروسرویس به یک میکروسرویس دیگر وجود دارد:روش اول ارسال اطلاعات کاربر در Headerهای HTTP است. این تکنیک به میکروسرویس دریافت کننده کمک می‌کند تا کاربر را تشخیص دهد، اما لازمه این کار اعتماد دریافت کننده به فراخوانی کننده است. اگر فراخوانی کننده بخواهد که دریافت کننده را فریب دهد به آسانی فقط با تنظیم نام دلخواهش در Headerهای HTTP می‌تواند اینکار را انجام دهد.روش دوم استفاده از JWT است. JWT اطلاعات زمینه‌ای کاربر را از میکروسرویس فراخوانی کننده به میکروسرویس گیرنده حمل می‌کند و او هم آن را درون سربرگ HTTP قرار میدهد. اگر قرار باشد سرویس صدا زننده خودش صادرکننده JWT باشد، هیچ ارزش افزوده‎ای نسبت به روش اول ندارد. JWTای که سرویس صدازننده تولید می‌کند، توسط خود سرویس فراخوانی کننده امضا می‌شود، فلذا براحتی می‌تواند میکروسرویس دریافت کننده را با اضافه کردن هر اطلاعات دلخواهی به آن در مورد اطلاعات زمینه‌ای کاربر فریب دهد. سومین روش نیز استفاده از JWTای که توسط یک STS خارجی صادر شده است و برای تمام ماشین‎‌های درون استقرار قابل اطمینان است. اطلاعات زمینه‌ای کاربر که درون JWT قرار گرفته است امکان تغییر ندارد، چنانچه تغییر کند، امضای JWT نامعتبر می‌شود. این امن‎‌ترین روش است. زمانی که JWT را از یک STS خارجی دارید، میکروسرویس فراخوانی کننده میتواند آن را درون یک JWT دیگر کار بگذارد و با اینکار JWT تو درتو ایجاد کند. 6.4. عبور از محدوده امن:به طور معمول هنگام انتشار میکروسرویس‌ها چندین محدوده مورد اطمینان خواهیم داشت. این محدوده‌های مورد اطمینان آن‌هایی هستند که تیم‌های توسعه میکروسرویس بر روی استراتژی‌ها و نحوه مدیریت آن‌ها نظارت دارند یا به کمک روابط سازمانی می‌توانند آن‌ها را کنترل کنند. برای مثلا در یک سیستم خرده فروشی، واحد خرید و فروش احتمالا بر روی تمامی سرویس‌های توسعه داده شده در این حوزه کنترل و نظارت دارد و محدوده مورد اطمینان خود را می‌سازد.هنگامی که دو سرویس در یک محدوده اطمینان با هم صحبت می‌کنند، آن سرویس‌ها به STS مرکزی اطمینان دارند و که با آن‌ها در یک دامنه اطمینان قرار دارد. با توجه به این اطمینان موجود بین سرویس‌ها و STS، میکروسرویس‌ها می‌توانند توکن‌های امنیتی که برای آن‌ها ارسال می‌شود را به سادگی بررسی و صحبت سنجی کنند. معمولا در یک دامنه مورد اطمینان یک STS هم وجود دارد که همه میکروسرویس‌های حاضر در این دامنه از آن برای صحت سنجی و انتشار نشانه‌های امنیتی استفاده می‌کنند. اگر یک میکروسرویس بخواهد با میکروسرویس خارج از محدوده اطمینان جاری خود ارتباط برقرار کند دو حالت کلی برای انجام این کار وجود دارد. برای تشریح اولین حالت به تصویر 4 نگاه کنید. تصویر 4 ارتباط میکروسرویس ها در دو محدوده داخل یک مرزفرض کنید که سرویس Order Processing در دامنه اطمینان foo می‌خواهد با میکروسرویس Delivery Service در دامنه اطمینان bar ارتباط برقرار کند. ابتدا میکروسرویس Order Processing باید یک توکن که مورد قبول میکروسرویس‌های حاضر در محدوده bar هستند را به دست آورد. به بیان دیگر سرویس حاضر در محدوده foo باید برای دریافت نشان امنیتی از طریق STSحاضر در محدوده امنیتی bar اقدام نماید. مراحل انجام این کار به شرح زیر می‌باشد.در اولین قدم API Gateway درخواست را از اپلیکیشن مشتری به میکروسرویس Order Processing در حوزه مطمئن foo بهمراه JWT امضا شده توسط API Gateway یا توسط STS متصل به آن ارسال می‌کند. از آنجاییکه تمام میکروسرویس‎های حوزه مطمئن foo به STS بالاترین سطح اطمینان دارند، میکروسرویس Order Processing توکن را بعنوان نشانه معتبر می‌پذیرد. JWT خاصیتی دارد بنام aud که سیستم هدف JWT را مشخص میکند. در این مورد، مقدار aud با میکروسرویس Order Processing حوزه foo تنظیم شده است. در حالت ایده‎‌آل، زمانی که میکروسرویس Order Processing یک JWT را با مقدار متفاوت aud دریافت کند، باید آن JWT را نادیده بگیرد، حتی اگر امضای آن معتبر باشد.قدم دوم این است که میکروسرویس Order Processing آن JWTای که از API Gateway یا STS سطح بالاتر گرفته است برای STS درون حوزه مطمئن foo ارسال میکند. تکرار می کنم، STS حوزه foo باید مقدار aud درون JWTای که دریافت کرده است را اعتبارسنجی کند. اگر نتواند نشانه آن را شناسایی کند، باید آن را نادیده بگیرد.سومین قدم این است که STS درون foo یک JWT جدید که توسط خودش امضا کرده است و مقدار aud آن را برابر با STS حوزه مطمئن bar قرار داده است برمی‌گرداند.در چهارمین و پنجمین قدم میکروسرویس Order Processing به STS حوزه مطمئن bar دسترسی پیدا می‌کند و JWT بدست آمده از قدم سوم را ارسال کرده و یک JWT امضا شده توسط STS حوزه مطمئن bar دریافت می‌کند و البته مقدار aud آن را برابر با میکروسرویس Delivery قرار می‌دهد.قدم ششم میکروسرویس Order Processing به میکروسرویس Delivery بواسطه JWT بدست آمده از قدم پنج دسترسی می‌گیرد و از آنجاییکه STS حوزه bar این JWT را امضا کرده است و مقدار aud درست می‌باشد، میکروسرویس Delivery توکن را می‌پذیرد.اما در حالت دوم سرویس‌ها پشت یک API Gateway قرار ندارند. در این حالت هر میکروسرویس در حوزه اطمینان خود و با یک API Gateway جداگانه قرار دارد که نمونه‌ای از این حالت را در تصویر 5 مشاهده می‌کنید. تصویر 5 ارتباط پشت API Gatewayهادر چنین شرایطی انجام ارتباط به شرح زیر صورت خواهد پذیرفت.در اولین قدم API Gateway درون حوزه‌‎ی مطمئن fooدرخواست را از نرم‌افزار مشتری به سمت میکروسرویس Order Processingبهمراه JWTامضا شده توسط API Gateway یا توسط STS درون foo که به API Gateway این حوزه چسبیده شده ارسال می‌کند. از آنجاییکه تمام میکروسرویس‌‎های درون حوزه foo به STS این حوزه اعتماد دارند، میکروسرویس Order Processing توکن رسیده را معتبر به حساب می‌آورد.در قدم دوم میکروسرویس Order Process، JWT اصلی را که از API Gateway یا همان STS حوزه foo دریافت کرده است را برای STS خود ارسال می‌کند.قدم سوم به این شکل است که STS حوزه foo یک JWT جدید برمی‌گرداند که توسط خودش برای API Gateway درون حوزه مطمئن bar امضا کرده است.در چهارمین قدم میکروسرویس Order Processing توسط JWTای که در قدم سوم بدست آمد، به میکروسرویس Delivery درون حوزه مطمئن bar دسترسی پیدا می‌کند. از آنجاییکه API Gateway حوزه bar به STS حوزه foo اطمینان دارد، JWT را معتبر تشخیص می‌دهد. JWT توسط STS حوزه foo امضا شده است و با API Gatewayحوزه bar همخوانی دارد.قدم پنجم این است که API Gatewayحوزه bar با STS حوزه bar صحبت می‌کند تا JWT خودش را ایجاد کند (یعنی توسط STS حوزه bar امضا شده باشد) که برای میکروسرویس Delivery امضا شده باشد.در انتها و ششمین قدم API Gatewayحوزه bar درخواست را به‌ همراه JWT صادر شده از STS حوزه bar به سمت میکروسرویس Delivery ارسال می‌کند. از آنجایی که میکروسرویس Delivery به STS خودش اطمینان دارد، نشانه بعنوان معتبر پذیرفته می‌شود.7. جمع بندی:در این قسمت با بخش دیگری از مقدمات امنیت در میکروسرویس‌ها آشنا شدیم، با هم دیدیم چالش‌های یکسانی در ارتباط با دنیای بیرون اپلیکیشن از طریق API Gateway و دنیای داخل اپلیکیشن بین میکروسرویس‌ها وجود دارد که برای هر چالش و صورت مسئله مثل شناسایی کاربر و مشتری و ... راهکارهای متفاوتی در دو حوزه وجود دارد!در قسمت‌های بعد مطالبی که در این دو قسمت به صورت اجمالی بیان شده است را با جزئیات بیشتری بررسی خواهیم کرد!پ.ن: منابع مورد استفاده در این سری مطالب همگی در مطلب اول ذکر شده است و از نام آوردن منابع به صورت تکراری اجتناب می‌کنم. علیرضا ارومند علیرضا ارومند Mon, 12 Jul 2021 11:07:15 +0430 https://virgool.io/dotin/%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%AF%D8%B1-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-ipowy6lmdndy 1. مقدمه تاریخچه، نحوه امن کردن نرم‌افزارهای یکپارچهیک نرم‌افزار یکپارچه تعداد کمی درگاه ورودی دارد. درگاه ورودی برای یک نرم‌افزار حکم درب یک ساختمان را دارد. همانطور که درب ورودی امکان وارد شدن به یک ساختمان را می‏دهد (احتمالا بعد از بررسی‏های امنیتی)، درگاه ورودی یک اپلیکیشن هم امکان درخواست دادن را مهیا می‏کند.یک نرم‌افزار تحت وب را تصور کنید (تصویر 1 را ببینید) که روی درگاهپیشفرض HTTP یعنی درگاه شماره 80 یک سرور با آدرس 192.168.0.1 در حال اجراست. درگاه 80 سرور 192.168.0.1 روی این سرور بعنوان مدخل ورودی نرم‌افزار ما است. اگر همین نرم‌افزار درخواست‏های HTTPS روی درگاه 443 همین سرور را هم بپذیرد، اکنون یک درگاه ورودی دیگر هم داریم. هرچقدر درگاه ورودی بیشتری داشته باشید، مکان‏های بیشتری برای نگرانی داریم. بعنوان مثال، زمانیکه مرز بیشتری برای محافظت دارید، سربازهای بیشتری هم نیاز دارید، یا باید دیواری مستحکم برای تمام درگاه‎های ورودی بسازید. درگاه‎های ورودی بیشتر یک اپلیکیشن به معنای مرزهایی هستند که مورد حمله قرار میگیرند.عمده نرم‌افزارهای یکپارچه، تعداد کمی درگاه ورودی بیشتر ندارند. هر جزء یک نرم‌افزار یکپارچه که به دنیای خارج سرویس میدهد، بطور مستقیم درخواست را قبول نمی‌کنند.در بستر معمول جاوا (وب اپلیکیشن‏های نسخه‌‏ی سازمانی Java EE که در تصویر 1 آماده است)، تمام درخواست‏های ورودی در سطح نرم‌افزار به واسطه‏ی servlet filter بررسی می‏شوند. در این غربالگری امنیتی بررسی می‏شود که آیا درخواست جاری مرتبط به یک نشست معتبر است و اگر نیست این درخواست را به سمت احراز هویت سوق دهد.تصویر 1 نمونه نرم‌افزار یکپارچه با دو درگاه ورودیدر مرحله بعد کنترل دسترسی‏های بیشتر بررسی می‌کنند که آیا طرف درخواست کننده اجازه یا صلاحیت‏های مورد نیاز برای آنچه که می‌خواهد را دارد یا نه. تمامی این کارها را بازرس بطور مرکزی انجام می‌دهد تا مطمئن شود درخواست‏های مشروع و مورد قبول به اجزای مربوطه برسد. اجزای درونی اهمیتی به مشروعیت درخواست نمی‌دهند، و همواره چنین پیشفرضی دارند که اگر درخواستی که به این مرحله رسیده است حتما موارد امنیتی آن بررسی شده است.در مواردی که اجزا‏ نیاز داشته باشند که بدانند طرف درخواست کننده (یا کاربر) کیست یا اطلاعاتی مرتبط با طرف درخواست کننده داشته باشند، چنین اطلاعاتی را می‌توانند از نشست وب که در سطح اپلیکیشن و برای تمام اجزا مشترک است، بازیابی کنند (عکس 2 را ببینید). Servlet filter در فرایند غربالگری اولیه بعد از فرایند احراز هویت و احراز مجوزها، اطلاعات طرف درخواست کننده را به نشست وب تزریق می‌کند.هنگامی که درخواست به لایه اپلیکیشن رسید، دیگر نباید نگرانی‌ای درخصوص ارتباط یک جزء با دیگری داشت. بعنوان مثال، زمانیکه زیرسیستم Order Processing با زیرسیستم Inventory صحبت می‏کند، الزامی به بررسی‏های امنیتی بیشتر نیست (البته این به این معنا نیست که شما نمی‌توانید به ازای هر جز، در سطح کامپوننت کنترل دسترسی داشته باشید). این عملیات فراخوانی‏های داخلی هستند و در غالب اوقات شنود آن برای شخص ثالث کار دشواری خواهد بود.تصویر 2 اشتراک نشست توسط بازرس مرکزی برای اجزا داخلی سیستم در اکثر نرم‌افزار‏های یکپارچه، امنیت در یک بخش مرکزی قرار دارد و تک تک اجزا نیازی به بررسی‏های بیشتر ندارند مگر در موارد بخصوص بسته به نوع نیاز داخلی یک قسمت از برنامه. به همین دلیل مدل امنیتی نرم‌افزار‏های یکپارچه به مراتب سر راست‌تر از میکروسرویس‌ها است.2. مبانی کلیدی امنیت:پایبندی به اصول در همه طرح‌های امنیتی مهم است. هیچ امنیت بی‎‌نقص و یا غیرقابل شکستنی وجود ندارد. باید این نکته را نیز در نظر بگیرید که میزان نگرانی شما در رابطه با امنیت صرفا یک کار فنی نبوده و تاثیرات اقتصادی نیز دارد. برای مثال برای امن کردن یک گاراژ خالی استفاده از یک دزدگیر فوق پیشرفته بی‌فایده است. بسته به دارایی که از آن‌ها محافظت می‌کنیم، سطح امنیت نیز تغییر می‌کند. به طور یقین طرح امنیتی برای یک فروشگاه اینترنتی با یک نرم‌افزار مالی متفاوت است.پایبندی به اصول امنیتی مهم است. حتی اگر برخی تهدیدات امنیتی را پیشبینی نکنید، پیروی از اصول امنیتی به شما برای در امان ماندن از این تهدیدات کمک خواهد. در این قسمت، ما اصول امنیتی را گام به گام با شما بررسی می‌کنیم و به ارتباط آن‎ها با امنیت میکروسرویس‎ها خواهیم پرداخت.2.1. جلوگیری از کلاهبرداری به کمک احراز هویت:شناسایی طرف درخواست کننده به‌منظور حفاظت از سیستم در برابر کلاهبرداری را احراز هویت می‌نامیم. طرف درخواست کننده می‌تواند یک سیستم باشد (یک میکروسرویس) یا یک سیستمی که توسط کاربر انسانی یا یک سیستم دیگر کنترل میشود (تصویر 3 را ببینید). این نوع دسترسی با دسترسی مستقیم کاربر انسانی به یک میکروسرویس متفاوت است. پیش از ایجاد یک طرح امنیتی برای سیستمی که درباره آن صحبت کردیم، باید شرکت‌کنندگان را بشناسیم. روش احراز هویتی که استفاده می‌کنید وابسته به شرکت کنندگان است.تصویر 3 اتصال سرویس‌ها به یکدیگر با و یدون عامل انسانی اگر نگران دسترسی یک سیستم به میکروسرویس هستید که در پشت صحنه توسط یک کابر هدایت می‌شود باید به این موضوع فکر کنید که چگونه آن سیستم می‌تواند مانند یک کاربرا در سیستم احراز هویت شود. در عمل ممکن است یک وب اپلیکیشن داشته باشیم که کاربری انسانی در آن احراز هویت شده و آن سیستم به میکروسرویس متصل می‌شود. در شرایطی، که یک سیستم درخواست دسترسی از طرف یک سیستم دیگر که قبل از آن یک عامل انسانی در آن احراز هویت شده است دارد، OAuth 2.0 استاندارد امنیتی مناسبی است. برای احراز هویت کاربرانسانی به سیستم ( برای مثال، یک وب اپلیکیشن)،در روش‌های مبتنی بر چند روش احراز هویت، باید درخواست نام کاربری و رمز عبور به همراه عنصر دیگر برای احرازهویت داشته باشید (Multi-Factor Authentication یا MFA). در اغلب موارد MFA یک تصمیم تجاری است که با توجه به میزان اهمیت دارایی‎های تجاری و یا میزان حساسیت داده‎هایی که میخواهید به کاربران منتقل کنید گرفته می‌شود. مشهورترین نوع استفاده از MFA کدعبور یکبار مصرف است (One time password یا OTP) که معمولا از طریق پیامک (SMS) ارسال می‌شود. شاید این راه در دنیای امنیت بهترین روش نباشد، اما پراستفاده‎‌ترین شکل از بکارگیری MFA می‌باشد، چرا که عمدتا جمعیت کثیری از جهان به تلفن‌های موبایل دسترسی دارند که الزاما نیازی هم نیست تلفن های هوشمند باشند. MFA به کاهش 99.99 درصدی رخنه‌‎های مربوط به حساب کاربری منجر شده است. انواع مطمئن‏‌تری از MFA وجود داند که از علائم حیاتی، گواهینامه‎‌ها و Fast Identity Online (FIDO) استفاده میکند.چندین راه برای احرازهویت یک سیستم وجود دارد که محبوب‎ترین گزینه‏‌ها استفاده از گواهینامه‎‌ها و JWTها می‌باشد.2.2. جلوگیری از تغییر غیرمجاز داده‌ها به کمک یکپارچگی:هنگامی که داده ها بین دو سرویس انتقال پیدا می‌کند، با توجه به قدرت کانال ارتباطی که مورد استفاده قرار می‌گیرد، ممکن است داده‌ها توسط فردی نفوذی در مسیر انتقال تغییر پیدا کند. برای مثال ممکن است پیامی که بین دو سیستم انتقال پیدا می‌کند مربوط به آدرس ارسال یک سفارش اینترنتی باشد و فرد نفوذی آدرس خود را با آدرس دریافت کننده حقیقی جایگزین کند. در حقیقت سیستم‌های مبتنی بر یکپارچگی راهکاری جهت جلوگیری از این دسترسی ارائه نمی‌کنند، بلکه راهکارهایی ایجاد می‌کنند که به کمک آن از تغییر داده‌ها در بین راه مطلع شوید.یکی از راهکارهای معمول برای پیاده سازی یکپارچگی داده، امضا کردن آن‌ها است. هر داده‌ای که انتقال پیدا می‌کند به کمک TLSمحافظت می‌شود. اگر از HTTPS برای انتقال داده‌ها بین سرویس‌ها استفاده کنید، پیام‌های شما به کمک TLSحفاظت می‌شود. 2.3. انکار ناپذیری:انکارناپذیری یکی از اصول امنیت نرم‌افزار است که مانع از عدم پذیرش مسئولیت کارهایی که انجام داده‌ایم می‌شود. در دنیای واقعی نیز چنین شرایطی وجود دارد. برای مثال فرض کنید زمانی‌که شما یک آپارتمان اجاره می‌کنید، برای مدت و هزینه‌ای معین، یک قرارداد امضا می‌کنید که با امضای آن قرارداد تصریح می‌کنید که به تمامی مفاد آن قرار داد پایبند هستید. شما نمی‌توانید اجاره ماهانه را پرداخت نکنید یا اگر بخواهید زود تر منزل را ترک کنید، یا باید اجاره ماه‌های باقی مانده را پرداخت کنید یا ناچارید شخص جایگزینی برای اجاره منزل بیابید. این انکارناپذیری در دنیای واقعی است. در دنیای دیجیتال نیز امضا همین حکم را دارد و مانع از انکار حقایق می‌شود. فقط به جای امضای حقیقی با امضای دیجیتال سر و کار داریم.فرض کنید یک فروشگاه اینترنتی دارید، اگر سفارشی در فروشگاه ثبت شود، میکروسرویس مدیریت سفارشات باید به سراغ میکروسرویس انبار برود و موجودی آن کالا را کسر کرده و برای ارسال آماده کند. در صورتی که برای این تراکنش امضای دیجیتال در نظر گرفته شده باشد، در آینده میکروسرویس مدیریت سفارشات نمی‌تواند انجام این تراکنش را انکار کند. در روش امضای دیجیتال، مالک امضا یک کلید خصوصی دارد که تنها به کمک آن امکان ایجاد امضا‌های کاملا مشابه وجود دارد و سایرین به کمک کلید عمومی این امضا را تایید می‌کنند. حفظ و نگهداری کلید خصوصی بسیار اهمیت دارد.2.4. محرمانگی و جلوگیری از انتشار داده‌های خصوصی:هنگامی که درخواست ثبت یک سفارش از نرم‌افزار مشتری به میکروسرویس ثبت سفارشات ارسال می‌شود، شما توقع دارید که به جز بخش ثبت سفارشات سایر قسمت‌ها به اطلاعات در حال جابجایی دسترسی نداشته باشند. با توجه به سطح امنیتی که کانال ارتباطی شما رعایت می‌کند، یک متجاوز می‌تواند به داده‌های در حال انتقال دسترسی داشته باشد. به جز داده‌هایی که روی کانال‌های ارتباطی در حال انتقال هستند، داده‌های داخلی برنامه نیز باید از دسترسی غیرمجاز حفظ شوند. اگر یک فرد متجاوز به محل ذخیره‌سازی فایل‌ها یا پایگاه‌های داده شما دسترسی پیدا کند، به سادگی به تمامی داده‌های حیاتی کسب و کار شما دسترسی خواهد داشت، مگر اینکه آن‌ها را برای چنین روزهایی در سطح محرمانگی خوبی قرار داده باشی.برای حفظ محرمانگی داده‌های در حال جابجایی معمولا از رمزگذاری داده‌ها استفاده می‌کنند. یک روال رمزگذاری خوب این اطمینان را به ما می‌دهد که اطلاعاتی که رمزنگاری شده است، تنها توسط اهدافی که قرار است به داده‌ها دسترسی داشته باشند قابل مشاهده است. اساسا TLS یکی از روش‌های اطمینان از محرمانگی هنگام انتقال داده‌ها است. اگر میکروسرویس‌های ما برای برقراری ارتباط از HTTPS استفاده کنند، می‌توانیم اطمینان حاصل کنیم که تنها دریافت کننده صحیح توانایی مشاهده داده‌ها را خواهد داشت.باید به این نکته دقت داشته باشید که این سطح از حفظ محرمانگی صرفا برای جابجایی داده‌ها کاربرد دارد. یعنی داده‌های خام در اختیار مالک اطلاعات است و هنگامی که اقدام به ارسال می‌کند TLS داده‌ها را رمزگذاری کرده و در بستری امن منتقل می‌کند، درست در لحظه ای که انتقال به پایان می‌رسد و داده‌ها به مقصد می‌رسند، مجدد از حالت رمزنگاری خارج شده و به صورت کاملا خام و واضح در اختیار دریافت کننده قرار می‌گیرند.در صورتی که نیاز داشته باشیم داده‌ها در مقصد نیز باید مجددا رمزگذاری شوند. یعنی هنگامی که اطلاعات را روی دیسک‌های سخت ذخیره می‌کنیم، سایر سیستم‌هایی که به فضای دیسک‌ها دسترسی دارند نباید بتوانند خارج از فرایند میکروسرویس‌های ما به اطلاعات دسترسی داشته باشند و اگر داده‌ای نیاز دارند باید از طریق نرم‌افزار درخواست دسترسی به آن داده‌ها را ارسال کنند. اغلب نرم‌افزارهای پایگاه داده این امکان را به صورت توکار پیاده‌سازی کرده‌اند و برای داده‌های حساس خود می‌توانیم از این امکانات توکار استفاده کنیم.2.5. دسترسی پذیری ویژگی مهم نرم‌افزار:یکی از نکاتی که هنگام طراحی سیستم‌های نرم‌افزاری باید به آن توجه کرد این است که سیستم باید دائما در دسترس باشد. از دسترس خارج شدن یک سیستم نرم‌افزاری می‌تواند ضرر هنگفتی را به کسب و کار وارد کند. در ماه مارچ سال 2016 وبسایت آمازون برای 20 دقیقه از دسترس خارج شد و ضرر این سایت برای این 20 دقیقه چیزی در حدود 3.75 میلیون دلار براورد می‌شود. در تابستان سال 1399 وب سایت سفارشات یک کارگزار ایرانی برای 1 روز کاری از دسترس خارج شد و ضرری در حدود 20 میلیارد تومانی برای این کارگزاری و سهامداران عضو آن براورد گردید.دسترسی‌پذیری یک سامانه‌نرم افزاری صرفا یک ویژگی و کارکرد امنیتی نیست، بلکه مبحثی عمومی و مربوط به معماری کل سیستم می‌شود. برای مثلا یک خطای بحرانی در قلب سورس‌کدهای کسب و کار ممکن است منجر به از دسترس خارج شدن آن شود. اما در بین ویژگی‌های مختلفی که موجود دسترسی‌پذیری سیستم می‌شود، رعایت نکات امنیتی از اهمیت ویژه‌ای برخوردار است.در یک سیستم که زیرساخت‌های امنیتی خوبی نداشته باشند، حمله کنندگان ممکن است با حملات Dos یا DDos تلاش کنند سیستم را برای ارائه خدمات نا‌توان کنند . مقابله با این حملات در سطوح مختلفی قابل انجام است. در سطح نرم‌افزار بهترین راه مقابله با این حملات این است که به محض یافتن درخواست‌های نامشروع آن‌ها را از چرخه پردازش خارج کنید. طراحی یک نرم‌افزار به صورت چند لایه این امکان را فراهم می‌کند که در هر لایه مراقب برخی تهدیدات امنیتی بود و با یافتن آن‌ها، از ایجاد خسارت توسط آن تهدید جلوگیری کنیم. در یک نرم‌افزار میکروسرویس همه درخواست ها از طریق یک دروازه به APIها می‌رسند. اگر بخواهیم در مورد حملات DDos تصمیم گیری کنیم بهترین محل جلوگیری از آن‌ها ابتدا در لایه شبکه است. اگر از این لایه عبور کرد بهترین راهکار استفاده از دیواره‌آتش است. بعد از آن درخواست‌ها به API Gatewayمی‌رسد که آنجا نیز می‌توانیم با بررسی درخواست‌ها، موارد غیرقانونی را از چرخه حیات خارج کنیم.2.5. احراز مجوز و تعیین محدوده اختیارات:احراز هویت به ما می‌گوید که چه فردی با سیستم می‌خواهد کار کند و احراز مجوز تعیین می‌کند که کاربر در چه محدوده‌ای از نرم‌افزار می‌تواند کار خود را انجام دهد . برای مثال در یک سیستم فروشگاه اینترنتی ما ابتدا با احراز هویت مشتری را شناسایی می‌کنیم و پس از آن با احراز مجوز تعیین می‌کنیم که مشتری به چه قسمت‌هایی از نرم‌افزار دسترسی دارد. برای مثلا امکان ثبت سفارش دارد، ‌می‌تواند کالاها را مورد بررسی قرار دهد و می‌تواند سفارشات پیشین خود را مشاهده کند، اما نمی‌تواند قیمت یک کالا را تغییر دهد یا کالای جدید ثبت کند. در یک سیستم توسعه داده شده بر مبنای میکروسرویس این احراز مجوز معمولا در مرزهایبیرونی که همان API Gateway است اتفاق می‌افتد. در اصل ارتباط اگر از بیرون سیستم باشد در سطح مرز و API Gateway احراز مجوز می‌شود. ولی ممکن است در هنگام ارتباط داخلی بین سرویس‌ها نیز نیاز به احراز هویت و مجوز داشته باشیم که در این سطح دیگر داخل سرویس‌ها این عملیات انجام می‌شود.3. جمع بندی:در این مطلب که در چندین قسمت منتشر خواهد شد به بحث و بررسی موارد امنیتی در حوزه نرم‌افزارهای توزیع شده می پردازیم. مطالبی که در قسمت اول عنوان شد اغلب به حوزه عمومی برنامه‌ها و معماری یک‌پارچه نیز مرتبط است که در قسمت‌های بعد این مباحث را در نرم‌افزارهای توزیع شده با جزئیات بیشتری بررسی خواهیم کرد.در صورتی که دوست داشتید با این مفاهیم بهتر و دقیق‌تر آشنا بشید منابع زیر کمک بسیار کمک کننده خواهند بود:1. Christudas, B. (2019). Practical Microservices Architectural Patterns. Berkeley, CA: APress.2. Fowler, m., Lewis, J. (2014). Microservice A Definitioin of This New Architecture Term. https://martinfowler.com/articles/microservices.html3. Gilman, E., Barth, D. (2017). Zero Trust Networks: Building Secure Systems in Untrusted Networks. Cambridge, England: O’Reilly.4. IDC. (2018). Enterprise Adoption of Microservices Architecture Push ISVs to Modernize. https://www.idc.com/getdoc.jsp?containerId=US449298195. J.Fowler, S. (2017). Production-Ready Microservices. Cambridge, England: O’Reilly.6. Kamaraju, A. (2012). Database encryption demystified: Four common misconceptions. https://www.zdnet.com/article/database-encryption-demystified-four-common-misconceptions/7. Joseph. C, Chandrasekaran .K, (2019). Straddling the crevasse: A review of microservice software architecture foundations and recent advancements. Software: Practive and Experience, 49(10), 1448–1484.8. Lepofsky, R. (2014). The Manager’s Guide to Web Application Security. Berkeley, CA: APress.9. Lu. D, Huang .D, Walenstein .A & , Medhi .D, (2017). A Secure Microservice Framework for IoT. 2017 11th IEEE Symposium on Service-Oriented System Engineering (SOSE), 1, 9–18.10. McDonald, M. (2020). Web Security for Developers Real Threats, Practical Defense. San Francisco, US: No Starch Press.11. Mauro, T. (2015). Adopting Microservices at Netflix: Lessons for Architectural Design. https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/12. Newman, S. (2015). Building Microservices Designing Fine-Grained System. Cambridge, England: O’Reilly.13. Newman, S. (2018). Monolith to Microservices Evolutionary Patterns to Transform Your Monolith. Cambridge, England: O’Reilly.14. Rafe. V, Hosseinpouri. R, (2015). A security framework for developing service‐oriented software architectures. Security And Communication Networks, 8(17), 2957–2972.15. Siriwardena, P. (2020). Advanced API Security: OAuth 2.0 and Beyond Berkeley, CA: APress.16. Siriwardena, P., & Dias, N. (2020). Microservices Security in Action. Ny, USA: Manning.17. Yarygina. T, Bagge. A, (2018). Overcoming Security Challenges in Microservice Architectures. 2018 IEEE Symposium on Service-Oriented System Engineering (SOSE), 1, 11–21.18. Yu. D, Jin. Y, Zhang. Y& Zheng. X, (2018). A survey on security issues in services communication of Microservices‐enabled fog applications. Concurrency and Computation Practive and Experience. علیرضا ارومند علیرضا ارومند Sat, 03 Jul 2021 13:34:20 +0430 https://virgool.io/dotin/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-impact-mapping-z1b6wmzh2lzd 1. مقدمه:هنگام که می‌خواهیم ویژگی‌هایی را به محصول خود اضافه کنیم نیاز به ابزارها و روال‌هایی داریم که ما را در این فرایند تشخیص، تعریف و اولویت بندی این ویژگی‌ها کمک کنند. Impact Mapping یک تکنیک گرافیکی برنامه ریزی استراتژیک است. در ابتدا برای خود هدفی تعیین می‌کنیم و از همانجا شروع به گسترش کار خواهیم کرد. هر ویژگی که شناسایی می‌کنیم تاثیری مستقیم در رسیدن به آن هدف خواهد داشت. Impact Mapping هنگام توسعه و تحویل محصول به تیم‌ها کمک می‌کند تا فعالیت‌های خود را در راستای اهداف کسب و کار قرار داده و از گم شدن تیم‌ها در مسیر پرپیچ و خم توسعه محصول جلو‌گیری می‌کند. این تکنیک در سال 2012 توسط Gojko Adzic در کتاب Impact Mapping معرفی شد.2. معرفی Impact Mapping:مانند Story Mapping و Mind Mapping این تکنیک هم یک روش بصری است. این روش برای تشخیص و اولویت بندی ویژگی‌ها مورد نیاز استفاده می‌شود. این تکنیک خیلی سریع برای ما یک مسیر جذاب ایجاد می‌کند. مسیری که از هدف اصلی شروع می‌شود و تعیین می‌کند کدامیک از نقش آفرینان (Actor) در سیستم چه تاثیری برای رسیدن به هدف می‌تواند ایجاد کنند و برای اینکه بخواهد این تاثر را ایجاد کنند چه کارهایی باید انجام دهند.هنگامی که هدف را پایه و اساس کار قرار می‌دهیم، عملا زمان بیشتری را برای تشخیص و تعریف دقیق‌تر هدف تخصیص می‌دهیم. اگر هدف درست و خوش تعریفی نداشته باشیم هر تلاشی ممکن است ما را از مسیر اصلی کار دور کند. اگر می‌خواهیم مطمئن باشیم هدف درستی داریم باید به این پنج پرسش که مخفف آن Smart می‌شود پاسخ دهیم:آیا هدف شما خاص (Specific) است؟آیا هدف شما قابل اندازه گیری (Measurable) است؟آیا عملگرا (Action-oriented) است؟آیا هدفتان واقع‌بینانه (Realistic) است؟آیا به‌موقع (Timely) است؟مثل هر فرایند و تکنیک دیگری دیدگاه‌ها، تجربیات و نظرات مختلفی در این حوزه وجود دارد. هنگامی که این فرایند را با تیم‌ها و گروه‌های مختلفی پیش ‌می‌برید خواهید دید که با توجه به عقاید و پیش‌زمینه‌هایی که در هر گروه وجود دراد همپوشانی‌ها و تفاوت‌هایی نیز در این فرایند وجود خواهد داشت.3. تکنیک Impact Mapping چه دستاورد هایی را ایجاد می‌کند؟اگر این تکنیک به درستی و کامل انجام شود، دستاورد‌های مختلفی را به دنبال خواهد داشت. تیم اجرایی، هدفی را تعیین کرده است و با کمک این تکنیک ارتباط بین دست‌یابی به هدف تعیین شده و سرمایه‌گذاری که روی محصول انجام می‌شود واضح و شفاف خواهد شد. وقتی که تیم اجرایی تاثیر سرمایه گذاری خود روی محصول و هدفی که می‌خواهند به آن رسند را به طور واضح مشاهده می‌کند، در انجام آن کار مصمم خواهد شد و هر بحث و جنجالی در مورد ارزشمند بودن سرمایه گذاری روی محصول پایان خواهد یافت. تمام توجه‌ها به فراهم کردن سرمایه و ابزارهای مورد نیاز برای پیاده سازی محصول و رسیدن به هدف متمرکز خواهد شد.از منظر تیم توسعه اگر به این نقشه راه نگاه کنیم آن‌ها یک ارتباط مستقیم بین عملکرد‌هایی که پیاده سازی می‌کنند و هدف سازمان مشاهده می‌کنند. با این نقشه راهی که در اختیار تیم قرار دارد آن‌ها کاملا روی ویژگی‌هایی متمرکز می‌شوند که در جهت رسیدن به هدف است. هر گونه حواس پرتی و توجه به ویژگی‌هایی که برای رسیدن به هدف مهم نیست از فرایند‌های تیم خارج خواهد شد. اما کار در اینجا به پایان نمی‌رسد. Impact Mapping برای مشتری‌های کلیدی ما نیز دستاورد‌هایی خواهد داشت. به کمک این نقشه راه مشتری‌ها ابزاری در اختیار دارند که می‌توانند اولویت‌بندی‌های خود را در پیاده سازی ویژگی‌ها را بهتر بیان کنند. 4. چرا مدیر محصول باید به این ابزار مسلح باشد؟تولید و نگهداری یک محصول یک فرایند زمانگیر است. خیلی وقت‌ها با گذر زمان شرکت‌ها و تیم‌ها فراموش می‌کنند که راه حلی که ارائه کرده اند قرار بود کدام مسئله را حل کند. محصول در طول زمان تغییر ماهیت می‌دهد و در نهایت محصولی تولید می‌شود که هیچ ارتباطی به هدف اولیه ندارد. با این شرایط یا بازار محصول از دست خواهد رفت و یا در نهایت محصولی خواهیم داشت که پر از ویژگی‌های هیجان انگیز اما بدون استفاده است که هیچ کمکی در رسیدن به هدف نمی‌کنند.به کمک Impact Mapping تیم محصول همیشه راهنمایی دارد که آن‌ها را به سمت هدف اصلی هدایت می‌کند. با استفاده از این فرایند اگر ویژگی‌ای را تشخیص دهیم که مسیری از هدف اصلی به آن وجود نداشته باشد خیلی سریع متوجه خواهیم شد که ویژگی اشتباه و غیرکاربردی را می‌خواهیم توسعه دهیم. به کمک این ابزار می‌توانیم خیلی ساده به ذینفع‌های پروژه توضیح دهیم چرا یک ویژگی را برای توسعه محصول در اولیت قرار داده ایم و ویژگی دیگری را از فرایند توسعه خارج کرده‌ایم. از آنجایی که Impact Map بسیار ساده و مصور است استفاده از آن برای هر کاری ساده است. با توجه به اینکه تمرکز کامل این تکنیک روی هدف اصلی است، اساسا جر و بحث در برابر آن اتفاق نمی‌افتد.5. چگونه یک Impact Map بسازیم؟ساخت Impact Map بسیار ساده است. در ابتدا شما به یک هدف نیاز دارید که کار را از آنجا شروع کنید و شاخ و برگ‌هایی را به آن اضافه کنید. هر مرحله که کار را جلو می‌بریم ممکن است چندین شاخه به مرحله قبل اضافه کنیم. با توجه به اینکه هر مرحله با توجه به مرحله قبل توسعه داده می‌شود بسیار مهم است که کار را مرحله به مرحله و به ترتیب پیش ببریم. اگر شما یک مرحله را رها کنید یا از چندین مرحله پرش کنید و به مرحله آخر بروید، کاملا از هدف این تکنیک دور خواهید شد. نکته کلیدی در این تکنیک این است که هر سطح از کار را با توجه به سطح قبلی توسعه دهیم. شاید در ابتدا این تکنیک کمی سخت و رسمی به نظر برسد، اما اگر کمی در آن دقیق شوید خواهید دید که کار اتفاقا بسیار ساده و غیر رسمی پیش‌خواهد رفت و کافی است یک Mind Map ساده ایجاد کنید.برای اینکه کمی دقیق تر در مورد این فرایند بدانیم در ادامه مثالی را بررسی خواهیم کرد.6. مثال:فرض کنید یک فروشگاه آنلاین دارید و محصولات متفاوتی در آن به فروش می‌رسانید. برای شما هدفی تعیین می‌شود که برای سال جاری فروش محصول یا محصولاتی را به مقدار مشخصی افزایش دهید. مثلا قرار است برای سال جاری فروش دوچرخه 25 درصد بیشتر شود. حال با این صورت مسئله به تصویر زیر نگاه کنید.همانطور که مشاهده می‌کنید با یک هدف شروع کردیم که در این مثال 25 درصد افزایش فروش دوچرخه بوده است. در ادامه تعیین کرده‌ایم که چه نقش‌آفرینانی در این فرایند می‌توانند کمک کنند. سپس تعیین کرده ایم که هر کدام از این نقش آفرینان چه تاثیری در رسیدن به این هدف می‌توانند بگذارند و در انتها گفته ایم که هر کدام از نقش آفرینان برای اینکه تاثیری که باید را در رسیدن به هدف بگذارند چه کارهایی باید انجام دهند. مثل اینکه برنامه نویس‌ها باید سرعت سایت را بیشتر کنند تا استفاده از سایت ساده‌تر شود. یا اینکه برای اینکه مراجعین غیر عضو هم برای خرید ترغیب شوند، فرایند خرید به صورت غیر عضو را به سایت اضافه کنند. حال که با یک مثال با Impact Mapping آشنا شدیم بیایید هر سطح را جداگانه معرفی و بررسی کنیم.6.1. ابتدا به سراغ چرایی انجام کار می‌رویم Goalبا هدف انجام کار شروع می‌کنیم و خیلی واضح بیان می‌کنیم چرا میخواهیم این کار‌ها را انجام دهیم. از انجا که تعیین هدف کل فرایند را تحت تاثیر قرار می‌دهد باید برای تعیین آن دقت کافی به خرج دهیم.6.2. نقش‌آفرینان افرادی که در رسیدن به هدف همراهمان هستنند Actors:افراد و گروه‌های مختلفی در موفقیت یا عدم موفقیت ما در رسیدن به هدف تاثیر گذار هستند. پس در ادامه به سراغ شناسایی این افراد و گروه‌ها می‌رویم. باید دریابیم که چه افرادی ما را در این فرایند کمک خواهند کرد. دقت کنید که لزوما این افراد نیرو‌های تیم و شرکت نیستند. ممکن است مشتریان فعلی سیستم نیز از نقش‌آفرینان ما در رسیدن به هدف باشند.6.3. چه تاثیری می‌گذارند Impact:حالا که فهمیدیم چه هدفی داریم و چه کسانی به ما در انجام این کار کمک می‌کنند، وقت آن رسیده است که پیدا کنیم که هر فرد یا گروه در این مسیر چه تاثیرهایی خواهد گذاشت. 6.4. چگونه تاثیر گذاشته می‌شود Deliverables:در نهایت تعیین می‌کنیم که هرکدام از نقش‌آفرینان چه کارهایی انجام می‌دهند تا در فرایند رسیدن به هدف تاثیری گذار باشند. حال که این لیست را داریم و ارتباط کاملی از هدف تا کاری که باید انجام شود وجود دارد به سادگی می‌توانیم ویژگی‌های محصول را اولویت بندی کنیم و به ترتیب اولویت روی آن‌های سرمایه گذاری کرده و به هدفمان برسیم. 7. جمع بندی:در این قسمت با یک تکنیک بسیار ساده و کاربردی در توسعه محصول آشنا شدیم. این تکنیک ابزاری بسیار کاربردی برای همه افرادی است که در فرایند توسعه محصول همکاری می‌کنند. سرمایه گذارها می‌دانند برای رسیدن به اهدافشان چه کارهایی انجام می شود و سرمایه آن‌ها کجا هزینه می‌شود. مدیر محصول می‌داند قرار است کشتی محصول را به کدام ساحل آرامش برساند. تحلیل‌گرهای سیستم برای شناخت کلی سیستم و تعیین اولویت‌های کاریشان از آن استفاده می‌کنند و ...در صورتی که تمایل دارید در این موضوع مطالب بیشتری مطالعه کنید اینجا می‌توانید منابع و مطالب متنوعی را بیابید. مثال این مطلب از کتاب PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN نوشته آقایان Scott Millet و Nick Tune گرفته شده است. پ.ن: یعنی برای این روزا دل تنگ می‌شیم؟ علیرضا ارومند علیرضا ارومند Wed, 30 Jun 2021 00:30:22 +0430