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