بازی و دیزاین، بازی و زندگی

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

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

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

اگر به دنبال دلایلی می‌گردید که مدیر خود را قانع کنید تا هرروز بازی کنید، مقاله امروز را از دست ندهید.

https://uxdesign.cc/warm-ups-in-design-thinking-more-than-just-a-game-7f755fcc8497

(زمان حدودی مطالعه، ۷ دقیقه)

#معرفی #بازی #تیم
@Dexign فلسفه دیزاین

___

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

پروژه یا محصول؟ مدیر پروژه یا مدیر محصول؟

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

شما در حال توسعه کدام یک هستید؟ محصول یا پروژه؟

https://www.brainmates.com.au/brainrants/project-manager-vs-product-manager

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

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



___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. قرار دادن فایل‌های PDF در دیتابیس (SQL Server)

https://t.me/SoftwarePhilosophy/1267

۲. نحوه انتخاب متدولوژی مناسب برای پروژه نرم‌افزاری

https://t.me/SoftwarePhilosophy/1269

۳. چگونه تصمیمات در سطح معماری و کلان پروژه را مستند کنیم؟ (Iran Agile)

https://t.me/SoftwarePhilosophy/1270

۴. ماکروسافت گیت هاب را خرید (Asp.Net Mvc)

https://t.me/SoftwarePhilosophy/1271

۵. بازی و دیزاین، بازی و زندگی (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1272

۶. پروژه یا محصول؟ مدیر پروژه یا مدیر محصول؟

https://t.me/SoftwarePhilosophy/1274

ـــــــــــ

@SoftwarePhilosophy

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

در سیستم‌هایی که پردازش درخواست‌ها روی منابع مشترک انجام می شود. انجام ترتیبی درخواست‌ها به روش قفل گذاری (Locking) رایج‌ترین روش جلوگیری از همزمانی است. دو دیدگاه برای قفل گذاری وجود دارد. خوشبینانه (Optimistic) و بدبینانه (Pessimistic) و هنر معمار یا طراح نرم افزار، انتخاب روش مناسب برای رفع همزمانی است. مقاله زیر توضیح می‌دهد چطور شناخت دقیق کسب و کار، معرف روش قفل گذاری خواهد بود.


https://goo.gl/G8SyJU

#مهدی_نظری

لینکدین
https://ir.linkedin.com/in/mohammad-mahdi-nazari-90097b58

توییتر
https://twitter.com/ShamehdiN

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


___

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

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

http://www.cio.com/article/2436015/enterprise-architecture/5-things-grady-booch-has-learned-about-complex-software-systems.html

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

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


___

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

دیتابیس‌های NoSQL امروزه در معماری‌های نوین نرم‌افزار جایگاه ویژه‌ای پیدا کرده‌اند. در سال‌های قبل از این نوع دیتابیس‌ها فقط در پروژه‌های خاصی استفاده می‌شد ولی به مرور نقش این نوع دیتابیس‌ها با ظهورمعماری‌های نوین یا مفاهیمی مانند CQRS پر رنگ تر شده‌است. مفاهیم این دیتابیس‌ها به طور کلی با مدل فکری دیتابیس‌های رابطه‌ای یا Relational متفاوت است.

http://www.c-sharpcorner.com/article/introduction-to-no-sql-and-working-with-mongodb-part-one/

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

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


___

🔵 هرچیز مهم به ندرت فوریت دارد و هر چیز فوری به ندرت مهم است

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

یک مالک محصول خوب باید بتواند در اولویت بندی کارها هم فوریت و هم اهمیت کارها را در نظر بگیرد.

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

http://bit.ly/2JOKK82
@iranagile

درباره Titanها بیشتر بدانیم!

چطور می‌شود که تایتان‌ها انقدر قوی باشند؟ اگر در جریان سری کامیک‌ها و فیلم‌های Marvel باشید می‌دانید که اخیرا جنگی به نام Infinity War در دنیای Marvel به راه افتاده است. یک طرف این جنگ Thanos، از نژاد تایتان‌ها قرار دارد و در طرف دیگر آن، Capitan America، Iron Man و Thor و حتی Hulk و باقی Avengers! و با این‌حال نگران هستند که مبارزه را واگذار کرده و این اتفاق، نقطه پایانی باشد برای نسل تمام موجودات زنده در دنیا.

برای اطلاع بیشترتان می‌خواهم چند ویژگی تایتان‌ها را نام ببرم: ذهن و پوستی غیرقابل نفوذ؛ قدرت،‌ سرعت و استقامتی منحصربفرد؛ کنترل انرژی؛ نامیرا بودن و …
هیجان‌انگیزست نه؟ گذشته از توضیحات دنیای Marvel که دلیل قدرت تایتان‌ها را ترکیب شدن ژن جاودانی، تکثیر بیونیک، قدرت‌های خدایی و نهاد مرگ می‌داند، تایتان‌های دنیای واقعی چه کسانی هستند؟ چگونه دیزاینرها هم می‌توانند درون خود تایتانی داشته باشند؟

آقای Tim Ferriss، یکی از سرمایه‌گذاران موفق دنیای استارتاپ‌ها، کتابی درباره موفق‌ترین و قدرتمند‌ترین انسان‌های دنیای واقعی با نام «ابزارهای تایتان‌ها» یا Tools of Titans منتشر کرده‌ست. Tim در یادداشتی، از تجربیاتش در برخورد با این انسان‌های فوق موفق نوشته‌ست که پست امروز ماست.
جدای از اینکه خواندن کتاب ایشان را شدیدا پیشنهاد می‌کنم، مقاله امروز به کلیدی‌ترین ویژگی تمامی این افراد اشاره دارد و آن «ورزش و تمرین ذهن» است.

می‌پرسید دقیقا چگونه؟ مقاله امروز را از دست ندهید:

https://medium.com/the-mission/the-one-routine-common-to-billionaires-icons-and-world-class-performers-28ed11a49eda

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

پ. ن.
تریلر فیلم Avengers: Infinity War، محصولی از کمپانی Marvel:
https://www.youtube.com/watch?v=I0e3TXkSd4Q

#بررسی #ابزار_تایتان #موفقیت_خلاقیت
@Dexign فلسفه دیزاین

___

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

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

http://mehrandvd.me/2016/05/02/steady-consistent-flow-features/

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

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



___

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

اصطلاح Full Stack Developer عبارتی است که در چند سال اخیر بسیار رایج شده‌است. این برنامه‌نویسان معمولا درک خوبی از برنامه‌نویسی، زیرساخت، طراحی و حتی فهم بیزنس‌ها دارند. چند سالی هم هست که «متخصص UX» به عنوان یک تخصص مهم در تیم‌ها جا افتاده است. مقاله زیر اصطلاح جدیدی را با عنوان Full Stack UXer را معرفی می‌کند و نشان می‌دهد که این نقش و تخصص در یک تیم چقدر می‌تواند به موفقیت کمک کند. در این مقاله تخصص‌هایی که از یک Full Stack UXer انتظار می‌رود توضیح داده شده است. در این تعریف معمولا این فرد بیشتر درگیر تخصص‌های زیادی خواهد بود که از Gamification تا حتی برنامه‌نویسی را شامل می‌شود.

مقاله زیر تجربه تعریف و استفاده از نقش توضیح داده شده است.

http://uxmag.com/articles/the-full-stack-uxer

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

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



___

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

نوشتن یک رزومه خوب برای پست‌های برنامه‌نویسی و یا UI/UX بسیار مهم است. رزومه باید بتواند قابلیت‌های شما را در یک تعامل ذهنی به خواننده منتقل کند. شما باید بتوانید در رزومه خود، یک خط پنهان طراحی کنید تا کسی که رزومه شما را می‌خواند ناخودآگاه به ترتیبی که شما می‌خواهید رزومه شما را ببیند. به عبارت دیگر، اگر برای پست UI/UX رزومه می‌نویسید باید در آن اصول UI/UX را رعایت کنید.

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

http://www.rleonardi.com/interactive-resume

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

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



___

چهار موردی که کاربران بخاطرشان از شما متنفرند!

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

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

در مقاله امروز به نقل از سرویس طراحی Justinmind به بررسی نتایج بدست آمده در این نظرسنجی می‌پردازیم.

مقاله امروز را از دست ندهید:

https://uxplanet.org/what-users-hate-most-about-your-app-according-to-google-c4a089ddfafa

(زمان حدودی مطالعه، ۷ دقیقه)

#بررسی #نظرسنجی #مشکلات_اپلیکیشن
@Dexign فلسفه دیزاین

___

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

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

http://www.c-sharpcorner.com/article/managing-technical-debt-using-vsts

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

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



___