قدرتی فراتر از سیاه‌چاله‌ی فورتنایت

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

این بازی در سال ۲۰۱۷ توسط کمپانی Epic Games برای تمامی پلتفرم‌های ویندوز، مک، پلی‌استیشن، ایکس‌باکس، نینتندو، آندروید و آی‌اواس منتشر شد.
با توجه به رایگان بودن بخش آنلاین بازی با عنوان «Battle Royale» و ارائهٔ بروزرسانی‌ها، این بازی توانست بسیار موفق باشد. در حال حاضر نزدیک به 250 میلیون بازیکن دارد.

اما دقیقا چه چیزی این بازی را آنقدر محبوب کرده است که کاربران حاضر به دل کندن از بازی با آن نیستند. برای فهمیدن دقیق این موضوع باید با مدلِ قُلّابِ این بازی که ما را درگیر آن می‌کند آشنا شویم.

قُلّاب‌ها چه هستند؟

قُلّاب‌ها، طبق صحبت‌های آقای Nir Eyal نویسنده‌ی کتاب معروف Hooked: How to Build Habit-Forming Products (که قبلا نیز خواندن آن را به شما پیشنهاد کردیم)، تجربه‌هایی هستند که برای ایجاد عادت در کاربران برای پیوند مشکل آن‌ها با محصول شرکت، دیزاین می‌شوند. Eyal در این کتاب به توصیف ۴ فازِ مدل هوک (Hooked Model) می‌پردازد. اینکه چطور شرکت‌ها از هوک برای ساخت محصولات و خدماتی بهره می‌برند که مردم عاشق آن‌ها می‌شوند.

در مقاله‌ی امروز به بررسی این ۴ فاز مدل هوک بر روی بازی فورتنایت می‌پردازیم:

http://bit.ly/dxgn547

(زمان حدودی مطالعه: ۸ دقیقه)

نویسنده: حسین میرزاده

#مدل_هوک #قلاب #فورتنایت #بازی_ویدئویی

@Dexign فلسفه دیزاین


ــــــــــ

لزوما به پیش بردن پروژه در طی اسپرینت‌ها به معنی چابک بودن نخواهد بود.

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

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

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

https://martinfowler.com/bliki/WaterfallProcess.html

@iranagile

❇️ مهم ترین اخبار رویداد NET Conf. با موضوع Focus on Blazor

دو روز پیش رویداد یک روزه دات نت کانف با محوریت تمرکز بر روی Blazor برگزار شد و اخبار و آموزش های جدید در اون منتشر شد از جمله :

🔶 معرفی امکانات جدید
امکانات جدیدی که قرار است تا ماه May به Blazor WebAssembly (همان Client-Side Blazor سابق) اضافه شود
https://gunnarpeipman.com/focus-on-blazor-announcements/

🔷 معرفی نمونه پروژه ای از ترکیب Blazor + Electron
که امکان ساخت برنامه های مدرن و سریع Desktop ایی به صورت Cross-Platform توسط Blazor و تکنولوژی های Web ایی را فراهم می سازد (توضیحات بیشتر)
ریپازیتوری گیتهاب :
https://aka.ms/blazorelectron

🔶معرفی نمونه پروژه ای از ترکیب Blazor + WebWindow
که امکان ساخت برنامه های مانند پروژه قبلی را فراهم می سازد با این تفاوت که سبک تر است و حجم کمتری دارد. WebWindow یک پروژه (در حال حاضرآزمایشی) است که توسط Steve Sanderson خالق Blazor ساخته شده و جایگزین الکترون برای برنامه‌های NET Core. خواهد شد و نسبت به الکترون سبک تر و کم حجم تر است.
https://aka.ms/webwindow

🔷معرفی پروژه Mobile Blazor Bindings
که امکان ساخت برنامه های Native موبایل را توسط Razor و #C و CSS فراهم می سازد. همچنین به کامپوننت های بومی موبایل مانند GPS و Media دسترسی دارد. در این روش از کامپوننت های مبنی بر Xamarin Forms استفاده می شود
اطلاعات بیشتر و نمونه اپ های ساخته شده
https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings-experiment/
https://docs.microsoft.com/en-us/mobile-blazor-bindings/
https://github.com/xamarin/MobileBlazorBindings

🔶امکان تست نویسی برای Blazor
قابلیت Unit Test نویسی برای کامپوننت های Blazor هم اکنون در حد نمونه اولیه پیاده سازی شده است و به زودی تکمیل می شود
اطلاعات بیشتر و ریپازیتوری کتابخانه مربوطه
https://blog.stevensanderson.com/2019/08/29/blazor-unit-testing-prototype/
https://github.com/egil/razor-components-testing-library

🔷کاهش حجم برنام های Blazor WebAssembly
توسط قابلیت Assembly trimming می توان حجم خروجی برنامه های Blazor WebAssembly را کاهش داد. به طور مثال حجم نسخه پیشفرض فعلی یک اپ Blazor WebAassembly حدود 2 مگابایت است که تیم Blazor وعده داده در انتشار ماه May سال جاری، حجم آن را تا 1.5 مگابایت کاهش دهد.
_______________
@DotNetZoom

#پست_مجدد این پست تا به حال بیش از ۲۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

EXACT INSTRUCTIONS

پیشنهاد می‌کنم اول فیلم رو ببنید بعد بقیه مطلب رو بخونید.

https://www.youtube.com/watch?reload=9&v=Ct-lOOUqmyY

خیلی جالب بود و در نگاه اول هیچ ربطی به نرم‌افزار و دنیای نرم‌افزار نداره. ولی وقتی یه خورده عمیق بشیم خیلی جالب میشه.

یکی از مهم‌ترین کارهایی که باید توی شرکت‌های نرم‌افزاری به درستی انجام بشه، داکیومنت کردن است. (داکیومنت به معنی کامنت گذاشتن داخل کد اصلا منظورم نیست، کد باید خودش به قدری خوانا باشه که نیاز به کامنت نداشته باشه یا به اصطلاح Self-Document باشه.)
داکیومنت کردن رو نباید به عنوان یه کار اضافه دید و سرسری انجامش داد.
تمام مراحل انتقال دانش باید به وسیله داکیومنت انجام بشه. نه به صورت نقل قول و سینه به سینه.

اتفاقی که برای خودم افتاد رو براتون تعریف می‌کنم:
در شرکت کرانه ادمین TFS بودم، و یکی از کارهایی که باید انجام می‌دادم و داکیومنت می‌کردم Disaster Recovery خود TFSبود. ۱ روز کامل وقت گذاشتم و Recovery رو انجام دادم و داکیومنتش رو نوشتم، کاری که مدیرمون کرد خیلی خوب بود. داکیومنت رو داد به یکی دیگه گفت TFS رو بیار بالا. حدس می‌زنید چی شد؟ نتونست، چون داکیومنتی که نوشته بودم به درد خودم می‌خورد.
و حرفی که به من زد این بود «داکیومنت باید طوری باشه که اگه دست یه نفر رو از توی خیابون گرفتم و این داکیومنت رو بهش دادم بتونه TFS رو بیاره بالا». بعد از ۳ بار داکیومنت نوشتن بالاخره موفق شدم داکیومنتی بنویستم که به هر کی بدمش فقط با Back up دیتا بیس بتونه TFS رو بالا بیاره.

به نظر من داکیومنت باید طوری باشه تا تمام کسانی که می‌خوننش، همشون یک برداشت رو داشته باشن، داکیومنت نباید وابسته به Context ذهن ما باشه.

خوشحال می‌شم نظر شما رو هم بدونم.

#افشین_علیزاده (http://ow.ly/l7cA30m3OQ9)

کانال تلگرام:
@SoftwarePhilosophy

___

دیزاین سیستم‌ها و آنچه باید در مورد آن‌ها بدانید.

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

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

یک دیزاین سیستم، منبعی قابل اتکا است که تمام المان‌های لازم برای طراحی، تحلیل و توسعه محصولات دیجیتال را ارائه کرده و فعالیت تیم‌ها در راستای طراحی محصول را تسهیل می‌کند.

به عنوان مثال می‌توان به دیزاین سیستم «Material» شرکت گوگل اشاره کرد که مجموعه‌ای از المان‌ها، کامپوننت‌ها، راهنماها و اصول و قواعد طراحی برای اپلیکیشن‌های بر پایه سیستم‌عامل اندروید است.

برای آشنایی بیشتر با دیزاین سیستم‌ها می‌توانید مقاله زیر را مطالعه کنید:

http://bit.ly/dxgn548-1

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

http://bit.ly/dxgn548-1

(زمان حدودی مطالعه: ۱۴ دقیقه)

نویسنده: محمدرضا پناهی

#دیزاین #دیزاین_سیستم

@Dexign فلسفه دیزاین


_______

تاریخچه اسکرام
چه اتفاقی افتاد که اسکرام معرفی شد؟

هر دو نفر خالق اسکرام در جنگ ویتنام از ۱۹۶۷ تا ۱۹۷۵ حضور داشتند. آقای جف سادرلند خلبان هواپیمای جنگنده بود.
درک آنها از عدم قطعیت در شرایط جنگ باعث شده بود که مفهوم پیچیدگی‌ را بهتر درک کنند. پس از اتمام جنگ هر کدام به شرکتهای نرم افزاری پیوستند اما درک کردند که روش مرسوم آن روزها که واترفال بود، با شرایط پیچیده و عدم قطعیت توسعه نرم افزار همخوان نیست.

آقای سادرلند در شرکتی در حوزه ATM های بانکی کار می‌کرد و دنبال بهبود شیوه کار بود که اتفاقی مقاله آقای تایچی اوهنو ژاپنی با عنوان The new new product development game را دید که این سرآغاز تولد اسکرام بود. در سال 1995 با همراهی کن شوئبر مقاله ای با عنوان اسکرام ارایه کردند.

داستان کامل را در لینک زیر مشاهده کنید

https://www.scrumdesk.com/the-history-of-scrum-how-when-and-why/

@iranagile

❇️ ساخت برنامه های gRPC بدون فایل های proto. در ASP.NET Core

🔰برای ساخت برنامه های gRPC در دات نت، 2 پیاده سازی متفاوت (یکی رسمی و دیگری غیر رسمی) وجود دارد

1️⃣ پیاده سازی grpc-dotnet (یا gRPC for .NET) که کتابخانه رسمی gRPC برای دات نت است
https://github.com/grpc/grpc-dotnet

2️⃣ پیاده سازی protobuf-net.Grpc که کتابخانه غیر رسمی و از توسط Marc Gravell (یکی از برنامه نویسان بزرگ سایت Stackoverflow، و نویسنده کتابخانه های محبوب Dapper و StackExchange.Redis) تهیه شده است
https://github.com/protobuf-net/protobuf-net.Grpc

🔸یکی از تفاوت های این دو کتابخانه این است که در حالت عادی (توسط grpc-dotnet) ساخت فایل های .proto جهت تعریف ساختار API الزامی است ولی توسط کتابخانه protobuf-net.Grpc نیازی به فایل های اضافی .proto نبوده و ساختار متد های سرویس دهنده توسط Interface ها مشخص می شوند.

🔹تفاوت دیگر آن این است که کتابخانه protobuf-net.Grpc تارگت های NETFramework 4.6.1. و NETStandard 2.0. و NETStandard 2.1. را پشتیبانی میکند در حالی که کتابخانه grpc-dotnet فقط NETStandard 2.1. را پشتیبانی میکند در نتیجه بر روی .NET Framework و .NET Core نسخه های قبل از 3.0 قابل اجرا نیست
- البته یک پیاده سازی رسمی دیگر (به نام gRPC for C#) نیز وجود دارد که از نسخه های قدیمی تر مانند NETFramework 4.5. و NETStandard 1.5. و NETStandard 2.0. هم پشتیبانی میکند
https://github.com/grpc/grpc/tree/master/src/csharp

🔸نکته بعدی، تفاوت در سرعت این دو کتابخانه است به صورتی که طبق بنچمارک زیر protobuf-net.Grp کمی کند تر از grpc-dotnet است
https://pawelkmiec.net/2019/11/17/gRPC-performance-benchmark.html

🔹تفاوت بعد آن این است که API های کتابخانه رسمی grpc-dotnet و #gRPC for C شبیه پیاده سازی اصلی grpc گوگل بوده در حالی که کتابخانه protobuf- net.Grpc بیشتر متمایل به Contract های سی شارپی بوده و کار با آن برای برنامه نویسان سی شارپ ساده تر و باب میل تر است


🔰 مشابه قضیه بالا، برای استفاده از protobuf در دات نت نیز 2 کتابخانه وجود دارد

1️⃣ کتابخانه Google.Protobuf : که پیاده سازی و استفاده از آن شبیه نسخه اصلی protobuf است. (ریپازیتوری گیتهاب)

2️⃣ کتابخانه protobuf-net : که پیاده سازی و استفاده از آن شبیه بقیه سریالایزر‌های دات نتی بوده و بیشتر متمایل به سی شارپ است. (ریپازیتوری گیتهاب)

کتابخانه دومی بیشتر باب میل سی شارپی‌ها بوده و نیز ساده تر است. با دیدن مثال هر دو کتابخانه میتوانید بهتر متوجه این تفاوت شوید.
لینک زیر هم به مقایسه این دو کتابخانه پرداخته :
How to choose between protobuf-csharp-port and protobuf-net


✅ آموزش استفاده از protobuf-net.Grpc
✔️Getting Started with protobuf-net.Grpc
✔️Mark Gravell Talking Between Services with gRPC and Other Tricks

✅ آموزش استفاده از grpc-dotnet و #gRPC for C
✔️Introduction to gRPC on .NET Core
✔️gRPC services with C#
✔️gRPC services with ASP.NET Core
✔️Call gRPC services with the .NET client
✔️Create a gRPC client and server in ASP.NET Core
✔️Trying out gRPC in ASP.NET Core 3

__________________
@DotNetZoom

#پست_مجدد این پست تا به حال بیش از ۴۲۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

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

http://mehrandvd.me/2016/03/28/linq-the-bad-parts/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilisophy



___

کسب رضایت مشتریان در طراحی بهتر خدمات پشتیبانی

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

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

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

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

در مقاله امروز نویسنده به شما کمک می‌کند تا نحوه ارائه خدمات به مشتریان را بهتر بشناسید و به معرفی برخی از موثرترین روش‌های جلب رضایت مشتریان می‌پردازد.

http://bit.ly/dxgn550

(زمان حدودی مطالعه: ۱۰ دقیقه)

نویسنده: نیما‌ حکیم‌رابط

#رضایت‌مشتری #طراحی‌خدمات

@Dexign فلسفه دیزاین


ــــــــ

❇️ مهمترین اخبار اخیر

✅ آپدیت ژانویه 2020 برای NET Core. منتشر شد

🔸بروز رسانی نسخه ها 2.1.15 و 3.0.2 و 3.1.1 به جهت رفع چند باگ امنیتی در مورد (Remote Code Execution و Denial of Service (حمله Dos)) منتشر شدند

🔹اگر از وِیژوال استادیو استفاده می کنید برای استفاده از آخرین بروزرسانیNET Core SDK. ورژن 3.1.x به نسخه Visual Studio 2019 نسخه 16.4.x به بالا نیاز خواهید داشت

دانلود NET Core SDK. نسخه 3.1.1
https://dotnet.microsoft.com/download/dotnet-core/3.1
توضیحات بیشتر
https://devblogs.microsoft.com/dotnet/net-core-january-2020/

✅ پایان پشتیبانی از Windows 7 و. Windows Server 2008 و Windows Server 2008 R2

از این پس ویندوز های قبلی همچنان قابل استفاده خواهند بود ولی دیگر بروز رسانی های امنیتی را دریافت نخواهند کرد و در برابر آسیب پذیری های جدید ایمن نخواهند بود

✅ نسخه نهایی مرورگر Edge مبتنی بر Chromium منتشر شد
ماکروسافت نسخه پایدار Edge جدید را برای سیستم عامل های Windows و Mac منتشر کرد. کاربران به زودی یک آپدیت برای Windwos 10 دریافت خواهند کرد که مرورگر Edge با آن نصب خواهد شد. ماکروسافت مدعی شده این مرورگر از Chrome سبک تر بوده و Memory کمتری مصرف میکند.
لینک دانلود
https://www.microsoft.com/en-us/edge
من که نصب کردم پیشنهاد میکنم شما هم امتحان کنین و نظرتونو بگین 😉✌️
_______________
@DotNetZoom

#خبر

انگولار 9.0.0، هم بلاخره بعد از مدتها انتظار منتشر شد! 🎉🥳

از اینجا می توانید آخرین تغییرات را مشاهده کنید.
🔗 https://github.com/angular/angular/blob/master/CHANGELOG.md

@Angular_Iran
—
#angular9

دوستانت را نزدیک و رقبایت را نزدیک‌تر نگه دار!

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

اگر رقیبی برای پروژه و یا محصول شما وجود نداشته باشد، ممکن است دلیل آن کم اهمیت بودن مشکلی باشد که قصد ارائه راه‌حل برای آن را دارید. یا مشکل مورد نظر آنقدر غیرمعمول است که نیازی به ارائه راه‌حل مختص آن نباشد. پس تحلیل رقبا از اهمیت بالایی برخوردار است.

رقبای شما به دو دسته مستقیم و غیرمستقیم تقسیم می‌شوند. رقبای مستقیم آن‌هایی هستند که هدف و محصولشان مشابه هدف و محصول شماست. مثلا هنگامی که می‌خواهید یک سرویس ایمیل طراحی کنید، رقبای مستقیم شما Gmail، Yahoo mail و سرویس‌های اینچنینی هستند. از طرفی دیگر رقبای غیرمستقیم رقبایی هستند که برخی ابزارها و روند‌های آن‌ها مشابه محصول شماست. مثلا نحوه ثبت‌نام و ایجاد حساب کاربری در محصولات مختلف در مقایسه با این روند در محصول شما.

هنگام تحلیل رقبا برای جلوگیری از افزایش حجم داده‌ها و پیچیده شدن روند تحلیل، پیشنهاد می‌شود به بررسی ۵ الی ۱۰ رقیب پرداخته شود و برای این کار از قانون ۸۰/۲۰ استفاده شود. یعنی ۸۰ درصد آن‌ها رقبای مستقیم و ۲۰ درصدشان غیرمستقیم باشند.

تحلیل رقبا روش مناسب برای شناخت و تحلیل مشکلات کاربر و ارائه‌ی راه حلی بهینه برای آن است. برای شناخت بیشتر این روش و اهمیت آن پیشنهاد می‌کنیم مقاله زیر را مطالعه کنید:

http://bit.ly/dxgn552

(زمان حدودی مطالعه: ۶ دقیقه)

نویسنده: محمدرضا پناهی

#تجربه_کاربری #تحلیل_رقابتی

@Dexign فلسفه دیزاین


ــــــــ

#پست_مجدد این پست تا به حال نزدیک به ۵۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

تئوری اسب مرده!

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

یک ضرب‌المثل قدیمی هندی می‌گوید: اگه دیدین سوار یه اسب مرده هستید، بهترین استراتژی اینه که پیاده شین.

در حالی که معمولا استراتژی‌های پیشرفته‌تری در دولت‌ها، شرکت‌ها، سیستم‌های آموزشی و ... استفاده می‌شود. این استراتژی‌ها حتما برای شما هم آشنا هستند:

- یه شلاق سنگین‌تر بخریم!
- سوارکار رو عوض کنیم!
- یک کمیته تشکیل بدیم تا اسب رو بررسی کنیم!
- کشورهای دیگر رو ببینیم که تو فرهنگشون چطوری با اسب مرده سوارکاری می‌کنن!
- استانداردهای زنده موندن رو پایین بیاریم تا این اسب هم زنده محسوب بشه!
- در طبقه‌بندی جدید اسب‌ها، این اسب رو در دسته «زنده آسیب‌دیده» قرار بدیم!
- با افرادی قرارداد ببندیم که سوارکاری اسب رو انجام بدن!
- چند اسب مرده دیگه رو هم با هم افسار بزنیم تا سرعت بیشتر بشه!
- پول بیشتری خرج کنیم و به اسب مهارت‌های لازم رو آموزش بدیم تا کاراییش بیشتر بشه!
- تحقیق کنیم ببینیم تاثیر یک سوارکار لاغرتر روی بالارفتن سرعت اسب چقدره!
- قانونی وضع کنیم که به اسب‌های مرده غذا ندهیم. این از لحاظ اقتصادی بسیار به صرفه است و باعث می‌شه این اسب‌ها حتی از بقیه اسب‌ها بیشتر به نفع اقتصاد باشند!
- مستند «معیارهای کارایی اسب» رو بازنویسی کنیم که قاعدتا شامل این اسب هم می‌شه، تا خودش متوجه بشه!
- اسب مرده رو به یک پست مدیریتی ارتقا بدیم!

مفهومی که هنگام خواندن این ضرب‌المثل تداعی می‌شود، مفهوم Root Cause است. اغلب مشکلاتی که در اطراف ما وجود دارد دارای دلایل واضح و سطحی است که غالبا منجر به حل آن مشکل نمی‌شود. از طرفی، اگر تلاش کنید برای یک مشکل عمیق فکر کنید و به Root Cause آن برسید، مشکلات به طور عجیبی حل می‌شوند و حتی با حل یک مشکل، مشکلات دیگری نیز خود به خود حل می‌شوند.

در پست زیر از بلاگم در مورد این مفهوم صحبت کردم.

http://mehrandvd.me/2018/06/27/the-dead-horse-theory/


⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

http://ow.ly/AGJa30kQv8N

#مهران_داودی (http://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

چگونه یک نیروی جدید به تیم اضافه کنیم.

ویدئویی که می‌بینید یه ایستگاه قطاره که توش یه پیانو گذاشتن که هر کسی خواست بشینه و بزنه.
یه آقایی نشسته و داره پیانو می‌زنه که یه نفر دیگه هم بهش اضافه می‌شه و کمکش می‌کنه و هماهنگی‌شون فوق‌العاده می‌شه.

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

به نظرم این مدل برای تیم‌های نرم‌افزاری و تیم‌های استارتاپی که در حال scale کردن هستن، کاملا الگوی مناسبیه.

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#مهران_داودی (http://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy

___

ابزارهای دورکاری تیم های چابک

با توجه به اینکه آموزه های چابک، بیشتر تاکید دارند که ارتباطات چهره به چهره باشه ولی خود چابکی به ما یاد داده که باید به تغییرات پاسخگو باشیم. برای همین بهترین استراتژی الان کشور دور کاری و ریموت هست.
ولی تیم ها با استفاده از ابزارهای مناسب میتوانند چابکی خود را همچنان در دور کاری نیز حفظ نمایند:

29 ابزار برای دورکاری تیم های چابک
https://luis-goncalves.com/tools-distributed-agile-retrospectives/

صدایم را بشنو

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

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

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

جسیکا پاول، معاون سابق گوگل، درباره قدرت شنیده شدن در جلسات مقاله‌ای برپایه تجربیات خودش نوشته است.
خواندن این مقاله، به دلیل واقعی بودن موقعیت‌هایی که به آن اشاره شده، می‌تواند بسیار موثر واقع شود.

اگر شما هم تجربیات مشابهی در این زمینه دارید، در بخش نطرات، آنها را با ما به اشتراک بگذارید.


http://bit.ly/dxgn554


(زمان حدودی مطالعه: ۱۰ دقیقه)

نویسنده: آرش اصغری

#تجربه #رفتارشناسی #جلسه

@Dexign فلسفه دیزاین



______

#پست_مجدد این پست تا به حال بیش از ۹۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.

تفاوت بین Site Reliability Engineering و Engineering DevOps مطلب جالبی‌ست. با آنکه با هم تفاوت دارند اما شبیه به هم هستند. اگر بخواهیم با دنیای OOP مقایسه کنیم SRE شبیه کلاس‌ها است و DevOps شبیه اینترفیس‌ها . SRE روابط بین دپارتمان‌های تولید و عملیات را به لحاظ همکاری و به اشتراک گذاری داده ها تنظیم می‌کند .

لینک زیر تفاوت این دو را به خوبی بیان می‌کند :

https://www.bmc.com/blogs/sre-vs-devops/

#شهریار_انتظام (http://ow.ly/qDN430nPiCg)

کانال تلگرام:
@SoftwarePhilosophy

___