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

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

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

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

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

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

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

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

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

فاجعه اصلی

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

این موضوع را که بیشتر برنامه نویس ها چند شغله هستند نمی توان انکار کرد. در واقع این موضوع که اکثر ایرانی ها چند شغله هستند را نمی شود انکار کرد. حتی اگر کسی بتواند با شگردهای خلاقانه این موضوع را پنهان کند.

شاید بعضی مواردی که در این مطلب مطالعه خواهید کرد در مورد مشاغل غیر از برنامه نویسی نیز صحت داشته باشد.

چرا برنامه نویس ها چند شغله می شوند؟

۱) عدم امنیت شغلی

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

۲) پرداختی نامناسب

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

۳) یادگیری

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

۴) کسب تجربه

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

۵) پیشرفت

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

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

موارد ذکر شده از نظر اهمیت مرتب شده بودند. به طوری که موارد بالاتر از نظر بنده اهمیت بیشتری داشته اند.