https://virgool.io/feed/@Zangeneh من سعید زنگنه، یک تکنوکرات، فعال فاوا و یک نویسنده آماتور هستم fa 2026-04-14 22:19:28 https://files.virgool.io/upload/users/92040/avatar/6X6OzQ.png?height=120&width=120 https://virgool.io/@Zangeneh https://virgool.io/@Zangeneh/%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D9%88-%D9%87%D9%85%D8%B2%D8%A7%D8%AF-%D8%AF%DB%8C%D8%AC%DB%8C%D8%AA%D8%A7%D9%84-hjlnlcsv3jgc یکی از موضوعات جذاب و عمیقی که در هایپ هوش مصنوعی منو به خودش کنکجاو کرده موضوع همزاد دیجیتال یا همون Digital Twin است. جایی که هوش مصنوعی میتونه به شکل فزاینده ای ارزش خلق کنه و از خسارتها جلوگیری کنه.تصور کنید یک نسخه کپی دقیق از "شما"، "ماشین‌تان" یا حتی "کارخانه‌تان" در دنیای کامپیوتر وجود دارد که نفس می‌کشد، رشد می‌کند و پیر می‌شود. این دیگر داستان علمی-تخیلی نیست؛ این واقعیتِ فناوری AI Digital Twin است. همزاد دیجیتال پلی است که شکاف میان دنیای فیزیکی (اتم‌ها) و دنیای مجازی (بیت‌ها) را پر می‌کند.۱. کالبدشکافی مفهوم: همزاد دیجیتال دقیقاً چیست؟در سطح بنیادین، همزاد دیجیتال نمایش مجازی یک شیء، سیستم یا فرآیند فیزیکی است که در طول چرخه عمر خود به‌روز می‌شود. اما تفاوت آن با یک مدل سه‌بعدی معمولی (CAD) چیست؟ «جریان داده».یک مدل سه‌بعدی، استاتیک است (مثل یک عکس یا نقشه 3D)، اما همزاد دیجیتال دینامیک و زنده است (مثل یک فیلم زنده).ارتباط دوطرفه: داده‌ها از طریق حسگرهای اینترنت اشیا (IoT) از جسم فیزیکی به نسخه دیجیتال می‌روند (مانیتورینگ) و بینش‌ها و فرمان‌ها از نسخه دیجیتال به جسم فیزیکی برمی‌گردند (کنترل).حافظه تاریخی: همزاد دیجیتال فقط "حال" را نمی‌بیند؛ بلکه تمام تاریخچه عملکرد آن دستگاه را ذخیره دارد و با استفاده از آن یاد می‌گیرد و دائما مقایسه میکند.۲. نقش حیاتی هوش مصنوعی: مغز متفکریک همزاد دیجیتال بدون هوش مصنوعی، صرفاً یک داشبورد زیباست. هوش مصنوعی به این کالبد دیجیتالی «قدرت تفکر» می‌دهد. نقش AI در سه سطح کلیدی است:تشخیص ناهنجاری (Anomaly Detection): هوش مصنوعی الگوهای نرمال را یاد می‌گیرد و به محض اینکه لرزش یک توربین یا ضربان قلب یک بیمار از حالت نرمال خارج شد (حتی قبل از خرابی)، هشدار می‌دهد. شاید نسخه های خیلی ابتدایی از این را در محصولاتی مانند Apple Watch دیده باشید.پیش‌بینی (Prediction): با استفاده از یادگیری ماشین، همزاد می‌تواند بگوید: «با این روند فشار کاری، قطعه X در ۴۸ ساعت آینده خواهد شکست.» این یعنی گذر از تعمیرات واکنشی به تعمیرات پیش‌بینانه (Predictive Maintenance).شبیه‌سازی سناریو (What-if Analysis): شما می‌توانید سناریوهای خطرناک یا حتی خلاقانه را روی همزاد تست کنید. مثلاً: «اگر دمای کوره را ۵۰۰ درجه بالا ببرم، چه اتفاقی برای ساختار فلز می‌افتد؟» «یا اگر رنگ بسته بندی را تغییر دهید چه تاثیری روی مصرف کننده خواهید گذاشت؟» هوش مصنوعی نتیجه را بدون هیچ ریسک واقعی به شما نشان می‌دهد.۳. انواع همزاد دیجیتال: از پیچ و مهره تا شهرهابرای درک بهتر کاربرد، باید بدانیم همزادها سطوح مختلفی دارند:همزاد قطعه (Component Twin): مدل‌سازی یک بلبرینگ یا سنسور خاص.همزاد دارایی (Asset Twin): مدل‌سازی کل یک دستگاه، مثلاً یک موتور جت یا دستگاه MRI.همزاد سیستم (System Twin): مدل‌سازی یک خط تولید کامل یا یک نیروگاه برق.همزاد فرآیند (Process Twin): مدل‌سازی گردش کار، زنجیره تأمین یا تعاملات انسانی درون یا بیرون یک سازمان.۴. کاربردهای تحول‌آفرین در صنایع مختلفالف) صنعت و تولید (Industry 4.0)در کارخانه‌های هوشمند، مدیران می‌توانند خط تولید را در فضای مجازی بازآرایی کنند تا گلوگاه‌ها (Bottlenecks) را پیدا کنند. شرکت‌هایی مانند زیمنس و جنرال الکتریک از این فناوری برای کاهش زمان توقف (Downtime) تا ۳۰٪ استفاده می‌کنند.ب) پزشکی و سلامت (Bio-Twins)این شاید جذاب‌ترین و ترسناک‌ترین کاربرد باشد. پزشکان می‌توانند یک «همزاد دیجیتال از قلب بیمار» بسازند. قبل از انجام یک عمل جراحی پیچیده، جراح روی نسخه دیجیتال تمرین می‌کند تا بهترین روش برش را پیدا کند. همچنین می‌توان واکنش بدن بیمار به داروهای شیمی‌درمانی را ابتدا روی همزاد او تست کرد تا عوارض جانبی به حداقل برسد.ج) شهرسازی و محیط زیستشهرهایی مثل سنگاپور و شانگهای دارای همزاد دیجیتال کامل هستند. مدیران شهری می‌توانند تأثیر ساخت یک برج جدید بر جریان باد، ترافیک و حتی سایه‌اندازی روی ساختمان‌های مجاور را قبل از گذاشتن اولین آجر بررسی کنند.د) بازاریابی و فروشتعامل مشتریان در قبال تغییرات یا کمپین جدید چطور خواهد بود؟ از آنجایی که هوش مصنوعی با دیتاهای فراوانی تولید شده با ضریب خطای کمی میتواند رفتار مصرف کننده در قبال تغییرات را پیش بینی کند۵. معماری ساخت: چگونه یک همزاد متولد می‌شود؟ساخت یک Digital Twin یک پروژه چندلایه است:لایه فیزیکی (Sensing): نصب هزاران سنسور IoT برای اندازه‌گیری دما، رطوبت، لرزش، موقعیت مکانی و غیره.لایه اتصال (Connectivity): انتقال انبوه داده‌ها با سرعت بالا و تأخیر کم (معمولاً با کمک 5G و محاسبات لبه‌ای یا Edge Computing).لایه داده و پردازش (Cloud & Data Lake): ذخیره‌سازی و تمیز کردن داده‌های خام.لایه مدل‌سازی و تحلیل (AI Core): جایی که الگوریتم‌های هوش مصنوعی روی داده‌ها سوار می‌شوند و مدل فیزیکی را شبیه‌سازی می‌کنند.لایه تعامل (Visualization): رابط کاربری که انسان با آن کار می‌کند (مانیتور، عینک VR، یا داشبورد).۶. نحوه تعامل نوین: گفتگو با ماشین‌هاتا پیش از این، تعامل با همزادها نیازمند متخصصان داده بود. هرچند در گذشته نزدیک هم با توجه به محدودیت پردازش حجم عظیم اطلاعات کاربردها خیلی خاص بودند. اما اکنون با ظهور قدرت پردازشی بالای GPU ها ، هوش مصنوعی مولد (Generative AI) و مدل‌های زبانی بزرگ(LLMs)، تعامل دگرگون شده است.رابط‌های مکالمه‌ای: مهندس می‌تواند به زبان طبیعی تایپ کند یا بگوید: "وضعیت سلامت پمپ شماره ۳ چطور است و چه زمانی نیاز به سرویس دارد؟" و سیستم با تحلیل داده‌های پیچیده، پاسخی ساده و متنی می‌دهد.واقعیت گسترده (XR): تکنسین با زدن عینک واقعیت افزوده (AR)، وقتی به یک دستگاه نگاه می‌کند، همزاد دیجیتال آن را به صورت هولوگرام روی دستگاه واقعی می‌بیند که دمای داخلی و قطعات معیوب را با رنگ قرمز نشان می‌دهد ( مانند دید اشعه ایکس ولی بر پایه داده های واقعی و لایه به لایه).جمع‌بندیهمزاد دیجیتال مبتنی بر هوش مصنوعی، فقط یک ابزار نیست؛ بلکه یک تغییر پارادایم در نحوه مدیریت جهان فیزیکی است. این فناوری به ما اجازه می‌دهد تا «اشتباهات را ارزان کنیم»؛ یعنی خطاها را در دنیای دیجیتال تجربه کنیم تا در دنیای واقعی به کمال برسیم.فرصتی بینظیر هم در اختیار متخصصان برای اجرا عملیات AI Transmission در سازمانهای سنتی ایجاد میکند درواقع یک فرصت جدید برای آوردن هوش مصنوعی به صنایعی که تا همین چند روز پیش به معنای واقعی سنتی رفتار میکردند و حالا هوش مصنوعی در آنها یک کاربرد خیلی موثر خواهد داشت. سعید زنگنه سعید زنگنه Tue, 23 Dec 2025 15:29:00 +0330 https://virgool.io/@Zangeneh/%D8%AF%D9%84%D8%A7%DB%8C%D9%84-%D8%B4%DA%A9%D8%B3%D8%AA-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%AF%D8%B1-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-%D8%B9%D8%AF%D9%85-%D9%82%D8%B7%D8%B9%DB%8C%D8%AA-leqpjo1fzind اگر قسمت اول دلایل شکست اسکرام در ایران را نخوانده‌اید حتماً به شما پیشنهاد می‌کنم از آنجا شروع کنید. دوباره هم تأکید می‌کنم این مقاله قرار نیست اصول اجایل-اسکرام را بازتعریف کند بلکه فقط به مواردی که کمتر به آنها توجه شده خواهد پرداخت.در قسمقبلی مقاله به یکی از دلایل شکست اجایل-اسکرام با موضوع استراتژی یا چرایی استفاده از آن پرداختیم. در این قسمت از مقاله نیز به موضوع عدم قطعیت می‌پردازیم که بخش مهمی از روح اجایل و اسکرام است البته حتماً از نگاهی که تابه‌حال به آن کمتر نگاه کرده‌ایم.عدم قطعیت (Uncertainty)در تعاریف کلاسیک و عمومی اجایل عدم قطعیت را این‌گونه شرح می‌دهند: ازآنجایی‌که معمولاً تعریف اولیه از موضوع با نتیجه دلخواه متفاوت است پس ما در فضای عدم قطعیت به سر می‌بریم. عمومی‌ترین مثال این است که مشتری خودش به‌درستی نمی‌داند چه می‌خواهد! یا چیزی در ذهن دارد را به‌درستی بیان نمی‌کند یا به‌درستی به تیم تولید و توسعه منتقل نمی‌شود و معمولاً نتیجه با چیزی که مشتری یا ذی‌نفعان انتظار دارد متفاوت است پس ما با وجود این عدم قطعیت باید شیوه‌ای را اتخاذ کنیم که این مشکل را برطرف کرده یا به حداقل برسانیم. این راهکار هم چیزی نیست جز اجایل!عدم قطعیت و اجایلاساساً اشتباه نگفته‌ایم که اجایل زاده مشکل عدم قطعیت در پروژه‌ها بوده است. هرچقدر پروژه‌های بشر پیچیده‌تر و بزرگ‌تر شد و در مسیر انجام پروژه و کسب نتیجه با مشکل روبرو شد با مسئله عدم قطعیت به‌عنوان ریشه مشکلات برخورد کرد. مدیران پروژه و سازمان‌های مدیریتی به دنبال راه حلی برای حل این مشکل گشتند که شامل مدل چابک یا همان اجایل بود.در این مدل که بر مبنای روش تکمیل شونده (Incremental) و یا تکرارشونده (Iterative) و البته نه محدود به اینها شکل گرفت تمرکز در مفهوم سطح بالا به درک درست نیاز مشتری، چرخه بازخورد (Feedback) و تبدیل آن به محصول نهایی بود.موانع فنی (Technical Obstacles)احتمالاً از اکثر اسکرام مسترها بپرسید می‌گویند ما در چرخه‌های اسپرینت (Sprint) خروجی ممکن را در اختیار مشتری یا مالک محصول قرار می‌دهیم تا چرخه بازخورد و اصلاح را در دوره‌های بعدی اجرا کنیم و این را راه‌حل عدم قطعیت می‌دانیم. اما… مشکل همین جاست! برخی از این مسائل باید قبل از شروع اسپرینت حل شود! عجیب است؟ پس به مثالی که در ادامه می‌زنم توجه کنید.فکر کنید در ضلع غربی زمینی می‌خواهیم دیوار بکشیم. خشت‌های دیوار در ضلع شرقی دپو شده است. اسپرینتی برنامه‌ریزی می‌کنیم که در طول یک هفته آجرها و مصالح را به محل ساخت دیوار منتقل کنیم (از ضلع شرقی به غربی) تا در اسپرینت بعدی شروع به ساختن دیوار کنیم و پروسه ساخت دیوار منتظر متریال نماند. می‌نشینیم و برنامه‌ریزی اسپرینت را انجام می‌دهیم. یک فرقون برای جابه‌جایی راحت‌تر مصالح تدارک می‌بینیم و این کار را به ۲ نفر می‌سپاریم.در جلسه روزانه (Daily Meeting) فردا میاییم و وضعیت را بررسی می‌کنیم نفرات به ما می‌گویند در وسط زمین موانعی مانند جوب آب و تپه‌ای وجود دارد که اگر بخواهند آن را دور بزنند کار در پایان اسپرینت تمام نمی‌شد. ما به فکر چاره می‌افتیم که ماشینی برای حل این مشکل تدارک ببینیم اما متأسفانه در برنامه‌ریزی همین اسپرینت برای ماشین‌های کارگاه کار دیگری را تعیین کرده‌ایم و نیروی انسانی ما در اسپرینت بعدی منتظر آماده بودن آجر و مصالح است و اگر نرسد همه چیز به هم می‌خورد.اگر مدیر خوش‌شانسی باشیم راه حلی (Workaround) مانند اجاره ماشینی از خارج از کارگاه برای این مشکل پیدا می‌کنیم و اگر خوش‌شانس نباشیم تمام برنامه‌ریزی‌های منظم و دقیقی که انجام داده‌ایم تحت‌تأثیر این موضوع پیش‌بینی‌نشده که خودش نوعی از عدم قطعیت است دست خوش تغییر می‌شود و زمان را از دست می‌دهیم.اگر با خودمان صادق باشیم عدم قطعیت بالا تقریباً ربطی با چرخه بازخورد ندارد. عملاً عدم پیش‌بینی و نظاره (Observation) درست باعث این مشکل شده است. در پروژه‌های پیچیده این مشکلات با عنوان موانع فنی (Technical Obstacles) پیش میایند که حاصل همان طرح‌ریزی سطحی و یا عدم نظاره درست است.طرح‌ریزی عمیقحتماً شما هم مثل من این افسانه را شنیده‌اید که فرنگی‌ها برای انجام کاری یک سال مطالعه و برنامه‌ریزی می‌کنند و در چند هفته یا ماه اجرا! چقدر این افسانه حقیقت داشته باشد یا نه ولی راه‌حل همین است. بخصوص وقتی پروژه‌های از جنس تحقیق و توسعه باشند یعنی باید قبل از اجرا راهکاری کشف، آزمایش و اگر مؤثر بود وارد چرخه توسعه بشود نه اینکه وسط پروژه برنامه‌نویس به شما بگوید این راهی که فکر می‌کردیم جواب بده، جواب نمی‌دهد!طرح‌ریزی عمیق نیازمند افرادی مسلط به دامنه (Domain Expert)کار است. می‌بایست قبل از ورود به هر چرخه اسپرینت توسعه، تحقیق و آزمایش لازم را انجام داده باشند. شاید درست به نظر برسد که باید در اسپرینت‌های قبل اسپرینتی برای تحقیق و آزمایش برگزار و نتایج آن به اسپرینت بعدی موکول شود. اما راستش را بخواهید به نظرم اسکرام فضای مناسبی (کافی) برای تحقیق و آزمایش ندارد چه‌بسا موضوع تحقیق و آزمایش حتی پیچیده‌تر از فضای عدم قطعیت است و در فضای نادانسته زیست می‌کند. تا جایی که اداره تحقیقات انستیتو تکنولوژی ماساچوست (MIT) کتابی با نام "مدیریت بر مدیریت‌ناپذیر – مدیریت سازمان‌های تحقیقاتی" نوشته آر. کی. جین و اچ. سی. تریاندیس در این زمینه منتشر کرده است. مدیریت بر مدیریت‌ناپذیر! (کتاب دیگری نیز با همین نام منتشر شده "مدیریت بر مدیریت‌ناپذیر - قوانین، ابزارها و بینش برای مدیریت افراد و تیم‌های نرم‌افزار اثر میکی مانتل و ران لیچتیکه خواندن آن هم خالی‌ازلطف نیست!)هرچند بر این باورم تحقیق و آزمایش به‌خودی‌خود موضوع پیچیده است (به‌مراتب پیچیده‌تر از پیداکردن پستی‌وبلندی‌های زمینی که در مثال گفتیم) اما شما و تیمتان درخور پیچیدگی و اهمیت پروژه‌تان باید به راه‌حل این موضوع فکر کنید. افرادی مسلط به دامنه این مسئولیت را قبول و بالاخره به روشی متناسب با تیم و ابعاد پروژه در قالب اسپرینت‌های قبلی یا هر شیوه دیگری به نتیجه برسانند.هدف از اسپرینتبرای اطمینان از حدود 10 اسکرام مستر پرسیدم هدف از اسپرینت چیست؟ اکثر قریب به‌اتفاق گفتند که نتایج ملموس را بتوان در اختیار مشتری قرار داد. اتفاقاً منابع اسکرام هم همی را بیان می‌کنند اما به نظرم این کفایت نمی‌کند! اسپرینت در چرخه اجایل-اسکرام نقش بزرگی را بازی می‌کند و آن‌قدر مؤلفه‌هایی دارد که فقط همین دلیل کفایت نمی‌کند و اساساً به نظر من شما می‌توانستی خارج از چرخه اجایل حتی در برنامه‌ریزی و مدیریت پروژه آبشاری به نحوی برنامه‌ریزی انجام دهید که نتیجه هرکدام از خروجی‌ها را ببری به مشتری نشان بدهی و فیدبک بگیری پس قطعاً اجایل-اسکرام هدف مهم‌تری را از اسپرینت انتظار دارد و از آن مهم‌تر معتقدم هیچ آدم عاقلی نمی‌ایستد در پایان اسپرینت حتی اگرچند روز باشد صبر کند تا متوجه شود اشتباه می‌کند! پس من تعریف جدیدی از اسپرینت را برای خودم به وجود آوردم. (ادعایی ندارم این تعریف از آن من باشد چرا که آن‌قدر به نظرم بدیهی است حتماً کسانی قبل از من به آن فکر کرده‌اند):من معتقدم اسپرینت تنها بخشی از پروژه است که ما در آن باید آگاهی کامل داشته باشیم و فضای بزرگ عدم قطعیت پروژه را به فضای قطعیت در بازه‌های کوچک تبدیل کنیم. حالا اگر اشتباه هم کردیم در دوره‌های بعدی از آن درس‌آموخته در آغاز اسپرینت جدید استفاده کنیم.این قطعیت می‌تواند شامل موارد ذیل باشد (صدالبته نه محدوده به اینها):· بدانیم مشتری از خروجی کوچک اسپرینت چه انتظاری دارد· پیاده‌سازی این خروجی چه پیچیدگی و موانع فنی دارد· ریسک‌های محتمل و راهکارهای مربوط به ریسک‌ها از قبل مشخص باشد.جمع‌بندی قسمت دوم – عدم قطعیتعلاوه بر هر حالتی از عدم قطعیت که در اجایل-اسکرام به آن می‌پردازیم توجه به موانع فنی به همان مقدار مهم است. بارها دیده‌ام که اتفاقاً هم مشتری می‌داند چه می‌خواهد هم به‌درستی بیان کرده است و هم به‌درستی منتقل شده است ولی موانع فنی از جنس مفروضات غلط یا پیچیدگی پیش‌بینی‌نشده موجب تأخیر در تحویل نتایج و آزار تیم و ذی‌نفعان می‌شود.موضوع مهم توجه به این موانع پیش از شروع هر چرخه توسعه با استفاده از هر روشی متناسب با ابعاد، پیچیدگی و یا اهمیت پروژه شما است. هیچ راهکار قطعی هم برای آن وجود ندارد اما عدم توجه به آن حتماً موجب اشکالات بزرگ‌تری خواهد شد. سعید زنگنه سعید زنگنه Fri, 05 Aug 2022 17:59:13 +0430 https://virgool.io/@Zangeneh/%DA%86%D8%B1%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%AF%D8%B1-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86-%D9%85%D8%AF%D8%A7%D9%85-%D8%B4%DA%A9%D8%B3%D8%AA-%D9%85%DB%8C%D8%AE%D9%88%D8%B1%D8%AF-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-%D8%A7%D8%B3%D8%AA%D8%B1%D8%A7%D8%AA%DA%98%DB%8C-wnaj5zztosef امیدوارم شرایطی را تجربه کرده باشید که با تیتر این مقاله مخالف باشید و اساساً متدولوژی چابک (Agile) و هرکدام از قالب‌های کاری (Framework) که از آن استفاده می‌کنید برای شما نتایج مطلوبی در پروژه یا محصولتان و از همه مهم‌تر تیم به جا گذاشته باشد.اما تقریباً در ۱۲ سال گذشته که با مدل توسعه چابک و به‌خصوص فریم‌ورک پرطرف‌دار اسکرام که آشنا شدم بارها شاهد تعارض (Conflict) در پروژه بوده‌ام. انگار همیشه یک سمت یا چند سمت رضایت کافی را نداشته. از همین رو تصمیم گرفتم برداشت خودم از شرایط و دلایل مشکلات را بیان کنم.بیایید امیدوار باشید هرچه من و شما از اجایل و اسکرام خوانده‌ایم درست بوده است و اینجا در مورد اصول (Principles) نمی‌خواهیم بحث کنیم بلکه قصد من این است توجه شما را به نکاتی که فکر می‌کنم بیشتر مغفول مانده است جلب کنم.ازآنجایی‌که تعداد این نکات کم نیست این نوشته در قالب چند قسمت دنبال خواهم کرد.استراتژییکی از نکاتی که به نظرم در مورد اجایل از آن غافل شده‌ایم استراتژی یا بهتر بگویم چرایی استفاده از این متدولوژی و فریم‌ورک‌های آن است. بگذارید با خاطره کوتاهی شروع کنم.اولین باری که همان حدود ۱۲ سال پیش وقتی تازه از فرنگ برگشته بودم خدمت یک مدیرعامل که درحال‌توسعه محصولی نرم‌افزاری (آنلاین) بود عرض کردم. آقاجان در دنیا تیم‌های توسعه اجایل-اسکرام کار می‌کنند.مدیرعامل پرسید: اجایل چیه؟گفتم: متدولوژی چابک‌سازیگل از گل آقای مدیرعامل شکفت که ای آقا من بارها گفته‌ام ما باید چابک باشیم و از لختی بگذریم و کارها را سریع‌تر جمع‌وجور کنیم این برنامه‌نویس‌ها و مدیر فنی حرف منو نمی‌فهمد همه‌اش کارها رو کش میدن. خدا رو شکر که شما آمدی شدی گواه خواسته من که اینها باید سریع‌تر و چابک‌تر کار کنند و محصول را تحویل دهند ...فارغ از اینکه این آقای مدیر برداشت خودش از یک کلمه را سریع تعمیم داد به خواسته‌هایش که درست یا غلط بود وقتی عرض کردم خوب ما باید ۳ یا ۴ جایگاه شغلی اضافه کنیم و کلی جلسه بگذاریم و صحبت کنیم، گفت ای آقا این که شد همان بروکراسی ... شما هم دنبال حرف‌زدنید بنشینید شبانه‌روز کار کنید ... اسکرام مستر چیه؟ مالک محصول چیه ما اگر بچه‌ها درست کار کنند نیرو اضافه هم داریم ...دیدم این نشد که بشه، رفتم پیش تیم توسعه و مدیر فنی و از ایشان خواستم در این مورد اجایل-اسکرام صحبت کنیم. آقای مدیر فنی هم رفت روی منبر که بله این درست است، اگر مالک محصول و اسکرام مستر داشتیم این آقای مدیرعامل همین‌جوری وسط روز یک تسک جدید روی خروار تسک‌های ما نمیریزه، یک چیزی نمیگه بعد موقع تحویل بگه نه من اینو نمی‌خواستم ...از قصه بگذریم.امروز بعد از بیش از یک دهه درگیری با موضع مدیریت چابک اگر از من بپرسی حق با کدام سمت بود به شما می‌گویم هر دو سمت. مدیریت چابک آمده که نتیجه مناسب با کمترین هزینه ممکن به نتیجه برسد اما چه شده که تقریباً در اکثر جاهایی که درگیر این موضوع بودم هنوز هر 2 سمت از شرایط ناراضی‌اند؟همان‌طور که در بالا گفتم یکی از اشکالات اساسی در استراتژی است یا اصلاً ساده‌تر بگویم "چرایی؟" برای اینکه بگویم این چرایی از نظر من چیست ابتدا لازم است به شما بگویم چه نیست!اجایل-اسکرام روشی برای تند تند انجام‌دادن کارها نیست!اجایل-اسکرام روشی برای کمتر کارکردن و بیشتر نتیجه گرفتن نیست!اجایل-اسکرام روشی برای انجام‌دادن کاری با زحمت کمتر نیست!اجایل-اسکرام روشی برای پایین آوردن هزینه‌ها نیست!اجایل-اسکرام روشی برای موفقیت قطعی پروژه‌ها نیست!اجایل-اسکرام روشی برای جلوگیری از کار نکردن و تنبلی عضوی یا اعضایی از تیم نیست!اجایل اسکرام روشی برای جلوگیری از اشتباه کردن نیست!اجایل-اسکرام استراتژیِ Time to Market استابتدا Time to Market  که به اختصار TTM هم گفته می‌شود را تعریف کنیم که به صورت بنیادین دو تا تعریف معمولا ارائه میشود:مدت زمان بین ایده ای که فاز اجراییش شروع شده تا زمانی که وارد بازار می شود.مدت زمان بین ایده ای که فاز اجراییش شروع شده تا زمانی که اولین محصول خودش را میفروشد.البته حتماً اینکه بگوییم ماموریت چرایی اجایل-اسکرام صرفا و قطعی Time to Market باشد نیست. اما به نظر من روح اجایل - تنظیم زمان واردشدن به بازار- است. اینکه شما در چه زمانی بتوانی محصول را وارد بازار یا پروژه‌ات را فارغ از ضرب‌الاجل‌های قراردادی تحویل بدهی.بگذارید موضوع را با این سه حالت توضیح بدهم:ورود محصولی ناقص، ناکارآمد و ناپایدار در زمان بسیار کوتاهی حتماً منجر به شکست می‌شود.ورود محصول کامل و آماده هم در زمان طولانی و دیرتر از زمان مناسب به بازار هم منجر به ازدست‌رفتن بازار و شکست می‌شود.ورود محصول مناسب در زمان مناسب است که می‌تواند فاکتور قابل‌توجهی (نه قطعی) در موفقیت محصول باشد. (این مثال حتی در پروژه‌های سفارش مشتری هم که ربطی به بازار ندارد صادق است. شما کمی دیرتر محصول مناسبی را تحویل دهید قابل‌قبول است اما خیلی دیرتر خیر!)مثالی که ممکن است به ذهن شما بیاید برای نقض مورد فوق محصولاتی است که دیرتر از رقبا به بازار آمده‌اند و جای رقیب را گرفته‌اند. پس می‌توان نتیجه گرفت من دیرتر از همه می‌آیم ولی با یک محصول خیلی‌خیلی عالی؟! ۲ اشکال اساسی دارد:شما فاکتورهای داخلی مانند خسته شدن یا پشیمانی سرمایه‌گذار، ریزش نیرو و ... را در طولانی شدن مدت نادیده می‌گیرید و اساساً مسئله ما زمان به معنای موقعیت تقویمی نیست بلکه بیشتر از جنس مدت (Duration) است.در ثانی شما حتماً در مورد تله کمال‌گرایی (Perfectionism) و اثرات مخرب آن آگاهید که اساساً منجر به عدم تولید محصول کارآمدی می‌شود که اتفاقاً در اواسط عمر توسعه به‌درستی کار می‌کرده است. پس طولانی شدن کارها به امید محصولی عالی خودش ممکن است موجب تخریب محصول شود.جمع بندی قسمت اول - استراتژیابتدا گوشزد می‌کنم این یکی از عوامل مهمی است که به نظر من به آن درست توجه و پرداخته نشده است و حتماً عوامل دیگری هم وجود دارد. اما باید بپذیریم ما اغلب باهدف ایجاد ارزش و ثروت درحال‌توسعه محصول و یا انجام پروژه‌ای هستیم و اگر Time to Marketیا زمان مناسب ورود به بازار را نادیده بگیریم احتمال بسیار، بسیار زیاد محکوم به شکست هستیم.هرچند باید به این نکته توجه داشت که Time to Market در کنار اینکه ممکن است که تاریخ تقویمی باشد می‌تواند از جنس مدت‌زمان هم بوده و در صورت سپری شدن آن ذی‌نفعان محصول را خسته، پشیمان یا مجبور به مداخله غیرسازنده کند که اصول با اصول اجایل متناقض و موجب بی‌نظمی بیشتر و بیشتر شود.اگر این موضوع به‌درستی روشن و در سطح تیم و نفرات پذیرفته شود اینجاست که بخش عمده‌ای از انتظارات کارفرما، سهام‌دار یا سرمایه‌گذار تأمین و او با خیال راحت‌تری اصول اجایل را می‌پذیرد. سعید زنگنه سعید زنگنه Tue, 02 Aug 2022 00:33:07 +0430