Forwarded from Iran Agile
ژاپن برای واکسیناسیون کوید-19 از متد تویوتا استفاده میکند
متد تویوتا در واقع راه روش شرکت خودروسازی تویوتا است که در کشورهای غربی معمولا با عنوان ناب شناخته می شود. در واقع اساس این متد بر از بین بردن اتلافات و افزایش بازدهی هست. بازدهی که در راستای خلق ارزش هست، مثلا انتظار کم برای کسانی که میخواهند واکسن بزنند.
اینکه چگونه این متد برای افزایش بازدهی طرح واکسیناسیون استفاده شده بسیار جالب هست
https://mainichi.jp/english/articles/20210609/p2a/00m/0bu/022000c
@iranagile
متد تویوتا در واقع راه روش شرکت خودروسازی تویوتا است که در کشورهای غربی معمولا با عنوان ناب شناخته می شود. در واقع اساس این متد بر از بین بردن اتلافات و افزایش بازدهی هست. بازدهی که در راستای خلق ارزش هست، مثلا انتظار کم برای کسانی که میخواهند واکسن بزنند.
اینکه چگونه این متد برای افزایش بازدهی طرح واکسیناسیون استفاده شده بسیار جالب هست
https://mainichi.jp/english/articles/20210609/p2a/00m/0bu/022000c
@iranagile
Forwarded from فلسفه دیزاین
اختیار از دست رفته؛
چگونه محصولات دیجیتال را انسانیتر کنیم!
برخلاف ادعای انسان محور بودن محصولات، اتفاقا بیشتر تمرکز شرکتها روی منفعتهاییست که میتوانند از کاربرانشان دریافت کنند و کمتر به فکر این هستند که واقعا چه چیزی را میتوانند برای آنها عرضه کنند.
محصولات دیجیتال تمام زمان و توجه ما را اشغال کردهاند، طوری که به سختی میتوانیم از آنها دل بکنیم. هیچ وقت احساس کافی بودن به ما دست نمیدهد و ما خود را بیشتر و بیشتر خرج آنها میکنیم. این سرویسها و محصولات دیجیتال حریصند و نیازمند تمام اطلاعات ما هستند، عکسها، فیلمها، جملات، دوستان و خانه و زندگی ما را طلب میکنند. ما تمامی این اطلاعات را در اختیار این محصولات دیجیتال قرار میدهیم چون آنها به ذات مفید هستند. اما این حس سودمندی برای انسان به تنهایی کافی نیست.
احتمالا اغلب اوقات با این حس افسردگی، ناامیدی و خستگی هنگام تعامل با این اپلیکیشنها مواجه شدهاید. ما دوست داریم در برخورد با تکنولوژی احساس اختیار و قدرت بکنیم و به کلی این موضوع را فراموش کردهاییم که سودمندی با توانمندی و اختیار یکسان نیست.
توانمندسازی در انسان بدین معنی است که او احساس مطمئن و دلگرمی از کنترل کردن زندگی خود داشته باشد. و این موضوع اصلا اولویتی در تکنولوژی حال حاضر ندارد و برعکس آن در حال اتفاق افتادن است.
تمامی اطلاعات ما در حال واکاوی ، استخراج و تحت تحلیلهای مختلفی بدون شفافیت قرار دارد. ما با دریایی از نوتیفیکیشنها در گوشی همراه خود مواجهاییم. تمامی انتخابهای ما در دنیای دیجیتال کاملا دیکتهشده طبق الگوریتمهای تبلیغاتی قرار دارد.
ما از تکنولوژی این را میخواهیم که توانایی ما را تقویت کند به ما قدرت اختیار بدهد، بدون اینکه چیزی را به ما دیکته کند. بهترین مثالی که میتوان دراینباره زد، اتوموبیل است، سفر کردن انسانها را با یک پیشرفت چشمگیر روبرو کرده است. ما زمانی که به آن نیاز داریم سراغ آن میرویم و وقتی نیازی به آن نداریم برخلاف اپلیکیشنهای سمج هیچ اصراری به ما نمیکند و کاملا از دید ما پنهان است. برای انسان کار میکند، به او گوش میدهد. و هیچگونه مزاحمتی برای او ایجاد نمیکند.
در مقالات زیر با انواع ربایشهای اطلاعاتی، غصب زمان ارزشمند انسانها و راهحلهای اخلاقی تبدیل دیزاینهای شما به محصولات توانمند آشنا میشوید. امیدوارم که به خوبی آنها را مطالعه کنید و هنگام دیزاین از آنها بهره ببرید.
http://bit.ly/dxgn693-1
http://bit.ly/dxgn693-2
http://bit.ly/dxgn693-3
(زمان حدودی مطالعهی مقالهی اول: ۱۷ دقیقه،
مقالهی دوم: ۸ دقیقه
و مقالهی سوم: ۱۰ دقیقه)
نویسنده: حسین میرزاده
#تجربه_کاربری #روانشناسی #تکنولوژی #دیزاین_اخلاقی #انسان_محور
@Dexign فلسفه دیزاین
______
چگونه محصولات دیجیتال را انسانیتر کنیم!
برخلاف ادعای انسان محور بودن محصولات، اتفاقا بیشتر تمرکز شرکتها روی منفعتهاییست که میتوانند از کاربرانشان دریافت کنند و کمتر به فکر این هستند که واقعا چه چیزی را میتوانند برای آنها عرضه کنند.
محصولات دیجیتال تمام زمان و توجه ما را اشغال کردهاند، طوری که به سختی میتوانیم از آنها دل بکنیم. هیچ وقت احساس کافی بودن به ما دست نمیدهد و ما خود را بیشتر و بیشتر خرج آنها میکنیم. این سرویسها و محصولات دیجیتال حریصند و نیازمند تمام اطلاعات ما هستند، عکسها، فیلمها، جملات، دوستان و خانه و زندگی ما را طلب میکنند. ما تمامی این اطلاعات را در اختیار این محصولات دیجیتال قرار میدهیم چون آنها به ذات مفید هستند. اما این حس سودمندی برای انسان به تنهایی کافی نیست.
احتمالا اغلب اوقات با این حس افسردگی، ناامیدی و خستگی هنگام تعامل با این اپلیکیشنها مواجه شدهاید. ما دوست داریم در برخورد با تکنولوژی احساس اختیار و قدرت بکنیم و به کلی این موضوع را فراموش کردهاییم که سودمندی با توانمندی و اختیار یکسان نیست.
توانمندسازی در انسان بدین معنی است که او احساس مطمئن و دلگرمی از کنترل کردن زندگی خود داشته باشد. و این موضوع اصلا اولویتی در تکنولوژی حال حاضر ندارد و برعکس آن در حال اتفاق افتادن است.
تمامی اطلاعات ما در حال واکاوی ، استخراج و تحت تحلیلهای مختلفی بدون شفافیت قرار دارد. ما با دریایی از نوتیفیکیشنها در گوشی همراه خود مواجهاییم. تمامی انتخابهای ما در دنیای دیجیتال کاملا دیکتهشده طبق الگوریتمهای تبلیغاتی قرار دارد.
ما از تکنولوژی این را میخواهیم که توانایی ما را تقویت کند به ما قدرت اختیار بدهد، بدون اینکه چیزی را به ما دیکته کند. بهترین مثالی که میتوان دراینباره زد، اتوموبیل است، سفر کردن انسانها را با یک پیشرفت چشمگیر روبرو کرده است. ما زمانی که به آن نیاز داریم سراغ آن میرویم و وقتی نیازی به آن نداریم برخلاف اپلیکیشنهای سمج هیچ اصراری به ما نمیکند و کاملا از دید ما پنهان است. برای انسان کار میکند، به او گوش میدهد. و هیچگونه مزاحمتی برای او ایجاد نمیکند.
در مقالات زیر با انواع ربایشهای اطلاعاتی، غصب زمان ارزشمند انسانها و راهحلهای اخلاقی تبدیل دیزاینهای شما به محصولات توانمند آشنا میشوید. امیدوارم که به خوبی آنها را مطالعه کنید و هنگام دیزاین از آنها بهره ببرید.
http://bit.ly/dxgn693-1
http://bit.ly/dxgn693-2
http://bit.ly/dxgn693-3
(زمان حدودی مطالعهی مقالهی اول: ۱۷ دقیقه،
مقالهی دوم: ۸ دقیقه
و مقالهی سوم: ۱۰ دقیقه)
نویسنده: حسین میرزاده
#تجربه_کاربری #روانشناسی #تکنولوژی #دیزاین_اخلاقی #انسان_محور
@Dexign فلسفه دیزاین
______
Medium
How Technology is Hijacking Your Mind — from a Magician and Google Design Ethicist
Where does technology exploit our minds’ weaknesses?
Forwarded from Iran Agile
هفت نکته مهم برای تصمیم های بهتر محصول
معمولا همه ما علاقه داریم یا حداقل شنیدیم که بهتر است تصمیم های مرتبط با محصول به صورت تعاملی گرفته شود، اما این همیشه آسان نیست، یا مدیران از نفوذ جایگاه خود برای پر رنگ کردن نظرات خودشان استفاده می کنند یا بعضا دچار آشوب در جلسات می شویم که تصمیم گیری انجام نمی شود. در زیر نکاتی گفته شده است که میتواند به شما در پروسه تصمیم گیری تعاملی با تیم توسعه یا ذینفعان کمک کند.
1- باید بدانیم چه زمانی تیم توسعه و ذینفعان را در تصمیم گیری مشارکت بدهیم: اصولا همیشه لازم نیست هر تصمیمی به صورت مشارکتی گرفته شود، تشخیص زمان درست بسیار مهم است. از بعد اجرایی، ذینفعان و تیم های توسعه دهنده را در تصمیماتی که بر استراتژی محصول و نقشه راه محصول تأثیر می گذارد، درگیر کنید.
2- افراد درست را دوره هم جمع کنید: برخی مواقع ما تصمیم جمعی با افراد اشتباه میگیریم
3- در جلسات حتما یک تسهیل گر با تجربه داشته باشید، کسی بتواند جلسه را با مهارت شروع، باز کرده و بتواند به سمت جمع بندی هدایت کند. این میتواند توسط یک اسکرام مستر اتفاق بیفتد.
4- خودتان تعاملی بودن را در عمل نشان بدهید، برخی افراد عادت دارند، جلسه را در دست بگیرند و نگذارند دیگران صحبت کنند، شما با نشان دادن گوش دادن فعال، سوال پرسیدن، .... میتوانید بقیه را به تعامل به جای رقابت در جلسه دعوت کنید. کسی قرار نیست برنده جلسه باشد.
5- در مورد شیوه تصمیم گیری توافق کنید، 1- اتفاق نظر: همه با راه حل پیشنهادی موافق هستند و از تأیید آن خوشحال هستند. 2- رضایت: هیچ کس اعتراض معناداری ندارد. 3- اکثریت: بیش از نیمی از افراد ملزم به توافق با راه حل پیشنهادی هستند. 4- متخصص محصول پس از شنیدن بحث، تصمیم می گیرد: هنگامی که همه شنیده شدند و درک مشترکی از ایده های مختلف ایجاد شد، مثلا مدیر محصول تصمیم می گیرد.
6- برای تصمیم های مهم عجله نکنید، شاید در چند جلسه این تصمیم گیری باید انجام شود.
7- از دیتا بعنوان پشتیبان تصمیم گیری استفاده کنید. داده های مرتبط را جمع آوری کنید و از آنها برای تصمیم گیری استفاده کنید.
بیشتر بخوانید
https://www.romanpichler.com/blog/tips-for-deciding-with-stakeholders-and-dev-teams/
@iranagile
معمولا همه ما علاقه داریم یا حداقل شنیدیم که بهتر است تصمیم های مرتبط با محصول به صورت تعاملی گرفته شود، اما این همیشه آسان نیست، یا مدیران از نفوذ جایگاه خود برای پر رنگ کردن نظرات خودشان استفاده می کنند یا بعضا دچار آشوب در جلسات می شویم که تصمیم گیری انجام نمی شود. در زیر نکاتی گفته شده است که میتواند به شما در پروسه تصمیم گیری تعاملی با تیم توسعه یا ذینفعان کمک کند.
1- باید بدانیم چه زمانی تیم توسعه و ذینفعان را در تصمیم گیری مشارکت بدهیم: اصولا همیشه لازم نیست هر تصمیمی به صورت مشارکتی گرفته شود، تشخیص زمان درست بسیار مهم است. از بعد اجرایی، ذینفعان و تیم های توسعه دهنده را در تصمیماتی که بر استراتژی محصول و نقشه راه محصول تأثیر می گذارد، درگیر کنید.
2- افراد درست را دوره هم جمع کنید: برخی مواقع ما تصمیم جمعی با افراد اشتباه میگیریم
3- در جلسات حتما یک تسهیل گر با تجربه داشته باشید، کسی بتواند جلسه را با مهارت شروع، باز کرده و بتواند به سمت جمع بندی هدایت کند. این میتواند توسط یک اسکرام مستر اتفاق بیفتد.
4- خودتان تعاملی بودن را در عمل نشان بدهید، برخی افراد عادت دارند، جلسه را در دست بگیرند و نگذارند دیگران صحبت کنند، شما با نشان دادن گوش دادن فعال، سوال پرسیدن، .... میتوانید بقیه را به تعامل به جای رقابت در جلسه دعوت کنید. کسی قرار نیست برنده جلسه باشد.
5- در مورد شیوه تصمیم گیری توافق کنید، 1- اتفاق نظر: همه با راه حل پیشنهادی موافق هستند و از تأیید آن خوشحال هستند. 2- رضایت: هیچ کس اعتراض معناداری ندارد. 3- اکثریت: بیش از نیمی از افراد ملزم به توافق با راه حل پیشنهادی هستند. 4- متخصص محصول پس از شنیدن بحث، تصمیم می گیرد: هنگامی که همه شنیده شدند و درک مشترکی از ایده های مختلف ایجاد شد، مثلا مدیر محصول تصمیم می گیرد.
6- برای تصمیم های مهم عجله نکنید، شاید در چند جلسه این تصمیم گیری باید انجام شود.
7- از دیتا بعنوان پشتیبان تصمیم گیری استفاده کنید. داده های مرتبط را جمع آوری کنید و از آنها برای تصمیم گیری استفاده کنید.
بیشتر بخوانید
https://www.romanpichler.com/blog/tips-for-deciding-with-stakeholders-and-dev-teams/
@iranagile
Forwarded from فلسفه دیزاین
سیستمهایی پویا برای تحول تیم
سیستمهای طراحی (Design System) مدتهاست که وجود دارند، این سیستمها نه فقط برای طراحی یک مورد خاص بلکه برای طراحی مجموعهای کامل از عناصر با حفظ یکپارچگی ظاهر و حس آنها بهوجود آمدهاند.
دیزاین سیستمها ابتدا به عنوان راهنمای استانداردی برای اسفتاده از علائم و کتابهای تجاری ساخته و بعداً با چارچوبهای CSS وارد وب شد، مانند بوت استرپ ( Bootstrap) معروف توییتر، که مجموعه ای از عناصر UI مانند تایپوگرافی، دکمه ها و لیست های کشویی را ارائه میداد.
متد طراحی اتمی (Atomic Design) باعث محکمتر شدن آنها شد و با Google Material Design استانداردها و دستورالعملهایی را تصویب کردند.
امروزه تعداد زیادی از شرکتها در حال ساخت سیستمهای طراحی اختصاصی خود هستند تا با رشد محصولات خود همچنان از ثبات و سازگاری برخوردار باشند و در عینحال مقیاسگذاری را نیز برای آنها آسانتر کند. HubSpot Canvas، زبان تصویری Airbnb ،Polaris از Shopify و Lightning از Salesforce چند نمونه عالی از این دیزاین سیستمهاست.
اما واقعیت این است که اگرچه سیستمهای طراحی مفید هستند و کار طراحان و توسعه دهندگان را آسانتر میکنند ، اما ساخت آنها بسیار دشوار است، زیرا افراد و فرایندهای بسیاری را شامل میشوند.
نویسنده این مقاله تلاش کرده است تا تجربیات مفید خود درباره ساختن و راهاندازی سیستمهای طراحی در تیم را با ما در میان بگذارد.
http://bit.ly/dxgn699
(زمان حدودی مطالعه: ۵ دقیقه)
نویسنده: فیروزه ایمانی
#دیزاین #دیزاین_سیستم
@Dexign فلسفه دیزاین
______
سیستمهای طراحی (Design System) مدتهاست که وجود دارند، این سیستمها نه فقط برای طراحی یک مورد خاص بلکه برای طراحی مجموعهای کامل از عناصر با حفظ یکپارچگی ظاهر و حس آنها بهوجود آمدهاند.
دیزاین سیستمها ابتدا به عنوان راهنمای استانداردی برای اسفتاده از علائم و کتابهای تجاری ساخته و بعداً با چارچوبهای CSS وارد وب شد، مانند بوت استرپ ( Bootstrap) معروف توییتر، که مجموعه ای از عناصر UI مانند تایپوگرافی، دکمه ها و لیست های کشویی را ارائه میداد.
متد طراحی اتمی (Atomic Design) باعث محکمتر شدن آنها شد و با Google Material Design استانداردها و دستورالعملهایی را تصویب کردند.
امروزه تعداد زیادی از شرکتها در حال ساخت سیستمهای طراحی اختصاصی خود هستند تا با رشد محصولات خود همچنان از ثبات و سازگاری برخوردار باشند و در عینحال مقیاسگذاری را نیز برای آنها آسانتر کند. HubSpot Canvas، زبان تصویری Airbnb ،Polaris از Shopify و Lightning از Salesforce چند نمونه عالی از این دیزاین سیستمهاست.
اما واقعیت این است که اگرچه سیستمهای طراحی مفید هستند و کار طراحان و توسعه دهندگان را آسانتر میکنند ، اما ساخت آنها بسیار دشوار است، زیرا افراد و فرایندهای بسیاری را شامل میشوند.
نویسنده این مقاله تلاش کرده است تا تجربیات مفید خود درباره ساختن و راهاندازی سیستمهای طراحی در تیم را با ما در میان بگذارد.
http://bit.ly/dxgn699
(زمان حدودی مطالعه: ۵ دقیقه)
نویسنده: فیروزه ایمانی
#دیزاین #دیزاین_سیستم
@Dexign فلسفه دیزاین
______
Medium
Raising a Design System in a team
The challenges of building a Design System together.
در این سری صحبتها در کلابهاوس قراره در مورد مفاهیم مرتبط با «ساخت تیمهای نرمافزاری صحبت کنیم.
موضوع این هفته «علل شکست پروژههای نرمافزاری» هست.
خوشحال میشیم در این گفتگو همراه ما باشین.
آدرس روم: https://www.clubhouse.com/join/peachak-co/tE7ztfzO/mWLnQqVa
آدرس کلابهاوس: https://www.clubhouse.com/@mehrandvd
کانال فلسفه نرمافزار @SoftwarePhilosophy
.
موضوع این هفته «علل شکست پروژههای نرمافزاری» هست.
خوشحال میشیم در این گفتگو همراه ما باشین.
آدرس روم: https://www.clubhouse.com/join/peachak-co/tE7ztfzO/mWLnQqVa
آدرس کلابهاوس: https://www.clubhouse.com/@mehrandvd
کانال فلسفه نرمافزار @SoftwarePhilosophy
.
Forwarded from Iran Agile
تجربه پیاده سازی مفاهیم چابک در پروژه دولتی آمریکا
اگر به شما بگویم که چابک ترین تجربه من در دولت فدرال آمریکا اتفاق افتاده چه؟ در این گزارش، من توضیح خواهم داد که چگونه سه تیم چابک که به عنوان پیمانکار دولت فدرال ایالات متحده کار میکردند، تصمیم گرفتند که از مفهوم NoEstimates استفاده کنند. این داستانی در مورد چگونگی سازگاری این گروه محصولات با تغییر اصول چابک به بهترین شکل ممکن است. گرچه بی عیب و نقص نیست، اما این واقعی ترین بیان چابک است که من تا به حال تجربه کرده ام. احساس می کنم مجبورم که این داستان را به عنوان یک جشن به اشتراک بگذارم.
https://www.agilealliance.org/resources/experience-reports/no-estimates-at-scale-in-the-us-federal-government/
@Iranagile
اگر به شما بگویم که چابک ترین تجربه من در دولت فدرال آمریکا اتفاق افتاده چه؟ در این گزارش، من توضیح خواهم داد که چگونه سه تیم چابک که به عنوان پیمانکار دولت فدرال ایالات متحده کار میکردند، تصمیم گرفتند که از مفهوم NoEstimates استفاده کنند. این داستانی در مورد چگونگی سازگاری این گروه محصولات با تغییر اصول چابک به بهترین شکل ممکن است. گرچه بی عیب و نقص نیست، اما این واقعی ترین بیان چابک است که من تا به حال تجربه کرده ام. احساس می کنم مجبورم که این داستان را به عنوان یک جشن به اشتراک بگذارم.
https://www.agilealliance.org/resources/experience-reports/no-estimates-at-scale-in-the-us-federal-government/
@Iranagile
Forwarded from فلسفه دیزاین
رفتار یا گفتار؟ مساله این است!
«یا چگونه میتوانیم درک درستتری نسبت به رفتار کاربرانمان بهدست بیاوریم.»
زمانی طراحی خاص یک محصول اهمیت زیادی داشت، انقدر که گاهی اهمیت طراحی از کاربردپذیری محصول بیشتر شده و در نتیجه طراحیهای زیبایی خلق میشد که امکان کار کردن با آن به سختی ممکن بود. خوشبختانه این روش رفتهرفته به کنار رانده شد و کاربردپذیری طرحها اهمیت بیشتری نسبت به زیبایی آنها پیدا کرد اما همچنان با محصولات پیچیدهای مواجه هستیم که کار کردن با آنها چندان راحت نیست.
به طور کلی تمام محصولات و خدمات برای استفاده کاربران و در راستای رفع مشکلات و برطرف کردن نیازهای آنها طراحی میشوند. به همین دلیل است که طراحان تلاش میکنند تا با استفاده از روشهای متفاوت شناخت بهتری نسبت به کاربرانشان پیدا کنند. اما گاهی اشتباه بودن اطلاعاتی که از کاربرانشان جمع آوری میکنند باعث میشود تا مسیری غلط را در پیش بگیرند و طراحیهای خود را بر پایه یک اشتباه انجام دهند.
اما چه چیزی باعث به وجود آمدن این اشتباه میشود؟ تصور کنید که محصولی را در برابر کاربری که تاکنون تجربه استفاده از آن نداشته است قرار میدهید. عدم شناخت کاربر نسبت به آن محصول باعث میشود تا نظرات اون تنها بر پایه مشاهداتش باشد و این نظرات معمولا برخلاف بازخوردهای کاربران پس از کار کردن با آن محصول است. بررسی رفتار کاربر هنگام کار با محصول سادهترین راه برای رفع چنین مشکلاتی است. زیرا اکثر کاربران مشکلات خود را به درستی نمی شناسند و دقیقا نمیدانند که به چیزی نیاز دارند پس شاید بهتر است که برای به دست آوردن درک درستی از رفتار کاربران و رسیدن به یک تجربه کاربری خوب، بهجای گوش کردن به صحبتهای کاربران به رفتارشان توجه کنید.
دنیا پر از کسبوکارهای است که به دلیل شناخت نادرست از کاربرانشان مسیری اشتباه را در پیش گرفتند و در نهایت شکست خوردند. اگر علاقهمند هستید که درباره روشهای درست شناخت کابران بیشتر بدانید پیشنهاد میکنم که این مقاله را مطالعه کنید.
https://bit.ly/36QXtT0
(زمان حدودی مطالعه: ۷ دقیقه)
نویسنده: فیروزه ایمانی
#تجربه_کاربری #کاربردپذیری
@Dexign فلسفه دیزاین
_______
«یا چگونه میتوانیم درک درستتری نسبت به رفتار کاربرانمان بهدست بیاوریم.»
زمانی طراحی خاص یک محصول اهمیت زیادی داشت، انقدر که گاهی اهمیت طراحی از کاربردپذیری محصول بیشتر شده و در نتیجه طراحیهای زیبایی خلق میشد که امکان کار کردن با آن به سختی ممکن بود. خوشبختانه این روش رفتهرفته به کنار رانده شد و کاربردپذیری طرحها اهمیت بیشتری نسبت به زیبایی آنها پیدا کرد اما همچنان با محصولات پیچیدهای مواجه هستیم که کار کردن با آنها چندان راحت نیست.
به طور کلی تمام محصولات و خدمات برای استفاده کاربران و در راستای رفع مشکلات و برطرف کردن نیازهای آنها طراحی میشوند. به همین دلیل است که طراحان تلاش میکنند تا با استفاده از روشهای متفاوت شناخت بهتری نسبت به کاربرانشان پیدا کنند. اما گاهی اشتباه بودن اطلاعاتی که از کاربرانشان جمع آوری میکنند باعث میشود تا مسیری غلط را در پیش بگیرند و طراحیهای خود را بر پایه یک اشتباه انجام دهند.
اما چه چیزی باعث به وجود آمدن این اشتباه میشود؟ تصور کنید که محصولی را در برابر کاربری که تاکنون تجربه استفاده از آن نداشته است قرار میدهید. عدم شناخت کاربر نسبت به آن محصول باعث میشود تا نظرات اون تنها بر پایه مشاهداتش باشد و این نظرات معمولا برخلاف بازخوردهای کاربران پس از کار کردن با آن محصول است. بررسی رفتار کاربر هنگام کار با محصول سادهترین راه برای رفع چنین مشکلاتی است. زیرا اکثر کاربران مشکلات خود را به درستی نمی شناسند و دقیقا نمیدانند که به چیزی نیاز دارند پس شاید بهتر است که برای به دست آوردن درک درستی از رفتار کاربران و رسیدن به یک تجربه کاربری خوب، بهجای گوش کردن به صحبتهای کاربران به رفتارشان توجه کنید.
دنیا پر از کسبوکارهای است که به دلیل شناخت نادرست از کاربرانشان مسیری اشتباه را در پیش گرفتند و در نهایت شکست خوردند. اگر علاقهمند هستید که درباره روشهای درست شناخت کابران بیشتر بدانید پیشنهاد میکنم که این مقاله را مطالعه کنید.
https://bit.ly/36QXtT0
(زمان حدودی مطالعه: ۷ دقیقه)
نویسنده: فیروزه ایمانی
#تجربه_کاربری #کاربردپذیری
@Dexign فلسفه دیزاین
_______
Nielsen Norman Group
First Rule of Usability? Don't Listen to Users
For good UX, watch what users do, not what they say. Self-reported claims and speculations about future behavior are unreliable. Users do not know what they want.
Forwarded from Iran Agile
تجربه پیاده سازی اسکرام در شرکتهای دیجیتال مارکتینگ
آژانس بازاریابی دیجیتال فیش بت در تلاش بود تا با سرعت تغییر در چشم انداز دیجیتالی که روز به روز پیچیده تر می شود، خودش را منطبق نماید. درست زمانی که تیم متوجه شده بود که رویکرد قدیمی آنها در عملیات آژانس دیگر موثر نیست، آنها به Zen Ex Machina ، یک شرکت مشاوره چابک معرفی شدند. با اتخاذ رویکرد چابک به عملیات و ارائه خدمات، فیش بت اکنون قادر به پاسخگویی به تغییرات صنعت و ارائه کار معناداری است که نتایج با ارزش برای مشتریان به ارمغان می آورد.
https://www.agilealliance.org/resources/experience-reports/scrum-for-digital-marketing-control-the-chaos-and-deliver-value/
@iranagile
آژانس بازاریابی دیجیتال فیش بت در تلاش بود تا با سرعت تغییر در چشم انداز دیجیتالی که روز به روز پیچیده تر می شود، خودش را منطبق نماید. درست زمانی که تیم متوجه شده بود که رویکرد قدیمی آنها در عملیات آژانس دیگر موثر نیست، آنها به Zen Ex Machina ، یک شرکت مشاوره چابک معرفی شدند. با اتخاذ رویکرد چابک به عملیات و ارائه خدمات، فیش بت اکنون قادر به پاسخگویی به تغییرات صنعت و ارائه کار معناداری است که نتایج با ارزش برای مشتریان به ارمغان می آورد.
https://www.agilealliance.org/resources/experience-reports/scrum-for-digital-marketing-control-the-chaos-and-deliver-value/
@iranagile
Forwarded from فلسفه دیزاین
اصول طراحی رابط کاربری مختص توسعهدهندگان!
به عنوان توسعهدهنده فرانتاند، نیاز است تا پا به پای تیم محصول همکاری کنید تا در نهایت، یک محصول عالی نتیجه کار باشد. اگرچه در نگاه اول طراحی یک تجربه کاربری خوب بر عهده تیم محصول است اما توسعهدهندگان نیز نقش بسزایی در شکلدهی نحوه تعامل برنامه با کاربر دارند.
توسعهدهنده رابط کاربری کیست؟
توسعهدهنده رابط کاربری، مفهومی است که به خوبی برروی اینترنت تعریف نشده است. در اصل توسعهدهنده رابط کاربری، یک توسعهدهنده فرانتاند با دانش اصول و مفاهیم رابط کاربری است که در صورت نیاز میتواند به تنهایی پروژههای کوچک را ایجاد کند.
چرا داشتن دانش اصول طراحی کاربری مفید است؟
رابط کاربری اولین چیزی است که کاربر هنگام تعامل با محصول، مشاهده میکند. اگر جذاب و استفاده از آن آسان نباشد، کاربر بدون در نظرگرفتن ویژگیهای دیگر محصول، از استفاده از آن صرف نظر خواهد کرد. بنابراین نیاز است تا توسعه دهنده با استفاده از اصول رابط کاربری، به تولید یک محصول بهتر و موفق کمک کند. همچنین روابط بین طراحان و توسعهدهندگان را بهبود خواهد بخشید زیرا هر دو طرف خواهند فهمید چرا یک قسمت از محصول، به روش خاصی طراحی شده است.
معمولا اصول رابط کاربری در طراحی محصول به کار میروند اما در ادامه قصد داریم آن ها را از دید یک توسعهدهنده بررسی کنیم.
۱- یکپارچگی و هماهنگی
یکی از مواردی که معمولا در ابتدای بیشتر اصول روابط کاربری مشاهده میکنید، یکپارچگی و هماهنگی است. تمامی قسمتهای یک پلتفرم باید شبیه به هم به نظر برسد. این مورد میتواند با تعریف پالت رنگی، تایپوگرافی و کامپوننتها تا حد قابل قبولی حل شود.
۲- کارایی بیشتر
بیشتر اوقات، کارایی یک سیستم از طریق زمانی که کاربر برای انجام یک کار (به همراه شمارش کلیکها) صرف میکند، محاسبه میشود. اگر لایههای یک سیستم به خوبی تعریف شده باشند، کاربر میتواند به سرعت به هدف خود برسد. به عنوان یک توسعهدهنده رابط کاربری، چندکار در رابطه با این مورد میتوانید انجام دهید.
۳- مشخصبودن اقدامات کاربر و وضعیت سیستم
به همان اندازه که نشاندادن اقداماتی که کاربر میتواند در این وضعیت از سیستم انجام دهد یا قبلا انجام داده، ضروری است. نشان دادن وضعیت سیستم نیز به کاربر کمک میکند تا به نتایج اقدامات خود شک نکند.
در ادامهی این مقاله، میتوانید موارد پیشنهادی از اصول رابط کاربری مخصوص توسعهدهندگان به همراه مثالهایی از آن را مشاهده کنید.
http://bit.ly/dxgn727
(زمان حدودی مطالعه: ۸ دقیقه)
نویسنده: محمدرضا وفائی
#طراحی #توسعه_دهنده #محصول #اصول #فرانت_اند #رابط_کاربری
@Dexign فلسفه دیزاین
_______
به عنوان توسعهدهنده فرانتاند، نیاز است تا پا به پای تیم محصول همکاری کنید تا در نهایت، یک محصول عالی نتیجه کار باشد. اگرچه در نگاه اول طراحی یک تجربه کاربری خوب بر عهده تیم محصول است اما توسعهدهندگان نیز نقش بسزایی در شکلدهی نحوه تعامل برنامه با کاربر دارند.
توسعهدهنده رابط کاربری کیست؟
توسعهدهنده رابط کاربری، مفهومی است که به خوبی برروی اینترنت تعریف نشده است. در اصل توسعهدهنده رابط کاربری، یک توسعهدهنده فرانتاند با دانش اصول و مفاهیم رابط کاربری است که در صورت نیاز میتواند به تنهایی پروژههای کوچک را ایجاد کند.
چرا داشتن دانش اصول طراحی کاربری مفید است؟
رابط کاربری اولین چیزی است که کاربر هنگام تعامل با محصول، مشاهده میکند. اگر جذاب و استفاده از آن آسان نباشد، کاربر بدون در نظرگرفتن ویژگیهای دیگر محصول، از استفاده از آن صرف نظر خواهد کرد. بنابراین نیاز است تا توسعه دهنده با استفاده از اصول رابط کاربری، به تولید یک محصول بهتر و موفق کمک کند. همچنین روابط بین طراحان و توسعهدهندگان را بهبود خواهد بخشید زیرا هر دو طرف خواهند فهمید چرا یک قسمت از محصول، به روش خاصی طراحی شده است.
معمولا اصول رابط کاربری در طراحی محصول به کار میروند اما در ادامه قصد داریم آن ها را از دید یک توسعهدهنده بررسی کنیم.
۱- یکپارچگی و هماهنگی
یکی از مواردی که معمولا در ابتدای بیشتر اصول روابط کاربری مشاهده میکنید، یکپارچگی و هماهنگی است. تمامی قسمتهای یک پلتفرم باید شبیه به هم به نظر برسد. این مورد میتواند با تعریف پالت رنگی، تایپوگرافی و کامپوننتها تا حد قابل قبولی حل شود.
۲- کارایی بیشتر
بیشتر اوقات، کارایی یک سیستم از طریق زمانی که کاربر برای انجام یک کار (به همراه شمارش کلیکها) صرف میکند، محاسبه میشود. اگر لایههای یک سیستم به خوبی تعریف شده باشند، کاربر میتواند به سرعت به هدف خود برسد. به عنوان یک توسعهدهنده رابط کاربری، چندکار در رابطه با این مورد میتوانید انجام دهید.
۳- مشخصبودن اقدامات کاربر و وضعیت سیستم
به همان اندازه که نشاندادن اقداماتی که کاربر میتواند در این وضعیت از سیستم انجام دهد یا قبلا انجام داده، ضروری است. نشان دادن وضعیت سیستم نیز به کاربر کمک میکند تا به نتایج اقدامات خود شک نکند.
در ادامهی این مقاله، میتوانید موارد پیشنهادی از اصول رابط کاربری مخصوص توسعهدهندگان به همراه مثالهایی از آن را مشاهده کنید.
http://bit.ly/dxgn727
(زمان حدودی مطالعه: ۸ دقیقه)
نویسنده: محمدرضا وفائی
#طراحی #توسعه_دهنده #محصول #اصول #فرانت_اند #رابط_کاربری
@Dexign فلسفه دیزاین
_______
Blog | Imaginary Cloud
UI Developer: a mix of Design and Front-end
Learn the main responsibilities of a UI developer and how to become one. Further, find out the technologies they use and take an in-depth look at how UI principles contribute to frontend development.
توسعه برنامه های Cross Platform
اگر قصد پیاده سازی برنامه Cross Platform در دات نت را دارید می توانید از Xamarin استفاده کنید.
اما قبل از شروع، احتمالا به دنبال این هستید که برای این کار چه راهی مناسبتر است.
در این مقاله بین سه گزینه Xamarin, React Native, Ionic بررسی هایی انجام شده است و شما میتوانید با توجه به شرایط خود، شرایط تیم، دانش برنامه نویسی خودتان و ... گزینه مورد نظر را انتخاب کنید.
گزینه های دیگری نیز وجود دارد که با توجه به نحوه مقایسه سه مورد ذکر شده در مقاله جاری، حتی میتوانید آنها را نیز با یکدیگر مقایسه کنید.
در نهایت اگر تصمیمتان Xamarin بود میتوانید از این کتاب رایگان که توسط خود مایکروسافت ارائه شده است استفاده کنید.
مایکروسافت این کتاب را به صورت خلاصه و با نوشتاری سلیس و روان ارائه کرده است.
در نهایت برای بالا بردن کیفیت پروژههای Xamarin خود میتوانید از سری آموزشهای توسعه برنامههای Cross Platform با Xamarin Forms & Bit Framework استفاده کنید.
#زامارین #xamarin
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
اگر قصد پیاده سازی برنامه Cross Platform در دات نت را دارید می توانید از Xamarin استفاده کنید.
اما قبل از شروع، احتمالا به دنبال این هستید که برای این کار چه راهی مناسبتر است.
در این مقاله بین سه گزینه Xamarin, React Native, Ionic بررسی هایی انجام شده است و شما میتوانید با توجه به شرایط خود، شرایط تیم، دانش برنامه نویسی خودتان و ... گزینه مورد نظر را انتخاب کنید.
گزینه های دیگری نیز وجود دارد که با توجه به نحوه مقایسه سه مورد ذکر شده در مقاله جاری، حتی میتوانید آنها را نیز با یکدیگر مقایسه کنید.
در نهایت اگر تصمیمتان Xamarin بود میتوانید از این کتاب رایگان که توسط خود مایکروسافت ارائه شده است استفاده کنید.
مایکروسافت این کتاب را به صورت خلاصه و با نوشتاری سلیس و روان ارائه کرده است.
در نهایت برای بالا بردن کیفیت پروژههای Xamarin خود میتوانید از سری آموزشهای توسعه برنامههای Cross Platform با Xamarin Forms & Bit Framework استفاده کنید.
#زامارین #xamarin
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.
#حامد_حاجیلو (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
✅ تولید تگ های SEO در ASPNET Core با کتابخانه SeoTags
تگ های زیاد و متنوعی برای بهبود SEO سایت وجود دارند. از انواع meta و link گرفته تا تگ های تنظیم Twitter Card و Open Graph تا JSON-LD و Microdata برای Structred Data تا SiteMap و...
هرکدوم هم مسلما مقادیر خاص خودشون رو میپذیرن و بسته به شرایط و نوع محتوا متفاوت هستند.
کتابخانه SeoTags تمامی تگ های مهم و کاربردی رو براحتی برای وبسایت ASPNET Core ایی شما میسازه و حالت ها و تگ های زیادی هم پشتیبانی میکنه.
اینو کتابخونه رو تازگی نوشتم (در جهت راه اندازی سایت DotNetZoom) و به زودی تکمیل ترش هم میکنم.
شما هم اگه دوست داشتین توش مشارکت کنین، issue بزنین و pull request بفرستین
طریقه استفاده و نمونه خروجی تگ ها رو میتونین توی ریپازیتوری مشاهده کنین
https://github.com/mjebrahimi/SeoTags
___________________
@DotNetZoom
تگ های زیاد و متنوعی برای بهبود SEO سایت وجود دارند. از انواع meta و link گرفته تا تگ های تنظیم Twitter Card و Open Graph تا JSON-LD و Microdata برای Structred Data تا SiteMap و...
هرکدوم هم مسلما مقادیر خاص خودشون رو میپذیرن و بسته به شرایط و نوع محتوا متفاوت هستند.
کتابخانه SeoTags تمامی تگ های مهم و کاربردی رو براحتی برای وبسایت ASPNET Core ایی شما میسازه و حالت ها و تگ های زیادی هم پشتیبانی میکنه.
اینو کتابخونه رو تازگی نوشتم (در جهت راه اندازی سایت DotNetZoom) و به زودی تکمیل ترش هم میکنم.
شما هم اگه دوست داشتین توش مشارکت کنین، issue بزنین و pull request بفرستین
طریقه استفاده و نمونه خروجی تگ ها رو میتونین توی ریپازیتوری مشاهده کنین
https://github.com/mjebrahimi/SeoTags
___________________
@DotNetZoom
GitHub
GitHub - mjebrahimi/SeoTags: 🚀 SeoTags generates All SEO Tags you need such as meta, link, Twitter card (twitter:), Open Graph…
🚀 SeoTags generates All SEO Tags you need such as meta, link, Twitter card (twitter:), Open Graph (for Facebook) (og:), and JSON-LD schema (structured data). - mjebrahimi/SeoTags
👍1
Forwarded from فلسفه دیزاین
تعریف مسئله به روش نردبان ذهنی
خیلی از مواقع، طرح مشکل به صورت عبارت نامشخصی بیان میشود. مثلا گفته میشود که به صندلی بهتری برای این دفتر کار نیازمندیم، یا این دکمه در صفحهی لندینگپیج باید بزرگتر شود. این قبیل تعریفهای سطحی، ما را در مسیر پیشرو گنگ و نامفهوم رها میکند.
به عنوان یک دیزاینر یا شاید بهتر بگویم حلکنندهی مسائل، باید قدرت بالایی در شناسایی مشکل، ریشهها و ابعاد آنها داشته باشیم. به طور سادهتر، باید مسئله مانند روز برایمان روشن باشد.
برای هرچه واضحتر کردن مسئله برای خودمان، نیاز داریم تا ریشهی آن نفوذ کنیم. امروز با یک ابزار به دردبخور آشنا میشویم که در فرآیند دیزاین بسیار کمککننده است.
این فریموُرک، به «نردبان ذهنی یا انتزاعی» معروف است. به طور خلاصه میگوید که مشکل را در میان نردبان بگذارید و حالا دو سؤال بپرسید. چرا (why) و چطور (How).
وقتی بپرسید چرا، از نردبان بالا میروید و طرح مسئله به هرچه مفهومیتر و انتزاعیتر شدن نزدیک میشود. وقتی بپرسید چطور یا چگونه، با ایدههای عمومیتر و واقعیتر مواجه میشوید.
این روش دقیقا با طرح مسئله چه کار میکند؟
مشکل اصلی و درست را از دل کار بیرون میکشد. یعنی در آخر متوجه خواهید شد که آن مشکل اولیهای که داشتیم در واقع فقط یک زیر شاخه از مشکل اصلی بوده است. میخواستیم که کاربران بیشتری را برای ثبتنام در سرویسمان جذب کنیم ولی اینطور مسئله مطرح شده بود که اگر دکمه بزرگتر شود، کاربران وبسایت نیز بیشتر میشوند. چه بسا اینکه بزرگترکردن یک دکمه شاید یکی از اهداف ما بوده است ولی مشکل به درستی مطرح نشده است که دقیقا متوجه شویم چه کاری باید در مراحل بعدی انجام دهیم.
برای اینکه دقیقا متوجه شوید که این روش چطور کار میکند، مقالات زیر را پیشنهاد میکنم که با مثالهای عینی و شفاف این مدل ذهنی را شرح میدهند:
http://bit.ly/dxgn742-1
http://bit.ly/dxgn742-2
http://bit.ly/dxgn742-3
(زمان حدودی مطالعهی مقالهی اول: ۸ دقیقه
،مقالهی دوم: ۶ دقیقه
و مقالهی سوم: ۷ دقیقه)
نویسنده: حسین میرزاده
#مدل_ذهنی #تعریف_مسئله #روش_حل_مشکل #نردبان_ذهنی
@Dexign فلسفه دیزاین
______
خیلی از مواقع، طرح مشکل به صورت عبارت نامشخصی بیان میشود. مثلا گفته میشود که به صندلی بهتری برای این دفتر کار نیازمندیم، یا این دکمه در صفحهی لندینگپیج باید بزرگتر شود. این قبیل تعریفهای سطحی، ما را در مسیر پیشرو گنگ و نامفهوم رها میکند.
به عنوان یک دیزاینر یا شاید بهتر بگویم حلکنندهی مسائل، باید قدرت بالایی در شناسایی مشکل، ریشهها و ابعاد آنها داشته باشیم. به طور سادهتر، باید مسئله مانند روز برایمان روشن باشد.
برای هرچه واضحتر کردن مسئله برای خودمان، نیاز داریم تا ریشهی آن نفوذ کنیم. امروز با یک ابزار به دردبخور آشنا میشویم که در فرآیند دیزاین بسیار کمککننده است.
این فریموُرک، به «نردبان ذهنی یا انتزاعی» معروف است. به طور خلاصه میگوید که مشکل را در میان نردبان بگذارید و حالا دو سؤال بپرسید. چرا (why) و چطور (How).
وقتی بپرسید چرا، از نردبان بالا میروید و طرح مسئله به هرچه مفهومیتر و انتزاعیتر شدن نزدیک میشود. وقتی بپرسید چطور یا چگونه، با ایدههای عمومیتر و واقعیتر مواجه میشوید.
این روش دقیقا با طرح مسئله چه کار میکند؟
مشکل اصلی و درست را از دل کار بیرون میکشد. یعنی در آخر متوجه خواهید شد که آن مشکل اولیهای که داشتیم در واقع فقط یک زیر شاخه از مشکل اصلی بوده است. میخواستیم که کاربران بیشتری را برای ثبتنام در سرویسمان جذب کنیم ولی اینطور مسئله مطرح شده بود که اگر دکمه بزرگتر شود، کاربران وبسایت نیز بیشتر میشوند. چه بسا اینکه بزرگترکردن یک دکمه شاید یکی از اهداف ما بوده است ولی مشکل به درستی مطرح نشده است که دقیقا متوجه شویم چه کاری باید در مراحل بعدی انجام دهیم.
برای اینکه دقیقا متوجه شوید که این روش چطور کار میکند، مقالات زیر را پیشنهاد میکنم که با مثالهای عینی و شفاف این مدل ذهنی را شرح میدهند:
http://bit.ly/dxgn742-1
http://bit.ly/dxgn742-2
http://bit.ly/dxgn742-3
(زمان حدودی مطالعهی مقالهی اول: ۸ دقیقه
،مقالهی دوم: ۶ دقیقه
و مقالهی سوم: ۷ دقیقه)
نویسنده: حسین میرزاده
#مدل_ذهنی #تعریف_مسئله #روش_حل_مشکل #نردبان_ذهنی
@Dexign فلسفه دیزاین
______
Autodesk
Abstraction Laddering: Clearly Define the Problem | Autodesk
Knowing which problems to solve is what makes us better engineers. Abstraction laddering gives you a framework for understanding unclear tasks.
Forwarded from Iran Agile
چرا کامیونیتیهای چابک دچار کج روی شدند؟
نزدیک به پنجاه تا مقاله در حوزه چابک در سایتهای معتبر و لینکدین بررسی کردم، بسیار نکته جالبی دریافت کردم، نویسندگان و تولیدکنندگان این مطالب به صراحت در مورد برخی چیزها ادعا کرده بودند بدون داشتن هیچ استدلالی، یا حداکثر استدلال ارجاع دادن به سخن یا توییت یکی از افراد برجسته کامیونیتی بوده است.
مثلاً فلانی هم گفته «تخمین زدن بیخود هست» یا «فلان روش کار نمیکند »، اکثرا این ادعا همراه با استدلالهای خیلی ضعیفی بیان میشوند و یا دچار خطاهای شناختی هستند.
البته حرف من در اینجا این نیست که نتیجه بگیرم "تخمین عالی است" ، "SAFe ایده خوبی است" و "اسکراممستر همچنین می توانند مالک محصول نیز باشد". حرف من این است که به نظر می رسد تلاش های سیستماتیک واقعی برای بررسی این موضوعات با رویکرد تجربی، دیدگاه ظریفتری در مورد این سوالات ارائه میدهد.
چرا کامیونیتیهای چابک از تجربه گرایی فاصله گرفتند؟
آنچه به ویژه در اینجا آشکار می شود این است که جامعه چابک ظاهراً همه راجع به "تجربه گرایی" است. اما آیا ما واقعا تجربه گرا هستیم؟ ویکی پدیا تجربه گرایی را چنین تعریف می کند:
"تجربه گرایی […] بر شواهد تأکید می کند، به ویژه که در آزمایشات کشف شده باشند. این یک بخش اساسی از روش علمی است که همه فرضیهها و نظریهها باید در برابر مشاهدات جهان طبیعی آزمایش شوند تا اینکه فقط به شهود یا مکاشفه پیشینی استوار باشند."
تجربه گرایی به ما امکان می دهد تا دانش قابل اعتمادی در مورد جهان ایجاد کنیم و عواقب اقدامات را درک کنیم. دانش قابل اعتماد مستلزم شواهد معتبری است که متناسب با ادعا باشد. با اینکه احساس شهود و ترجیحات شخصی مطمئناً ارزش خود را دارند ، منابع معتبری برای شواهد نیستند. کارل ساگان فیزیکدان این طور خلاصه کرد که "ادعاهای خارق العاده به مدارک خارقالعاده نیاز دارند". ساگان همچنین از ما میخواهد که نسبت به ادعاهایی که فاقد شواهد متناسب هستند تردید داشته باشیم و کسانی را که فاقد چنین شواهدی ارائه می دهند به چالش بکشیم. از همه مهمتر ، وجود شواهد عینی همچنین زمینه ما را حرفه ای تر می کند زیرا بحثهای بهتری برای متقاعد کردن افراد بدبین ارائه می دهد.
چه چیزی شواهد خوبی ارائه می دهد؟
شواهد خوب عاری از سوگیری شخصی است و با روشهای بی طرفانه جمع آوری و تحلیل می شود. این بدان معناست که افراد دیگر می توانند داده های یکسان (مشاهدات ، موارد ، اعداد) را جمع آوری کرده و از همان روش ها برای رسیدن به نتایج یکسان استفاده کنند. این در علم "تکرار" نامیده می شود ، و این استاندارد طلایی برای چگونگی تولید دانش قابل اعتماد است.
نوشته کامل در لینک زیر 👇
https://medium.com/the-liberators/why-doesnt-the-agile-community-practice-empiricism-12082e48ffba
@iranagile
نزدیک به پنجاه تا مقاله در حوزه چابک در سایتهای معتبر و لینکدین بررسی کردم، بسیار نکته جالبی دریافت کردم، نویسندگان و تولیدکنندگان این مطالب به صراحت در مورد برخی چیزها ادعا کرده بودند بدون داشتن هیچ استدلالی، یا حداکثر استدلال ارجاع دادن به سخن یا توییت یکی از افراد برجسته کامیونیتی بوده است.
مثلاً فلانی هم گفته «تخمین زدن بیخود هست» یا «فلان روش کار نمیکند »، اکثرا این ادعا همراه با استدلالهای خیلی ضعیفی بیان میشوند و یا دچار خطاهای شناختی هستند.
البته حرف من در اینجا این نیست که نتیجه بگیرم "تخمین عالی است" ، "SAFe ایده خوبی است" و "اسکراممستر همچنین می توانند مالک محصول نیز باشد". حرف من این است که به نظر می رسد تلاش های سیستماتیک واقعی برای بررسی این موضوعات با رویکرد تجربی، دیدگاه ظریفتری در مورد این سوالات ارائه میدهد.
چرا کامیونیتیهای چابک از تجربه گرایی فاصله گرفتند؟
آنچه به ویژه در اینجا آشکار می شود این است که جامعه چابک ظاهراً همه راجع به "تجربه گرایی" است. اما آیا ما واقعا تجربه گرا هستیم؟ ویکی پدیا تجربه گرایی را چنین تعریف می کند:
"تجربه گرایی […] بر شواهد تأکید می کند، به ویژه که در آزمایشات کشف شده باشند. این یک بخش اساسی از روش علمی است که همه فرضیهها و نظریهها باید در برابر مشاهدات جهان طبیعی آزمایش شوند تا اینکه فقط به شهود یا مکاشفه پیشینی استوار باشند."
تجربه گرایی به ما امکان می دهد تا دانش قابل اعتمادی در مورد جهان ایجاد کنیم و عواقب اقدامات را درک کنیم. دانش قابل اعتماد مستلزم شواهد معتبری است که متناسب با ادعا باشد. با اینکه احساس شهود و ترجیحات شخصی مطمئناً ارزش خود را دارند ، منابع معتبری برای شواهد نیستند. کارل ساگان فیزیکدان این طور خلاصه کرد که "ادعاهای خارق العاده به مدارک خارقالعاده نیاز دارند". ساگان همچنین از ما میخواهد که نسبت به ادعاهایی که فاقد شواهد متناسب هستند تردید داشته باشیم و کسانی را که فاقد چنین شواهدی ارائه می دهند به چالش بکشیم. از همه مهمتر ، وجود شواهد عینی همچنین زمینه ما را حرفه ای تر می کند زیرا بحثهای بهتری برای متقاعد کردن افراد بدبین ارائه می دهد.
چه چیزی شواهد خوبی ارائه می دهد؟
شواهد خوب عاری از سوگیری شخصی است و با روشهای بی طرفانه جمع آوری و تحلیل می شود. این بدان معناست که افراد دیگر می توانند داده های یکسان (مشاهدات ، موارد ، اعداد) را جمع آوری کرده و از همان روش ها برای رسیدن به نتایج یکسان استفاده کنند. این در علم "تکرار" نامیده می شود ، و این استاندارد طلایی برای چگونگی تولید دانش قابل اعتماد است.
نوشته کامل در لینک زیر 👇
https://medium.com/the-liberators/why-doesnt-the-agile-community-practice-empiricism-12082e48ffba
@iranagile
Medium
Why Doesn’t The Agile Community Practice Empiricism?
How we can improve our profession with more reliance on objective evidence, and less on personal opinions
Google firebase
گوگل فایربیس، سرویس پشتیبان گوگل است که امکانات فوق العادهای را در اختیار توسعه دهندگان iOS ,android و وب اپلیکیشن قرار میدهد.
امکانات و ابزار های متفاوت و قدرتمند فایربیس در این شش بخش قرار میگیرند:
• Cloud firestore
ذخیره دیتا در دیتابیسی که در اختیار میگذارد و همگام سازی آن در مقیاس جهانی.
• Authentication
سرویس احراز هویت قدرتمند با امکانات متنوع.
• Crashlytics
پیگیری و رفع هر چه سریعتر کرش برنامه.
• Analytics
تجزیه و تحلیل عملکردهای متفاوت برنامه برای بهبود قسمتهایی که به پرفورمنس برنامه کمک میکند.
• Remote Config
کنترل و بهبود برنامهی خود به صورت ریموت، بروزرسانی برنامه بدون نیاز به بازنشر دوباره.
• Cloud Messaging
ارسال اعلانات به پلتفرمهایی که از برنامه شما استفاده میکنند.
در انگولار با نصب پکیج fireangular و firebase تمام سرویسهای ذکر شده قابل استفاده است.
برای آشنایی بیشتر با فایربیس میتوانید به لینک زیر مراجعه کنید:
https://firebase.google.com/products/firestore
برای نحوه استفاده و نصب فایربیس در انگولار نیز میتوانید به لینک زیر مراجعه کنید:
https://github.com/angular/angularfire
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.
#حسن_یوسفی (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
گوگل فایربیس، سرویس پشتیبان گوگل است که امکانات فوق العادهای را در اختیار توسعه دهندگان iOS ,android و وب اپلیکیشن قرار میدهد.
امکانات و ابزار های متفاوت و قدرتمند فایربیس در این شش بخش قرار میگیرند:
• Cloud firestore
ذخیره دیتا در دیتابیسی که در اختیار میگذارد و همگام سازی آن در مقیاس جهانی.
• Authentication
سرویس احراز هویت قدرتمند با امکانات متنوع.
• Crashlytics
پیگیری و رفع هر چه سریعتر کرش برنامه.
• Analytics
تجزیه و تحلیل عملکردهای متفاوت برنامه برای بهبود قسمتهایی که به پرفورمنس برنامه کمک میکند.
• Remote Config
کنترل و بهبود برنامهی خود به صورت ریموت، بروزرسانی برنامه بدون نیاز به بازنشر دوباره.
• Cloud Messaging
ارسال اعلانات به پلتفرمهایی که از برنامه شما استفاده میکنند.
در انگولار با نصب پکیج fireangular و firebase تمام سرویسهای ذکر شده قابل استفاده است.
برای آشنایی بیشتر با فایربیس میتوانید به لینک زیر مراجعه کنید:
https://firebase.google.com/products/firestore
برای نحوه استفاده و نصب فایربیس در انگولار نیز میتوانید به لینک زیر مراجعه کنید:
https://github.com/angular/angularfire
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.
#حسن_یوسفی (لینکدین)
کانال تلگرام:
@SoftwarePhilosophy
________
Firebase
Cloud Firestore | Store and sync app data at global scale
Discover Firebase, Google’s mobile and web app development platform that helps developers build apps and games that users will love.
👍1
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
✅ بهبود SEO سایت های AspNet Core توسط کتابخانه SeoTags به کمک قابلیت Structred Data و JSON-LD
قابلیت Structured Data یکی از مباحث پیشرفته SEO هست که با تعریف ساختار صفحه به موتور های جستجو کمک میکنه محتوای صفحه شما رو بهتر متوجه بشن و نمایش بدن. نمونه نمایش نتایج در صفحه سرچ گوگل این موضوع رو میتونین از این لینک مشاهده کنین. همانطور که میبینین بعضی موارد به صورت rich result نمایش داده میشوند.
گوگل داکیومنت کاملی در مورد پیاده سازی Structured Data داره که از این لینک میتونین مشاهده کنین.
پیاده سازی این قابلیت توسط یکی از سه روش زیر انجام میشه
1- روش JSON-LD
2- روش Microdata
3- روش RDFa
روش اول یعنی JSON-LD روش پیشنهادی گوگل هست و در اون محتوای صفحه به صورت json در قالب استاندارد Schema.org درون یک تگ noscript از نوع application/ld+json تعریف میشه. که در این لینک میتونین نمونه پیاده سازیش رو برای یک product مشاهده کنین.
در روش های Microdata و RDFa هم محتوای صفحه در قالب attribute هایی بر روی تگ های html نشانه گذاری میشن.
داکیومنت گوگل یک قسمت از نحوه پیاده سازی این مورد برای مثال های پرکاربرد از جمله Article و Product و Book و ... نیز ارائه کرده.
حالا کتابخانه SeoTags از JSON-LD هم پشتیبانی میکنه و علاوه بر تولید تمام تگ های SEO برای سایت شما، محتوای JSON-LD رو هم خروجی میده.
داکیومنت استفاده از این کتابخانه برای تولید تگ های meta و link و... در اینجا مشاهده کنید.
و نمونه استفاده از قابلیت JSON-LD رو هم در اینجا و اینجا مشاهده کنید.
https://mjebrahimi.github.io/SeoTags/
__________________
@DotNetZoom
قابلیت Structured Data یکی از مباحث پیشرفته SEO هست که با تعریف ساختار صفحه به موتور های جستجو کمک میکنه محتوای صفحه شما رو بهتر متوجه بشن و نمایش بدن. نمونه نمایش نتایج در صفحه سرچ گوگل این موضوع رو میتونین از این لینک مشاهده کنین. همانطور که میبینین بعضی موارد به صورت rich result نمایش داده میشوند.
گوگل داکیومنت کاملی در مورد پیاده سازی Structured Data داره که از این لینک میتونین مشاهده کنین.
پیاده سازی این قابلیت توسط یکی از سه روش زیر انجام میشه
1- روش JSON-LD
2- روش Microdata
3- روش RDFa
روش اول یعنی JSON-LD روش پیشنهادی گوگل هست و در اون محتوای صفحه به صورت json در قالب استاندارد Schema.org درون یک تگ noscript از نوع application/ld+json تعریف میشه. که در این لینک میتونین نمونه پیاده سازیش رو برای یک product مشاهده کنین.
در روش های Microdata و RDFa هم محتوای صفحه در قالب attribute هایی بر روی تگ های html نشانه گذاری میشن.
داکیومنت گوگل یک قسمت از نحوه پیاده سازی این مورد برای مثال های پرکاربرد از جمله Article و Product و Book و ... نیز ارائه کرده.
حالا کتابخانه SeoTags از JSON-LD هم پشتیبانی میکنه و علاوه بر تولید تمام تگ های SEO برای سایت شما، محتوای JSON-LD رو هم خروجی میده.
داکیومنت استفاده از این کتابخانه برای تولید تگ های meta و link و... در اینجا مشاهده کنید.
و نمونه استفاده از قابلیت JSON-LD رو هم در اینجا و اینجا مشاهده کنید.
https://mjebrahimi.github.io/SeoTags/
__________________
@DotNetZoom
GitHub
GitHub - mjebrahimi/SeoTags: 🚀 SeoTags generates All SEO Tags you need such as meta, link, Twitter card (twitter:), Open Graph…
🚀 SeoTags generates All SEO Tags you need such as meta, link, Twitter card (twitter:), Open Graph (for Facebook) (og:), and JSON-LD schema (structured data). - mjebrahimi/SeoTags
Forwarded from فلسفه دیزاین
چرا از قبول و درک تغییر گریزانیم؟
چندوقت پیش بود قسمتی از پادکست Moniaz گوش میکردم که درباره ذهن انسان و علاقهاش به تغییر نکردن صحبت میکرد.
تغییر، وقت و انرژی مصرف میکند و طبیعتا ذهن ما تمام تلاشش را میکند تا حتی ایده تغییرات احتمالی را در هنگام شکلگیری از بین ببرد.
دقیقا برای همین است که بیشتر مواقع با تغییر مخالفیم، چون راحتیمان را به خطر میاندازد.
این مساله درباره دیزاین و ریبرند شرکتها هم صدق میکند. چرا خیلی از مردم از ریبرند شرکتها بدشان میآید؟ چرا به راحتی پذیرای لوگوی جدید یک شرکت قدیمی نیستند؟ در طراحی لوگوی جدید برای یک شرکت قدیمی چه مسائلی را باید در نظر گرفت که حاشیه این خطر را به حداقل رساند؟
دیزاین، سوای مسائل تکنیکیاش، یک مقوله احساسی است. شما به عنوان یک دیزاینر مستقیما با احساسات کاربر سروکار دارید. اینکه چه حسی به شما و برند شما دارد. این حس از شمایل لوگو در حال شکلگیری است تا میزان گردی باتنهای رابط کاربری.
در این مقاله، Kushaan Shah به واکاوی دلایلی میپردازد که چرا مردم از ریبرندها متنفرند؟
پیشنهاد میکنم این مقاله جذاب رو از دست ندهید.
http://bit.ly/dxgn746
(زمان حدودی مطالعه: ۱۲ دقیقه)
نویسنده: آرش اصغری
#دیزاین #چالش
@Dexign فلسفه دیزاین
______
چندوقت پیش بود قسمتی از پادکست Moniaz گوش میکردم که درباره ذهن انسان و علاقهاش به تغییر نکردن صحبت میکرد.
تغییر، وقت و انرژی مصرف میکند و طبیعتا ذهن ما تمام تلاشش را میکند تا حتی ایده تغییرات احتمالی را در هنگام شکلگیری از بین ببرد.
دقیقا برای همین است که بیشتر مواقع با تغییر مخالفیم، چون راحتیمان را به خطر میاندازد.
این مساله درباره دیزاین و ریبرند شرکتها هم صدق میکند. چرا خیلی از مردم از ریبرند شرکتها بدشان میآید؟ چرا به راحتی پذیرای لوگوی جدید یک شرکت قدیمی نیستند؟ در طراحی لوگوی جدید برای یک شرکت قدیمی چه مسائلی را باید در نظر گرفت که حاشیه این خطر را به حداقل رساند؟
دیزاین، سوای مسائل تکنیکیاش، یک مقوله احساسی است. شما به عنوان یک دیزاینر مستقیما با احساسات کاربر سروکار دارید. اینکه چه حسی به شما و برند شما دارد. این حس از شمایل لوگو در حال شکلگیری است تا میزان گردی باتنهای رابط کاربری.
در این مقاله، Kushaan Shah به واکاوی دلایلی میپردازد که چرا مردم از ریبرندها متنفرند؟
پیشنهاد میکنم این مقاله جذاب رو از دست ندهید.
http://bit.ly/dxgn746
(زمان حدودی مطالعه: ۱۲ دقیقه)
نویسنده: آرش اصغری
#دیزاین #چالش
@Dexign فلسفه دیزاین
______
Medium
Why do we hate brand redesigns?
Most brand redesigns immediately evoke a strong negative reaction — what does this tell us about humans?
Forwarded from Iran Agile
تفکر سیستمی برای توسعه دهندگان نرمافزار
چند روز پیش، آقای کنتبک(مبدع اکس پی ) یک ارایه خیلی جذاب در مورد تفکر سیستمی ویژه برنامه نویسها داشت.
از این لحاظ این ارایه جذاب هست که هم خیلی ساده توضیح میدن، و هم اینکه برای نرمافزاریهاست و اینکه خود ایشون از دنیای چابک است. مثلاً اینکه چرا خیلی از تغییرات ما در دنیای نرمافزار مثل نوشتن تست اتوماتیک اتفاق نمیافتند
توصیه میشود با حوصله ببینید حتی اگر فنی نیستید، البته لازم نیست فنی باشید 👇👇👇
https://youtu.be/z8bL_V9in9o
@iranagile
چند روز پیش، آقای کنتبک(مبدع اکس پی ) یک ارایه خیلی جذاب در مورد تفکر سیستمی ویژه برنامه نویسها داشت.
از این لحاظ این ارایه جذاب هست که هم خیلی ساده توضیح میدن، و هم اینکه برای نرمافزاریهاست و اینکه خود ایشون از دنیای چابک است. مثلاً اینکه چرا خیلی از تغییرات ما در دنیای نرمافزار مثل نوشتن تست اتوماتیک اتفاق نمیافتند
توصیه میشود با حوصله ببینید حتی اگر فنی نیستید، البته لازم نیست فنی باشید 👇👇👇
https://youtu.be/z8bL_V9in9o
@iranagile
YouTube
Keynote: Systems Thinking — Kent Beck & Jessica Kerr
The third and final keynote of ETE 2021, delivered in an alternative format by Kent Beck and Jessica Kerr.
--------------------------------------------
Philly Emerging Technologies for the Enterprise (ETE) is hosted yearly by Chariot Solutions. You can…
--------------------------------------------
Philly Emerging Technologies for the Enterprise (ETE) is hosted yearly by Chariot Solutions. You can…
Forwarded from فلسفه دیزاین
وارونگی؛ زاویهی دیگر مسئله
روش وارونگی زمانی مفید است که هنگام حل مسئله، نیازمند این باشید که آن را از زاویهی دیگری ببینید. این تکنیک به شما کمک میکند که بدترین سناریوهای ممکن را متصور شوید و از ابعاد دیگر مسئله نیز آگاه شوید.
بهترین سؤالی که میتوانید از خود بپرسید تا بدانید که آیا این روش میتواند به شما کمک کند اینست: آیا به دنبال یک راهحل ایدهآلی هستیم؟
حالا میتوانید افکار خود را دربارهی مسئله و یا راهحل معکوس کنید.
۱. از خودتان بپرسید که بدترین تصمیم یا راهحل برای این مسئله چیست؟
۲. حال از خود بپرسید که چرا این بدترین تصمیم است؟ علتها را یادداشت کنید.
۳. با توجه به علتها و راهحل بدی که یادداشت کردید. تصمیم یا راهحل درست را ارائه بدهید. (از خود بپرسید که چطور میشود ازین راهحل بد جلوگیری کرد.)
وارونگی به شما کمک میکند که نتایج بد را ببینید و از وقوع آنها جلوگیری کنید.
سؤالاتی که میتواند شما را در این تکنیک کمک کند میتواند موارد زیر باشد:
- چطور میتواند این تصمیم غلط اتفاق بیافتد؟
- عکس این قضیه چه خواهد بود؟
- چه چیزهایی باعث بدترین راهحل برای این موضوع شده است؟
معمولا مدیران پروژه از روشی به نام Pre-mortem (پیش از مرگ) استفاده میکنند. افراد تیم را جمع میکنند و فرض میکنند به اتمام زمان پروژه رسیدهاند و پروژه شکست خورده است. آنها این سناریو را با سؤالاتی از قبیل «چه چیزی اشتباه پیش رفت؟»، «چه اشتباهاتی انجام دادیم؟» و «چطور شد که این پروژه شکست خورد» بررسی میکنند.
این کار باعث میشود که افراد تیم زودتر از موعد مشکلات احتمالی را ببینند و برای آنها آماده شوند.
مقالهی زیر را مطالعه کنید تا با دیگر مثالهای این روش حل مسئله آشنا شوید:
http://bit.ly/dxgn748
(زمان حدودی مطالعه مقاله: ۹ دقیقه)
نویسنده: حسین میرزاده
#مدل_ذهنی #تعریف_مسئله #روش_حل_مشکل #وارونگی #معکوس_سازی
@Dexign فلسفه دیزاین
______
روش وارونگی زمانی مفید است که هنگام حل مسئله، نیازمند این باشید که آن را از زاویهی دیگری ببینید. این تکنیک به شما کمک میکند که بدترین سناریوهای ممکن را متصور شوید و از ابعاد دیگر مسئله نیز آگاه شوید.
بهترین سؤالی که میتوانید از خود بپرسید تا بدانید که آیا این روش میتواند به شما کمک کند اینست: آیا به دنبال یک راهحل ایدهآلی هستیم؟
حالا میتوانید افکار خود را دربارهی مسئله و یا راهحل معکوس کنید.
۱. از خودتان بپرسید که بدترین تصمیم یا راهحل برای این مسئله چیست؟
۲. حال از خود بپرسید که چرا این بدترین تصمیم است؟ علتها را یادداشت کنید.
۳. با توجه به علتها و راهحل بدی که یادداشت کردید. تصمیم یا راهحل درست را ارائه بدهید. (از خود بپرسید که چطور میشود ازین راهحل بد جلوگیری کرد.)
وارونگی به شما کمک میکند که نتایج بد را ببینید و از وقوع آنها جلوگیری کنید.
سؤالاتی که میتواند شما را در این تکنیک کمک کند میتواند موارد زیر باشد:
- چطور میتواند این تصمیم غلط اتفاق بیافتد؟
- عکس این قضیه چه خواهد بود؟
- چه چیزهایی باعث بدترین راهحل برای این موضوع شده است؟
معمولا مدیران پروژه از روشی به نام Pre-mortem (پیش از مرگ) استفاده میکنند. افراد تیم را جمع میکنند و فرض میکنند به اتمام زمان پروژه رسیدهاند و پروژه شکست خورده است. آنها این سناریو را با سؤالاتی از قبیل «چه چیزی اشتباه پیش رفت؟»، «چه اشتباهاتی انجام دادیم؟» و «چطور شد که این پروژه شکست خورد» بررسی میکنند.
این کار باعث میشود که افراد تیم زودتر از موعد مشکلات احتمالی را ببینند و برای آنها آماده شوند.
مقالهی زیر را مطالعه کنید تا با دیگر مثالهای این روش حل مسئله آشنا شوید:
http://bit.ly/dxgn748
(زمان حدودی مطالعه مقاله: ۹ دقیقه)
نویسنده: حسین میرزاده
#مدل_ذهنی #تعریف_مسئله #روش_حل_مشکل #وارونگی #معکوس_سازی
@Dexign فلسفه دیزاین
______
James Clear
Inversion: The Crucial Thinking Skill Nobody Ever Taught You
One of the best ways to solve problems in life is to use the mental model of inversion. Read this article to learn how to become a better thinker today.
Forwarded from Iran Agile
داستان تحول چابک بوش آلمان
بوش با هر استانداردی شرکت عظیمی محسوب می شود. این شرکت مهندسی و فناوری آلمانی حدود 400000 کارمند دارد و محصولات آن - آگاهانه و ناآگاهانه - بخشی از زندگی روزمره ما هستند.
طی پنج سال گذشته ، تحول هیجان انگیزی در بخش ابزارها شرکت ایجاد شده است. بخش کالاهای مصرفی انواع ابزارهای برقی، ابزار اندازه گیری و لوازم جانبی مانند مته، اره برقی، سمباده و چیزهای دیگر را تولید می کند.
در لینک زیر میتوانید داستان این سفر پنج ساله بوش را مطالعه کنید 👇👇👇
https://corporate-rebels.com/transforming-bosch
@iranagile
بوش با هر استانداردی شرکت عظیمی محسوب می شود. این شرکت مهندسی و فناوری آلمانی حدود 400000 کارمند دارد و محصولات آن - آگاهانه و ناآگاهانه - بخشی از زندگی روزمره ما هستند.
طی پنج سال گذشته ، تحول هیجان انگیزی در بخش ابزارها شرکت ایجاد شده است. بخش کالاهای مصرفی انواع ابزارهای برقی، ابزار اندازه گیری و لوازم جانبی مانند مته، اره برقی، سمباده و چیزهای دیگر را تولید می کند.
در لینک زیر میتوانید داستان این سفر پنج ساله بوش را مطالعه کنید 👇👇👇
https://corporate-rebels.com/transforming-bosch
@iranagile