چگونه ذینفعان را قانع کنیم که تخمین ضمانت نیست

نویسنده: آنیتا هادیزاده – اسکرام مستر شرکت داتین

این نوشته برداشت آزادی از مجموعه سه ویدئوی منتشر شده توسط آقای Mike Cohn است که به چالش‌هایی که تیم‌ها در رابطه با تخمین زدن با استوری پوینت مواجه هستند، می پردازد .

قسمت اول

بخش دوم : با تیمی که با چالش تخمین عالی یا پرفکت دست و پنجه نرم می کند، چه کنیم؟

تخمین عالی یا پرفکت به نظر ایده ی خوبی میرسد تا زمانی که شما به این نتیجه می رسید که در واقع تخمین عالی وجود ندارد و ایده تخمین عالی برای تیم شما بیشتر از سود، ضرر به دنبال دارد. به همین دلیل در این مطلب میخواهیم به این حس که تخمین ها باید عالی باشند غلبه کنیم و نه تنها با تیم، بلکه با ذینفعان هم مکالمه ای در مورد فهم مشترکی از آنچه تخمین واقعا باید باشد داشته باشیم.

مثال هایی از مشکلات تخمین های عالی

شرکتی که سالها با موفقیت به فعالیت می پرداخت و در سال های قبل بدون رقیب پیشرفت کرده بود، اخیرا تکنولوژی باعث شده بود شرکت های کوچک هم به فضای رقابت با آنها وارد شوند و شرکت به سختی برای نگه داشتن سهم بازار خود با چالش‌ها دست و پنجه نرم می کرد و سعی می کرد از خودش در مقابل این رقبای جدید محافظت کند. همچنین مدیری را  مسئول به وجود آوردن خروجی (نتیجه) و رساندن بموقع آن به مشتری، قرار داده بودند. فضای اضطراب بر شرکت حاکم شده بود، راهی که این مدیر برای برآوردن انتظارات شرکت انتخاب کرده بود این بود که تمام افراد تیم را بر آن دارد که تخمین دقیق بدهند و آن تخمین را بعنوان ضمانت در نظر گرفته و آن را در برنامه‌ها و گزارشاتی که با ذینفعان به اشتراک می گذاشت، استفاده می کرد.

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

مشکل دیگر این بود که حتی با وجود تخمین های به اصلاح گشاد، باز هم زمان برای انجام کافی نبود، چرا؟ 

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

مشکل آخراین است که، روش تخمین گشاد، اعتماد را بین مدیران و تیم خدشه دار می‌کند. 

تمام این مشکلات به این دلیل به وجود آمده بود که در خصوص معنی تخمین مشکل ارتباطی بابت درک موضوع رخ داده بود. مدیران انتظار دارند که تخمین ها عالی و دقیق باشند و این تیم ها را دچار مشکل می کند اما از طرفی، گاهی هم مشکل تخمین عالی یا دقیق از خود تیم نشات می گیرد!

مثال: یک مدیر که در شرکتی مربی چابک هم بود و دو مشکل با تخمین داشت: برخی تیم هایی که مربیگری می‌کرد اصلا علاقه ای به تخمین نداشتند، عقیده آنها بر این بود که تخمین زدن کار بیهوده ای است.  آنها بر این عقیده بودند که تا یک کار را شروع نکنند از کجا بدانند چقدر طول می کشد. برخی تیم های دیگر وی تخمین میزدند ولی تا سطوح کسل کننده ای از جزئیات به این کار می پرداختند. مثلا برای  چنین تیمی 15 دقیقه طول می‌کشید تا تصمیم بگیرند یک آیتم 2 امتیازیست یا 1 امتیازی، هر عدم قطعیت و موضوع بازی  در مورد آیتم بک‌لاگ باید قبل از تخمین آیتم پاسخ داده می شد. با اینکه یک دسته تخمین میزدند و یک دسته نه، ولی هر دو گروه بر این باور بودند که تخمین باید دقیق و عالی باشد. یعنی تیمی که تخمین نمی زد دلیل آن این بود که تخمین حتما باید دقیق باشد وگرنه تخمین زدن فایده ای ندارد، اگر قرار است اشتباه باشد چرا خودمان را اذیت کنیم؟ عکس‌العمل گروه دوم به تخمین دقیق و عالی صرف زمان بسیار زیاد روی تخمین زدن بود و خوب نتیجه حدس بزنید ؟ تخمین آنها هم هیچ وقت دقیق نبود!

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

فقط  تخمین و نه ضمانت! 

اگر با چالش مدیرانی که انتظار تخمین دقیق را دارند، یا تیم هایی که می خواهند عالی تخمین بزنند روبرو هستید راه حل ها ی زیر به شما کمک خواهد کرد:

 اولین مورد بابت درک مشترک این است که همه روی نوع تخمین توافق داشته باشند.

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

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

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

یک قدم به عقب بروند، و همه را وارد کنند که یک چیز را تخمین بزنند.

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

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

مثال : سفارش یک پیتزا برای شام 

شما پیتزا سفارش می دهید و در واقع یک زمان مشخص بعنوان تخمین (Most Likely)  به احتمال وقوع زیاد، وجود دارد (تخمینی که اغلب محقق می شود) و چیزهای کمی ممکن است رخ دهد و به سریعتر شدن سفارش شما منجر شود: رستوران شلوغ نباشد، دقیقا در لحظه ای که سفارش می دهید پیتزا آماده کرده باشند، پیک در رستوران آماده باشد و…. ولی لیستی از بی نهایت موارد وجود دارد که می تواند زمان رسیدن پیتزا به دست شما را طولانی تر کند . رستوران گوجه فرنگی تمام کرده باشد، راننده در دسترس نباشد، ترافیک، گم کردن راه و … 

این باعث می شود نمودار شکلی به خود بگیرد  که تخمین (Most Likely)  به احتمال وقوع زیاد به سمت چپ میل کند. یعنی مقدار استوری پوینت کوچکتر از آن،  نسبت به استوری پوینت های بزرگتر از آن کمتر است بدین معنا که احتمال کمی وجود دارد که می تواند کمک کند تا کار زودتر از تخمین به احتمال وقوع زیاد  تمام شوند. تخمین (Medium) متوسط ، تخمین 50 50 تیم است، بدین معنی که  از نظر اندازه، اندازه ی استوری پوینت داده شده به مقداری است  که، کار در واقعیت، نیمی از مواقع زودتر از این تخمین و نیم دیگر مواقع دیرتر از تخمین تمام می شود.

تخمین (Risk Averse ) دور از ریسک ، تخمینی است که برخی اعضای تیم به جای تخمین (Worst Case )  بدترین حالت، می دهند. این نوع از تخمین را افرادی می دهند که  دقیقا بدترین حالت ها  و سناریوهایی که همه چیز در آن بد پیش می رود  را می دانند ولی علاوه بر آن، این موضوع را نیز می دانند که چقدر این سناریوها غیر محتمل هستند اما هنوز می خواهند، محافظه کار باشند و تخمین دور از ریسک می دهند.

حالا فرض کنید تخمین های  دور از ریسک ، 90 در صد مواقع  محقق شوند، بدین معنی که 90 درصد مواقع سناریویی پیش نمی آید که منجر شود ما به آن تخمین نرسیم و کار مقدار بیشتری طول بکشد، در مقایسه با این حالت، تخمین های بدترین حالت (Worst Case)، عموما 99 در صد  سناریوهای ممکن  را پوشش می دهند و در واقع 99 در صد از مواقع اتفاقی رخ نمی دهد که کار بیشتر از تخمین داده شده طول بکشد.

 حال با این شرح، این کار شماست که با تیمتان صحبت کنید که :  چه نوع تخمینی بزنند؟ نوع تخمینی که همه می توانند رویش توافق داشته باشند و جلو بروند؟  پیشنهاد می شود که  تیم یکی از انواع تخمین  (Most likely)  به احتمال وقوع زیاد یا (Medium)   متوسط را انتخاب کنند. 

 تخمین (Most likely)  به احتمال وقوع زیاد:  تخمینی است که تعداد استوری پوینتی را نشان می دهد که تیم فکر می کند اغلب اوقات به وقوع می پیوندد و یا به عبارتی تیم فکر می کند که اغلب اوقات، کار در همین تعداد استوری پوینت تخمینی داده شده، تمام می شود .

تخمین (Medium) متوسط:  تخمینی است که به طور مساوی  احتمال دارد (50 درصد)  که خیلی بالا یا خیلی پایین باشد و یا به عبارتی 50 درصد احتمال دارد کار بیشتر از مقدار استوری پوینت تخمینی داده شده بابت آن طول بکشد و 50 در صد احتمال دارد کمتر طول بکشد.

وقتی تیم یکی از انواع تخمین های  (Most likely)  به احتمال وقوع زیاد  یا (Medium)   متوسط را انتخاب کرد حالا زمان آن است که در این مورد با ذینفعانتان صحبت کنید. 

معمولا ذهنیت بدی در خصوص عدم درک تخمین در مورد روئسا ، مشتریان، ارباب رجوع ها و ذینفعان وجود دارد، با توضیحاتی که دادیم، اینجاست که متوجه می شویم چرا این افراد تصور می کنند که تخمین ها ضمانت هستند، روشن است:  زیرا خود ما  به آنها غیر از این را نگفته ایم!

ذینفعان شاید یک نسخه غیر رسمی از این  نمودار را در ذهنشان دارند و فرض می کنند همه تخمین ها (Risk Averse)  دور از ریسک یا بدترین حالت (Worst Case) هستند و 90 تا 99 درصد از سناریوهای بد را پوشش می دهند. آنچه مسلم است این است که  اکثرشان این موضوع را درک می کنند که تخمین ها ضمانت نیستند و کار ممکن است بیشتر از تخمین طول بکشد ولی شاید فکر می کنند این امکان یک تا ده  درصد رخ می دهد.

واقعیت این است که تخمین های(Medium) متوسط ، 50 درصد این سناریوهای بد را پوشش می دهند و تخمین های  (Most likely)  به احتمال وقوع زیاد  حتی خیلی کمتر، بنابراین وقتی تیم تخمین (Most likely)  به احتمال وقوع زیاد یا(Medium)  متوسط  را انتخاب کرد باید در این مورد با ذینفعانتان صحبت کنید،  تا زمانی که این مکالمه را با ذینفعان تان نداشته باشید، باید انتظار این را داشته باشید که آنها فرض کنند تخمین ها ضمانت هستند و 90 تا 99 درصد سناریوهای محتمل را پوشش داده و محقق می شوند.

اما چگونه این موضوع را برای آنها مطرح کنیم ؟ خیلی ساده ، با یک مثال، از آنها بپرسید: چقدر طول می کشد تا از محل کار به خانه برسند؟

عمدا، از آنها بخواهید که تخمین متوسط  بدهند. تخمینی که در واقعیت، 50 درصد مواقع خیلی کمتر و 50 درصد مواقع خیلی بیشتر از آن طول می کشد. آنها مثلا می گویند 30 دقیقه !  حالا بگویید تخمینی که با 100 درصد اعتماد بتوانند مطمئن باشند که می توانند به آن برسند و دیرتر از آن تخمین نخواهند رسید را بگویند این یعنی اگر 100 شب به سمت خانه حرکت کنند، تمام آن 100 شب رسیدن به خانه، بیشتر از تخمین داده شده طول نخواهد کشید.

اگر آنها در تخمین زدن خوب باشند عددی را به شما می گویند که ضریبی از تخمین متوسط  است مثلا اگر 30 دقیقه تخمین متوسط باشد، آنها ضمانت می کنند که 45 دقیقه ای منزل باشند که این افزایش قطعا عدد کافی ای نیست سعی کنید به این نکته اشاره کنید که همه ی مواردی را که منجر به دیر رسیدنشان می شود را در نظر بگیرند،  که می تواند خرابی راه، زلزله،آتش سوزی, صاعقه ، طوفان و باشد. پس از این شرح، پاسخی که میدهند قطعا نیاز به بحث زیادی ندارد ولی احتمالا خواهند گفت  90 دقیقه، بعد از گرفتن این دو تخمین از ذینفعتان، نمودار بکشید  و تخمین 50 50  را روی نقطه(Medium)  متوسط  قرار دهید و تخمین بالایی که آنها دادند را جایی سمت راست نمودار قرار بدهید، بعد توضیح دهید که تیم شما چه نوع تخمینی می زند و چرا آن را انتخاب نموده است (بین(Medium) متوسط و (Most likely)  به احتمال وقوع زیاد ) به این نکته اشاره کنید که تخمین متوسط  مثل آنچه آنها تخمین زدند 50 درصد مواقع بیشتر و 50 درصد مواقع کمتر طول می کشد. اکثر ذینفعان مدیران، ارباب رجوع‌ها این موضوع را درک می کنند هر چند ممکن است قبلا به این روش فکر نکرده بوده باشند. اکثر اعضای تیمتان هم همین حالت را دارند و ممکن است آنها هم  قبلا به این روش فکر نکرده باشند.  به همین خاطر هم هست که می گوییم اول این مکالمه را با تیم داشته باشید.

 بعد از گرفتن توافق از اعضای تیم در مورد تخمین متوسط  یا به احتمال وقوع  زیاد و آشنا کردن ذینفعانتان به معنی این دو، وقت آن است که قدم دوم را بردارید و سعی کنید به تیمتان کمک کنید  که از شر تخمین عالی (perfect) خلاص شوند و این یعنی تعامل راجع به این موضوع که تخمین ها ضمانت نیستند و مطمئن شوید مدیران این موضوع را درک کرده اند.

اگر این مفاهیم را با کشیدن نمودار به آنها منتقل کردید  و با نشان دادن اینکه چطور تخمین بدترین حالت (Worst Case) اغلب مقدار زیادی از تخمین های (Medium)   متوسط   و (Most likely)  به احتمال وقوع زیاد، بزرگتر است برایشان موضوع را روشن نمودید و بازهم از شما ضمانت یا نوعی از درجه قطعیت بالاتر در مورد تخمین ها خواستند، لازم است تا شما این مسئله را با افزودن یک حاشیه امنیت به تخمین ها رفع کنید.

برای تجسم موضوع، فرض کنید در حال تولید یک محصول با 10 فیچر هستید، آیا برایتان مهم است  که در نسخه‍‌‌ ای که میزنید، 5 فیچر بیشتر از تخمین اشان طول کشیده اند و 5 فیچر کمتر؟ حالا این موضوع چطور:  آیا به این موضوع اهمیت می دهید که نسخه چه زمانی آماده می شود؟ مهم است که زمان نسخه با تخمین هایی که تیم می دهد همخوانی داشته باشد  و تا زمانی که شما در موعد مقرر نسخه می زنید اینکه بعضی فیچر ها بیشتر از تخمین و بعضی کمتر طول کشیده اند اهمیتی ندارد. به عبارت دیگر انحراف از تخمین ها تا زمانی که تاریخ تحویل را تحت تاثیر قرار ندهند اهمیت ندارد، به همین خاطر لازم است تا حاشیه امنیت به تخمین هایی که برنامه ریزی کرده اید اضافه کنید . از جمع زدن ساده ی  10 تخمین فیچر و اعلام به ذینفعانتان  به عنوان تاریخ تحویل پرهیز کنید، به جای این کار، تخمین ها را جمع بزنید و یک حاشیه امنیت به آنها اضافه کنید و آن را بعنوان پلن ارائه کنید.

این موضوع منجر به سومین چیزی می شود که به تیمی که در تله ی  تخمین عالی (perfect) گرفتار شده کمک می کند:

تخمین را دقیقا روی میانگین بگویید:

اعضای تیم اغلب در تخمین زدن  روی تخمین بالا دادن به دلیل مسئله تخمین عالی حساس هستند و  روی میانگین حرکت نمی کنند  زیرا روی میانگی نبودن راحت تر و سریعتر است، برای اینکه بتوانند روی میانگین تخمین دهند، دو مورد نیاز است:

اول:  تخمین تعداد زیادی از کارها :

برای متوسط شدن میزان خطاها در نظر گرفتن این موضوع ضروری است. نمی توان بک لاگی 8 قلمی از محصول را تخمین زد و انتظار داشت که نرخ خطای تخمین ها متوسط باشد. برای این تعداد آیتم کم، بسیار محتمل است که هر کدام بیشتر یا کمتر تخمین زده شوند. بیشتر تیم های چابک در ساختن بک لاگ های بزرگ موفق هستند و تعداد زیادی آیتم برای تخمین دارند. 

دوم : به یک رویکرد تخمین نیاز دارید که تیم را تشویق کند  تا با احتمالی برابر، درست یا بالاتر از واقعیت تخمین بزند

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

 پلنینگ پوکر یکی از این تکنیک هاست. در این روش و روشهای مشابه تیم با سری ای از مقادیر از پیش تعیین شده تخمین می زند. متداول ترین سری تخمین مورد استفاده سری فیبوناچی است. بهتر است مقادیر چنین سری عددی ای را به صورت سطل بصری کنید. هر سطل  می تواند تخمینی را بنابر سایزش نگه دارد. سطل 5 و 8 امتیازی: یعنی تیم آیتم هایی راکه 6 یا 7 امتیاز تخمین می زنند به سطل 8 امتیاز ی می برد و این یعنی تیم تمایل ملایمی به رند به بالا دارد، چیزی که تیم دوست دارد بعنوان 6 تخمین دهد بعنوان 8 تخمین میدهد این رند به بالا که گاها رخ می دهد یک سوگیری خوش بینانه ایجاد می کند که تمایل تیم ها به تخمین به پایین را پوشش میدهد و این یعنی به تیم کمک می کند بین تخمین بالا و پایین تعادل ایجاد کنند. 

روش ذکر شده دارای اهمیت زیادی است به این دلیل که اسکرام مستر و مربی می توانند از این طریق مفهوم را مجددا ساختاردهی کنند:

چه تخمینی روی این آیتم بگذاریم؟ این آیتم به کدام سطل تعلق دارد؟

بدین ترتیب به نرمی ساختاری به وجود می آید که در آن، لازم نیست تیم در تخمین  زدن، عالی (perfect) باشد و همزمان تخمین زدن هم بهبود پیدا می کند. چهارمین چیزی که به تیم کمک می کند تا روی تخمین عالی (perfect) متوقف نشوند این است که:

 به آنها کمک کنیم از مجموعه اعداد درستی برای تخمین استفاده کنند 

 تیم را مجبور به انتخاب از میان دو تخمینی که خیلی به هم نزدیکند نکنیم به اینکه یک تیم چقدر در تخمین زدن خوب است کاری نداریم، ممکن است حتی  بین دو امتیاز 42 و 43 هم انتخابی انجام دهند  ولی چون فقط یک امتیاز اختلاف دارد و بخاطر اینکه اختلاف بسیار ناچیزی است، در چنین حالتی حتی مقایسه 1 و 2 ارزش زمانی بیشتری دارد چون دو برابر هستند  اما در کل به دلیل اینکه تعداد اقلام بک لاگ زیاد است اجازه ندهید چنین بحثهایی خیلی طول بکشد. مطمئن شوید از لیست اعدادی که از هم فاصله خوبی دارند استفاده می کنید به تفاوت درصدی فاصله اعداد توجه کنید :

1 و 2 : 100 درصد ولی 42 و 43: 2 درصد

به همین خاطر است که سری فیبوناچی محبوب شده است زیرا اعداد بالای 3 هر کدام 2/3 بزرگتر از قبلی است  و به همین خاطر بسیاری تیم ها فکر می کنند که این فاصله کافی است. به این ترتیب به مرور زمان شاهد بهبود در تخمین تیم ها خواهیم بود.

درباره اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

1 دیدگاه در “چگونه ذینفعان را قانع کنیم که تخمین ضمانت نیست

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

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