مدیریت محصول یعنی ایستادن در نقطه‌ای که همه تیم‌ها به شما نگاه میکنند؛ بازاریابی، فروش، ذینفعان، کاربران و البته مهم‌ترین شریک شما: تیم توسعه.
به‌عنوان یک پروداکت منیجر، ارتباط با دولوپر مهم‌ترین کار روزمره شماست. شما ممکن است استراتژی بچینید، بک لاگ طراحی کنید و بهترین پرسونای دنیا را داشته باشید، اما اگر نتوانید با Dev Team خود همکاری مؤثری داشته باشید، همه این‌ها روی کاغذ می‌ماند.
واقعیت این است که دولوپرها مغز فنی محصول شما هستند؛ کسانی که ایدههای شما را به چیزهای واقعی تبدیل میکنند. اما آنها دنیای خودشان را دارند؛ پر از کد، معماری و محدودیت‌های فنی. اگر نتوانید زبان مشترکی پیدا کنید، هر اسپرینت می‌تواند به کابوسی از دوبارهکاری، تأخیر و ناامیدی تبدیل شود.
خبر خوب این است که این مهارت یادگرفتنی است! در این مقاله با هم مهم‌ترین اصول و ترفندهایی که کمک میکند ارتباط مدیر محصول و توسعهدهنده را مثل یک حرفه‌ای انجام دهید مرور می‌کنیم، اینکه چگونه اعتمادشان را به دست بیاورید و در نهایت محصولی بسازید که همه به آن افتخار کنند.
-
اهل جزئیات کامل و دقیق باشید
دولوپرها عاشق جزئیات هستند، واقعاً همین‌طور است! هرچه اطلاعات بیشتری داشته باشند، ابهام‌ها و نگرانیهایشان کمتر میشود و راحت‌تر می‌توانند خواسته‌های شما را به یک کد شیک و تمیز تبدیل کنند.
معمولاً توسعه‌دهنده‌ها افراد باهوشی هستند، اما نمی‌توانند خودشان را جای کاربر بگذارند یا همه مسائل بیزینسی را درک کنند. چیزی که آنها می‌خواهند، یک چالش یا نیازمندی واضح است که بتوانند آن را به یک الگوریتم بهینه در زبان‌های مختلف برنامهنویسی تبدیل کنند.
پس در ارتباط میان مدیر محصول و توسعهدهنده، شما باید سعی کنید تا جای ممکن همه جزئیات را پوشش دهید تا هم وقت تیم توسعه گرفته نشود، هم برایشان شفاف باشد که دقیقاً چه چیزی باید بسازند.
فکر می‌کنم شما هم با تجربه شرکت در جلسات متعدد پر از سؤال و سناریوهای مختلف، این نظر را تایید می‌کنید که تابه‌حال هیچ دولوپری نیامده و بگوید «خیلی اطلاعات دادی، اصلاً لازم نبود!» و بعید می‌دانم چنین روزی بیاید!
شما به‌عنوان مدیر محصول معمولاً مسیر موفقیت یا Success Flow رو خوب تعریف می‌کنید، اما دولوپرها معمولاً روی این چهار مورد کلی سؤال دارند:
-
بینالمللیسازی / Internationalization
چطور این فیچر در زبان‌های مختلف، منطقه‌های زمانی یا قابلیت‌های بین‌المللی کار میکند؟
-
حالتهای خطا / Error States
سؤالاتی مثل:
-
اگر API خطا داد چه؟ چه پیامی باید به کاربر نشان دهیم؟
-
اگر سرویس داون شد چه؟
-
اگر کاربر دسترسی لازم را نداشت چه؟
-
ترنزیشن‌ها / Transitions
مثلاً وقتی کاربر یک فرایند را کامل میکند، از یک صفحه به صفحه بعدی میرود، یا با جریان‌های امنیتی مثل فراموشی رمز عبور، راه‌اندازی احراز هویت دومرحله‌ای سروکار داریم.
-
حالتهای خاص یا مرزی / Corner Cases
مثل کمترین و بیشترین مقادیر، لیست‌های خالی، حالتهای پیش‌فرض، ترکیب‌های غیرمعمول دسترسی، سناریوهای استثنایی و...
پس باید بتوانید این موارد را با آنها صحبت کنید و نقطه‌نظراتشان را بشنوید و در انتها برای آنها شفاف کنید که چه باید بکنند، نگران چه چیز باشند و چه چیز را اولویت قرار ندهند تا از هدف اسپرینت خارج شوند.
-
یوزر استوریها را شفاف کنید
در فرایند توسعه محصول، یوزر استوری همان چیزی‌ست که یک فیچر، نیازمندی، باگ یا درخواست تغییر را تعریف میکند. این دقیقاً اولین جایی‌ست که دولوپرها به سراغش می‌روند تا بفهمند دقیقاً چه کاری باید انجام دهند. همکاری مدیر محصول و توسعهدهنده همیشه این چالش را داشته است. پس بهتر است داستان‌های کاربر را با این ساختار بنویسید:
عنوان / Title
یک عنوان واضح و کوتاه بنویسید، ترجیحاً بیشتر از ده کلمه نشود. این کار باعث میشود در لیست بلندبالای فیچرها، راحت بتوان مفهوم کلی داستان را فهمید؛ بدون اینکه لازم باشد همه متن را باز کنیم و بخوانیم. باور کنید این کار کلی از زمان شما را ذخیره میکند و وضوح خیلی خوبی به کار می‌دهد.
کاربر / User
کاربر را دقیق تعریف کنید. پرسونای او و درک نیازهایش بهترین نقشه برای نزدیک شدن به کاربر است. بهتر است جزئیات، اهداف یا علایق آن پرسونا را هم اضافه کنید.
هدف / Goal
اینجاست که تعریف می‌کنید دقیقاً چه کاری باید انجام شود. چند مثال:
-
وقتی کاربر روی دکمه «ارسال کد تأیید» کلیک میکند، یک پیامک حاوی کد به شماره موبایل او ارسال شود.
-
وقتی کاربر تصویر پروفایل خود را آپلود میکند، تصویر جدید در لحظه به‌روزرسانی و در تمام صفحات نمایش داده شود.
دلیل / Reason
اینجا توضیح دهید چرا این تغییر مهم است. چند مثال:
-
ارسال پیامک کد تأیید باعث افزایش امنیت ورود کاربران و جلوگیری از دسترسی‌های مخرب میشود.
-
نمایش فوری تصویر پروفایل جدید، تجربه کاربری بهتری ایجاد میکند و کاربر اطمینان پیدا میکند که تغییر با موفقیت انجام شده است.
معیارهای پذیرش / Acceptance Criteria
اینجا قوانین و منطق قرار می‌گیرد. معیارهای پذیرش شانس ارائه یک فیچر باکیفیت‌تر را بالا می‌برد، زیرا توسعهدهنده، تستر و ذینفعان می‌توانند با این معیارها بررسی کنند که آیا فیچر قبل از عرضه، شرایط موردنظر را برآورده کرده یا نه.
اگر در نحوه تدوین یوزر استوریها ابهام یا سؤال دارید، می‌توانید از اسکرام مستر تیم خود کمک بگیرید تا این مهارت را به نقطه اوج خود برسانید.
-
در مورد «چطور» همیشه سکوت کن!
این بخش اصلاً قلمرو شما نیست! هیچوقت به دولوپرها نگویید «چطور» باید یک کار را پیادهسازی کنند، زیرا آنها دید عمیق‌تر و دقیق‌تری نسبت به کدبیس، مدیریت داده‌ها و قراردادهای API دارند.
در عوض، همیشه با آنها یا لید تیم فنی همکاری کنید و بپرسید: «آیا این قابلیت قابل اجراست؟» یا «پیادهسازی این تغییر چقدر امکان‌پذیر است؟»
اگر شما روش انجام را به آنها دیکته کنید، وقتی نتیجه عجیب یا اشتباه شد، این شمایید که مقصر شناخته می‌شوید!
-
شنونده‌ای فوق‌العاده باشید
یکی از ویژگی‌های ضروری یک مدیر محصول خوب، رهبری است و رهبرهای خوب همیشه شنونده‌های عالی‌ای هستند! وقتی با تیم توسعه همکاری می‌کنید، ایده‌هایشان را بادقت گوش دهید.
آنها نزدیک‌ترین آدم‌ها به کدبیس هستند و می‌توانند بهترین سرنخ‌ها را درباره امکان‌پذیری یک ایده به شما بدهند.
خودم بارها با ایدههای ناب دولوپرها مواجه شدم که باعث شد صدها ساعت زمان صرفه‌جویی کنم.
تأکید می‌کنم که باید ایدههای تیم فنی را وارد فرایند تصمیم‌گیری کنیم.
-
قدرت جادویی دانش فنی
من مدیران محصول فوق‌العاده‌ای دیده‌ام که از دنیای مدیریت، مالی و حوزه‌های دیگر وارد این کار شده‌اند؛ اما اگر شما یک مدیر محصول با تسلط بالا روی تکنولوژی و استک‌های فنی باشید، این یک قدرت ماورایی‌ست.
با این مهارت، می‌توانید فیچرهای منسجم‌تر و پیشرفته‌تری طراحی کنید، بفهمید چرا تیم Dev یک چیز را به آن شکل توسعه داده، وابستگی‌های تسک‌ها را تشخیص دهید، فرایند انتشار یا Rollout را دقیق‌تر پیش‌بینی کنید، تعداد چرخه‌های رفت‌وبرگشت با تیم توسعه را کم کنید و کنترل مستحکمی روی کار داشته باشید و تیم توسعه را بهتر درک کنید.
وقتی دانش فنی داشته باشید، آدم‌ها راحت‌تر شما را دنبال میکنند و هیچ‌کس به شما به چشم یک مدیر محصول غیر‌فنی که از پشت پرده خبر ندارد نگاه نمی‌کند. خیلی از مدیران محصولی که معماری و تکنولوژی زیرساختی را نمی‌فهمند، ساعت‌ها با تیم توسعه وقت می‌گذرانند تا ساختار فنی را درک کنند و این یعنی اتلاف زمان زیاد و البته دست کم گرفتن شما توسط تیم Dev.
یادتان باشد، دولوپرها این روزها منابع گرانی هستند و واقعاً نباید وقت آنها را برای چیزهایی که می‌توانستید خودتان یاد بگیرید ولی نگرفتید، هدر دهید.
-
با دقت انتخاب کنید که از چه بگذرید!
به‌عنوان مدیر محصول، شما همیشه باید بین این سه مورد یکی را قربانی کنید:
-
قلمرو (دامنه) / Scope
-
زمان / Time
-
کیفیت / Quality
حرف من این است: سعی کنید هیچوقت کیفیت را قربانی نکنید! چون هرچقدر هم کیفیت را کم کنید، باز هم تیم توسعه فیچر را در همان زمان تعیین شده تحویل می‌دهد، ولی با کیفیت پایین. این کار کم‌کم چیزی به اسم بدهی فنی / Technical Debt ایجاد میکند که به‌مرور جمع میشود و بعداً مقیاس‌پذیری محصول را گران، پر خطا و دردسرساز میکند.
این یکی از چالش‌های مدیر محصول و دولوپر است که پس چه چیز را قربانی کنیم؟
دامنه! سعی کنید در اکثر مواقع حامی حقوق تیم توسعه باشید و ذینفعان را قانع کنید که از حجم کار کم کنند. می‌دانم این کار آسان نیست، ولی مدیریت محصول هم هیچوقت آسان نبوده است.
-
صدای بلند کاربر باشید
شما نماینده اصلی کاربران و مشتریان هستید. آیا این دو یکی هستند؟ خب، بیشتر وقت‌ها بله، ولی همیشه نه! مثلاً وقتی یک شرکت مشتری محصول شماست، آن شرکت مشتری شماست چراکه محصول را از شما خریده است؛ اما افرادی که داخل اپلیکیشن لاگین میکنند و از آن استفاده میکنند، کاربر نهایی شما هستند.
بعد از هر اسپرینت اسکرام، اگر مشکلی بعد از انتشار پیش بیاید، نمی‌توانید تقصیر را گردن تیم توسعه بیندازید. شما باید قبل از انتشار، تست می‌کردید که آیا چیزی که قرار است ارائه شود با معیارهای پذیرش هماهنگ است یا نه.
برای جلوگیری از این اشتباه، در طول مراحل مختلف چرخه توسعه محصول / SDLC چندین بار با تیم توسعه یا لید فنی هماهنگ شوید. به‌عنوان مدیر محصول، هیچ‌گاه اصل «اول کاربر» را فراموش نکنید و همیشه صدای کاربران نهایی باشید، چه بین مهندس‌ها، تسترها، نیروهای دواپس، طراح‌ها و حتی ذینفعان!
-
موفقیت ارتباطات در تکرار مداوم است
فرض کنید اولین بار ویژگی جدیدی را به تیم توسعه معرفی می‌کنید و جلسه‌ای درباره آن برگزار میشود. اما این فقط شروع کار است! ممکن است بعد از جلسه اول، دولوپرها سؤال‌هایی داشته باشند یا نکاتی برای بهبود پیشنهاد بدهند. پس لازم است که شما مرتب با آنها در تماس باشید، بازخوردهایشان را بشنوید و اطلاعات را به‌روزرسانی کنید.
مثلاً وقتی نسخه اولیه آماده شد، دوباره آن را بررسی می‌کنید و مشکلات یا ایدههای جدید ظهور میکنند. این روند مکرر باعث میشود محصول نهایی دقیق‌تر و کارآمدتر باشد و همه در جریان پیشرفت کار باشند.
این ارتباطات پی‌درپی را می‌توانید در جلسات بک لاگ رفاینمنت، اسپرینت پلنینگ و ریویو پیگیری و بررسی کنید.
-
اعتماد تیم توسعه را جلب کنید
مثلاً اگر توسعه‌دهنده‌ای مشکلی را مطرح میکند، شما بهجای رد کردن سریع نظر او، با دقت گوش دهید و راه‌حلی مشترک پیدا کنید. در این تیم احساس میشود که نظرات شنیده و ارج نهاده میشود.
به این ترتیب اعضای تیم بیشتر با شما صادق خواهند بود، مشکلات را زودتر به شما می‌گویند و با انگیزه بیشتری کار میکنند. در مقابل، اگر مدیر محصول بدون توجه به نظر تیم، دائم به آنها فشار بیاورد توسعه‌دهنده‌ها ممکن است صرفاً کار را انجام دهند؛ ولی کیفیت و خلاقیت آنها کم میشود.
در انتها...
مدیریت محصول فقط برنامه‌ریزی و تعریف فیچرها نیست؛ بخش بزرگی از موفقیت شما به این برمی‌گردد که چطور با تیم توسعه همکاری کنید. Dev Team بازوی اجرایی ایدههای شماست و ارتباط پروداکت منیجر و دولوپر بسیار اهمیت دارد. پس اگر ارتباطتان با آنها ضعیف است، هیچ استراتژی یا بک‌لاگی شما را نجات نمی‌دهد!
به یاد داشته باشید:
-
جزئیات شفاف، یعنی نصف راه موفقیت.
-
بهجای دیکته کردن «چطور»، روی «چه» و «چرا» تمرکز کنید.
-
اعتماد و ارتباط مداوم، دو ستون اصلی یک همکاری موفق‌اند.
-
اگر دانش فنی داشته باشید، نه‌تنها احترام تیم را به دست می‌آورید، بلکه سرعت و کیفیت محصول هم چند برابر میشود.
-
همیشه مدافع کیفیت باشید، حتی اگر مجبور شوید دامنه کار را کوچک کنید.
در نهایت، شما نماینده و صدای کاربر هستید؛ پس در هر تصمیم، از برنامه‌ریزی تا انتشار، صدای او را بلند و واضح به گوش همه برسانید. وقتی این مهارت‌ها را تمرین کنید، نه‌تنها محصولتان موفق‌تر میشود، بلکه همکاری شما با تیم توسعه تبدیل به یک رابطه حرفه‌ای و لذت‌بخش خواهد شد.
|
«مدیریت محصول، نقشه راهی‌ست بین نیاز کاربران و توانایی تیم. در اجیلیتی، آموزش مدیریت محصول با نگاهی به چالش‌ها و فرصت‌های بازار ایران ارائه میشود.»
|