توی مطالب قبلی از مبحث پروداکت دلیوری با تدریس میلاد حاج فتحعلی، همه‌ی قطعات پازلی که در تعریف پروداکت دلیوری داشتیم رو بررسی کردیم تا رسیدیم به خود قطعه پازل پروداکت دلیوری. در این مرحله دیگه به فازی میرسیم که میخوایم محصول رو بسپریم به دست همه کاربرا و مبحث دلیوری محصول تموم میشه. این بخش شاید به ظاهر یه قطع پازل ساده باشه ولی چند تا نکته مهم داره که در ادامه درباره‌ش صحبت میکنیم.
بخش‌های قبلی دلیوری محصول رو میتونین در این مطالب بخونین:
اولین نکته مهم اینه که به عنوان PM استراتژی کانتکست رو برای تیم فنی خوب جا انداخته باشی که حتی نیروهای فنی هم بدونن داریم کدوم سمت میریم. مهمه که اونها از دلایل انجام کارها و تصمیماتی که در ادامه استراتژی کانتکست گرفته میشه مطلع بشن. تیم فنی نباید حس کنن که دارن صرفا یه رباط تصور میشن و قرار نیست با محصول و چرایی کارها اینگیج بشن.
مورد بعدی اینه که هیچوقت وقتی هنوز با تیم فنی الاین نشدی و نظرشون رو در مورد کار و تایم‌بندی کارها نگرفتی، به ذینفعا و مدیرا کامیت ندی و خواسته‌هاشون رو بدون مشورت با فنی نهایی نکنی و تایم ندی از خودت. درستش اینه که وقتی نیازمندی رو از مدیریت میگیری بهشون بگی بعد از اینکه با بچه‌های فنی کار دیسکاوری و ریلیز نهایی رو تخمین زدیم برمیگردم و میگم چقدر زمان میخواد اینکار.
و این ترفند مهمه که بعد از تخمینی که از فنی گرفتی لازمه اون رو ضربدر یه ضریب منظقی بکنی و اونو به مدیریت بگی که آقا ما فرآیندمون اینه، اینطوری دیسکاور میکنیم، اینطوری مطمئن میشیم سولوشن درسته یا نه و در نهایت ریلیز نهایی رو میریم که انقدر زمان میبره.
مهمه که نری دقیقا به فنی بگی که اینه راه حل و میخوایم بزنیم. بهتره ازشون نظر بپرسی، بگی صورت مسئله اینه، نظر شما چیه؟ ایده من اینه و من اینطوری فکر میکنم. اینجوری میتونی تِراست رو با تیمت بسازی و در چنین فضایی ممکنه حتی به راه‌حل‌های بهتری از دل تیم برسی که بتونی اونا رو به مدیریت منتقل کنی و پیشنهاد بدی.
نکته مهم بعدی اینه که یه PM مرز دونسته‌هاش از ندونسته‌هاش جدا باشه. بهتره اگر سوالی داشتیم که جوابش رو نداریم در موردش صادق باشیم و سعی نکنیم خودمون رو دایرت‌المعارف صورت مسئله‌های محصول نشون بدیم. اما باید متعهد باشیم که در یک ددلان مشخص برگردیم و سعی کنیم جواب مسائلی که نمی‌دونیم رو دربیاریم و با تیم به اشتراک بگذاریم.
شاید فکر کنیم این موضوع میتونه اعتبار ما رو در تیم خدشه‌دار کنه. این مسئله خیلی به سطح ما در سازمان بستگی داره و با توجه به اینکه APM هستیم، جونیور هستیم یا سینیور باید نسبت دانسته‌ها به ندانسته‌هامون رو متناسب با سطحمون آپدیت نگه داریم. یه APM میتونه 50 50 بدونه و ندونه، اما این برای یه سینیور فرق میکنه. سینیور دست کم باید 70 بدونه و 30 ندونه. اما صداقت در مورد ندانسته‌هامون و تعهدمون به پیدا کردن جواب، اتفاقا باعث میشه که اعضای تیم همواره اطمینان بیشتری به دانسته‌های ما داشته باشن و تِراست قوی‌تری شکل میگیره بینمون.
وقتی این تِراست شکل میگیره حرف زدن و فالو آپ راحت‌تر میشه. اما باید یادمون باشه که توی فالو آپ کردن همیشه لحن همدلانه و درک متقابل رو حفظ کنیم. به عنوان یه PM اگر تِراست بسازیم و problem oriented باشیم، حرف‌هامون اثرگذاری بیشتری دارن و این حس رو داریم که تیممون پشتمونه و اعتماد به نفسمون بیشتره و راحت‌تر میتونیم مدیریت و ذینفع‌ها رو مدیریت کنیم.
یه نکته ای که وجود داره اینه که باید حواسمون باشه قرار نیست همه‌ی اعضای تیم فنی به یک اندازه اینگیج بشن. بهتره اونایی که دغدغه دارن رو اینگیج کنیم (که در بهترین حالت میتونیم نقش TPM (Technical Product Manager) رو در کنار خودمون داشته باشیم) و اونایی که ترجیح میدن فقط تسک بگیرن رو جور دیگه‌ای منیج کنیم.
اون آدم اصلی توی فنی که توی دیسکاور بهت کمک میکنه، تخصص فنی داره اما بیزینس رو دوست داره و میتونه فیدبک‌های مثبتی در اون زمینه بده.
کسیه که کمک میکنه تایمی که PM توی سازمان‌ها مجبوره درگیر کارهای سمت مدیریت پروژه بشه رو کاهش میده و هندلش میکنه.
اگر این آدم نباشه ممکنه خیلی طول بکشه که PM بتونه با تک تک آدم‌های فنی ارتباط موثر بسازه و تراست ایجاد کنه. ولی با وجود TPM تو میتونه تِراست رو با تِک‌لید بسازی و با بقیه فقط رفاقت داشته باشی و دیگه تک‌لید خودش بقیه رو منیج میکنه. که در نتیجه باعث میشه روابط بهتر مدیریت بشه و زمان هدر نره. TPM به عنوان نماینده فنی در فاز دیسکاور و دیزاین حضور داره و نظراتش میتونه خیلی کمک کنه. به عنوان حلقه وصل PM و بچه‌های فنی عمل میکنه و به عنوان کسی که با تو الاین شده میتونه سمت فنی رو منیج کنه.
چیزی که مهمه اینه که این آدم باید کمتر درگیر کد بشه و بیشتر نقش لیدر رو به عهده داره. یعنی رابطه مدیر محصول و تیم فنی رو منیج میکنه و سرعت میده.
همونطور که مشخصه دلیوری محصول در ارتباط مستقیم با تیم فنی قرار داره و یکی از نکات مهم درباره این موضوع مسئله زمانبندی و تخمین زمان مورد نیاز برای داون شدن کارهاست.
در مورد ریلیز نهایی یا دلیوری‌های کوچیکی که در طول فاز دیسکاوری داریم، همیشه با این سوال روبروییم که این کار چقدر طول میکشه؟
سازمانهایی که مدام توش این سوال پرسیده میشه خودشونم نمیدونن بعدش قراره چیکار کنن. چون اون کانتکست درست توشون ایجاد نشده. چون اگر کانتکست درست توی سازمان وجود داشته باشه، مدیریت هم در جریان فاز و مسائل تو قرار داره و ارتباط بهتری برقرار میشه بینتون. در غیر اینصورت همیشه احساس میکنی همه چی فورسه و مشخص نیست برنامه پیش رو چیه؟
بازم تاکید میکنم که PM بدون هماهنگی نباید بره کامیت کنه و باید با تیمش هماهنگ باشه، بعلاوه اینکه باید زمان تخمین زده شده رو بک ضریب منطقی بهش بده و اونو به مدیریت بگه. مهمه که به ذینفعا بگی که ما مسئله رو کوچیک کردیم و این متریک‌ها رو تعریف کردیم که سریع‌تر بره بالا ببینیم الان سولوشن خوبی هست یا نه؛ که این اگر اوکی شد فاز نهایی انقدر طول میکشه و...
خیلی مهمه که تایم اولیه رو وقتی دادی، باید حواست باشه همیشه ذینفعا رو آپدیت نگه داری و به عنوان PM وظیفه داری تغییراتی که به دلایل مختلف در زمانبندی رخ میده رو به مدیریت یا ذینفعا اطلاع بدی تا در جریان باشن و بدونن چرا کارها داره طول میکشه.
اینجا تو تِراست رو شکل دادی چون مسئله رو شکستی، تایم دقیق دادی، تیمت ازا حمایت میکنن، اگر تغییری بشه آپدیت میکنی و همه اینها اعتمادسازی میکنه و هر چقدر اعتماد بیشتر باشه سوال مداوم "این کار چقدر طول میکشه؟" از بالا کمتر میشه.
باید حواست باشه هر ایده‌ای رو یه فاز دیسکاوری بری براش و بعد بری سمت دلیوری تا فاز تست و ریلیز جدا باشه از هم. این باعث میشه که توی هر فاز در صورت نیاز آپدیت کنی زمانبندی رو و ریسک اینکه کار طول بکشه رو کمتر کنی.
خلاصه‌ش میشه اینکه بچه‌ها ناراحتی‌ها و خوشحالی‌هاشون رو به اشتراک میذارن و بعد فیدبک‌ها سگمنت‌بندی میشه و تیم‌ها و مسائلشون مشخص میشه و سعی میشه برای مسائل راه حل پیدا بشه. اصل مطلب اینه که مسئله اکتیو لیسنینگ وجود داشته باشه و مسائله تیم دیده بشه.
توی این مطلب به خوبی تکنیکهای برگزاری جلسات رترو در متد اجایل رو توضیح داده. ابزارهای مختلفی برای برگزاری این جلسات به صورت آنلاین و ریموت وجود داره که امکانات مورد نیازمون رو در اختیارمون قرار میده. مثل RemoteRetro ،Echometer، FunRetro و...
وقتی چیزی رو میفرستید بالا و فیچری ران میشه یا هر تغییری که به وجود میاد، مهمه که همه از جمله پشتیبانی، فروش و مارکتیک باید در جریان قرار بگیرن که محصول داره چه تغییراتی میکنه. بنابراین باید یه داکیومنت براش درست بشه که محصول چی بود و چه زمانی قراره چه تغییراتی بکنه و چه زمانی چه تغییراتی کرده.
توی این مطلب به خوبی درباره اینکه چطور میتونیم ریلیز نوت بنویسیم توضیح داده و مثال‌های خوبی آورده.
داشتن لاگ کارها به پیش‌بینی تاثیر کارهای آینده‌ت کمک میکنه و کمک میکنه اگر جایی به مشکل خوردی بتونی تشخیص بدی به چه علت بوده و چرا اینطوری شده؟ بنابراین مهمه که بدونیم در چه تاریخی چه کاری انجام شده و محل اثرش کجا بوده.
توی این بخش از ویدئو میلاد حاج‌فتحعلی نکات سافت اسکیلی بسیار خوبی مطرح میکنه که دیگه توی این مطلب به همشون اشاره نمی‌کنم. اما در ادامه چند تا نکته جذابش رو به طور خیلی خلاصه میارم تا سرنخ دستمون باشه.
1. وجود تفکر نقادانه در تیم خیلی مهمه؛ و مهم‌تره که افراطیو تفریطی نباشه. یعنی نه اینجوری باشه که اصلا فکر نکنی، نه اینکه اوتینگ باشی. اگر سطح خوبی از تفکر نقادانه در تیم وجود داشته باشه نمودش اینه که جلوی سرعت رو نمیگیره ولی باعث میشه mvpت هم تا جای ممکن اونی باشه که باید باشه.
2. مهمه که تعریف شکست توی سازمان وجود داشته باشه. وقتی تعریف شکست در تیمت وجود داشته باشه نمودش اینه که بچه‌ها دارن با این دید تلاش میکنن که میریم تا با احتمال کمتری شکست بخوریم. میریم جلو، مترارو درمیاریم سعی میکنیم کاری کنیم که زودتر متوجه بشیم داریم شکست میخوریم و مسیر رو عوض میکنیم. این نگرش برخلاف نرگش "میریم که موفق بشیم" جلوی جسارت شروع کار رو نمیگیره و ترس از شروع توش وجود داره. و همیشه در اولین زمان ممکن هرجا که لازم بود مسیر رو تغییر میدیم. و حُسن دیگه‌ش اینه که باگای مار درمیاد و جاده‌ای که تو آسفالت کردی رو دیگه بقیه دیگه الکی نمیرن.
مثال میاره از پروژه تغییر ساحتار دسته بندی که توی قبیله کالای دیوار وجود داشت که 6 ماه زمان برد اما وقتی جزئیاتش درومد برای تیم‌های دیگه 2 ماهه اوکی میشه.
3. نباید زیاد درگیر مسائل اینچنینی بشیم که آیا سازمان فلت هست یا نه و... مهم اینه که یه تعادلی بین تاپ-داون و باتن-آپ وجود داشته باشه و بروکراسی زیادی نداشته باشیم.
4. تیمی خوبه که توش فرآیندی برای فیدبک وجود داشته باشه. دو تا نمودی که توی دیوار داریم جلسات رترو و جلسات یک به یک هستنش که من با عنوان لیدر با کسایی که لید میکنم دو هفته یه بار جلسه میرم، و رترو هم ماهی یکبار با کل تیمه. و درستش اینجوریه که تهش اگر نکته‌ای درومد پیگیری بشه و مشکل حل بشه.
یه مدیر محصول خوب کسیه که بتونه ارتباط درست و موثری با آدم ها برقرار کنه، بتونه فعالانه گوش بده و واکنشهای کنترل شده‌ای داشته باشه.نمودش اینه که تیمت باهات راحتن و میتونن صریح باهات حرف بزنن و رفاقت و اعتماد بینتون وجود داره. مهمه که بتونی زبون آدمها رو پیدا کنی؛ با کسی که شوخ نیست شوخی نکنی، با کسی که شوخ‌طبعه بیش از اندازه جدی نباشی. EQ خوبی داشته باشی، یعنی بتونی با آدمها طوری ارتباط بگیری که زیر فشار قرار نگرین. بحث مدیریت زمان، شجاع بودن، تشخیص مرز حماقت از شجاعت، صبور بودن، تحمل ابهام، پروداکت سنس و داشتن شهود محصولی چیزایی هستن که اهمین دارن. کاری نباید معطل ترسو بودن یا کمالگرایی PM بشه.
اینها مهارت‌هایی هستن که کمک میکنن یه مدیر محصول خوب باشی؛ با تیمت ارتباط درستی بگیری و در نتیجه کارها اونطور که انتظار داری پیش برن و محصول به درستی دلیور بشه.
موضوع دلیوری محصول اینجا تموم شد و ازین به بعد وارد موضوع مدیریت پروژه میشیم.
