پولدارشو:
مدیر:«آقا پس این کی تموم میشه؟»
برنامه نویس:«این کار می بره، باید رو طراحیش کار کنم…»
مدیر: «همینجوری خوبه، بده بدیم مشتری تا نپریده»
برنامه نویس:« فقط بلدین ماستمالی کنید کارها رو، هیچ استانداردی اینجا رعایت نمیشه…»
یکی از بزرگترین چالشها در دنیای توسعه نرم افزار ارتباط بین توسعهدهندگان (برنامه نویس، طراح UI و …) با مدیران (مدیرمحصول، مدیر پروژه و…) است، از طرفی توسعهدهندگان مدیران را متهم به«ماست مالی کردن و بزن درویی کار کردن» میکنند، مدیران هم برنامه نویسها را به «اضافه کاری بیمورد یا هیجان فنی یا تولید چیزی که مشتری لازم ندارد» متهم میکنند. اما واقعیت چیست؟
پنجره شانس
بعضی وقتها محصولات مانند روزنامه است، روزنامه امروز، فردا بعنوان روزنامه باطله بفروش میرسد. اولین بودن در ارایه یک محصول یا یک ویژگی خاص در بازار رقابتی، میزان موفقیت محصول را بالا میبرد. حتی اگر محصول خوبی ارایه کنید، سریعا رقبا آن را کپی خواهند کرد، پس ارایه سریع و مداوم ویژگیها الزامی است.
برای مثال اگر توجه کردهباشید همه بانکها امکان برداشت پول از عابرها بدون کارت را دارند ولی اولین بانکی که این کار را انجام داد تبلیغات بشدت زیادی در این خصوص انجام داد، ولی کمتر از چند هفته بانکهای دیگر همان ویژگی را کپی کردند. پنجرههای شانس برای همیشه باز نیستند و سریع بودن در بازار رقابتی بشدت نیاز است.
بدهی فنی
سرعت ارایه بالا بشدت در بازار رقابتی باعث مزیت رقابتی خواهد شد، و لعنت به هر چیزی که ما را کند بکند. اما چه چیزی ما را کند می سازد؟
وقتی طراحی سیستمها ضعیف باشد، وقتی برنامهنویسها بخاطر سرعت، کیفیت را فدا کنند، وقتی متد طراحی ما Code & Fix بشود، وقتی کارها بزن درویی انجام شوند، مثل آن دزدی میشود که شب ساز میزد ولی صدایش فردا صبح در میآمد. در چنین شرایطی بعد از مدتی اضافه کردن ویژگیهای جدید بسیار سخت خواهد شد و هزینه رفع باگ هم بالا خواهد بود. هر باگی که درست میشود، چند باگ جدید ایجاد خواهد کرد. معمولا در این فازها جمله آشنای «از اول مینوشتیم بهتر بود» را خواهیم شنید.
به هر چیزی که فرآیند توسعه را کند نماید، بدهی فنی گفته می شود.
بدهی فنی و پنجره شانس
بدهی فنی اصولا همیشه بد نیست، البته زمانی که بخواهیم پنجره شانس را از دست ندهیم. اما زمانی بد می شود که حجم بدهی آنقدر زیاد شده باشد که قابل پس دادن نباشد. پس بدهی می گیریم تا شانس را از دست ندهیم، ولی باید برای پس دادن آن بدهی زودتر برنامه ای داشته باشیم.
مدیران بخوانند:
- بدهی فنی می تواند بنیاد هر نوع سیستمی را از بین ببرد، می تواند آبروی شما را جلوی مشتری ببرد. سعی کنید مابین توسعه ویژگی های جدید و توسعه ویژگی های فنی مانند فریم ورک، رفاکتور کردن، ایجاد چارچوب تست و … یک تعادل ایجاد کنید
برنامه نویس ها بخوانند:
- اگر بهترین فریم ورک ها تولید بشوند، بهترین طرح ها ایجاد شوند، تمیز ترین کدها نوشته بشوند، ولی اگر فرصت بازار از دست برود دیگر همه اینها بدرد نخواهد خورد. هدف همه ما حل مشکل کسب کار است. سعی کنید مابین توسعه ویژگی های جدید و توسعه ویژگی های فنی مانند فریم ورک، رفاکتور کردن، ایجاد چارچوب تست و … یک تعادل ایجاد کنید
در آینده حتما یک نوشته کامل در مورد بدهی فنی خواهم نوشت.
Gold Plating
اما همیشه داستان بدهی فنی وپنجره شانس نیست بلکه عطش فنی بچه ها است. به یاد می آورم در پروژه ای دوستان اسرار بشدت زیادی داشتند که حتما ما باید از معماری Micro Services استفاده کنیم و فقط این جواب پروژه را می دهد. سوالی که پرسیده شد که آیا کسی در تیم تجربه این تکنولوژی(معماری) جدید را دارد؟ جواب این بود که «یک چیزهایی خوندیم، ولی راه میندازیم مشکلی نیست…».
کسی که گرسنه است اصلا متوجه نمی شود شما در بشقاب طلا به او غذا داده اید، به این مفهوم Gold Plating گفته می شود. یعنی اینکه شما برای انجام یک پروژه از تکنولوژی های استفاده کنید که هزینه زیادی دارند و اصلا نیازی به این پیچیدگی نبوده است و با تکنولوژی های ساده تر هم نیاز رفع می شد.
دو مورد کلی باعث Gold Plating می شود:
۱- عطش یادگیری در نیروهای فنی : چه دوست داشته باشیم یا نه، این ویژگی بارز نیروهای فنی است و آنها همیشه دوست دارند تکنولوژی های جدید را تجربه کنند و یاد بگیرند و دوباره یاد بگیرند. البته نیروی فنی با دیدن فیلم آموزشی یا کلاس چیزی یاد نمی گیرد، او زمانی یاد می گیرد که در پروژه (واقعی) تجربه کرده باشد. اما بعضی وقت ها هزینه یادگیری، یک پروژه شکست خورده می شود (یکی از دوستان می گفت؛ خوب چی مهم تر از این (: )
۲- بزرگ جلوه دادن پروژه از سمت مدیران محصول: بعضی وقت ها مدیران محصول بدلیل عدم آشنایی با کسب کار، پروژه را بزرگ جلوه می دهند. مثلا برنامه نویس می پرسد چند نفر قرار است با این سیستم همزمان کار کنند، جواب «خیلی زیاد مثلا ۵۰۰ هزار نفر» . یا «آیا قرار است بعدا این قوانین کسب کار توسط خود مشتری عوض شوند؟» جواب:«بله». شاید یک جواب بله، باعث بشود که تیم به سراغ Workflow engine – فرم ساز و … بروند و این یعنی هزینه خیلی زیاد.
راه حل :
۱- عطش یادگیری را نمی توان از بین برد، ولی شرکت هایی مثل گوگل که ۲۰ درصد زمان را به خود نفرات می دهند، شاید یکی از دلایل همین یادگیری در حین کار باشد.
۲- اصلا YAGNI در مورد این است که به چیزی که نیاز ندارید و مطئمن نیستید زیاد فکر نکنید، You are not gonna need it. یکی از هنرهای مدیریت محصول این است که تیم را به سمت ایجاد یک راه حل بزرگ نکشاند و سعی کند مشکل کسب کار را با کوچکترین راه حل ممکن حل کند.
۳- هنر تیم هم این است که با تکیه بر اصول Keep it simple و با معماری تدریجی و طراحی پدیداری، سعی کند معماری و طراحی را از اول پیچیده در نظر نگیرد. به قول دوستان معمار، معمار خوب کسی است که تصمیم های مهم را به بعد موکول کند، یعنی اینکه با کسب دانش در طول پروژه بتواند تصمیم های درست تری بگیرد.
منبع