10 قانون اساسی در توسعه محصول نرم افزاری

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

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

4-18-2014 6-04-49 AM

چرا تولید یا خروجی بیشتر نشانه موفقیت نیست؟ 

  1. در صنعت نرم افزار خروجی بیشتر = هزینه تولید و نگه داری بالا. 
  2. هزینه نگه داری ، معمولا 80% منابع پروژه صرف نگه داری می شود ( رفع باگ، پشتیبانی، مدیریت سرور ها و …)
  3. خروجی بیشتر = پیچیدگی برای کاربر نهایی، شاید مشتری زمانیکه پول میدهد از شما طلب هزاران قابلیت را کند، اما کاربر نهایی تنها بدنبال سادگی کار است.

خروجی یا برآیند؟ ما بدنبال کدام هستیم؟

خروجی یا Output  میزان خروجی شما است، یعنی کمیت کارایی خط تولید شما. مثل اینکه هر روز چند تا کلوچه تولید می کنید. اما برآیند یا Outcome کیفیت تاثیر کار شما بر مصرف کننده است. یعنی چند تا از کلوچه های تولیدی شما خورده می شود؟

اما سوالی که قابل طرح این است که ما دنبال خروجی هستیم یا برآیند؟ یا روش ما مبتنی بر کدامیک است؟

خیلی ساده، هر بار که یک Feature به محصول تان اضافه می کنید موارد زیر رو بررسی کنید:

الف – سریع Feature بعدی رو شروع می کنید و مشتری اگر درخواستی بر روی بهبود Feature قبلی نیز داشت به بعد موکول می کنید. علاقه کلی به تولید هست.

ب- Feature را به دست  مشتری می رسانید و بعد از مدتی رفتار کاربر را نسبت به آن قابلیت می سنجید و به این پی می برید که چرا کاربر از این قابلیت زیاد استفاده می کند یا چرا اصلا استفاده نمی کند؟

مورد الف کسانی هستند که خروجی محورند و مورد ب کسانی هستند که برآیند محور هستند.

راه حل چیست؟

یک نفر مسئول تصمیم گیری محصول 

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

این نفر نظرات و ایده ها را از همه (تیم، مشتری، مدیران و …) می گیرد ولی تصمیم گیر نهائی فقط خود این نفر است. تاکید فقط یک نفر.

نه به ایده های خوب 

همیشه وقتی محصولی را می سازید کلی ایده خوب به ذهن همه خطور می کند، به قدری که این ها بیشتر از منابع(پول و زمان) ما هستند. پس حواسمان باید باشد بیشتر از اینکه بله بگوییم باید نه بگوییم.

دهمین اصل بیانه چابک بهترین دوست مدیران و مالکان محصول

سادگی — هنر به حداکثر رساندن مقدار کار انجام  نشده — ضروری است (بیانه

اعترافی که باید بکنم این است که اولین بار که این اصل رو دیدم واقعا نفهمیدم یعنی چی؟ ولی بعد از چند سال واقعا به معنای واقعی کلمه پی بردم. سادگی سادگی سادگی. یعنی اینکه باید سعی کنیم تا آنجایی که امکان داره کار انجام ندهیم. یعنی بیشتر از اینکه Feature  اضافه بکنیم، نکنیم. به جای اینکه دنبال معماری پیچیده برویم، دنبال روش های ساده باشیم. یا بعبارت دیگر وقتی یک کاری شروع می شود بیشتر از اینکه دنبال چگونه انجام دادن آن باشیم دنبال “چرایی” بگردیم. چرا اصلا لازم است؟

قانون 80/20 

اگر شما یک لیست نیازمندی برای پروژه تان دارید، مطمئن باشید که فقط 20 درصد آنها نیاز واقعی مشتری را برطرف خواهند کرد. بقیه چیزهایی هستند که یا اصلا استفاده نخواهند شد یا خیلی کم. پس به جای اینکه منابع را بر روی 80 درصد کم استفاده صرف بکنیم بهتر است روی 20% سرمایه گذاری کنیم.

وظیفه مالک محصول اینجا کشف 20% واقعی و تمرکز بر روی آنها است.

فرضیه ها نیاز به آزمایش دارند 

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

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

هدف ساخت نرم افزار نیست

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

شاید این جمله خیلی شعار گونه باشد که هدف ما بهتر کردن زندگی است. ولی واقعا هدف IT به جز این نیست. دلیل اینکه ما نرم افزار حسابداری می سازیم، یا اپ ورزشی برای اندازه گیری کالری، چیزی نیست برای بهتر کردن زندگی. پس در این حالت تیم واقعا به جای اینکه به فانتزی های خود فکر کنند (من بهتر از اونها می دونم که اونها چی می خان) و آنها را بسازند و کاربر را مجبور کنند از آنها استفاده کنند و اگر کاربر استفاده نکرد به او لقب بیشعور بدهند، باید به فکر برطرف کردن نیاز واقعی او باشند.

نیاز از سمت مشتری، راه حل از سمت تیم

یکی از مشکلات این هست که مشتری راه حل به ما ارائه می کند ( من ERP میخام) و تیم توسعه نیازها را تعریف می کند (شما در بخش حسابداری مشکل دارید ما باید برای شما نرم افزار تولید کنیم). مارتین فولر جمله جالبی در یک کنفرانسی که  بنده  هم حضور داشتم گفت:

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

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

دو صد گفته چون نیم کردار نیست 

با همه این تفاسیر در نهایت ما باید تعدادی Feature بسازیم و آنها را ارزیابی کنیم. بدترین روش این است از مشتری بپرسیم که نظر شما چیست؟ احتمال زیاد برای اینکه شما ناراحت نشوید می گویند “خیلی عالی است”ولی شاید یک بار هم این قابلیت را استفاده نکرده باشد.

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

فنگ شویی کنید و شجاع باشید

اگر واقعا به این نتیجه رسیدید ویژگی شما استفاده نمی شود و کاربر نیز روی خوشی به آن نشان نمی دهد، شجاع باشید و آن را حذف کنید. نگویید “بذار باشه حالا بعدا یکی ازش استفاده می کنه، یا حیفه دو ماه روش کار کردیم حالا بذار باشه، یا ضرری نداره که بذار همون گوشه بمونه”.

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

امیدوارم این پست بلند خوب بوده باشد، اگر نظر خاصی برای ادامه این نوشته داشتید بسیار خوشحال می شوم در اینجا به اشتراک بگذارید.

اسد صفری

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

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

3 دیدگاه در “10 قانون اساسی در توسعه محصول نرم افزاری

  1. این ویژگی های بیخودی هم از دردهای مزمن همه پروژه هاست
    بعضی هایشان هم واقعا ایده جالبی است ولی در عمل واقعا مفید نیست و حتی دردسر ساز است
    مثال مارتین فائولر هم جالب بود. واقعا نیازمندی ها به تیم تولید ربطی نداره
    در مجموع مقاله پر محتوا و خوبی که آه از نهاد ما بلند کرد
    بازم بنویس
    موفق باشی

  2. سلام

    ممنون. خیلی ساده و کاربردی بود چون همه مشکلات اشاره شده را در یک پروژه سه ساله که در نهایت هم ناموفق بود تجربه کردم. واقعا امان از این فیچرهای اضافی… ای کاش چندتا راهکار عملی هم برای مقابله با مشتریانی که فیچرهای همه محصولات دنیا رو در محصول خودشون میخوان ارائه بدید …

پاسخ دادن به فاطمه لغو پاسخ

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

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