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

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

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

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

نتیجه

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

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

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

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

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

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

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

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

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

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

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

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

فاجعه اصلی

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

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

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

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

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

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

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

متاسفانه در دنیای واقعی خیلی این اتفاق نمی افتد. تصمیمات برنامه نویس ها ممکن است بیشتر بر مبنای اثر آن موضوع خاص روی رزومه شخص گرفته شود. مثلا در انتخاب این که یک پروژه تحت وب single page باشد یا نه، قبل از این که به نیاز مشتری توجه شود ممکن است به سابقه کاری و فرصت کسب تجربه شخصی و اثر موضوع sinple page application روی روزمه شخص توجه شود.

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

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

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

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

*ایده اصلی این مطلب از یکی از بخش های کتاب ۹۷Things Every Software Architect Should Know گرفته شده است.

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

درسی از یک نرم افزار ۱۵ دقیقه ای