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

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

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

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

نتیجه

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

---

راهکارهایی برای مشتری، یا رزومه

تصمیمات اقتصادی تصمیمات احساسی

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

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

چند نمونه از نیازمندی هایی که به این صورت نیستند را در زیر می بینید:

• نرم افزار باید سریع باشد
• وبسایت باید زیبا باشد
• نرم افزار باید خوش دست باشد
• نرم افزار باید کاربران را مدیریت نمایید

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

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

• روی کامپیوتر با حداقل چه مشخصاتی برنامه اجرا خواهد شد؟
• آیا برنامه به صورت شبکه ای اجرا خواهد شد؟
• بالا آمدن برنامه باید در حداقل چه زمانی انجام شود؟ محدودیتی در این زمینه وجود دارد؟
• بارگزاری داده ها در فرم های اطلاعاتی حداکثر در چه زمانی انجام شود؟ (با در نظر گرفتن امکانات سخت افزاری)
• عمل ذخیره سازی حداکثر در چه زمانی انجام شود؟ (با در نظر گرفتن امکانات سخت افزاری)

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

حتی شاید با توجه به نیازمندی ارائه شده و امکانات موجود، نیازمندی ها غیر منطقی به نظر برسند و مورد قبول قرار نگیرند.

فاجعه اصلی

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

معمولا تحویل گرفتن نیازمندی ها به صورت غیر قابل اندازه گیری و مشخص مشکلات زیر را بوجود خواهد آورد:

• تحویل بسیار مشکل کار و عدم رضایت همیشگی مشتری
• عدم امکان طراحی و پیاده سازی نرم افزار مناسب نرم افزار و تکرار دوباره کارهای انجام شده به دلیل طراحی بد
• بی انگیزگی تیم تولید به دلیل حاشیه ها و تنش های ایجاد شده در تحویل کارها
• عدم امکان تهیه و ارائه گزارش پیشرفت پروژه

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