بیشتر مدیران محصول ذی‌نفعان را مدیریت می‌کنند؛ تعداد کمی سیستم را می‌فهمند
۲۰ شهریور ۱۴۰۵
بیشتر توصیه‌های مدیریت محصول درباره افراد است: ذی‌نفعان، نقشه راه و چارچوب‌های اولویت‌بندی. کمتر درباره سیستمی صحبت می‌کنند که شما مسئول محصول آن هستید. پایگاه داده رابطه‌ای چه تضمینی می‌دهد که ذخیره‌ساز سری زمانی نمی‌دهد؟ قرارداد API چرا می‌شکند؟ مدل دسترسی پس از دو سال اجرای درخواست «برای این قابلیت هم یک گروه بسازید» چه شکلی پیدا می‌کند؟ بدون این سطح از شناخت، نمی‌توان درباره سیستم تصمیم درست گرفت. فقط می‌توان تصمیمی گرفت که در جلسه منطقی به نظر برسد.
سه نمونه از تجربه ساخت محصول در اکوسیستم پرداخت:
صفحه درگاه پرداخت بخشی از برنامه شما نیست
تیمی که محصول پرداخت را با Java توسعه می‌داد، باید وضعیت تراکنش را تشخیص می‌داد: کاربر پرداخت کرده یا فرایند را رها کرده است؟ سیگنال موجود، پاسخ سامانه خودشان و زمان دریافت آن بود. مسئله این بود که سامانه آن‌ها از اتفاقات صفحه درگاه پرداخت خبر نداشت. آن صفحه به بانک یا پردازشگر پرداخت تعلق داشت؛ سامانه‌ای مستقل با نشست، زمان‌بندی و مسیر بازگشت اطلاعات خودش. این مسیر معمولاً Webhook یا Callback است و پیام آن با تأخیر می‌رسد؛ زمان دریافت پیام الزاماً با اقدام کاربر هم‌زمان نیست.
تیم، «هنوز پاسخ نرسیده» را معادل «کاربر پرداخت نکرده» می‌گرفت. این دو وضعیت متفاوت‌اند. کاربر ممکن است موفق پرداخت کرده باشد، اما سامانه شما هنوز خبر نداشته باشد. اطلاعات باید از مرز سامانه‌ای عبور کند که تحت کنترل شما نیست. استفاده از تأخیر درگاه برای استنباط قصد کاربر، داشبورد سلامتی می‌سازد که با قطعیت نتیجه غلط می‌دهد. چنین داشبوردی از داشبوردی که عدم‌قطعیت را نشان می‌دهد خطرناک‌تر است؛ چون افراد تصمیم‌های بعدی را بر همان قطعیت غلط بنا می‌کنند.
راه‌حل، اصلاح ظاهر داشبورد نیست. باید بپذیریم «پرداخت انجام شد» و «ما از انجام پرداخت مطلع شدیم» دو رویداد مجزا هستند. میان آن‌ها مرزی خارج از کنترل ما وجود دارد. مدل وضعیت باید این فاصله را صریح نشان دهد و آن را حذف‌شده فرض نکند.
تحویل قابلیت با تحویل محصول یکسان نیست
در همان اکوسیستم، تیمی ثبت‌نام خودکار ساخت: شماره موبایل کاربر را از پایگاه داده موجود پذیرنده می‌گرفت و بدون درخواست کاربر یا اطلاع‌دادن به او، حساب می‌ساخت. این قابلیت یک مسئله واقعی را حل می‌کرد: موانع ورود کاربر. هم‌زمان برای فردی حساب و رابطه داده‌ای ایجاد می‌کرد که به هیچ‌کدام رضایت نداده بود. تیم عمداً سیاست‌ها را نادیده نمی‌گرفت؛ اصلاً به سیاست‌ها فکر نمی‌کرد. چون سیاست‌گذاری در دامنه تعریف قابلیت نبود. مسئله را مهندسی تعریف کرده بودند: چگونه از شماره تلفن حساب بسازیم؟ اما پرسش محصول این بود: ساخت حساب بدون رضایت، چه تعهدی برای ما ایجاد می‌کند، این تعهد در برابر چه کسی است و در آینده چگونه باید آن را مدیریت کنیم؟
فاصله میان «کد کار می‌کند» و «این قابلیت تحت چه محدودیت‌ها و تعهداتی باید وجود داشته باشد»، همان بخشی از کار است که وقتی نقش مدیر محصول را به «تبدیل درخواست ذی‌نفع به تیکت» تقلیل می‌دهیم، حذف می‌شود.
درخت مجوزها یک مدل داده است، نه فهرست کارها
کنترل دسترسی در همان اکوسیستم به شیوه رایج رشد کرد: یک گروه برای این قابلیت و یک گروه برای قابلیت بعدی. هر بار کسی دسترسی می‌خواست و گروه مناسبی وجود نداشت، گروه تازه‌ای اضافه می‌شد. پس از انباشت قابلیت‌ها، هیچ‌کس نمی‌توانست درخت مجوزها را ببیند و معنای آن را توضیح دهد. مسئله الزاماً غلط‌بودن یک گروه نبود؛ کل ساختار هرگز طراحی نشده بود و فقط روی هم انباشته شده بود.
سامانه مجوزها مانند هر سامانه دیگر، مدل داده دارد. این مدل شکل هدف و قواعدی دارد که باید همواره برقرار بمانند. هر استثنایی که به‌جای توسعه مدل اضافه کنیم، هزینه ایجاد می‌کند. اگر با آن مانند فهرست کار برخورد کنیم و بگوییم «کسی دسترسی می‌خواهد، یک گروه بساز»، بدهی فنی‌ای می‌سازیم که رفع آن از اصلاح کد سخت‌تر است. وقتی ساختار نامفهوم شود، دیگر کسی به یاد ندارد کدام دسترسی لازم است و کدام‌یک از قابلیتی قدیمی و فراموش‌شده باقی مانده است.
مسئولیت مدیر محصول در قبال سیستم
تیم‌هایی که در این اکوسیستم با آن‌ها کار کردم، هرکدام بخش خود را خوب انجام می‌دادند: یکی سفارش می‌گرفت، یکی کد می‌نوشت و دیگری منتشر می‌کرد. اما نگاه یکپارچه به سیستم، این فعالیت‌ها را به هم وصل نمی‌کرد. به‌ویژه کمتر کسی پایش، ثبت لاگ و بازیابی پس از بحران را بخشی از خود محصول می‌دانست. این موارد معمولاً پس از خرابی و به‌عنوان وظیفه عملیات به سامانه اضافه می‌شدند.
از نظر من مسئولیت اصلی همین است: شناخت سیستم برای تصمیم‌گیری، فراتر از چیدن درخواست‌های ذی‌نفعان در قالب نقشه راه. باید پایگاه‌های داده، APIها، ماشین‌های حالت و مرز سامانه‌هایی را که در اختیارمان نیستند بشناسیم. این شناخت باید به‌اندازه‌ای باشد که درخواست منطقی را از درخواست ریسک‌ساز یا مسئله اشتباه تشخیص دهیم. بیشتر مدیران محصول، افراد پیرامون سیستمی را مدیریت می‌کنند که نمی‌شناسند. باید سیستم را آن‌قدر فهمید که هماهنگی افراد پیرامون آن ساده‌تر شود.