‏⚜️ اعتبارسنجی فرضیه‌ها یا تکیه بر شهود

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

مثلاً درباره‌ی چالش‌هایی که در پیام قبلی آوردم، می‌دونم که «اعتماد کاربران به ثبت اطلاعات» یه فرضیه‌ست و طبق آموزه‌های Product باید ولیدیت بشه. اما چون راهکاری که براش در نظر دارم (offline-first بودن اپ)، چالش بعدی یعنی «ریسک‌های حقوقی و رگولاتوری» رو هم تا حد زیادی پوشش می‌ده و در عمل هزینه‌ی اضافه‌ای هم برام نداره، به نظرم منطقیه که بدون ولیدیت کردن اون فرضیه، همین مسیر رو ادامه بدم.

یه صدایی توی مغزم می‌گه: «خب، اینکه فکر می‌کنی offline-first بودن این مشکل رو حل می‌کنه هم خودش یه فرضیه‌ست!»
جوابش اینه که: آره، هست. ولی خب... می‌گی چیکاااار کنم؟ =)))

جدا از شوخی، واقعاً فکر می‌کنم مرز بین اینکه کجا باید ولیدیت کنیم و کجا می‌تونیم به قضاوت خودمون تکیه کنیم، یه مهارته که به مرور و با شکل گرفتن شهود بهتر، متعادل‌تر می‌شه.


🔻 پی نوشت:

همین متن رو به GPT دادم و در تأیید این ایده به مفهوم Value of Information (VOI) اشاره کرد:

‏
اطلاعات ذاتاً ارزشمند نیست؛ ارزش اطلاعات به این بستگی داره که آیا باعث می‌شه تصمیم بهتری بگیریم یا نه.
‏

به نظرم این نگاه، معیار خوبی برای تصمیم گرفتن درباره‌ی اعتبارسنجی فرضیاته.

#daruyar #product #thinkingOutLoud

⚜️ دو زاویه دید متفاوت برای توصیف گزاره‌های 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

بالاتر به چهار نگرانی اساسی درمورد دارویار اشاره کرده بودم. در ادامه، نتیجه‌گیری‌هایی که درباره هرکدوم داشتم رو توضیح می‌دم و بعد هم از قدم بعدی‌ای که می‌خوام سراغش برم می‌گم:
‏

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

— این مشکل تقریباً در همه‌ی سیستم‌هایی وجود داره که یک digital state نمایانگر یک وضعیت فیزیکی در دنیای واقعی باشه. سینک نگه داشتن این دو همیشه یک چالشه.

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

— اما توی اپ ما، سینک موندن موجودی وابسته به اینه که خود بیمار مصرفش رو ثبت کنه. برای اینکه اصطکاک این کار کم بشه، تصمیم دارم از optimistic log استفاده کنم.

— ایده اینه که بعد از وارد کردن موجودی اولیه توسط بیمار و تنظیم الگوی مصرفش (مثلاً روزهای مشخصی از هفته یا هر روز ۲ ویال)، خود سیستم در زمان‌های مقرر به‌صورت خودکار لاگ مصرف ثبت کنه.

— البته ممکنه کاربر گاهی خارج از الگوی مصرفی که تنظیم کرده رفتار کنه و همین باعث ایجاد drift بشه. در نتیجه، دیگه عدد موجودی داخل اپ، نمایش‌دهنده‌ی موجودی واقعی کاربر نخواهد بود و چالش دقیقاً همینجاست.

— برخلاف سیستم‌های انبارداری داروخانه‌ها که دقت لحظه‌ای موجودی اهمیت زیادی نداره، توی کیس ما خیلی مهمه که از دید کاربر این موجودی قابل اعتماد به نظر برسه و بتونه بر اساسش تصمیم بگیره؛ مثلاً اینکه تا چند ماه دارو داره، یا این بار که برای دریافت دارو مراجعه می‌کنه، چند تا باید بگیره. در نتیجه، چیزی که واقعاً اهمیت داره، قابل‌اعتماد بودن موجودی از دید کاربره.

— در نهایت به این نتیجه رسیدم که به‌جای تلاش برای از بین بردن این اختلاف که ذاتاً اجتناب‌ناپذیره، بهتره اون رو بپذیرم و روی افزایش انگیزه‌ی کاربر برای سینک نگه داشتن موجودی تمرکز کنم.

— راهکاری که بهش رسیدم اینه که خودِ «اعتماد به موجودی» رو هم داخل اپ مدل کنم و براش یک visual representation داشته باشم؛ چیزی که در مرکز توجه کاربر قرار بگیره. یعنی به‌جای اینکه فقط عدد موجودی نمایش داده بشه، به کاربر هم گفته بشه که این عدد تا چه حد قابل اعتماده. همچنین یک CTA هم در اختیارش قرار بگیره تا با مرور، تأیید یا رد کردن لاگ‌های مصرف، بتونه این اعتماد رو دوباره بازیابی کنه.

— اینطور شد که اسکچ این ایده رو روی کاغذ کشیدم و بعد به GPT دادم تا براش یک صفحه طراحی کنه و ایده ملموس‌تر بشه.


✅ نتیجه‌گیری

به نظرم ایده خوبیه و می‌تونه نگرانی ذکرشده رو برطرف کنه. اعتبارسنجیش هم یه راه داره؛ باید بسازیم و تست کنیم. از اونجایی که کل ارزشی که دارویار می‌تونه خلق کنه وابسته به اینه که سیستم مدیریت موجودی کارش رو درست انجام بده، اتفاقاً توی نسخه اول هدفم ارزیابی همین قضیه‌ست.

#daruyar #product #decision

🔻 ریسک‌های حقوقی و رگولاتوری

— این نگرانی بیشتر از جایی پررنگ می‌شد که اگر قرار بود داخل اپلیکیشن بستری برای به‌اشتراک‌گذاری داروهای مازاد بین بیماران ایجاد کنیم، وارد حوزه‌ای می‌شدیم که ریسک‌های حقوقی و رگولاتوری قابل توجهی داشت.

— مثلاً مشخص نبود اگر دارویی با شرایط نگهداری نامناسب، تاریخ انقضای نزدیک، یا هر مشکل دیگری بین دو نفر جابه‌جا بشه، مسئولیتش با چه کسی خواهد بود. از طرفی، فراهم کردن چنین بستری ممکن بود از نظر قوانین مربوط به توزیع دارو هم ابهام‌ها و محدودیت‌هایی ایجاد کنه.

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

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

✅ نتیجه‌گیری

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

#daruyar #product #decision

🔻وابستگی ارزش محصول به کمبود دارو | 🔻اعتماد کاربران به ثبت اطلاعات

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

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

— جایی که اشتباه می‌کردم، اصلِ این تفاوت نبود؛ بلکه تصورم از میزان فراوانیش بود.

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

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



✅ نتیجه‌گیری

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

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

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

#daruyar #product #decision

‌‏
🔻قدم بعدی

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

#daruyar #product #decision

درود =)

من برای تبدیل گفتار به متن از ابزاری به اسم Wisper Flow استفاده می‌کنم. فوق‌العاده‌اس! فارسی رو هم خوب ساپورت می‌کنه و می‌شه با فیچر Transform اش، گفتار تبدیل شده به متن رو بصورت اتوماتیک یک مرحله‌ی دیگه با AI بهبود داد و به خروجی مطلوب‌تری رسید. مثلا می‌تونید تنظیم کنید، امممم اوممم هارو حذف کنه و جمله‌بندی‌هارو بهبود بده.

عکس بالا پروفایل منه بعد از ۴۲ هزار کلمه‌ای که باهاش تبدیل به متن کردم.

سرعت پرامپت نویسی رو خیلی بالا می‌بره و اصطکاک تعامل با ai رو به شدت کاهش می‌ده.

این دومین ماهیه که دارم استفاده می‌کنم. پلن پرو رو برای ماه اول رایگان می‌ده و در ادامه به ازای هر دعوتی که می‌کنیم، اگر ۲۰۰۰ کلمه باهاش تبدیل کنن. ۱ ماه دوباره پرو رو آپدیت می‌کنه.

تقریبا یک هفته به انتهای پلنم‌ مونده. محبت می‌کنید اگر حوصله دارید، با لینک من ثبت‌نام کنید تا هم خودتون یک ماه پلن پرو دریافت کنید و هم بعد از ۲۰۰۰ کلمه به من یک ماه رو بده.

واقعا ابزار خوبیه. احتمالا خودتون هم عاشقش می‌شید. ^^


لینک معرف برای ثبت‌نام:
https://wisprflow.ai/r?ALIREZA279

#ai

‏
⚜️ از PRD تا کد؛ روشی که فعلاً دارم امتحان می‌کنم

چند روزیه توسعه MVP رو با کمک Cursor شروع کردم. اول PRDی که قبلاً نوشته بودم رو آپدیت کردم و جزئیات Inventory Confidence Modeling رو بهش اضافه کردم.

🔻سؤال اینه که تو عصر AI، بهترین روش برای شروع توسعه یه پروژه چیه؟

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

ولی برای من، چون هنوز نیاز به یادگیری زیادی دارم و تصمیم‌های فنی با یه اصطکاکی همراهن، همین تصمیم‌های اولیه Cognitive Load زیادی دارن و ذهنم رو فرسوده می‌کنن. برای همین فعلاً این روش خیلی به کارم نمیاد.

فعلاً از روی PRD یه implementation plan مرحله‌ای ساختم. در نظر دارم تو هر مرحله Agent یه بخش از کار رو انجام بده، من کدها رو review کنم، هر جا چیزی رو نفهمیدم ازش بپرسم، یاد بگیرم و برم سراغ مرحله بعد.

این‌طوری تصمیم‌های فنی به‌جای اینکه همون اول روی سرم خراب بشن، بین مراحل مختلف تقسیم می‌شن.

#daruyar #dev #ai

🧠 اهمیت درک عمیق از مفهوم کلمه عامل (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 نیز دقیقاً همین دغدغه را دنبال می‌کنیم؛ کمک به سازمان‌ها برای ساختن سیستم‌هایی که پایداری آن‌ها تنها به فناوری وابسته نباشد، بلکه بر پایهٔ مدل‌های ذهنی دقیق‌تر، مدیریت دانش بهتر و تعامل مؤثرتر میان عامل‌ها شکل بگیرد.

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

تازه دوباره برگشتم روی دارویار و هم‌زمان یه تغییر هم توی روند کارم با AI دادم. قبلاً قرار بود Cursor کد بزنه و من ریویو کنم، ولی الان تصمیم گرفتم برعکسش پیش برم: خودم کد بزنم و Cursor ریویو کنه و صرفاً برای یادگیری و هم‌فکری ازش استفاده کنم.

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

کلاً مثل هر automation و delegation دیگه‌ای، معتقدم استفاده agentic از AI هم باید هم‌سو با ورک‌فلوی شخصی هر آدمی باشه. سطح فنی‌ای که توش هستیم و ویژگی‌های ذهنی‌مون هم مهمه و باید در نظر گرفته بشه. هر کسی باید متناسب با شرایط خودش تصمیم بگیره کدوم بخش‌های ورک‌فلوی توسعه نرم‌افزارش رو به agent می‌سپاره و کدوم بخش‌ها رو خودش انجام می‌ده. برای همین خیلی نمی‌شه آموزه‌ها و best practiceهایی که اون بیرون هست رو به همه تعمیم داد.

این‌طور نیست که گارد گرفته باشم؛ می‌دونم که در آینده نزدیک سهم خیلی بیشتری از کارها رو نسبت به الان بهش خواهم داد، ولی توی این مرحله، عامدانه می‌خوام استفاده‌ ازش رو کاهش (تغییر) بدم تا زمانی که کمی دانش و تجربه فنی‌م بیشتر بشه.


#daruyar #ai #thinkingOutLoud #dev

‏
#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 هم ادد کنه و خیلی به تصمیم مورد بحث‌مون وابسته نیست.