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

متد چابک موردنظرتان رو الگو قرار دهید، منابع مشابهی را که دارید، بر روی نقشه محکم کنید و درنهایت کم و کسری اگر وجود داشت، آن را جبران کنید.

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

بارها این جملات را از مدیران سازمان‌ها در زمان پذیرش چابکی (Agile Adoption) شنیده‌ایم که «نگاه کن، ما چارت سازمانی پیچیده‌ای داریم، این نقش‌ها برای ما کافی نیست!» یا «خب! تکلیف مدیران محصول ما چه می‌شود؟» یا «این متد برای سازمان‌های کوچک است، از اندازه‌اش معلوم است!!» و بسیاری جملات مشابه دیگر.

مالک محصول

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

هیچ جایی در اسکرام نمی‌بینید که مالک محصول بر مربی اسکرام ازلحاظ جایگاه، برتری داشته باشد یا مربی اسکرام بر گروه توسعه یا برعکس.

یک مالک محصول فارغ از آنکه چه کسی است، باید سه ویژگی اصلی زیر را علاوه بر توانایی‌های دیگر داشته باشد:

• نیازمندی‌های مشتری را بشناسد و بتواند آن‌ها را توضیح دهد: یعنی بتواند بجای مشتری فکر کند و گاهی نیازهای مشتری را به مسیر واقعی و صحیح سوق دهد. علم ارتباطات اهمیت فراوان دارد.
• اختیار اولویت‌بندی نیازمندی‌ها را داشته باشد: یعنی بتواند در یک کلمه نیازمندی یک را از نیازمندی دو تشخیص دهد و مشتری را در خصوص اولویت‌بندی انتخاب‌شده قانع کند. بکلاگ محصولی با اولویت‌های متزلزل آفت گروه‌های توسعه چابک هست. یک آفت جدی!
• جسارت و توانایی تحویل گرفتن و تشخیص نیازمندی‌های تکمیل‌شده را داشته باشد: یعنی مالک ‌محصول چابک باید بتواند نیازمندی که در ابتدا ویژگی‌هایشان را برای گروه توضیح داده است را در روز دمو تحویل بگیرد. مالک محصولی که بگوید، «خب این خیلی خوبه، ولی اجازه دهید من با مشتری در خصوص رنگ زمینه این فرم صحبت کنم!» یا اینکه «این دقیقاً چیزیه که ما می‌خواستیم ولی نمی‌دانم مشتری هم راضی خواهد بود یا نه!»، کمکی به گروه توسعه نمی کند. این‌ها جملاتی هستند که شنیده‌ایم و متأسفانه به‌سرعت یک گروه چابک را از بین برده است.

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

«خب، من نمی‌توانم شما رو قانع کنم، لطف کنید با مشتری تماس بگیرید و از او نظر بخواهید»

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