مدتی هست به این فکر می‌کنم که چرا در طراحی رودمپ نمی‌تونیم از Feature setها و زمان دلیوریشون بگذریم. نوشته زیر حاصل مطالعه و تحقیق من، پیرامون این سوال است.
به نظر میاد نمایش زیرکانه‌ی رودمپ به شرکت‌ها کمک می‌کند از این حقیقت تلخ که نمی‌توانیم بر روی فضای پیچیده کنترل مطلق داشته باشیم، فرار کنند.
رودمپ‌های دارای Feature و زمان‌بندی به سه دلیل برای بسیاری از ما جذابیت دارند:
دیدگاه اول: فقط ایده‌های بیزنسی‌ای که در تصورات ما هستند، قابل اطمینان‌اند
ایده‌های بیرنسی معمولاً بر پایه فرضیات بسیار و هزاران متغیر بنا شده‌اند. اگر با این دیدگاه اولویت‌بندی کنیم، اولویت‌بندی‌مان بر اساس ارزشی که قرار است به مشتری تحویل داده شود، نیست. اما ما عاشق تفکراتمان هستیم و دوست داریم افکارمان تا حد ممکن درست باشند.
خیلی بهتر است که با انجام آزمایش‌های کوچک، دامنه تغییرات را کاهش داده و فرضیات را به چالش بکشیم. و سپس با کمک این اطلاعات، ایده‌های معقولانه‌ای بسازیم که ریشه در واقعیت دارند. اما این کار باعث می‌شود پیش‌بینی زمان‌بندی‌ها و ویژگی‌هایی که می‌توانیم به آن عمل کنیم حتی از قبل هم سخت‌تر شود. چنین کاری به مذاق‌مان چندان خوش نمی‌آید.
دیدگاه دوم: تحویل Featureها به منزله تحویل Valueهاست.
این دیدگاه شایع‌ترین تصور از رودمپ Featureی است. همانطور که یک لطیفه نمی‌تواند به طور حتم باعث خنداندن مردم شود، تحویل Featureها هم لزوماً باعث بهبود زندگی مشتریان نخواهد شد.
فرض کنید کمدین هستید و می‌دانید که باید در نه ماه آینده برنامه جدیدی را اجرا کنید. آیا تمام این نه ماه را به تفکر به لطیفه‌هایتان اختصاص خواهید داد و سپس برنامه را اجرا خواهید کرد؟ مسلماً نه!
کمدین‌ها مدام امتحان و آزمایش می‌کنند تا ببینند لطیفه‌هایشان چه بازخوردی دارد. وقتی مردم به لطیفه‌ای نخندند یعنی آن لطیفه نیاز به تغییر دارد یا باید کلاً قیدش را بزنند. وقتی هم مردم بخندند یعنی لطیفه جذابیت دارد. کمدین‌ها با بازی با داستان‌ها و نحوه تعریف‌شان می‌توانند حتی خنده بلندتری را بر لب حضار بنشانند.
اصل ماجرا این نیست که چه ساخته‌اید بلکه مهم بازخوردیست که دریافت می‌کنید.
برای این کار باید به مشتری خود گوش بدهیم و با توجه به بازخوردی که گرفته‌ایم آن را تغییر دهیم. مدل « بساز و فراموش کن» در این معادله هیچ جایی ندارد و این دقیقاً همان مقصدیست که رودمپ‌های دارای Feature و زمان‌بندی معمولاً به آن منتهی می‌شوند.
دیدگاه سوم: بهبود هماهنگی میان بخش‌های مختلف با کمک رودمپ‌ها به بهترین شکل ممکن صورت می‌گیرد
اکثر فرآیندهای رودمپ‌سازی پاسخی به مشکلات پیرامون مقیاس‌پذیری(scaling problems) است. در پروسه Scale، تیم‌هایمان در هماهنگی با یکدیگر مشکل دارند و فرآیند رودمپ‌سازی ما را مجبور به همکاری می‌کند. رودمپ ابزاریست که برای بهبود همکاری با یکدیگر می‌سازیم.
برقراری تعادل میان دوراندیشی و چاره‌اندیشی بهترین راه برای انجام کارهای پیچیده است. یعنی از طریق برنامه‌ریزی، تحلیل و طراحی بر اساس دانسته‌های قبلی خود پیشروی کنیم و با انعطاف و سرعت عمل به یافته‌هایمان عکس‌العمل نشان دهیم.
ولی اکثر مشکلات پیرامون هماهنگی و تعامل با رودمپ حل نمی‌شود. وقتی به ناتوانی‌ها و ندانسته‌هایتان پی ببرید، رودمپ‌های دارای Feature و زمان‌بندی به جز پیروی از برنامه هیچ خاصیت دیگری نخواهند داشت.
نمی‌توانید بر اساس آنچه هنوز نمی‌دانید هماهنگی و گفتگو کنید.
تنها راه چاره این است که وقتی از مشکل یا اطلاعات جدیدی باخبر می‌شوید بتوانید به سرعت از خود واکنش نشان دهید. اغلب تیم‌های اسکرام در طول مسیر آنقدر انعطاف‌پذیر نیستند که به بقیه هم کمک کنند.
وقتی هر تیم رودمپی جداگانه داشته و مجبور به پاسخگویی باشد وضعیت حتی از این نیز بدتر می‌شود. اینگونه هر تیم راغب می‌شود سایر تیم‌ها را نادیده بگیرد تا بتواند به تعهدات خودش عمل کند. در عمل نیز دقیقاً همین اتفاق روی می‌دهد. خیلی بهتر است که تیم دیگری به جای تیم شما برای بدقولی مجازات شود، حتی اگر این کار به ضرر شرکت باشد.
بیایید خودمان را با رودمپ‌های دارای Feature و زمان‌بندی گول نزنیم
مواردی هم وجود دارند که در آن‌ها داشتن Feature بر روی رودمپ کاری عقلانیست (مانند وقتی که می‌خواهید محصول‌مان را بازسازی کنیم یا قراردادهای قیمت مقطوع با زمان‌بندی و اهداف ثابت یا زمانی که در حوزه‌های غیرپیچیده کار می‌کنیم). اما اگر بخواهیم اکتشاف، یادگیری و آزمایش را در اولویت بگذاریم، رودمپ‌های دارای Feature و زمان‌بندی از همان ابتدای کار ما را در مسیر شکست قرار می‌دهند.
هدف اصلی کار در حوزه‌های پیچیده این است که با دانسته‌هایتان کار کنیم تا به ندانسته‌هایمان پی ببریم. برای آن که در مسیر درست حرکت کنیم باید خودمان را تطبیق دهیم، اصلاح کنیم، جلا دهیم و منعطف باشیم.
وقتی مشکل تنهایی تیم خودتان را حل کردید باید حتی از قبل هم انعطاف‌پذیری بیشتری داشته باشید. پیچیدگی کار با گسترش تیم‌ها به طرزی تصاعدی افزایش می‌یابد.
واکنش پیش‌فرض تیم‌ها در قبال عدم قطعیت بازگشت به برنامه‌ریزی، تحلیل و طراحی بیشتر است.
حتی با وجود اینکه می‌دانیم این رویکرد در تیم‌های تکی با شکست مواجه می‌شود، به نحوی خودمان را گول می‌زنیم که شاید این کار در چند تیم موفقیت‌آمیز باشد.
تحلیل بیش از حد بر اساس دانش ناکافی در مقایسه با واکنش جمعی و سریع تمام تیم‌ها بر اساس دانسته‌ها و آموخته‌ها رویکردی ناکارآمد است.
حالا چه باید کرد؟
مطمئن شویم تیم‌های جداگانه که بر روی یک محصول کار می‌کنند همگی از یک رودمپ کلی وابسته به هدف (رودمپ با rکوچیک) که اولویت‌ها را مشخص می‌کند، پیروی نمایند. بسیاری از شرکت‌ها برای هر تیم یک رودمپ جداگانه دارند. این کار عملاً به این معناست که هیچ کنترلی بر اولویت‌ها ندارند. تیم‌ها با یکدیگر جدل خواهند داشت و بر سر قلمروشان با یکدیگر نزاع خواهند کرد که این کارشان معمولاً به ضرر شرکت و با بی‌اعتنایی به کلیت ماجرا همراه می‌شود.
بیانیه روش توسعه نرم‌افزار چابک لب کلام را به زیبایی تمام بیان می‌کند:
«واکنش به تغییرات به جای پیروی از برنامه»
در حوزه‌های پیچیده تنها تا زمانی می‌توانیم به برنامه‌هایمان (و رودمپ‌ها) اعتماد داشته باشیم که بیانگر واقعیت باشند. یعنی هرگز نمی‌توانیم بی چون و چرا به آن‌ها اعتماد کنیم. بلاخره زمانی می‌رسد که نمی‌توانیم مانع شویم و تفکر اولیه‌مان از واقعیت فاصله می‌گیرد. هر قدر هم صحبت کنیم، طراحی کنیم، تحلیل کنیم یا هماهنگ باشیم، هرگز به صورت تمام و کمال در کنترل نخواهیم بود.
