آشنایی با چارچوب اسکواد در مدیریت محصول – قسمت اول

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

برای مشاهده سایر مقالات در زمینه مدیریت محصول و اسکرام، به وب سایت آکادمی محصول به آدرس http://productcollege.ir/ مراجعه کنید.

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

هر اسکوآد حق تصمیم‌گیری در مورد اینکه چه بسازند؟ چگونه طراحی کنند؟ چگونه تقسیم‌کار کنند؟ و غیره را دارد. گرچه نیاز است که تصمیماتشان در راستای مأموریت اسکواد، استراتژی محصول و اهداف کوتاه‌مدت در پروسه‌ی مدیریت محصول باشد.

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

مسئولیت رهبر اسکواد (اسکواد لیدر)، شناسایی مشکلات نیازمند به حل و بیان هدف /چرایی حل این مشکلات است تا بتواند در دامنه هدف اسکواد، مشکلات را در اختیار اعضای تیم قرار دهد. اعضای تیم اسکواد نیز می‌بایست با همکاری تیمی و مشارکت فعالانه بهترین راه‌کار برای حل مشکلات را بیابند.

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

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

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

می‌توان گفت فرهنگ کاری تیمی درون اسکوآدها، بر مشارکت و به اشتراک‌گذاری بنا شده است.

مفاهیم مرتبط با چارچوب اسکوآد در فرآیند مدیریت محصول

در ساختار اسکواد، پایین‌ترین سطح مربوط به تیم اسکواد است که پیرو یک هدف مشترک با هم کار می‌کنند. به طور مثال، در اسپاتیفای، بخش سرچ شامل دو اسکواد است. اسکواد “پلتفرم سرچ” و اسکواد “تجربه کاربری سرچ”.

در اسکوآد “تجربه کاربری سرچ” اعضای تیم مشتکل از نیروی آندروید، نیروی آی.او.اس، فرانت اند دولوپر، پروداکت دیزاینر، مدیر محصول و مربی چابک هستند و مسئولیت توسعه نسخه کلاینت سرچ را برعهده دارند.

به طور مثال در تیم ” تجربه کاربری سرچ”، برای توسعه دهنده آندروید، علاوه بر توسعه فیچرهای جدید، کارهایی از قبیل نگهداشت ورژن‌های قبلی (با کد بیس، مدل برنامه‌نویسی و ابزارهای استفاده شده متفاوت از نسخه جدیدتر)، اجرای A/B تست (با توجه به اعلام مدیر محصول) و غیره از کارهای توسعه دهنده در اسکواد به شمار می‌رود.

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

معمولا تیم‌های اسکوآد از ۱۰ الی ۱۲ نفر تشکیل شده‌اند که معمولاً در حال توسعه فیچر یا نگهداشت فیچرهای توسعه داده شده هستند.

سطح بعد از اسکواد Tribe (ترایب) است. ترایب مجموعه‌ای از چند تا اسکواد است. در واقع معمولا ۵ الی ۶ اسکواد که برای تحقق یک هدف مشترک فعالیت می‌کنند، یک ترایب را تشکیل می‌دهند. به طور مثال ترایب تحت عنوان core experience تمام قابلیت‌های فانکشنال، رابط / تجربه کاربری موجود در اپلیکیشن اسپاتیفای مانند “صفحه اصلی اپ، آلبوم، رادیو، هنرمندان، کتابخانه شما” را در بر می‌گیرد.

جلسات مشترک و تعاملات نزدیک بین اسکوآدها بسیار حائز اهمیت است (به طور مثال اگر از code base همدیگر استفاده می‌کنند یا می خواهند یک A/B تست مشترک اجرا کنند و غیره).

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

در شکل‌های زیر نمایی از ساختار اسکوادها نمایش داده شده است.

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

در ادامه نمایی از محیط دفتر اسپاتیفای در نیویورک نمایش داده شده که نشان می‌دهد حتی در فضاسازی سازمانی نیز اسکوادها، مرزبندی‌های خودشان را دارند و حتی دکورهای فضای کاری هر اسکواد در سازمان با توجه به مفهوم Squad branding می‌تواند از هدف و ماموریت اسکواد الهام گرفته شود.

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

سه نوع متداول اسکوادها عبارتند از:

۱) اسکواد فیچر محور (Feature Squad): اسکوادها در این مدل بر روی یک فیچر یا بخش خاصی از محصول تمرکز می‌کنند.

۲) تیم اپلیکیشن (Client app Squad): بر ساخت و عرضه‌ی آسان محصول بر اساس پلتفرم مورد نظر مانند آندروید، PWA و غیره تمرکز می‌کنند.

۳) تیم زیرساختی (Infrastructure Squad): نظارت بر اسکوادها و تأمین ابزار و موارد مورد نیاز اسکوادهای اول و دوم را بر عهده دارد.

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

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

شکل زیر می‌تواند منظور را بهتر برساند: