فرق کلوچه سازی با توسعه نرم افزار

–          من : “اکبر آقا، سلام. دستگاههای جدید مبارک”

–          اکبر آقا : “قربونت، خواستیم خط تولید رو مکانیزه بکنیم”

–          من : “برای چی؟ اینطوری یک سری آدم هم که بیکار میشن”

–          اکبر آقا :”ببین دیگه کارگر صرف نمیکنه کلی هم ناز و نوز داره، گذشته از این ما میخاییم تولیدمون رو دو برابر کنیم با این ماشین ها میتونیم چند شیفت تولید کنیم”

 همیشه وقتی از دوستان یا همکاران یا شرکت های مختلفی که در آن هستیم “لفظ خط تولید نرم افزار” رو می شنوم یاد این خاطره میفتم. برای همین دوستان نزدیک که با من کار کرده اند می دونند که همیشه از “ما که کلوچه تولید نمی کنیم …” استفاده می کنم.

 اما واقعا چرا تولید کلوچه با توسعه نرم افزار فرق دارد؟

 –          هر چقدر بیشتر بهتر؟!

در خط تولید معمولا هر چقدر بیشترش بهتره، یعنی خط تولید رو سه شیفته می کنند تا تولید بیشتر بشه، ولی در نرم افزار کمش بهتره. اگر تجربه پروژه نرم افزاری دارید، لازم هم نیست کتاب پرسمن رو خونده باشید، خواهید فهمید که مابین “تعداد قابلیت ها یا ویژگی ها یک نرم افزار” و “هزینه نگه داری” یک رابطه مستقیم وجود دارد. خیلی ساده، ویژگی بیشتر یعنی باگ بیشتر، باگ بیشتر یعنی دیباگ بیشتر، دیباگ بیشتر یعنی زمان بیشتر، این یعنی عصاب خوردی برنامه نویس ها و هزینه کارفرمای بدبخت.

حالا شاید شما بفرمایید نه ما خط تولید با کیفیت داریم، تست داریم، این رو داریم و اون رو داریم، ایجاد این امر در عمل کار بسیار سختی است اما بالاخره برای نوشتن تست زمان زیادی صرف می شود که این ها نیز به نوعی هزینه نگه داری هستند.

–          افکار کلوچه سازی به جای نرم افزاری

فرق نداره که روش توسعه  اسکرام باشد یا واترفال. مسئله این هست که فکر کلوچه سازی است.

مدیران فکر می کنند چون به برنامه نویس ها پول داده اند پس باید پدر اونها رو در بیارند و تولید رو به حداکثر برسانند، ویژگی پشت ویژگی. برنامه نویس ها هم که چون پول گرفته اند و احساس گناه می کنند فکر می کنند هر چقدر بیشتر کد تولید کنند بهتره. مشتری هم که قراره پول بده بابت نرم افزار، کار نداره نرم افزار برای چه کاری هست، میخاد همه چی داشته باشه.

–          لعنت به نیازمندی ها

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

باید باشه … کی گفته باید باشه؟!؟!؟! که گفته اصلا نیازه؟ چرا اصلا نیازه؟

همین لفظ نیازمندی ها که یک سری دوستان تنهایی اول پروژه ها شروع می کنند به تهیه آنها، بعد دست برنامه نویس ها میرسه برای تولید.

نشانه های افکار کلوچه سازی در پروژه های نرم افزاری

  • مدیران می خواهند چند نفر برنامه نویس جدید به پروژه اضافه کنند تا سرعت تولید رو بالا ببرنند.
  • مدیران برای اینکه بیشتر تولید کنند، به ازای انجام کار بیشتر پاداش یا کارانه می دهند.
  • هر چقدر بیشتر تولید کنیم بهتره. خروجی هر چقدر بیشتر می شود (Feature بیشتر) خوشحال تر می شویم، بدون اینکه در نظر بگیریم تاثیر این خروجی بر کاربران چی هست؟!
  • یک برنامه نویس شاخ میاریم (سرکارگر) بقیه برنامه نویس ها در حد تایپیست؛ اون فکر می کنه بقیه انجام می دهند.
  • اول تولید می کنیم بعد دنبال این می گردیم که چه کسی مشتری این محصول ما است.
  • برنامه نویس ها کاری با مصرف کننده ندارند و فقط موظف هستند نیازمندی ها را انجام بدهند همین.

اگر دوستان علاقمند بودن، در یک نوشته بعدی به اینکه چگونه می توان این موارد رو برطرف کرد می تونیم بررسی داشته باشیم.

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

درباره اسد صفری

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

15 دیدگاه در “فرق کلوچه سازی با توسعه نرم افزار

  1. این بندهای مربوط به «نشانه های افکار کلوچه سازی در پروژه های نرم افزاری» رو با بند بند وجودم تجربه کردم.

    خوشحال میشم این مطلب ادامه پیدا کنه تا راه حل‌های پیشنهادی شما رو بخونم.

  2. توی صنعت طراحی و تولید بازی ها هم همیشه جا برای اضافه کردن فیچرهای هیجان انگیزتر هست، هیچ زمانی نیست که بتونی بگی خب دیگه تموم شد همش پیاده سازی شد و بهتر از این نمیشه. ذات بازی سازی هم اینه که وقتی فکر می کنی دیگه هیچ کاری نمونده میبینی کلی پیشنهادات هیجان انگیز رسید.
    ممنون اسد جان عالیه ادامش بدید لطفا

  3. خیلی خوب بود اسد جان …
    بعضی وقتها کل توان تیم صرف نیازمندی ها یی میشه که وقتی این ویژگی به نرم افزار ما اضافه بشه میبینیم شاید 10 % مشتری ها یا حتی کمتر از این قابلیت جدید استفاده میکنند …اما کارفرما دلش ب این خوشه که یک قابلیت به سیستمش اضافه شده غافل از اینکه این قابلیت جدید کلی هزینه برای نگهداری سیستم ایجاد کرده …مطلب بعدی رو بگی خیلی مفید هستش برای کسایی که تازه ممکنه با این مسایل رو ب رو بشن

  4. با سلام
    دوست عزیز، من با بسیاری از مطالب شما موافق هستم و با بخش هایی از آن موافق نمی باشم.
    به عنوان نمونه ما از تولید نرم افزار به عنوان پروژه یاد می کنیم در حالی که به تولید کلوچه و امثال آن عملیات یا Operation گفته می شود.
    در نتیجه وجود تفاوت بسیار بین پروژه و عملیات امری بدیهی می باشد.
    در نتیجه، افزودن منابع در هر پروژه ای(خواه سد سازی باشد یا نرم افزار) می بایست با دقت بیشتری انجام شود در غیر این صورت موجب ایجاد اصطکاک در بین کارشناسان خواهد شد و همچنین مدیریت پیچیده ای را نیاز خواهد داشت.
    در مورد نیازمندی های یک پروژه هم می بایست در نظر داشت که این یک اصل می باشد و ما می بایست به نیازهای مشتری و یا صاحبان پروژه پاسخ بدهیم. حال یا با ایجاد قابلیت جدید یا تغییر فرآیند اجرا و بهبود آن.
    این که در تیم نرم افزاری هیچ وقت و انرژی برای BPI صرف نمی شود مشکل در مفهوم نیازمندی نمی باشد.

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

    1. به همه نیازمندیها همیشه نمیشه پاسخ داد به خصوص در سیستمهای بزرگ .چون تناقض در نیازمندیها در ذات اونها وجود داره.
      به عنوان مثال شما شاید نتونید سیتمی رو پیاده سازی کنید که هم امن باشه و هم کارایی بالایی داشته باشه.
      تضمین امنیت یک سیستم میتونه زمانبر باشه.و گاها مجبور به ایجاد مصالحه یا tradeoff بین نیازمندیها هستیم

  5. ممنون مطلب عالی آموزنده ای بود که بحث کنترل تغییرات نرم افزار را به زبانی ساده بیان کرد ولی بعضا دیده ام که این مطالب به گونه ای تعبیر میشه که انگار نیازمندیهای نرم افزار اصلا مهم نیست.
    فراموش نکنیم که هدف اصلی نرم افزار چیه؟ رفع نیازهای مشتری و پوشش نیازمندیهای وی.
    اگر قراره از این متن این نتیجه گرفته بشه که باید تیم در مقابل نیازمندیهای جدید مقاومت کنه، اون موقع باید به کل متن شک کرد. ولی اگه قراره این برداشت بشه که فرایند مدیریت تغییرات در تولید نرم افزار اهمیت ویژه ای داره، اون موقع میشه گفت این متن با زبان ساده مفهوم بزرگی رو منتقل کرده.

پاسخ دادن به مجتبی پورمیرزایی لغو پاسخ

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

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.