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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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