⚜️ چرا یاد گرفتن Product Thinking اینقدر ذهنم رو خسته میکنه؟
هر بار که میخوام یه مفهوم جدید توی Product یاد بگیرم، یه فشار ذهنی عجیبی حس میکنم. یه مدت بود داشتم فکر میکردم این حس از کجا میاد و به نظرم سه تا دلیل داره:
🔻 ۱. ذهنم دنبال جواب قطعیه.
فکر میکنم این عادت از بکگراند فنیم اومده. توی مسائل فنی معمولاً صورتمسئله شفافتره و خیلی وقتها یه جواب درست یا حداقل یه راهحل بهینه وجود داره. ولی مسائل محصولی اینجوری نیستن. خیلیهاشون از جنس Wicked Problem هستن؛ یعنی نه جواب قطعی دارن، نه مسیر حل مشخص.
شاید اگر این تفاوت رو واقعاً بپذیرم، دیگه از خودم انتظار نداشته باشم که برای هر سؤال یه جواب نهایی پیدا کنم. شاید فقط باید به خودم زمان بدم تا کمکم با ابهام راحتتر بشم.
🔻۲. زیادی درگیر ابزارها و مدلها میشم.
یه چیز دیگه که متوجهش شدم اینه که گاهی بیش از حد درگیر ابزارها و مدلهای ذهنی میشم. هر بار یه ابزار یا مدل جدید میبینم، یه حس FOMO میاد سراغم که «اینم باید یاد بگیرم، وگرنه یه چیزی کم دارم.» ولی هرچی بیشتر فکر میکنم، بیشتر به این نتیجه میرسم که شاید این فقط یه خطای ذهنیه.
ذهن ما حتی بدون اینکه اسم مدلها رو بدونه، خودش دائم داره مدلسازی میکنه. مدلهای ذهنی فقط کمک میکنن این مدلسازی شفافتر بشه. اصلاً ارزششون هم به این نیست که کاملاً درست باشن؛ به اینه که به درد بخورن.
در مورد ابزارها هم همینطوره. ممکنه بهترین ابزار دنیا رو نداشته باشم، ولی اگر روی همون ابزاری که دارم مسلط باشم، معمولاً میتونم کارم رو جلو ببرم.
یادداشتبرداری مثال خوبیه. قلم و کاغذ از Notion یا Obsidian محدودتره، ولی هنوز هم میشه باهاش یادداشتهای خوب و کاربردی نوشت. نمیگم ابزار مهم نیست. فقط فکر میکنم قبل از اینکه برم یه ابزار جدید یاد بگیرم، بهتره از خودم بپرسم: برای چه هدف و کارکردی میخوام این ابزار رو یاد بگیرم؟
🔻۳. گم شدن
هرچی بیشتر بهش فکر میکنم، حس میکنم مشکل اصلی نه ابزارها هستن، نه مدلهای ذهنی. مشکل اینه که وسط مسیر، گم میشم و با یه صفحه مشکی (بسته به تنظیمات تم مغزتون میتونه برای شما سفید هم باشه) مواجه میشم و عملا مغزم به بنبست میخوره و نمیدونه از کجا مسئله رو از سر بگیره. همین باعث میشه از این مقاله به اون مقاله برم، از این مدل و ابزار به اون یکی، بدون اینکه واقعاً بدونم دنبال چی میگردم.
🔻راهکاری که فکر میکنم جواب بده:
فکر میکنم اگر یک فریمورک شخصی بسازم و ذهنم رو مرتب کنم، این مشکلات هم حل بشن. یعنی چی؟ برای من، بالاترین سطحی که میتونم ازش به ساخت محصول نگاه کنم، Product Life Cycle ئـه.
اگر کل فرآیند ساخت محصول رو به Stageهای مختلف بشکنم و هر Stage رو هم به Substageهای کوچیکتر تقسیم کنم، اون وقت برای هر مرحله میتونم یه Context مشخص بسازم.
منظور از Context چیه؟ مثلاً Product Discovery رو میتونیم به Solution Validation ،Problem Validation و ... بشکنیم.
بعد برای هر کدوم از این مرحلهها، Context رو میتونیم مجموعهای از این سوالات در نظر بگیریم:
— هدف این مرحله چیه؟
— چه Modelهایی اینجا به دردم میخورن؟
— چه Heuristicهایی معمولاً جواب میدن؟
— چه ابزارهایی براش بلدم و تو جعبه ابزارم هست؟
— خروجی این مرحله باید چی باشه؟
این سؤالها کمک میکنن قبل از اینکه برم دنبال ابزار یا مدل جدید، بتونم یه نقشهای داشته باشم که مثل گیمها موقع گم شدن، بهش رجوع کنم.
احتمالاً نسخه اولش خیلی ناقص و حتی اشتباه از آب درمیاد. ولی اشکالی نداره، مهم اینه که در حال حاضر برای مغز من قابل فهم باشه و چرخش برام بچرخه.
از همه مهمتر، فکر نمیکنم یه Framework درست برای همه وجود داشته باشه. ممکنه یه مدل ذهنی یا یه ابزار برای من خیلی کاربردی باشه، ولی برای یکی دیگه جواب نده. هر چند البته که میشه از هم ایده گرفت.
💭 نگاه شما چیه؟ نکتهای هست که بخوایید اضافه کنید؟
#product #thinkingOutLoud
هر بار که میخوام یه مفهوم جدید توی Product یاد بگیرم، یه فشار ذهنی عجیبی حس میکنم. یه مدت بود داشتم فکر میکردم این حس از کجا میاد و به نظرم سه تا دلیل داره:
🔻 ۱. ذهنم دنبال جواب قطعیه.
فکر میکنم این عادت از بکگراند فنیم اومده. توی مسائل فنی معمولاً صورتمسئله شفافتره و خیلی وقتها یه جواب درست یا حداقل یه راهحل بهینه وجود داره. ولی مسائل محصولی اینجوری نیستن. خیلیهاشون از جنس Wicked Problem هستن؛ یعنی نه جواب قطعی دارن، نه مسیر حل مشخص.
شاید اگر این تفاوت رو واقعاً بپذیرم، دیگه از خودم انتظار نداشته باشم که برای هر سؤال یه جواب نهایی پیدا کنم. شاید فقط باید به خودم زمان بدم تا کمکم با ابهام راحتتر بشم.
🔻۲. زیادی درگیر ابزارها و مدلها میشم.
یه چیز دیگه که متوجهش شدم اینه که گاهی بیش از حد درگیر ابزارها و مدلهای ذهنی میشم. هر بار یه ابزار یا مدل جدید میبینم، یه حس FOMO میاد سراغم که «اینم باید یاد بگیرم، وگرنه یه چیزی کم دارم.» ولی هرچی بیشتر فکر میکنم، بیشتر به این نتیجه میرسم که شاید این فقط یه خطای ذهنیه.
ذهن ما حتی بدون اینکه اسم مدلها رو بدونه، خودش دائم داره مدلسازی میکنه. مدلهای ذهنی فقط کمک میکنن این مدلسازی شفافتر بشه. اصلاً ارزششون هم به این نیست که کاملاً درست باشن؛ به اینه که به درد بخورن.
در مورد ابزارها هم همینطوره. ممکنه بهترین ابزار دنیا رو نداشته باشم، ولی اگر روی همون ابزاری که دارم مسلط باشم، معمولاً میتونم کارم رو جلو ببرم.
یادداشتبرداری مثال خوبیه. قلم و کاغذ از Notion یا Obsidian محدودتره، ولی هنوز هم میشه باهاش یادداشتهای خوب و کاربردی نوشت. نمیگم ابزار مهم نیست. فقط فکر میکنم قبل از اینکه برم یه ابزار جدید یاد بگیرم، بهتره از خودم بپرسم: برای چه هدف و کارکردی میخوام این ابزار رو یاد بگیرم؟
🔻۳. گم شدن
هرچی بیشتر بهش فکر میکنم، حس میکنم مشکل اصلی نه ابزارها هستن، نه مدلهای ذهنی. مشکل اینه که وسط مسیر، گم میشم و با یه صفحه مشکی (بسته به تنظیمات تم مغزتون میتونه برای شما سفید هم باشه) مواجه میشم و عملا مغزم به بنبست میخوره و نمیدونه از کجا مسئله رو از سر بگیره. همین باعث میشه از این مقاله به اون مقاله برم، از این مدل و ابزار به اون یکی، بدون اینکه واقعاً بدونم دنبال چی میگردم.
🔻راهکاری که فکر میکنم جواب بده:
فکر میکنم اگر یک فریمورک شخصی بسازم و ذهنم رو مرتب کنم، این مشکلات هم حل بشن. یعنی چی؟ برای من، بالاترین سطحی که میتونم ازش به ساخت محصول نگاه کنم، Product Life Cycle ئـه.
اگر کل فرآیند ساخت محصول رو به Stageهای مختلف بشکنم و هر Stage رو هم به Substageهای کوچیکتر تقسیم کنم، اون وقت برای هر مرحله میتونم یه Context مشخص بسازم.
منظور از Context چیه؟ مثلاً Product Discovery رو میتونیم به Solution Validation ،Problem Validation و ... بشکنیم.
بعد برای هر کدوم از این مرحلهها، Context رو میتونیم مجموعهای از این سوالات در نظر بگیریم:
— هدف این مرحله چیه؟
— چه Modelهایی اینجا به دردم میخورن؟
— چه Heuristicهایی معمولاً جواب میدن؟
— چه ابزارهایی براش بلدم و تو جعبه ابزارم هست؟
— خروجی این مرحله باید چی باشه؟
این سؤالها کمک میکنن قبل از اینکه برم دنبال ابزار یا مدل جدید، بتونم یه نقشهای داشته باشم که مثل گیمها موقع گم شدن، بهش رجوع کنم.
احتمالاً نسخه اولش خیلی ناقص و حتی اشتباه از آب درمیاد. ولی اشکالی نداره، مهم اینه که در حال حاضر برای مغز من قابل فهم باشه و چرخش برام بچرخه.
از همه مهمتر، فکر نمیکنم یه Framework درست برای همه وجود داشته باشه. ممکنه یه مدل ذهنی یا یه ابزار برای من خیلی کاربردی باشه، ولی برای یکی دیگه جواب نده. هر چند البته که میشه از هم ایده گرفت.
💭 نگاه شما چیه؟ نکتهای هست که بخوایید اضافه کنید؟
#product #thinkingOutLoud
❤1
ممکنه بعضی وقتا پیامهای این کانال رو که میخونید حس کنید لحن متنها دقیقاً لحن خودم نیست، یا حتی فکر کنید AI توی آماده شدنشون نقش داشته.
واقعیتش اینه که برای اینکه بتونم زمان و انرژیم رو بهتر مدیریت کنم، مجبورم سعی کنم با کمترین هزینه، بیشترین خروجی رو بگیرم.
روشی که بهش رسیدم اینه که اول با ابزارهای تبدیل گفتار به نوشتار، هر چی توی ذهنمه رو به شکل یه Brain Dump ثبت میکنم. یعنی ایدهها، ترتیب مطالب و حتی بخش زیادی از جملهبندیها از خودمه و AI متن رو از صفر نمینویسه.
بعدش فقط از AI میخوام متن رو یه کم مرتبتر و روونتر کنه؛ با این تأکید که ساختار جملهها، منظور و سبک بیانم حفظ بشه و فقط متن محاورهایتر و خوشخوانتر بشه، چون خروجی اولیه معمولاً زیادی رسمی و کتابی درمیاد.
خلاصه اینکه حضورتون برام خیلی ارزشمنده و اصلاً دوست ندارم وقتتون با محتوایی که کامل توسط AI تولید شده هدر بره. چیزی که میخونید همچنان حرفها و نگاه خودمه؛ AI فقط کمک میکنه همون حرفها شفافتر و راحتتر منتقل بشن.
#bip #ai
واقعیتش اینه که برای اینکه بتونم زمان و انرژیم رو بهتر مدیریت کنم، مجبورم سعی کنم با کمترین هزینه، بیشترین خروجی رو بگیرم.
روشی که بهش رسیدم اینه که اول با ابزارهای تبدیل گفتار به نوشتار، هر چی توی ذهنمه رو به شکل یه Brain Dump ثبت میکنم. یعنی ایدهها، ترتیب مطالب و حتی بخش زیادی از جملهبندیها از خودمه و AI متن رو از صفر نمینویسه.
بعدش فقط از AI میخوام متن رو یه کم مرتبتر و روونتر کنه؛ با این تأکید که ساختار جملهها، منظور و سبک بیانم حفظ بشه و فقط متن محاورهایتر و خوشخوانتر بشه، چون خروجی اولیه معمولاً زیادی رسمی و کتابی درمیاد.
خلاصه اینکه حضورتون برام خیلی ارزشمنده و اصلاً دوست ندارم وقتتون با محتوایی که کامل توسط AI تولید شده هدر بره. چیزی که میخونید همچنان حرفها و نگاه خودمه؛ AI فقط کمک میکنه همون حرفها شفافتر و راحتتر منتقل بشن.
#bip #ai
❤4
⚜️ بیاید کمی بیشتر درباره دارویار صحبت کنیم =)
اینکه چطور به این ایده رسیدم، الان تو چه مرحلهای هستم و چرا تصمیم گرفتم مسیر توسعهش رو یه کم تغییر بدم.
تا الان دارویار رو همیشه اینطوری تو یه خط معرفی میکردم:
تا همین اواخر فکر میکردم باید محصولی بسازم که برای همه بیماران خاص کاربرد داشته باشه، اما هرچی بیشتر فکر کردم، متوجه شدم احتمالاً این انتخاب درستی برای شروع نیست.
فهمیدم مدیریت دارو تو بیماریهای مختلف تفاوتهای زیادی داره. الگوی مصرف دارو، شکلهای دارویی، محدودیتها و حتی ترجیح افراد برای مدیریت موجودی با هم فرق میکنه. مثلاً یه فرد مبتلا به دیابت بیشتر با قلم انسولین، کارتریج، سوزن و نگهداری دارو تو دمای مناسب سروکار داره، اما تو تالاسمی معمولاً فرد همزمان چند دارو با شکلهای مختلف مصرف میکنه و مدیریت موجودی اهمیت بیشتری پیدا میکنه؛ مثلاً اینکه داروها بر اساس تاریخ انقضا (First Expired, First Out) مصرف بشن یا بر اساس ترتیب ورود به موجودی (First In, First Out). همین تفاوتها باعث میشه طراحی راهکاری که از همون اول همه این سناریوها رو پوشش بده، بیش از حد پیچیده بشه.
از طرف دیگه، این اولین تجربه جدی من تو Product Discovery ئه، برای همین ترجیح میدم دامنه مسئله رو تا جای ممکن کوچیک نگه دارم تا بتونم عمیقتر درکش کنم، فرضیهها رو بهتر اعتبارسنجی کنم و در نهایت محصولی بسازم که واقعاً برای کاربرها ارزش ایجاد کنه.
📌 به همین خاطر، تصمیم گرفتم فقط روی یه بیماری تمرکز کنم: تالاسمی.
دلیل این انتخاب فقط آشنایی من با این بیماری نیست. سالهاست خودم باهاش زندگی میکنم و خیلی از چالشهایی که دارویار قراره حل کنه رو از نزدیک تجربه کردم. علاوه بر این، دسترسی خوبی به جامعه هدف دارم و همین موضوع انجام مصاحبه، گرفتن بازخورد و اعتبارسنجی ایدهها رو خیلی سادهتر میکنه.
البته این موضوع یه چالش هم داره. وقتی خودت بخشی از مسئلهای، ممکنه ناخواسته تو تعریف مسئله یا انتخاب راهحلها دچار سوگیری بشی. به خاطر همین سعی میکنم تا جای ممکن به اصول Product Discovery پایبند بمونم و تصمیمها رو بر اساس داده، مصاحبه و نیاز واقعی کاربرها بگیرم، نه صرفاً تجربه شخصی خودم.
امیدوارم با این رویکرد بتونم قدمبهقدم دارویار رو به محصولی تبدیل کنم که واقعاً برای کاربرهاش مفید، ارزشمند و قابل اتکا باشه.
#daruyar #decision
اینکه چطور به این ایده رسیدم، الان تو چه مرحلهای هستم و چرا تصمیم گرفتم مسیر توسعهش رو یه کم تغییر بدم.
تا الان دارویار رو همیشه اینطوری تو یه خط معرفی میکردم:
یه سیستم مدیریت موجودی دارو توی خونه، با تمرکز روی بیماران خاص.
تا همین اواخر فکر میکردم باید محصولی بسازم که برای همه بیماران خاص کاربرد داشته باشه، اما هرچی بیشتر فکر کردم، متوجه شدم احتمالاً این انتخاب درستی برای شروع نیست.
فهمیدم مدیریت دارو تو بیماریهای مختلف تفاوتهای زیادی داره. الگوی مصرف دارو، شکلهای دارویی، محدودیتها و حتی ترجیح افراد برای مدیریت موجودی با هم فرق میکنه. مثلاً یه فرد مبتلا به دیابت بیشتر با قلم انسولین، کارتریج، سوزن و نگهداری دارو تو دمای مناسب سروکار داره، اما تو تالاسمی معمولاً فرد همزمان چند دارو با شکلهای مختلف مصرف میکنه و مدیریت موجودی اهمیت بیشتری پیدا میکنه؛ مثلاً اینکه داروها بر اساس تاریخ انقضا (First Expired, First Out) مصرف بشن یا بر اساس ترتیب ورود به موجودی (First In, First Out). همین تفاوتها باعث میشه طراحی راهکاری که از همون اول همه این سناریوها رو پوشش بده، بیش از حد پیچیده بشه.
از طرف دیگه، این اولین تجربه جدی من تو Product Discovery ئه، برای همین ترجیح میدم دامنه مسئله رو تا جای ممکن کوچیک نگه دارم تا بتونم عمیقتر درکش کنم، فرضیهها رو بهتر اعتبارسنجی کنم و در نهایت محصولی بسازم که واقعاً برای کاربرها ارزش ایجاد کنه.
📌 به همین خاطر، تصمیم گرفتم فقط روی یه بیماری تمرکز کنم: تالاسمی.
دلیل این انتخاب فقط آشنایی من با این بیماری نیست. سالهاست خودم باهاش زندگی میکنم و خیلی از چالشهایی که دارویار قراره حل کنه رو از نزدیک تجربه کردم. علاوه بر این، دسترسی خوبی به جامعه هدف دارم و همین موضوع انجام مصاحبه، گرفتن بازخورد و اعتبارسنجی ایدهها رو خیلی سادهتر میکنه.
البته این موضوع یه چالش هم داره. وقتی خودت بخشی از مسئلهای، ممکنه ناخواسته تو تعریف مسئله یا انتخاب راهحلها دچار سوگیری بشی. به خاطر همین سعی میکنم تا جای ممکن به اصول Product Discovery پایبند بمونم و تصمیمها رو بر اساس داده، مصاحبه و نیاز واقعی کاربرها بگیرم، نه صرفاً تجربه شخصی خودم.
امیدوارم با این رویکرد بتونم قدمبهقدم دارویار رو به محصولی تبدیل کنم که واقعاً برای کاربرهاش مفید، ارزشمند و قابل اتکا باشه.
#daruyar #decision
❤2
تا اینجا ایده دارویار رو داریم که تو دل خودش یه فهمی از مسئله رو داره و همراه با یه راهکار پیشنهادی هستش. ولی میدونیم که هم درک ما از مسئله و هم خود راهکار، پر از فرضیهان و باید اعتبارسنجی بشن.
اگه قرار باشه Product Discovery رو از همین نقطه شروع کنیم، اولین قدمتون چیه؟ و چرا؟
#daruyar #product #question
اگه قرار باشه Product Discovery رو از همین نقطه شروع کنیم، اولین قدمتون چیه؟ و چرا؟
#daruyar #product #question
❤2
الان یکیدو روزه دارم دربارهی Product Discovery میخونم؛ اینکه اولین قدم دقیقاً چیه و اصلاً باید از کجا شروع کرد.
به این رسیدم که برای شروع بهتره Domain Map ساخت. با اینکه تمرکز پروژهمون روی مدیریت مصرف دارو برای بیماران تالاسمیه، ولی بهتره یک قدم عقبتر برگشت و اول یه Life Domain Map از کل زندگی بیمار ترسیم کرد. داشتن یه تصویر کاملتر از زندگی کاربر هدف باعث میشه تصمیمات آگاهانهتری تو حوزه تمرکزمون بگیریم.
یه تشبیه باحال هم برای خودم پیدا کردم؛ همونطور که توی دنیای بازیها از Map برای navigate کردن در جهان بازی استفاده میکنیم، از Domain Map هم میشه برای navigate کردن در فهم خودمون از مسئله استفاده کرد.
این Map برای من خیلی شبیه مپ بازیهای Metroidvania است؛ اولش ناقصه و به مرور کاملتر میشه؛ درست مثل فهممون از مسئله. همینطور باید توجه داشت که جواب درست و غلطی هم وجود نداره و ممکنه آدمای مختلف جور دیگهای مپ کنن. مادامی که کمک میکنه شفافتر فکر کنیم و ذهنمون مرتب بشه، یعنی داره کارش رو درست انجام میده.
در مجموع، همهی اینها برام ارزشمند بود و واقعاً حس میکردم دارم چیزهای جدید یاد میگیرم. اما همزمان یه حس آزاردهنده هم داشتم؛ اینکه هرچی بیشتر میخونم، انگار بیشتر از خود پروژه و دارویار فاصله میگیرم. یه جور حس درجا زدن؛ انگار بهجای نزدیکتر شدن به مسئله، مدام دارم دربارهی روشهای نزدیک شدن به مسئله مطالعه میکنم.
الان بیشتر به این نتیجه رسیدم که وقتشه دوباره برگردم به خود مسئله و دارویار رو تو مرکز توجهم قرار بدم. ببینم مهمترین ریسکها چی هستن، چه ابهامهایی وجود داره و کدوم فرضیهها باید validate بشن. نمیخوام اونقدر درگیر فریمورکها و مفاهیم بشم که از مسئلهی واقعی فاصله بگیرم.
#daruyar #product #thinkingOutLoud
به این رسیدم که برای شروع بهتره Domain Map ساخت. با اینکه تمرکز پروژهمون روی مدیریت مصرف دارو برای بیماران تالاسمیه، ولی بهتره یک قدم عقبتر برگشت و اول یه Life Domain Map از کل زندگی بیمار ترسیم کرد. داشتن یه تصویر کاملتر از زندگی کاربر هدف باعث میشه تصمیمات آگاهانهتری تو حوزه تمرکزمون بگیریم.
یه تشبیه باحال هم برای خودم پیدا کردم؛ همونطور که توی دنیای بازیها از Map برای navigate کردن در جهان بازی استفاده میکنیم، از Domain Map هم میشه برای navigate کردن در فهم خودمون از مسئله استفاده کرد.
این Map برای من خیلی شبیه مپ بازیهای Metroidvania است؛ اولش ناقصه و به مرور کاملتر میشه؛ درست مثل فهممون از مسئله. همینطور باید توجه داشت که جواب درست و غلطی هم وجود نداره و ممکنه آدمای مختلف جور دیگهای مپ کنن. مادامی که کمک میکنه شفافتر فکر کنیم و ذهنمون مرتب بشه، یعنی داره کارش رو درست انجام میده.
در مجموع، همهی اینها برام ارزشمند بود و واقعاً حس میکردم دارم چیزهای جدید یاد میگیرم. اما همزمان یه حس آزاردهنده هم داشتم؛ اینکه هرچی بیشتر میخونم، انگار بیشتر از خود پروژه و دارویار فاصله میگیرم. یه جور حس درجا زدن؛ انگار بهجای نزدیکتر شدن به مسئله، مدام دارم دربارهی روشهای نزدیک شدن به مسئله مطالعه میکنم.
الان بیشتر به این نتیجه رسیدم که وقتشه دوباره برگردم به خود مسئله و دارویار رو تو مرکز توجهم قرار بدم. ببینم مهمترین ریسکها چی هستن، چه ابهامهایی وجود داره و کدوم فرضیهها باید validate بشن. نمیخوام اونقدر درگیر فریمورکها و مفاهیم بشم که از مسئلهی واقعی فاصله بگیرم.
#daruyar #product #thinkingOutLoud
❤4
⚜️ پیچیدگیهای ذاتی مسئله
فکر میکنم قبل از اینکه برم سراغ مصاحبه با کاربرها و اعتبارسنجی Pain Pointها، نیازها و Jobهایی که انتظار دارم دارویار برای کاربرهاش انجام بده، بهتره اول به یک سری پیچیدگیهای ذاتی مسئله فکر کنم. پیچیدگیهایی که اگه بهشون پرداخته نشه، حتی بهترین طراحی و تجربه کاربری هم نمیتونه محصول رو به موفقیت برسونه.
چالشهایی که تا الان تونستم برای دارویار تشخیص بدم اینها هستن:
🔻قابل اتکا بودن موجودی نمایش داده شده در اپلیکیشن
ارزش دارویار زمانی شکل میگیره که کاربر بتونه به موجودی نمایشدادهشده اعتماد کنه و بر اساسش تصمیم بگیره. اما چون بهروز نگه داشتن موجودی تا حد زیادی به مشارکت خود کاربر وابستهست، به مرور ممکنه بین موجودی واقعی و اطلاعات داخل اپ اختلاف ایجاد بشه. اگر بهروز نگه داشتن این اطلاعات برای کاربر زحمت بیشتری از ارزشی که دریافت میکنه داشته باشه، احتمالاً اعتمادش رو از دست میده و کمکم استفاده از محصول رو کنار میذاره.
🔻اعتماد کاربران به ثبت اطلاعات
دارویار برای اینکه بتونه ارزش ایجاد کنه، به اطلاعات موجودی داروهای کاربران نیاز داره. اما ممکنه بعضی از کاربران به خاطر نگرانیهای مربوط به حریم خصوصی، ترس از سوءاستفاده یا حتی حساسیت ناشی از کمبود دارو، حاضر نباشن موجودی واقعی خودشون رو ثبت کنن.
🔻ریسکهای حقوقی و رگولاتوری
دارویار با اطلاعات دارویی کاربران سروکار داره و ممکنه در آینده قابلیتهایی مثل شناسایی داروهای مازاد یا ایجاد ارتباط بین بیماران رو هم اضافه کنه. همین موضوع میتونه حساسیت نهادهای قانونگذار رو برانگیزه. اگر محصول بهعنوان ابزاری برای توزیع غیرمجاز دارو یا فعالیت خارج از چارچوب قوانین شناخته بشه، ممکنه با محدودیتهای قانونی، الزام به تغییر محصول یا حتی توقف فعالیت روبهرو بشه.
🔻وابستگی ارزش محصول به کمبود دارو
الان بخش زیادی از ارزش پیشنهادی دارویار روی مدیریت موجودی در شرایط کمبود دارو بنا شده. اگر کاربر در شرایطی باشه که دارو همیشه بهراحتی در دسترسه، احتمالاً انگیزه زیادی برای ثبت و مدیریت موجودی خودش نخواهد داشت. در نتیجه، ارزش محصول برای بخشی از کاربران کمتر میشه و ممکنه بازار هدف، کوچکتر از چیزی باشه که الان تصور میکنیم.
موارد مطرح شده به ترتیب الویت بودن. باید روی اینها فکر و به نوعی وجود داشتنشون رو ولیدیت کنم و ببینم چطور میشه هندلشون کرد.
#daruyar #product
فکر میکنم قبل از اینکه برم سراغ مصاحبه با کاربرها و اعتبارسنجی Pain Pointها، نیازها و Jobهایی که انتظار دارم دارویار برای کاربرهاش انجام بده، بهتره اول به یک سری پیچیدگیهای ذاتی مسئله فکر کنم. پیچیدگیهایی که اگه بهشون پرداخته نشه، حتی بهترین طراحی و تجربه کاربری هم نمیتونه محصول رو به موفقیت برسونه.
چالشهایی که تا الان تونستم برای دارویار تشخیص بدم اینها هستن:
🔻قابل اتکا بودن موجودی نمایش داده شده در اپلیکیشن
ارزش دارویار زمانی شکل میگیره که کاربر بتونه به موجودی نمایشدادهشده اعتماد کنه و بر اساسش تصمیم بگیره. اما چون بهروز نگه داشتن موجودی تا حد زیادی به مشارکت خود کاربر وابستهست، به مرور ممکنه بین موجودی واقعی و اطلاعات داخل اپ اختلاف ایجاد بشه. اگر بهروز نگه داشتن این اطلاعات برای کاربر زحمت بیشتری از ارزشی که دریافت میکنه داشته باشه، احتمالاً اعتمادش رو از دست میده و کمکم استفاده از محصول رو کنار میذاره.
🔻اعتماد کاربران به ثبت اطلاعات
دارویار برای اینکه بتونه ارزش ایجاد کنه، به اطلاعات موجودی داروهای کاربران نیاز داره. اما ممکنه بعضی از کاربران به خاطر نگرانیهای مربوط به حریم خصوصی، ترس از سوءاستفاده یا حتی حساسیت ناشی از کمبود دارو، حاضر نباشن موجودی واقعی خودشون رو ثبت کنن.
🔻ریسکهای حقوقی و رگولاتوری
دارویار با اطلاعات دارویی کاربران سروکار داره و ممکنه در آینده قابلیتهایی مثل شناسایی داروهای مازاد یا ایجاد ارتباط بین بیماران رو هم اضافه کنه. همین موضوع میتونه حساسیت نهادهای قانونگذار رو برانگیزه. اگر محصول بهعنوان ابزاری برای توزیع غیرمجاز دارو یا فعالیت خارج از چارچوب قوانین شناخته بشه، ممکنه با محدودیتهای قانونی، الزام به تغییر محصول یا حتی توقف فعالیت روبهرو بشه.
🔻وابستگی ارزش محصول به کمبود دارو
الان بخش زیادی از ارزش پیشنهادی دارویار روی مدیریت موجودی در شرایط کمبود دارو بنا شده. اگر کاربر در شرایطی باشه که دارو همیشه بهراحتی در دسترسه، احتمالاً انگیزه زیادی برای ثبت و مدیریت موجودی خودش نخواهد داشت. در نتیجه، ارزش محصول برای بخشی از کاربران کمتر میشه و ممکنه بازار هدف، کوچکتر از چیزی باشه که الان تصور میکنیم.
موارد مطرح شده به ترتیب الویت بودن. باید روی اینها فکر و به نوعی وجود داشتنشون رو ولیدیت کنم و ببینم چطور میشه هندلشون کرد.
#daruyar #product
❤1
⚜️ اعتبارسنجی فرضیهها یا تکیه بر شهود
درسته که همیشه توصیه میشه بر اساس فرضیات پیش نریم، ولی فکر میکنم این نباید باعث بشه به این اشتباه بیفتیم که هر فرضیهای حتماً باید اعتبارسنجی بشه. اعتبارسنجی هم هزینهی خودش رو داره. به نظرم کاملاً منطقیه که اگر احساس میکنیم هزینهی اعتبارسنجی از ارزش اطلاعاتی که قراره به دست بیاریم بیشتره، با همون فرض جلو بریم.
مثلاً دربارهی چالشهایی که در پیام قبلی آوردم، میدونم که «اعتماد کاربران به ثبت اطلاعات» یه فرضیهست و طبق آموزههای Product باید ولیدیت بشه. اما چون راهکاری که براش در نظر دارم (offline-first بودن اپ)، چالش بعدی یعنی «ریسکهای حقوقی و رگولاتوری» رو هم تا حد زیادی پوشش میده و در عمل هزینهی اضافهای هم برام نداره، به نظرم منطقیه که بدون ولیدیت کردن اون فرضیه، همین مسیر رو ادامه بدم.
یه صدایی توی مغزم میگه: «خب، اینکه فکر میکنی offline-first بودن این مشکل رو حل میکنه هم خودش یه فرضیهست!»
جوابش اینه که: آره، هست. ولی خب... میگی چیکاااار کنم؟ =)))
جدا از شوخی، واقعاً فکر میکنم مرز بین اینکه کجا باید ولیدیت کنیم و کجا میتونیم به قضاوت خودمون تکیه کنیم، یه مهارته که به مرور و با شکل گرفتن شهود بهتر، متعادلتر میشه.
🔻 پی نوشت:
همین متن رو به GPT دادم و در تأیید این ایده به مفهوم Value of Information (VOI) اشاره کرد:
به نظرم این نگاه، معیار خوبی برای تصمیم گرفتن دربارهی اعتبارسنجی فرضیاته.
#daruyar #product #thinkingOutLoud
درسته که همیشه توصیه میشه بر اساس فرضیات پیش نریم، ولی فکر میکنم این نباید باعث بشه به این اشتباه بیفتیم که هر فرضیهای حتماً باید اعتبارسنجی بشه. اعتبارسنجی هم هزینهی خودش رو داره. به نظرم کاملاً منطقیه که اگر احساس میکنیم هزینهی اعتبارسنجی از ارزش اطلاعاتی که قراره به دست بیاریم بیشتره، با همون فرض جلو بریم.
مثلاً دربارهی چالشهایی که در پیام قبلی آوردم، میدونم که «اعتماد کاربران به ثبت اطلاعات» یه فرضیهست و طبق آموزههای Product باید ولیدیت بشه. اما چون راهکاری که براش در نظر دارم (offline-first بودن اپ)، چالش بعدی یعنی «ریسکهای حقوقی و رگولاتوری» رو هم تا حد زیادی پوشش میده و در عمل هزینهی اضافهای هم برام نداره، به نظرم منطقیه که بدون ولیدیت کردن اون فرضیه، همین مسیر رو ادامه بدم.
یه صدایی توی مغزم میگه: «خب، اینکه فکر میکنی offline-first بودن این مشکل رو حل میکنه هم خودش یه فرضیهست!»
جوابش اینه که: آره، هست. ولی خب... میگی چیکاااار کنم؟ =)))
جدا از شوخی، واقعاً فکر میکنم مرز بین اینکه کجا باید ولیدیت کنیم و کجا میتونیم به قضاوت خودمون تکیه کنیم، یه مهارته که به مرور و با شکل گرفتن شهود بهتر، متعادلتر میشه.
🔻 پی نوشت:
همین متن رو به GPT دادم و در تأیید این ایده به مفهوم Value of Information (VOI) اشاره کرد:
اطلاعات ذاتاً ارزشمند نیست؛ ارزش اطلاعات به این بستگی داره که آیا باعث میشه تصمیم بهتری بگیریم یا نه.
به نظرم این نگاه، معیار خوبی برای تصمیم گرفتن دربارهی اعتبارسنجی فرضیاته.
#daruyar #product #thinkingOutLoud
❤1
⚜️ دو زاویه دید متفاوت برای توصیف گزارههای Product Discovery
🔻 در Product Discovery برای نشون دادن رابطهمون با گزارههایی که دربارهی محصول بیان میکنیم، میتونیم از یکسری Statement استفاده کنیم:
Observation, Assumption, Risk, Concern, Fact, Hypothesis, Claim, Decision
— هر کدوم از ما ممکنه تعریف متفاوتی از هر یک از این عبارتها داشته باشیم که به نظرم مهم نیست. فکر نمیکنم درست و غلط سفتوسختی وجود داشته باشه. مهم اینه که استفاده از این دستهبندیها باعث شفافیت توی افکارمون بشه و اگر هم بهصورت تیمی کار میکنیم، بتونیم با فهم و ادبیات مشترکی با هم کامیونیکیت کنیم.
— بعضی از این عبارتها مرز باریکی با هم دارن و ممکنه در ابتدا سردرگمکننده باشن. برای همین لازمه کمی بهشون فکر کنیم، مثالهای مختلف رو مرور کنیم و در نهایت مرزهاشون رو برای خودمون شفافتر کنیم. مثلاً Assumption، Claim و Hypothesis ممکنه به هم نزدیک به نظر برسن؛ یا همینطور Risk و Concern.
— یه نکتهی خیلی مهم به نظرم وجود داره. کار این Statementها Represent کردن وضعیت فعلی فهم ما از مسئلهست. این فهم ممکنه اشتباه باشه، اما اگر بتونه همون فهم اشتباه رو بهدرستی ابراز کنه، یعنی ما این قسمت از کارمون رو درست انجام دادیم.
— مثلاً ممکنه یه چیزی رو Decision بدونیم و بهعنوان یک Decision Statement ثبت و مطرحش کنیم. بعداً شاید معلوم بشه اون تصمیم اشتباه بوده، ولی این مهم نیست. مهم اینه که در اون لحظه، اون موضوع واقعاً یک Decision بوده و باید با ادبیات متناسب با یک Decision Statement بیان میشده، نه مثلاً به شکل یک Assumption یا Risk.
— حس میکنم وقتی این مفاهیم از هم تفکیک نباشن، ذهنمون هم آشفته میشه. نه میتونیم منظورمون رو دقیق منتقل کنیم و نه فرآیند فکر کردنمون شفاف پیش میره. اما وقتی بدونیم هر ایده یا گزاره دقیقاً در کدوم دسته قرار میگیره، هم ارتباط مؤثرتری خواهیم داشت و هم خودمون منظمتر و شفافتر فکر میکنیم.
🔻 یه سؤال توی ذهنم شکل گرفته بود که این عبارتها چه فرقی با عبارتهایی مثل Pain Point، Needs، Wants، Job و... دارن؟
— به این نتیجه رسیدم که اونها برچسبهای مفهومی هستن، ولی اینهایی که بالاتر گفتم، برچسبهای رابطهای هستن. یعنی به یک گزاره میشه از هر دو دسته برچسب نسبت داد و هر کدوم از یک بُعد به بیان دقیقترش کمک میکنن.
— مثلاً وقتی توی مصاحبه میشنویم که مصاحبهشونده میگه «من فلان مشکل یا درد رو دارم»، در همون لحظه میدونیم جملهای که داریم ثبت میکنیم، از نظر مفهومی یک Pain Point محسوب میشه. اما همزمان باید حواسمون باشه که رابطهی ما با این گزاره هنوز در حد یک Observation هست و هنوز هیچ تحلیلی روش انجام ندادیم.
— بعد از مصاحبه، وقتی دادهها رو تحلیل کردیم، ممکنه همون Pain Point رو در کنار چند مورد دیگه به شکل یک Job بازنویسی کنیم. اما حالا رابطهی ما با اون Job دیگه Observation نیست؛ بلکه یک Assumption محسوب میشه.
— میتونم حدس بزنم که شاید دارم موضوع رو بیش از حد پیچیده میکنم، ولی فعلاً اینطور حس نمیکنم. در این لحظه احساس میکنم اضافه کردن این بُعد رابطهای، کمک میکنه با اصطکاک ذهنی کمتری فکر کنم.
— چون قبلاً همیشه یه حس مبهمی داشتم که مثلاً این Pain Pointای که نوشتیم، صرفاً یک فرض ضعیف از درد کاربره یا واقعاً تقریباً مطمئنیم که دردش همینه؟ چرا توی این ابزارها جایی برای تفکیک و مدل کردن میزان اعتمادمون به یک گزاره، یا به عبارتی همین رابطهای که باهاش داریم، وجود نداره؟ البته اون موقع این مسئله انقدر برام شفاف نبود. فقط یه حس مبهم داشتم که یه جای کار میلنگه و همون ابهام مدام اذیتم میکرد.
— هنوزم سواله برام که چرا واقعا تو ابزارهای مختلفی که تو Miro مثلا وجود داره این رو لحاظ نکردن. میدونم مثلا Assumption map رو داریم ولی اونجا فرض شده همهی گزارههایی که میاریم داخلش Assumption هستن ولی جاهایی که با هم قاطیان اینا، مثل Business Model Canvas یا Value Proposition Canvas چیزی براش نیست.
— من تصمیم گرفتم با گذاشتن Dot Vote های رنگی که تو Miro هست، روی استیکی نوتها اون تفکیک رو قائل شم برای خودم.
💬 اگر شما هم تجربهی مشابهی داشتید یا راهحل بهتری برای مدل کردن این موضوع میشناسید، خوشحال میشم توی کامنتها share کنید.
#product #thinkingOutLoud
🔻 در Product Discovery برای نشون دادن رابطهمون با گزارههایی که دربارهی محصول بیان میکنیم، میتونیم از یکسری Statement استفاده کنیم:
Observation, Assumption, Risk, Concern, Fact, Hypothesis, Claim, Decision
— هر کدوم از ما ممکنه تعریف متفاوتی از هر یک از این عبارتها داشته باشیم که به نظرم مهم نیست. فکر نمیکنم درست و غلط سفتوسختی وجود داشته باشه. مهم اینه که استفاده از این دستهبندیها باعث شفافیت توی افکارمون بشه و اگر هم بهصورت تیمی کار میکنیم، بتونیم با فهم و ادبیات مشترکی با هم کامیونیکیت کنیم.
— بعضی از این عبارتها مرز باریکی با هم دارن و ممکنه در ابتدا سردرگمکننده باشن. برای همین لازمه کمی بهشون فکر کنیم، مثالهای مختلف رو مرور کنیم و در نهایت مرزهاشون رو برای خودمون شفافتر کنیم. مثلاً Assumption، Claim و Hypothesis ممکنه به هم نزدیک به نظر برسن؛ یا همینطور Risk و Concern.
— یه نکتهی خیلی مهم به نظرم وجود داره. کار این Statementها Represent کردن وضعیت فعلی فهم ما از مسئلهست. این فهم ممکنه اشتباه باشه، اما اگر بتونه همون فهم اشتباه رو بهدرستی ابراز کنه، یعنی ما این قسمت از کارمون رو درست انجام دادیم.
— مثلاً ممکنه یه چیزی رو Decision بدونیم و بهعنوان یک Decision Statement ثبت و مطرحش کنیم. بعداً شاید معلوم بشه اون تصمیم اشتباه بوده، ولی این مهم نیست. مهم اینه که در اون لحظه، اون موضوع واقعاً یک Decision بوده و باید با ادبیات متناسب با یک Decision Statement بیان میشده، نه مثلاً به شکل یک Assumption یا Risk.
— حس میکنم وقتی این مفاهیم از هم تفکیک نباشن، ذهنمون هم آشفته میشه. نه میتونیم منظورمون رو دقیق منتقل کنیم و نه فرآیند فکر کردنمون شفاف پیش میره. اما وقتی بدونیم هر ایده یا گزاره دقیقاً در کدوم دسته قرار میگیره، هم ارتباط مؤثرتری خواهیم داشت و هم خودمون منظمتر و شفافتر فکر میکنیم.
🔻 یه سؤال توی ذهنم شکل گرفته بود که این عبارتها چه فرقی با عبارتهایی مثل Pain Point، Needs، Wants، Job و... دارن؟
— به این نتیجه رسیدم که اونها برچسبهای مفهومی هستن، ولی اینهایی که بالاتر گفتم، برچسبهای رابطهای هستن. یعنی به یک گزاره میشه از هر دو دسته برچسب نسبت داد و هر کدوم از یک بُعد به بیان دقیقترش کمک میکنن.
— مثلاً وقتی توی مصاحبه میشنویم که مصاحبهشونده میگه «من فلان مشکل یا درد رو دارم»، در همون لحظه میدونیم جملهای که داریم ثبت میکنیم، از نظر مفهومی یک Pain Point محسوب میشه. اما همزمان باید حواسمون باشه که رابطهی ما با این گزاره هنوز در حد یک Observation هست و هنوز هیچ تحلیلی روش انجام ندادیم.
— بعد از مصاحبه، وقتی دادهها رو تحلیل کردیم، ممکنه همون Pain Point رو در کنار چند مورد دیگه به شکل یک Job بازنویسی کنیم. اما حالا رابطهی ما با اون Job دیگه Observation نیست؛ بلکه یک Assumption محسوب میشه.
— میتونم حدس بزنم که شاید دارم موضوع رو بیش از حد پیچیده میکنم، ولی فعلاً اینطور حس نمیکنم. در این لحظه احساس میکنم اضافه کردن این بُعد رابطهای، کمک میکنه با اصطکاک ذهنی کمتری فکر کنم.
— چون قبلاً همیشه یه حس مبهمی داشتم که مثلاً این Pain Pointای که نوشتیم، صرفاً یک فرض ضعیف از درد کاربره یا واقعاً تقریباً مطمئنیم که دردش همینه؟ چرا توی این ابزارها جایی برای تفکیک و مدل کردن میزان اعتمادمون به یک گزاره، یا به عبارتی همین رابطهای که باهاش داریم، وجود نداره؟ البته اون موقع این مسئله انقدر برام شفاف نبود. فقط یه حس مبهم داشتم که یه جای کار میلنگه و همون ابهام مدام اذیتم میکرد.
— هنوزم سواله برام که چرا واقعا تو ابزارهای مختلفی که تو Miro مثلا وجود داره این رو لحاظ نکردن. میدونم مثلا Assumption map رو داریم ولی اونجا فرض شده همهی گزارههایی که میاریم داخلش Assumption هستن ولی جاهایی که با هم قاطیان اینا، مثل Business Model Canvas یا Value Proposition Canvas چیزی براش نیست.
— من تصمیم گرفتم با گذاشتن Dot Vote های رنگی که تو Miro هست، روی استیکی نوتها اون تفکیک رو قائل شم برای خودم.
💬 اگر شما هم تجربهی مشابهی داشتید یا راهحل بهتری برای مدل کردن این موضوع میشناسید، خوشحال میشم توی کامنتها share کنید.
#product #thinkingOutLoud
❤2
بالاتر به چهار نگرانی اساسی درمورد دارویار اشاره کرده بودم. در ادامه، نتیجهگیریهایی که درباره هرکدوم داشتم رو توضیح میدم و بعد هم از قدم بعدیای که میخوام سراغش برم میگم:
❤2
🔻 قابلاتکا بودن موجودی نمایشدادهشده در اپلیکیشن
— این مشکل تقریباً در همهی سیستمهایی وجود داره که یک digital state نمایانگر یک وضعیت فیزیکی در دنیای واقعی باشه. سینک نگه داشتن این دو همیشه یک چالشه.
— مثلاً تو سیستمهای انبارداری داروخانهها، چون هر بار برداشت دارو توسط پذیرش ثبت میشه، این مسئله با اصطکاک کمتری همراهه. با این حال، باز هم اجتنابناپذیره که بین موجودی واقعی و موجودی ثبتشده مقداری اختلاف ایجاد بشه. برای همین هم معمولاً سالی یک بار انبارگردانی انجام میدن تا این drift اصلاح بشه.
— اما توی اپ ما، سینک موندن موجودی وابسته به اینه که خود بیمار مصرفش رو ثبت کنه. برای اینکه اصطکاک این کار کم بشه، تصمیم دارم از optimistic log استفاده کنم.
— ایده اینه که بعد از وارد کردن موجودی اولیه توسط بیمار و تنظیم الگوی مصرفش (مثلاً روزهای مشخصی از هفته یا هر روز ۲ ویال)، خود سیستم در زمانهای مقرر بهصورت خودکار لاگ مصرف ثبت کنه.
— البته ممکنه کاربر گاهی خارج از الگوی مصرفی که تنظیم کرده رفتار کنه و همین باعث ایجاد drift بشه. در نتیجه، دیگه عدد موجودی داخل اپ، نمایشدهندهی موجودی واقعی کاربر نخواهد بود و چالش دقیقاً همینجاست.
— برخلاف سیستمهای انبارداری داروخانهها که دقت لحظهای موجودی اهمیت زیادی نداره، توی کیس ما خیلی مهمه که از دید کاربر این موجودی قابل اعتماد به نظر برسه و بتونه بر اساسش تصمیم بگیره؛ مثلاً اینکه تا چند ماه دارو داره، یا این بار که برای دریافت دارو مراجعه میکنه، چند تا باید بگیره. در نتیجه، چیزی که واقعاً اهمیت داره، قابلاعتماد بودن موجودی از دید کاربره.
— در نهایت به این نتیجه رسیدم که بهجای تلاش برای از بین بردن این اختلاف که ذاتاً اجتنابناپذیره، بهتره اون رو بپذیرم و روی افزایش انگیزهی کاربر برای سینک نگه داشتن موجودی تمرکز کنم.
— راهکاری که بهش رسیدم اینه که خودِ «اعتماد به موجودی» رو هم داخل اپ مدل کنم و براش یک visual representation داشته باشم؛ چیزی که در مرکز توجه کاربر قرار بگیره. یعنی بهجای اینکه فقط عدد موجودی نمایش داده بشه، به کاربر هم گفته بشه که این عدد تا چه حد قابل اعتماده. همچنین یک CTA هم در اختیارش قرار بگیره تا با مرور، تأیید یا رد کردن لاگهای مصرف، بتونه این اعتماد رو دوباره بازیابی کنه.
— اینطور شد که اسکچ این ایده رو روی کاغذ کشیدم و بعد به GPT دادم تا براش یک صفحه طراحی کنه و ایده ملموستر بشه.
✅ نتیجهگیری
به نظرم ایده خوبیه و میتونه نگرانی ذکرشده رو برطرف کنه. اعتبارسنجیش هم یه راه داره؛ باید بسازیم و تست کنیم. از اونجایی که کل ارزشی که دارویار میتونه خلق کنه وابسته به اینه که سیستم مدیریت موجودی کارش رو درست انجام بده، اتفاقاً توی نسخه اول هدفم ارزیابی همین قضیهست.
#daruyar #product #decision
— این مشکل تقریباً در همهی سیستمهایی وجود داره که یک digital state نمایانگر یک وضعیت فیزیکی در دنیای واقعی باشه. سینک نگه داشتن این دو همیشه یک چالشه.
— مثلاً تو سیستمهای انبارداری داروخانهها، چون هر بار برداشت دارو توسط پذیرش ثبت میشه، این مسئله با اصطکاک کمتری همراهه. با این حال، باز هم اجتنابناپذیره که بین موجودی واقعی و موجودی ثبتشده مقداری اختلاف ایجاد بشه. برای همین هم معمولاً سالی یک بار انبارگردانی انجام میدن تا این drift اصلاح بشه.
— اما توی اپ ما، سینک موندن موجودی وابسته به اینه که خود بیمار مصرفش رو ثبت کنه. برای اینکه اصطکاک این کار کم بشه، تصمیم دارم از optimistic log استفاده کنم.
— ایده اینه که بعد از وارد کردن موجودی اولیه توسط بیمار و تنظیم الگوی مصرفش (مثلاً روزهای مشخصی از هفته یا هر روز ۲ ویال)، خود سیستم در زمانهای مقرر بهصورت خودکار لاگ مصرف ثبت کنه.
— البته ممکنه کاربر گاهی خارج از الگوی مصرفی که تنظیم کرده رفتار کنه و همین باعث ایجاد drift بشه. در نتیجه، دیگه عدد موجودی داخل اپ، نمایشدهندهی موجودی واقعی کاربر نخواهد بود و چالش دقیقاً همینجاست.
— برخلاف سیستمهای انبارداری داروخانهها که دقت لحظهای موجودی اهمیت زیادی نداره، توی کیس ما خیلی مهمه که از دید کاربر این موجودی قابل اعتماد به نظر برسه و بتونه بر اساسش تصمیم بگیره؛ مثلاً اینکه تا چند ماه دارو داره، یا این بار که برای دریافت دارو مراجعه میکنه، چند تا باید بگیره. در نتیجه، چیزی که واقعاً اهمیت داره، قابلاعتماد بودن موجودی از دید کاربره.
— در نهایت به این نتیجه رسیدم که بهجای تلاش برای از بین بردن این اختلاف که ذاتاً اجتنابناپذیره، بهتره اون رو بپذیرم و روی افزایش انگیزهی کاربر برای سینک نگه داشتن موجودی تمرکز کنم.
— راهکاری که بهش رسیدم اینه که خودِ «اعتماد به موجودی» رو هم داخل اپ مدل کنم و براش یک visual representation داشته باشم؛ چیزی که در مرکز توجه کاربر قرار بگیره. یعنی بهجای اینکه فقط عدد موجودی نمایش داده بشه، به کاربر هم گفته بشه که این عدد تا چه حد قابل اعتماده. همچنین یک CTA هم در اختیارش قرار بگیره تا با مرور، تأیید یا رد کردن لاگهای مصرف، بتونه این اعتماد رو دوباره بازیابی کنه.
— اینطور شد که اسکچ این ایده رو روی کاغذ کشیدم و بعد به GPT دادم تا براش یک صفحه طراحی کنه و ایده ملموستر بشه.
✅ نتیجهگیری
به نظرم ایده خوبیه و میتونه نگرانی ذکرشده رو برطرف کنه. اعتبارسنجیش هم یه راه داره؛ باید بسازیم و تست کنیم. از اونجایی که کل ارزشی که دارویار میتونه خلق کنه وابسته به اینه که سیستم مدیریت موجودی کارش رو درست انجام بده، اتفاقاً توی نسخه اول هدفم ارزیابی همین قضیهست.
#daruyar #product #decision
❤2
🔻 ریسکهای حقوقی و رگولاتوری
— این نگرانی بیشتر از جایی پررنگ میشد که اگر قرار بود داخل اپلیکیشن بستری برای بهاشتراکگذاری داروهای مازاد بین بیماران ایجاد کنیم، وارد حوزهای میشدیم که ریسکهای حقوقی و رگولاتوری قابل توجهی داشت.
— مثلاً مشخص نبود اگر دارویی با شرایط نگهداری نامناسب، تاریخ انقضای نزدیک، یا هر مشکل دیگری بین دو نفر جابهجا بشه، مسئولیتش با چه کسی خواهد بود. از طرفی، فراهم کردن چنین بستری ممکن بود از نظر قوانین مربوط به توزیع دارو هم ابهامها و محدودیتهایی ایجاد کنه.
— در نهایت تصمیم گرفتم این قابلیت داخل اپلیکیشن پیادهسازی نشه. در عوض، صرفاً اگر سیستم تشخیص بده کاربر داروی مازاد داره، در قالب یک پیام بهش اطلاع بده که این مقدار دارو مازاد محسوب میشه و اگر امکانش رو داره، بهتره اون رو با دیگران به اشتراک بذاره.
— این تصمیم با رفتار واقعی جامعه هدف هم همخوانی داره. در عمل، بچهها بارها این کار رو انجام میدن و خود من هم بارها پیش اومده که از کسی دارو بگیرم یا به کسی دارو بدم.
✅ نتیجهگیری
به نظرم ارزش اصلی محصول در مدیریت موجودی و کمک به تصمیمگیری کاربره، نه ایجاد یک مارکتپلیس برای تبادل دارو. بنابراین، بهتره اپلیکیشن فقط نقش اطلاعرسان و تسهیلگر رو داشته باشه و وارد فرآیند تبادل دارو بین کاربران نشه. این تصمیم هم ریسکهای حقوقی رو بهشدت کاهش میده و هم باعث میشه تمرکز محصول روی مسئلهی اصلی باقی بمونه.
#daruyar #product #decision
— این نگرانی بیشتر از جایی پررنگ میشد که اگر قرار بود داخل اپلیکیشن بستری برای بهاشتراکگذاری داروهای مازاد بین بیماران ایجاد کنیم، وارد حوزهای میشدیم که ریسکهای حقوقی و رگولاتوری قابل توجهی داشت.
— مثلاً مشخص نبود اگر دارویی با شرایط نگهداری نامناسب، تاریخ انقضای نزدیک، یا هر مشکل دیگری بین دو نفر جابهجا بشه، مسئولیتش با چه کسی خواهد بود. از طرفی، فراهم کردن چنین بستری ممکن بود از نظر قوانین مربوط به توزیع دارو هم ابهامها و محدودیتهایی ایجاد کنه.
— در نهایت تصمیم گرفتم این قابلیت داخل اپلیکیشن پیادهسازی نشه. در عوض، صرفاً اگر سیستم تشخیص بده کاربر داروی مازاد داره، در قالب یک پیام بهش اطلاع بده که این مقدار دارو مازاد محسوب میشه و اگر امکانش رو داره، بهتره اون رو با دیگران به اشتراک بذاره.
— این تصمیم با رفتار واقعی جامعه هدف هم همخوانی داره. در عمل، بچهها بارها این کار رو انجام میدن و خود من هم بارها پیش اومده که از کسی دارو بگیرم یا به کسی دارو بدم.
✅ نتیجهگیری
به نظرم ارزش اصلی محصول در مدیریت موجودی و کمک به تصمیمگیری کاربره، نه ایجاد یک مارکتپلیس برای تبادل دارو. بنابراین، بهتره اپلیکیشن فقط نقش اطلاعرسان و تسهیلگر رو داشته باشه و وارد فرآیند تبادل دارو بین کاربران نشه. این تصمیم هم ریسکهای حقوقی رو بهشدت کاهش میده و هم باعث میشه تمرکز محصول روی مسئلهی اصلی باقی بمونه.
#daruyar #product #decision
👍3❤1
🔻وابستگی ارزش محصول به کمبود دارو | 🔻اعتماد کاربران به ثبت اطلاعات
— بعد از صحبت با چند نفر از فعالان انجمنهای تالاسمی و پرسیدن درمورد وضعیت داروهای مختلف از نظر در دسترس بودن و میزان استفاده، به نتایجی رسیدم که باعث شد بعضی از فرضهام اصلاح بشه. توی این نوشته، اونها رو باهاتون به اشتراک میذارم.
— از همون اول میدونستم که همهی بیمارها کمبود دارو رو به یک شکل تجربه نمیکنن. خیلیها، با اینکه همیشه داروی ترجیحیشون در دسترس نیست، کمکم به استفاده از نمونههای ایرانی یا داروهای جایگزین عادت کردن و درمانشون ادامه پیدا میکنه.
— جایی که اشتباه میکردم، اصلِ این تفاوت نبود؛ بلکه تصورم از میزان فراوانیش بود.
— چون تجربهی شخصی خودم این بوده که همیشه ترجیحم داروی خارجیه و هر ماه هم بهراحتی پیداش نمیکنم، ناخودآگاه تصور میکردم بخش بزرگی از جامعهی هدف هم تجربهای شبیه من دارن و مدیریت موجودی برای مقابله با این کمبود، دغدغهی مهمی برای بیشترشونه.
— اما بعد از یکی دو مصاحبه، به این نتیجه رسیدم که با وجود واقعی بودن کمبود دارو، اون مدلی از کمبودی که من تجربه میکنم، فقط برای بخشی از بیمارها اتفاق میافته. برای خیلیها، مسئله اینه که داروی ترجیحیشون همیشه در دسترس نیست، نه اینکه برای ادامهی درمان با کمبود جدی روبهرو باشن.
✅ نتیجهگیری
این گفتوگوها باعث شد یکی از فرضهای مهمم اصلاح بشه. مشکل کمبود دارو وجود داره، اما نه برای اون بخشی از جامعه که اول تصور میکردم. بنابراین، اگر دارویار قراره برای طیف گستردهای از بیمارها محصول ارزشمندی باشه، باید حتی برای کاربرهایی که هر روز با کمبود دارو درگیر نیستن هم ارزش ایجاد کنه، نه اینکه ارزشش فقط به شرایط کمبود وابسته باشه.
یه نکتهی دیگه هم اینه که نگرانی دربارهی اعتماد کاربر برای وارد کردن اطلاعات، بیشتر بین کسایی مطرحه که واقعاً کمبود دارو رو تجربه میکنن. حالا که دیدم برآوردم از تعداد این افراد اصلاح شده، به نظرم وزن این نگرانی هم کمتر از چیزیه که اول فکر میکردم. البته همچنان میشه با offline-first نگه داشتن بخش موجودی دارو، برای همین گروه از کاربرها هم خیال راحتتری ایجاد کرد.
در نهایت به این نتیجه رسیدم که شاید بهتر باشه دارویار رو نه بهعنوان یک سیستم مدیریت موجودی دارو، بلکه بهعنوان محصولی برای کمک به پایبندی به درمان ببینم.
#daruyar #product #decision
— بعد از صحبت با چند نفر از فعالان انجمنهای تالاسمی و پرسیدن درمورد وضعیت داروهای مختلف از نظر در دسترس بودن و میزان استفاده، به نتایجی رسیدم که باعث شد بعضی از فرضهام اصلاح بشه. توی این نوشته، اونها رو باهاتون به اشتراک میذارم.
— از همون اول میدونستم که همهی بیمارها کمبود دارو رو به یک شکل تجربه نمیکنن. خیلیها، با اینکه همیشه داروی ترجیحیشون در دسترس نیست، کمکم به استفاده از نمونههای ایرانی یا داروهای جایگزین عادت کردن و درمانشون ادامه پیدا میکنه.
— جایی که اشتباه میکردم، اصلِ این تفاوت نبود؛ بلکه تصورم از میزان فراوانیش بود.
— چون تجربهی شخصی خودم این بوده که همیشه ترجیحم داروی خارجیه و هر ماه هم بهراحتی پیداش نمیکنم، ناخودآگاه تصور میکردم بخش بزرگی از جامعهی هدف هم تجربهای شبیه من دارن و مدیریت موجودی برای مقابله با این کمبود، دغدغهی مهمی برای بیشترشونه.
— اما بعد از یکی دو مصاحبه، به این نتیجه رسیدم که با وجود واقعی بودن کمبود دارو، اون مدلی از کمبودی که من تجربه میکنم، فقط برای بخشی از بیمارها اتفاق میافته. برای خیلیها، مسئله اینه که داروی ترجیحیشون همیشه در دسترس نیست، نه اینکه برای ادامهی درمان با کمبود جدی روبهرو باشن.
✅ نتیجهگیری
این گفتوگوها باعث شد یکی از فرضهای مهمم اصلاح بشه. مشکل کمبود دارو وجود داره، اما نه برای اون بخشی از جامعه که اول تصور میکردم. بنابراین، اگر دارویار قراره برای طیف گستردهای از بیمارها محصول ارزشمندی باشه، باید حتی برای کاربرهایی که هر روز با کمبود دارو درگیر نیستن هم ارزش ایجاد کنه، نه اینکه ارزشش فقط به شرایط کمبود وابسته باشه.
یه نکتهی دیگه هم اینه که نگرانی دربارهی اعتماد کاربر برای وارد کردن اطلاعات، بیشتر بین کسایی مطرحه که واقعاً کمبود دارو رو تجربه میکنن. حالا که دیدم برآوردم از تعداد این افراد اصلاح شده، به نظرم وزن این نگرانی هم کمتر از چیزیه که اول فکر میکردم. البته همچنان میشه با offline-first نگه داشتن بخش موجودی دارو، برای همین گروه از کاربرها هم خیال راحتتری ایجاد کرد.
در نهایت به این نتیجه رسیدم که شاید بهتر باشه دارویار رو نه بهعنوان یک سیستم مدیریت موجودی دارو، بلکه بهعنوان محصولی برای کمک به پایبندی به درمان ببینم.
#daruyar #product #decision
Aliza Builds
بلکه بهعنوان محصولی برای کمک به پایبندی به درمان ببینم.
🔻قدم بعدی
این تغییر زاویه دید، خیلی چیزهارو عوض میکنه. ایدههایی براش تو ذهنم دارم ولی باز همگی وابسته به درست کار کردن سیستم مدیریت موجودیه و ترجیحم اینه بدون معطلی برم سراغ پیادهسازی MVP که قراره همین بخش مدیریت موجودی رو شامل شه و تست کنیم ببینیم اصلا اون ایدهی مدل کردن confidence جواب میده یا نه.
#daruyar #product #decision
🔻قدم بعدی
این تغییر زاویه دید، خیلی چیزهارو عوض میکنه. ایدههایی براش تو ذهنم دارم ولی باز همگی وابسته به درست کار کردن سیستم مدیریت موجودیه و ترجیحم اینه بدون معطلی برم سراغ پیادهسازی MVP که قراره همین بخش مدیریت موجودی رو شامل شه و تست کنیم ببینیم اصلا اون ایدهی مدل کردن confidence جواب میده یا نه.
#daruyar #product #decision
درود =)
من برای تبدیل گفتار به متن از ابزاری به اسم Wisper Flow استفاده میکنم. فوقالعادهاس! فارسی رو هم خوب ساپورت میکنه و میشه با فیچر Transform اش، گفتار تبدیل شده به متن رو بصورت اتوماتیک یک مرحلهی دیگه با AI بهبود داد و به خروجی مطلوبتری رسید. مثلا میتونید تنظیم کنید، امممم اوممم هارو حذف کنه و جملهبندیهارو بهبود بده.
عکس بالا پروفایل منه بعد از ۴۲ هزار کلمهای که باهاش تبدیل به متن کردم.
سرعت پرامپت نویسی رو خیلی بالا میبره و اصطکاک تعامل با ai رو به شدت کاهش میده.
این دومین ماهیه که دارم استفاده میکنم. پلن پرو رو برای ماه اول رایگان میده و در ادامه به ازای هر دعوتی که میکنیم، اگر ۲۰۰۰ کلمه باهاش تبدیل کنن. ۱ ماه دوباره پرو رو آپدیت میکنه.
تقریبا یک هفته به انتهای پلنم مونده. محبت میکنید اگر حوصله دارید، با لینک من ثبتنام کنید تا هم خودتون یک ماه پلن پرو دریافت کنید و هم بعد از ۲۰۰۰ کلمه به من یک ماه رو بده.
واقعا ابزار خوبیه. احتمالا خودتون هم عاشقش میشید. ^^
لینک معرف برای ثبتنام:
https://wisprflow.ai/r?ALIREZA279
#ai
من برای تبدیل گفتار به متن از ابزاری به اسم Wisper Flow استفاده میکنم. فوقالعادهاس! فارسی رو هم خوب ساپورت میکنه و میشه با فیچر Transform اش، گفتار تبدیل شده به متن رو بصورت اتوماتیک یک مرحلهی دیگه با AI بهبود داد و به خروجی مطلوبتری رسید. مثلا میتونید تنظیم کنید، امممم اوممم هارو حذف کنه و جملهبندیهارو بهبود بده.
عکس بالا پروفایل منه بعد از ۴۲ هزار کلمهای که باهاش تبدیل به متن کردم.
سرعت پرامپت نویسی رو خیلی بالا میبره و اصطکاک تعامل با ai رو به شدت کاهش میده.
این دومین ماهیه که دارم استفاده میکنم. پلن پرو رو برای ماه اول رایگان میده و در ادامه به ازای هر دعوتی که میکنیم، اگر ۲۰۰۰ کلمه باهاش تبدیل کنن. ۱ ماه دوباره پرو رو آپدیت میکنه.
تقریبا یک هفته به انتهای پلنم مونده. محبت میکنید اگر حوصله دارید، با لینک من ثبتنام کنید تا هم خودتون یک ماه پلن پرو دریافت کنید و هم بعد از ۲۰۰۰ کلمه به من یک ماه رو بده.
واقعا ابزار خوبیه. احتمالا خودتون هم عاشقش میشید. ^^
لینک معرف برای ثبتنام:
https://wisprflow.ai/r?ALIREZA279
#ai
❤2
⚜️ از PRD تا کد؛ روشی که فعلاً دارم امتحان میکنم
چند روزیه توسعه MVP رو با کمک Cursor شروع کردم. اول PRDی که قبلاً نوشته بودم رو آپدیت کردم و جزئیات Inventory Confidence Modeling رو بهش اضافه کردم.
🔻سؤال اینه که تو عصر AI، بهترین روش برای شروع توسعه یه پروژه چیه؟
یه رویکرد اینه که قبل از کدنویسی، داکهای فنی رو با جزئیات بنویسی و بعد توسعه رو به AI Agentها بسپری. احتمالاً چون تصمیمهای اصلی از قبل گرفته شدن، خروجی هم به چیزی که میخوای نزدیکتره.
ولی برای من، چون هنوز نیاز به یادگیری زیادی دارم و تصمیمهای فنی با یه اصطکاکی همراهن، همین تصمیمهای اولیه Cognitive Load زیادی دارن و ذهنم رو فرسوده میکنن. برای همین فعلاً این روش خیلی به کارم نمیاد.
فعلاً از روی PRD یه implementation plan مرحلهای ساختم. در نظر دارم تو هر مرحله Agent یه بخش از کار رو انجام بده، من کدها رو review کنم، هر جا چیزی رو نفهمیدم ازش بپرسم، یاد بگیرم و برم سراغ مرحله بعد.
اینطوری تصمیمهای فنی بهجای اینکه همون اول روی سرم خراب بشن، بین مراحل مختلف تقسیم میشن.
#daruyar #dev #ai
⚜️ از PRD تا کد؛ روشی که فعلاً دارم امتحان میکنم
چند روزیه توسعه MVP رو با کمک Cursor شروع کردم. اول PRDی که قبلاً نوشته بودم رو آپدیت کردم و جزئیات Inventory Confidence Modeling رو بهش اضافه کردم.
🔻سؤال اینه که تو عصر AI، بهترین روش برای شروع توسعه یه پروژه چیه؟
یه رویکرد اینه که قبل از کدنویسی، داکهای فنی رو با جزئیات بنویسی و بعد توسعه رو به AI Agentها بسپری. احتمالاً چون تصمیمهای اصلی از قبل گرفته شدن، خروجی هم به چیزی که میخوای نزدیکتره.
ولی برای من، چون هنوز نیاز به یادگیری زیادی دارم و تصمیمهای فنی با یه اصطکاکی همراهن، همین تصمیمهای اولیه Cognitive Load زیادی دارن و ذهنم رو فرسوده میکنن. برای همین فعلاً این روش خیلی به کارم نمیاد.
فعلاً از روی PRD یه implementation plan مرحلهای ساختم. در نظر دارم تو هر مرحله Agent یه بخش از کار رو انجام بده، من کدها رو review کنم، هر جا چیزی رو نفهمیدم ازش بپرسم، یاد بگیرم و برم سراغ مرحله بعد.
اینطوری تصمیمهای فنی بهجای اینکه همون اول روی سرم خراب بشن، بین مراحل مختلف تقسیم میشن.
#daruyar #dev #ai
❤2
Forwarded from Geniuses Group (Omid Hekayati)
🧠 اهمیت درک عمیق از مفهوم کلمه عامل (Agent) برای حل مشکلات کار کردن با #هوشواره ها (AI)
🔬این روزها تقریباً همه دربارهٔ AI Agentها صحبت میکنند؛ ابزارهای جدید معرفی میشوند، دورههای آموزشی برگزار میشود و هر روز اصطلاحات تازهای وارد اکوسیستم میشوند. اما احساس میکنم قبل از اینکه بخواهیم یاد بگیریم چگونه با AI Agentها کار کنیم، لازم است یک قدم به عقب برگردیم. شاید مسئله اصلاً هوشواره نباشد. شاید مسئله این باشد که ما هنوز مفهوم Agent (#عامل) را بهدرستی #مدل نکردهایم.
🚨وقتی کلمهٔ Agent را میشنویم، ذهنمان مستقیم به سمت #هوش_مصنوعی میرود، در حالی که Agent مفهومی بسیار قدیمیتر و عمومیتر است. هر موجودیتی که از طرف یک سیستم (شخص، سازمان، ...)، مسئولیتی را بر عهده میگیرد، یک Agent است. اگر این تعریف را بپذیریم، آن وقت AI Agent فقط یکی از انواع Agentها خواهد بود؛ همانطور که یک کارمند، یک پیمانکار، یک نرمافزار، یک سرویس یا حتی یک سازمان نیز میتواند نقش یک Agent را ایفا کند. و دقیقاً همینجا است که نگاه ما به #مسئله تغییر میکند. یک #تلنگر_ذهنی و سوال باز #فلسفه_ذهن را هم مطرح کنیم که حتی میشه بدن انسان را هم به نوعی عامل هویت اون فرد در نظر بگیریم.
اگر AI Agent را مفهومی کاملاً جدید تصور کنیم، ناخواسته بخش بزرگی از دانش انباشتهٔ گذشته دربارهٔ تعامل با Agentها را کنار میگذاریم و دوباره همان اشتباهات را با نامهای جدید تکرار میکنیم.
⏳بخش بزرگی از مشکلاتی که امروز به هوشواره نسبت میدهیم، در واقع سالها قبل از ظهور هوشواره هم وجود داشتهاند.
- وقتی مسئولیت را مبهم واگذار میکنیم...
- وقتی انتظار خروجی را شفاف تعریف نمیکنیم...
- وقتی زمینهٔ لازم را منتقل نمیکنیم...
- وقتی دانش سازمان در ذهن افراد باقی میماند و به دانش مشترک تبدیل نمیشود...
نتیجه معمولاً قابل پیشبینی نیست؛ چه طرف مقابل یک انسان باشد، چه یک هوشواره. دقت کنیم هوشواره مشکل جدیدی ایجاد نکرده است؛ فقط کیفیت #مدل_ذهنی و کیفیت #مدیریت_دانش ما را با وضوح بیشتری نمایان کرده است.
⏳به همین دلیل، شاید بهتر باشد به جای اینکه فقط دربارهٔ نقشهای کاذب (False Classification) منتسب به مهندسی مثل Prompt Engineering یا Harness Engineering صحبت کنیم، دربارهٔ اصول تعامل با هر Agent صحبت کنیم؛ اصولی که سالها قبل از ظهور هوشواره نیز وجود داشتهاند و احتمالاً سالها بعد از تغییر فناوریهای امروز نیز معتبر خواهند ماند. در چند کامنت زیر همین پست، سعی میکنم دربارهٔ همین اصول صحبت کنم؛ از #تفویض_اختیار و نحوهٔ #مستندسازی از نگارش درخواستها گرفته تا انتقال زمینه، مرزهای مسئولیت، معیارهای پذیرش و نقش #مدیریت_دانش در تعامل با عاملها.
⏳شاید هنگام خواندن این متن با خودتان گفته باشید:
- ما هم مدام خروجیهایی میگیریم که با انتظارمان فاصله دارند.
- هر بار باید دوباره همه چیز را توضیح بدهیم.
- افراد مختلف برداشتهای متفاوتی از یک درخواست دارند.
- دانش پروژه بیشتر در ذهن افراد است تا در مستندات.
- با وجود استفاده از هوشواره، کیفیت خروجی تیم بهتر نشده، فقط سرعت تولید بیشتر شده است.
اگر چنین نشانههایی را در #سازمان خود میبینید، احتمال دارد مسئلهٔ اصلی نه هوشواره باشد و نه حتی افراد تیم. اینها معمولاً نشانههایی از ضعف در #مدیریت_دانش، نبود یک #چارچوب_توسعه مشترک، ابهام در تعریف مسئولیتها یا ضعف در مدلسازی مسائل سازمان هستند. اینها با تعویض ابزار حل نمیشوند؛ نیازمند اصلاح شیوهٔ فکر کردن، انتقال دانش و طراحی فرآیندهای توسعه هستند.
🔗 در Geniuses.Group نیز دقیقاً همین دغدغه را دنبال میکنیم؛ کمک به سازمانها برای ساختن سیستمهایی که پایداری آنها تنها به فناوری وابسته نباشد، بلکه بر پایهٔ مدلهای ذهنی دقیقتر، مدیریت دانش بهتر و تعامل مؤثرتر میان عاملها شکل بگیرد.
🔬این روزها تقریباً همه دربارهٔ AI Agentها صحبت میکنند؛ ابزارهای جدید معرفی میشوند، دورههای آموزشی برگزار میشود و هر روز اصطلاحات تازهای وارد اکوسیستم میشوند. اما احساس میکنم قبل از اینکه بخواهیم یاد بگیریم چگونه با AI Agentها کار کنیم، لازم است یک قدم به عقب برگردیم. شاید مسئله اصلاً هوشواره نباشد. شاید مسئله این باشد که ما هنوز مفهوم Agent (#عامل) را بهدرستی #مدل نکردهایم.
🚨وقتی کلمهٔ Agent را میشنویم، ذهنمان مستقیم به سمت #هوش_مصنوعی میرود، در حالی که Agent مفهومی بسیار قدیمیتر و عمومیتر است. هر موجودیتی که از طرف یک سیستم (شخص، سازمان، ...)، مسئولیتی را بر عهده میگیرد، یک Agent است. اگر این تعریف را بپذیریم، آن وقت AI Agent فقط یکی از انواع Agentها خواهد بود؛ همانطور که یک کارمند، یک پیمانکار، یک نرمافزار، یک سرویس یا حتی یک سازمان نیز میتواند نقش یک Agent را ایفا کند. و دقیقاً همینجا است که نگاه ما به #مسئله تغییر میکند. یک #تلنگر_ذهنی و سوال باز #فلسفه_ذهن را هم مطرح کنیم که حتی میشه بدن انسان را هم به نوعی عامل هویت اون فرد در نظر بگیریم.
اگر AI Agent را مفهومی کاملاً جدید تصور کنیم، ناخواسته بخش بزرگی از دانش انباشتهٔ گذشته دربارهٔ تعامل با Agentها را کنار میگذاریم و دوباره همان اشتباهات را با نامهای جدید تکرار میکنیم.
⏳بخش بزرگی از مشکلاتی که امروز به هوشواره نسبت میدهیم، در واقع سالها قبل از ظهور هوشواره هم وجود داشتهاند.
- وقتی مسئولیت را مبهم واگذار میکنیم...
- وقتی انتظار خروجی را شفاف تعریف نمیکنیم...
- وقتی زمینهٔ لازم را منتقل نمیکنیم...
- وقتی دانش سازمان در ذهن افراد باقی میماند و به دانش مشترک تبدیل نمیشود...
نتیجه معمولاً قابل پیشبینی نیست؛ چه طرف مقابل یک انسان باشد، چه یک هوشواره. دقت کنیم هوشواره مشکل جدیدی ایجاد نکرده است؛ فقط کیفیت #مدل_ذهنی و کیفیت #مدیریت_دانش ما را با وضوح بیشتری نمایان کرده است.
⏳به همین دلیل، شاید بهتر باشد به جای اینکه فقط دربارهٔ نقشهای کاذب (False Classification) منتسب به مهندسی مثل Prompt Engineering یا Harness Engineering صحبت کنیم، دربارهٔ اصول تعامل با هر Agent صحبت کنیم؛ اصولی که سالها قبل از ظهور هوشواره نیز وجود داشتهاند و احتمالاً سالها بعد از تغییر فناوریهای امروز نیز معتبر خواهند ماند. در چند کامنت زیر همین پست، سعی میکنم دربارهٔ همین اصول صحبت کنم؛ از #تفویض_اختیار و نحوهٔ #مستندسازی از نگارش درخواستها گرفته تا انتقال زمینه، مرزهای مسئولیت، معیارهای پذیرش و نقش #مدیریت_دانش در تعامل با عاملها.
⏳شاید هنگام خواندن این متن با خودتان گفته باشید:
- ما هم مدام خروجیهایی میگیریم که با انتظارمان فاصله دارند.
- هر بار باید دوباره همه چیز را توضیح بدهیم.
- افراد مختلف برداشتهای متفاوتی از یک درخواست دارند.
- دانش پروژه بیشتر در ذهن افراد است تا در مستندات.
- با وجود استفاده از هوشواره، کیفیت خروجی تیم بهتر نشده، فقط سرعت تولید بیشتر شده است.
اگر چنین نشانههایی را در #سازمان خود میبینید، احتمال دارد مسئلهٔ اصلی نه هوشواره باشد و نه حتی افراد تیم. اینها معمولاً نشانههایی از ضعف در #مدیریت_دانش، نبود یک #چارچوب_توسعه مشترک، ابهام در تعریف مسئولیتها یا ضعف در مدلسازی مسائل سازمان هستند. اینها با تعویض ابزار حل نمیشوند؛ نیازمند اصلاح شیوهٔ فکر کردن، انتقال دانش و طراحی فرآیندهای توسعه هستند.
🔗 در Geniuses.Group نیز دقیقاً همین دغدغه را دنبال میکنیم؛ کمک به سازمانها برای ساختن سیستمهایی که پایداری آنها تنها به فناوری وابسته نباشد، بلکه بر پایهٔ مدلهای ذهنی دقیقتر، مدیریت دانش بهتر و تعامل مؤثرتر میان عاملها شکل بگیرد.
❤2
خب دوستان، من از آخرین پیام به اینور، توسعه رو طبق همون پلنی که قرار بود Roadmap دربیارم و agent هر مرحله رو انجام بده و من ریویو کنم، شروع کردم. منتها این وسط بهخاطر نیاز مالی یه پروژه گرفتم و مجبور شدم کلاً روی اون کار کنم و یه وقفهای ایجاد شد.
تازه دوباره برگشتم روی دارویار و همزمان یه تغییر هم توی روند کارم با AI دادم. قبلاً قرار بود Cursor کد بزنه و من ریویو کنم، ولی الان تصمیم گرفتم برعکسش پیش برم: خودم کد بزنم و Cursor ریویو کنه و صرفاً برای یادگیری و همفکری ازش استفاده کنم.
یه مدت بود خیلی تو فرایند فکر کردن و کدنویسی ازش استفاده میکردم و دیدم به مرور دیگه نمیتونم کار عمیق انجام بدم و تمرکزم رو روی یک مسئله نگه دارم. از طرفی چون اطلاعات زیادی وارد ذهنم میشد، شبها دچار بیشفکری میشدم و خواب عمیقی هم نمیتونستم داشته باشم.
کلاً مثل هر automation و delegation دیگهای، معتقدم استفاده agentic از AI هم باید همسو با ورکفلوی شخصی هر آدمی باشه. سطح فنیای که توش هستیم و ویژگیهای ذهنیمون هم مهمه و باید در نظر گرفته بشه. هر کسی باید متناسب با شرایط خودش تصمیم بگیره کدوم بخشهای ورکفلوی توسعه نرمافزارش رو به agent میسپاره و کدوم بخشها رو خودش انجام میده. برای همین خیلی نمیشه آموزهها و best practiceهایی که اون بیرون هست رو به همه تعمیم داد.
اینطور نیست که گارد گرفته باشم؛ میدونم که در آینده نزدیک سهم خیلی بیشتری از کارها رو نسبت به الان بهش خواهم داد، ولی توی این مرحله، عامدانه میخوام استفاده ازش رو کاهش (تغییر) بدم تا زمانی که کمی دانش و تجربه فنیم بیشتر بشه.
#daruyar #ai #thinkingOutLoud #dev
خب دوستان، من از آخرین پیام به اینور، توسعه رو طبق همون پلنی که قرار بود Roadmap دربیارم و agent هر مرحله رو انجام بده و من ریویو کنم، شروع کردم. منتها این وسط بهخاطر نیاز مالی یه پروژه گرفتم و مجبور شدم کلاً روی اون کار کنم و یه وقفهای ایجاد شد.
تازه دوباره برگشتم روی دارویار و همزمان یه تغییر هم توی روند کارم با AI دادم. قبلاً قرار بود Cursor کد بزنه و من ریویو کنم، ولی الان تصمیم گرفتم برعکسش پیش برم: خودم کد بزنم و Cursor ریویو کنه و صرفاً برای یادگیری و همفکری ازش استفاده کنم.
یه مدت بود خیلی تو فرایند فکر کردن و کدنویسی ازش استفاده میکردم و دیدم به مرور دیگه نمیتونم کار عمیق انجام بدم و تمرکزم رو روی یک مسئله نگه دارم. از طرفی چون اطلاعات زیادی وارد ذهنم میشد، شبها دچار بیشفکری میشدم و خواب عمیقی هم نمیتونستم داشته باشم.
کلاً مثل هر automation و delegation دیگهای، معتقدم استفاده agentic از AI هم باید همسو با ورکفلوی شخصی هر آدمی باشه. سطح فنیای که توش هستیم و ویژگیهای ذهنیمون هم مهمه و باید در نظر گرفته بشه. هر کسی باید متناسب با شرایط خودش تصمیم بگیره کدوم بخشهای ورکفلوی توسعه نرمافزارش رو به agent میسپاره و کدوم بخشها رو خودش انجام میده. برای همین خیلی نمیشه آموزهها و best practiceهایی که اون بیرون هست رو به همه تعمیم داد.
اینطور نیست که گارد گرفته باشم؛ میدونم که در آینده نزدیک سهم خیلی بیشتری از کارها رو نسبت به الان بهش خواهم داد، ولی توی این مرحله، عامدانه میخوام استفاده ازش رو کاهش (تغییر) بدم تا زمانی که کمی دانش و تجربه فنیم بیشتر بشه.
#daruyar #ai #thinkingOutLoud #dev
❤2👍1
#daruyar #dev #thinkingOutLoud
تو دارویار یه بخشی از مدل دادهمون تقریباً این شکلیه:
از نظر domain، یه Medication بدون حداقل یک Variant عملاً برای inventory معنایی نداره، و همینطور Variant بدون Batch.
با اینحال دو تا روش میشه در پیش گرفت:
۱. enforce کردن invariant موقع create
یعنی کاربر وقتی Medication میسازه، همون flow حداقل یه Variant و یه Batch هم داشته باشه؛ در نتیجه هیچوقت entity ناقص نداریم.
۲. enforce کردن invariant موقع Read
Medication، Variant و Batch هر کدوم route/form جدا داشته باشن و کاربر بتونه هرکدوم رو جداگانه بسازه:
در این حالت ممکنه یه Medication ایجاد بشه ولی هنوز Variant نداشته باشه، یا Variant داشته باشیم که هنوز Batch نداره. ولی میشه اینو در domain/read layer کنترل کرد؛ مثلاً یه چیزی مثل:
و فقط treeهایی که حداقل یک Variant با حداقل یک Batch دارن وارد محاسبات inventory بشن.
🔻چیزی که برام سؤال شده اینه:
چه trade-off هایی این دو روش دارن و تو چه کیسهایی بهتره با کدوم پیش رفت؟
نظر فعلی خودم اینه که جدا در نظر بگیرم و تو مرحله ایجاد سخت نگیرم، تا برای تغییرات بعدی هم کارمون راحت باشه.
یوزر فلو رو هم میشه حتی با این روش هم طوری درآورد که کاربر موقع ایجاد medication بعدش variant و batch هم ادد کنه و خیلی به تصمیم مورد بحثمون وابسته نیست.
#daruyar #dev #thinkingOutLoud
تو دارویار یه بخشی از مدل دادهمون تقریباً این شکلیه:
Medication
└── Variant
└── Batch
از نظر domain، یه Medication بدون حداقل یک Variant عملاً برای inventory معنایی نداره، و همینطور Variant بدون Batch.
با اینحال دو تا روش میشه در پیش گرفت:
۱. enforce کردن invariant موقع create
یعنی کاربر وقتی Medication میسازه، همون flow حداقل یه Variant و یه Batch هم داشته باشه؛ در نتیجه هیچوقت entity ناقص نداریم.
۲. enforce کردن invariant موقع Read
Medication، Variant و Batch هر کدوم route/form جدا داشته باشن و کاربر بتونه هرکدوم رو جداگانه بسازه:
Create Medication
↓
Create Variant
↓
Create Batch
در این حالت ممکنه یه Medication ایجاد بشه ولی هنوز Variant نداشته باشه، یا Variant داشته باشیم که هنوز Batch نداره. ولی میشه اینو در domain/read layer کنترل کرد؛ مثلاً یه چیزی مثل:
isInventoryReady(medication)
و فقط treeهایی که حداقل یک Variant با حداقل یک Batch دارن وارد محاسبات inventory بشن.
🔻چیزی که برام سؤال شده اینه:
چه trade-off هایی این دو روش دارن و تو چه کیسهایی بهتره با کدوم پیش رفت؟
نظر فعلی خودم اینه که جدا در نظر بگیرم و تو مرحله ایجاد سخت نگیرم، تا برای تغییرات بعدی هم کارمون راحت باشه.
یوزر فلو رو هم میشه حتی با این روش هم طوری درآورد که کاربر موقع ایجاد medication بعدش variant و batch هم ادد کنه و خیلی به تصمیم مورد بحثمون وابسته نیست.
❤1