ماست مالی کردن یا از دست ندادن بازار

مدیر:”آقا پس این کی تموم میشه؟”

برنامه نویس:”این کار می بره، باید رو طراحیش کار کنم…”

مدیر: “همینجوری خوبه، بده بدیم مشتری تا نپریده”

برنامه نویس: “فقط بلدین ماست مالی کنید کارها رو، هیچ استانداردی اینجا رعایت نمی شه…”

یکی از بزرگترین چالش ها در دنیای توسعه نرم افزار ارتباط بین توسعه دهندگان (برنامه نویس، طراح 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 و با معماری تدریجی و طراحی پدیداری، سعی کند معماری و طراحی را از اول پیچیده در نظر نگیرد. به قول دوستان معمار، معمار خوب کسی است که تصمیم های مهم را به بعد موکول کند، یعنی اینکه با کسب دانش در طول پروژه بتواند تصمیم های درست تری بگیرد.

چابک و موفق باشید

اسد صفری

اگر به تازگی با چابک یا اسکرام آشنا شده اید پیشنهاد می کنم این کتابچه چند صفحه را بخوانید و اگر مطالب بیشتری نیاز داشتید شاید این مطلب اول تا آخر چابک برای شما مفید باشد.

مطالب را هم دوست داشتید می توانید از طریق این لینک عضو فید دنیای چابک شوید تا مطالب جدید برای شما ارسال شود

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

6 دیدگاه

  1. وحید   •  

    وااای!
    یعنی در هر شرایطی قرار می‌گیرم چند روز بعدش یه مطلب در مورد اون در وبلاگ‌ها و خبرنامه‌ها می‌خونم.
    الان در اصفهان در یک شرکت کار می‌کنم و بین من و مدیر شرکت دقیقا این حالتی که مثال زدید وجود داره. من می‌خوام کد تمیز بنویسم و مدیر شرکت میگه بزن بره … !

  2. رضا هاشمی   •  

    مثل همیشه چابک و خواندنی. ممنون

  3. محسن عرب   •  

    واقعا ازت یاد می گیرم. ممنون

  4. عدالت   •  

    بازاریابی یکی از مهم‌ترین ارکان هر شرکت محسوب می‌شود. بازاریابی خوب با تحقیقات و قیمت‌گذاری در بازار آغاز می‌شود لیکن جنبه‌های بسیار دیگری مشتمل بر تبلیغات، بسته‌بندی، نشانه‌گذاری، توزیع و نیز رضایت مشتری، بر آن تاثیر می‌گذارد.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *