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

لینک زیر راه های ساده و کارآمدی را برای داشتن کد مرتب CSS معرفی می‌کند که استفاده از آنها توصیه می‌شود.

http://cssguidelin.es/

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

http://ow.ly/IdOy30aYW4S

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

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

___

🔴 راهنمای عملی پروتوتایپ برای مدیران محصول

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

http://blog.scrum.ir/2017/04/prototyping-for-product- managers

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

۱. نحوه استفاده از هوش مصنوعی Microsoft Cognitive Services در سه پلتفرم Android, iOS, Windows 10
#ai #cognitiveservices #dotnet
https://news.1rj.ru/str/SoftwarePhilosophy/761

۲. نظر Dino Esposito در مورد زمان مهاجرت به ASP.NET Core
#aspnetcore #dotnetcore
https://news.1rj.ru/str/SoftwarePhilosophy/762

۳. دراپ‌باکس دوست‌داشتنی و روند هیجا‌ن‌انگیز بازطراحی آن (دیزاین)
#design #ui #ux
https://news.1rj.ru/str/SoftwarePhilosophy/763

۴. راه های ساده و کارآمد برای داشتن کد مرتب CSS
#css #cleancode
https://news.1rj.ru/str/SoftwarePhilosophy/764

۵. راهنمای عملی پروتوتایپ برای مدیران محصول (Iran Agile)
#prototype
ـــــــــــ

@SoftwarePhilosophy

تنظیم محیط برنامه‌نویسی Linux روی Windows 10 عنوان مقاله‌ای است که اسکات هانسلمن در بلاگش در مورد آن توضیح داده‌است. یکی از نکات جالب مورد اشاره او در این پست این جمله بود: «بعضی‌ها دوست دارند با ماوس و کلیک کار کنند، بعضی‌ها ترجیح می‌دهند با کیبورد و تایپ کردن کار کنند، اشکال ندارد برای همه جا هست!»
دو عادت کاملا متفاوت برنامه‌نویسان، محیط‌های کارمندی و محیط‌های گرافیکی است. در این مقاله نحوه استفاده از bash روی linux که روی windows 10 بالا آمده‌است توضیح داده شده.

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

https://www.hanselman.com/blog/SettingUpAShinyDevelopmentEnvironmentWithinLinuxOnWindows10.aspx

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

http://ow.ly/FD3X30b4Kyd

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

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


___

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

در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویس‌های Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature‌ ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی می‌شوند. سپس این Feature ها به Backlog Item ها شکسته می‌شوند. یک Backlog Item در حقیقت یک نیازمندی‌است است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.

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

http://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/

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

http://ow.ly/3NGm30b5IjZ

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

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


___

دو مورد کلی باعث Gold Plating می شود:

1- عطش یادگیری در نیروهای فنی : چه دوست داشته باشیم یا نه، این ویژگی بارز نیروهای فنی است و آنها همیشه دوست دارند تکنولوژی های جدید را تجربه کنند و یاد بگیرند و دوباره یاد بگیرند. البته نیروی فنی با دیدن فیلم آموزشی یا کلاس چیزی یاد نمی گیرد، او زمانی یاد می گیرد که در پروژه (واقعی) تجربه کرده باشد. اما بعضی وقت ها هزینه یادگیری، یک پروژه شکست خورده می شود (یکی از دوستان می گفت؛ خوب چی مهم تر از این (: )

2- بزرگ جلوه دادن پروژه از سمت مدیران محصول: بعضی وقت ها مدیران محصول بدلیل عدم آشنایی با کسب کار، پروژه را بزرگ جلوه می دهند. مثلا برنامه نویس می پرسد چند نفر قرار است با این سیستم همزمان کار کنند، جواب "خیلی زیاد مثلا 500 هزار نفر". یا "آیا قرار است بعدا این قوانین کسب کار توسط خود مشتری عوض شوند؟" جواب: "بله". شاید یک جواب بله، باعث بشود که تیم به سراغ Workflow engine - فرم ساز و ... بروند و این یعنی هزینه خیلی زیاد.

👍 راه حل :

1- عطش یادگیری را نمی توان از بین برد، ولی شرکت هایی مثل گوگل که 20 درصد زمان را به خود نفرات می دهند، شاید یکی از دلایل همین یادگیری در حین کار باشد.

2- اصلا YAGNI در مورد این است که به چیزی که نیاز ندارید و مطئمن نیستید زیاد فکر نکنید، You are not gonna need it. یکی از هنرهای مدیریت محصول این است که تیم را به سمت ایجاد یک راه حل بزرگ نکشاند و سعی کند مشکل کسب کار را با کوچکترین راه حل ممکن حل کند.

3- هنر تیم هم این است که با تکیه بر اصول Keep it simple و با معماری تدریجی و طراحی پدیداری، سعی کند معماری و طراحی را از اول پیچیده در نظر نگیرد. به قول دوستان معمار، معمار خوب کسی است که تصمیم های مهم را به بعد موکول کند، یعنی اینکه با کسب دانش در طول پروژه بتواند تصمیم های درست تری بگیرد.

https://goo.gl/U4LLN0

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

خارجی‌ها هم مثل دروغ سیزده ما، مفهومی به اسم April's Fool دارن که در روز اول آوریل خیلی از سرویس‌ها و سایت‌ها عمل مشابه دروغ سیزده انجام میدن و بعضی از شرکت‌ها هم از این فرصت و بهانه استفاده می‌کنن تا ایده‌های هیجان‌انگیزشون رو به دنیا معرفی کنن.

امسال هم مثل سال‌های گذشته شرکت‌های بزرگ زیادی در این رسم شرکت کردن. یکی از بهترین‌های ایده‌های اجرا شده، ایده سایت Reddit بود.
سایت Reddit یک سایت بحث و گفتگو و همینطور خبری است. یکی از ویژگی‌های بارز سایت پرطرفدار Reddit اینه که خیلی از کاربرانش به شکل ناشناس (Anonymous) در اون فعالیت دارند.
امسال Reddit به بهانه April's Fool، یک صفحه به اسم Place راه‌اندازی کرد که یک بوم سفید بود و هر کاربر می‌تونست یک پیکسل از این بوم سفید رو با یکی از ۱۶ رنگی که در اختیارش قرار داره رنگ کنه. هر کاربری هرچند باری که میخواست می‌تونست این کار رو انجام بده، فقط باید چند دقیقه بین هر بار رنگ کردن یک پیسکل صبر می‌کرد.
قبل از خوندن ادامه به این ایده فکر کنید و تصور کنید که ساختن یک شکل واحد در اون ممکنه ماه‌ها طول بکشه یا اصلا آیا با این تعداد کاربری که ممکنه این صفحه رو ببینن و روی پیکسل‌های همدیگه رو رنگ کنن، اصلا ساختن یک طرح مشخص امکان‌پذیره یا نه؟
نتیجه کار حتی برای خود سازندگان سایت Reddit هم حیرت‌آور بود.

جامعه‌ای جهانی متشکل از ۱ میلیون کاربر شکل گرفت و شروع کردن به رنگ کردن این بوم سفید، مثل تمامی جوامع واقعی بشری، برخی به دنبال ساختن شکلی در کل بوم بودن و برخی فقط برای یه تیکه از بوم برنامه‌ریزی کرده بودن، گروه‌های خرابکاری شکل گرفت که مدام کارهای بقیه رو خراب می‌کردن. گروه‌های هکری دست به هک کردن تایمر زدن تا بتونن خارج از نوبت بوم رو رنگ کنن و …

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

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

https://digitalculturist.com/when-pixels-collide-reddit-place-and-the-creation-of-art-3f9c15cc3d82

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

پ. ن.
انیمیشن گیف زیر نحوه شکل‌گیری طرح نهایی رو از ابتدا نشون میده.

#ایده #هنر
@Dexign دیزاین

___

مفهوم Concurrent Programming و تفاوت آن با Parallel Programming همیشه یکی از مباحث چالش برانگیز برای برنامه نویسان بوده است. مفهوم اجرای همزمان یا Concurrent حتی قابل اجرا روی یک نخ یا یک cpu است. در حالی که اجرای موازی یا Parallel نیاز به چند نخ دارد. مقاله زیر به زیبایی و بسیار خلاصه این دو مدل برنامه‌نویسی را توضیح داده‌است. همچنین نحوه استفاده از امکانات .net core را برای پیاده‌سازی این مفاهیم را به همراه مثال‌هایی خوانا شرح داده‌است.

مفاهیم TPL, PLINQ, Async, Immutable Collection و مفاهیم دیگر در این مقاله با ذکر مثال‌هایی جالب شرح داده شده‌اند.

http://www.dotnetcurry.com/dotnet/1360/concurrent-programming-dotnet-core

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

http://ow.ly/xoWQ30bbJFn

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

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


___

✅ آیا بعد از پیاده سازی اسکرام، نیازی به اسکرام مستر داریم؟

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

👇👇👇👇👇
https://goo.gl/JYXqfx

@iranagile

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

۱. تنظیم محیط برنامه‌نویسی Linux روی Windows 10

https://news.1rj.ru/str/SoftwarePhilosophy/767

۲. شرح استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویس‌های Azure در یک پروژه عملی

https://news.1rj.ru/str/SoftwarePhilosophy/768

۳. دلایل ایجاد Gold Plating و راه حل‌های آن (Iran Agile)

https://news.1rj.ru/str/SoftwarePhilosophy/769

۴. بوم سفید سایت Reddit برای کاربران (دیزاین)

https://news.1rj.ru/str/SoftwarePhilosophy/770
https://news.1rj.ru/str/SoftwarePhilosophy/771

۵. توضیحاتی در رابطه با مفاهیم مفاهیم TPL, PLINQ, Async, Immutable Collection

https://news.1rj.ru/str/SoftwarePhilosophy/772

۶. آیا بعد از پیاده سازی اسکرام، نیازی به اسکرام مستر داریم؟ (Iran Agile)

https://news.1rj.ru/str/SoftwarePhilosophy/773

ـــــــــــ

@SoftwarePhilosophy

حذف حجم زیادی از سطرها از دیتابیس با اجرای دستور DELETE می‌تواند بسیار پر هزینه و زمان‌بر باشد. برای بهبود عملکرد و سرعت عملیات حذف باید Foreign Key ها، Index ها را هم بررسی کرد. ولی پس از بررسی و بهبود توسط این عوامل، راه بعدی استفاده از Delete Chunks است. شکستن DELETE های بزرگ به تکه‌های کوچک‌تر می‌تواند کمک زیادی به بهبود سرعت کند.

مقاله زیر ضمن آموزش این روش، نتایج اجرای این روش را با روش‌های دیگر مقایسه کرده‌است.


https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes

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

http://ow.ly/CcQz30bhNiQ


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

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


___

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

الگوی Async Retry Pattern یکی از الگوهایی است که در برنامه‌نویسی برنامه‌های نسل جدید بسیار مهم است. بسیاری دستگاه‌ها و بسترهای جدید شبکه مطمئنی ندارند. برای مثال اینترنت روی گوشی ممکن است بسته به موقعیت قطع و وصل شود و یا کیفیت پایینی داشته باشد. در این بسترها عملیات باید در صورت ناموفق بودن چند بار تکرار شوند و یا اصلاحا retry شود. ابزارهایی که برای retry طراحی شده‌اند این امکان را می‌دهند تا بتوان یک کار را با چند بار retry کردن انجام داد. برای مثال:
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);

RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);

کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.

مقاله زیر ضمن تشریح این الگو، توضیح داده‌است که چطور می‌توان با استفاده از async/await الگوی retry pattern را پیاده‌سازی کرد.

https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/

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

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

___

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

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

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

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

https://blog.prototypr.io/information-architecture-the-most-important-part-of-design-youre-probably-overlooking-20372ade4fc0

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

#معماری_اطلاعات #تجربه_کاربری #مفاهیم
@Dexign دیزاین

___

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

مدتیست کمپین #NoEstimates در توییتر توجه مهندسین نرم‌افزار را به خود جلب کرده‌است. این کمپین فلسفه جالبی دارد، افراد در این فلسفه اعتقاد دارند story ها نباید estimate شوند!! در این فلسفه تنها تخمین درست این است که آیا یک story به اندازه کافی کوچک هست یا نه. اگر یک story هنوز به اندازه کافی کوچک نیست، باید به تکه‌های کوچکتر شکسته شود. در این تیم‌ها به جای مجموع زمان باقیمانده یا point های باقیمانده از «تعداد» استوری‌های باقیمانده استفاده می‌شود.
مقاله زیر این مفهوم را در ترکیب با اسکرام توضیح داده و در مورد مزایا و معایب این فلسفه بحث کرده‌است.

http://innolution.com/blog/to-estimate-or-not-to-estimate-that-is-the-controversy

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

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

___

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

خلق تجربه کاربری خوب و مناسب برای تمام وسایل نمایش، فارغ از سایز آنها، هدف اصلی طراحی responsive است. خواه موبایل باشد یا تبلت یا رایانه شخصی و ....
در حال حاضر 99 سایز متفاوت برای نمایش وجود دارد که این تعداد روز به روز بیشتر می شود. بنابراین با توجه به این تنوع زیاد منطقی به نظر نمی رسد که طراحی ها براساس سایز هر وسیله نمایش باشد. به این معنی که نباید نقاط شکست (breakpoints) را براساس سایزهای مختلف وسایل موجود درنظر گرفت. بلکه این نقاط شکست می بایست براساس محتوی سایت درنظر گرفت. یعنی نقطه شکست وقتی اضافه شود که دیکر نحوه نمایش محتوی مناسب نیست. با این روش دیگر نیازی نیست نگران به بازار آمدن وسایل با سایز نمایشی جدید باشد زیرا نقاط شکست شما با توجه به محتوی سایت شماست نه سایز وسیله نمایش...
مقاله زیر به شرح کامل نحوه انتخاب نقاط شکست(breakpoints) می پردازد.

https://responsivedesign.is/articles/why-you-dont-need-device-specific-breakpoints

#مریم_داودی

لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a

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


___

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

۱. نوشتن کوئری‌های DELETE بهینه برای حجم دیتای زیاد
#sql #optimization
https://news.1rj.ru/str/SoftwarePhilosophy/775

۲. چگونه با استفاده از async/await الگوی retry pattern را پیاده‌سازی کنیم
#csharp #async #designpattern
https://news.1rj.ru/str/SoftwarePhilosophy/777

۳. مروری بر معماری اطلاعات یا فوت کوزه‌گری دیزاین (دیزاین)
#design
https://news.1rj.ru/str/SoftwarePhilosophy/778

۴. کمپین #NoEstimates و ترکیب آن با اسکرام
#scrum #estimation
https://news.1rj.ru/str/SoftwarePhilosophy/780

۵. طراحی responsive و نحوه انتخاب نقاط شکست
#css
https://news.1rj.ru/str/SoftwarePhilosophy/782

ـــــــــــ

@SoftwarePhilosophy

سوالاتی که هر دیزاینر جدیدی باید از تیم‌ش بپرسد

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

اجازه بدید با یه داستان کوتاه شروع کنیم.
آقای Jason Cashdollar به تازگی به عضویت تیم دیزاین اپلیکیشن Facebook Lite در فیس‌بوک در اومده. اولین تسک Jason بازطراحی روند عضویت در این اپلیکیشن هست و هدفی که براش تعیین شد عبارت بود از «کاهش سردرگمی کاربرانی که می‌خواهند ثبت‌نام کنند.». Jason مراحلی که هر دیزاینری برای دیزاین طی می‌کنه رو رفت و در نهایت پروپوزالی رو برای تیم‌ش ارسال کرد.
انتظار Jason این بود که تمام اعضای تیم با پیشنهاد اون به وجد بیان و هیجان‌زده بشن. ولی بعد از اینکه عکس‌العمل تیم رو دید متوجه شد که به قول خودش «مسابقه اشتباهی رو برنده شده بود.» و چیزی که طراحی کرده بود کارایی لازم رو نداشت.

یک لحظه همینجا صبر کنید. حدس می‌زنید دلیل این موضوع چی بود؟

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

پیشنهاد می‌کنم داستان کامل و سوالاتی که پرسیدن‌شون رو پیشنهاد میده، از زبان خود Jason بخونید.

https://medium.com/facebook-design/questions-to-ask-as-a-new-designer-on-the-team-7e3ace0c787f

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

پ. ن.
داشتن پایگاه دانش (knowledge base) همیشه به روند ملحق شدن اعضای جدید به تیم کمک می‌کنه. لازم نیست حتما از سیستم‌های پیچیده استفاده کنید، ما ۸ ماهی‌ست که یه نسخه کوچیک‌ش رو در قالب یک Board روی Trello راه‌اندازی کردیم و بچه‌های تیم خودشون بروزرسانی‌ش می‌کنند و کاملا کارمون رو راه می‌اندازه.

#تیم #طراحی_محصول
@Dexign دیزاین

___