https://virgool.io/feed/@mhamidreza مدیریت محصول در hamidreza.net fa 2026-06-07 11:35:47 https://files.virgool.io/upload/users/4737/avatar/pLk7rZ.png?height=120&width=120 https://virgool.io/@mhamidreza https://virgool.io/@mhamidreza/%D8%B4%D8%B1%D8%AD%DB%8C-%D8%A8%D8%B1-%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%85%D8%B3%D8%AA%D9%86%D8%AF%D8%B3%D8%A7%D8%B2%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84%D8%A7%D8%AA-%DA%86%D8%A7%D8%A8%DA%A9-bclquphekbll مستندسازی در چابک Lean/Agileتصمیم گرفتم مواردی که جهت بهبود فرآیند documentation در چابک/لین تجربه کردم رو در اینجا ذکر کنم امیدوارم مفید باشه. خوشحال میشم اگر نظر یا تجربه ای در جهت تکمیل/اصلاح این موارد دارید کامنت کنید تا سایر دوستانِ مشتاق هم بتونن استفاده کنند.1. آنچه که در مستندسازی حائز اهمیت است موضوع just-enough بودنش هست، در واقع تمام انتقاداتی که به شیوه های قبلی مستندسازی میشه برای more than enough بودنشون هست و اینکه دیگه از "راهنما" خارج و تبدیل به رُمان میشن.2. تا جایی که دیدم دو تایپ اصلی برای مستندسازی در Agile مرسوم هست یکی سندی هست که تیم در آینده برای تغییر و نگهداری محصول ممکن هست بهش refer کنه که میتونه در برگیرنده کد استایل، استوری ها، criteria های مهم، بزنس رول ها، مپ ها، flow ها، دیاگرام ها، موارد مهم بزنس محصول، کامنت های کد، اسامی و شرح یک خطی تست ها، خلاصه API ها، سند خلاصه معماری، تصمیمات طراحی، باگ ها، توضیحات بدهی فنی، موارد Deploy و سایر مواردی که برای تیم ها یا محصولات مختلف مورد نیاز است. سند دوم برای onboarding نیروی جدید مورد استفاده قرار میگیره و هدفش افزایش سرعت در پروسه آنبوردینگ فرد جدید هست در واقع میشه گفت بیشتر در Knowledge Management سازمان جای می گیره. تیم میتونه brainstorm کنه و سرفصل های هر دو سند رو تهیه کنه و تصمیم میگیره چه مواردی در کدوم سند و در چه سر فصلی باید قرار بگیره یا اشتراکات رو تعیین می کنه.3. سندها باید از لحاظ ادبیات و شیوه نگارش طوری نوشته بشن که از misunderstanding جلوگیری کنه و کاملاً Clear باشه. توصیه اکید میشه هر مستندی دارای یک goal باشه تا خواننده با خواندن اون goal بفهمه که کلیات چی هست و تصمیم به خواندن یا نخواندن رو سریع بتونه بگیره. از مثال، جدول و نمودار برای افزایش Clarity میشه استفاده کرد. ترجیحاً سندها in tandem نوشته یا review بشن یعنی دو یا سه نفر انجام بدن نه یک نفر. همچنین قابلیت سرچ، نظم و طبقه بندی خیلی مهم است در واقع UX خوبی باید براش ایجاد شود.4. سندها باید به طور مداوم در چارچوب continuous improvement قرار بگیرند و به روزرسانی (افزودن، تغییر و حتی حذف) بشن. داکیومنت ها وقتی استفاده میشن در واقع در حال تست هستن و استفاده کننده ها باید فیدبک بدن و این فیدبک منتج به اصلاح بشه.5. لازم نیست همه چی text باشه می تونید از عکس استفاده کنید مثلاً بعد از یک جلسه مهم از وایت بورد عکس بگیرید یا آن چیزی که روی کاغذ کشیدید رو استفاده کنید یا یک audio باشه ولی براش باید tag بزنید که در سرچ بتونید پیداش کنید.6. دقت کنید که داکیومنت کردن خودش یک کار جاری در اسپرینت هست و جزئی از زمانی که تیم در اسپرینت صرف می کنه باید وقفش بشه. جهت الزام به انجام، داکیومنت میتونه در قالب criteria آورده شه. اگر در حالت enough بهش نگاه کنید هیچ cost ای برای تیم نداره و جلوتر قطعاً چندین برابر این زمان و انرژی که براش صرف شده به تیم باز خواهد گشت. نکته مهم این است که روش های قبلی مستندسازی عموماً به صورت Document Late Strategy انجام میشد به این معنی که آخر کار سراغ داکیومنت کردن میرفتن در حالیکه در Agile به این صورت نیست و اصطلاحاً باید به صورت Document Continuously Strategy و پیوسته انجام بشه.7. اگر documentation فراموش بشه و یا value کمی بهش داده شه قطعاً تیم در آینده از چابکی خارج خواهد شد. این مورد به دفعات در استارتاپ هایی که درscale هستن به وضوح تجربه شده و زمان و انرژی زیادی میبره تا تیم به state قبلی برای حل مشکل یا اعمال تغییر برگرده. با این حرف که در داکیومنت کردن در تیم های سریع قابل انجام نیست، موافق نیستم چون به همون سرعت هم میشه enough ها رو نوشت. البته seniority تیم هم نقش پر رنگی در اینجا ایفا می کنه.8. نکته پایانی نگرش تیم به documentation هست اگر تمرکز روی why مفهوم مستندسازی گذاشته شه در اولویت قرار می گیره به طوریکه در culture سازمان نهادینه میشه. نظر شخصی م این هست که تیمی که میتونه موارد بالا را بخوبی هندل کنه تیم invaluable ای هست و البته قبول دارم که کم پیدا میشه ولی هست.موفق باشید. حمیدرضا متقیان Hamidreza Motaghian حمیدرضا متقیان Hamidreza Motaghian Thu, 25 Nov 2021 11:59:47 +0330 https://virgool.io/@mhamidreza/%D8%A8%D8%A7%D9%88%D8%B1-agile-%DA%86%D8%A7%D8%A8%DA%A9-vghesn3ljvg7 یک روز صبح از خواب بلند میشم و به خودم میگم از امروز من میخوام سلامت تر زندگی کنم و تصمیم می گیرم هر روز یه سیب بخورم. حتماً اون ضرب المثل بلاد خارجه رو شنیدید که میگه: An Apple a Day, Keep Doctor Away...اما جالب اینجاست که من در کنار خوردن سیب همچنان به خوردن فست فودها ادامه می دم، تحرک زیادی هم ندارم، زیاد میخوابم و خلاصه اینکه هیچ کدوم از عادت های قبلیم رو که برای سلامتی مضر هست ترک نکردم! به نظر شما با این وضعیت، خوردن سیب میتونه من رو از دکتر دور کنه؟ بدیهی است که اینطور نخواهد بود و مسلماً سلامتی من رو به بهبود نخواهد رفت. در نتیجه از سیب خوردن دیگه ناامید میشم و به خودم میگم اینم فایده نداشت! این نکته در توسعه نرم افزار هم صادق هست. شرکت یا سازمان شما تصمیم گرفته اجایل کار کنه، جلسات متعددی برگزار شده، بسترسازی های سازمانی! انجام شده و خیلی کارهای دیگه اما نکته مهم اینه که:آیا به صرف گفتن چابک و اسکرام کار کردن و برگزاری ۴ تا جلسه stand-up و داشتن رول های SM و PO میتونیم به نتیجه برسیم؟آیا عادت های قدیمی ای که در توسعه نرم افزار داشتیم رو ترک کردیم؟آیا مدیریت منابع انسانیمون مثل گذشته هست؟آیا هنوز خودمون رو عالم دهر میدونیم و از هیچ کس مشورت نمی گیریم؟آیا از مشارکت و همراهی افراد زیر مجموعه مون لذت می بریم و یا هنوز باور داریم که من رده سازمانیم از فلانی بالاتره؟یک سازمان یا یک تیم زمانی Agile خواهد شد که علاوه بر اینکه اصول ۱۲ گانه چابک رو درک کرده و بهشون باور قلبی داره، هر آنچه که با این اصول در نتاقض هست رو هم ترک کنه و نگرش خودش رو تغییر بده. تنها در این حالت هست که تفکر اجایل و متدهای وابسته ش میتونه در توسعه محصول موفق تاثیرگذار باشه.این پست اولین بار در تاریخ 1391/03/31 در وب سایت hamidreza.net منتشر شده است. حمیدرضا متقیان Hamidreza Motaghian حمیدرضا متقیان Hamidreza Motaghian Wed, 30 Oct 2019 19:30:08 +0330 https://virgool.io/@mhamidreza/%DB%B2%DB%B4-%D8%AA%D9%84%D9%87-%DB%8C-%D8%B1%D8%A7%DB%8C%D8%AC-%D8%AF%D8%B1-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-frzsnf1b1vwn در این پست در ادامه مقاله قبلی، به بررسی ۱۲ تله دیگر در اسکرام خواهم پرداخت که امیدوارم با در نظرگرفتن این موارد بتوانید با کارایی بالاتری اسکرام را اجرا کنید. https://virgool.io/Software/%DB%B2%DB%B4-%D8%AA%D9%84%D9%87-%DB%8C-%D8%B1%D8%A7%DB%8C%D8%AC-%D8%AF%D8%B1-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-tfjay4orux2x با فرضیات پیش رفتناغلب اعضای تیم اسکرام، موفق به سوال از Product Owner در مورد جزئیاتی که در حال انجامش هستند نمی شوند و یکی از اعضای تیم مشکلات رو حل می کند در حالیکه که این فرد درباره محدودیت های محصول اطلاعات کاملی ندارد و با فرضیات خودش تصمیم گیری می کند. ارتباط و بازخورد بین خروجی تیم و PO باید روزانه در هر اسپرینت انجام بگیرد.تکمیل (DONE) نشدن Taskهااین خیلی سخت است که بتونیم از به تعویق انداختن کارهایی که کامل نشدند و مقدار کمی از اونها باقی مونده جلوگیری کرد اما این موضوع میتونه به عنوان یک عادت در تیم باشه چرا که همیشه کارهای جدیدی ممکن است اضافه بشوند و کارهای قبلی ۱۰۰ درصد به اتمام نرسند. در چنین حالتی استفاده از Burndown Chart توصیه میشه و همچنین ارائه دمو نیز باید انجام شه حتی اگر همه Task ها تکمیل نشده باشند.آماده نشدن دموبعضی اوقات ممکن است تیم فراموش کنه که آماده سازی دمو نیاز به صرف زمان لازم داره مثل تمیز کردن محیطی که تیم در اون داره کار می کنه، آماده سازی مکان ارائه دمو، نوشتن متن هایی که باید در جلسه راجع بهش توضیحاتی داده بشه، اطمینان حاصل کردن از حضور ذینفعان. این فعالیت ها می تونن جزئی از Taskهای موجود در Sprint Backlog باشند.آماده نشدن پروتوتایپ ها برای ارائهتیم اسکرام تلاش می کنه یک محصول با کیفیت تولید کنه به طوری که از همان اسپرینت های اولیه باید محصول پتانسیل ارائه شدن را در خودش داشته باشه. ساختن کد-پروتوتایپ ها باعث تاخیر در لزوم نوشتن کدهای نهایی میشه. از جزئیات در طراحی و کلاً هر کاری که باعث به تعویق افتادن بشه باید اجتناب کرد.تیم توزیع یافتهاگرچه اسکرام به طور رسمی بر حضور کل اعضای تیم در یک محل تاکیدی نکرده اما حقیقت این است  عدم حضور اعضاء تیم در یک محل تاثیر منفی بسیاری در ارتباطات و شفافیت میذاره که در نتیجه این تاثیر به کارایی و کیفیت نیز سرایت خواهد کرد.اسکرام مستر دایرکتیواسکرام مستر یک تسهیل گر است که از تیم برای یادگیری قوانین اسکرام و خودسازماندهی پشتیبانی می کند. یک اسکرام مستر هرگز نباید وسوسه شه تا به یکی از اعضای تیم توصیه کنه که کارش رو چطوری باید انجام بده.تغییر عضویت تیماسکرام یک چارچوب است برای خلق تیم های توسعه محصول با کارایی بالا. اگر عضویت یکی از اعضای تیم بخواد تغییر کنه باید مدل Forming-Storming-Norming-Performing در تیم دوباره بازسازی شه که این مساله برای تیم و محصول ایجاد سربار خواهد کرد.نقش های غیر اسکرامی در تیمدر برخی از سازمان ها این معمول است که اسکرام رو استفاده کنند بدون اینکه عناوین شغلی و شرح وظایف این عناوین تغییر کنه. مثلاً مدیر پروژه در نقش مالک محصول میشه با همون شرح وظایفی که قبلاً داشته.رها کردن کیفیتبرای تیم اسکرام خیلی ساده است که بجای اینکه در تمام زمان ها کیفیت رو در سطح بالایی حفظ کنه بیاد صرفاً جاهایی که حدس میزنه بیشتر مشکل ساز میشه رو رفع باگ کنه که این البته میتونه متاثر از فشار کاری حاکم بر تیم باشه.تحمیل محدودیت زمانی یا منابعاسکرام مبتنی بر واقعیت ها است. اگر یکی از ذینفعان خارجی قصد داره تحمیل زمانی یا منابعی بر روی تیم انجام بده، باید بپذیره که این مساله مسلماً منجر به لغزش در کیفیت خواهد شد و این خلاف اصول اسکرام است. واقعیت این است که هیچ کس آینده رو نمیتونه پیش گویی کنه و تحمیل و فشار آوردن به تیم یک وهم است.تحمیل کردن استانداردها به جای مفهوم DoDعموماً مفهوم DoD با استانداردها اشتباه گرفته میشه. مدیران و بعضی از ذینفعان مفهوم استانداردها رو به جای DoD در نظر میگیرن و توقعشون از تیم این است که استانداردها رو باید انجام بدهند.حاضر نبودن اسکرام مستراسکرام مستر به دلیل ماهیت نقشی که در تیم اسکرام داره باید همیشه حاضر باشه و این موضوع کمک زیادی به سرعت بخشیدن در انجام Task ها و حرکت رو به جلوی تیم میشه.این پست اولین بار در تاریخ 1395/05/18 در وب سایت hamidreza.net انتشار یافته است. حمیدرضا متقیان Hamidreza Motaghian حمیدرضا متقیان Hamidreza Motaghian Wed, 30 Oct 2019 19:15:37 +0330 https://virgool.io/Software/%DB%B2%DB%B4-%D8%AA%D9%84%D9%87-%DB%8C-%D8%B1%D8%A7%DB%8C%D8%AC-%D8%AF%D8%B1-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-tfjay4orux2x همونطور که می دونید اسکرام(Scrum) محبوب ترین فریم ورک Agile (چابک) است اما انجام صحیحش کار ساده ای نیست! برای این که شما هم بتونید اسکرام را درست پیش ببرید مواظب باشید در این تله ها گرفتار نشین:۱ افراط در مقدمه­ سازی و برنامه ریزی قبل از شروع هر اسپرینت در اسکرام، نیازی نیست اصطلاحاً مته به خشخاش بذارید و بخواین در ابتدا همه مقدمات برگزاری اسپرینت آماده بشه و بعد اون رو برگزار کنید. این موضوع مخصوصاً در اسپرینت اول خیلی اتفاق میفته. کار رو شروع کنید و در Sprint Review آنچه که اتفاق افتاده رو بررسی کنید. حتی اگر Product Backlog هم برای اسپرینت اول آماده نیست باز مشکلی وجود نداره و می تونید این اسپرینت رو برگزار کنید. ۲ تمرکز بیش از حد بر روی ابزارخیلی از افراد یا شرکت ها مرتب دنبال این هستن که ببینن چه ابزار جدیدی اومده که میتونه در جهت پیشبرد اسکرام بهشون کمک کنه حتی اگر ندونن اصلاً اسکرام چی هست. اولین چیزی هم که در مباحثه ها به شما میگن اینه که ما از فلان ابزار استفاده می کنیم شما از چی استفاده می کنین؟! انگار اسکرام کِرِم دور چشم شده که مارکش مهم باشه! واقعاً شما اسکرام رو با همون حداقل ابزارهای خودش میتونین پیش ببرید. نهایت امر یه Excel نیاز خواهید داشت و لا غیر. وقتی رو هم که صرف جستجو، یادگیری و آزمون و خطای این می کنید که کدوم ابزار به کار شما میاد رو صرف افزایش دانشتون در خود اسکرام کنید. ۳ حل مشکلات در جلسه Stand-up این جلسه، از جلسه های کوتاه بسیار مفید در اسکرام است و قرار نیست به طول بیانجامد. هرگز وقت این جلسه رو صرف بررسی چراها، علت ها، تعیین مقصرین، نق زدن ها، داستان گفتن ها و … نکنید. همون سه سوال اصلی رو کوتاه و مختصر پاسخ بدید. اسکرام مستر در این جلسه نقش کلیدی ای رو بازی میکنه. ۴ تعیین وظیفه برای اعضای تیم اساس تیم در اسکرام بر اساس self-organized بودن اون است و چیزی به نام Task-Assign توسط هر عضوی از تیم یا سازمان کارفرما یا سازمان مجری در اسکرام وجود نداره. واقعاً اگه روحیه و فرهنگ این کار رو ندارید اسکرام رو انتخاب نکنید! کاری که میتونه انجام بشه ایجاد اشتیاق در اعضای تیم برای انتخاب یک Task است. ۵ تاخیر در شروع مجدد یک Sprint اگرچه کنسل شدن یک اسپرینت خیلی نادر است اما این میتونه خیلی وسوسه انگیز باشه که اول صبر کنیم تا همه چی آماده و اوکی بشه بعد اسپرینت رو مجدداً شروع  کنیم. بعد از اینکه اسپرینت به هر دلیلی کنسل شد تیم می بایست اسپرینت رو به سرعت و بدون هیچ تاخیری شروع کنه. ۶ اسکرام مستر در نقش مشارکت کننده در انجام Taskها اسکرام مستر مثل آتش نشان میمونه. بیکار بودنش اشکالی نداره، میتونه فعالیت تیم رو نظاره کنه و منتظر باشه تا مانعی اتفاق بیفته تا وارد شه. اما اگر بخواد چون وقتش خالی است پس در انجام Taskای مشارکت جدی کنه و یا مسئولیتی از اعضای تیم توسعه رو بعهده بگیره این باعث میشه از وظیفه اصلیش که بر طرف کردن موانعی است که بر سر راه تیم ممکنه پیش بیاد و یا هر آنچه که در فعالیت تیم وقفه ایجاد میکنه دور بمونه. ۷ غیبت Product Owner مالک محصول یک عضو تمام وقت تیم اسکرام است و باید در جلسات اسکرام مانند Planning، Review و یا Daily حضور داشته باشه. کلاً باید در طول تایم کاری فعال و در دسترس تیم باشه. نبود اون تیم رو دچار مشکل خواهد کرد. ۸ افراط در هدف گذاری یک اسپرینت تیم تصمیم میگیره که در طول یک اسپرینت چه کارهایی رو میتونه انجام بده و در واقع توانش چقدر است. هیچ کس نمیتونه به تیم فشار بیاره تا حجم کار بیشتری رو انجام بده. در صورت این اتفاق اعضای تیم آزرده خاطر خواهند شد و مطمئناً کیفیت کار پایین میاد. ۹ قهرمان سازی های فردگرایانه اسکرام به ما کمک می کنه تا از افراد تیم های خوبی بسازیم نه تیم هایی از افراد خوب بسازیم (Barry Turner) شخص واحد در اسکرام جایگاهی نداره. اگر محصول با ارزش و موفق است کل تیم نقش داره و اگر شکست خورده باز کل تیم مقصر است. ممکن است یکی از اعضای تیم رو قهرمان موفقیت ها بدونن که این اشتباه است و انگیزه رو از سایرین خواهد گرفت. ۱۰ تیم به تنهایی پروداکت بک لاگ رو سازماندهی میکنه تیم ِتوسعه اطلاع جامعی از نیازهای مشتری و اولویت بندی اونها بر اساس ROI نداره در نتیجه نمیتونه آیتم های پروداکت بک لاگ رو اولویت دهی و سازماندهی کنه. این وظیفه مالک محصول است که این کار رو انجام بده. تنها کاری که تیم میتونه در این قسمت انجام بده مشارکت با PO در اولویت بندی هایی است که از لحاظ تکنیکالی باید جابجا بشن و امکان انجامش از لحاظ فنی نیست. ۱۱ تعیین راه حل توسط Product Owner مالک محصول می بایست از تمامی اعضای تیم در مورد تعیین راه حل برای مشکلاتی که ممکن است در پروداکت بک لاگ پیش بیاد مشورت بگیره و خودش نباید مستقیماً تصمیم بگیره و به باید نظر تیم احترام بذاره. ۱۲ وقفه های اورژانسی این وقفه ها نباید در طول یک اسپرینت اتفاق بیفتن و باعث طولانی شدن اسپرینت بشن. در عوض اگر تا حد زیادی ضروری است می بایست اسپرینت توسط تیم کنسل بشه. بعبارت دیگه عامل وقفه باید در پروداکت بک لاگ قرار بگیره تا در اسپرینت جدید بهش رسیدگی بشه. جهت مشاهده بخش دوم مقاله می توانید به لینک زیر مراجعه نمایید: https://virgool.io/@mhamidreza/%DB%B2%DB%B4-%D8%AA%D9%84%D9%87-%DB%8C-%D8%B1%D8%A7%DB%8C%D8%AC-%D8%AF%D8%B1-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-frzsnf1b1vwn این پست اولین بار در تاریخ 1392/02/04 در وب سایت hamidreza.info انتشار یافته است. حمیدرضا متقیان Hamidreza Motaghian حمیدرضا متقیان Hamidreza Motaghian Wed, 02 May 2018 11:46:10 +0430 https://virgool.io/@mhamidreza/httpshamidrezainfo139605passion-d8a7d8b3d8aad8a7d8b1d8aad8a7d9bedb8c-d988-d8a7d8b4d8aad8a8d8a7d987d8a7d8aa-d8a7d981d8b3d8a7d986d987-ywqeoslnpxft این روزها تقریباً خیلی از بیلبوردهای سطح تهران، تبلیغ وب سایت ها و استارتاپ های حوزه نرم افزار شدند و با توجه به اقدامات و حمایت های نسبتاً خوب دولت و همچنین بخش خصوصی در دو سه سال گذشته، تب و تاب راه اندازی کسب و کارهای نوپا -استارتاپ ها- هم خیلی داغ شدند.ذات این شور و شوق و کلاً فعال بودن این اکوسیستم رو باید به فال نیک گرفت چراکه یکی از زودبازده ترین صنایعی که در زمان کوتاه منجر به اشتغال زایی بالا میشه صنعت IT و نرم افزار است. هم هزینه ایجاد شغل به نسبت سایر صنایع دیگر درش پایین تر است و هم سریعتر به بهره برداری میرسد. در نتیجه هرگونه حمایت اصولی و با برنامه ای که از این قبیل کسب و کارها صورت بگیرد به حل بسیاری از مشکلات نهان و پیدا جامعه کمک می کند. اما سایر جوانب قضیه رو هم باید دید. قضیه به این روی سکه ختم نمیشه. در آن روی سکه ۴ افسانه مهلک وجود داره که ممکن است در بدو تاسیس یا حین رشد گرفتارش بشید که در ادامه بهش می پردازم: ایده پردازی رویایی و بی رقیب بودنجوانان تازه کار فکر می کنند به صرف داشتن یک ایده که تا به حال به فکر هیچ بنی بشری نرسیده، میتونند سریعاً به ثروت برسند. غافل از اینکه "ایده" فقط  ۲۰ درصد موفقیت است و نیازسنجی، تحلیل بازار و شیوه اجرای ایده ۸۰ درصد باقیمانده است. در حال حاضر کمتر ایده ای در ایران میشه پیدا کرد که قبلاً حداقل یکبار اجرا نشده باشد. قبل از شروع، حتماً جستجو کنید و مطمئن باشید کسی زودتر از شما این ایده رو پیاده سازی کرده و شما باید به دنبال اجرای متفاوتش یا نوآوری و ایجاد ارزش جدید باشید. عدم نیازسنجی ایده/عدم شناخت بازار تا اینجا با یونیک نبودن ایده تون کنار اومدین اما مصرانه فکر می کنید در سه ماه اول ۱۰۰۰ نفر مشتری خواهید داشت. اولین و مهمترین هدف استارتاپ ها پاسخگویی به یک نیاز برآورده نشده و یا کاملاً برآورده نشده است که در بازار وجود دارد. ارائه MVP یا کمینه محصول به مشتری و گرفتن فیدبک و همچنین صحبت با مردم عادی در مورد ایده از این افسانه شما رو نجات می دهد. در واقع شما باید تا حدودی مطمئن بشید که ایده شما ارزشی رو به مشتری ارائه میکند که مشتری بابت این ارزش، حاضرِ که به شما پول بدهد. البته استفاده از ابزارهایی مثل بوم مدل کسب و کار هم میتونه تا حدودی به شما کمک کند که البته متداول است ولی تکمیل سنجیده این بوم کار آسانی نیست ولی درک شما رو از کار بالا میبره. در این مرحله بیشتر باید بر روی ارزشی که به مشتری قرار است ارائه کنید تمرکز کنید. عدم اجرای صحیح و اصولی ایده پس از عبور از دو مرحله قبلی، سخت ترین مرحله یعنی اجرای ایده فرا می رسد. برای اجرا نیاز به یک تیم خلاق، متخصص و با پشتکار است که در این مسیر طولانی و ناهموار شما رو کمک کند. اگر بتونید تیمی رو دور هم جمع کنید که تک تک اعضایش از خود شما بهتر باشند احتمال موفقیت شما به مراتب بالاتر خواهد رفت. کار کردن تیم در یک فضایی که قطعیت نداره سخت هست. یک اجرای بد، یک ایده خوب رو تباه میکنه. عدم نیاز به دانش و آگاهیبعد از یه زمانی که کار راه افتاد و جلو رفت این افسانه که من دانای دهر هستم و همه چی رو میدونم دردسر ساز میشه. به عنوان یک اصل کلی از بدو تاسیس استارتاپ تون تا بالاترین سطح رشدش همواره مطالعه کنید و یاد بگیرید. نیاز به دونستن در تمام مراحل رشد یک نیاز جدی هست که باید پاسخ داده بشه. به نظرم این ۴ افسانه متداول ترین اشتباهاتی هستند که اکوسیستم فعلی ایران بهش دچار هست و امیدوارم در ادامه بهش گرفتار نشود. این پست اولین بار در تاریخ 1396/05/26 در وب سایت hamidreza.info انتشار یافته است. حمیدرضا متقیان Hamidreza Motaghian حمیدرضا متقیان Hamidreza Motaghian Sun, 29 Apr 2018 10:48:59 +0430