https://virgool.io/feed/@mahmoodBagheri سازمان‌ها پر از جلسه و ابزارند، اما تصمیم ندارند. من درباره همکاریِ ناکارآمد، مدیریتِ نمایشی و راه‌هایی می‌نویسم که تیم‌ها را از شلوغی به اثرگذاری واقعی می‌رساند. fa 2026-04-15 00:36:42 https://files.virgool.io/upload/users/3958/avatar/r1TYL3.png?height=120&width=120 https://virgool.io/@mahmoodBagheri https://virgool.io/@mahmoodBagheri/%D9%85%D9%82%D8%A7%D9%84%D9%87-%D8%B4%D8%B4%D9%85-%D8%AD%D8%A7%D9%81%D8%B8%D9%87-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%DB%8C-%DA%86%D8%B1%D8%A7-%D9%87%D8%B1-%D8%AA%D8%B5%D9%85%DB%8C%D9%85-%D9%86%D8%A8%D8%A7%DB%8C%D8%AF-%D8%AF%D9%88%D8%A8%D8%A7%D8%B1%D9%87-%DA%AF%D8%B1%D9%81%D8%AA%D9%87-%D8%B4%D9%88%D8%AF-zsmz5wxwu3jo یادداشت نویسنده | درباره روش نگارش این مجموعهاین مقاله، مانند سایر نوشته‌های مجموعه MOCA، با کمک هوش مصنوعی تدوین شده است.اما مسئله‌مندی، چارچوب فکری، مثال‌ها و مسیر تحلیل آن حاصل مطالعه، تجربه و خط فکری شخصی من درباره MOCA (Modern Collaboration Architecture) است.هوش مصنوعی در این مسیر نقش یک ابزار کمکی را داشته؛برای ویرایش، فشرده‌سازی و تبدیل یک تحلیل مفهومی به متنی شفاف‌تر و کاربردی‌تر.این انتخاب آگاهانه بوده، چون برای موضوعی مثل همکاری سازمانی،فهم عمیق مسئله مهم‌تر از توضیح مفصل آن است.اگر تازه وارد این مجموعه شده‌اید، پیشنهاد می‌کنم مسیر را به‌ترتیب دنبال کنید:مقاله اول: وقتی MOCA را فهمیدم، تازه دیدم چرا سازمان‌ها پرکار اما کم‌اثر شده‌اندمقاله دوم: این مشکل فقط مال ما نیست؛ یک مسئله جهانی استمقاله سوم: یک جلسه، از تولد تا فراموشیمقاله چهارم: وقتی تصمیم صاحب ندارد، همکاری فرو می‌ریزدمقاله پنجم: وقتی تصمیم صاحب دارد، چه چیزی تغییر می‌کند؟این مقاله ادامه مستقیم همان مسیر است.یک سؤال آشنا که همه شنیده‌ایم«این موضوع قبلاً تصمیم‌گیری نشده بود؟»«فکر کنم جلسه قبل هم همین بحث را داشتیم…»این جمله‌ها آشنا هستند،نه چون آدم‌ها حواس‌پرت‌اند،بلکه چون سازمان حافظه ندارد.حافظه افراد هست، حافظه سازمان نیستآدم‌ها به یاد می‌آورند.سازمان‌ها نه.تا وقتی افراد حضور دارند:تصمیم‌ها زنده‌اندمسیرها یادآوری می‌شوندزمینه‌ها منتقل می‌شوداما کافی است:کسی تیم را ترک کندنقش‌ها جابه‌جا شوندیا زمان بگذردتصمیم‌ها شروع به محو شدن می‌کنند.اینجاست که سازمان مجبور می‌شوددوباره فکر کند، دوباره بحث کند، دوباره تصمیم بگیرد.سازمان‌ها از کمبود تصمیم نمی‌میرندیک جمله کلیدی این‌جا لازم است:سازمان‌ها نه از کمبود تصمیم، بلکه از نبود حافظه می‌میرند.تصمیم بدون حافظه:دوباره تکرار می‌شوددوباره زیر سؤال می‌روددوباره انرژی می‌گیردو این چرخه،فرسایش پنهان سازمان است.هزینه واقعی نبود حافظه سازمانینبود حافظه فقط «کلافگی» نیست.هزینه واقعی دارد:دوباره‌کاری ذهنیاتلاف زمان جلسه‌هابی‌اعتمادی به تصمیم‌هاکند شدن حرکت تیم‌هاو مهم‌تر از همه:آدم‌ها حس می‌کنندهیچ‌چیز واقعاً جلو نمی‌رود.یک اشتباه رایج | ثبت ≠ حافظهبیشتر سازمان‌ها این‌جا اشتباه می‌کنند.می‌گویند:«ما همه‌چیز را ثبت کرده‌ایم.»اما ثبت، حافظه نیست.فایل ذخیره شدهپیام آرشیو شدهصورت‌جلسه ارسال شدههمه این‌ها ثبت هستند،نه حافظه.حافظه یعنی چه؟حافظه سازمانی یعنی:تصمیم قابل پیدا شدن باشددلیل تصمیم مشخص باشدتصمیم قبلی در تصمیم بعدی استفاده شودحافظه یعنی:سازمان مجبور نباشد هر بار از صفر شروع کند.MOCA این مسئله را چطور می‌بیند؟در MOCA:تصمیم یک artifact زنده استartifact در جریان همکاری حرکت می‌کندحافظه بخشی از flow است، نه انبارنه آرشیو مرده،نه فولدر پر از فایل،بلکه تصمیم‌هایی که قابل رجوع و قابل استفاده‌اند.اینجا همکاری بالغ می‌شود.وقتی حافظه هست، همکاری تغییر می‌کنددر سازمانی که حافظه دارد:تصمیم‌ها تکرار نمی‌شوندجلسه‌ها ادامه مسیرند، نه شروع دوبارهافراد جدید سریع‌تر هماهنگ می‌شوندانرژی ذهنی حفظ می‌شودهمکاری آرام‌تر و عمیق‌تر می‌شود.نه چون همه‌چیز کامل است،بلکه چون چیزی گم نمی‌شود.جمع‌بندی | بلوغ همکاری از این‌جا شروع می‌شودتصمیم صاحب‌دار،بدون حافظه، دوام نمی‌آورد.حافظه سازمانی:تصمیم‌ها را زنده نگه می‌داردهمکاری را پیوسته می‌کندو سازمان را از فرسایش نجات می‌دهددر مقاله بعدی،یک قدم جلوتر می‌رویم و همه این‌ها را کنار هم می‌گذاریم:از حافظه تا جریان؛ وقتی همکاری واقعاً معماری دارداینجا MOCA وارد فاز نهایی خودش می‌شود. محمود باقری محمود باقری Sun, 04 Jan 2026 17:39:56 +0330 https://virgool.io/@mahmoodBagheri/%D9%85%D9%82%D8%A7%D9%84%D9%87-%D9%BE%D9%86%D8%AC%D9%85-%D9%88%D9%82%D8%AA%DB%8C-%D8%AA%D8%B5%D9%85%DB%8C%D9%85-%D8%B5%D8%A7%D8%AD%D8%A8-%D8%AF%D8%A7%D8%B1%D8%AF-%DA%86%D9%87-%DA%86%DB%8C%D8%B2%DB%8C-%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1-%D9%85%DB%8C-%DA%A9%D9%86%D8%AF-cmdkfsikoyye یادداشت نویسنده | درباره روش نگارش این مجموعهاین مقاله، مانند سایر نوشته‌های مجموعه MOCA، با کمک هوش مصنوعی تدوین شده است.اما مسئله‌مندی، ساختار فکری، مثال‌ها و مسیر تحلیلی آن حاصل مطالعه و تجربه شخصی من در مواجهه با مفهوم MOCA (Modern Collaboration Architecture) است.هوش مصنوعی در این مسیر نقش ابزار ویرایشی و فشرده‌سازی را داشته؛برای اینکه ایده‌ها واضح‌تر، کاربردی‌تر و قابل لمس‌تر منتقل شوند.این انتخاب آگاهانه بوده، چون معتقدم برای موضوعی مثل همکاری سازمانی،دیدن تغییرات در عمل، مهم‌تر از خواندن توضیح‌های صرفاً نظری است.اگر تازه وارد این مجموعه شده‌اید، پیشنهاد می‌کنم مسیر را به‌ترتیب دنبال کنید:مقاله اول: وقتی MOCA را فهمیدم، تازه دیدم چرا سازمان‌ها پرکار اما کم‌اثر شده‌اندمقاله دوم: این مشکل فقط مال ما نیست؛ یک مسئله جهانی استمقاله سوم: یک جلسه، از تولد تا فراموشیمقاله چهارم: وقتی تصمیم صاحب ندارد، همکاری فرو می‌ریزداین مقاله ادامه مستقیم همان مسیر است.فرض کنیم تصمیم‌ها بالاخره صاحب دارندبرای یک لحظه فرض کنیم اتفاق ساده‌ای افتاده است:تصمیم‌ها دیگر بی‌صاحب نیستند.نه ابزار جدید آمده،نه ساختار سازمانی عوض شده،نه آدم‌ها حرفه‌ای‌تر شده‌اند.فقط هر تصمیم:یک مالک مشخص داردو رها نمی‌شودسؤال این است:چه چیزی واقعاً تغییر می‌کند؟تغییر اول | پیگیری دیگر شخصی نیستدر سازمانی که تصمیم صاحب دارد،پیگیری شبیه «یادآوری خسته‌کننده» نیست.کسی دنبال کسی نمی‌دود.کسی احساس مزاحمت نمی‌کند.چون:انتظارها شفاف استمالک تصمیم معلوم استپیگیری، بخشی از جریان است نه خواهش شخصیهمکاری از حالت فرسایشی خارج می‌شود.تغییر دوم | جلسه‌ها کوتاه‌تر و دقیق‌تر می‌شوندوقتی تصمیم‌های قبلی زنده‌اند:بحث‌ها تکرار نمی‌شوندجلسه از صفر شروع نمی‌شودتمرکز روی ادامه کار است، نه باز کردن دوباره گذشتهجلسه دیگر محل «اثبات نظر» نیست؛محل حرکت به جلو است.و این یعنی:جلسه کمتر، خروجی بیشتر.تغییر سوم | اعتماد آرام‌آرام برمی‌گردداعتماد سازمانی با شعار ساخته نمی‌شود.با تکرار یک رفتار ساده ساخته می‌شود:تصمیم → انجام → دیده‌شدن نتیجهوقتی تصمیم‌ها صاحب دارند و جلو می‌روند:تیم می‌بیند کارها گم نمی‌شوندحرف‌ها به عمل تبدیل می‌شوندقول‌ها تهی نیستنداعتماد بالا می‌رود،و همکاری سریع‌تر و روان‌تر می‌شود.یک نکته مهم | این سخت‌گیری نیستخیلی‌ها این‌جا نگران می‌شوند:«این یعنی فشار بیشتر روی آدم‌ها؟»نه.مالکیت تصمیم:ابزار کنترل نیستابزار سرزنش نیستابزار شفافیت است.وقتی شفافیت هست:سوءتفاهم کمتر می‌شودفشار پخش می‌شودهمکاری انسانی‌تر می‌شودمکث کوتاه | MOCA این تغییر را چطور می‌بیند؟در MOCA:تصمیم یک اتفاق لحظه‌ای نیستیک artifact زنده استمالک داردو در جریان کار حرکت می‌کندنه برای گزارش،نه برای کنترل،بلکه برای اینکه همکاری واقعاً جلو برود.اینجا هنوز درباره ابزار حرف نمی‌زنیم.داریم درباره رفتار درست همکاری حرف می‌زنیم.همکاری وقتی سبک می‌شودشاید مهم‌ترین تغییر همین باشد:وقتی تصمیم صاحب دارد، همکاری سبک می‌شود.نه به این معنا که کار کمتر است،بلکه به این معنا که:اصطکاک کمتر استدوباره‌کاری کمتر استانرژی ذهنی هدر نمی‌رودسازمان آرام‌تر حرکت می‌کند،حتی اگر سریع‌تر نشده باشد.جمع‌بندی | این فقط شروع تفاوت استمالکیت تصمیم:همکاری را نجات نمی‌دهداما آن را قابل نجات می‌کندبدون آن،هر معماری همکاری فرو می‌ریزد.در مقاله بعدی،می‌رویم سراغ چیزی که همه این تصمیم‌ها را زنده نگه می‌دارد:حافظه سازمانیو اینکه چرا هر تصمیمی نباید دوباره گرفته شود.اینجا، MOCA وارد فاز جدی‌تری می‌شود. محمود باقری محمود باقری Wed, 31 Dec 2025 16:11:38 +0330 https://virgool.io/@mahmoodBagheri/%D9%85%D9%82%D8%A7%D9%84%D9%87-%DA%86%D9%87%D8%A7%D8%B1%D9%85-%D9%88%D9%82%D8%AA%DB%8C-%D8%AA%D8%B5%D9%85%DB%8C%D9%85-%D8%B5%D8%A7%D8%AD%D8%A8-%D9%86%D8%AF%D8%A7%D8%B1%D8%AF-%D9%87%D9%85%DA%A9%D8%A7%D8%B1%DB%8C-%D9%81%D8%B1%D9%88-%D9%85%DB%8C-%D8%B1%DB%8C%D8%B2%D8%AF-ut5eo9jetgdc یادداشت نویسنده | درباره روش نگارش این مجموعهاین مقاله، مانند سایر نوشته‌های مجموعه MOCA، با کمک هوش مصنوعی تدوین شده است.اما مسئله‌مندی، زاویه نگاه، مثال‌ها و مسیر تحلیلی آن حاصل مطالعه، تجربه و خط فکری شخصی من درباره MOCA (Modern Collaboration Architecture) است.هوش مصنوعی در این مسیر نقش یک ابزار کمکی را داشته؛برای ویرایش، فشرده‌سازی و تبدیل یک تحلیل مفهومی به متنی شفاف‌تر و قابل لمس‌تر.این انتخاب آگاهانه بوده، چون برای موضوعی مثل همکاری سازمانی،روایت تحلیلی و سناریومحور را مؤثرتر از یک متن صرفاً آکادمیک می‌دانم.این نوشته‌ها قرار نیست نسخه بدهند؛قرار است کمک کنند مسئله را دقیق‌تر ببینیم.اگر تازه به این مجموعه رسیده‌اید، پیشنهاد می‌کنم این دو مقاله را پیش از ادامه بخوانید:مقاله اول: وقتی MOCA را فهمیدم، تازه دیدم چرا سازمان‌ها پرکار اما کم‌اثر شده‌اندمقاله دوم: این مشکل فقط مال ما نیست؛ یک مسئله جهانی استمقاله سوم نیز نشان داد یک جلسه معمولی چطور از تولد به فراموشی می‌رسد.ادامه همان جلسه | تصمیمی که همه با آن موافق بودندبرگردیم به همان جلسه‌ای که در مقاله قبل دیدیم.بحث شد.جمع‌بندی شد.همه سر تکان دادند.حتی جمله‌ای شبیه این گفته شد:«اوکی، پس این تصمیم نهایی است.»اما یک سؤال ساده هرگز پرسیده نشد:این تصمیم دقیقاً مالِ کی است؟تصمیمی که صاحب ندارد، زنده نمی‌مانددر بسیاری از سازمان‌ها،تصمیم‌ها همین‌جا شروع به مردن می‌کنند.نه با مخالفت.نه با دعوا.بلکه با بی‌صاحبی.تصمیم گرفته شده،اما:چه کسی باید آن را جلو ببرد؟چه کسی پیگیری می‌کند؟اگر انجام نشد، به چه کسی برمی‌گردد؟پاسخ‌ها مبهم‌اند.و ابهام، قاتل خاموش همکاری است.یک جمله کلیدی (اگر فقط همین را بگیری، کافی است)تصمیم بدون مالک، فقط یک نظر مودبانه است.این جمله ساده،خیلی از آنچه در سازمان‌ها اتفاق می‌افتد را توضیح می‌دهد.ما فکر می‌کنیم تصمیم گرفته‌ایم،در حالی که فقط درباره چیزی به توافق رسیده‌ایمکه هیچ‌کس مسئول زنده نگه‌داشتنش نیست.چرا تصمیم‌های بی‌صاحب این‌قدر خطرناک‌اند؟چون:پیگیری ندارندتکرار می‌شوندفرسایش می‌آورنداعتماد را آرام‌آرام می‌خورندو بعد از مدتی:جلسه بعدی دوباره همان بحث‌ها تکرار می‌شودآدم‌ها انگیزه‌شان را از دست می‌دهندسازمان «پرکار اما کم‌اثر» می‌شودنه به‌خاطر کم‌کاری،بلکه به‌خاطر تصمیم‌هایی که هیچ‌وقت وارد عمل نشدند.یک تفکیک مهم که اغلب نادیده گرفته می‌شوددر بسیاری از سازمان‌ها، این سه مفهوم با هم قاطی می‌شوند:تصمیماقداممسئولیتتصمیم گرفتن به‌معنای اقدام نیست.اقدام کردن بدون مسئول مشخص، پایدار نیست.و مسئولیت بدون تصمیم شفاف، فقط فشار است.وقتی این‌ها از هم جدا نشوند،همکاری فرو می‌ریزد، حتی اگر نیت‌ها خوب باشد.مکث کوتاه | MOCA این‌جا چه می‌گوید؟در MOCA،تصمیم یک جمله در چت یا یک اسلاید در فایل نیست.تصمیم:یک artifact استیک owner داردوارد جریان کار می‌شودقابل پیگیری و بازگشت استنه به‌عنوان کنترل،بلکه برای اینکه همکاری واقعاً جلو برود.اینجا هنوز درباره ابزار حرف نمی‌زنیم.فقط داریم از مالکیت تصمیم صحبت می‌کنیم.همان جلسه، با تصمیم صاحب‌دارحالا همان جلسه را دوباره تصور کن،اما این‌بار:تصمیم مشخص استصاحبش معلوم استانتظار از او شفاف استبقیه تیم می‌دانند چه چیزی را باید دنبال کنندهیچ چیز عجیب نشده.فقط تصمیم، رها نشده.و همین تفاوت کوچک،اثر بزرگی روی همکاری می‌گذارد.جمع‌بندی | سازمان‌ها از تصمیم‌گیری نمی‌میرندسازمان‌ها از تصمیم‌گیری کم نمی‌میرند.از تصمیم‌های بی‌صاحب فرسوده می‌شوند.تا وقتی تصمیم:مالک نداشته باشددر جریان کار قرار نگیردو حافظه نداشته باشدهمکاری شکننده باقی می‌ماند.در مقاله بعدی،یک قدم جلوتر می‌رویم و می‌پرسیم:وقتی تصمیم صاحب دارد، چه چیزی واقعاً تغییر می‌کند؟آن‌جا تازهاثر معماری همکاری را می‌شود دید. محمود باقری محمود باقری Tue, 30 Dec 2025 11:19:27 +0330 https://virgool.io/@mahmoodBagheri/%D9%85%D9%82%D8%A7%D9%84%D9%87-%D8%B3%D9%88%D9%85-%DB%8C%DA%A9-%D8%AC%D9%84%D8%B3%D9%87-%D8%A7%D8%B2-%D8%AA%D9%88%D9%84%D8%AF-%D8%AA%D8%A7-%D9%81%D8%B1%D8%A7%D9%85%D9%88%D8%B4%DB%8C-wo4didysnkgj اگر تازه به این مجموعه رسیده‌اید، این مقاله بخشی از یک زنجیره فکری درباره MOCA (Modern Collaboration Architecture) است.برای درک کامل‌تر مسیر بحث، پیشنهاد می‌کنم ابتدا این دو مقاله را بخوانید:مقاله اول: وقتی MOCA را فهمیدم، تازه دیدم چرا سازمان‌ها پرکار اما کم‌اثر شده‌اندمقاله دوم: این مشکل فقط مال ما نیست؛ یک مسئله جهانی استاین سه مقاله کنار هم، از تشخیص مسئله شروع می‌کنند و قدم‌به‌قدم به دیدن آن در عمل می‌رسند.یادداشت نویسنده | درباره روش نگارش این مجموعهاین مقاله، مانند سایر نوشته‌های مجموعه MOCA، با کمک هوش مصنوعی تدوین شده است.اما مسئله‌مندی، روایت، مثال‌ها و مسیر تحلیلی آن، حاصل مطالعه، تجربه و خط فکری شخصی من درباره MOCA (Modern Collaboration Architecture) است.هوش مصنوعی در این مسیر نقش یک ابزار کمکی داشته؛برای ویرایش، فشرده‌سازی و تبدیل یک تحلیل مفهومی به متنی روان‌تر و کاربردی‌تر.این انتخاب آگاهانه بوده، چون معتقدم برای موضوعی مثل همکاری سازمانی،روایت سناریومحور و قابل لمس،بیش از یک مقاله صرفاً متنی و آکادمیک می‌تواند اثرگذار باشد.این نوشته‌ها قرار نیست پاسخ نهایی بدهند؛قرار است کمک کنند مسئله را در عمل ببینیم.صحنه آشنا | یک جلسه کاملاً معمولییک جلسه معمولی است.دعوت‌نامه آمده، چند نفر آنلاین‌اند، چند نفر حضوری.موضوع مشخص است.همه حرف می‌زنند.چند تصمیم هم گرفته می‌شود.در پایان، یکی می‌گوید:«خیلی خوب بود، جمع‌بندی شد.»جلسه تمام می‌شود.و دقیقاً از همین‌جا، همه‌چیز شروع به گم‌شدن می‌کند.بعد از جلسه چه می‌شود؟ (یا دقیق‌تر: چه نمی‌شود)چند ساعت بعد:تصمیم‌ها کجا ثبت شد؟چه کسی مسئول کدام کار است؟فایل نهایی کدام بود؟پیگیری چه زمانی است؟اگر کسی جدید به تیم اضافه شود، از کجا بفهمد چه شد؟هیچ‌کدام جواب مشخصی ندارند.نه به این دلیل که کسی بی‌مسئولیت است،بلکه چون هیچ‌چیز برای بعد از جلسه طراحی نشده است.جلسه مشکل نداشت؛ ما جلسه را تنها رها کردیماینجا معمولاً اشتباه تشخیص می‌دهیم.می‌گوییم:جلسه خوب نبودآدم‌ها آماده نبودندزمان‌بندی بد بوداما واقعیت این است:جلسه کار خودش را کرد؛ما همکاری را قبل و بعد از آن رها کردیم.جلسه یک «لحظه» است.همکاری یک «جریان» است.ما این دو را با هم اشتباه گرفته‌ایم.جلسه بدون معماری چه شکلی است؟در اکثر سازمان‌ها، جلسه:بدون context کافی شروع می‌شودبدون اتصال به تصمیم‌های قبلی پیش می‌رودبدون حافظه مشخص تمام می‌شودجلسه می‌آید و می‌رود،انگار یک جزیره جداستکه به هیچ‌چیز قبل و بعدش وصل نیست.و بعد تعجب می‌کنیم چرا:تصمیم‌ها تکرار می‌شوندبحث‌ها دوباره باز می‌شوندپروژه‌ها جلو نمی‌روندیک مکث لازم | این‌جا MOCA آرام وارد می‌شوددر MOCA،جلسه یک اتفاق مستقل نیست.جلسه:بخشی از یک جریان همکاری استقبلش context داردوسطش تصمیم داردبعدش action و حافظه داردنه تعریف پیچیده،نه اصطلاح خاص.فقط یک سؤال ساده:این جلسه، در جریان کار کجاست؟همان جلسه، در یک معماری همکاریحالا همان جلسه را دوباره تصور کن،اما این‌بار:قبل از جلسه:تصمیم‌های قبلی مشخص‌اندهدف جلسه شفاف استدر جلسه:تصمیم‌ها ثبت می‌شوندمالک هر تصمیم معلوم استبعد از جلسه:خروجی‌ها جایی مشخص دارندپیگیری از همان‌جا شروع می‌شودجلسه «تمام نمی‌شود»، بلکه وارد فاز بعدی می‌شودهیچ چیز عجیب نیست.فقط جلسه دیگر تنها نیست.تفاوت اصلی همین‌جاستتفاوت بین یک جلسه معمولیو یک جلسه در معماری MOCA این نیست که:ابزار بهتر استآدم‌ها حرفه‌ای‌ترندتفاوت این است که:همکاری طراحی شده است.جلسه دیگر بار اضافی نیست؛جزئی از حرکت رو به جلوست.جمع‌بندی | بیشتر جلسه‌ها بد نیستندبیشتر جلسه‌ها بد نیستند.ما فقط آن‌ها را بی‌سرنوشت رها می‌کنیم.وقتی جلسه:به تصمیم وصل نباشدتصمیم به اقدام وصل نشودو اقدام حافظه نداشته باشدطبیعی است که سازمان «پرکار اما کم‌اثر» به نظر برسد.در مقاله بعدی،یک قدم جلوتر می‌رویم:وقتی تصمیم صاحب دارد و گم نمی‌شود،همکاری چه تغییری می‌کند؟اینجا تازه داستان جدی می‌شود. محمود باقری محمود باقری Mon, 29 Dec 2025 11:41:39 +0330 https://virgool.io/@mahmoodBagheri/%D9%85%D9%82%D8%A7%D9%84%D9%87-%D8%AF%D9%88%D9%85-%D9%85%D8%B4%DA%A9%D9%84-%D9%87%D9%85%DA%A9%D8%A7%D8%B1%DB%8C-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%DB%8C-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%86%DB%8C%D8%B3%D8%AA-%E2%80%94-%D9%85%D8%A7%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%A7%D9%81%D8%AA-%D9%87%D9%85-%D8%A8%D9%87-%D9%87%D9%85%DB%8C%D9%86-%D9%86%D8%AA%DB%8C%D8%AC%D9%87-%D8%B1%D8%B3%DB%8C%D8%AF%D9%87-h2m3bulqr9ss اگر مقاله اول این مجموعه را نخوانده‌اید، پیشنهاد می‌کنم از این‌جا شروع کنید:مقاله ۱ | وقتی MOCA را فهمیدم، تازه دیدم سازمان‌ها چقدر «بی جان» شده‌اندیادداشت کوتاه نویسنده | درباره روش نگارش این مجموعهاین مقاله، مانند سایر نوشته‌های این مجموعه، با کمک هوش مصنوعی تدوین شده است.اما چارچوب فکری، مسیر تحلیل، انتخاب منابع و زاویه نگاه، حاصل مطالعات و تجربه‌های من در حوزه MOCA (Modern Collaboration Architecture) است.هوش مصنوعی در این مسیر نقش یک ابزار ویرایشی و ساختاری داشته؛برای فشرده‌سازی، شفاف‌سازی و تبدیل یک تحلیل مفهومی به متنی خوانا و کاربردی.انتخاب آگاهانه این روش، به این دلیل بوده که برای موضوعی مثل همکاری سازمانی،روایت تحلیلی و سناریومحور را مؤثرتر از یک متن صرفاً آکادمیک می‌دانم.مقدمه | چرا اصلاً باید به مایکروسافت توجه کنیم؟وقتی درباره همکاری سازمانی صحبت می‌کنیم،نادیده گرفتن Microsoft منطقی نیست.نه به‌خاطر نام یا سهم بازار،بلکه به‌خاطر مقیاس تجربه.مایکروسافت سال‌هاست با هزاران سازمان enterprise کار می‌کند؛سازمان‌هایی که:تیم‌های توزیع‌شده دارندتصمیم‌های پیچیده می‌گیرندو هزینه شکست در همکاری برایشان واقعی و سنگین استپس وقتی مایکروسافت زبانش درباره «همکاری» تغییر می‌کند،این تغییر حاصل مشاهده یک مسئله تکرارشونده در مقیاس جهانی است، نه یک ترند زودگذر.تغییر زبان مایکروسافت: از ابزار به جریانمرور اسناد رسمی مایکروسافت در سال‌های اخیر(به‌ویژه در مستندات Microsoft 365 و Microsoft Teams)نشان می‌دهد تمرکز از «ابزار» به «جریان همکاری» منتقل شده است.در این اسناد، به‌جای تأکید صرف بر chat یا meeting،مفاهیمی مثل این‌ها پررنگ شده‌اند:WorkstreamCollaboration lifecycleContextShared artifactsAsynchronous collaborationاین تغییر واژگان تصادفی نیست.مایکروسافت عملاً دارد می‌گوید:همکاری مجموعه‌ای از تعاملات جدا نیست؛یک جریان پیوسته و طراحی‌شدنی است.اعتراف غیرمستقیم: ابزار به‌تنهایی کافی نیستدر اسناد تحلیلی مایکروسافت، بارها به این نکته اشاره می‌شود که:گفتگو بدون context اثربخشی نداردجلسه بدون پیگیری ارزشی تولید نمی‌کندفایل بدون اتصال به تصمیم، به‌سرعت بی‌مصرف می‌شوداین یعنی:اضافه‌کردن ابزار جدید، مشکل همکاری را حل نمی‌کند.حتی پلتفرمی مثل Microsoft Teamsکه یکی از کامل‌ترین تلاش‌ها برای یکپارچه‌سازی همکاری است،اگر بدون تفکر معماری پیاده‌سازی شود،به همان الگوهای آشنای قبلی دچار می‌شود:کانال‌های رهاشدهجلسه‌های بی‌خروجیفایل‌های بی‌هویتمشکل Teams نیست.مشکل، نبود معماری همکاری است.نقطه اتصال | جایی که مایکروسافت و MOCA به هم می‌رسنداگر نگاه مایکروسافت را در یک جمله خلاصه کنیم:همکاری سازمانی یک سیستم است، نه یک قابلیت نرم‌افزاری.و این دقیقاً همان جایی است که مفهوم MOCA (Modern Collaboration Architecture) شکل می‌گیرد.MOCA نه محصول است،نه جایگزین Teams یا ابزارهای مشابه؛بلکه یک چارچوب فکری برای طراحی همکاری است.MOCA؛ استخراج‌شده از تجربه، نه تخیلوقتی مایکروسافت در اسنادش روی موضوعاتی مثل:lifecycle جلسهاتصال تصمیم به اقدامحفظ حافظه سازمانیکاهش وابستگی به کار هم‌زمان (sync)تأکید می‌کند،در واقع دارد اجزای همان معماری‌ای را توصیف می‌کندکه ما آن را MOCA می‌نامیم.سمت چپ: همکاری ابزارمحور (Chat / Meeting / File جدا) سمت راست: همکاری معماری‌محور (Flow یکپارچه)(در مقالات بعدی، به بخش‌های مشخص‌تری از اسناد رجوع خواهیم کرد.)جمع‌بندی | چرا این مقاله مهم است؟این مقاله قصد نداشت:Teams را تبلیغ کندیا مایکروسافت را مرجع نهایی معرفی کندهدف این بود که نشان دهد:مسئله همکاری سازمانی،مسئله‌ای شناخته‌شده و مستند در سطح جهانی است.MOCA تلاشی است برای:فهم این مسئلهترجمه آن به زبان معماریو آماده‌سازی ذهن برای طراحی آگاهانه همکاریدر مقاله بعدی،از اسناد فاصله می‌گیریمو وارد سناریوی واقعی می‌شویم:یک جلسه، یک تصمیم، و یک پیگیریدر معماری MOCA چه شکلی دارد؟ محمود باقری محمود باقری Sun, 28 Dec 2025 12:38:39 +0330 https://virgool.io/@mahmoodBagheri/%D9%88%D9%82%D8%AA%DB%8C-moca-%D8%B1%D8%A7-%D9%81%D9%87%D9%85%DB%8C%D8%AF%D9%85-%D8%AA%D8%A7%D8%B2%D9%87-%D8%AF%DB%8C%D8%AF%D9%85-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-%D9%87%D8%A7-%DA%86%D9%82%D8%AF%D8%B1-%D8%A8%DB%8C-%D8%AC%D8%A7%D9%86-%D8%B4%D8%AF%D9%87-%D8%A7%D9%86%D8%AF-wv6kgx2ts3ly یادداشت نویسندهچرا این مجموعه با کمک هوش مصنوعی نوشته شده است؟این مجموعه مقالات با کمک هوش مصنوعی تدوین شده‌اند،اما نه به‌عنوان جایگزین فکر، تجربه یا تحلیل.چارچوب فکری، مسئله‌مندی، مثال‌ها و مسیر مفهومی این نوشته‌ها حاصل مطالعات، تجربه‌های عملی و بررسی عمیق من روی MOCA (Modern Collaboration Architecture) است.هوش مصنوعی در این مسیر، نقش «ویرایشگر و فشرده‌ساز» را داشته؛ ابزاری برای اینکه ایده‌ها خلاصه‌تر، کاربردی‌تر و شفاف‌تر منتقل شوند.به‌عمد این مسیر را انتخاب کردم،چون احساس می‌کنم برای موضوعی مثل همکاری سازمانی،یک متن زنده، سناریومحور و کاربردیبیش از یک مقاله صرفاً متنی و آکادمیک می‌تواند مفید باشد.این مجموعه قرار نیست دانش را شبیه‌سازی کند؛قرار است تفکر را منتقل کند.این مقاله، قرار نیست آموزش باشد.قرار نیست تعریف دیکشنری بدهد.قرار است اعتراف باشد.لحظه‌ای که همه‌چیز به هم وصل شداولین باری که با مفهوم MOCA (Modern Collaboration Architecture) آشنا شدم، حس عجیبی داشتم.نه از جنس «ایده جدید» یا «ترند مدیریتی».بیشتر شبیه این بود که یکی یک آینه جلوی سازمان‌ها گرفته باشد.یکهو فهمیدم چرا:جلسه‌ها تمام می‌شوند، ولی کارها نهتصمیم‌ها گرفته می‌شوند، ولی پیگیری ندارندابزارها زیادند، ولی خروجی کم استهمه درگیرند، اما هیچ‌چیز جلو نمی‌رودو بدتر از همه:همه این‌ها آن‌قدر عادی شده که کسی دیگر تعجب نمی‌کند.همین شد که تصمیم گرفتم درباره MOCA، نه در یک مقاله، بلکه در یک زنجیره مقاله بنویسم.نه برای معرفی یک محصول،بلکه برای باز کردن یک زخم قدیمی که سال‌هاست رویش ابزار چسبانده‌ایم.سازمان‌ها تنبل نشده‌اند؛ بی‌معماری شده‌اندبیایید رک باشیم.اکثر سازمان‌ها امروز بی جان به نظر می‌رسند.نه چون آدم‌های بدی دارند.نه چون مدیرها بی‌سوادند.نه حتی چون ابزار ندارند.اتفاقاً برعکس:آدم‌ها سخت‌کوش‌اندابزارها متنوع‌اندجلسه‌ها زیادنداما خروجی؟تصمیم پایدار؟مالک مشخص؟حافظه سازمانی؟تقریباً هیچ.مشکل اینجاست:ما همکاری را جدی نگرفتیم؛ فقط ابزارش را خریدیم.وقتی همکاری را با «چت» اشتباه گرفتیمسال‌هاست همکاری سازمانی را خلاصه کرده‌ایم در:یک پیام‌رسانچند کانالیک تقویمیک فضای فایلو خیالمان راحت شده که «دیجیتال شدیم».اما واقعیت تلخ این است:ابزار، بدون معماری، فقط سرعت آشفتگی را بالا می‌برد.حتی پلتفرم‌هایی مثل Microsoft Teams(که اتفاقاً از بهترین‌های دنیاست)وقتی بدون تفکر معماری وارد سازمان می‌شود،خیلی زود تبدیل می‌شود به:انبوه کانال‌های رهاشدهجلسه‌های بی‌صاحبفایل‌هایی که کسی نمی‌داند کجای تصمیم‌اندمشکل Teams نیست.مشکل این است که ما فکر کردیم همکاری برابر است با ابزار.نشانه‌های یک سازمان بی جان (اگر دیدی، تعجب نکن)اگر این‌ها برایت آشناست، بدان تنها نیستی:تصمیم‌ها در جلسه گرفته می‌شوند، ولی بعدش گم می‌شوندهیچ‌کس دقیق نمی‌داند خروجی جلسه چه بودفایل هست، ولی نمی‌دانی نسخه نهایی کدام استپیام‌ها هست، ولی زمینه (context) نیستپروژه‌ها شروع می‌شوند، اما هیچ‌وقت «جمع» نمی‌شونداین‌ها نشانه بی‌نظمی نیست؛نشانه نبود معماری همکاری است.چرا دنیا به فکر افتاد؟ تولد یک نقش جدید: CCOجالب است بدانید که در بعضی سازمان‌های پیشرو،اصلاً این مشکل آن‌قدر جدی شده که یک نقش جدید به وجود آمده:Chief Collaboration Officer (CCO)نقشی که وظیفه‌اش:خرید ابزار نیستبرگزاری جلسه نیستمدیریت آدم‌ها هم نیستبلکه:طراحی و مدیریت «چگونگی همکاری» در سازمان است.این خودش یک پیام واضح دارد:همکاری دیگر یک موضوع فرعی نیست؛یک مسئله استراتژیک است.اینجاست که MOCA معنا پیدا می‌کندMOCA از این سؤال ساده شروع می‌شود:اگر همکاری را مثل یک سیستم طراحی کنیم، نه یک ابزار، چه می‌شود؟در MOCA:انسان‌ها نقطه شروع‌اند، نه ابزارجریان کار مهم‌تر از فیچر استجلسه، پروژه، تصمیم و پیگیری از هم جدا نیستندهمکاری «اتفاقی» نیست؛ طراحی‌شده استو مهم‌تر از همه:MOCA نمی‌پرسد «چه ابزاری بخریم؟»می‌پرسد:«همکاری در سازمان ما باید چطور اتفاق بیفتد؟»جمع‌بندی | این تازه شروع ماجراستاین مقاله قرار نبود راه‌حل بدهد.قرار بود یک چیز را روشن کند:اگر سازمانت خسته است،اگر آدم‌ها فرسوده‌اند،اگر خروجی کمتر از تلاش است،به‌احتمال زیاد مشکل:کمبود ابزار نیستکمبود نیروی انسانی نیستمشکل، نبود معماری همکاری است.در مقاله‌های بعدی:دقیق‌تر می‌رویم سراغ MOCAسناریو واقعی می‌سازیمنشان می‌دهیم یک جلسه، یک پروژه، و حتی یک تصمیم، در معماری درست چه شکلی می‌شوداینجا نقطه‌ای است کهداستان MOCA شروع می‌شود.لینک مقاله دوم محمود باقری محمود باقری Sat, 27 Dec 2025 11:59:39 +0330 https://virgool.io/@mahmoodBagheri/%D9%87%D8%B1-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%DB%8C-%DB%8C%DA%A9-%D9%BE%D8%A7%DA%A9%D8%B3%D8%AA%D8%A7%D9%86-%D8%AF%D8%A7%D8%B1%D8%AF-avuya19nhqgr درباره‌ی تیم‌هایی که قربانی سیاست خارجی ضعیف می‌شوندبعد از سال‌ها کار در شرکت‌ها و تیم‌های مختلف، به یک الگوی تکرارشونده رسیده‌ام:تقریباً در هر سازمانی، تیمی وجود دارد که می‌توان آن را «پاکستان سازمان» نامید.در ابتدا لازم می‌دانم تأکید کنم که این تشبیه به‌هیچ‌وجه توهین به هیچ کشور یا مردمی نیست. از این مثال صرفاً برای توضیح یک الگوی رفتاری و ساختاری استفاده می‌کنم؛ الگویی که سال‌ها در سازمان‌های مختلف دیده‌ام و اخیراً به شکل جدی‌تری با آن درگیر بوده‌ام. همین تجربه‌ها انگیزه‌ی نوشتن این مقاله شد.هدف این نوشته، توصیف یک مشکل رایج در سازمان‌ها و ارائه‌ی راهی برای کاهش اصطکاک‌های درون‌تیمی است؛ مشکلی که ریشه‌ی آن نه فنی است و نه انسانی، بلکه ساختاری و ارتباطی است.چرا پاکستان؟جهان و نظم بین‌المللی شباهت زیادی به ساختار یک سازمان دارد:کشورها مثل تیم‌ها هستند، منافع متفاوت دارند، منابع نامتقارن، و روابطی که اگر درست مدیریت نشود، به بحران ختم می‌شود.سیل‌های اخیر پاکستان جرقه‌ی این تشبیه را در ذهن من روشن کرد. پاکستان ویژگی‌هایی دارد که آن را به نمونه‌ی مناسبی برای توضیح این الگوی سازمانی تبدیل می‌کند.بیشترین آسیب، کمترین نقشاز مجموع دی‌اکسیدکربن تولیدشده در جهان از سال ۱۹۵۹، سهم پاکستان حدود ۰٫۴ درصد است. در مقابل، کشورهای صنعتی مانند آمریکا و چین به ترتیب با حدود ۲۱٫۵ درصد و ۱۶٫۴ درصد، نقش اصلی را در گرمایش زمین داشته‌اند.با این حال، پاکستان یکی از آسیب‌پذیرترین کشورهای جهان در برابر تغییرات اقلیمی است. افزایش بی‌سابقه‌ی بارندگی، ذوب یخچال‌های طبیعی و شرایط جغرافیایی باعث شد در سیل‌های اخیر، حدود یک‌سوم کشور به زیر آب برود؛ بحرانی که بیش از همه دامان کشوری را گرفت که کمترین سهم را در ایجاد آن داشت.«پاکستان»‌های سازمانی چه کسانی هستند؟در سازمان‌ها نیز تیم‌هایی وجود دارند که:کمترین نقش را در تصمیم‌های کلان دارنداما بیشترین فشار و آسیب را تحمل می‌کنندنمونه‌ی بارز این تیم‌ها، تیم‌های زیرساخت، پلتفرم یا میان‌افزار هستند؛ تیم‌هایی که سرویس تولید می‌کنند تا سایر تیم‌ها از آن استفاده کنند.وقتی استفاده‌ی نادرست از یک سرویس اتفاق می‌افتد:تبعات آن قبل از همه به تیم سازنده برمی‌گرددسیل انتقادها معمولاً به سمت تولیدکننده است، نه مصرف‌کنندهاصلاح خطاها اغلب بر عهده‌ی همان تیمی است که «کمترین تقصیر» را داشتهاین وضعیت به‌تدریج چند اثر مخرب ایجاد می‌کند:فرسودگی و خستگی مزمن اعضای تیمتخریب روحیه و انگیزهاز بین رفتن اعتماد بین‌تیمیشکل‌گیری نگاه تدافعی نسبت به کل سازمانمسئله‌ی اصلی: نه فنی است، نه انسانی؛ دیپلماتیک استدر این نقطه معمولاً تحلیل‌ها اشتباه می‌روند.مشکل این تیم‌ها کمبود تخصص یا بدخواهی نیست.مشکل اصلی، نبود یک سیستم روابط خارجی سالم است.در بسیاری از این تیم‌ها:ارتباط با سایر تیم‌ها واکنشی است، نه فعالپاسخ‌ها کوتاه، قاطع و بدون توضیح‌اند«نه» گفته می‌شود، بدون اینکه روایت یا زمینه‌ای ارائه شودو همین «نه»‌ها، آغاز بحران‌اند.«نه» بدون دیپلماسی، اعلان جنگ استدر سازمان، «نه گفتن» ذاتاً بد نیست.اما:نه بدون توضیح منجر به قطع همکاری بین تیمی می شودنه بدون همدلی به بی اعتمادی خواهد رسیدنه بدون مسیر جایگزین به موازی کاری یا ساختن سیستم های سایه منجر می شودبسیاری از اختلافات عمیق سازمانی از همین‌جا شروع می‌شود؛ جایی که یک تیم می‌گوید:«این کار شدنی نیست»اما:چرا شدنی نیست؟چه زمانی ممکن می‌شود؟چه جایگزینی وجود دارد؟پاسخی داده نمی‌شود.نتیجه؟تیم مقابل تصمیم می‌گیرد سرویس را خودش بسازد، از مسیر رسمی عبور نکند، یا وارد جنگ فرسایشی شود.قدرت اتمی، سیاست خارجی سنتیپاکستان با وجود اینکه کشوری در حال توسعه است، قدرت اتمی محسوب می‌شود.قدرت دارد، اما سیاست خارجی آن اغلب تدافعی، سنتی و واکنشی است. همین تضاد، آن را وارد تعارض‌های مداوم کرده است.در سازمان‌ها نیز تیم‌هایی وجود دارند که:دانش انحصاری دارندزیرساخت حیاتی را کنترل می‌کنندقدرت واقعی در اختیارشان استاما روابط بین‌تیمی را همچنان به شیوه‌ای سنتی و بسته مدیریت می‌کنند.این تضاد، زمینه‌ساز بحران‌هایی شبیه «کشمیر سازمانی» می‌شود:دو تیم وابسته به هم، هر دو قدرتمند، اما فاقد گفت‌وگوی سازنده.راه‌حل: هر تیم قدرتمند، به «وزارت امور خارجه» نیاز داردراه‌حل این مسئله، تغییر ماهیت تیم فنی نیست.راه‌حل، اضافه کردن یک نقش مشخص برای دیپلماسی سازمانی است.نقشی که:زبان فنی را به زبان کسب‌وکار ترجمه کندقبل از بحران، انتظارات را تنظیم کند«نه»‌ها را قابل فهم، قابل پذیرش و قابل مذاکره کنداین نقش می‌تواند:Platform PMTechnical Liaisonیا هر عنوان دیگری داشته باشداما یک شرط حیاتی دارد:باید اختیار، دسترسی و حمایت مدیریت ارشد را داشته باشد.بدون این سه، این نقش تبدیل می‌شود به روابط عمومی بی‌اثر یا سپر انسانی تیم فنی.جمع‌بندیبسیاری از بحران‌های تیمی، نه از ضعف فنی می‌آیند و نه از نیت بد.آن‌ها محصول نبود دیپلماسی سازمانی هستند.تیم‌هایی که امروز «پاکستان سازمان» شده‌اند:اغلب قربانی ساختارند، نه مقصر آنو بدون اصلاح روابط خارجی، هرچقدر هم قوی باشند، فرسوده می‌شونداگر سازمان‌ها یاد بگیرند:چگونه نه بگویندچگونه توضیح بدهندو چگونه مذاکره کنندبخش بزرگی از جنگ‌های درون‌سازمانی، اصلاً شکل نخواهد گرفت. محمود باقری محمود باقری Mon, 22 Dec 2025 13:39:10 +0330 https://virgool.io/blue-white/%D8%A7%D9%88%D9%84%DB%8C%D9%86-%D9%85%D8%B4%D8%AA%D8%B1%DB%8C%D8%A7%D9%86-%DB%8C%DA%A9-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-saas-software-as-a-service-%D8%A8%D8%A7%DB%8C%D8%AF-%D9%87%D8%A7-%D9%88-%D9%86%D8%A8%D8%A7%DB%8C%D8%AF-%D9%87%D8%A7-m6nwrwg4zqey بدون شک مهمترین بخش یک کسب و کار SaaS اولین مشتریان آن کسب و کار هستند. این مشتری ها مسیر حرکت شما، دلایل ماندگاری و ریزش مشتریان و اطلاعاتی برای پایداری محصول شما را در اختیارتان قرار می دهند.اما چگونه این مشتری ها را میتوان بدست آورد، حفظ کرد و با آنها در ارتباط بود و در هر زمانی از عمر این محصول چگونه باید با این مشتری ها برخورد کرد. متاسفانه از همان ابتدای راه اندازی یک محصول SaaS صاحبان آنها به فکر رشد آنها هستند و از روشهایی که باید اولین مشتری های خود را بدست بیاورند و حفظ کنند غفلت می کنند. در این مقاله بیشتر روی مشتری های اول تمرکز میکنیم و مقاله های بعدی را در مورد روش های هک رشد و مثالهایی از آنها ادامه خواهیم داد.اصولا زمانی که صاحبان یک استارت آپ به فکر راه اندازی آن می افتند دو خطای بزرگ در مورد اولین مشتریان خود میکنند.۱- آنقدر وارد مباحث فنی و گسترش برنامه هستند که اصلا به سراغ مشتری نمی روند.۲- از همان ابتدا تنها به فکر رشد و روش های رشد مشتریان خود هستند.اولین تجربه من برای ساختن یک برنامه SaaS به سال ۹۱ برمیگرده. زمانی که در یک شرکت با مشتریان Enterprise کار میکردم و تصمیم گرفتیم برنامه ای تولید کنیم و شرکتهای حوزه کوچک تر(Small&Meduim) را هم وارد چرخه مشتریان بکنیم. حاصل کار یه شکست بزرگ بود و تنها دلیل آن ذهنیت آدمهایی بود که از حوزه Enterprise وارد تولید این محصول شده بودند.در این محصول بیشتر از فروش و مشتری تیم درگیر تحلیلگران سیستم قبلی شده بود. بعد از ساخت هر قابلیت نظرات تیم تحلیل شروع می شد و صدها استثناء که تحلیلگران سیستم قبلی بر حسب تجربه دیده بودند مطرح میشد؛ غافل از اینکه، محصول قبلی یک محصول Enterprise بود. پس تیم دوباره مشغول تغییرات و اضافه کردن قابلیت ها جهت رفع استثناها میشد؛ و راه اندازی محصول تا زمان رفع آنها به تعویق می افتاد. این کار آنقدر ادامه پیدا کرد تا زمانی که تصمیم گرفتیم اولین مشتری را روی محصول بیاوریم و متوجه شدیم محصولی مشابه محصول Enterprise قبلی تولید کرده ایم که نه از نظر کارکرد و نه از نظر سادگی مناسب بازار مشتریان مد نظر ما نبود. حاصل کار یک شکست بزرگ بود که تنها دلیل آن نبودن یک بازخورد مناسب از تعدادی مشتری اولیه برای ارزیابی خواسته های مناسب محصول بود. گرچه بعد ها خیلی تلاش کردیم که با یک چرخش (Pivot) و استفاده از قابلیت های آن محصول، وارد بازار خارج از ایران شویم ولی متاسفانه باید اعتراف کنم که نتیجه با فکر اولیه برای تولید، بسیار متفاوت بود.از طرف دیگر بعد از گذشته بیش از یک سال و نبود مشتری و تنها تولید، حتی تیم تولید که تیم حقوق بگیر بود انگیزه های کافی برای ادامه کار و تغییرات در محصول را نداشت و دلیل آن این بود که برای ورود به بازار بسیاری از قابلیت ها، که زمان زیادی از هر شخص را گرفته بود و بعضا افراد به تولید آن افتخار میکردند باید از محصول حذف یا بسیار کوچک می شدند.اما سوی دیگری هم وجود دارد. زمانی که صاحبان یک برنامه SaaS آنقدر رویاپردازی می کنند که از همان ابتدا تنها به روش های رشد محصول به صورت انبوه فکر میکنند. از همان ابتدا به صفحه اول موتور های جست و جو بیاییم یا روش های دیجیتال مارکتینگ استفاده کنیم. رشد های عجیب و بعضا چند صد در صدی داشته باشیم که در ابتدای کار، شاید کار بسیار سختی هم نباشد. متاسفانه صاحبان این محصول سوی دیگر نرخ رشد که نرخ ریزش است را فراموش کرده اند. آنها فراموش کرده اند که علاوه بر هزینه های جذب، هزینه های نگهداری مشتری نیز از اهمیت خاصی برخوردارند و به جای تمرکز روی پایداری محصول و جلوگیری از خطا ها و لذت بخش کردن کار با محصول تنها بر روی افزودن مشتری تمرکز کرده اند. شاید این محصولات شروع خوبی داشته باشند اما اصولا به مرور زمان نرخ ریزش آنها افزایش پیدا میکند و در بسیاری از مواقع به دلیل ایجاد یک خاطره بد در ذهن مشتریان دیگر قادر با بازگرداندن مشتریان سابق خود که بعضا زیاد هم هستند نخواهند بود.اما واقعا اولین مشتریان چه کسانی هستند، چه کسی و از چه طریقی باید آنها را به کسب وکار اضافه کند.شاید مقاله ی Do Things that Don't Scale - Paul Graham بسیار زیبا در قسمتی به نام تازه وارد ها (Recruit) موضوع جذب اولین مشتریان را مطرح کرده است. این مقاله به موارد زیادی اشاره کرده که موجب رشد یک استارت آپ نمی شود ولی به موفقیت آن کمک خواهد کرد که امیدورام در آینده ای نزدیک به صورت یک ترجمه بتوانم از همین طریق در اختیار شما قرار دهم.بدون شک برای بدست آوردن اولین مشتری ها نشستن و منتظر ماندن بزرگترین خطاست. صاحبین کسب و کار باید از محل کار بیرون بروند و مشتری پیدا کنند و آنها را به سیستم اضافه کنند. برای مثال Stripe که در حال حاضر با جذب ۱۵۰ میلیون دلار در سرمایه‌گذاری جدید، به ارزشی بالغ بر ۹ میلیارد دلار رسید و کمپین‌های انتخاباتی دو نامزد انتخابات اخیر آمریکا از جمله‌ مشتریان این شرکت بوده اند یکی از موفق ترین استارت آپ ها در حوزه مالی بوده است. مشکلی که این شرکت توانست حل کند مشکلی حیاتی بود و اگر استارت آپی بتواند بشیند و منتظر مشتری باشد بی شک Stripe است. اما آنها بخاطر جذب مشتریان اولیه خود معروف هستند. به روشی که Stripe برای جذب مشتری اولیه اختراع کرده است "Collison installation" گفته می شود. بنیانگذاران سؤال می کنند "آیا نسخه بتا ما را امتحان می کنید؟" و اگر جواب مثبت است ، آنها می گویند "عالی ، ما لینکی برای شما ارسال خواهیم کرد." اما برادران کولیسون ( برادران ایرلندی و بنیان گذار Stripe) منتظر نبودند. وقتی کسی موافقت کرد که Stripe را امتحان کند ، می گفتند "عالیه ، لپ تاپ خود را به من بده" و برای آنها در همان محل تنظیمات استفاه از محصول خود را انجام میدادند.به دو دلیل بنیان گذاران استارت آپ ها از محل کار خود خارج نمیشوند و به سراغ مشتری نمی روند.دلیلی اصلی که خیلی از بنیانگذاران استارت آپ ها برای بیرون رفتن و جذب تک تک مشتری مقاومت می کنند ترکیبی از کمرویی و تنبلی است. خیلی از آنها ترجیح میدهند که در محل کار بشینند و کد بزنند تا اینکه با مردم و غریبه ها صحبت کنند و از آنها نه بشنوند. اما حقیقت این است که برای شروع باید حداقل یکی از بینانگذاران (معمولان CEO) زمان زیادی را برای فروش و مارکتینگ صرف کند. دلیل دیگر هم این است که این تعداد مشتری و رشد برای بسیاری از آنها بسیار کوچک به نظر می آید. اما آنها قدرت رشد مرکب را فراموش کرده اند. اگر نرخ رشد هفتگی را، برنامه های SaaS و استارت آپ ها محاسبه کنند و تلاش کنند که هر هفته ۱۰ درصد نسبت به هفته قبل مشتری های خود را افزایش دهند به مرور هم میتوانند محصول خود را رشد دهند و هم دامنه مشتریان خود را افزایش دهند.راه های مخلتفی برای بدست آوردن هزاران کاربر وجود دارد که در مقاله بعدی با عنوان روشهای هک رشد تعدادی از آنها را بررسی میکنیم اما شاید بهترین روش برای شروع جذب کاربران به صورت رو در رو یا روشهای سنتی مثل تلفن زدن یا معرفی محصول به مشتریان آشنا و قبلی باشد و کم کم به روشهای دستی کمتر مثل روش های بازیابی دیجیتال روی بیاورید.نمونه بسیار مشخص این روش Airbnb است. Airbnb وبسایتی است که مردم در آن مکان‌های اقامتی‎ ‎را کرایه می‌دهند.‏‎ ‎این وبسایت دارای بیش ‏از 1500000 مکان فهرست شده در 34000 شهر و 190 کشور است. بدست آوردن بازار گاهی اونقدر سخت است که نیاز به فعالیت های قهرمانه ای دارد. در مورد Airbnb، افراد تیم برای شروع بازار به تک تک خانه ها در نیویورک سر میزدند و سعی میکردند مشتری جذب کنند یا مکانهای جدیدی به لیستشون اضافه کنند. شام سه شنبه های Airbnb معروف است؛ کارکنان زمانی که به محل شام می رسیدند کوله پشتی هایی که از بازاریابی منزل به منزل با خود می بردند هنوز همراهشان بود و از مسیر به محل شام می آمدند.به هر حال یه محصول با مشتریان خود زنده خواهد بود اما شاید مشتریان زیاد در شروع کار عامل مرگ یک محصول شوند. از طرفی همیشه به خاطر داشته باشید که با نشستن و منتظر ماندن هیچ مشتری از محصول شما استفاده نخواهد کرد. محمود باقری محمود باقری Sun, 03 Nov 2019 18:14:32 +0330