در حالی که کمک به گروهی از افراد برای دستیابی به اهداف مشترک یک هدف کلی رهبری است، به نظر شش چالش مشترک وجود دارد که ذینفعان پیشرو و تیم های توسعه را خاص می کند: به عنوان مسئول محصول، شما معمولاً فاقد قدرت معامله هستید. شما رهبری یک گروه نسبتاً بزرگ و ناهمگن را دارید. شما تأثیر محدودی در انتخاب اعضای گروه دارید. شما به طور فعال در رسیدن به اهداف مشارکت می کنید و در عین حال دیگران را راهنمایی می کنید. شما رهبری استراتژیک و تاکتیکی را ارائه می دهید. و معمولاً با تمرینات چابک کار می کنید.
بدون قدرت معامله
برخلاف یک Line Manager، شما رئیس نیستید. شما تیم توسعه و ذینفعان را مدیریت نمی کنید و افراد معمولاً به شما گزارش نمی دهند. در نتیجه شما هیچ قدرت معامله ای ندارید: نمی توانید به اعضای گروه بگویید چه کاری انجام دهند. شما نمی توانید وظایفی را به آنها اختصاص دهید و شما معمولاً در موقعیتی نیستید که بتوانید پاداش، افزایش دستمزد یا سایر مشوق ها را ارائه دهید. در عین حال به کار آنها متکی هستید. علاوه بر این، برخی از افرادی که شما رهبری می کنید ممکن است از شما مسن تر باشند. آنها ممکن است مدت طولانی تری برای شرکت کار کرده باشند و ممکن است بسیار مفید باشند.
گروه بزرگ و ناهمگن
گروهی که شما رهبری می کنید می تواند بزرگ و ناهمگن باشد. تیم توسعه معمولاً Cross-functional است: اعضا سوابق و مهارتهای متفاوتی از جمله طراحی، توسعه نرمافزار و تست دارند. ذینفعانی را که از واحدهای تجاری مختلف می آیند – به عنوان مثال، بازاریابی، فروش، پشتیبانی و خدمات برای یک محصول تجاری- به ترکیب اضافه کنید و در نهایت با گروه بسیار متنوعی مواجه خواهید شد که به راحتی می تواند شامل 15 نفر باشد. بنابراین درک دیدگاه ها و نیازهای مختلف اعضای گروه و هدایت موثر همه افراد می تواند چالش برانگیز باشد.
تأثیر محدود در انتخاب گروه
در حالی که باید سعی کنید افراد مناسبی را در تیم داشته باشید، همیشه نمیتوانید اعضای تیم و ذینفعان را انتخاب کنید و معمولاً در موقعیتی نیستید که بتوانید افراد را خودتان انتخاب کنید. در عوض، شما اغلب برای اعضای تیم توسعه و انتخاب نمایندگانی از واحدهای تجاری بهعنوان ذینفعان، به Line Manager متکی هستید – مهم نیست چقدر افراد را دوست دارید و چقدر خوب با آنها کنار میآیید. به همین ترتیب، شما معمولاً کنترلی روی مدت زمان همکاری افراد ندارید: در حالی که تشکیل یک گروه پایدار که اعضای آن به طور مداوم با هم کار می کنند مفید است، افراد ممکن است بر اساس تغییر نیازهای تجاری تیم را ترک کنند یا به آن بپیوندند.
نقش دوگانه
در حالی که هدایت افراد به تنهایی می تواند چالش برانگیز باشد، شما همچنین باید فعالانه در رسیدن به اهداف مشترک و دستیابی به موفقیت محصول مشارکت کنید. از این نظر، شما نقش دوگانه ای ایفا می کنید: شما رهبر و مشارکت کننده هستید. اولی شامل حصول اطمینان از همسو بودن جریان های کاری مختلف، مانند طراحی و ساخت محصول، آماده سازی عرضه آن، و پشتیبانی از آن است – به عنوان مثال، با تشویق ذینفعان کلیدی برای شرکت در جلسات Sprint Review. همچنین شامل ارزیابی منظم عملکرد محصول و نظارت بر پیشرفت در راستای نقشه راه محصول است. علاوه بر این، ممکن است مجبور شوید برخی از افراد را راهنمایی کنید و به آنها کمک کنید تا دانش مربوط به محصول را کسب کنند و بتوانند کار بزرگی انجام دهند. گویی این کافی نیست، شما همچنین باید به پیشرفت محصول کمک کنید – به عنوان مثال، با مشاهده و مصاحبه با کاربران، تجزیه و تحلیل بازخورد و دادههای کاربر، تجدید نظر در استراتژی محصول، تطبیق نقشه راه محصول، اولویتبندی Product Backlog، و ایجاد User Story های جدید.
رهبری در سطوح چندگانه
هدایت تیم توسعه و ذینفعان به سمت موفقیت محصول نیازمند رهبری در سه سطح است: چشم انداز، استراتژی و تاکتیک. به عنوان مسئول محصول، شما باید چشم انداز محصول خود را شکل دهید. شما باید تلاش برای ایجاد، اعتبارسنجی، و تکامل یک استراتژی موثر را رهبری کنید. شما باید توسعه یک نقشه راه محصول را هدایت کنید. و باید با تیم توسعه بر روی Product Backlog کار کنید تا آیتم های آن را تعیین و بررسی کنید، مجدداً تغییر دهید و اولویت بندی کنید. این کار تضمین می کند که رهبری و تصمیم گیری، یکی هستند: چشم انداز باید استراتژی را هدایت کند و استراتژی باید تاکتیک ها را هدایت کند. در عین حال، بینشهایی که در سطح تاکتیکی به دست میآیند – به عنوان مثال، با آزمایش نمونههای اولیه یا افزایش محصول با کاربران – باید استراتژی را مشخص کند، که به نوبه خود ممکن است روی چشمانداز تأثیر بگذارد.
رهبری محصول مشترک
محصولات ممکن است به حدی برای یک نفر بزرگ باشند که نتواند در هر سه سطح مالکیت کامل داشته باشد. رویکردی که توسط چارچوب مقیاس بندی SAFe رایج شده است، تقسیم مسئولیت های استراتژیک و تاکتیکی است. این رویکرد منجر به استخدام فردی می شود که تصمیمات استراتژیک محصول را اتخاذ می کند و یک یا چند نفر به دنبال کارهای تاکتیکی و مدیریت بک لاگ محصول هستند. با این حال، این گزینه در تجربه من فقط برای محصولات بالغ و پایداری که بعید است استراتژی آنها تغییر قابل توجهی داشته باشد، توصیه می شود.
فرآیندهای چابک
اکثر محصولات دیجیتال با استفاده از یک چارچوب توسعه چابک مانند Scrum یا Kanban توسعه داده می شوند. یک فرآیند چابک الزاماتی را برای تعامل شما با تیم توسعه و تا حدی ذینفعان ایجاد می کند. به عنوان مثال، یک تیم چابک خود سازماندهی می کند. این شامل حق تعیین حجم کاری مناسب، رد موارد کاری در صورتی که بیش از ظرفیت تیم باشد، و تمرکز فقط روی آنچه برای هدف اسپرینت توافق شده است یا انجام کارها با رعایت (WIP) می باشد. این قوانین باعث افزایش بهره وری و ایجاد یک محیط کاری سالم و پایدار می شود. اما منظور آنها این است که شما نمی توانید کار را به تیم تحمیل کنید یا در کار در طول Sprint مداخله کنید. درعوض، تیم توسعه، کار را از Product Backlog بر میدارد. علاوه بر این، باید در دسترس توسعهدهندگان باشید تا بهطور مشترک بر روی PBI ها کار کنید، در جلساتی مانند Sprint Planning و Sprint Review شرکت کنید، به سؤالات پاسخ دهید و در مورد کارهای انجام شده بازخورد ارائه دهید.
نویسنده: رومن پیچلر
به قلم : امیر دوراندیش