چیزهایی که نمی دانیم ولی فکر می کنیم می دانیم

IMAG0221

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

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

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

مشکل اینجاست که ما یادمان می رود، علت ظهور روش های چابک برای این است که “ما نمی دانیم که نمی دانیم” 

 ولی چرا فکر می کنیم که می دانیم؟

این خیلی ساده است، اما قبل از ادامه مطلب این دو تمرین را انجام دهید:

1- یک برگ کاغذ سفید بردارید، بدون اینکه در اینترنت سرچ کنید روی این کاغذ یک دوچرخه بکشید، شکل واقعی یک دوچرخه چگونه است؟ یک دوچرخه که قرار است واقعا راه برود.

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

2- به زیپ کاپشن یا کیف خود نگاه کنید، آن را بالا پایین کنید، متوجه می شوید که یک زیپ چگونه کار می کند؟

این دو تمرین به سادگی نشان می دهد که ما به سادگی با اشیای دوروبر خودمون برخورد داریم و فکر می کنیم که می دانیم آنها چگونه هستند و چگونه کار می کنند، ولی در واقع نمی دانیم. نمی دانیم که نمی دانیم آنها چگونه کار می کنند، اما مدل ذهنی انسان به گونه ای است که تصور می کند که می داند همه چیز دقیقا چگونه است و به این عارضه  Over Confidence effect گفته می شود. یعنی ما بیشتر از واقعیت به دانسته ها و قضاوت های خودمان باور و اعتقاد داریم، و این می شود ریشه تصمیم گیری های بعدی در تمام مراحل زندگی و پروژه.

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

روش های چابک برای همین مسئله هستند که نخست قبول کنیم که “نمی دانیم که نمی دانیم”. با فرض این پروژه را شروع کنیم که تغییرات را باید پذیرا باشیم، اگر تغییری نیاز بود این را به حساب خرفتی مدیر محصول یا مشتری نگذاریم و از کارهای عبث برای تحلیل اولیه خیلی زیاد در ابتدای پروژه دوری کنیم.

چابک و موفق باشید

اگر به تازگی با چابک یا اسکرام آشنا شده اید پیشنهاد می کنم این کتابچه چند صفحه را بخوانید و اگر مطالب بیشتری نیاز داشتید شاید این مطلب اول تا آخر چابک برای شما مفید باشد.

مطالب را هم دوست داشتید می توانید از طریق این لینک عضو فید دنیای چابک شوید تا مطالب جدید برای شما ارسال شود

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

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

پاسخ دهید

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