Md Daily
راجب مقالات و مستندات فنی یا غیر فنی که میخونم و علایقم اینجا مینویسم :) گروه کانال: https://t.me/MdDailyGap کورس ها: https://t.me/MdDaily/395
Show more- Subscribers
- Post coverage
- ER - engagement ratio
Data loading in progress...
Data loading in progress...
# Good commit
git commit -m "Add user authentication"
# Bad commit
git commit -m "Add user authentication and update UI styles"
پیام کامیت توصیفی:
پیام کامیت باید به وضوح توضیح بده که کامیت چه کاری انجام میده و چرا این تغییر ایجاد شده. این پیام باید اطلاعات کافی رو در اختیار دیگران (و خود آیندهات) بذاره تا بتونن بدون خوندن کد، تغییر رو درک کنن.
مثال:
# Good commit message
git commit -m "Fix Correct null pointer exception in user login"
# Bad commit message
git commit -m "Fix bug"
رعایت استانداردهای کامیت:
میتونی از استانداردهای کامیت استفاده کنی تا تاریخچه گیتت تمیز، منظم و قابل خوندن تر باشه. معمولا این استانداردها شامل نوع تغییر (مثلا ویژگی جدید، رفع باگ، تغییر ساختار، مستندسازی) یا همون (feat, fix, chore, refactor, docs)، خلاصه کوتاه و گاهی توضیح طولانی یا اشاره به مشکلات مرتبط میشه.
مثال:
# Good commit message following conventional guidelines
git commit -m "feat(auth): add JWT-based authentication"
git commit -m "fix(login): resolve race condition in login flow"
میتونید از ایموجی هم استفاده کنید که لیست ایموجی هاش توی این gist و یا سایت gitmoji.dev پیدا میشن :)تست شده و تأیید شده: مطمئن شو که تغییرات توی کامیتت تست شده و درست کار میکنه. کد خراب یا تست نشده میتونه روند کار رو مختل کنه و بقیه رو اذیت کنه. محدوده مناسب: کامیتهات رو درست محدوده بندی کن. مثلاً اگه داری روی یه قابلیت خاص کار میکنی یا یه باگ رو درست میکنی، مطمئن شو که همه تغییرات مربوط به اون کار تو یه کامیت قرار گرفتن. از تغییرات ناقصی که ممکنه کد رو تو وضعیت ناپایداری بذاره، خودداری کن. مثال:
# Good commit with proper scope
git commit -m "refactor(auth): split auth logic into separate module"
# Bad commit with mixed scope
git commit -m "refactor and minor fixes"
❌ ویژگیهای یک کامیت بد
بزرگ و بدون تمرکز:
کامیت با تغییرات خیلی زیاد، یه کامیت بده. فهمیدن اینکه کامیت چه کاری انجام میده رو سخت میکنه. کامیتهای بزرگ و بدون تمرکز، بررسی و دیباگ کردن رو چالش برانگیز میکنن.
مثال:
# Bad commit
git commit -m "Update project"
پیامهای مبهم یا گمراهکننده:
پیامهای کامیت که مبهم یا گمراهکننده هستن، اطلاعات مفیدی درباره تغییرات ارائه نمیدن. این کمبود جزئیات میتونه باعث سردرگمی بشه و ردیابی تاریخچه تغییرات رو سخت کنه.
مثال:
# Bad commit message
git commit -m "Stuff"
تغییرات بیربط:
ترکیب تغییرات بیربط توی یه کامیت، جداسازی تغییرات خاص رو سخت میکنه و ممکنه باعث ایجاد باگ و پیچیده شدن روند بررسی بشه.
مثال:
# Bad commit
git commit -m "Update readme and fix login issue"
کد ناقص یا تست نشده:
کامیت کردن کد ناقص یا تست نشده میتونه جریان کار رو مختل کنه، برای بقیه اعضای تیم مشکل ایجاد کنه و ممکنه باعث خراب شدن بیلد بشه.
در نهایت بین کامیت کردن خیلی زیاد و خیلی کم تعادل برقرار کن. هر کامیت باید یه تغییر معنیدار رو نشون بده. هیچ وقت تغییرات بیربط رو تو یه کامیت قرار نده و پیامهای کامیتت باید توضیح بدن که کامیت چه کاری انجام میده و چرا این تغییر رو ایجاد کردی.
〰️〰️〰️
پ ن:
اگه هم مثه خودم خیلی حوصله ی نوشتن پیام commit ندارید میتونید از ابزاری که توی این پست معرفی کردم استفاده کنید تا خودش براتون کامیت رو بنویسه :)
🆔 @MdDailySELECT
a.author_name,
COUNT(ol.line_id) AS book_count
FROM order_line ol
INNER JOIN book b ON ol.book_id = b.book_id
INNER JOIN book_author ba ON b.book_id = ba.book_id
INNER JOIN author a ON ba.author_id = a.author_id
GROUP BY a.author_name
HAVING COUNT(ol.line_id) > 1;
خب این کوئری بدون مشکل اجرا میشه و نویسنده هایی که بیشتر از یک کتاب فروختند رو نشون میده. حالا اگه قرار باشه ببینیم کدوم نویسنده ها بیشتر از 5 تا کتاب فروختن چی؟
SELECT
a.author_name,
COUNT(ol.line_id) AS book_count
FROM order_line ol
INNER JOIN book b ON ol.book_id = b.book_id
INNER JOIN book_author ba ON b.book_id = ba.book_id
INNER JOIN author a ON ba.author_id = a.author_id
GROUP BY a.author_name
HAVING COUNT(ol.line_id) > 5;
تقریبا با یه تفاوت کوچیک تو قسمت آخر مثله کوئری قبلیه. توی این کوئری پیچیدگی وجود داره و دیتابیس توی هر بار اجرا باید عملیات های مختلفی انجام میده.
یکی از راه حل ها استفاده از یک temporary table یا به اختصار temp table هست. این جدول یه جور حافظه موقتیه که میتونید توش یه سری اطلاعات رو ذخیره کنید، ولی فقط تا زمانی که سشن توی پایگاه داده بازه وجود داره و بعدش پاک میشه.
فرض کنید یه سری اطلاعات پیچیده دارید که باید چند بار باهاشون کار کنید. با استفاده از یه جدول موقتی میتونید این اطلاعات رو یه بار توی جدول بریزید و بعد هر بار که بهشون نیاز دارید به جای اینکه دوباره محاسبات رو انجام بدید، از همین جدول موقتی استفاده کنید.
اینجوری هم کوئری ها خیلی سادهتر میشن، چون دیگه نیازی نیست که هر بار همه محاسبات از اول انجام بشن و یه مزیت دیگه استفاده از جدولهای موقتی اینه که کنترل بیشتری میده.
میخوایم یه جدول موقتی تو Postgres بسازیم تا تعداد کتابهای فروخته شده توسط هر نویسنده مثال رو توش ذخیره کنیم. دستورات ساخت جدول تو هر پایگاه داده یه کمی با هم فرق دارن، ولی مفهوم کلی یکیه.
تو Postgres، دستور ساخت یه جدول موقتی تقریبا شبیه به دستور ساخت یه جدول عادیه، کافیه بعد از کلمه Create و قبل از کلمه Table کلمه Temporary رو اضافه کنید:
CREATE TEMPORARY TABLE author_books_sold (
author_name VARCHAR(400),
book_count INT
);
بعد از اجرای این SQL وقتشه که داده هامون رو بریزیم تو این جدول موقت:
INSERT INTO author_books_sold (author_name, book_count)
SELECT
a.author_name,
COUNT(ol.line_id) AS book_count
FROM order_line ol
INNER JOIN book b ON ol.book_id = b.book_id
INNER JOIN book_author ba ON b.book_id = ba.book_id
INNER JOIN author a ON ba.author_id = a.author_id
GROUP BY a.author_name;
حالا از این به بعد با یه دستور SELECT ساده میشه به نویسنده هایی که بیشتر از n تا کتاب دارند دسترسی پیدا کرد چون محاسبه نویسندهها و کتابهای فروخته شده قبلا انجام شده، و داده تو جدول موقت ذخیره شده:
SELECT author_name, book_count
FROM author_books_sold
WHERE book_count > 1;
SELECT author_name, book_count
FROM author_books_sold
WHERE book_count > 5;
استفاده از جداول موقت یه تکنیک خیلی مفیده.
میتونید ازشون هر موقع که کوئریهای پیچیدهتری دارید استفاده کنید، یا وقتی که نمیخواهید یا نیاز ندارید یه جدول واقعی بسازید. اینها میتونن عملکرد رو بهبود ببخشن و کوئریهای شما رو سادهتر کنن، به خصوص اگه دادههای مشابه رو چندین بار محاسبه یا مشاهده میکنید.
🔗 Simplify Complex SQL With This Feature
🆔 @MdDailyapi/v1/{genre}/metaسعی شده در نوشتن api ها best practice هایی که توی این پست هم راجبشون نوشتم رعایت بشه. بعد بکند استریم میگه بذار اول از ice cast بپرسم ببینم چیا درحال پخش هستند ولی قبل از اینکه بره به آیس کست درخواست بزنه میره کشش رو چک میکنه چون که درخواست های تکراری زیاد هستند و تا زمان عوض شدن موزیک داده های قبلی توی ردیس کش باقی موندن. بکند استریم یه جیسون از اطلاعاتی مثل: اسم موزیک درحال پخش، آلبوم، نام خواننده و حتی کاور موزیک اماده میکنه و میده به بکند اپلیکیشن. اطلاعتی مثل آلبوم و نام خواننده از icecast قابل دریافت هستند ولی کاور موزیک و متادیتا های خاص را باید حتما بره از روی فایل بخونه. حالا بکند اپلیکیشن داده ها را برمیگردونه سمت اپ و اپلیکیشن توی پلیر خودش نشون میده. اما اینجا یه اتفاق بامزه میوفته، برای کاهش IO و افزایش پرفورمنس تو حجم تعداد کاربر بالا پلیر رادیویی که برای اپلیکیشن نوشته شده وقتی وصل شد به ادرس استریم موزیک مثلا: http://127.0.0.1:15210/pop و متا دیتا های اولیه رو هم گرفت، دیگه به بکند درخواست نمیزنه، بلکه اطلاعات موزد نیاز رو از خود موزیک درحال پخش میگیره و برای گرفتن کاور موزیک هم یک scraping کوچیک نوشتیم که میره از iTunes استخراج میکنه و برای بخش لیریکس هم از سرویس genius استفاده شده. حالا اگه به هر دلیلی سرویس genius قطع شد یا نت ملی شد یا iTunes فیلتر شد، اپ به مشکل نمیخوره و اتوماتیک دوباره برای گرفتن اطلاعات به بکند وصل میشه. به طور کلی برای بهبود سرعت پاسخگویی: 1- از ردیس براش کشینگ استفاده کردیم 2- بکند ها به صورت concurrency پیاده سازی شدن و روی چند ترد اجرا میشن. 3- خود اپلیکیشن هم سیستم کشینگ داخلی داره و از دیتابیس Isar استفاده میکنه پی نوشت: موقع ساخت MVP و اینکه تست کنیم ببینیم میشه یا نه کل این ساختار در ساده ترین شکل ممکن پیاده سازی شد، ما یک بکند پایتون داشتیم که متا دیتا ها را بر میگردوند و از دیتابیس و سیستم کشینگ هم خبری نبود، اپلیکیشن مستقیم وصل میشد به Icecast و پلی لیست ها را نشون میداد. بکند اولیمون که با پایتون بود توی دو روز نوشته شده بود و بعد از اینکه تست هامون رو گرفتیم و سیستم دیزاینمون تکمیل شد زیر ساخت جدید که توی تصویر مشخصه توی حدودا 3 هفته آماده شد و خیلی بهبود پیدا کرد. 🆔 @MdDaily
مفهوم MVP یا Minimum Viable Product به معنای حداقل محصول قابل ارائه هست. فرض کنید یه ایده برای یه محصول جدید دارید. به جای اینکه زمان و پول زیادی صرف ساخت کامل محصول و بعد عرضه به بازار کنید، میتونید یه نسخه اولیه از محصول رو بسازید که فقط کارکردهای اصلی و ضروری رو داشته باشه. به این نسخه اولیه MVP میگن. لینک های مفید: https://amplitude.com/blog/what-is-a-minimum-viable-product-mvp https://www.productplan.com/glossary/minimum-viable-product/بعد از اینکه فیدبک کاربران رو گرفتیم متوجه شدیم که اینکه هربار لینک رادیو از سایت کپی کنند و توی مثلا VLC وارد کنند یا از پلیر وب گوش بدند، خیلی دسترسی پذیر نیست و دوست دارن که از روی نوتیفیکشن دستگاه هم بتونند موزیک ها را کنترل کنند و قطعی نداشته باشن. خب کاری که من کردم این بود که چندین UI اپلیکیشن را برای کاربران هدف فرستادم، نظراتشون رو پرسیدم و در نهایت ما یک خروجی اولیه روی کاغذ داشتیم از اینکه کاربران چی دوست دارن. قبل از اینکه کار را شروع کنیم چنتا قانون گذاشتیم: 1- همه چیز را در فرایند توسعه ساده نگه داریم 2- دچار چرخه ی توسعه ی بی پایان نشیم 3- تو هر مرحله فیدبک بگیریم بیایند بخش دچار چرخه ی توسعه ی بی پایان نشیم باز تر کنیم. بار ها و بار ها توی تیم ها و پروژه های مختلف دیدم که پروژه یا ایده ها قبل از انتشار به دلیل اینکه مکررا بهشون فیچر اضافه شده و در نهایت برای مدت طولانی در حال توسعه باقی موندن شکست خوردن. مثلا شما قصد دارید یک اپلیکیشن آموزش زبان فرانسوی بسازید. اگر تعیین نکنید کاربران هدف اولیتون چه کسانی هستند، در اولین نسخه قرار چه سطحی رو پوشش بدید و چه امکاناتی داشته باشید، این اپلیکیشن هیچ وقت منتشر نخواهد شد. چون بجای اینکه دنبال خوب بودن باشید، دنبال کامل بودن هستید و مدام فیچر اضافه می کنید. بخش آموزش گرامر تموم شده، بعد با خودتون می گید خب بذار هوش مصنوعی هم اضافه کنم و وقتی هنوز بازخورد کاربران در ویژگی های core و اصلی نگرفتید، متوجه نمیشید که آیا اصلا این فیچر های جدید که اضافه کردید نیازی از کاربر رفع میکنه یا نه؟ پس در نهایت دامنه پروژه رو به وضوح باید تعریف کرد و بهش پایبند بود. برای رفع این مشکل من اومدم توی Todoist ( اینجا Todoist رو مثال زدم چون مدت زمان زیادی هست ازش استفاده میکنم ولی شما از هر ابزار project management ای مثل ClickUp که باهاش راحت هستید میتونید استفاده کنید ) توی پروژه 5 تا بخش تعریف کردم: 👉 Next Version: تسک ایده ها و اینکه در نسخه های آینده چیکار کنیم توی این بخش قرار گرفتن. بعد از انتشار هر نسخه نهایی بخشی از تسک های این بخش بر اساس اولویت و نیاز کاربر انتخاب و به Up next منتقل میشن 👉 Up next: تسک های نسخه ی فعلی 👉 In progress: تسک های درحال انجام 👉 In review: تسک های انجام شده که درحال تست هستن و فیدبک کاربران رو دریافت میکنن 👉 Done: تسک های انجام شده و با این تقسیم بندی ساده موفق شدیم که گرفتار چرخه ی بی پایان توسعه نشیم و در نهایت اولین MVP ما ساخته شد. به نظرم یکی از جالب ترین تجربه ها از اهمیت MVP مربوط به محصول DropBox هست که درو هوستون در سال 2008 یه ویدیو ساخت که نشون میداد دراپباکس چیکار میکنه. این ویدیو خیلی ساده بود، فقط نشون میداد که چطور میشه فایلها رو بین کامپیوترها همگامسازی کرد. ولی همین ویدیو ساده کلی سروصدا کرد! خیلیها با دیدن این ویدیو و عاشق دراپباکس شدن. تعداد آدمهایی که میخواستن از دراپباکس استفاده کنن و توی لیست انتظار ثبت نام کرده بودن از ۵۰۰۰ نفر به ۷۵۰۰۰ نفر رسید! این نشون میداد که مردم عاشق ایدهی دراپباکس بودن. دراپباکس با این ویدیو فهمید که باید چی بسازه. اونا به جای اینکه کلی پول خرج یه محصول کامل بکنن، فقط روی چیزهایی که مردم میخواستن تمرکز کردن. اینجوری دراپباکس تونست از یه استارتآپ کوچیک به یه شرکت بزرگ و معروف تبدیل بشه. لینک مقاله How DropBox Started As A Minimal Viable Product: 🔗 https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/ 🆔 @MdDaily
Learn more about MVPs—minimum viable products (derisked, initial versions of a new product or feature). Designed to elicit feedback from early users and empower teams to build, ship, and learn—faster.
مفهوم MVP یا Minimum Viable Product به معنای حداقل محصول قابل ارائه هست. فرض کنید یه ایده برای یه محصول جدید دارید. به جای اینکه زمان و پول زیادی صرف ساخت کامل محصول و بعد عرضه به بازار کنید، میتونید یه نسخه اولیه از محصول رو بسازید که فقط کارکردهای اصلی و ضروری رو داشته باشه. به این نسخه اولیه MVP میگن. لینک های مفید: https://amplitude.com/blog/what-is-a-minimum-viable-product-mvp https://www.productplan.com/glossary/minimum-viable-product/بعد از اینکه فیدبک کاربران رو گرفتیم متوجه شدیم که اینکه هربار لینک رادیو از سایت کپی کنند و توی مثلا VLC وارد کنند یا از پلیر وب گوش بدند، خیلی دسترسی پذیر نیست و دوست دارن که از روی نوتیفیکشن دستگاه هم بتونند موزیک ها را کنترل کنند و قطعی نداشته باشن. خب کاری که من کردم این بود که چندین UI اپلیکیشن را برای کاربران هدف فرستادم، نظراتشون رو پرسیدم و در نهایت ما یک خروجی اولیه روی کاغذ داشتیم از اینکه کاربران چی دوست دارن. قبل از اینکه کار را شروع کنیم چنتا قانون گذاشتیم: 1- همه چیز را در فرایند توسعه ساده نگه داریم 2- دچار چرخه ی توسعه ی بی پایان نشیم 3- تو هر مرحله فیدبک بگیریم بیایند بخش دچار چرخه ی توسعه ی بی پایان نشیم باز تر کنیم. بار ها و بار ها توی تیم ها و پروژه های مختلف دیدم که پروژه یا ایده ها قبل از انتشار به دلیل اینکه مکررا بهشون فیچر اضافه شده و در نهایت برای مدت طولانی در حال توسعه باقی موندن شکست خوردن. مثلا شما قصد دارید یک اپلیکیشن آموزش زبان فرانسوی بسازید. اگر تعیین نکنید کاربران هدف اولیتون چه کسانی هستند، در اولین نسخه قرار چه سطحی رو پوشش بدید و چه امکاناتی داشته باشید، این اپلیکیشن هیچ وقت منتشر نخواهد شد. چون بجای اینکه دنبال خوب بودن باشید، دنبال کامل بودن هستید و مدام فیچر اضافه می کنید. بخش آموزش گرامر تموم شده، بعد با خودتون می گید خب بذار هوش مصنوعی هم اضافه کنم و وقتی هنوز بازخورد کاربران در ویژگی های core و اصلی نگرفتید، متوجه نمیشید که آیا اصلا این فیچر های جدید که اضافه کردید نیازی از کاربر رفع میکنه یا نه؟ پس در نهایت دامنه پروژه رو به وضوح باید تعریف کرد و بهش پایبند بود. برای رفع این مشکل من اومدم توی Todoist ( اینجا Todoist رو مثال زدم چون مدت زمان زیادی هست ازش استفاده میکنم ولی شما از هر ابزار project management ای مثل ClickUp که باهاش راحت هستید میتونید استفاده کنید ) توی پروژه 5 تا بخش تعریف کردم: 👉 Next Version: تسک ایده ها و اینکه در نسخه های آینده چیکار کنیم توی این بخش قرار گرفتن. بعد از انتشار هر نسخه نهایی بخشی از تسک های این بخش بر اساس اولویت و نیاز کاربر انتخاب و به Up next منتقل میشن 👉 Up next: تسک های نسخه ی فعلی 👉 In progress: تسک های درحال انجام 👉 In review: تسک های انجام شده که درحال تست هستن و فیدبک کاربران رو دریافت میکنن 👉 Done: تسک های انجام شده و با این تقسیم بندی ساده موفق شدیم که گرفتار چرخه ی بی پایان توسعه نشیم و در نهایت اولین MVP ما ساخته شد. به نظرم یکی از جالب ترین تجربه ها از اهمیت MVP مربوط به محصول DropBox هست که درو هوستون در سال 2008 یه ویدیو ساخت که نشون میداد دراپباکس چیکار میکنه. این ویدیو خیلی ساده بود، فقط نشون میداد که چطور میشه فایلها رو بین کامپیوترها همگامسازی کرد. ولی همین ویدیو ساده کلی سروصدا کرد! خیلیها با دیدن این ویدیو و عاشق دراپباکس شدن. تعداد آدمهایی که میخواستن از دراپباکس استفاده کنن و توی لیست انتظار ثبت نام کرده بودن از ۵۰۰۰ نفر به ۷۵۰۰۰ نفر رسید! این نشون میداد که مردم عاشق ایدهی دراپباکس بودن. دراپباکس با این ویدیو فهمید که باید چی بسازه. اونا به جای اینکه کلی پول خرج یه محصول کامل بکنن، فقط روی چیزهایی که مردم میخواستن تمرکز کردن. اینجوری دراپباکس تونست از یه استارتآپ کوچیک به یه شرکت بزرگ و معروف تبدیل بشه. لینک مقاله How DropBox Started As A Minimal Viable Product: 🔗 https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/ 🆔 @MdDaily
Learn more about MVPs—minimum viable products (derisked, initial versions of a new product or feature). Designed to elicit feedback from early users and empower teams to build, ship, and learn—faster.
چیزی بسازید که صد نفر عاشق آن باشند نه اینکه یک میلیون نفر آن را تا حدودی دوست داشته باشند. - Brian Cheskyتقریبا اواخر سال 2022 بود که سید مهدی عزیز ایده ی رادیو رو پیاده سازی کرد. چیزی که من راجب این کار خیلی دوس داشتم این بود که همه چیز در ساده ترین حالت ممکن بود. بجای ساخت یک محصول کامل ما پلتفرمی را داشتیم که کار اصلیش یعنی بخش موزیک رو انجام می داد. زیر ساخت این پروژه تشکیل شده بود از یه سرور که روش Icecast پیاده سازی شده بود و یک فرانت که از این سرور Icecast لیست ژانر ها را می گرفت. Icecast به این صورت عمل میکنه که شما مثلا چنتا پوشه به اسم های pop , rap , hipop دارید و با استفاده از LIQUIDSOAP که یک زبان برای استریم Audio و Video هست میتونید برنامه نویسیش کنید. یک نمونه کد LIQUIDSOAP:
# Create a playlist containing all the files in the folder
pop = playlist("/music/pop/playlist.m3u")
output.icecast(
%mp3,
host="icecast2",
port=8000,
mount="pop",
password="1234",
fallible=true,
url="http://127.0.0.1:15210/pop",
encoding = "UTF-8",
name="Pop",
genre="pop",
pop
)
در نهایت کاربر میتونست با وارد شدن به لینک http://127.0.0.1:15210/pop به استریم موزیک های ژانر pop گوش کنه. یه ایده ی فان و کاربردی بود.
شروع سال 2023:
به مهدی پیشنهاد دادم یک نسخه ی مستقل از رادیو رو در قالب اپ بسازم. خیلی خلاصه بخوام بگم یعنی بخش اپلیکیشن دیگه با اسم و زیر مجموعه رادیو فعالیت نکنه و با یک اسم جدید و یک اپلیکیشن مستقل با ویژگی ها و امکانات اضافه تر توسعه پیدا کنه ولی همچنان از زیر ساخت رادیو استفاده کنه.
یه متدی داریم به اسم Design thinking یا به اختصار DT . خیلی ساده بخوام بگم این متد تشکیل شده از 5 مرحلس.
👈 مرحله ی اول همدلی یا درک نیازهای انسان (Empathize): توی این مرحله باید فرضیه های پیش فرضو کنار گذاشت و واقعا دید چه مشکلی وجود داره و یه جورایی با جمع آوری داده ها بتونیم با بقیه همزاد پنداری کنیم.
👈 مرحله ی دوم تعریف مسئله (Define): توی این مرحله مشکل رو به شکلی واضح و روشن باید بیان کرد، جوری که همه بتونن درکش کنن.
👈 مرحله ی سوم ایده پردازی (Ideate): توی این مرحله افراد بدون قضاوت ایده هاشون رو میگن و تمرکز روی تعداد ایده هاست نه کیفیتشون.
👈 مرحله ی چهارم نمونهسازی اولیه (Prototype): توی این مرحله باید با ساخت نمونه های اولیه دید که ایده ها توی دنیای واقعی چطوری عمل میکنن
👈 مرحله ی پنجم تست (Test): در واقع نتیجهگیری از این مرحله به شما اجازه میده تا مراحل قبلی رو بررسی کنید که داده های بدست اومده درست بودند یا نه.
به طور خلاصه متد DT یک متد خطی نیست و مداوم شما بین مراحل جابه خواهید شد. یه اشتباه بزرگی که بعضی از تیم ها انجام میدن اینکه مرحله ی درک نیاز رو نادیده میگیرن و مستقیم میرن سراغ مرحله ی ایده پردازی و ساخت محصول اولیه و بعد تازه دنبال مشکلی میگردن که این ایده بتونه حلش کنه.
توی مورد ما مشکل مهدی این بود که بتونه موقع برنامهه نویسی و توی جاده ژانر های مورد علاقشو گوش بده و مشکل قطع و وصلی و تحریم و فیلترینگ نداشته باشه پس نیاز خودش و بقیه ی افرادی که مثل خودش بودند رو درک کرده بود. بعد من بهش پیشنهاد ساخت اپ رو دادم ولی در شروع کار هیچ اپی ساخته نشد و شروع کردیم فقط فیدبک گرفتن از کاربر ها که اصلا اپی نیاز دارن یا نه و به نظرشون چه طراحی و ویژگی هایی میتونه براشون جذابیت داشته باشه.
اگه دوس داشتید بیشتر راجب DT بدونید این مقاله رو بخونید:
🔗 The 5 Stages in the Design Thinking Process
این بود خلاصه ای از مرحله ی شروع ایده و ادامه دارد...
🆔 @MdDailyYour current plan allows analytics for only 5 channels. To get more, please choose a different plan.