مقایسه راه حل و معماری دریایی
در چهار سال گذشته حرفه حرفه ای ام، به عنوان معمار دریایی کار کرده ام. اکثر مردم نمی دانند معماری دریایی چیست و برخلاف آنچه از نامش پیداست، من اصلاً طراحی یا طراحی انجام نمی دهم. با کمال تعجب، معماران راه حل و معماران دریایی بیشتر از شغلشان مشترک هستند عناوین. ما کار مشابهی داریم وظایف! ما فقط در صنایع مختلف کار می کنیم.
به عبارت ساده، من راه حل های فنی را طراحی می کنم کشتی های نیروی دریایی. این راه‌حل‌ها بر اساس داده‌هایی هستند که من برای محاسبه/مدل‌سازی رفتار مورد انتظار کشتی‌ها و ساختار آنها با استفاده از تحلیل تنش و تئوری‌های شناوری، الزامات فنی و مشخصات، و داده‌هایی که توسط «مشتری» به من ارائه می‌شود، استفاده می‌کنم. من طرح‌ها، پیشنهادات و سایر مستندات ارائه‌شده توسط مشتری را بررسی می‌کنم، یک مدل ایجاد می‌کنم، و سپس راه‌حلی برای یک مشکل ارائه می‌دهم یا تأیید می‌کنم.
توجه: ما پروژه‌ها را «اقلام کاری» یا «موجودات» می‌نامیم، بنابراین می‌توانید هنگام خواندن اینجا به جای هم از آن استفاده کنید.
تجزیه و تحلیل داده ها و طراحی راه حل های فنی
بسیاری از داده های استفاده شده در این مدل ها به قدمت خود نیروی دریایی است. مدت‌ها پیش، معماران دریایی آزمایش‌های مختلفی را بر روی رفتار کشتی‌های نیروی دریایی در اثر تنش‌های مختلف مانند باد، سیل تانک‌ها، زلزله و طوفان و انفجار انجام دادند و ثبت کردند. با استفاده از این داده‌ها در ارتباط با قرائت‌های فعلی و مقادیر گزارش‌شده، می‌توانم نتیجه مورد انتظار تنش، خوردگی، پایداری و غیره را مدل‌سازی کنم تا سپس خطر شکست سازه یا تلفات را ارزیابی و مدیریت کنم. در اینجا دو نمونه وجود دارد:
-
از این آزمایش‌ها، «آزمایش‌های متمایل» برای مدل‌سازی رفتار شناوری یا پایداری ناشی از بارهای روی کشتی وجود داشت. وزن‌های سنگین به طور خلاصه به مکان‌های مختلف منتقل شدند و شناوری مشاهده، ثبت شد و در نهایت به نمودارها و فرمول‌های مربوطه تبدیل شد. معماران نیروی دریایی در دفتر من کمتر از یک دهه پیش مجبور بودند فرآیند طاقت فرسا خواندن این نمودارهای بسیار زیاد و ایجاد جداول و نمودارهای اضافی را تحمل کنند تا سپس رفتار مورد انتظار شناوری به دلیل حذف و اضافه وزن ها را مدل کنند. دست در عوض اکنون، همه این نمودارها و داده‌ها در یک پایگاه داده تعاملی دوست‌داشتنی آپلود شده‌اند (حتی اگر مجبور شده‌ام محاسبات را به صورت دستی انجام دهم). اکنون به سادگی داده‌های جدید ستون‌ها و ردیف‌ها را وارد می‌کنم و مدل پایداری جدید ما با چند تصویر بصری کامل می‌شود. سپس می توانم راه حل درخواستی را تأیید کنم یا جایگزین مناسبی ارائه کنم.
-
فرض کنید سوراخی روی عرشه وجود دارد که نیاز به تعمیر دارد، اما بر اساس موارد کاری که از قبل برنامه ریزی شده است، زمانی برای تکمیل تعمیر وجود ندارد. با در نظر گرفتن داده هایی مانند اندازه و محل سوراخ و نوع و ضخامت مواد، می توانم میزان خوردگی و شکست را از طریق مدلی تخمین بزنم که عرشه به دلیل استرس از بین می رود. به عنوان مثال مکان های مختلف کشتی و مواد نشان داده شده است که درجات مختلفی از تنش یا زوال را نشان می دهند. سپس بر اساس این مدل، بهترین روش تعمیر و تاریخ تکمیل مورد نیاز آن را توصیه می کنم.
بسیاری از مؤلفه‌های دیگر وجود دارد که من آنها را مدیریت می‌کنم که همگی دستورالعمل‌ها و فرمول‌های فنی خود را دارند. خوشبختانه هیچ روز کسل کننده ای در اداره وجود ندارد!
برآورد پروژه و تحلیل ریسک
در حین یادگیری در مورد معماری راه حل، با یک تکنیک/مفهوم تخمین پروژه مواجه شدم که به نظر شبیه روشی است که در نقش فعلی خود استفاده می کنم: اندازه تی شرت. در موقعیت فعلی من، پروژه‌های آینده به نام موجودی‌ها را با وظایف از پیش تعیین‌شده در یک «مورد کاری» برنامه‌ریزی کرده‌ایم. وظایف کوچکتر یا بزرگتری وجود دارد که به ترتیب به در دسترس بودن برنامه ریزی شده کوتاهتر یا طولانی تر اختصاص داده می شوند تا در برنامه باقی بمانند یا نزدیک به زمان بندی باشند. دسترسی‌های کوتاهتر بسیار بیشتر است و در دسترس‌پذیری‌های طولانی‌تر را می‌توان با سال‌ها فاصله گرفت.
با این حال، هنگامی که خطر یک شکست یا تلفات را ایجاد و ارزیابی می‌کنم، اگر وظایف پیچیده‌تر یا بزرگتری به‌عنوان «بحرانی» برچسب‌گذاری شود، می‌توان آن را اولویت تلقی کرد و بدون توجه به در دسترس بودن کوتاهتر یا زودتر دوباره به آنها اختصاص داد و وظایف به‌عنوان «کم» ارزیابی شد. می توان دوباره به در دسترس بودن طولانی تر اختصاص داد.
همچنین پیش از شروع در دسترس بودن، به پیمانکاران برای کار پرداخت می شود و هر کار اضافی یا “کار رشد” اضافه شده هزینه های اضافی و بالاتری دارد. فقط کارهایی که حیاتی تلقی می شوند به عنوان کار رشد اضافه می شوند.
البته من در اندازه تی شرت متخصص نیستم اما به نظر شبیه این روش است.
ارتباط بین دامنه ای
به عنوان یک SME، من در ارتباط مستمر با افراد مختلف در موقعیت ها و زمینه های مختلف تخصصی هستم. هنگامی که یک مدل ایجاد کردیم، مشکل را ارزیابی کردیم، یک راه حل طراحی کردیم، آخرین مرحله این است که این راه حل را به بقیه تیم پروژه منتقل کنیم.
برای تکامل لنگرگاه (که شروع یا پایان در دسترس بودن است)، غواصان، استادان اسکله، ملوانان استخدام شده و سفارش داده شده، نگهبانان طناب، اپراتورهای جرثقیل و غیره وجود دارند که همگی در حال کار بر روی ورود یا خروج کشتی به حوض خشک هستند. ممکن است ساده به نظر برسد، اما روزها آماده سازی طول می کشد و رساندن کشتی به حوض خشک و تکمیل یک تکامل می تواند تقریباً 28 ساعت متوالی طول بکشد (خوشبختانه وقت اضافه وجود دارد که باعث می شود کمی کنترل شود). در طول این مدت، ما باید در ارتباط دائمی با همه پرسنل برای پیگیری، ثبت و گزارش هر مرحله از این فرآیند باشیم زیرا ما ناظر رسمی دولت و رهبری POC هستیم و همچنین انتظار می رود برای هر مشکلی راه حلی پیدا کنیم. ممکن است پیش بیاید که چه کسی باید تماس بگیرد یا چه کتابچه راهنمای فنی را بخوانید. در زیر به نظر می رسد که یک تکامل docking چگونه است.
https://www.youtube.com/watch?v=G3kdqwsLCBI
برای تعمیرات یا تغییرات ساختاری، ما اغلب بازرسی در محل انجام می‌دهیم و با پرسنل و مدیران پروژه‌های مختلف ملاقات می‌کنیم تا قبل از ارائه راه‌حل، تصویر کاملی از موضوع به دست آوریم. داشتن مهارت های ارتباطی قوی برای درک کار در دست و برقراری ارتباط موثر همه الزامات و راه حل ها قطعاً یک ضرورت است و نقطه قوت من است!
