https://virgool.io/azki-posts/feed مطالبی برای آشنایی بیشتر با ازکی fa 2026-04-15 02:55:24 https://files.virgool.io/upload/publication/tkhygntpfgw3/dpppes.png https://virgool.io/azki-posts https://virgool.io/azki-posts/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-goalert-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%A2%D9%86%DA%A9%D8%A7%D9%84-%D9%88-%D8%A7%D8%B9%D9%84%D8%A7%D9%86-%D9%87%D8%A7%DB%8C-%D8%A7%D8%B6%D8%B7%D8%B1%D8%A7%D8%B1%DB%8C-adyvqodbsl39 سیستم‌های مدیریت حوادث و آنکال یکی از ارکان اصلی زیرساخت‌های نرم‌افزاری مدرن هستند. GoAlert، به عنوان یک راه‌حل متن‌باز که توسط تیم مهندسی Target توسعه یافته، رویکردی جدید به این مسئله ارائه می‌دهد. در این تحلیل، به بررسی عمیق جنبه‌های فنی و معماری این سیستم می‌پردازیم.گوآلرت GoAlert چیست؟گوآلرت GoAlert یک پلتفرم جامع برای مدیریت برنامه‌های آنکال، ارسال هشدارها و مدیریت حوادث است. این سیستم به تیم‌های فنی کمک می‌کند تا به سرعت به مشکلات پاسخ دهند و از زمان خرابی سیستم‌ها (downtime) جلوگیری کنند. من در قسمت پایین goalert را در به سطوح مختلف تقسیم کرده و هر سطح را تشریح میدهم.سطح ۱ - مفهوم کلی:گوآلرت GoAlert یک سیستم مدیریت آنکال open-source هست که سه کار اصلی انجام میده:مدیریت شیفت‌های آنکال (on-call scheduling)صعود خودکار مشکلات (automated escalation)ارسال نوتیفیکیشن از طریق SMS و تماس صوتیسطح ۲ - نحوه استفاده‌ی اولیه:۱. ورود به سیستم: از هر دستگاهی که به اینترنت وصل باشه میتونید وارد شوید۲. تنظیم پروفایل:وارد کردن روش‌های تماس (contact methods)تنظیم قوانین نوتیفیکیشنامکان تست کردن روش‌های تماسمشاهده سرویس‌ها و پالیسی‌های مرتبط با شماسطح ۳ - کار با آلرت‌ها:۱. مشاهده آلرت‌ها:جستجو و پیدا کردن سرویس‌های مهمامکان favorite کردن سرویس‌ها برای دسترسی سریع‌تر2. پاسخ به آلرت‌ها:پاسخ از طریق SMS (برای شماره‌های آمریکایی)پاسخ از طریق تماس صوتیپاسخ از طریق رابط کاربری وبسطح ۴ - مدیریت پیشرفته آلرت‌ها:۱. صعود (Escalation) آلرت:انتقال آلرت به شخص یا تیم دیگر در صورت نیاز۲. مدیریت گروهی آلرت‌ها:امکان Acknowledge یا Close کردن همه آلرت‌های یک سرویسمفید برای زمان‌هایی که حجم زیادی آلرت داریدتوجه: Automated Escalation یعنی اگر یک مشکل یا آلرت در زمان مشخص شده توسط نفر اول حل نشد، به صورت خودکار ( با توجه به Escalation Policy) به نفر یا تیم بعدی منتقل میشه. این فرایند مطمئن میشه که هیچ مشکلی بدون رسیدگی باقی نمیمونه.مثال:مرحله ۱: ارسال به مهندس آنکال (۱۵ دقیقه صبر)↓مرحله ۲: ارسال به تیم لید (۳۰ دقیقه صبر)↓مرحله ۳: ارسال به مدیر پروژه (۱ ساعت صبر)↓مرحله ۴: ارسال به همه اعضای تیممدیریت تیم‌ها در GoAlert:مفهوم کاملا مرتبط با تیم‌ها, Rotationها هستن که به معنای دوره‌های چرخشی برای اعضای تیم هست. همچنین برای مشخص کردن زمان تحویل شیفت (Handoff Time) و تنظیم نوع چرخش (هفتگی، ماهانه و...) به کار می‌رود.مثال:- تیم الف: چرخش هفتگی، تحویل ساعت ۹ صبح- تیم ب: چرخش دو هفته‌ای، تحویل ساعت ۶ عصرسطح ۵- سناریوهای پیشرفته:مثال عملی: مدیریت آنکالی بین دو تیم در مناطق زمانی مختلف:۱. ایجاد دو Rotation برای هر تیم۲. تنظیم یک Schedule مشترک۳. تنظیم Assignment Rules برای هر تیم۴. ایجاد Escalation Policy۵. اتصال به سرویس مورد نظریکی از ویژگی های کلیدی goalert یکپارچه‌سازی با اکثر برنامه‌ها و سیستم های مانیتورینگ و آلرتینگ متداول مانند Prometheus AlertManager و همچنین گرافانا می‌باشد.نحوه نصب و راه‌اندازیپیش‌نیازهایکی از بهترین روش‌های نصب goalert استفاده از داکر است. فایل داکر کامپوز نمونه در زیر آمده است. در این داکر کامپوز سعی کردیم بهترین حالت setup این سرویس را پیاده سازی کرده باشیم. همچنین برای مقادیر مربوط به یوزر دیتابیس, پسورد دیتابیس و پابلیک url از یک فایل .env استفاده کرده‌ایم.گوآلرت GoAlert یک راه‌حل قدرتمند و منعطف برای مدیریت آنکالی و هشدارها است که می‌تواند نیازهای تیم‌های کوچک تا سازمان‌های بزرگ را برآورده کند. با توجه به متن‌باز بودن و پشتیبانی قوی جامعه کاربری، انتخاب مناسبی برای سازمان‌هایی است که به دنبال یک سیستم مدیریت هشدار قابل اعتماد هستند.یک سناریو و تجربه‌ی واقعی در شرکت ازکی:در شرکت ازکی ما برای برخی آلرت‌های متوسط به بالا از سیستم تماس تلفنی برای اعلام مشکل استفاده می‌کنیم. به این صورت بود که گروه بندی صورت گرفته و در برخی از مشکلات به تیم توسعه تماس گرفته می‌شد و در برخی دیگر تیم دوآپس.این پیاده سازی ساده چندین مشکل به همراه داشت. 1- برای هر مشکلی که به وجود می‌آمد به تمام نفرات دوآپس حتی شخصی که آنکال نباشد تماس تلفنی برقرار می‌شد که از بهینگی تماس و دقت آن کاسته می‌شد.2- گاهی اوقات مشکل رخ داده به گونه‌ای هست که برای حل آن حتما باید یک نیروی سمت توسعه هم اضافه می‌شد که نیاز به تماس دستی از سمت نیروی دوآپس به آن‌ها بود و این خود زمانگیر بود.(شماره شخص آنکال توسعه رو پیدا کرده و تماس برقرار کنیم.)ابزار goalert حل کننده‌‌ی شمار زیادی از این دست مشکلات بود. ما از قابلیت Escalation تو این حالات استفاده کردیم. اولا تو هر مرحله از تماس فقط به شخص آنکال (چه توسعه‌, چه دوآپس) تماس برقرار می‌شد. در برخی آلرت‌ها که مربوط به دوآپس بود مشخص کرده‌ایم که این نوع آلرت نیاز به تماس با نفر آنکالِ توسعه وجود دارد. و در مواردی که مشکل برای نفر اول حل نشود و یا نفر اول در دسترس نباشد‌‌‌, اتوماتیک نفر دوم تماس برقرار می‌شود. انتشارات ازکی علیرضا حمیدی Tue, 10 Dec 2024 01:00:58 +0330 https://virgool.io/azki-posts/%D8%A7%D8%B3%DA%A9%D9%86-%D8%A7%D9%85%D9%86%DB%8C%D8%AA%DB%8C-%D8%A7%DB%8C%D9%85%DB%8C%D8%AC-%D9%87%D8%A7%DB%8C-%D8%AF%D8%A7%DA%A9%D8%B1%DB%8C-y5hj81nwftqj توی این مقاله میخوام در مورد روند ساخت یک پروژه برای خودکارسازی اسکن امنیتی ایمیج‌های داکر صحبت بکنم و پروژه ای رو با شما به اشتراک بزارم تا شما هم بتونید از مزایاش توی سازمانتون استفاده بکنید.دقیقا یادم نمیاد چه تاریخی بود که همکار خوبم علیرضا حمیدی داشت ابزارهای grype و trivy و ... رو با هم مقایسه میکرد و تفاوت هاش رو به ما ارائه میداد. بعد از اون جلسه تصمیم نهایی رو گرفتیم که با ابزار grype پیش بریم.اما چرا این همه زحمت؟ زمانی که برای یک سازمان بزرگ مثل ازکی کار میکنید باید بتونید محافظت از امنیت اطلاعات کاربران و سازمانتون رو توی لایه های مختلف پیاده سازی بکنید، یکی از اون لایه های ایمیج های داکر هست که عموما به خاطر نبودن ابزار آماده یا پولی بودن این ابزارها، نادیده گرفته میشه یا به صورت مرتب انجام نمیشه، ما توی ازکی دنبال راه حل مناسب بودیم و این شد که به سمت ساختن یک پروژه برای استاندار سازی خروجی اسکن های امنیتی ایمیج‌هامون رو آوردیم.من دست به کار شدم و شروع کردم به پیدا کردن یک راه حل مناسب برای این مشکل، اما چه نیازمندی هایی داشتیم؟ اول از همه این راهکار باید بتونه به صورت دوره ای اجرا بشه و نیاز به عملیات دستی نداشته باشه تا هزینه جدیدی برای اجرا به تیم اضافه نشه، نیازمندی دیگه ما این بود که بتونیم دیتایی هیستوریکال داشته باشیم تا در صورت نیاز بتونیم به بهبود تا بدتر شدن شرایط اشاره بکنیم. در همین راستا علیرضا پیشنهاد داد که از خروجی html ابزار grype استفاده بکنیم. خروجی رو به همه تیم ارائه داد و فوق العاده بود! یه صفحه html به صورت تک فایل و بسیار سبک، همینطور این فایل قابلیت کاستومایز شدن داشت.با این اطلاعاتی که به مرور زمان جمع کردیم شروع کردم به پیدا کردن یک راه حل مناسب، برای شروع یک ابزار CLI پایتون توسعه دادم که بتونه یک فایل، شامل لیستی از ایمیج‌های داکری، که نیاز به اسکن داره رو بخونه و با استفاده از دسترسی shell ابزار grype رو صدا بزنه و خروجی های html مورد نیاز رو آماده بکنه.خروجی ابزار ترمینالی پایتونخب حالا نیاز داریم که بتونیم فایل هایی که با پوشه بندی بر اساس تاریخ به صورت خروجی داریم رو توی مرورگر نشون بدیم. برای این کار هم از وب‌سرور nginx استفاده کردم و خروجی هایی که ساختم رو با استفاده از دستور autoindex به کاربران نمایش دادم. آیا این کافی بود؟ نه، اینکه خروجی پوشه ها رو ببینیم برای من کافی نبود و با استفاده از دستورات add_before_body و add_after_body توی nginx یک قالب هم به خروجی نمایش داده اضافه کردم و از حقه های regex مختلف استفاده کردم برای اینکه این قالب فایل های از پیش ساخته grype رو تحت تاثیر قرار نده و خرابشون نکنه. آیا کافی بود؟ بله :) .به تبدیل این پروژه به یک helm فکر کردم و تا مراحل خوبی هم پیش بردمش (توی هیستوری گیت میتونید ببینید)، ولی در نهایت پشیمون شدم و خروجی رو به شکل داکر کامپوز آماده کردم، دلیلم برای این کار چی بود؟ چون میخواستم همه بتونند از این سرویس استفاده بکنند و فقط برای کسایی که سرویس کوبرنتیز دارند جذاب نباشه (باور من این هست که توی اولویت بندی امروزم، کسی که کوبرنتیز داره خودش میتونه پروژه من رو تبدیل بکنه به manifest از روی داکر کامپوزی که ساختم).قبل از اجرای پروژه داخل دو فایل در صورت نیاز تغییر ایجاد بکنید. فایل اول یک فایل .env هست برای استفاده از ریپازتوری داکر کاستوم و فایل دوم images.txt هست برای معرفی کردم آدرس ایمیج هایی که میخواید اسکن بشه. توی عکس زیر هم میتونید ساختار پروژه خام رو مشاهده بکنید.ساختار فایل های پروژهبعد از پایان تنظیم کردم دو تا فایل مورد نظر حالا میتونید پروژه رو ران بکنید. برای اینکار یک دستور برای اجرا شدن وب‌سرور نیاز دارید و یک دستور دیگه که میتونید به صورت دوره‌ای اجرا بکنید یا با ابزاری مثل cron برای زمان های خاصی زمان بندی بکنید.دستورات مورد نیاز و یک نمونه از cron برای اجرا در ابتدای هر هفته رو براتون همین پایین گزاشتم:# Run webserver docker compose up -d web # Run the scan result generator docker compose up --build generator # Run the scan generator as a job in crontab 0 0 * * FRI root { cd /opt/image-sec-scan && docker compose up --build generator; } > /opt/image-sec-scan/run.log 2>&1بعد از اجرا به پرت ۸۸۸۸ (دیفالت) یا پرتی که داخل فایل .env کاستوم کردید سر بزنید و خروجی اسکن رو مشاهده کنید. تصویر نمونه خروجی اسکن با دیفالت پروژه:مسیر ایندکس اسکن هاخروجی نهایی اسکن یک داکر ایمیجتوی خروجی نهایی، میتونید سرچ کنید، فیلتر کنید و یا حتی خروجی pdf بگیرید!امیدوارم این راهکار برای شما مفید باشه و اگر نیاز بیشتر یا پیچیده‌تر دارید خوشحال میشم که مشارکت‌های شما رو توی پروژه داشته باشم.آدرس پروژه توی گیت هاب: github.com/erfantkerfan/image-sec-scanمن عرفان قلی زاده یک مهندس DevOps هستم و سعی میکنم از تجربیاتم که میتونه براتون مفید باشه به صورت منظم و نامنظم بلاگ بنویسم. انتشارات ازکی عرفان قلی زاده Thu, 05 Dec 2024 10:41:26 +0330 https://virgool.io/azki-posts/%D8%AC%D9%85%D8%B9-%D8%A2%D9%88%D8%B1%DB%8C-%D9%84%D8%A7%DA%AF-%D8%A8%D8%A7-%D9%81%D9%84%D9%88%DB%8C%D9%86%D8%AA-%D8%A8%DB%8C%D8%AA-fluent-bit-khpckon72tis در دنیای امروز، جمع‌آوری و تحلیل داده‌ها به یک نیاز اساسی برای کسب‌وکارها تبدیل شده است. داده‌های تلمتری، که شامل اطلاعاتی از عملکرد و وضعیت سیستم‌ها هستند، نقش مهمی در نظارت و بهینه‌سازی فرآیندها ایفا می‌کنند. اما چگونه می‌توان این داده‌ها را به صورت کارآمد و بهینه جمع‌آوری و پردازش کرد؟ اینجاست که ابزارهایی مانند فلوینت بیت وارد میدان می‌شوند.معرفی فلوینت بیت (Fluent Bit)فلوینت بیت یک ابزار منبع‌باز و کارآمد برای جمع‌آوری، پردازش و ارسال داده‌های تلمتری و لاگ‌ها از منابع مختلف به مقصدهای متنوع است. این ابزار کوچک و سریع برای مصرف بهینه منابع طراحی شده و می‌تواند روی دستگاه‌های مختلف، از IoT تا سرورهای بزرگ، اجرا شود. فلوینت بیت قابلیت یکپارچه‌سازی با سیستم‌های مانیتورینگ و تحلیل مانند Elasticsearch، Prometheus و OpenTelemetry را دارد و توسط ارائه‌دهندگان بزرگِ‌ابری و شرکت‌های مختلف مورد استفاده قرار می‌گیرد. این نرم افزار به طور خاص برای محیط‌های کانتینری، ابری و میکروسرویس‌ها مناسب است. رسالت فلوینت بیت در یک جمله خلاصه میشود: جمع آوری لاگ از همه جا، پردازش آن‌ و فرستادن آن به هر سرویس مد نظر.ویژگی‌های کلیدیسبک و کم‌مصرفحافظه مصرفی کمتر از 650KBنوشته شده به زبان Cبدون وابستگی خارجیمناسب برای محیط‌های IoT و embeddedقابلیت اطمینان بالاپشتیبانی از مکانیزم‌های بافرینگقابلیت ریکاوری در صورت قطعی سیستمپشتیبانی از TLS/SSL برای ارتباطات امنانعطاف‌پذیریپشتیبانی از بیش از 70 پلاگین ورودی و خروجیقابلیت فیلترینگ و غنی‌سازی داده‌هاامکان تعریف روتینگ پیچیدهنیازمندی به فلوینت بیتدر سازمان‌ها، شرکت‌ها و استارتاپ‌ها، نظارت بر عملکرد سیستم‌ها و تحلیل داده‌ها برای بهبود کارایی و کشف مشکلات پیش از وقوع، ضروری است. فلوینت بیت به شما کمک می‌کند تا داده‌های تلمتری و لاگ های تمامی سرویس‌ها را به صورت متمرکز و کارآمد جمع‌آوری کنید، بدون اینکه بار اضافی بر روی سیستم‌های شما ایجاد شود. این ابزار به ویژه برای محیط‌های پیچیده و بزرگ، که در آن‌ها حجم عظیمی از داده‌ها باید به صورت مداوم مانیتور شوند، بسیار مفید است.معماری فلوینت بیتFluent Bit از یک معماری Pipeline-based استفاده می‌کند که شامل چندین مؤلفه اصلی است :1- input: (داده‌ها را از منابع مختلف مانند فایل‌ها، سرورها و سرویس‌ها جمع‌آوری می‌کند.)پشتیبانی از منابع متنوع مانند:فایل‌های لاگمتریک‌های سیستمیTCP/UDPMQTTKubernetes logs2-Parser. تبدیل داده‌های خام به فرمت ساختاریافته. پشتیبانی از فرمت‌های مختلف:JSONRegular ExpressionLTSVLogfmt3-Filter (داده‌های ورودی را پردازش و تغییر می‌دهد، مانند افزودن یا حذف فیلدها)امکانات فیلترینگ:GrepRecord ModifierKubernetesLua Scripts4-Outputارسال داده‌ها به مقصدپشتیبانی از مقاصد متنوع:ElasticsearchPrometheusInfluxDBHTTP endpoints(Cloud services (AWS, GCP, Azure5- TAGبه هر رویدادی که وارد فلوئنت بیت می شود، یک تگ اختصاص داده می شود. این تگ یک رشته داخلی است که در مراحل بعدی توسط روتر برای تصمیم گیری در مورد فاز فیلتر یا خروجی استفاده می شود.6-Bufferبافرینگ در Fluent Bit مکانیزمی است که داده‌ها را قبل از ارسال به مقصد ذخیره می‌کند. این قابلیت برای اطمینان از عدم از دست رفتن داده‌ها در شرایط مختلف (مانند قطعی شبکه یا فشار بالا) حیاتی است.انواع بافرینگ در فلوینت بیت:Memory Buffer (بافر حافظه):Storage Buffer (بافر ذخیره‌سازی)7-Routingروتینگ در Fluent Bit مکانیزمی است که تعیین می‌کند هر داده به کجا باید ارسال شود. این قابلیت امکان ایجاد مسیرهای پیچیده برای داده‌ها را فراهم می‌کند.روش‌های روتینگ:Tag-based Routing (روتینگ بر اساس تگ):Multi-Destination Routing (روتینگ چند مقصدی):نصب fluent-bit:نصب فلوینت بیت با توجه به کاربرد آن میتواند متفاوت باشد. در زیر روش های مختلف نصب فلوینت بیت به اختصار آمده است.1-نصب آن روی لینوکسنصب از طریق Package Manager:روی ابونتو و دبین# اضافه کردن کلید GPGCurl https://packages.fluentbit.io/fluentbit.key | gpg --dearmor > /usr/share/keyrings/fluentbit-keyring.gpg# اضافه کردن مخزنecho &quotdeb [signed-by=/usr/share/keyrings/fluentbit-keyring.gpg] https://packages.fluentbit.io/debian/$(lsb_release -cs) $(lsb_release -cs) main&quot >> /etc/apt/sources.list.d/fluent-bit.list# به‌روزرسانی و نصبsudo apt-get updatesudo apt-get install fluent-bit2- نصب در Dockerبا استفاده از ایمیج رسمی# دریافت آخرین نسخهdocker pull fluent/fluent-bit:latest# اجرا با تنظیمات پیش‌فرضdocker run -d --name fluent-bit fluent/fluent-bit:latest# اجرا با فایل کانفیگ سفارشیdocker run -d --name fluent-bit \-v /path/to/fluent-bit.conf:/fluent-bit/etc/fluent-bit.conf \fluent/fluent-bit:latest3-با استفاده از داکر کامپوز:version: '3' Services: Fluent-bit: image: fluent/fluent-bit:latest Volumes: - ./config:/fluent-bit/etc/ - ./logs:/var/log ports: - &quot24224:24224&quot environment: - FLB_LOG_LEVEL=info 4-با استفاده از کوبرنتیز:با استفاد از Helm# اضافه کردن Helm repositoryhelm repo add fluent https://fluent.github.io/helm-charts# به‌روزرسانی repositoryhelm repo update# نصب با تنظیمات پیش‌فرضhelm install fluent-bit fluent/fluent-bit# نصب با values سفارشیhelm install fluent-bit fluent/fluent-bit -f values.yamlنمونه values.yaml برای helm:config: inputs: | [INPUT] Name tail Path /var/log/containers/*.log filters: | [FILTER] Name kubernetes Match kube.* outputs: | [OUTPUT] Name es Match kube.* Host elasticsearch-host Port 9200نیازمندی در ازکی:محصولات ازکی به صورت میکروسرویس‌هایی طراحی شده‌اند که بر روی کوبرنتیز مدیریت می‌شوند. این میکرو سرویس ها با توجه به تعداد بالا و پیچیدگی های محصولی که دارند، دارای لاگ های با اهمیتی هم هستند که توی موارد حساس و پیچیده با حضورشون میتونن خیلی کمک کننده باشند، پس توی یک همکاری تیمی این لاگ ها از فایل به خروجی های کانتینری تبدیل شدند و توسط فلوئنت بیت با حداقل مصرف ریسورس به یک کلاستر الاستیک سرچ منتقل میشوند این دیتا در نهایت میتونه توسط تمام تیم های تکنولوژی به بهره برداری برسه. انتشارات ازکی علیرضا حمیدی Mon, 18 Nov 2024 10:30:45 +0330 https://virgool.io/azki-posts/%D9%86%D8%A7%D9%85%DA%AF%D8%B0%D8%A7%D8%B1%DB%8C-%D9%85%D8%A8%D8%AA%D9%86%DB%8C-%D8%A8%D8%B1-%D8%AF%D8%A7%D9%85%D9%86%D9%87-%DA%A9%D8%A7%D9%86%D8%B3%D8%AA%D9%86%D8%AA-%D9%87%D8%A7-tvo1niyovdqp به طور کلی constantها نقش مهمی در یک پروژه بزرگ دارن و از اونجایی که پروژه شروع به رشد می کنه و توسعه دهنده‌های زیادی روش کار می‌کنن، اگر ساختار یکپارچه‌ای براشون نداشته باشیم دیر یا زود برامون مشکل‌ساز می‌شن.در تیم فرانت ازکی، ما یه جایی احساس کردیم که عدم توجه به موضوع constantها در پروژمون می‌تونه ما رو دچار مشکل کنه. برای اینکه بتونیم جلوی این مشکل رو بگیریم راه‌حل‌های مختلف رو بررسی کردیم و در نهایت به ساختار و قوانینی رسیدیم که باعث شد دیگه هیچ نگرانی نسبت به کانستنت‌ها و نحوه تعریفشون نداشته باشیم و در این پست میخوایم مسیری که طی کردیم رو با شما به اشتراک بزاریم.مشکلاتی که بدون ساختار بودن کانستنت‌ها می‌تونست برامون به وجود بیاره، موارد زیر بودن:سخت شدن توسعه (اضافه کردن و یا ادیت کردن کانستنت‌ها)مشخص نبودن دامین و منطق کانستنتمشخص نبودن ساختار دیتای کانستنتبوجود آمدن duplicationمزیت‌های داشتن ساختار عبارتند از:ساده کردن توسعه کانستنت‌ها : پروژه به دامین‌های منطقی تقسیم میشه و هر کانستنت جدید متعلق به یک دامین خواهد بودجلوگیری از duplication : یونیک شدن نام کانستنت‌هامشخص بودن دامنه کانستنت‌ها : منطق و مقدار قابل پیشبینی هر کانستنت از نامش مشخص میشهمشخص بودن نوع مقدار ذخیره شده : تعریف کردن کانستنت‌ها به دو شکل مختلف به منظور مشخص کردن نوع دیتای ذخیره شدهپیاده‌سازیما می خواستیم در دو مرحله این کار رو ممکن کنیم و برای کانستنت‌هامون یک ساختار شسته رفته داشته باشیم:در مرحله اول، پروژمون رو به یکسری دامین تقسیم می‌کنیم، بهتره دامین‌ها بر اساس بیزینس لاجیک باشن (میشه کمی به DDD ربطش داد) چون غالبا کانستنت‌ها از دل بیزینس لاجیک‌ها میان بیرون.از اونجایی که کانستنت‌ها در فایل‌های مختلفی از پروژه استفاده می‌شن، پس بهتره یک سری قوانین برای نام‌گذاریشون داشته باشیم و اسمشون در اصل شناسنامه شون بشه.بریم ببینیم داستان چی بود!مرحله اولساختاری که داریم ازش حرف می‌زنیم به این شکل هست:constants└── ├── domain-1-1│ ├── domain-2-1│ └── domain-2-1├── domain-1-2│ ├── domain-2-1│ └── domain-2-1| ├── domain-3-1│ └── domain-3-2└── domain-1-3└── domain-2-1└── domain-3-1همونطور که می‌بینید ما پروژمون رو به دامین‌های مختلف تقسیم کردیم، یکسری از دامین‌ها ممکنه خیلی بزرگ باشن، پس می‌تونیم اون‌ها رو هم به دامین‌های دیگه تقسیم کنیم.بر اساس تجربه ما در ازکی پیشنهاد میشه که بیشتر از ۳ سطح دامنه‌هارو خورد نکنیم، جلوتر میگم چرا!بزارین برای این ساختار یه مثال دنیای واقعی‌‌تر بزنیم: فرض کنید که ما یه فروشگاه دیجیتال داریم و می‌خوایم به دامین‌های مختلف تقسیمش کنیم و روش کار کنیم.constants└── ├── order│ ├── status│ └── tag├── customer│ ├── info│ └── purchase| ├── done│ └── undone└── product└── category├── phone├── tablet└── laptopبخشی از ساختار مورد انتظارمون برای این محصول میتونه این شکلی باشه (بهش صرفا به عنوان یه مثال نگاه کنید)مرحله اول رو تموم کردیم و تونستیم پروژمون رو به دامین‌های بیزنس لاجیکی تقسیم کنیم.مرحله دومفرض کنید در مثال بالا میخوایم به دسته‌بندی موبایل در زیرمجموعه محصول یک کانستنت‌ اضافه کنیم، پس فایل مقصدمون برای اضافه کردن این کانستنت product -> category -> phone هست.فقط کافیه از ۲ قانون پیروی کنیم تا به اون چیزی که می‌خوایم برسیم.قانون اولنامگذاری : نام کانستنت باید مسیری که فایلمون درش قرار داده شده رو به عنوان پیشوند داشته باشه، مثلا اگر ما می‌خوایم یک کانستنت تحت عنوان brands به این فایل اضافه کنیم، پیشوندهامون به این ۲ شکل میشه (اشکال مختلف رو در قانون دوم میگیم) :productCategoryPhone یا PRODUCT_CATEGORY_PHONEقانون دومتایپ: برای اینکه بتونیم از اسم کانستنت‌هامون نوع مقداری که درشون هست رو بهتر متوجه بشیم اونا رو به دو دسته تقسیم می‌کنیم، یک دسته primitiveها هستن که برای تعریفشون از SCREAMING_SNAKE_CASE استفاده می‌کنیم و برای non-primitive ها که همون آرایه و آبجکت‌هامون میشن از camelCase استفاده می‌کنیم.پس برای مثال بالا که می‌خو‌استیم کانستنت brands رو داشته باشیم، مطمئنا باید از camelCase استفاده کنیم و از دو پیشوندی که بالا به دست آوردیم productCategoryPhone رو انتخاب می‌کنیم و در نهایت productCategoryPhoneBrands رو می‌سازیم، کانستنتی که همین الان ساختیم مطمئنا لیستی از برندها خواهد بود، مثل سامسونگ، پس برای تعریف کردن برند سامسونگ هم به راحتی می‌تونیم به PRODUCT_CATEGORY_PHONE_BRAND_SAMSUNG برسیم.همونطور که می‌بینید، ما خیلی راحت می‌تونیم از اسم کانستنتی که تعریف کردیم به دامین و همینطور نوع و ماهیت دیتایی که درش ذخیره شده برسیم.مطمئنا متوجه شدین که اسم‌ هامون با پیمایش داخل دامین‌ها بلندتر می‌شن، برای همین توصیه می‌کنم که بیشتر از ۳ سطح دامین نداشته باشیم.پلاگینبا تموم شدن مرحله دوم، حالا ما یک ساختار خیلی خوب و قابل توسعه برای کانستنت‌های پروژمون داریم، ولی از اونجایی که در پروژه‌های بزرگ افراد زیادی در بخش‌های مختلف کد می‌زنن و تضمینی نیست که این قوانین به درستی رعایت می‌شن یا خیر، یه پلاگین eslint نوشته شده که ما ازش استفاده کردیم و بهمون در اجرای این قوانین کمک کرد.نحوه‌ پیاده سازی و استفاده ازش رو هم می‌تونین در صفحه گیت‌هابی که ضمیمه شده داشته باشین.در نهایتما در ازکی این ساختار و قوانین رو در پروژمون پیاده کردیم و تونستیم یک ساختار تمیز از کانستنت‌هامون داشته باشیم و از مزیت‌هاش استفاده کنیم که علاوه بر فهم و توسعه راحت، مسیر آنبوردینگ افراد جدید در پروژه را نیز هموارتر کرد. https://www.npmjs.com/package/eslint-plugin-path-dependant-constant-naming https://github.com/mobinHor/eslint-plugin-path-dependant-constant-naming انتشارات ازکی مبین حر Sun, 28 Jul 2024 09:00:13 +0330 https://virgool.io/azki-posts/%D8%B1%D9%88%DB%8C%DA%A9%D8%B1%D8%AF%DB%8C-%D9%85%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D8%A8%D9%87-%D8%B3%D9%88%D9%BE%D8%B1%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-%D9%82%D8%AF%D9%85-%D8%A8%D9%87-%D9%82%D8%AF%D9%85-%D8%A8%D8%A7-%D8%B1%DB%8C%D8%AF%DB%8C%D8%B2%D8%A7%DB%8C%D9%86-%D8%B5%D9%81%D8%AD%D9%87-%D8%A7%D8%B5%D9%84%DB%8C-%D8%A7%D8%B2%DA%A9%DB%8C-y76c2tblch4l ازکی، همواره در تلاش بوده است با ارائه سرویس‌های جدید دامنه فعالیت خود را افزایش دهد و خدمات بیشتر و مفیدتری در اختیار کاربران بگذارد. در راستای این سیاست و با شکل‌گیری ازکی‌وام و ازکی‌سرمایه، نیاز به ایجاد ساختاری جدید و گویا برای شرح خدمات ازکی احساس شد که بازطراحی صفحه اصلی ازکی به عنوان مهم‌ترین جلوه این هدف، بخشی از برنامه‌ی‌ بلند مدت ازکی بود. بازطراحی صفحه اصلی، علاوه بر معرفی موثر و مفید خدمات، برای توسعه در آینده انعطاف‌ و ظرفیت بالایی دارد و امکان ایجاد گستره متنوعی از خدمات را فراهم می‌کند. در این گزارش شرح مرحله به مرحله فرآیند بازطراحی صفحه اصلی ازکی را مشاهده خواهید کرد.در ادامه خواهید خواند: ‍۱- شرح مسئله و چرایی‌ها ۲- اهداف ۳- چالش‌ها ۴- فرآیند و روند بازطراحی ۵- مطالعات و پژوهش‌ها ۶- نتایج۱- شرح مسئله و چرایی‌هامهمترین مسئله در پروژه بازطراحی، ایجاد ساختاری مناسب برای نمایش تمام سرویس‌های ازکی بود. از طرفی این بازطراحی با رویکرد تولید یک سوپر اپلیکیشن‌ انجام شد و از طرف دیگر می‌توان آن را نقطه شروعی پررنگ و قدرتمند برای بهبود جریان کاربری (User flow) در سرویس‌های دیگر ازکی یعنی ازکی‌وام و ازکی‌سرمایه در نظر گرفت. علاوه بر این موارد ویژگی توسعه‌پذیری طراحی نیز از اهمیت بسیار بالایی برخودار بود تا امکان اضافه کردن سرویس‌های جدید در آینده با کمترین هزینه و به راحتی وجود داشته باشد.بنابراین صورت مسئله به این ترتیب شکل گرفت:ایجاد ساختاری منعطف و توسعه‌پذیر برای ارائه‌ و افزودن سرویس‌های متنوع، با در نظر گرفتن نیازهای کاربری، محتوایی و مارکتینگی برای صفحه نخست ازکی به عنوان پلتفرمی در حال رشد و پرمخاطب۲- اهدافدر راستای این بازطراحی ۴ هدف اصلی دنبال شد. هر یک از این اهداف متصل به سیاست‌های کلان محصول در بلند مدت است. نکته اساسی و مهم طی این مسیر در نظر داشتن تمام جوانب و شرایط موجود بود زیرا این صفحه به عنوان اولین نقطه تماس کاربران اهمیت بسیار بالایی داشت و بر روی اهداف و عملکرد تمام تیم‌های سازمان تاثیرگذار بود. اهداف شامل موارد زیر بودند:۳- چالش‌هامهم‌ترین چالش در بازطراحی این صفحه، حفظ توامان تجربه‌ی قبلی کاربران از ازکی به عنوان ابزار مقایسه، انتخاب و خرید آنلاین بیمه و ایجاد ظرفیت برای توسعه و اضافه شدن سرویس‌های دیگر به این صفحه بود. حضور سرویس‌ها با ویژگی‌های متعدد و متفاوت و در نظر گرفتن کامپوننت‌ها و اجزای تعامل‌پذیر در هر کدام، طراحی فضایی یکپارچه و منسجم را سخت‌تر می‌کرد. از طرف دیگر پیاده‌سازی این فضا در محیط محدود وب و PWA در موبایل این مسیر را پیچیده‌تر کرده بود.به طور کلی چالش‌ها را می‌توان در موارد زیر خلاصه کرد:۱- حفظ تجربه قبلی کاربران از ازکی به عنوان سرویس مقایسه، انتخاب و خرید آنلاین بیمه۲- ایجاد راهکاری جامع و گسترش‌پذیر۳- یکپارچه‌سازی و ایجاد انسجام در نمایش تمام سرویس‌ها۴- مدیریت زمان، منابع و ذی‌نفعان با توجه به محدودیت‌ها۴- فرآیند و روند بازطراحیویژگی‌ای که این پروژه را از سایر موارد متمایز می‌کرد، وجود سرویس‌های دیگر یعنی ازکی‌وام و ازکی‌سرمایه در این بازطراحی بود؛ این ویژگی‌ موجب شد فرآیند معمول تیم طراحی تجربه برای پاسخ به پچیدگی‌ها این پروژه دستخوش تغییراتی شود. برای مثال این پروژه ذی‌نفعان بیشتری نسبت به پروژه‌های دیگر داشت؛ پیگیری و جمع‌آوری نظرات تمام ذی‌نفعان مسیری زمان‌بر و پرهزینه بود که فرآیندی بهینه را می‌طلبید.فرآیندی که در این پروژه طی شد به شرح زیر است؛ لازم به ذکر است که جزئیات بیشتر و نکات مهم هر مرحله، در ادامه به طور مفصل شرح داده شده‌است.۱-۴- طرح مسالهبه طور کلی صورت مساله این پروژه در سیاست‌های کلان ازکی برای توسعه و افزایش دامنه خدمات آنلاین به کاربران ریشه داشت و بر اساس نقشه‌ راه و نکات تعیین شده از سمت کسب‌وکار و ملزوماتش شکل گرفته بود. بنابراین در طرح مسئله این پروژه دغدغه‌های کسب‌وکار و چگونگی پیاده‌سازی موارد پیش‌بینی شده در بهترین حالت ممکن با هدف بهبود، حفظ و ارتقا تجربه کاربران در اولویت بودند. نتیجه این بخش در ابتدای این مستند شرح داده شد.۲-۴- ایده پردازیدر این مرحله با توجه به شرایط متفاوت ازکی و سرویس‌های مختلفش از نظر زمینه فعالیت، ویژگی‌های مخاطبین و... لازم بود راه حلی نوآورانه و خلاقانه ایجاد کنیم تا علاوه بر پاسخ دادن به نیازهای مطرح شده از سمت کسب‌وکار، تجربه کاربر حفظ شده و امکان توسعه‌پذیری نیز فراهم شود.مهمترین چالش در این مرحله مدیریت ذی‌نفعان بود. ذی‌نفعان این پروژه نسبت به سایر پروژه بسیار بیشتر بودند. راه‌حلی که برای مدیریت این موضوع به کار گرفتیم استفاده از فرآیند Early Feedback بود. با این روش توانستیم با پیاده‌سازی و طراحی low-fi و جمع‌آوری نظرات با سرعت بالا و هزینه کم، نتیجه‌ قابل قبولی دریافت کنیم.برای طرح ایده‌ها در طی فرآیند‌‌ بالا، بنچمارک‌ و پژوهش‌های متعددی انجام شد که در ادامه توضیح داده شده‌اند. 
ساختار کلی به دست آمده به شرح زیر است:۳-۴- طراحیبا انجام فرآیند‌ها در مرحله قبل به ساختار کلی جدید دست پیدا کردیم. این ساختار با جمع‌آوری تمام نظرات، انتظارات و بررسی عملکرد‌ تیم‌های مختلف شکل گرفت. این تیم‌ها شامل سرویس‌ها (ازکی‌وام و ازکی‌سرمایه)، مدیران و سرپرستان محصول، مارکتینگ، SEO و... بودند. نتایج این قسمت به طور مفصل در ادامه آورده شده است.۴-۴- تستبا توجه به محدودیت‌‌ در منابع و زمان پروژه، تست‌ها بر اساس اهداف مذکور پروژه تدوین شده اند. این تست‌ها در سه دسته تقسیم‌بندی می‌شوند که در قسمت‌های بعد به توضیح آن‌ها می‌پردازیم.۵- مطالعات و پژوهش‌هابرای دست‌یابی به نتیجه‌‌ای مطمئن و اثربخش و همین‌طور کاهش ریسک، زمان قابل توجهی برای این مرحله صرف شد. البته در تمام مراحل و تصمیمات همواره سعی داشتیم با در نظر گرفتن اهداف این بازطراحی از اتلاف زمان و هزینه جلوگیری کنیم.۱-۵- بنچمارک‌‌هابنچمارک‌ در ایجاد و سنجنش ایده‌ها در مراحل ابتدایی بسیار حائز اهمیت است. این پروژه نیز از این قاعده مستثنی نبود. در بنچمارک‌ها سعی شد به چرایی و رویکرد‌ها پرداخته شود. برای مثال چرا شرکت A چنین راه حلی را برای سرویسش انتخاب کرده است یا چرا شرکت B با وجود شباهت بسیار در خدمات از همان راه حل استفاده نکرده است. این رویکرد باعث می‌شود مرحله بنچمارک‌ اثر بخش‌تر باشد و سرنخ‌های بهتری در اختیار ما بگذارد.در این پروژه سعی شد انتخاب نمونه‌ها با تمرکز بر رویکرد و پیاده‌سازی راه‌حل‌ ارائه‌ شده توسط آن‌ها تنوع داشته باشند، چرا که هدف این بازطراحی با مفاهیم مطرح شده در حوزه سوپراپلیکیشن‌ها متفاوت بود. در واقع مقاصد و اهداف ازکی مشابه با این دست اپلیکیشن‌ها بود اما دغدغه‌هایی همچون حفظ تجربه قبلی کاربران موجب ‌شد که راه‌حل انتخابی کمی متفاوت و منعطف باشد.در بررسی هر گزینه بر روی موارد زیر تمرکز کردیم:۱- نحوه چیدمان و اولویت‌دهی: موضوع اساسی در سوپراپلیکیشن‌ها یعنی چگونگی چینش سرویس‌های اصلی و فرعی با توجه به میزان اهمیت آن ها برای کاربران و از نظر کسب‌وکار۲- فضای در نظر گرفته شده برای سرویس‌ها: هر سرویس چه مقدار فضا در اختیار دارد، چه اجزای داخلی دارد و این موارد تعامل‌پذیر یا پویا هستند یا خیر.۳- تمایز پیاده‌سازی در موبایل و دسکتاپ: چگونگی و تفاوت پیاده‌سازی راه‌حل انتخاب‌شده در موبایل و دسکتاپ و رعایت محدودیت‌ها و ویژگی‌ها در هر فرم ۴- تطبیق‌پذیری و پویایی: تغییر ساختار سوپراپلیکیشن در طول زمان و چگونگی استفاده کاربران از آن۲-۵- مطالعاتمستقل از انجام بنچمارک‌ها و با توجه به مفهومی که به دنبال پیاده‌سازی آن برای صفحه نخست ازکی بودیم، مطالعاتی در میان مقالات مرتبط با سازمان‌ها و مجموعه‌هایی که در حوزه سرویس‌های برخط فعال هستند و خدماتی با موضوعات و زمینه‌های متفاوت ارائه می‌دهند، انجام شد. مهم‌ترین نکات حاصل به شرح زیر است:۱- چیدمان پویا: در کنار هم گذاشتن آیکن‌ سرویس‌‌ها خصوصا در مجموعه‌هایی که تعداد زیادی سرویس مجزا دارند، از نظر ترتیب و اولویت حساس و حائز اهمیت زیادی است و نیازد دارد تا از حالت ایستا و ثابت فاصله بگیرد. پویا ساختن این چینش به طور کلی می‌تواند در سه گروه دسته‌بندی شود:بر اساس موقعیت جغرافیایی: تفاوت سرویس‌ها در چگونگی یا حتی فعالیت یا عدم فعالیت در نقاط مختلف جغرافیایی (شهرها یا کشور‌ها)بر اساس رفتار کاربر: تغییر اولویت‌ها و چیدمان بر اساس نیاز کاربران و رفتارهای گذشته‌ی او در سوپراپلیکیشنبر اساس سیاست‌های کسب‌وکار: نحوه برنامه ریزی کسب‌وکار‌ها در رونمایی و یا توسعه یک سرویس خاص در نحوه جانشانی سرویس‌ها می‌تواند در مقاطع مختلف زمانی تغییر ایجاد کند. این سیاست‌ها باید به نحوی باشد که تجربه قبلی کاربران تا حد امکان حفظ شده و حداقل بهبود یابد.۲- فضاهای مخصوص تبلیغات: از مهم‌ترین مشکلاتی که در سوپراپلیکیشن‌ها می‌توان به آن اشاره کرد، معرفی و یا تبلیغ سرویس‌ها و ویژگی‌های آن‌هاست. مدیریت جایگاه‌ها و جلوگیری از شلوغی بیش از حد در فضای اپلیکیشن نکته‌ مهمی‌ست که نیازمند برنامه‌ریزی و سازمان‌دهی دقیق است.۳- ناحیه کاربری و اطلاعات مرتبط: ایجاد جریانی روان و مراحلی هر چه ساده‌تر برای دسترسی به قسمت‌ها و سرویس‌های مختلف یک بار ورود کاربر و مدیریت موارد مرتبط بسیار مهم است. برای مثال ایجاد و پیاد‌ه‌سازی سرویس SSO یا موارد مشابه آن.۳-۵- تست‌هاتست‌های انجام شده در این پروژه به سه دسته کلی تقسیم می‌شوند:۱- تست‌های کاربرد پذیری:برگزاری ۳ تست برای هر یک از بخش‌های بیمه، وام و سرمایه و یک تست برای کل مجموعه بعد از پیاده سازی کامل هر سه تب انجام شد.بیمه: از آنجایی که ساختار این بخش دچار تغییرات زیادی نشده بود و در بازطراحی قبلی تست‌های متعددی را به خوبی پشت سر گذاشته بود، صرفا برای تغییرات کوچک ایجاد شده تست کاربردپذیری انجام دادیم. در این تست نحوه عملکرد ویژگی جست‌وجوی بیمه‌ها مورد بررسی قرار گرفت که تمامی شرکت‌کنندگان به خوبی از آن استفاده کردند.تست برگزار شده در مورد پیدا کردن بیمه توسط کاربران بود. در این تست که با ۶ نفر برگزار شد، از کاربران خواستیم تا ۲ بیمه خاص را پیدا کنند؛ بیمه اول در تایل‌ها موجود بود و بیمه دوم در تایل‌های اصلی وجود نداشت.تمام کاربران توانستند بیمه مورد نظر را بیابند، ۴ نفر از قابلیت جست‌وجو و ۲ نفر از دکمه «همه بیمه‌ها» استفاده کردند.وام: به دلیل محدودیت‌های قانونی و تغییراتی که این بخش در طی پروژه متحمل شد، در نهایت خروجی پیاده‌سازی شده با خروجی عبور کرده از تست‌ها، تفاوت داشت. در نتیجه با توجه به شباهت خروجی پیاده‌سازی‌ شده با دیزاین بخش بیمه، صرفا از نتایج تست‌های قبلی استفاده کردیم. این‌ تست متمرکز بر نحوه استفاده از شبکه‌ آیکن (tiles) بود و از الگو‌های مورد انتظار کاربران پیروی می‌کرد.سرمایه: در فضای اختصاصی این سرویس کامپوننتی وجود دارد که در آن کاربر می‌تواند با مشخص کردن مبلغی که برای سرمایه‌گذاری انتخاب کرده است، مقدار سود خود را ببیند؛ در طی تست انجام شده اصلاحاتی در نحوه نمایش قیمت‌ها و امکان مقایسه با سود بانکی صورت گرفت.۶- نتایجدر این بخش نتایج به دست آمده را در وجوه مختلفی بررسی خواهیم کرد: موارد مرتبط با تجربه و رابط کاربری، تجربه نویسی و طراحی‌های بصری به طور جداگانه مورد بحث قرار می‌گیرند.۱-۶- ساختار تب‌ها و سرویس‌هابنابر آنچه در قسمت‌های قبل توضیح داده شد، در نهایت ساختار Tab برای نمایش سرویس‌ها در کنار هم انتخاب و پیاده‌سازی شد. با این روش علاوه حفظ تجربه کاربران ازکی به عنوان سرویس مقایسه، انتخاب و خرید بیمه، امکان توسعه سرویس‌ها فراهم آمد؛ همچنین فضای اختصاصی کافی و مجزایی برای نمایش هر سرویس با هر شرایطی از نظر تعداد اجزا یا کامپوننت‌ها به وجود آمد.ساختار دقیق هر تب به این صورت است:۲-۶- آیکن‌هادر طراحی آیکن‌ها سه معیار اصلی تعیین‌کننده هستند. حفظ یکپارچگی، وضوح و صراحت محتوایی، قابلیت تمایز کافی. یکپارچگی بدین معناست که بین آیکن‌ها از منظر سبک طراحی، زبان بصری و ترکیب رنگی همسویی وجود داشته باشد. وضوح و صراحت محتوایی پایه‌ای‌ترین اصل طراحی یک آیکن است، در اکثر مواقع هدف اصلی استفاده از آيکن، ایجاد یک راهنمای بصری برای بخشی از محتوا و در اینجا عنوان محصولات است. در صورتی‌که یک آیکن نتواند محتوای موردنظر را به‌ خوبی نمایش دهد و از سمت کاربر قابل تشخیص نباشد، از هدف اصلی خود باز مانده است. معیار سوم یعنی قابلیت تمایز آیکن‌ها، در بازشناسی آیکن‌ها اهمیت پیدا می‌کند. زمانی‌که آیکن‌ها برای طیف متنوعی از خدمات و محصولات طراحی می‌شوند و به طور مستمر مورد استفاده‌ی کاربران قرار می‌گیرند نیاز است نسبت به هم تفکیک‌پذیر باشند. ایجاد این تفکیک‌پذیری از دو طریق امکان‌پذیر است، تفاوت در رنگ و یا تفاوت در سیلوئت. انتخاب ما با توجه به هویت برند و نیازمندی‌های محصول استفاده از سیلوئت‌ها و فرم‌های متفاوت بود. از چالش‌های عمومی طراحی آیکن‌ها می‌توان به تعامل میان‌تیمی در فرآیند طراحی برای خدمات متفاوت اشاره کرد، تلاش کردیم با گرفتن فیدبک‌های سریع و کوتاه‌کردن لوپ طراحی این مسئله را برطرف کنیم. از دیگر چالش‌ها، طراحی بصری برای مفاهیم متناسب با بیمه است. همواره تلاش ما در ایجاد زبان بصری محصول ازکی برخورد غیربدبینانه با مفاهیم بیمه‌ای بوده‌است، برای این منظور تا حد ممکن نمایش حفاظت به نسبت آسیب ارجحیت داشته‌است و افزودن چاشنی طنز برای نمایش مفاهیم راهکار دیگری بوده که انتخاب کرده‌ایم.۳-۶- تجربه نویسیهدف اصلی تجربه‌نویس ایجاد تجربه بهتر برای کاربران یک پلتفرم دیجیتال به واسطه وجه نوشتاری محصول است. در این پروژه برای ایجاد تجربه یکپارچه باید نیاز هر سه سرویس ازکی مورد توجه قرار می‌گرفت. از آن‌ جایی که سرویس بیمه اخیرا بازطراحی شده بود، وجه نوشتاری آن به عنوان معیار اصلی در نظر گرفته شد و ازکی‌وام و ازکی‌سرمایه بر اساس لحن آن نوشته شدند.چون در این پروژه سه سرویس اصلی ازکی به صورت مجزا در یک صفحه جای گرفته‌اند و هر کدام از آن‌ها شامل چندین زیرمجموعه می‌شوند لازم بود تا کاربران سریع و با صرف انرژی و بار شناختی اندک، سرویس‌ها را شناسایی کرده و به هدف خود دست یابند.سه بخش مربوط به سرویس‌ها شامل یک عنوان و یک زیر عنوان می‌شد. برای رسیدن به هدف مذکور عناوین را با رویکرد توضیح سرویس‌ها در یک نگاه نوشتیم تا کاربران پس از ورود به وب‌سایت بر اساس نیاز خود به سرعت یکی از سرویس‌های اصلی را انتخاب کنند و سپس زیر عنوان‌ها را طوری انتخاب کردیم که کاربران به طور کلی با ویژگی‌ها و اهداف هر سرویس آشنا شوند.بیمه: از آنجایی که حفظ تجربه و شناخت کاربران از ازکی به عنوان پلتفرم مقایسه و خرید بیمه اهمیت زیادی داشت با هدف افزایش تمرکز کاربران، عنوان آن را بر خلاف دو سرویس دیگر، کوتاه و یک بخشی انتخاب کردیم. زیر عنوان این بخش قسمتی از تگ لاین ازکی و دو هدف اصلی این پلتفرم یعنی مقایسه و خرید در نظر گرفته شد. 
در ادامه پس نوشتن کامل شعار ازکی و متن کادر جست‌وجو، به تایل‌های مخصوص خدمات این بخش پرداختیم که در طراحی قبلی، پس از معماری اطلاعات و بررسی SEO عناوین آن نوشته شد و زیر عنوان آن بر اساس نقاط تمرکز هر رشته بیمه تعیین شده بود.خرید اعتباری: از چالش‌های ما در نوشتن خرید اعتباری طراحی چندین ورژن برای رسیدن به بهترین محتوا بود. تیم ازکی‌وام علاوه بر شعار و توضیح اصلی سرویس خود، چهار دسته از محصولات قابل خرید با اعتبار را به عنوان نقطه تماس کاربری در نظر گرفت و آن را با فرم بصری و نوشتاری مشابه و آزموده شده مانند بخش بیمه‌ی ازکی مورد تایید قرار داد. در ادامه جهت معرفی کامل‌تر ۳ ویژگی اصلی سرویس را با اشاره به مدت زمان بازپرداخت وام‌ها، طیف گسترده کالاهای انتخابی و خرید از فروشگاه‌های معتبر توضیح دادیم.سرمایه‌گذاری: این سرویس با توجه به حساسیت سرمایه‌گذاری برای افراد، شامل توضیحات، نکات کلیدی و اصطلاحات بسیاری می‌شد و چالش تجربه‌نویسی آن، تقسیم تمام این جزئیات نوشتاری در رابط کاربری بود. متن‌های این سرویس باید احساس اعتماد را القا می‌کردند و آگاهی کامل برای شروع سرمایه‌گذاری امن را به کاربر می‌دادند. این هدف با اولویت‌بندی پارامترها و انتخاب کلمات مناسب انجام شد.۴-۶- نسخه روز و شببرای تجربه‌ای جذاب‌تر و به‌یادماندنی‌تر، طراحی صفحه نخست در دو نسخه روز و شب پیاده‌سازی شد. به این صورت که نسخه شب با آغاز نیمه‌شب تا بامداد نمایش داده می‌شود. در نسخه شب تصویر پس‌زمینه، ساختار بنرها و رنگ متون تغییر می‌کند.۵-۶- نتیجه نهاییخروجی آنچه که خواندید در ادامه قابل مشاهده است. خروجی نهایی، انتظارات تمام تیم‌ها را برآورده کرد که شامل فضای در نظر گرفته شده برای سرویس‌ها، بنرها و موارد مرتبط با مارکتینگ می‌شد. طراحی بصری منسجم آیکن‌ها در تب‌ها و تایل محصولات موجب شد در نهایت ظاهری یکپارچه و هماهنگ با هویت برند در صفحه نخست جلوه کند.جمع بندیبرای سنجش موفقیت یک Design می‌توان معیار‌های متعددی تعریف کرد، از مواردی که در اعداد خلاصه می‌شوند تا متریک‌های متعدد در تخصص‌های مختلف. در زمان انتشار این مقاله مدت زیادی از انتشار این بازطراحی نگذشته است اما در همین زمان کوتاه، سرویس‌های اضافه شده یعنی ازکی‌وام و ازکی‌سرمایه engagement rate حدود ۹۵٪ را تجربه کرده‌اند. همچینین Average engagement time این صفحه حدودا ۲ برابر شده است. لازم به ذکر است که این مستند در طول زمان در قسمت نتایج و تاثیرات بروزرسانی خواهد شد.تیم:فرزین پزشکی - طراح محصول ارشد (Linkedin)دنا مهرگان - طراح بصری (Linkedin)مارال امدادیان - تجربه‌نویس (Linkedin)قدردانی:فرهاد فلاح - front-end developerایمان امیدی - Front-end chapter leadملیحه صحراگرد - Art directorزانیار قادرپناه - Graphic designerآران فنونی - Graphic designerیسنا باقرفر - Content specialistمحمد رخشانی‌زاده - eCRM expertزهرا میرحسینی - Performance marketing managerفاطمه داوودی‌آبادی - SEO expertمحمد صفاییان - Customer acquisition specialistعلیرضا کاظم‌زاده - MarCom Managerفرید عطارزاده - Public relation manager انتشارات ازکی فرزین پزشکی Sun, 10 Mar 2024 13:46:56 +0330 https://virgool.io/azki-posts/%DB%8C%DA%A9-%D8%B4%D8%B1%DA%A9%D8%AA-%D8%A8%DB%8C%D9%85%D9%87-%DA%86%D9%87-%D8%AC%D9%88%D8%B1%DB%8C-%D8%A7%D8%B3%D8%AA%D8%B1%D8%A7%D8%AA%DA%98%DB%8C-%D8%B3%D8%B1%D9%85%D8%A7%DB%8C%D9%87-%DA%AF%D8%B0%D8%A7%D8%B1%DB%8C-%D9%85%DB%8C-%DA%86%DB%8C%D9%86%D9%87-cs2ayunkxffb من امیرعلی هستم و تقریبا نزدیک به یکساله که در نقش کارشناس ارشد حسابداری تجاری به حرکت ازکی کمک می‌کنم. نقش من اینه که روی فرآیند‌های تجاری شرکت کار کنم و ماهیت اون‌ها رو در دنیای حسابداری معنی کنم. تبدیل، تحلیل و کنترل موضوع‌های مربوط به مسائل مالیاتی و بیمه هم از کارهاییه که من در دپارتمان مالی ازکی‌ انجام می‌دم. در این مقاله می‌خوام روش ساخت استراتژی‌ سرمایه‌گذاری شرکت‌های بیمه و نحوه تصمیم‌گیری‌شون رو توضیح بدم. این شرکت‌ها نقش مهمی در تقویت رقابت در بازار مالی، تحریک نوآوری‌های مالی، تقویت حاکمیت شرکتی و تاثیرگذاری روی ادغام در بازار دارن. مقدمه:بازار مالی محیطیه که در اون ادعاهای مالی ایجاد و متحول می‌شن و تأمین و تقاضای سرمایه‌گذاری‌های مالی در اون‌ها به وقوع می‌پیونده. این یه مکانیسم نهادی خاصه که در پایه اون نهادهای مالی وجود دارن و اجرای وظایف و کارایی اون‌ها رو فراهم می‌کنننهادهای مالی به عنوان مشارکت‌کنندگان اصلی در تجارت ابزارهای مالی هستن. نقش اصلی اون‌ها در واسطه‌گری بین ارائه‌دهنده و استفاده‌کننده انباشت است. این کار رو از طریق جمع‌آوری مخزن از طریق ابزارهای مالی اعتباری خودش انجام می‌دن و وظیفه انتقال اعتبار یا خرید ابزارهای مالی از طریق اموال اعتباری رو انجام می‌دن. نهادهای مالی به سه گروه تقسیم می‌شن: ۱- نهادهای سنتی (بانک‌ها، صندوق قرض‌الحسنه و غیره)۲- سرمایه‌گذاران نهادی (شرکت‌های بیمه، صندوق‌های بازنشستگی، شرکت‌های مالی، آموزشگاه‌ها و غیره) ۳- سرمایه‌گذاران گروهی (شرکت‌های سرمایه‌گذاری، صندوق‌های سرمایه‌گذاری، نهادهای دلال و بورس)به عنوان مشارکت‌کنندگان نهادی، شرکت‌های بیمه عوامل بسیار مهمی در بازار مالی، مخصوصا در بازار سرمایه هستن. اون‌ها نقش بسیار مهمی دارند چون به تقویت رقابت در بازار مالی، تحریک نوآوری‌های مالی، تقویت حاکمیت شرکتی، افزایش یکپارچگی بازار، فشار برای به‌روزرسانی زیرساخت بازار و تشویق به توسعه مقررات کمک می‌کنن که در اصل از افق کسب و کار درازمدت اون‌ها نشأت می‌گیره. اهمیتی که شرکت‌های بیمه در بازارهای سرمایه دارند، اصول سرمایه‌گذاری که به‌کار می‌برن و منابع مالی موجود برای اون‌ها. بازارهای مالی مدرن با بین‌المللی‌شدن، جهانی‌شدن و لغو مقررات مشخص شده و ظهور نهادها و ابزار جدید مشخص می‌شن. نهادهای استاندارد بانکداری به‌طور فزاینده‌ای جا به نهادهای سرمایه‌گذار نهادی می‌دن که نقش اون‌ها در بازار مالی روز به‌روز مهم‌تر می‌شه.چون خطرهای ناشی از فاجعه‌های طبیعی و تروریسم افزایش پیدا کردن، شرکت‌های بیمه در بازار جهانی از طریق ادغام به‌هم پیوسته و یک‌پارچه می‌شن. این کار منجر به ایجاد غول‌های بازار می‌شه که منابع عظیمی به ارزش میلیاردها یورو دارن. در نتیجه، اون‌ها به عنوان بازیگران کلیدی در بازارهای سرمایه جهانی ظاهر می‌شن و تأثیر زیادی بر حرکت قیمت‌ها توی این بازارها دارند. یه مثال از اهمیت شرکت‌های بیمه اینه که در ایالات متحده، فقط بانک‌های تجاری از نظر دارایی جلوی شرکت‌های بیمه قرار می‌گیرن. همچنین، اهمیت فوق‌العاده شرکت‌های بیمه در بازار مالی نشون‌دهنده این حقیقته که سرمایه‌گذاری‌های این شرکت‌ها در بازار سرمایه در ایالات متحده، در سال ۲۰۰۴ به مبلغ ۵.۳۴۳ میلیارد دلار بوده (که از این مبلغ ۴.۱۶۰ میلیارد دلار به سرمایه‌گذاری در شرکت‌های بیمه عمر اختصاص یافته).چرا فعالیت شرکت‌های بیمه در بازار مالی مهمه؟- بیمه پایداری مالی فراهم می‌کنه و از طریق تعویض هزینه به همه کسانی که ضرر دیدن، عدم قطعیت رو کاهش می‌ده. این به شکلی تأثیرگذار، اثرات ورشکستگی‌های گسترده که ممکنه پیامدهای فاجعه‌آمیزی بر تولید، اشتغال، درآمد مالیاتی دولت و وضعیت اقتصادی کلان داشته باشه رو کاهش می‌ده.- بیمه بازنشستگی به عنوان یکی از مهم‌ترین اقسام بیمه در اصطلاحات سرمایه‌گذاری این موارد در بازارهای مالی، امنیت برای بازنشستگان آینده فراهم می‌کنه تا با تأمین ماهیانه مبلغ بازنشستگی خودش، تا پایان عمر خودش استقرار داشته باشن.- رشد مقادیر کوچکی که به‌صورت حق بیمه جمع‌آوری می‌شه، به شکل حق بیمه، به شرکت‌های بیمه این امکان رو می‌ده که پروژه‌های سرمایه‌گذاری بزرگ رو مالی کنن و از این راه به رشد اقتصادی کشور مثبت تأثیر بذارن.- بیمه به منظور مدیریت موثر ریسک و تبدیل ارزیابی ریسک استفاده می‌شه. در زمان سرمایه‌گذاری، شرکت‌های بیمه از اعتبارات ویژگی‌های قرض‌الحسنه به‌عنوان یه بخش اصلی مورد بررسی ویژگی‌های شرکت‌های دیگه در بازار رو بررسی کرده و اطلاعاتی که سایر سرمایه‌گذاران در بازار نیاز دارند رو فراهم می‌کنه.- انجام تجارت بین‌المللی بین همکاران که به میزان کافی با اون‌ها آشنا نیستند، اغلب به وجود بیمه‌های خاص وابسته است. بنابراین، تضمین‌های ایجاد شده انگیزه توسعه تجارت بین‌المللی رو ترویج می‌کنه. - اختصاص تخفیف در حق بیمه و اقدامات پیشگیرانه برای محافظت در برابر آتش‌سوزی، آسیب در محل کار و غیره، شرکت‌های بیمه بر پیشگیری و کاهش ضرر‌های بیمه‌شده یا جامعه رفع می‌کنن.الف) اصول سرمایه‌گذاری شرکت بیمهاز اونجا که عمده‌ترین وظیفه‌ای که بیمه‌گرهای مسکن دارند به بیمه‌نامه مسکن مربوط می‌شه که به حفاظت از بیمه‌شده می‌پردازد، اون‌ها می‌بایست میزان کافی از رزروها رو بر اساس تخمین‌های علمی اخذی اختصاص دهند. یه نیاز دیگه برای حفاظت از بیمه‌گذاران و جبران به‌موقع خسارت‌ها به‌صورت پرداخت خسارت یا پرداخت مبلغ بیمه‌شده محسوب می‌شه که امانت و سودآوری رزروها است. در زمان گذاردن اموال در دسترس، شرکت‌های بیمه باید سعی کنن حداقل سودی رو کسب کنن که برابر با نرخ بهره میانگین درآمدی که در بازار سرمایه به‌دست می‌آید. اموال تخصیص یافته شرکت‌های بیمه می‌تونن در یکی از دسته‌های زیر انجام بشن:۱) املاک یا اعطای وام و تسهیلات مالی دیگه۲) خرید اوراق بهادار۳) واریز اموال در بانک‌ها و سایر مؤسسات مالی.هر سرمایه‌گذاری شرکت بیمه بر اساس دو اصل اساسی انجام می‌شه:۱) فراهم کردن سطح بالای حفاظت در برابر ریسک بیمه‌شده‌اش۲) دستیابی به بالاترین بازده ممکن بر روی سرمایه‌گذاری شده.برای رفع این دو تا شرط، سه اصل وجود داره که بر اساس اون‌ها سیاست سرمایه‌گذاری بیمه‌گر تعیین می‌شه: اصل امانتاصل سودآوریاصل نقدینگیویژگی مختصر موقعیتی که شرکت‌های بیمه در بازار مالی دارن، در الزاماتی که باید اجرا کنن قابل مشاهده‌ست. این الزامات به بیمه‌گذارانه که باید به موقع رعایت بشه و ساختار پرتفوی شرکت‌های بیمه رو مشخص می‌کنه.بنابراین، هنگام اتخاذ تصمیمات سرمایه‌گذاری در انواع دارایی‌هایی که برای این اموال واجد شرایط هستن، مدیران پرتفو باید به امانت این سرمایه‌گذاری‌ها توجه کنن. اگر شرکت‌های بیمه مانده اموال خودش رو در دارایی‌های پرخطر سرمایه‌گذاری کنن، ناتمامی در انجام وظایف اصلی اون‌ها به وجود می‌آید و اینکه میزان پرداخت جبران به مبلغ بیمه‌شده رو فراهم آورد. به همین دلیل، شرکت‌های بیمه باید دارایی‌های خودش رو اصلی به دارایی‌های کم ریسک فروش بدن. این موضوع اصولاً برای شرکت‌هایی که در زمینه بیمه عمر فعالیت می‌کنن اعمال می‌شه، چون این دارایی‌ها منابع ثابت و با کیفیت برای تأمین نیازهای بلندمدت و هماهنگ کردن ساختار سررسید اموال و بدهی شرکت‌های بیمه هستن. برای همینه که محض اطمینان از پایداری مالی شرکت‌های بیمه، لازمه که دولت تعیین کنه روی چه نوع و چه درصدی از اموال شرکت‌های بیمه می‌تونه سرمایه‌گذاری کنه. رشد حق بیمه و انباشت اموال بر اساس محصولات بیمه عمر منجر به این شده که شرکت‌های بیمه به عنوان بزرگترین سرمایه‌گذار نهادی در اروپا ظاهر بشن. در سال ۲۰۱۲ شرکت‌های بیمه با اشغال ۵۱٪ از بازار مالی، به عنوان بزرگترین سرمایه‌گذار ظاهر شده‌ن.مدل‌ها و الگوهای سرمایه‌گذاری در اوراق بهادار فردی توسط ماهیت محدودیت‌ها و مسئولیت‌های اون‌ها تعیین می‌شه. چون بیمه عمر در حال حاضر منبع دائمی و بلندمدت امواله، طبیعیه که شرکت‌های بیمه که در بیمه عمر فعالیت می‌کنن، اصلی‌ترین سرمایه‌گذاری خودش رو اصلی در بازار سرمایه انجام بدن؛ مخصوصا در اوراق بهادار دولتی و سند مسکن. مهمه که بین مهلت‌های سرمایه‌گذاری و تعهدات هماهنگی وجود داشته باشه. مثلا در مقابل بیمه عمر، بیمه مالکیت و یه شکل اساسی از سرمایه‌گذاری در سهام و اوراق بهادار شرکت‌هاست. چون رزروهای اون‌ها کمتر پایدار هستن و خسارت‌های ممکن مقدار بیشتره.ب) عملکرد جهانی صندوق‌های سرمایه‌گذاری شرکت‌های بیمهبه عنوان سرمایه‌گذاران نهادی، شرکت‌های بیمه از مهم‌ترین شرکت‌ها در بازار مالی، مخصوصا در بازار سرمایه، محسوب می‌شن. یکی از عوامل مهم که ساختار سرمایه‌گذاری شرکت‌های بیمه در جهان رو تعیین می‌کنه، بدون شک سطح توسعه بازارهای مالی در یک کشوره. هرچه بازار سرمایه پیشرفته‌تر باشه و تعداد بیشتری از اوراق بهادار با کیفیت بالا و بیشترین سرمایه‌گذار به اون سرمایه‌گذاری کنن، به شرکت‌های بیمه فرصت‌های بسیار بیشتری برای سرمایه‌گذاری مناسب فراهم می‌کنن.مقایسه با ساختار سرمایه‌گذاری شرکت‌های فعال در بیمه عمر نشون می‌ده که در شرکت‌های بیمه غیرعمر، سهم کمتری از اوراق بهادار وجود داره. مشارکت در این نوع اوراق بهادار بلندمدت و تحت سلطه اوراق بهادار شرکتی باعث شده سهم املاک و مستغلات کاهش پیدا کنه، در حالی که وام‌ها در سطوح تقریباً ثابت مونده‌ن. از ساختار سرمایه‌گذاری در اوراق بهادار (سهام) در بازارهای جهانی می‌شه نتیجه بگیریم:۱- برای بیمه عمر، خطرات آسون‌تری قابل پیش‌بینی هستن و هیچ رویداد ناگهانی عظیمی که ممکنه مایه خطرات اقتصادی بشه، وجود نداره. پس شرکت‌های بیمه معامله با این نوع بیمه می‌تونن در اوراق بهادار بلندمدت دولتی، سهام شرکت‌های خوب یا املاک سرمایه‌گذاری کنن.۲- در بیمه غیرعمر، مسئولیت‌های بالقوه پرداخت خسارت و مقدار پرداخت شده سخت‌تر پیش‌بینی می‌شه. پس لازمه بخشی از ابزارهای نقدی فراهم بشه که در صورت هزینه‌های غیرمنتظره، سریع به پول نقد تبدیل بشن.ج) تأثیر بحران مالیانحصار بالا به بیمه مسکن بر اثر بحران مالی، ناشی از نقش مهمش در بازارهای مالی کشورهای توسعه‌یافته‌ن. از کل ارزش دارایی‌های سرمایه‌گذاران نهادی در بازار اروپا، ۴۲٪ مربوط به شرکت‌های بیمه و ۳۰٪ به صندوق‌های بازنشستگیه.بر اساس یک پرتفوی از اوراق بهادار شرکت‌های بیمه عمر در کشورهای توسعه‌یافته، می‌شه ادعا کرد که بیشتر دارایی‌های اون‌ها به طور کل در بندها و اوراق بهاداری سرمایه‌گذاری شده‌اند که با بازدهی کمتر، اما خطر کمتر نسبت به ابزارهای سهام مشخص می‌شن. برای حداکثر کردن امانت سرمایه‌گذاری و بهره‌مندی از تحریک‌های مالیاتی خاص، این شرکت‌ها به طور خاص علاقه‌مند به سرمایه‌گذاری در بندهای دولتی هستن.در مقابل، شرکت‌های بیمه غیرعمر سهم نسبتاً بیشتری از دارایی‌های خودشوتن رو در نقد، معادلات نقدی و اوراق بهادار کوتاه مدت (عمدتاً کاغذهای تجاری و بلیط‌های خزانه) نگه می‌دارن. علاوه‌براین، این شرکت‌ها نسبت به شرکت‌های بیمه عمر نسبت به سهم بیشتر سرمایه‌گذاری می‌کنن.بحران مالی بر شرکت‌های بیمه تاثیرهای زیادی می‌ذاره که به پنج‌تاش اشاره می‌کنم:تأثیر مستقیم تسهیلات درجه دو مسکن با افشای ریسک از طریق ارتباط با دارایی‌های تسهیلات پرریسک مسکن شرکت‌های بیمه.تأثیر بر پرتفوی شرکت‌های بیمه از طریق افشای خاص به ریسک افت قیمت گواهی‌نامه‌های سپرده، اوراق بهادار و دیگه اوراق بهادار بانک‌ها که تحت تأثیر بحران مالی قرار گرفته‌ن.تأثیر کلی بر سقوط بازارهای مالی به عنوان نشون‌دهنده کاهش قیمت‌های سهام و افزایش نرخ سود در بازارهای سرمایه.تأثیر بحران بر کسب و کار بیمه نامه‌نویسی.ارزیابی (قیمت‌گذاری) شرکت‌های بیمه.در سال ۲۰۰۸ نسبت به سال ۲۰۰۷ بیمه‌گرها در بیشتر کشورهای OECD کاهش قابل توجهی در بازدهی خالص متوسط سرمایه‌گذاری خودش رو در زمینه بیمه عمر و عمر و اعتبار ایجاد کردن. در حالی که در کشورهایی مانند مجارستان، فنلاند، بلژیک و هلند بازدهی‌ها منفی شدن. این بیمه‌گرها به عنوان پاسخ به فروپاشی بازارهای مالی، سهم سهام رو کاهش و مشارکت (دولتی) در اوراق بهادار و سرمایه‌گذاری‌های کوتاه مدت رو در پرتفوی سرمایه‌گذاری خودشون رو افزایش دادن. این روند پس از بحران سال‌های ۲۰۰۰-۲۰۰۱ و پس از شروع بحران اقتصادی سال ۲۰۰۸ فوق‌العاده بود.با این حال، حتی اوراق دولتی به عنوان ابزارهای سنتی و ایمن، از نظر بحران فعلی بدهی، منبعی از ریسک اعتباری برای بیمه‌گرهان! بنابراین، در سال‌های اخیر روی کاهش سهم اوراق بهادار و افزایش نسبت سهام در پرتفوی بیمه‌گرها به شکل غیر معمولی تاکید کرده‌ن. با وجود افزایش عدم قطعیت و افزایش الزامات نظارتی، نقش سهام در پرتفوی سرمایه‌گذاری بیمه‌گرها نباید دست کم گرفته بشه. به دلیل نیاز به هماهنگی اشکال دارایی با نوسانات ارزش بدهی بیمه‌گرها و برای بهره‌گیری از اثرات تنوع ریسک، مالکیت سهام می‌تونه به کاهش کلی ریسکی که بیمه‌گر به عنوان یه سرمایه‌گذار معرفی می‌شه، کمک کنه.یه راه برای کاهش اثر ریسک تورم می‌تونه تخصیص بخش نسبتاً بزرگی از دارایی‌های بیمه‌گرها به دارایی‌های واقعی باشه. با این کاهش ، اثر افزایش نرخ تورم و ارائه بازدهی قابل مقایسه با ابزارهای سهام، سرمایه‌گذاری در دارایی‌های واقعی با نقدینگی کم و نوسان بالا همراهه؛ که جذابیت اون‌ها رو کاهش می‌ده. به عنوان جایگزین‌های مناسب سرمایه‌گذاری در شرایط پیش‌بینی شده، بالا بودن نرخ تورم، اوراق بهادار دولتی کوتاه مدت و اوراق بهادار مشتقه از تورم، بیشتر موثر هستن.نتیجه‌گیریشرکت‌های بیمه به عنوان نهادهای مالی‌ای که سپرده ندارن، بخش مهمی از زیرساخت نهادی سرمایه‌گذاری هستن که در یک بازی رقابتی، در انتقال پس‌انداز از اقراض‌دهندگان به واحدهای اقتصادی ناکارآمد شرکت می‌کنن و تقریباً به عنوان یه نهاد مالی نگهداری سپرده بانک رو پیش‌گرفته‌. در عمل، شرکت‌های بیمه و صندوق‌های بازنشستگی از سرمایه‌های جمع‌آوری‌شده از مشتری‌های خودشون بهره‌مند می‌شن. با خرید بیمه، افراد از بیمه بهره‌مند می‌شن چون شرکت بیمه ریسک رو به نفع مشتری خودش به عهده می‌گیره. بسیاری از افراد از شرکت‌های بیمه و صندوق‌های بازنشستگی به عنوان مسیرهای اصلی سرمایه‌گذاری خودش استفاده می‌کنن. میزان افزایش سرمایه‌های جمع‌آوری‌شده از مشتری‌ها، شرکت‌های بیمه و صندوق‌های بازنشستگی رو به جایگاه‌های مختلف سرمایه‌گذاری سودآور هدایت می‌کنن.داده‌های OECD نشون می‌ده که بخش بیمه بالاترین منبع سرمایه‌گذاری برای رشد هر اقتصادیه که چالش واقعی برای این سرمایه‌گذاران نهادی است. بنابراین، ضروریه که سازندگان سیاست اقتصادی اطمینان حاصل کنن که شرایطی فراهم بشه که شرکت‌های بیمه امانت سرمایه‌گذاری خودش رو داشته باشن.به عنوان یک نوآوری تو حوزه تنظیم صندوق‌های سرمایه‌گذاری شرکت‌های بیمه، مفهوم سولونسی II یه روش تنظیم احتیاطی (اصل شخص محتاط و دوراندیش) رو معرفی می‌کنه که محدودیت‌های کمیتی موجود در سرمایه‌گذاری رو منسوخ می‌کنه.منابعBalaban M., (2007), Insurance in Modern World, monograph, Cikos, Belgrade Bank for International Settlements (BIS) (2007), Institutional Investors, global savings and asset allocation, CGFS Papers, February. Business Insurance Monitor (2009), Serbia Insurance Report., Including 5-year industry forecast, New York Kočović, J. Šulejić, P., (2006), Insurance, Economic faculty, Belgrade Staking, K.B. & Babbel, D.F. (1995). The relation between capital structure, interest rate sensitivity, and market value in the property-liability insurance industry. Journal of Risk Statistic Report of National Bank of Serbia (2011), NBS, Belgrade Wyman O., (2013), Funding the future, Insurers’ role as institutional investors analysis, London, Zanjani, G., (2002). Pricing and capital allocation in catastrophe insurance.Journal of Financial Mladenka BALABAN انتشارات ازکی امیرعلی محمدی Mon, 19 Feb 2024 16:42:22 +0330 https://virgool.io/azki-posts/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%DA%A9%D8%A7%D8%B1%DB%8C-%D9%85%D9%86-%D8%AF%D8%B1-%D8%A7%D8%B2%DA%A9%DB%8C-h9jn0nhuu5v9 من معتقدم نمی‌تونیم بگیم که ما با فضای ابهام آشنا نیستیم. زندگی توی فضای اقتصادی و کاری ایران به ما یاد داده که با ابهام دست و پنجه نرم کنیم. بعضی‌هامون بیشتر موفق بودیم و بعضی‌هامون کمتر. اما همه ما بر این توافقیم که این موقعیت ساده‌ای نیست. این ابهام وقتی توی فضای استارتاپی کار کنی یه جور دیگه‌ای تجربه می‌شه. ماه‌های اول حضورم توی ازکی، سرو کله زدن با این ابهام واسم سخت بود. زمانی که وارد ازکی شدم، در شرایطی بودم که می‌خواستم از چارچوب‌ها و مرزهای خط‌کشی شده و فرآیند‌های سفت و سخت دور بشم و فضای جدیدی رو تجربه کنم. دوست داشتم از دایره امن خودم بیرون بیام و یه زمین بکر پیدا کنم و بسازمش. من به عنوان «مدیر جذب و استخدام ازکی» وارد تیم شدم. اما می‌دونستم که وقتی شرایط جدیدم رو آگاهانه انتخاب کردم، لازمه که بپذیرمش و بهش به عنوان فرصتی نگاه کنم که قراره توش مهارت‌هام رو تقویت کنم. یکی از این مهارت‌ها توانایی مدیریت ابهام بود.ممکنه ما در موقعیت‌هایی قرار بگیریم که آخرش معلوم نباشه و شرایط و مقتضیات خیلی سریع تغییر کنند. کسی که می‌خواد توی این شرایط کار کنه باید بتونه با این سطح از تغییرات کنار بیاد.خیلی اوقات چیزی که مدیریت ابهام رو چالش‌برانگیزتر می‌کنه، اینه که کار رو باید چابک جلو برد. نیاز به چابکی بیشترین چیزی بود که روزهای اول حس می‌شد. من در زمانی به تیم پیوستم که قرار تیم منابع‌انسانی بر این بود که بتونه هر نیازی که سمتش میاد، در سریع‌ترین زمان ممکن و به بهینه‌ترین شکل پاسخ بده. ما همگی مشغول ساختن زیرساخت‌های منابع‌انسانی بودیم. نشستیم و با هم رویه‌های جدید رو ایجاد کردیم. از قصه‌ی برند کارفرمایی و ارزش‌های سازمانی گرفته تا مدیریت عملکرد و رویه‌های جذب و استخدام و توسعه مهارت‌های رهبری، تا برگزاری ازکی‌موود (سنجش رضایت کارکنان) و متناسب‌ کردن حقوق‌ها.انجام دادن این کارها در کمتر از یک‌ سال، کار آسونی نبود، ولی چیزی که ما می‌خواستیم این بود که منابع‌انسانی تغییر اساسی کنه، انجام کار درست و بهینه هدفمون باشه و هممون دغدغه بهبود تجربه همکارهامون رو داشته باشیم. اون روزها برای من پر از تجربه‌های جدید و تغییرهای سریع بود.مدیریت ابهام در کنار چابکی!می‌تونم بگم سخته و کار هر کسی و هر تیمی نیست. نیاز به آزمون و خطا و رهبری درست داره. نیاز به روحیه‌ای داره که از اشتباهاتت درس بگیری. در ادامه این‌ها، آموخته‌های من برای مدیریت چابک ابهامه.برای مدیریت چابک ابهام:لازمه دقیقا شفاف کنم که چه چیزی مبهمه و چه چیزی شفافه. گاهی ممکنه ابهام در یک سری موضوعات باعث بشه حواسمون از چیزهایی که می‌دونیم و شفافه پرت بشه و ارزیابی‌مون از ابهام بیشتر از حد واقعیش باشه.همیشه ممکنه تمام تکه‌های پازل تصمیم‌گیری در دسترسم نباشه. اینجا گاهی لازمه ریسک‌ کنم.تا جای ممکن بهتره تصمیم‌گیری‌ها رو بر اساس آنالیزی که از داده‌های موجود دارم انجام بدم.برای تصمیمی که می‌گیرم سناریوهای احتمالی رو در نظر بگیرم تا بتونم به روش موثرتری با تغییر کنار بیام.بدون گفت‌وگوی موثر نمی‌شه. برای کاهش ابهام تا جایی که می‌شه باید ذی‌نفع‌های تصمیمم گفت‌وگو کنم.اشکالی نداره اگه در جریان گفت و گو با آدم‌ها شکست بخورم و چیزی که می‌خواستم انجام نشه. چون می‌فهمم کجا باید این گفت‌و‌گو رو بهتر مدیریت می‌کردم.اگر گفت‌وگویی به نتیجه برد‌-برد می‌رسه، حواسم باشه چطور اون گفت‌و‌گو رو جلو بردم تا بتونم بعدا ازش استفاده کنم.ارتباط با هر آدمی مدل خودش رو داره. اما بین همه این‌ها اصول مشترکی وجود داره که باید برای خودم شفاف بشه.گاهی باید با انعطاف‌پذیری فضای ابهام رو مدیریت کنم و تشخیص اینکه کجا انعطاف‌پذیری به بهبود نتیجه کمک می‌کنه نکته اصلی داستان و فوت کوزه‌گریه.لازمه از خودم بپرسم: «من کنترل چه چیزهایی رو در دستم دارم و کنترل چه چیزهایی در دستم نیست؟»لازمه برای خودم و تیمم شفاف کنم که: «مهم‌ترین کاری که همین الان می‌تونیم انجام بدیم چیه؟»مورد آخر، چیزیه که منو به نوشتن این متن واداشت. الان در آغاز یک تجربه جدید و ناشناخته ایستادم. و مهم‌ترین کاری که همین الان می‌تونستم انجام بدم، ثبت و انتشار یادگیری‌های باارزشم بود.#ازکی#ازکی_تجربه_کاری_من#منابع انسانی#مدیریت_ابهام#چابکی انتشارات ازکی مهسا رضوی Wed, 06 Dec 2023 10:08:45 +0330 https://virgool.io/azki-posts/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D9%85%D9%86-%D8%A8%D9%87-%D8%B9%D9%86%D9%88%D8%A7%D9%86-agile-delivery-manager-%D8%AF%D8%B1-%D8%A7%D8%B2%DA%A9%DB%8C-gqzrcbk0fepn در این مقاله برای درک بهتر تفاوت Agile Delivery Manager با اسکرام مستری، قصد دارم تجربه شخصی خودم رودر این مسیر با شما به اشتراک بگذارم.من، زهرا نصیری در ابتدای سال ۱۴۰۰ به عنوان اسکرام مستر به مجموعه ازکی پیوستم و با شرح شغلی استاندارد کارم رو آغاز کردم.در ابتدا با اینکه با عنوان «اسکرام مستر» به مجموعه اضافه شدم، اما این فرصت در اختیار من قرار گرفت که با بررسی تیم‌ها، چارچوب‌های مناسب اون‌ها رو انتخاب کنم. به همین دلیل، سعی کردم با استفاده از مدل Cynefin Framework محیط هر تیم رو شناسایی کنم. من اهداف، نیازمندی‌ها و شرایط هر تیم رو بررسی کردم تا چارچوب مناسب اون‌ها رو انتخاب کنم. پس از بررسی معیارهای متفاوت، به این نتیجه رسیدم که برای تیم‌های Cross-Functionبا عدم قطعیت و ابهام بیشتر چارچوب اسکرام، برای تیم‌های Functional (تیمی با تخصص‌های یکسان که به سایر تیم‌های خدماتی ارائه می‌دن مثل تیم زیرساخت و …) چارچوب کانبان و یکی دیگر از تیم‌ها چارچوب اسکرامبان روش مفید و موثرتریه و نیازی نمی‌دیدم همه تیم‌ها با یک روش ثابت هدایت بشن.در راستای همسو شدن با اعضای تیم، کارم رو از برگزاری کارگاه و آموزش افراد شروع کردم. وقتی مطمئن شدم با همه اعضای تیم همسو و هم راستا هستیم و به ادبیات مشترکی برای بیان اهداف، برنامه‌ها، کارها و .. رسیدیم، پیاده‌سازی اسکرام رو شروع کردم.برگزاری ایونت‌های اسکرامکمک به تیم توسعه برای تمرکز بر روی تولید High-Value Incrementکمک به توانمند کردن تیم‌هاتهیه Artifact هارفع موانع تیمهمکاری با مدیر محصول برای تهیه بکلاگ اولویت‌بندی شده بر اساس مدل ها مورد نیازایجاد فرهنگ چابکی در شرکتهمکاری با سایر مدیران برای شناساندن متدولوژی چابک و مدل اسکرامدر نهایت سعی کردم به عنوان یک اسکرام مستر چارچوب اسکرام رو در کنار هم نگه دارم و فرآیند مدیریت، کار گروهی و انجام کارها در پروژه رو برای شرکت، مدیر محصول و تیم توسعه آسون کنم.تا اینجای کار با استقرار چابکی تقریبا همه چیز خوب پیش رفته بود، ولی در تیم‌ها و ارتباطاتشون باز مشکلاتی رو شناسایی کردم که شفاف و روان نبود.یکی از معضلات که در تیم‌ها اختلال ایجاد می کرد، درخواست‌های جاری از سمت بقیه دپارتمان‌های شرکت مثل مارکتینگ و عملیات بود، که این درخواست‌ها از روش‌های مختلف به تیم می‌رسید و این موضوع باعث ایجاد آشفتگی و بی‌نظمی در تیم می‌شد. برای حل این مسئله، سعی کردم با جمع‌آوری نیازمندی‌های موجود، روش‌ها و فرآیندهایی رو طراحی و پیاده‌سازی کنم که بتونیم در زمان مناسب، بدون فشار کار و ایجاد صف و عقب افتادگی نیازهای این ذی‌نفع‌ها رو به موقع تحویل بدیم. برای حل این مشکل ابزارهای مختلفی (Asana, Jira, Trello) رو بررسی کردم و در نهایت به این نتیجه رسیدم جیرا ابزار مناسبی برای مدیریت و آگاهی از این نیازمندی‌ها و پیگیری مرتب مداوم اون‌هاست.در ادامه، بعد از اینکه تیم‌ها به نقطه پایداری قابل قبولی رسیده بودن، نیاز جدیدی در تیم‌ها ایجاد شد. اون‌ها نیاز به برنامه‌های کوتاه‌مدت و میان‌مدت مشترکی داشتن که هم بتونه نیازهای مدیران محصول، بدهی‌های فنی، نیازهای جاری کسب و کار و .. رو شامل بشه و باعث ایجاد ساختار و ‌بی‌نظمی بشه. ما نیاز داشتیم که بتونیم برای این نیازها برنامه اجرایی تهیه کنیم. زمانیکه در این موقعیت قرار گرفتم، عدم قطعیت‌ و ابهام‌ در تیم‌ها خیلی کمتر شده بود و نیازی به بازه‌های کوتاه‌مدت نبود و با تهیه برنامه‌های ۳ ماهه نیازمندی‌های ذی‌نفعان به موقع قابل تحویل بود.در راستای رسیدن به برنامه‌های با ثبات، رودمپ‌های ۳ ماهه نیازمندی‌های مدیرهای محصول، مدیرهای فنی و سایر ذی‌نفع‌ها جمع‌آوری شد و با کمک لیدرها رودمپ‌های سطح بالاتری برای تیم‌ها آماده کردیم که اساس برنامه‎های فصلی هر تیم مشخص شده بود. برای تهیه این رودمپ‌ها، نیاز بود با مدیران محصول(Product Manager) و مدیران فنی (Engineer Manager) جلسات متعددی برگزار بشه تا یک رودمپ واقعی و قابل قبول تهیه کنیم.در کنار این، علاوه بر تهیه گزارش‌های هر اسپرینت و پیشرفت محصول، گزارش‌هایی مطابق نیاز بقیه مدیران برای بررسی و پایش تیم‌ها به شکل ماهانه تهیه کردم.من قبل از اینکه به مجموعه ازکی ملحق بشم، به مدت ۳ سال به عنوان اسکرام مستر در شرکت‌های دیگه‌ای کار کرده بودم و به وظایف و نقش اسکرام مستر آگاه بودم ولی کارهایی که در تیم به من محول می‌شد خارج از این ساختارها بود و علاوه بر اون کارهایی بود که هنوز به طور شفاف مشخص نبود چه کسی مسئول نهایی اجرای اون‌هاست. در این زمان با افراد زیادی صحبت کردم و مقالات متعددی خواندم تا متوجه بشم چه کسی در سازمان‌ها این نقش‌ها رو ایفا می‌کنه یا این قبیل کارها در تیم‌ها به عهده چه کسانیه.در کل، وظایفی که در سازمان بر عهده من بود ولی در شرح شغلی اسکرام مستر نبود به این صورت است:تهیه رودمپ‌های تیماثربخشی و کارایی روابط بین تیمیتهیه مستندات برای فرآیندهایی که ساخته شدننگهداری و پایش انواع فرآیندهامشارکت در تخصیص بهینه منابع از جمله منابع انسانیمسئولیت در قبال تحویل به موقع و …تهیه گزارش‌هایی برای فاز اجرایی رودمپ‌های بین تیمیبا توجه به نکات بالا و برای آشنایی بیشتر با ساختار شرکتهای دیگر شروع به مطالعه کردم و متوجه شدم در شرکتهای غیر ایرانی (که بیشتر مورد مطالعه من بود) نقشی با عنوان Agile Delivery Manager وجود داره!اولین تعریفی که می‌شه برای این جایگاه شغلی تعریف کرد به صورت زیره:«فردی با توانمندی مدیریت پروژه که مسئول تحویل پروژه به صورت موثر و کارآمد با حداقل تاخیر و نواقص و استفاده بهینه از منابع است.»از جمله وظایف مهم این موقعیت شغلی می‌تونیم به موارد زیر اشاره کنیم:مسئول برنامه‌ریزی، اجرا و پیگیری یک پروژه توسعه نرم‌افزار و همکاری نزدیک با مدیران ارشد سازمانمسئولیت مدیریت منابع تیمنظارت بر پیشرفت پروژهشناسایی ریسک‌ها در مراحل اولیه قبل از تبدیل شدن به مشکلات جدیشناخت کسب و کار و توانایی تحلیل اهداف بلند، کوتاه و میان مدتمسئول بهبود عملکرد و انگیزه بخشی به تیم (Improve Team Performance & Motivation)توانایی ایفای نقش به عنوان اسکرام مستر در صورت نیاز تیمدرک نیازهای مشتری، استراتژی پروژه و اهداف آنرهبری و مربی‌گری تیم‌ها بدون حمایت عمده و تعیین بهترین راه‌های پیشروی پروژه به سمت موفقیت(Agile Coaching)تدوین و اصلاح نقشه راه پروژه به اندازه لازمارائه شفافیت از طریق گزارش‌دهی و ارتباط مداوم با ذی‌نفع‌هاارايه بازخورد‌ها و تغییرات برای بهبود عملکرد و کیفیت پروژه‌هاتهیه و کنترل فرآیندهای مناسب تیمی، سازمانی و ….برای ایفای این نقش این افراد باید گستره متفاوتی از مهارت‌ها داشته باشن که می‌تونم به چند نمونه زیر اشاره کنم :آشنایی کامل با مدیریت پروژه و چالش‌های اونآشنایی کامل با متدولوژی‌های چابک و نابآشنایی با صنعت نرم افزارمهارت مدیریت تیم و رهبری (Leadership and Team Management)مهارت در برقراری ارتباطات موثر و همکاری با اعضای تیم (Communication and Collaboration)مهارت حل مساله و تصمیم گیری(Problem-Solving and Decision-Making)بهبود مستمر (Continuous Improvement)رهبری خدمتگزار (Servant Leadership)مدیریت ذی‌نفع‌ها (Stakeholder Management)با این شرح وظایف و توانمندی‌ها سوال بعدی که در ذهن من شکل گرفت این بود که نتیجه و اثربخشی یک Agile Delivery Manage در سازمان‌ها چطوری مشخص می‌شه؟Agile Delivery Manage برای پروژه‌های چابک بسیار ارزشمندن و در اصطلاح به این افراد «ستون فقرات پروژه‌ها» گفته می‌شه. چون این افراد با تمرکز بر روی تحویل‌پذیر بودن کارهای تعریف شده، بررسی نیازمندی‌های ذی‌نفع‌ها، بهره‌وری تیم و برطرف کردن موانع برای تضمین موفقیت پروژه تلاش می‌کنن. این افراد با استفاده از انجام وظایف مختلف مثل مدیریت بک‌لاگ پروژه، همکاری با مدیر محصول، پیگیری برنامه‌های تیم و نحوه اجرای آن، اطمینان از وجود مکانیزم‌های بازخورد لازم و حتی برگزاری جلسات متعدد به رفع مانع‌های تیم کمک می‌کنن تا اعضای تیم بتونن به بهترین نتیجه دست پیدا کنن. اینطوری محصول باکیفیت در زمان‌بندی مناسب به مشتری نهایی می‌رسه و از این راه برای سازمان خلق ارزش می‌کنه.پس از آشنایی با این موقعیت شغلی وظایفم به عنوان اسکرام مستر در ازکی رو با وظایف اسکرام مسترهای مختلف در سازمان‌ها و Agile Delivery Manager مقایسه کردم و به این نتیجه رسیدم وظایف ما با توجه به ساختارهایی که تهیه و اجرا می شد بیشتر نزدیک به Agile Delivery Manager محسوب می‌شه. البته توی ازکی کارهایی همچنان وجود داره که در استانداردهای بین المللی برای تعریف این موقعیت شغلی نیست، ولی در راستای بهبود عملکرد تیم‌ها، افراد و فرآیندهای سازمانیه. در حوزه شرح شغلی این موقعیت قرار گرفته.در ادامه با تهیه مستندات توانستم لیدرها رو متقاعد کنم این موقعیت شغلی رو شرکت ایجاد کنیم.در ازکی ما چون در ساختار هر تیم Cross-Functional نقش دیگری با عنوان Engineer Manager داریم تعدادی از وظایف Agile Delivery Manage بین این دو نقش تقسیم می‌شه. مثلا مدیریت منابع معمولا مسئولیت ADM می‌شه ولی در تیم‌های ما برعهده Engineer Manager است و یا به عنوان مثالی دیگر حل تعارضات بین اعضای فنی تیم مسئولیت Engineer Manager حساب می‌شه ولی در بقیه سطح‌های تیم که شامل Product Designer, Product Manger و .. می‌شه مسئولیت ADM به شمار می‌ره.در نهایت ما در ازکی به توجه به نیاز و ساختارهای تیم، این شرح شغلی رو شخصی‌سازی کردیم و متناسب فرهنگ شرکتمون تغییر دادیم و همچنان در حال آزمون و خطا و بهبودش هستیم و این مسیر قراره یک مسیر طولانی باشه.در آخر پیشنهاد می‌کنم برای اینکه بیشتر با این مسیر آشنا بشید، از تجربیات افرادی که با این شرح شغلی در شرکت های خارجی کار کردن استفاده کنید و همیشه سعی کنید مسیر بازخورد و بهبود مستمر رو ادامه بدید.منابع:https://qat.com/delivery-managers-role-in-an-agile-project/https://uk.indeed.com/career-advice/finding-a-job/what-does-agile-delivery-manager-dohttps://emilywebber.co.uk/what-is-an-agile-delivery-manager/https://reviewnprep.com/blog/delivery-manager-vs-scrum-master-what-are-the-differences/ انتشارات ازکی زهرا نصیری Sat, 25 Nov 2023 11:03:39 +0330